[Bug 82588] X fails to start with linus-tip or drm-next

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

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

--- Comment #21 from Mike Lothian  ---
Yes 3.17-rc5

I downloaded the firmware files when they were first made available back when
drm-next first added the support for the new firmware at the end of the 3.16
cycle

Those files must have been damaged - installing the latest linux-firmware (or
radeon-ucode) fixed this for me

You are probably suffering from a different issue and should raise a separate
bug

-- 
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/20140915/13f828d0/attachment.html>

[Bug 82588] X fails to start with linus-tip or drm-next

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

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

--- Comment #20 from Alex Deucher  ---
(In reply to comment #19)
> 
> So is it bad to use 3.16.2 and 3.17-rc5 because every kernel installs his
> firmware files to the same directory and overwrites the other one's?
> 
> The kernel installs the firmware with most of the filenames of r(v)+numbers
> in /lib/firmware/radeon/ .
> 
> And the gentoo package "x11-drivers/radeon-ucode-20140823" installs the
> files with the chip codenames and some numbered files which are not
> installed by the kernel in the same dir.
> 
> So much from me now for more confusion.

The firmware is not shipped with the kernel.  It's packaged separately.  The
firmware for your card has not changed in years so it's not likely to the same
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/20140915/df89c51c/attachment.html>

[Bug 82588] X fails to start with linus-tip or drm-next

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

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

--- Comment #19 from jospezial  ---
(In reply to comment #18)
> That's the issue - it seems there was an issue with the firmwares I
> downloaded
> 
> Isn't there new checking in the code to make sure the firmwares are correct?
> 
> Now running 3.16-rc5 with no issues

You wanted to say 3.17-rc5?

So is it bad to use 3.16.2 and 3.17-rc5 because every kernel installs his
firmware files to the same directory and overwrites the other one's?

The kernel installs the firmware with most of the filenames of r(v)+numbers in
/lib/firmware/radeon/ .

And the gentoo package "x11-drivers/radeon-ucode-20140823" installs the files
with the chip codenames and some numbered files which are not installed by the
kernel in the same dir.

So much from me now for more confusion.

You marked that bug as resolved/invalid.

Would you please tell me in detail, how you fixed this? I'd like to reopen this
bug.
Reverting "drm/radeon/cik: Add support for new ucode format (v5)" did not help
me.

I know I have to bisect ... But this is new stuff for 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/20140915/c7d6b43e/attachment.html>

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to comment #11)
> If I change /sys/class/backlight/radeon_bl0/brightness or
> /sys/class/backlight/acpi_video0 the display stayes dark.
> 
> @Alex
> is this what you wanted to know? If not, please let me know, how I could
> help you to debug this problem!

Without the patch from this bug report applied (e.g., when your display is
working), which, if any, of the blacklight interfaces work?  It seems like
perhaps your laptop claims to have a GPU controlled backlight, but really uses
an external backlight control.  Can you attach a copy of your vbios?  TO get a
copy of your vbios:

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

-- 
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/20140915/fe06a764/attachment.html>

[Bug 81382] Text console blanking does not go away

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

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

--- Comment #13 from Patrick  ---
(In reply to comment #12)

Hi Daniel,

correct, before that patch, the display was controllable through
/sys/class/backlight/acpi_video0/brightness.

After that patch, the display is always dark.

The only change which was done by Alex, was adding the lines, which you
commeted out. (If I understood the code correct, the other two lines, which
were removed, are obsolete and not needed).

So if you removed that two lines, then you've got the same code as before and
our Amilo (with ATI card) is working fine, but Denys problem will appear
again...

-- 
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/20140915/4848bcff/attachment.html>

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

[Laurent Pinchart]

Hi Ajay,

Thank you for the patch.

I think we're moving in the right direction, but we're not there yet.

On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> This patch tries to seperate drm_bridge implementation
> into 2 parts, a drm part and a non_drm part.
> 
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
> 
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add_for_lookup".
> 
> The parent encoder driver waits till the bridge is available in the
> lookup table(by calling "of_drm_find_bridge") and then continues with
> its initialization.

Before the introduction of the component framework I would have said this is 
the way to go. Now, I think bridges should register themselves as components, 
and the DRM master driver should use the component framework to get a 
reference to the bridges it needs.

> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> the drm_device and the encoder pointers to the bridge object.
> 
> Now that the drm_device pointer is available, the encoder then calls
> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> registering itself with the drm core.

This is what really bothers me with DRM bridge.

The framework assumes that a bridge will always bridge an encoder and a 
connector. Beside lacking support for chained bridges, this creates an 
artificial split between bridges and encoders by modeling the same components 
using drm_encoder or drm_bridge depending on their position in the video 
output pipeline.

I would like to see drm_bridge becoming more self-centric, removing the 
awareness of the upstream encoder and downstream connector. I'll give this a 
try, but it will conflict with this patch, so I'd like to share opinions and 
coordinate efforts sooner than later if possible.

> Also, non driver model based ptn3460 driver is removed in this patch.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 --
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/bridge/Kconfig |   12 +-
>  drivers/gpu/drm/bridge/Makefile|2 -
>  drivers/gpu/drm/bridge/ptn3460.c   |  343 -
>  drivers/gpu/drm/drm_bridge.c   |   89 +
>  drivers/gpu/drm/drm_crtc.c |9 +-
>  drivers/gpu/drm/exynos/Kconfig |3 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   57 ++--
>  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +-
>  include/drm/bridge/ptn3460.h   |   37 ---
>  include/drm/drm_crtc.h |   16 +-
>  13 files changed, 147 insertions(+), 453 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
>  delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
>  create mode 100644 drivers/gpu/drm/drm_bridge.c
>  delete mode 100644 include/drm/bridge/ptn3460.h

-- 
Regards,

Laurent Pinchart

[PATCH 0/9 linux-next] drivers/gpu/drm: use container_of where possible

[Fabian Frederick]

> On 15 September 2014 at 01:13 One Thousand Gnomes  lxorguk.ukuu.org.uk>
> wrote:
>
>
> On Sun, 14 Sep 2014 18:40:13 +0200
> Fabian Frederick  wrote:
>
> > Small patchset using container_of instead of casting on first structure
> > member address.
>
> Why. Container_of is useful for random offsets but its just convoluting
> and confusing code which is designed with the fields intentionally at the
> start.
>
> Alan

What if someone doesn't know about that intention one day and inserts
some field in the structure at the "wrong place" ?
This would need at least some comment in each declaration
but once again it's hard to control.One other way is to
commonly use container_of and get rid of every casting with
some semantic script.

Peter has been asking for container_of in the following:

http://marc.info/?l=linux-arm-kernel=140838705729653=2


struct uart_amba_port *uap = (struct uart_amba_port *)port

(port/uart_port is the first field in uart_amba_port though)

Regards,
Fabian

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Ezequiel Garcia]

On 15 Sep 05:59 PM, Dave Airlie wrote:
> On 15 September 2014 17:50, Ezequiel Garcia
>  wrote:
> > Dave,
> >
> > On 03 Sep 08:08 AM, Johannes Pointner wrote:
> >> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia  >> vanguardiasur.com.ar>:
> >> > Dave,
> >> >
> >> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
> >> > ready for v3.17, but it got no maintainer feedback or review. Maybe it 
> >> > fell
> >> > through some crack?
> >> >
> >> > Just for reference, here goes the details about this series and why it's
> >> > needed:
> >> >
> >> > This patchset adds the required changes to support an optional backlight
> >> > and GPIO for the tilcdc panel driver.
> >> >
> >> > There was some code to support a backlight, but it was broken and 
> >> > undocumented.
> >> > I've followed the nice implementation in panel-simple and added a similar
> >> > one here.
> >> >
> >> > The enable GPIO is required to turn on and off devices with such 
> >> > capability.
> >> > Also here, I've followed panel-simple which looks correct.
> >> >
> >> > In addition to this there are very minor cosmetic cleanups and a larger
> >> > fix for the error path in tilcdc's DRM driver .load error path.
> >> >
> >>
> >> I tested the series with 3.16.1 (with additonal patches from Guido and
> >> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
> >> me without an issue. I tried it with and without the backlight
> >> addition in the dts file.
> >>
> >> For the series:
> >> Tested-by: Johannes Pointner 
> >>
> >
> > Any feedback for this series?
> >
> > If at all possible, it'd be great to not miss the merge this time.
> 
> Could you stick it in a git tree somewhere? and send a pull request for it?
> 

Hm.. I really don't have a git tree ready :/

Do you think you can pick the patches this time? I'll setup a tree as soon
as possible.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

PATCH: radeondrm x86_64 and android32

[Sergey Korshunoff]

Hi Christian!
Yes, it is. Android-x86 4.0-r1 dos'nt fill right a value fild of the
structture drm_radeon_info_t: high bits are a random value. But I
wrote a compat function for this ioctl which clears this bits only for
32-bit applications. This patch is against a 3.10 kernel.

2014-09-15 15:54 GMT+04:00, Christian K?nig :
> Am 15.09.2014 um 12:09 schrieb Sergey Korshunoff:
>> Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
>> trying to use a radeon kms. The following change correct a problem:
>>
>> drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):
>>
>> - value_ptr = (uint32_t *)((unsigned long)info->value);
>> + value_ptr = (uint32_t *)((unsigned)info->value);
>>
>> Looks like a userspace data in android running under x86_64 is located
>> above 4 Gb. I don't think so. But after this change android run fine.
>
> That's most likely a bug on the userspace side, caused by the upper
> 32bits of info->value not initialized properly.
>
> The kernel patch you show above will most likely just break 64bit
> userspace.
>
> Regards,
> Christian.
>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 12-radeon-info-compat.patch
Type: application/octet-stream
Size: 2589 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140915/ba28c872/attachment.obj>

[PATCH 1/2] drm/i915: Fix Sink CRC

[Rodrigo Vivi]

In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.

So let's give up to 6 vblank wait time. However we now check for
TEST_CRC_COUNT that shows when panel finished to calculate CRC and
has it ready.

v2: Jani pointed out attempts decrements was wrong and should never reach
the error condition. And Daniel pointed out that EIO is more appropriated than
EGAIN. Also I realized that I have to read test_crc_count after setting
test_sink

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +++--
 include/drm/drm_dp_helper.h |  5 +++--
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f79473b..fae0fae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3468,21 +3468,30 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
*crc)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct intel_crtc *intel_crtc =
to_intel_crtc(intel_dig_port->base.base.crtc);
-   u8 buf[1];
+   u8 buf;
+   int test_crc_count;
+   int attempts = 6;

-   if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, buf) < 0)
+   if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, ) < 0)
return -EAGAIN;

-   if (!(buf[0] & DP_TEST_CRC_SUPPORTED))
+   if (!(buf & DP_TEST_CRC_SUPPORTED))
return -ENOTTY;

if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_SINK,
   DP_TEST_SINK_START) < 0)
return -EAGAIN;

-   /* Wait 2 vblanks to be sure we will have the correct CRC value */
-   intel_wait_for_vblank(dev, intel_crtc->pipe);
-   intel_wait_for_vblank(dev, intel_crtc->pipe);
+   drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, );
+   test_crc_count = buf & DP_TEST_COUNT_MASK;
+
+   do {
+   drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, );
+   intel_wait_for_vblank(dev, intel_crtc->pipe);
+   } while (--attempts && (buf & DP_TEST_COUNT_MASK) == test_crc_count);
+
+   if (attempts == 0)
+   return -EIO;

if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
return -EAGAIN;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9305c71..8edeed0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -303,7 +303,8 @@
 #define DP_TEST_CRC_B_CB   0x244

 #define DP_TEST_SINK_MISC  0x246
-#define DP_TEST_CRC_SUPPORTED  (1 << 5)
+# define DP_TEST_CRC_SUPPORTED (1 << 5)
+# define DP_TEST_COUNT_MASK0x7

 #define DP_TEST_RESPONSE   0x260
 # define DP_TEST_ACK   (1 << 0)
@@ -313,7 +314,7 @@
 #define DP_TEST_EDID_CHECKSUM  0x261

 #define DP_TEST_SINK   0x270
-#define DP_TEST_SINK_START (1 << 0)
+# define DP_TEST_SINK_START(1 << 0)

 #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
 # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
-- 
1.9.3

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #3 from Alex Deucher  ---
Can you try it to be sure to at least narrow down what the problem might be?

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

DRM encoder/bridge architecture questions

[Laurent Pinchart]

Hi Sean,

On Monday 18 August 2014 16:29:24 Sean Cross wrote:
> Hi,
> 
> We've got an IT6251 LVDS -> eDP bridge chip we're hanging off of a
> dual-lane LVDS port on an i.MX6.  We have a driver we're using
> internally that's little more than a series of register pokes to boot
> the chip, but I'd like to clean it up for submission.
> 
> What kind of device is this?  It's externally connected to the main SoC
> via LVDS and I2C.

The kernel organizes its device hierarchy based on control buses, so this 
should be an I2C device.

> It's conceptually hanging off of the ldb "LVDS Display Bridge" encoder,
> which means it's an encoder attached to an encoder.  Is that allowed in the
> DRM model?

That's not allowed by the device model DRM exposes to userspace, but it's 
allowed internally in the kernel using the drm_bridge framework that has been 
designed to support chained encoders.

I'm not happy with the current implementation though.   Ajay Kumar has posted a 
patch series named "[PATCH V6 0/8] drm/exynos: few patches to enhance bridge 
chip support" that pushes the DRM bridge framework in the right direction, but 
we're not there yet. I'll reply to the patches now and will CC you.

> With the current driver, I have it just sitting in drivers/gpu/drm/i2c/,
> and it's not "attached" to anything.  The encoder chip automatically
> figures out display timings and the like.  Where should the file
> actually go?

If you implement it as a bridge, probably in drivers/gpu/drm/bridge, but if 
you implement it as a slave encoder (which is another DRM framework to support 
I2C encoders) then it's in the right place. The two frameworks should 
eventually be merged.

> Finally, how would the driver get attached to the system?  I see there's an
> Exynos bridge device that appears to go the other way, but it's explicitly
> loaded by the Exynos display adapter. Since most devices will have an LVDS
> panel attached directly to the LDB port, it seems silly to have it
> explicitly look for an additional bridge device to plug in as this is a
> special case. Is there any way I could pass the it6251 a handle to the ldb
> in device tree and have it hang itselff of the end that way?

That's how it should work, connections between components should be modeled in 
DT using phandles (see Documentation/devicetree/bindings/graph.txt and 
Documentation/devicetree/bindings/video/ti,omap-dss.txt for instance). Your 
DRM driver should use the component framework (include/linux/component.h) to 
get references to all external components it needs. There are several 
implementations in progress, but none yet that (in my opinion) is clean and 
standard enough to serve as a good example.

-- 
Regards,

Laurent Pinchart

[Bug 82588] X fails to start with linus-tip or drm-next

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

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

Mike Lothian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #18 from Mike Lothian  ---
That's the issue - it seems there was an issue with the firmwares I downloaded

Isn't there new checking in the code to make sure the firmwares are correct?

Now running 3.16-rc5 with no issues

-- 
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/20140915/004b9d21/attachment-0001.html>

[PATCH 3/3] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Vivek Gautam]

DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
---
 arch/arm/boot/dts/exynos5250.dtsi |2 +-
 arch/arm/boot/dts/exynos5420.dtsi |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index f21b9aa..9b85a2b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@

dp_phy: video-phy at 10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040720 4>;
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index bfe056d..a677812 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};

dp_phy: video-phy at 10040728 {
-   compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040728 4>;
+   compatible = "samsung,exynos5420-dp-video-phy";
+   samsung,pmu-syscon = <_system_controller>;
#phy-cells = <0>;
};

-- 
1.7.10.4

[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c |   58 +++
 drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
 2 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4f3c7eb..5ffc1b2 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,

 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_on(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg |= dp->enable_mask;
-   __raw_writel(reg, dp->phy_addr);
-   }
 }

 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_off(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg &= ~(dp->enable_mask);
-   __raw_writel(reg, dp->phy_addr);
-   }
 }

 static void exynos_dp_poweron(struct exynos_drm_display *display)
@@ -1210,39 +1196,21 @@ static struct video_info 
*exynos_dp_dt_parse_pdata(struct device *dev)

 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 {
-   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-   u32 phy_base;
int ret = 0;

-   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-   if (!dp_phy_node) {
-   dp->phy = devm_phy_get(dp->dev, "dp");
-   return PTR_ERR_OR_ZERO(dp->phy);
-   }
-
-   if (of_property_read_u32(dp_phy_node, "reg", _base)) {
-   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-   >enable_mask)) {
-   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   dp->phy_addr = ioremap(phy_base, SZ_4);
-   if (!dp->phy_addr) {
-   dev_err(dp->dev, "failed to ioremap dp-phy\n");
-   ret = -ENOMEM;
-   goto err;
+   dp->phy = devm_phy_get(dp->dev, "dp");
+   if (IS_ERR(dp->phy)) {
+   ret = PTR_ERR(dp->phy);
+   if (ret == -ENOSYS || ret == -ENODEV) {
+   dp->phy = NULL;
+   } else if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else {
+   dev_err(dp->dev, "no DP phy configured\n");
+   return ret;
+   }
}

-err:
-   of_node_put(dp_phy_node);
-
return ret;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..6426201 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,8 +153,6 @@ struct exynos_dp_device {
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-   void __iomem*phy_addr;
-   unsigned intenable_mask;

struct video_info   *video_info;
struct link_train   link_train;
-- 
1.7.10.4

[PATCH 1/3] phy: exynos-dp-video: Use syscon support to control pmu register

[Vivek Gautam]

Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.

To facilitate this, we have added another compatible string
for Exynso5420 SoC to acquire driver data which contains
different DP-PHY-CONTROL register offset.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/phy/samsung-phy.txt|7 +-
 drivers/phy/phy-exynos-dp-video.c  |   76 ++--
 2 files changed, 59 insertions(+), 24 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7a6feea..15e0f2c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -17,8 +17,11 @@ Samsung EXYNOS SoC series Display Port PHY
 -

 Required properties:
-- compatible : should be "samsung,exynos5250-dp-video-phy";
-- reg : offset and length of the Display Port PHY register set;
+- compatible : should be one of the following supported values:
+- "samsung,exynos5250-dp-video-phy"
+- "samsung,exynos5420-dp-video-phy"
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 0;

 Samsung S5P/EXYNOS SoC series USB PHY
diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 8b3026e..f093719 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -13,44 +13,58 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 

 /* DPTX_PHY_CONTROL register */
 #define EXYNOS_DPTX_PHY_ENABLE (1 << 0)

+struct exynos_dp_video_phy_drvdata {
+   u32 phy_ctrl_offset;
+};
+
 struct exynos_dp_video_phy {
void __iomem *regs;
+   const struct exynos_dp_video_phy_drvdata *drvdata;
 };

-static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+static void exynos_dp_video_phy_pwr_isol(struct exynos_dp_video_phy *state,
+   unsigned int on)
 {
-   u32 reg;
+   unsigned int val;

-   reg = readl(state->regs);
-   if (on)
-   reg |= EXYNOS_DPTX_PHY_ENABLE;
-   else
-   reg &= ~EXYNOS_DPTX_PHY_ENABLE;
-   writel(reg, state->regs);
+   if (IS_ERR(state->regs))
+   return;

-   return 0;
+   val = on ? 0 : EXYNOS_DPTX_PHY_ENABLE;
+
+   regmap_update_bits(state->regs, state->drvdata->phy_ctrl_offset,
+  EXYNOS_DPTX_PHY_ENABLE, val);
 }

 static int exynos_dp_video_phy_power_on(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);

-   return __set_phy_state(state, 1);
+   /* Disable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 0);
+
+   return 0;
 }

 static int exynos_dp_video_phy_power_off(struct phy *phy)
 {
struct exynos_dp_video_phy *state = phy_get_drvdata(phy);

-   return __set_phy_state(state, 0);
+   /* Enable power isolation on DP-PHY */
+   exynos_dp_video_phy_pwr_isol(state, 1);
+
+   return 0;
 }

 static struct phy_ops exynos_dp_video_phy_ops = {
@@ -59,11 +73,31 @@ static struct phy_ops exynos_dp_video_phy_ops = {
.owner  = THIS_MODULE,
 };

+static const struct exynos_dp_video_phy_drvdata exynos5250_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5_DPTX_PHY_CONTROL,
+};
+
+static const struct exynos_dp_video_phy_drvdata exynos5420_dp_video_phy = {
+   .phy_ctrl_offset= EXYNOS5420_DPTX_PHY_CONTROL,
+};
+
+static const struct of_device_id exynos_dp_video_phy_of_match[] = {
+   {
+   .compatible = "samsung,exynos5250-dp-video-phy",
+   .data = _dp_video_phy,
+   }, {
+   .compatible = "samsung,exynos5420-dp-video-phy",
+   .data = _dp_video_phy,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_video_phy_of_match);
+
 static int exynos_dp_video_phy_probe(struct platform_device *pdev)
 {
struct exynos_dp_video_phy *state;
struct device *dev = >dev;
-   struct resource *res;
+   const struct of_device_id *match;
struct phy_provider *phy_provider;
struct phy *phy;

@@ -71,11 +105,15 @@ static int exynos_dp_video_phy_probe(struct 
platform_device *pdev)
if (!state)
return -ENOMEM;

-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
-   state->regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(state->regs))
+   

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

[Vivek Gautam]

These patches are based on 'for-next' branch of kgene's linux-samsung tree.

Refactoring the exynos-dp-video phy to use pmu-system-controller handle
and access the register using mfd-syscon and regmap.
Simultaneously, removing the support for older dptx-phy, since it's obsolete
now and noone uses it.

Vivek Gautam (3):
  phy: exynos-dp-video: Use syscon support to control pmu register
  drm/exynos: dp: Remove support for unused dptx-phy
  arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

 .../devicetree/bindings/phy/samsung-phy.txt|7 +-
 arch/arm/boot/dts/exynos5250.dtsi  |2 +-
 arch/arm/boot/dts/exynos5420.dtsi  |4 +-
 drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
 drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
 drivers/phy/phy-exynos-dp-video.c  |   76 ++--
 6 files changed, 75 insertions(+), 74 deletions(-)

-- 
1.7.10.4

PATCH: radeondrm x86_64 and android32

[Christian König]

Hi Sergey,

that probably works, but a compat function is the wrong approach here.

The definition of the field was always 64bit and when userspace fails to 
properly set the upper 32bits than userspace needs to get fixed, not the 
kernel.

Can you try to figure out where the random bits in the upper 32bits come 
from?

Regards,
Christian.

Am 15.09.2014 um 17:43 schrieb Sergey Korshunoff:
> Hi Christian!
> Yes, it is. Android-x86 4.0-r1 dos'nt fill right a value fild of the
> structture drm_radeon_info_t: high bits are a random value. But I
> wrote a compat function for this ioctl which clears this bits only for
> 32-bit applications. This patch is against a 3.10 kernel.
>
> 2014-09-15 15:54 GMT+04:00, Christian K?nig :
>> Am 15.09.2014 um 12:09 schrieb Sergey Korshunoff:
>>> Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
>>> trying to use a radeon kms. The following change correct a problem:
>>>
>>> drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):
>>>
>>> - value_ptr = (uint32_t *)((unsigned long)info->value);
>>> + value_ptr = (uint32_t *)((unsigned)info->value);
>>>
>>> Looks like a userspace data in android running under x86_64 is located
>>> above 4 Gb. I don't think so. But after this change android run fine.
>> That's most likely a bug on the userspace side, caused by the upper
>> 32bits of info->value not initialized properly.
>>
>> The kernel patch you show above will most likely just break 64bit
>> userspace.
>>
>> Regards,
>> Christian.
>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Dave Airlie]

On 15 September 2014 17:50, Ezequiel Garcia
 wrote:
> Dave,
>
> On 03 Sep 08:08 AM, Johannes Pointner wrote:
>> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia > vanguardiasur.com.ar>:
>> > Dave,
>> >
>> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
>> > ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
>> > through some crack?
>> >
>> > Just for reference, here goes the details about this series and why it's
>> > needed:
>> >
>> > This patchset adds the required changes to support an optional backlight
>> > and GPIO for the tilcdc panel driver.
>> >
>> > There was some code to support a backlight, but it was broken and 
>> > undocumented.
>> > I've followed the nice implementation in panel-simple and added a similar
>> > one here.
>> >
>> > The enable GPIO is required to turn on and off devices with such 
>> > capability.
>> > Also here, I've followed panel-simple which looks correct.
>> >
>> > In addition to this there are very minor cosmetic cleanups and a larger
>> > fix for the error path in tilcdc's DRM driver .load error path.
>> >
>>
>> I tested the series with 3.16.1 (with additonal patches from Guido and
>> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
>> me without an issue. I tried it with and without the backlight
>> addition in the dts file.
>>
>> For the series:
>> Tested-by: Johannes Pointner 
>>
>
> Any feedback for this series?
>
> If at all possible, it'd be great to not miss the merge this time.

Could you stick it in a git tree somewhere? and send a pull request for it?

Dave.

[Bug 83461] hdmi screen flicker/unusable

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

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

kb at spatium.org changed:

   What|Removed |Added

 Regression|No  |Yes

--- Comment #2 from kb at spatium.org ---
I haven't tried myself, but according to publicly available forums it would
help. However, I need hdmi audio working, so I can't use this as a workaround.

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

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

So final feature pull request for 3.18. QA isn't really done yet with the
manul testing, but this help up a week of soaking so should be fairly
ok-ish. And I think holding up merging doesn't really help anyone,
especially since I want to rebase my 3.19 queue on top of drm-next with
all the branches that just landed.

drm-intel-next-2014-09-05:
- final bits (again) for the rotation support (Sonika Jindal)
- support bl_power in the intel backlight (Jani)
- vdd handling improvements from Ville
- i830M fixes from Ville
- piles of prep work all over to make skl enabling just plug in (Damien, Sonika)
- rename DP training defines to reflect latest edp standards, this touches all
  drm drivers supporting DP (Sonika Jindal)
- cache edids during single detect cycle to avoid re-reading it for e.g. audio,
  from Chris
- move w/a for registers which are stored in the hw context to the context init
  code (Arun)
- edp panel power sequencer fixes, helps chv a lot (Ville)
- piles of other chv fixes all over
- much more paranoid pageflip handling with stall detection and better recovery
  from Chris
- small things all over, as usual

Aside: A backmerge of latest drm-fixes would be good to baseline 3.19
stuff on top. Note that there's a conflict in i915 which gcc will catch -
you need to add a local dev_prive = dev->dev_private somewhere.

Cheers, Daniel


The following changes since commit 47c1296829505d119d7d58dd23d39cc5db344f12:

  drm/qxl: enables gem prime helpers for qxl using dummy driver callbacks 
(2014-09-03 15:36:52 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-09-05

for you to fetch changes up to a12624959ad4e3bfa8c344ad71728ffc9a379158:

  drm/i915: Update DRIVER_DATE to 20140905 (2014-09-05 14:57:29 +0200)


- final bits (again) for the rotation support (Sonika Jindal)
- support bl_power in the intel backlight (Jani)
- vdd handling improvements from Ville
- i830M fixes from Ville
- piles of prep work all over to make skl enabling just plug in (Damien, Sonika)
- rename DP training defines to reflect latest edp standards, this touches all
  drm drivers supporting DP (Sonika Jindal)
- cache edids during single detect cycle to avoid re-reading it for e.g. audio,
  from Chris
- move w/a for registers which are stored in the hw context to the context init
  code (Arun)
- edp panel power sequencer fixes, helps chv a lot (Ville)
- piles of other chv fixes all over
- much more paranoid pageflip handling with stall detection and better recovery
  from Chris
- small things all over, as usual


Andy Shevchenko (1):
  drm: i915: reduce memory footprint when debugging

Arun Siluvery (2):
  drm/i915/bdw: Apply workarounds in render ring init function
  drm/i915/bdw: Export workaround data to debugfs

Ben Widawsky (1):
  drm/i915: Don't save/restore RS when not used

Chris Wilson (15):
  drm/i915: Do not access stolen memory directly by the CPU, even for error 
capture
  drm/i915: Remove num_pages parameter to i915_error_object_create()
  drm/i915: Suppress a WARN on reading an object back for a GPU hang
  drm/i915: honour forced connector modes
  drm/i915: Make wait-for-pending-flips more defensive
  drm/i915: Differentiate between LLC or snooped for the user
  drm/i915/dp: Refactor common eDP lid detection
  drm/i915/dp: Cache EDID for a detection cycle
  drm/i915/hdmi: Cache EDID for a detection cycle
  drm/i915: Rename global latency_ns variable
  drm/i915: Remove shadowed local variable 'i' from i915_interrupt_info
  drm/i915: Fix unsafe vma iteration in i915_drop_caches
  drm/i915: Reset the HEAD pointer for the ring after writing START
  drm/i915: Check for a stalled page flip after each vblank
  drm/i915: Decouple the stuck pageflip on modeset

Daisy Sun (1):
  drm/i915/bdw: BDW Software Turbo

Damien Lespiau (12):
  drm/i915: Use dev_priv as first argument of for_each_pipe()
  drm/i915: Print the pipe on which the vblank wait times out
  drm/i915: Don't use a define when it's clearer to just put the value
  drm/i915: Add "Intel Corporation" as module author
  drm/i915/bdw: Let the memory controller do all the swizzling
  drm/i915: Rename intel_wa_registers with a i915_ prefix
  drm/i915: Don't overrun the intel_wa_regs array
  drm/i915: Don't silently discard workarounds
  drm/i915: Remove unneeded brackets
  drm/i915: Don't restrict i915_wa_registers to BDW
  drm/i915: Rewrite ABS_DIFF() in a safer manner
  drm/i915: Introduce a for_each_plane() macro

Daniel Vetter (2):
  MAINTAINERS: Update Daniel Vetter's email address
  drm/i915: Update DRIVER_DATE to 20140905

Deepak S (2):
  drm/i915: Bring UP Power Wells before disabling RC6.
  drm/i915: Fix to Enable GT/PM 

[Bug 83810] Blender Weight paint mode doesn't work with enabled VBOs.

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

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

--- Comment #4 from sunweb at hotmail.ru ---
When running Blender i get no messages in dmesg.

-- 
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/20140915/a61f38b8/attachment.html>

Shareable bufmgr objects v4

[Damien Lespiau]

On Mon, Sep 15, 2014 at 02:12:25PM +0100, Chris Wilson wrote:
> On Fri, Sep 12, 2014 at 01:48:34PM +0100, Lionel Landwerlin wrote:
> > This is getting bigger than expected. Adding the locking that Chris
> > suggested on IRC.
> > 
> > Thanks for taking time to review Chris.
> 
> I'm happy with this series,
> Reviewed-by: Chris Wilson 

Just landed the series for Lionel (who doesn't have access to this git
repo) then.

-- 
Damien

[PATCH 11/11] drm/i915: Clarify mmio_flip_lock locking

[Daniel Vetter]

The ->queue_flip callback is always called from process context, so
plain _irq spinlock variants are enough.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c01d783e59b1..a8632f6937ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9849,7 +9849,6 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   unsigned long irq_flags;
int ret;

if (WARN_ON(intel_crtc->mmio_flip.seqno))
@@ -9863,10 +9862,10 @@ static int intel_queue_mmio_flip(struct drm_device *dev,
return 0;
}

-   spin_lock_irqsave(_priv->mmio_flip_lock, irq_flags);
+   spin_lock_irq(_priv->mmio_flip_lock);
intel_crtc->mmio_flip.seqno = obj->last_write_seqno;
intel_crtc->mmio_flip.ring_id = obj->ring->id;
-   spin_unlock_irqrestore(_priv->mmio_flip_lock, irq_flags);
+   spin_unlock_irq(_priv->mmio_flip_lock);

/*
 * Double check to catch cases where irq fired before
-- 
1.9.3

[PATCH 10/11] drm/i915: Clarify uncore.lock locking

[Daniel Vetter]

Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.

Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runtime pm reference
but just check that the device isn't suspended - we have this duplicated
in the execlist code, too.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d120dfff3841..c01d783e59b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7660,7 +7660,6 @@ static void hsw_disable_lcpll(struct drm_i915_private 
*dev_priv,
 static void hsw_restore_lcpll(struct drm_i915_private *dev_priv)
 {
uint32_t val;
-   unsigned long irqflags;

val = I915_READ(LCPLL_CTL);

@@ -7680,10 +7679,10 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
 * to call special forcewake code that doesn't touch runtime PM and
 * doesn't enable the forcewake delayed work.
 */
-   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+   spin_lock_irq(_priv->uncore.lock);
if (dev_priv->uncore.forcewake_count++ == 0)
dev_priv->uncore.funcs.force_wake_get(dev_priv, FORCEWAKE_ALL);
-   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+   spin_unlock_irq(_priv->uncore.lock);

if (val & LCPLL_POWER_DOWN_ALLOW) {
val &= ~LCPLL_POWER_DOWN_ALLOW;
@@ -7714,10 +7713,10 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
}

/* See the big comment above. */
-   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+   spin_lock_irq(_priv->uncore.lock);
if (--dev_priv->uncore.forcewake_count == 0)
dev_priv->uncore.funcs.force_wake_put(dev_priv, FORCEWAKE_ALL);
-   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+   spin_unlock_irq(_priv->uncore.lock);
 }

 /*
-- 
1.9.3

[PATCH 09/11] drm/i915: Convert backlight_lock to a mutex

[Daniel Vetter]

Originally the irq safe spinlock was required because of asle
interrupts. But since

commit 7bd688cd66db93f6430f6e2b3145ee5686daa315
Author: Jani Nikula 
Date:   Fri Nov 8 16:48:56 2013 +0200

drm/i915: handle backlight through chip specific functions

there's no need for this any more. So switch to the simpler mutex.

Cc: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_panel.c | 30 --
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 1403b01e8216..0bc1583114e7 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1614,7 +1614,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)

spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
-   spin_lock_init(_priv->backlight_lock);
+   mutex_init(_priv->backlight_lock);
spin_lock_init(_priv->uncore.lock);
spin_lock_init(_priv->mm.object_stat_lock);
spin_lock_init(_priv->mmio_flip_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17dfce0f4e68..07dafa2c2d8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1528,7 +1528,7 @@ struct drm_i915_private {
struct intel_overlay *overlay;

/* backlight registers and fields in struct intel_panel */
-   spinlock_t backlight_lock;
+   struct mutex backlight_lock;

/* LVDS info */
bool no_aux_handshake;
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 18784470a760..f17ada3742de 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -538,14 +538,13 @@ static u32 intel_panel_get_backlight(struct 
intel_connector *connector)
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 val;
-   unsigned long flags;

-   spin_lock_irqsave(_priv->backlight_lock, flags);
+   mutex_lock(_priv->backlight_lock);

val = dev_priv->display.get_backlight(connector);
val = intel_panel_compute_brightness(connector, val);

-   spin_unlock_irqrestore(_priv->backlight_lock, flags);
+   mutex_unlock(_priv->backlight_lock);

DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
return val;
@@ -629,12 +628,11 @@ static void intel_panel_set_backlight(struct 
intel_connector *connector,
struct intel_panel *panel = >panel;
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 hw_level;
-   unsigned long flags;

if (!panel->backlight.present || pipe == INVALID_PIPE)
return;

-   spin_lock_irqsave(_priv->backlight_lock, flags);
+   mutex_lock(_priv->backlight_lock);

WARN_ON(panel->backlight.max == 0);

@@ -644,7 +642,7 @@ static void intel_panel_set_backlight(struct 
intel_connector *connector,
if (panel->backlight.enabled)
intel_panel_actually_set_backlight(connector, hw_level);

-   spin_unlock_irqrestore(_priv->backlight_lock, flags);
+   mutex_unlock(_priv->backlight_lock);
 }

 /* set backlight brightness to level in range [0..max], assuming hw min is
@@ -658,12 +656,11 @@ void intel_panel_set_backlight_acpi(struct 
intel_connector *connector,
struct intel_panel *panel = >panel;
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 hw_level;
-   unsigned long flags;

if (!panel->backlight.present || pipe == INVALID_PIPE)
return;

-   spin_lock_irqsave(_priv->backlight_lock, flags);
+   mutex_lock(_priv->backlight_lock);

WARN_ON(panel->backlight.max == 0);

@@ -679,7 +676,7 @@ void intel_panel_set_backlight_acpi(struct intel_connector 
*connector,
if (panel->backlight.enabled)
intel_panel_actually_set_backlight(connector, hw_level);

-   spin_unlock_irqrestore(_priv->backlight_lock, flags);
+   mutex_unlock(_priv->backlight_lock);
 }

 static void pch_disable_backlight(struct intel_connector *connector)
@@ -733,7 +730,6 @@ void intel_panel_disable_backlight(struct intel_connector 
*connector)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_panel *panel = >panel;
enum pipe pipe = intel_get_pipe_from_connector(connector);
-   unsigned long flags;

if (!panel->backlight.present || pipe == INVALID_PIPE)
return;
@@ -749,14 +745,14 @@ void intel_panel_disable_backlight(struct intel_connector 
*connector)
return;
}

-   spin_lock_irqsave(_priv->backlight_lock, flags);
+   mutex_lock(_priv->backlight_lock);

if (panel->backlight.device)

[PATCH 08/11] drm/i915: Clarify irq_lock locking, special cases

[Daniel Vetter]

Grab bag for all the special cases:
- i9xx_check_fifo_underruns is only called from crtc_enable hooks,
  i.e. process context.
- i915_enable_asle_pipestat is only called from interrupt postinstall
  hooks. So again process context.
- gen8_irq_power_well_post_enable is called from the runtime pm code,
  which again means process context.
- The open-coded hpd_irq_setup loop in _thaw is also running in process
  context.

So for all of them the plain _irq variant is sufficient.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c |  5 ++---
 drivers/gpu/drm/i915/i915_irq.c | 16 ++--
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b8bd0080603e..8ce1b13ad97e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -686,11 +686,10 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
intel_modeset_init_hw(dev);

{
-   unsigned long irqflags;
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
if (dev_priv->display.hpd_irq_setup)
dev_priv->display.hpd_irq_setup(dev);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
}

intel_dp_mst_resume(dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6a4f389ff2f5..a08cdc62f841 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -310,9 +310,8 @@ void i9xx_check_fifo_underruns(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *crtc;
-   unsigned long flags;

-   spin_lock_irqsave(_priv->irq_lock, flags);
+   spin_lock_irq(_priv->irq_lock);

for_each_intel_crtc(dev, crtc) {
u32 reg = PIPESTAT(crtc->pipe);
@@ -331,7 +330,7 @@ void i9xx_check_fifo_underruns(struct drm_device *dev)
DRM_ERROR("pipe %c underrun\n", pipe_name(crtc->pipe));
}

-   spin_unlock_irqrestore(_priv->irq_lock, flags);
+   spin_unlock_irq(_priv->irq_lock);
 }

 static void i9xx_set_fifo_underrun_reporting(struct drm_device *dev,
@@ -696,19 +695,18 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv, 
enum pipe pipe,
 static void i915_enable_asle_pipestat(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long irqflags;

if (!dev_priv->opregion.asle || !IS_MOBILE(dev))
return;

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);

i915_enable_pipestat(dev_priv, PIPE_B, PIPE_LEGACY_BLC_EVENT_STATUS);
if (INTEL_INFO(dev)->gen >= 4)
i915_enable_pipestat(dev_priv, PIPE_A,
 PIPE_LEGACY_BLC_EVENT_STATUS);

-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
 }

 /**
@@ -3477,14 +3475,12 @@ static void gen8_irq_reset(struct drm_device *dev)

 void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv)
 {
-   unsigned long irqflags;
-
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
GEN8_IRQ_INIT_NDX(DE_PIPE, PIPE_B, dev_priv->de_irq_mask[PIPE_B],
  ~dev_priv->de_irq_mask[PIPE_B]);
GEN8_IRQ_INIT_NDX(DE_PIPE, PIPE_C, dev_priv->de_irq_mask[PIPE_C],
  ~dev_priv->de_irq_mask[PIPE_C]);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
 }

 static void cherryview_irq_preinstall(struct drm_device *dev)
-- 
1.9.3

[PATCH 07/11] drm/i915: Clarify irq_lock locking, irq handlers

[Daniel Vetter]

irq handlers always run with interrupts locally disabled, so
plain spinlocks is all we need. I've also reviewed again that they
all follow the _irq_handler postfix convention.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a829619aa111..6a4f389ff2f5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4063,7 +4063,6 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
struct drm_i915_private *dev_priv = dev->dev_private;
u16 iir, new_iir;
u32 pipe_stats[2];
-   unsigned long irqflags;
int pipe;
u16 flip_mask =
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
@@ -4079,7 +4078,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
 * It doesn't set the bit in iir again, but it still produces
 * interrupts (for non-MSI).
 */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock(_priv->irq_lock);
if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
i915_handle_error(dev, false,
  "Command parser error, iir 0x%08x",
@@ -4095,7 +4094,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
if (pipe_stats[pipe] & 0x8000)
I915_WRITE(reg, pipe_stats[pipe]);
}
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock(_priv->irq_lock);

I915_WRITE16(IIR, iir & ~flip_mask);
new_iir = I915_READ16(IIR); /* Flush posted writes */
@@ -4249,7 +4248,6 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
struct drm_device *dev = arg;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 iir, new_iir, pipe_stats[I915_MAX_PIPES];
-   unsigned long irqflags;
u32 flip_mask =
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
@@ -4265,7 +4263,7 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
 * It doesn't set the bit in iir again, but it still produces
 * interrupts (for non-MSI).
 */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock(_priv->irq_lock);
if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
i915_handle_error(dev, false,
  "Command parser error, iir 0x%08x",
@@ -4281,7 +4279,7 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
irq_received = true;
}
}
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock(_priv->irq_lock);

if (!irq_received)
break;
@@ -4476,7 +4474,6 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 iir, new_iir;
u32 pipe_stats[I915_MAX_PIPES];
-   unsigned long irqflags;
int ret = IRQ_NONE, pipe;
u32 flip_mask =
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
@@ -4493,7 +4490,7 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 * It doesn't set the bit in iir again, but it still produces
 * interrupts (for non-MSI).
 */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock(_priv->irq_lock);
if (iir & I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT)
i915_handle_error(dev, false,
  "Command parser error, iir 0x%08x",
@@ -4511,7 +4508,7 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
irq_received = true;
}
}
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock(_priv->irq_lock);

if (!irq_received)
break;
-- 
1.9.3

[PATCH 06/11] drm/i915: Clarify irq_lock locking, interrupt install/uninstall

[Daniel Vetter]

All the interrupt setup/teardown hooks are always run from plain
process context. So again just the _irq variant is good enough.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c | 42 ++---
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4906823baa11..a829619aa111 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3603,7 +3603,6 @@ static void gen5_gt_irq_postinstall(struct drm_device 
*dev)

 static int ironlake_irq_postinstall(struct drm_device *dev)
 {
-   unsigned long irqflags;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 display_mask, extra_mask;

@@ -3642,9 +3641,9 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
 * spinlocking not required here for correctness since interrupt
 * setup is guaranteed to run in single-threaded context. But we
 * need it to make the assert_spin_locked happy. */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
ironlake_enable_display_irq(dev_priv, DE_PCU_EVENT);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
}

return 0;
@@ -3740,7 +3739,6 @@ void valleyview_disable_display_irqs(struct 
drm_i915_private *dev_priv)
 static int valleyview_irq_postinstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long irqflags;

dev_priv->irq_mask = ~0;

@@ -3754,10 +3752,10 @@ static int valleyview_irq_postinstall(struct drm_device 
*dev)

/* Interrupt setup is already guaranteed to be single-threaded, this is
 * just to make the assert_spin_locked check happy. */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
if (dev_priv->display_irqs_enabled)
valleyview_display_irqs_install(dev_priv);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

I915_WRITE(VLV_IIR, 0x);
I915_WRITE(VLV_IIR, 0x);
@@ -3848,7 +3846,6 @@ static int cherryview_irq_postinstall(struct drm_device 
*dev)
I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
u32 pipestat_enable = PLANE_FLIP_DONE_INT_STATUS_VLV |
PIPE_CRC_DONE_INTERRUPT_STATUS;
-   unsigned long irqflags;
int pipe;

/*
@@ -3860,11 +3857,11 @@ static int cherryview_irq_postinstall(struct drm_device 
*dev)
for_each_pipe(dev_priv, pipe)
I915_WRITE(PIPESTAT(pipe), 0x);

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
for_each_pipe(dev_priv, pipe)
i915_enable_pipestat(dev_priv, pipe, pipestat_enable);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

I915_WRITE(VLV_IIR, 0x);
I915_WRITE(VLV_IMR, dev_priv->irq_mask);
@@ -3891,7 +3888,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
 static void valleyview_irq_uninstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long irqflags;
int pipe;

if (!dev_priv)
@@ -3906,10 +3902,12 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   /* Interrupt setup is already guaranteed to be single-threaded, this is
+* just to make the assert_spin_locked check happy. */
+   spin_lock_irq(_priv->irq_lock);
if (dev_priv->display_irqs_enabled)
valleyview_display_irqs_uninstall(dev_priv);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

dev_priv->irq_mask = 0;

@@ -3995,7 +3993,6 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
 static int i8xx_irq_postinstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long irqflags;

I915_WRITE16(EMR,
 ~(I915_ERROR_PAGE_TABLE | I915_ERROR_MEMORY_REFRESH));
@@ -4018,10 +4015,10 @@ static int i8xx_irq_postinstall(struct drm_device *dev)

/* Interrupt setup is already guaranteed to be single-threaded, this is
 * just to make the assert_spin_locked check happy. */
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
i915_enable_pipestat(dev_priv, PIPE_A, PIPE_CRC_DONE_INTERRUPT_STATUS);
i915_enable_pipestat(dev_priv, 

[PATCH 05/11] drm/i915: Clarify irq_lock locking, work functions

[Daniel Vetter]

Work functions are in process context, so plain _irq spinlock variants
is all we need.

The hpd reenable work didn't follow the _work/_work_func postfix
naming scheme, so adjust that while at it.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d22f87020aee..4906823baa11 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1096,18 +1096,17 @@ static void i915_digport_work_func(struct work_struct 
*work)
 {
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, dig_port_work);
-   unsigned long irqflags;
u32 long_port_mask, short_port_mask;
struct intel_digital_port *intel_dig_port;
int i, ret;
u32 old_bits = 0;

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
long_port_mask = dev_priv->long_hpd_port_mask;
dev_priv->long_hpd_port_mask = 0;
short_port_mask = dev_priv->short_hpd_port_mask;
dev_priv->short_hpd_port_mask = 0;
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

for (i = 0; i < I915_MAX_PORTS; i++) {
bool valid = false;
@@ -1132,9 +1131,9 @@ static void i915_digport_work_func(struct work_struct 
*work)
}

if (old_bits) {
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
dev_priv->hpd_event_bits |= old_bits;
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
schedule_work(_priv->hotplug_work);
}
 }
@@ -1153,7 +1152,6 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
struct intel_connector *intel_connector;
struct intel_encoder *intel_encoder;
struct drm_connector *connector;
-   unsigned long irqflags;
bool hpd_disabled = false;
bool changed = false;
u32 hpd_event_bits;
@@ -1161,7 +1159,7 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
mutex_lock(_config->mutex);
DRM_DEBUG_KMS("running encoder hotplug functions\n");

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);

hpd_event_bits = dev_priv->hpd_event_bits;
dev_priv->hpd_event_bits = 0;
@@ -1195,7 +1193,7 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
 msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}

-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

list_for_each_entry(connector, _config->connector_list, head) {
intel_connector = to_intel_connector(connector);
@@ -1490,7 +1488,6 @@ static void ivybridge_parity_work(struct work_struct 
*work)
u32 error_status, row, bank, subbank;
char *parity_event[6];
uint32_t misccpctl;
-   unsigned long flags;
uint8_t slice = 0;

/* We must turn off DOP level clock gating to access the L3 registers.
@@ -1549,9 +1546,9 @@ static void ivybridge_parity_work(struct work_struct 
*work)

 out:
WARN_ON(dev_priv->l3_parity.which_slice);
-   spin_lock_irqsave(_priv->irq_lock, flags);
+   spin_lock_irq(_priv->irq_lock);
gen5_enable_gt_irq(dev_priv, GT_PARITY_ERROR(dev_priv->dev));
-   spin_unlock_irqrestore(_priv->irq_lock, flags);
+   spin_unlock_irq(_priv->irq_lock);

mutex_unlock(_priv->dev->struct_mutex);
 }
@@ -4606,19 +4603,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
 }

-static void intel_hpd_irq_reenable(struct work_struct *work)
+static void intel_hpd_irq_reenable_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv),
 hotplug_reenable_work.work);
struct drm_device *dev = dev_priv->dev;
struct drm_mode_config *mode_config = >mode_config;
-   unsigned long irqflags;
int i;

intel_runtime_pm_get(dev_priv);

-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
for (i = (HPD_NONE + 1); i < HPD_NUM_PINS; i++) {
struct drm_connector *connector;

@@ -4642,7 +4638,7 @@ static void intel_hpd_irq_reenable(struct work_struct 
*work)
}
if (dev_priv->display.hpd_irq_setup)
dev_priv->display.hpd_irq_setup(dev);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);

intel_runtime_pm_put(dev_priv);
 }
@@ -4668,7 +4664,7 @@ void intel_irq_init(struct drm_device *dev)

[PATCH 04/11] drm/i915: Clarify irq_lock locking, intel_tv_detect

[Daniel Vetter]

->detect callbacks are only ever called from process context, and
there's no fancy nesting going on here. So plain _irq spinlock
variants is what we want.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_tv.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index c14341ca3ef9..6f5f59b880f5 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1182,18 +1182,17 @@ intel_tv_detect_type(struct intel_tv *intel_tv,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long irqflags;
u32 tv_ctl, save_tv_ctl;
u32 tv_dac, save_tv_dac;
int type;

/* Disable TV interrupts around load detect or we'll recurse */
if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
i915_disable_pipestat(dev_priv, 0,
  PIPE_HOTPLUG_INTERRUPT_STATUS |
  PIPE_HOTPLUG_TV_INTERRUPT_STATUS);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
}

save_tv_dac = tv_dac = I915_READ(TV_DAC);
@@ -1266,11 +1265,11 @@ intel_tv_detect_type(struct intel_tv *intel_tv,

/* Restore interrupt config */
if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
-   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   spin_lock_irq(_priv->irq_lock);
i915_enable_pipestat(dev_priv, 0,
 PIPE_HOTPLUG_INTERRUPT_STATUS |
 PIPE_HOTPLUG_TV_INTERRUPT_STATUS);
-   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
+   spin_unlock_irq(_priv->irq_lock);
}

return type;
-- 
1.9.3

[PATCH 03/11] drm/i915: Clarify gpu_error.lock locking

[Daniel Vetter]

i915_capture_error_state can be called from all kinds of contexts, so
needs the full irqsave dance. But the other two places to grab and
release the error state are only called from process context. So
simplify them to the plaine _irq spinlock versions to clarify the
locking semantics.

Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2c87a797213f..386e45dbeff1 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1326,13 +1326,12 @@ void i915_error_state_get(struct drm_device *dev,
  struct i915_error_state_file_priv *error_priv)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long flags;

-   spin_lock_irqsave(_priv->gpu_error.lock, flags);
+   spin_lock_irq(_priv->gpu_error.lock);
error_priv->error = dev_priv->gpu_error.first_error;
if (error_priv->error)
kref_get(_priv->error->ref);
-   spin_unlock_irqrestore(_priv->gpu_error.lock, flags);
+   spin_unlock_irq(_priv->gpu_error.lock);

 }

@@ -1346,12 +1345,11 @@ void i915_destroy_error_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_error_state *error;
-   unsigned long flags;

-   spin_lock_irqsave(_priv->gpu_error.lock, flags);
+   spin_lock_irq(_priv->gpu_error.lock);
error = dev_priv->gpu_error.first_error;
dev_priv->gpu_error.first_error = NULL;
-   spin_unlock_irqrestore(_priv->gpu_error.lock, flags);
+   spin_unlock_irq(_priv->gpu_error.lock);

if (error)
kref_put(>ref, i915_error_state_free);
-- 
1.9.3

[PATCH 02/11] drm/i915: Clarify event_lock locking, irq context

[Daniel Vetter]

Now we tackle the functions also called from interrupt handlers.

- intel_check_page_flip is exclusively called from irq handlers, so a
  plain spin_lock is all we need. In i915_irq.c we have the convention
  to give all such functions an _irq_handler postfix, but that would
  look strange and als be a bit a misleading name. I've opted for a
  WARN_ON(!in_irq()) instead.

- The other two places left are called both from interrupt handlers
  and from our reset work, so need the full irqsave dance. Annotate
  them with a short comment.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dcbefe510a2a..d120dfff3841 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9385,6 +9385,10 @@ static void do_intel_finish_page_flip(struct drm_device 
*dev,
if (intel_crtc == NULL)
return;

+   /*
+* This is called both by irq handlers and the reset code (to complete
+* lost pageflips) so needs the full irqsave spinlocks.
+*/
spin_lock_irqsave(>event_lock, flags);
work = intel_crtc->unpin_work;

@@ -9466,7 +9470,12 @@ void intel_prepare_page_flip(struct drm_device *dev, int 
plane)
to_intel_crtc(dev_priv->plane_to_crtc_mapping[plane]);
unsigned long flags;

-   /* NB: An MMIO update of the plane base pointer will also
+
+   /*
+* This is called both by irq handlers and the reset code (to complete
+* lost pageflips) so needs the full irqsave spinlocks.
+*
+* NB: An MMIO update of the plane base pointer will also
 * generate a page-flip completion irq, i.e. every modeset
 * is also accompanied by a spurious intel_prepare_page_flip().
 */
@@ -9923,18 +9932,19 @@ void intel_check_page_flip(struct drm_device *dev, int 
pipe)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   unsigned long flags;
+
+   WARN_ON(!in_irq());

if (crtc == NULL)
return;

-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock(>event_lock);
if (intel_crtc->unpin_work && __intel_pageflip_stall_check(dev, crtc)) {
WARN_ONCE(1, "Kicking stuck page flip: queued at %d, now %d\n",
 intel_crtc->unpin_work->flip_queued_vblank, 
drm_vblank_count(dev, pipe));
page_flip_completed(intel_crtc);
}
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock(>event_lock);
 }

 static int intel_crtc_page_flip(struct drm_crtc *crtc,
-- 
1.9.3

[PATCH 01/11] drm/i915: Clarify event_lock locking, process context

[Daniel Vetter]

It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.

This is the first step whice replaces all occurances of _irqsave in
process context with the simpler irq disable/enable variants. We don't
have any funky spinlock nesting going on, especially since the
event_lock is the outermost of the irq/vblank related spinlocks.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++---
 drivers/gpu/drm/i915/intel_display.c | 35 +++
 2 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 063b44817e08..0ba5c7145240 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -516,7 +516,6 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long flags;
struct intel_crtc *crtc;
int ret;

@@ -529,7 +528,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
const char plane = plane_name(crtc->plane);
struct intel_unpin_work *work;

-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
work = crtc->unpin_work;
if (work == NULL) {
seq_printf(m, "No flip due on pipe %c (plane %c)\n",
@@ -575,7 +574,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
seq_printf(m, "MMIO update completed? %d\n",  
addr == work->gtt_offset);
}
}
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);
}

mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 82c0ad1f6a2e..dcbefe510a2a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2765,16 +2765,15 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc 
*crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   unsigned long flags;
bool pending;

if (i915_reset_in_progress(_priv->gpu_error) ||
intel_crtc->reset_counter != 
atomic_read(_priv->gpu_error.reset_counter))
return false;

-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
pending = to_intel_crtc(crtc)->unpin_work != NULL;
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);

return pending;
 }
@@ -3485,14 +3484,13 @@ void intel_crtc_wait_for_pending_flips(struct drm_crtc 
*crtc)
   !intel_crtc_has_pending_flip(crtc),
   60*HZ) == 0)) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   unsigned long flags;

-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
if (intel_crtc->unpin_work) {
WARN_ONCE(1, "Removing stuck page flip\n");
page_flip_completed(intel_crtc);
}
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);
}

if (crtc->primary->fb) {
@@ -9337,12 +9335,11 @@ static void intel_crtc_destroy(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct intel_unpin_work *work;
-   unsigned long flags;

-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
work = intel_crtc->unpin_work;
intel_crtc->unpin_work = NULL;
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);

if (work) {
cancel_work_sync(>work);
@@ -9953,7 +9950,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
enum pipe pipe = intel_crtc->pipe;
struct intel_unpin_work *work;
struct intel_engine_cs *ring;
-   unsigned long flags;
int ret;

//trigger software GT busyness calculation
@@ -9997,7 +9993,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
goto free_work;

/* We borrow the event spin lock for protecting unpin_work */
-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
  

[PATCH 00/11] Spinlock use clarification in i915

[Daniel Vetter]

Hi all,

So I've tried to figure out a way how to clear up our irq setup mess, but
instead only managed to get sidetracked on a spinlock usage review.

Review highly welcome.

Cheers, Daniel

Daniel Vetter (11):
  drm/i915: Clarify event_lock locking, process context
  drm/i915: Clarify event_lock locking, irq context
  drm/i915: Clarify gpu_error.lock locking
  drm/i915: Clarify irq_lock locking, intel_tv_detect
  drm/i915: Clarify irq_lock locking, work functions
  drm/i915: Clarify irq_lock locking, interrupt install/uninstall
  drm/i915: Clarify irq_lock locking, irq handlers
  drm/i915: Clarify irq_lock locking, special cases
  drm/i915: Convert backlight_lock to a mutex
  drm/i915: Clarify uncore.lock locking
  drm/i915: Clarify mmio_flip_lock locking

 drivers/gpu/drm/i915/i915_debugfs.c   |   5 +-
 drivers/gpu/drm/i915/i915_dma.c   |   2 +-
 drivers/gpu/drm/i915/i915_drv.c   |   5 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  10 ++--
 drivers/gpu/drm/i915/i915_irq.c   | 101 ++
 drivers/gpu/drm/i915/intel_display.c  |  67 +++---
 drivers/gpu/drm/i915/intel_panel.c|  30 --
 drivers/gpu/drm/i915/intel_tv.c   |   9 ++-
 9 files changed, 103 insertions(+), 128 deletions(-)

-- 
1.9.3

[GIT PULL FOR v3.18] DRM core change

[Laurent Pinchart]

Hi Daniel,

On Monday 15 September 2014 11:44:23 Daniel Vetter wrote:
> On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> > Hi Dave,
> > 
> > The following changes since commit 
98faa78ce7f1f986e11e7805d31b409782a6d2d4:
> >   Merge tag 'topic/drm-header-rework-2014-09-12' of
> > 
> > git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49
> > +1000)
> > 
> > are available in the git repository at:
> >   git://linuxtv.org/pinchartl/fbdev.git drm/next/core
> > 
> > for you to fetch changes up to 41e58cca2f8d99fe3d5cf60ad1a59cf94b00cf7a:
> >   drm/gem: Fix kerneldoc typo (2014-09-15 12:30:21 +0300)
> 
> I already have this one in my topic/core-stuff branch.

Thank you.

If you find yourself bored sometime, a git hook that would send an e-mail 
notification when you add a patch to a branch you will push to mainline would 
be appreciated :-)

> > 
> > 
> > Laurent Pinchart (1):
> >   drm/gem: Fix kerneldoc typo
> >  
> >  drivers/gpu/drm/drm_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

[GIT PULL FOR v3.18] DRM core change

[Daniel Vetter]

On Mon, Sep 15, 2014 at 02:29:52PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Monday 15 September 2014 11:44:23 Daniel Vetter wrote:
> > On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> > > Hi Dave,
> > > 
> > > The following changes since commit 
> 98faa78ce7f1f986e11e7805d31b409782a6d2d4:
> > >   Merge tag 'topic/drm-header-rework-2014-09-12' of
> > > 
> > > git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49
> > > +1000)
> > > 
> > > are available in the git repository at:
> > >   git://linuxtv.org/pinchartl/fbdev.git drm/next/core
> > > 
> > > for you to fetch changes up to 41e58cca2f8d99fe3d5cf60ad1a59cf94b00cf7a:
> > >   drm/gem: Fix kerneldoc typo (2014-09-15 12:30:21 +0300)
> > 
> > I already have this one in my topic/core-stuff branch.
> 
> Thank you.
> 
> If you find yourself bored sometime, a git hook that would send an e-mail 
> notification when you add a patch to a branch you will push to mainline would 
> be appreciated :-)

Well, I'm striking a fine balance here. On one side I want to help out
Dave with drm stuff to make sure he sticks around, otoh I want to suck
enough at it that Dave never gets the idea to sign me up officially ;-)
Since drm-intel is bad enough that I don't want to deal with drm itself at
all ...

Sometimes I do send out confirmation mails, but not always.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Shareable bufmgr objects v4

[Chris Wilson]

On Fri, Sep 12, 2014 at 01:48:34PM +0100, Lionel Landwerlin wrote:
> This is getting bigger than expected. Adding the locking that Chris
> suggested on IRC.
> 
> Thanks for taking time to review Chris.

I'm happy with this series,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

PATCH: radeondrm x86_64 and android32

[Sergey Korshunoff]

Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
trying to use a radeon kms. The following change correct a problem:

drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):

- value_ptr = (uint32_t *)((unsigned long)info->value);
+ value_ptr = (uint32_t *)((unsigned)info->value);

Looks like a userspace data in android running under x86_64 is located
above 4 Gb. I don't think so. But after this change android run fine.

[PATCH] drm: Improve debug output for drm_wait_one_vblank

[Daniel Vetter]

This replicates what we've done in i915 in

commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
Author: Damien Lespiau 
Date:   Mon Aug 18 13:51:00 2014 +0100

drm/i915: Print the pipe on which the vblank wait times out

to make sure that when we switch i915 to drm_wait_one_vblank that the
debug output doesn't regress.

Cc: Damien Lespiau 
Cc: Thomas Wood 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index e73cbdaa18df..5ef03c216a27 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1077,7 +1077,7 @@ void drm_wait_one_vblank(struct drm_device *dev, int crtc)
u32 last;

ret = drm_vblank_get(dev, crtc);
-   if (WARN_ON(ret))
+   if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", crtc, ret))
return;

last = drm_vblank_count(dev, crtc);
@@ -1086,7 +1086,7 @@ void drm_wait_one_vblank(struct drm_device *dev, int crtc)
 last != drm_vblank_count(dev, crtc),
 msecs_to_jiffies(100));

-   WARN_ON(ret == 0);
+   WARN(ret == 0, "vblank wait timed out on crtc %i\n", crtc);

drm_vblank_put(dev, crtc);
 }
-- 
2.0.1

[PATCH] drm: Improve debug output for drm_wait_one_vblank

[Damien Lespiau]

On Mon, Sep 15, 2014 at 02:05:56PM +0200, Daniel Vetter wrote:
> This replicates what we've done in i915 in
> 
> commit 31e4b89acbd7b19c9a8557e6e660a583a0b97daa
> Author: Damien Lespiau 
> Date:   Mon Aug 18 13:51:00 2014 +0100
> 
> drm/i915: Print the pipe on which the vblank wait times out
> 
> to make sure that when we switch i915 to drm_wait_one_vblank that the
> debug output doesn't regress.
> 
> Cc: Damien Lespiau 
> Cc: Thomas Wood 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/drm_irq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index e73cbdaa18df..5ef03c216a27 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1077,7 +1077,7 @@ void drm_wait_one_vblank(struct drm_device *dev, int 
> crtc)
>   u32 last;
>  
>   ret = drm_vblank_get(dev, crtc);
> - if (WARN_ON(ret))
> + if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", crtc, ret))
>   return;
>  
>   last = drm_vblank_count(dev, crtc);
> @@ -1086,7 +1086,7 @@ void drm_wait_one_vblank(struct drm_device *dev, int 
> crtc)
>last != drm_vblank_count(dev, crtc),
>msecs_to_jiffies(100));
>  
> - WARN_ON(ret == 0);
> + WARN(ret == 0, "vblank wait timed out on crtc %i\n", crtc);
>  
>   drm_vblank_put(dev, crtc);
>  }
> -- 
> 2.0.1
> 

PATCH: radeondrm x86_64 and android32

[Christian König]

Am 15.09.2014 um 12:09 schrieb Sergey Korshunoff:
> Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
> trying to use a radeon kms. The following change correct a problem:
>
> drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):
>
> - value_ptr = (uint32_t *)((unsigned long)info->value);
> + value_ptr = (uint32_t *)((unsigned)info->value);
>
> Looks like a userspace data in android running under x86_64 is located
> above 4 Gb. I don't think so. But after this change android run fine.

That's most likely a bug on the userspace side, caused by the upper 
32bits of info->value not initialized properly.

The kernel patch you show above will most likely just break 64bit userspace.

Regards,
Christian.

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

[PATCH] drm: Fixup locking for universal cursor planes

[Daniel Vetter]

Bunch of things amiss:
- Updating crtc->cursor_x/y was done without any locking. Spotted by
  David Herrmann.
- Dereferencing crtc->cursor->fb was using the wrong lock, should take
  the crtc lock.
- Grabbing _all_ modeset locks torpedoes the reason why we added
  fine-grained locks originally: Cursor updates shouldn't stall on
  background stuff like probing outputs.

Best is to just grab the crtc lock around everything and drop all the
other locking. The only issue is that we can't switch planes between
crtcs with that, so make sure that never happens when someone uses
universal plane helpers. This shouldn't be a possible regression ever
since legacy ioctls also only grabbed the crtc lock, so switching
crtcs was never possible for the underlying plane object. And i915
(the only user of universal cursors thus far) has fixed cursor->crtc
links.

Cc: David Herrmann 
Cc: Pallavi G
Cc: Matt Roper 
Reviewed-by: Matt Roper 
Tested-by: Matt Roper 
Reviewed-by: David Herrmann 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 51 ++
 1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2ec08e9269bd..4b8a262a8eb2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2262,21 +2262,19 @@ out:
  *
  * src_{x,y,w,h} are provided in 16.16 fixed point format
  */
-static int setplane_internal(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int32_t crtc_x, int32_t crtc_y,
-uint32_t crtc_w, uint32_t crtc_h,
-/* src_{x,y,w,h} values are 16.16 fixed point */
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h)
+static int __setplane_internal(struct drm_plane *plane,
+  struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  int32_t crtc_x, int32_t crtc_y,
+  uint32_t crtc_w, uint32_t crtc_h,
+  /* src_{x,y,w,h} values are 16.16 fixed point */
+  uint32_t src_x, uint32_t src_y,
+  uint32_t src_w, uint32_t src_h)
 {
-   struct drm_device *dev = plane->dev;
int ret = 0;
unsigned int fb_width, fb_height;
int i;

-   drm_modeset_lock_all(dev);
/* No fb means shut it down */
if (!fb) {
plane->old_fb = plane->fb;
@@ -2344,10 +2342,28 @@ out:
if (plane->old_fb)
drm_framebuffer_unreference(plane->old_fb);
plane->old_fb = NULL;
-   drm_modeset_unlock_all(dev);

return ret;
+}

+static int setplane_internal(struct drm_plane *plane,
+struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int32_t crtc_x, int32_t crtc_y,
+uint32_t crtc_w, uint32_t crtc_h,
+/* src_{x,y,w,h} values are 16.16 fixed point */
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+   int ret;
+
+   drm_modeset_lock_all(plane->dev);
+   ret = __setplane_internal(plane, crtc, fb,
+ crtc_x, crtc_y, crtc_w, crtc_h,
+ src_x, src_y, src_w, src_h);
+   drm_modeset_unlock_all(plane->dev);
+
+   return ret;
 }

 /**
@@ -2713,6 +2729,7 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
int ret = 0;

BUG_ON(!crtc->cursor);
+   WARN_ON(crtc->cursor->crtc != crtc && crtc->cursor->crtc != NULL);

/*
 * Obtain fb we'll be using (either new or existing) and take an extra
@@ -2732,11 +2749,9 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
fb = NULL;
}
} else {
-   mutex_lock(>mode_config.mutex);
fb = crtc->cursor->fb;
if (fb)
drm_framebuffer_reference(fb);
-   mutex_unlock(>mode_config.mutex);
}

if (req->flags & DRM_MODE_CURSOR_MOVE) {
@@ -2758,7 +2773,7 @@ static int drm_mode_cursor_universal(struct drm_crtc 
*crtc,
 * setplane_internal will take care of deref'ing either the old or new
 * framebuffer depending on success.
 */
-   ret = setplane_internal(crtc->cursor, crtc, fb,
+   ret = __setplane_internal(crtc->cursor, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
0, 0, src_w, src_h);

@@ -2794,10 +2809,12 @@ static int drm_mode_cursor_common(struct drm_device 
*dev,
 * If this crtc has a universal 

[PATCH] drm/exynos: fix plane-framebuffer linkage

[Daniel Drake]

Pageflipping currently causes some inconsistencies that lead to
crashes. Just run an app that causes a CRTC pageflip in a raw X session
and check that it exits cleanly and can be restarted - you'll see
crashes like:
 Unable to handle kernel NULL pointer dereference at virtual address 0334
 PC is at exynos_drm_crtc_plane_commit+0x20/0x40
 LR is at exynos_drm_crtc_plane_commit+0x20/0x40
 [] (exynos_drm_crtc_plane_commit) from [] 
(exynos_drm_crtc_commit+0x44/0x70)
 [] (exynos_drm_crtc_commit) from [] 
(exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
 [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] 
(exynos_drm_crtc_page_flip+0x140/0x1a8)
 [] (exynos_drm_crtc_page_flip) from [] 
(drm_mode_page_flip_ioctl+0x224/0x2dc)
 [] (drm_mode_page_flip_ioctl) from [] 
(drm_ioctl+0x338/0x4fc)

These crashes happen because drm_plane_force_disable has previously set
plane->crtc to NULL.

When drm_mode_page_flip_ioctl() is used to flip another framebuffer
onto the primary plane, crtc->primary->fb is correctly updated (this is
a virtual plane created by plane_helper), but plane->fb is not (this
plane is the real one, created by exynos_drm_crtc_create).

We then come to handle rmfb of the backbuffer, which the "real" primary
plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
the buffer is actually active on a plane and force-disables the plane.

Ensuring that plane->fb is kept up-to-date solves that issue, but
exposes a reference counting problem. Now we see crashes when rmfb is
called on the front-buffer, because the rmfb code expects to drop 3
references here, and there are only 2.

That can be fixed by adopting the reference management found in omapdrm:
Framebuffer references are not taken directly in crtc mode_set context,
but rather in the context of updating the plane, which also covers
flips. Like omapdrm we also unreference the old framebuffer here.

Signed-off-by: Daniel Drake 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 12 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index b68e58f..7aa9dee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
if (manager->ops->mode_set)
manager->ops->mode_set(manager, >mode);

-   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
crtc_w, crtc_h,
-   x, y, crtc_w, crtc_h);
-   if (ret)
-   return ret;
-
-   plane->crtc = crtc;
-   plane->fb = crtc->primary->fb;
-   drm_framebuffer_reference(plane->fb);
-
-   return 0;
+   return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
+crtc_w, crtc_h, x, y, crtc_w, crtc_h);
 }

 static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int y,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 8371cbd..df27e35 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,6 +139,14 @@ int exynos_plane_mode_set(struct drm_plane *plane, struct 
drm_crtc *crtc,
overlay->crtc_x, overlay->crtc_y,
overlay->crtc_width, overlay->crtc_height);

+   if (plane->fb)
+   drm_framebuffer_unreference(plane->fb);
+
+   drm_framebuffer_reference(fb);
+
+   plane->fb = fb;
+   plane->crtc = crtc;
+
exynos_drm_crtc_plane_mode_set(crtc, overlay);

return 0;
-- 
1.9.1

[Intel-gfx] [PATCH] drm/i915: Fix Sink CRC

[Jani Nikula]

On Sat, 13 Sep 2014, Rodrigo Vivi  wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits on kernel + 2 vblank waits on test case.
>
> So let's give up to 6 vblank wait time. However we now check for
> TEST_CRC_COUNT that shows when panel finished to calculate CRC and
> has it ready.
>
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 20 ++--
>  include/drm/drm_dp_helper.h |  5 +++--
>  2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f79473b..eda6467 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3468,21 +3468,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct intel_crtc *intel_crtc =
>   to_intel_crtc(intel_dig_port->base.base.crtc);
> - u8 buf[1];
> + u8 buf;
> + int test_crc_count;
> + int attempts = 6;
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, buf) < 0)
> + if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, ) < 0)
>   return -EAGAIN;
>  
> - if (!(buf[0] & DP_TEST_CRC_SUPPORTED))
> + if (!(buf & DP_TEST_CRC_SUPPORTED))
>   return -ENOTTY;
>  
> + test_crc_count = buf & DP_TEST_COUNT_MASK;
> +
>   if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_SINK,
>  DP_TEST_SINK_START) < 0)
>   return -EAGAIN;
>  
> - /* Wait 2 vblanks to be sure we will have the correct CRC value */
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> + do {
> + drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, );
> + intel_wait_for_vblank(dev, intel_crtc->pipe);
> + } while(attempts-- && (buf & DP_TEST_COUNT_MASK) <= test_crc_count);
> +
> + if (attempts == 0)
> + return -EAGAIN;

If the do-while stops because of attempts, we'll never end up here
because of the post-decrement. (We'll only return -EAGAIN here if the
other condition does not hold at precisely attempts == 1 before the
post-decrement.)

BR,
Jani.


>  
>   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
>   return -EAGAIN;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 9305c71..8edeed0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -303,7 +303,8 @@
>  #define DP_TEST_CRC_B_CB 0x244
>  
>  #define DP_TEST_SINK_MISC0x246
> -#define DP_TEST_CRC_SUPPORTED(1 << 5)
> +# define DP_TEST_CRC_SUPPORTED   (1 << 5)
> +# define DP_TEST_COUNT_MASK  0x7
>  
>  #define DP_TEST_RESPONSE 0x260
>  # define DP_TEST_ACK (1 << 0)
> @@ -313,7 +314,7 @@
>  #define DP_TEST_EDID_CHECKSUM0x261
>  
>  #define DP_TEST_SINK 0x270
> -#define DP_TEST_SINK_START   (1 << 0)
> +# define DP_TEST_SINK_START  (1 << 0)
>  
>  #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
>  # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
> -- 
> 1.9.3
>
> ___
> 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

[GIT PULL FOR v3.18] DRM core change

[Laurent Pinchart]

Hi Dave,

The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:

  Merge tag 'topic/drm-header-rework-2014-09-12' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 
+1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git drm/next/core

for you to fetch changes up to 41e58cca2f8d99fe3d5cf60ad1a59cf94b00cf7a:

  drm/gem: Fix kerneldoc typo (2014-09-15 12:30:21 +0300)


Laurent Pinchart (1):
  drm/gem: Fix kerneldoc typo

 drivers/gpu/drm/drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

[GIT PULL FOR v3.18] Renesas DRM changes

[Laurent Pinchart]

Hi Dave,

Could you please pull the following changes for v3.18 ?

Commit "drm/rcar-du: Use struct videomode in platform data" touches board code 
in arch/arm/mach-shmobile. There is, to the best of my knowledge, no risk of 
conflict for v3.18. Simon, are you fine with getting those changes merged 
through Dave's tree (and could you confirm that no conflict should occur) ?

The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:

  Merge tag 'topic/drm-header-rework-2014-09-12' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 
+1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git drm/next/du

for you to fetch changes up to 96c026911890ceacee238da00a0b140ad634cc43:

  drm/rcar-du: Add OF support (2014-09-15 11:55:47 +0300)


Laurent Pinchart (10):
  drm/rcar-du: Update copyright notice
  drm/shmob: Update copyright notice
  devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt
  devicetree: Add vendor prefix "thine" to vendor-prefixes.txt
  video: Add DT binding documentation for VGA connector
  video: Add ADV7123 DT bindings documentation
  video: Add THC63LVDM83D DT bindings documentation
  video: Add DT bindings for the R-Car Display Unit
  drm/rcar-du: Use struct videomode in platform data
  drm/rcar-du: Add OF support

 Documentation/devicetree/bindings/vendor-prefixes.txt   |   2 +
 Documentation/devicetree/bindings/video/adi,adv7123.txt |  50 +
 Documentation/devicetree/bindings/video/renesas,du.txt  |  84 +
 .../devicetree/bindings/video/thine,thc63lvdm83d|  50 +
 .../devicetree/bindings/video/vga-connector.txt |  36 
 arch/arm/mach-shmobile/board-koelsch-reference.c|  19 +-
 arch/arm/mach-shmobile/board-koelsch.c  |  19 +-
 arch/arm/mach-shmobile/board-lager-reference.c  |  19 +-
 arch/arm/mach-shmobile/board-lager.c|  19 +-
 arch/arm/mach-shmobile/board-marzen.c   |  19 +-
 drivers/gpu/drm/rcar-du/Kconfig |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 172 ---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c   |  13 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h   |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.c |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_group.h |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 233 +--
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  45 +++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h   |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c   |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h   |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_backlight.c  |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_backlight.h  |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c   |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.h   |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.c|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_drv.h|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_kms.c|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_kms.h|   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.c  |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_plane.h  |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_regs.h   |   2 +-
 include/linux/platform_data/rcar-du.h   |   4 +-
 41 files changed, 645 insertions(+), 198 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/adi,adv7123.txt
 create mode 100644 Documentation/devicetree/bindings/video/renesas,du.txt
 create mode 100644 Documentation/devicetree/bindings/video/thine,thc63lvdm83d
 create mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt

-- 
Regards,

Laurent Pinchart

[PATCH 03/16] video: Add DT binding documentation for VGA connector

[Tomi Valkeinen]

Hi,

On 27/08/14 19:41, Laurent Pinchart wrote:
> The VGA connector is described by a single input port and an optional
> DDC bus.
> 
> Cc: devicetree at vger.kernel.org
> Cc: linux-fbdev at vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---
>  .../devicetree/bindings/video/vga-connector.txt| 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/vga-connector.txt 
> b/Documentation/devicetree/bindings/video/vga-connector.txt
> new file mode 100644
> index 000..9a45ec1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/vga-connector.txt
> @@ -0,0 +1,28 @@
> +VGA Connector
> +==
> +
> +Required properties:
> +- compatible: "vga-connector"
> +
> +Optional properties:
> +- label: a symbolic name for the connector
> +- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC
> +
> +Required nodes:
> +- Video port for VGA input
> +
> +Example
> +---
> +
> +vga0: connector at 0 {
> + compatible = "vga-connector";
> + label = "vga";
> +
> + ddc-i2c-bus = <>;
> +
> + port {
> + vga_connector_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +};
> 

Looks good to me.

 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/20140915/2aca4f4a/attachment.sig>

[GIT PULL FOR v3.18] DRM core change

[Daniel Vetter]

On Mon, Sep 15, 2014 at 12:31:54PM +0300, Laurent Pinchart wrote:
> Hi Dave,
> 
> The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:
> 
>   Merge tag 'topic/drm-header-rework-2014-09-12' of 
> git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 
> +1000)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/pinchartl/fbdev.git drm/next/core
> 
> for you to fetch changes up to 41e58cca2f8d99fe3d5cf60ad1a59cf94b00cf7a:
> 
>   drm/gem: Fix kerneldoc typo (2014-09-15 12:30:21 +0300)

I already have this one in my topic/core-stuff branch.
-Daniel

> 
> 
> Laurent Pinchart (1):
>   drm/gem: Fix kerneldoc typo
> 
>  drivers/gpu/drm/drm_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v3] drm/ast: Add reduced blanking modes for wide screen mode

[Steven You2 Liang]

The Patch is PASSED by Lenovo side. 
Tested-by: Steven You2 Liang 

-Original Message-
From: YC Chen [mailto:yc_c...@aspeedtech.com] 
Sent: Thursday, August 28, 2014 5:11 PM
To: dri-devel at lists.freedesktop.org
Cc: Kuo-Hsiang Chou; airlied at redhat.com; eich at suse.com; YC Chen
Subject: [PATCH v3] drm/ast: Add reduced blanking modes for wide screen mode

From: "Y.C. Chen" 

Signed-off-by: Egbert Eich 
Signed-off-by: Y.C. Chen 

v3: based on [PATCH 1/2] drm/ast: Add missing entry to dclk_table[].
Add reduced blanking modes, improve mode matching to
identify these modes by thier sync polarities.
---
 drivers/gpu/drm/ast/ast_mode.c   | 42 +++-
 drivers/gpu/drm/ast/ast_tables.h | 42 
 2 files changed, 58 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c 
index 5389350..19ada0b 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -80,6 +80,8 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, 
struct drm_display_mo
struct ast_private *ast = crtc->dev->dev_private;
u32 refresh_rate_index = 0, mode_id, color_index, refresh_rate;
u32 hborder, vborder;
+   bool check_sync;
+   struct ast_vbios_enhtable *best = NULL;

switch (crtc->primary->fb->bits_per_pixel) {
case 8:
@@ -141,14 +143,34 @@ static bool ast_get_vbios_mode_info(struct drm_crtc 
*crtc, struct drm_display_mo
}

refresh_rate = drm_mode_vrefresh(mode);
-   while (vbios_mode->enh_table->refresh_rate < refresh_rate) {
-   vbios_mode->enh_table++;
-   if ((vbios_mode->enh_table->refresh_rate > refresh_rate) ||
-   (vbios_mode->enh_table->refresh_rate == 0xff)) {
-   vbios_mode->enh_table--;
-   break;
+   check_sync = vbios_mode->enh_table->flags & WideScreenMode;
+   do {
+   struct ast_vbios_enhtable *loop = vbios_mode->enh_table;
+
+   while (loop->refresh_rate != 0xff) {
+   if ((check_sync) &&
+   (((mode->flags & DRM_MODE_FLAG_NVSYNC)  &&
+ (loop->flags & PVSync))  ||
+((mode->flags & DRM_MODE_FLAG_PVSYNC)  &&
+ (loop->flags & NVSync))  ||
+((mode->flags & DRM_MODE_FLAG_NHSYNC)  &&
+ (loop->flags & PHSync))  ||
+((mode->flags & DRM_MODE_FLAG_PHSYNC)  &&
+ (loop->flags & NHSync {
+   loop++;
+   continue;
+   }
+   if (loop->refresh_rate <= refresh_rate
+   && (!best || loop->refresh_rate > 
best->refresh_rate))
+   best = loop;
+   loop++;
}
-   }
+   if (best || !check_sync)
+   break;
+   check_sync = 0;
+   } while (1);
+   if (best)
+   vbios_mode->enh_table = best;

hborder = (vbios_mode->enh_table->flags & HBorder) ? 8 : 0;
vborder = (vbios_mode->enh_table->flags & VBorder) ? 8 : 0; @@ -419,8 
+441,10 @@ static void ast_set_sync_reg(struct drm_device *dev, struct 
drm_display_mode *mo
struct ast_private *ast = dev->dev_private;
u8 jreg;

-   jreg = ast_io_read8(ast, AST_IO_MISC_PORT_READ);
-   jreg |= (vbios_mode->enh_table->flags & SyncNN);
+   jreg  = ast_io_read8(ast, AST_IO_MISC_PORT_READ);
+   jreg &= ~0xC0;
+   if (vbios_mode->enh_table->flags & NVSync) jreg |= 0x80;
+   if (vbios_mode->enh_table->flags & NHSync) jreg |= 0x40;
ast_io_write8(ast, AST_IO_MISC_PORT_WRITE, jreg);  }

diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index 05c01ea..28ce659 100644
--- a/drivers/gpu/drm/ast/ast_tables.h
+++ b/drivers/gpu/drm/ast/ast_tables.h
@@ -35,14 +35,18 @@
 #define HalfDCLK0x0002
 #define DoubleScanMode  0x0004
 #define LineCompareOff  0x0008
-#define SyncPP  0x
-#define SyncPN  0x0040
-#define SyncNP  0x0080
-#define SyncNN  0x00C0
 #define HBorder 0x0020
 #define VBorder 0x0010
-#define WideScreenMode 0x0100
-#define NewModeInfo0x0200
+#define WideScreenMode 0x0100
+#define NewModeInfo0x0200
+#define NHSync 0x0400
+#define PHSync 0x0800
+#define NVSync 0x1000
+#define PVSync 0x2000

[PULL] topic/core-stuff

[Daniel Vetter]

Hi Dave,

Here's the updated topic/core-stuff pull request with the two patches
already merged into drm-fixes dropped.

Cheers, Daniel


The following changes since commit edbaae5a5cab89de0e64b8c03ebd9a8d5d266550:

  Merge tag 'topic/vblank-rework-2014-09-12' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-12 19:04:53 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-15

for you to fetch changes up to d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21:

  drm: Drop modeset locking from crtc init function (2014-09-15 08:56:30 +0200)


Chris Wilson (1):
  drm: Include task->name and master status in debugfs clients info

Clint Taylor (2):
  drm/edid: Reduce horizontal timings for pixel replicated modes
  drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes

Daniel Vetter (1):
  drm: Drop modeset locking from crtc init function

Julia Lawall (1):
  drm: use c99 initializers in structures

Laurent Pinchart (1):
  drm/gem: Fix kerneldoc typo

Randy Dunlap (1):
  drm: fix drm_modeset_lock.h kernel-doc notation

 drivers/gpu/drm/drm_crtc.c|   5 --
 drivers/gpu/drm/drm_edid.c| 117 +++---
 drivers/gpu/drm/drm_gem.c |   2 +-
 drivers/gpu/drm/drm_info.c|  27 +++--
 drivers/gpu/drm/i915/intel_hdmi.c |  15 -
 drivers/gpu/drm/sti/sti_vtac.c|  12 +++-
 include/drm/drm_modeset_lock.h|   4 +-
 7 files changed, 107 insertions(+), 75 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH] drm/i915: Fix Sink CRC

[Daniel Vetter]

On Fri, Sep 12, 2014 at 07:49:25PM -0400, Rodrigo Vivi wrote:
> In some cases like when PSR just got enabled the panel need more vblank
> times to calculate CRC. I figured that out with the new PSR test cases
> facing some cases that I had a green screen but a blank CRC. Even with
> 2 vblank waits on kernel + 2 vblank waits on test case.
> 
> So let's give up to 6 vblank wait time. However we now check for
> TEST_CRC_COUNT that shows when panel finished to calculate CRC and
> has it ready.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 20 ++--
>  include/drm/drm_dp_helper.h |  5 +++--
>  2 files changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f79473b..eda6467 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3468,21 +3468,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct intel_crtc *intel_crtc =
>   to_intel_crtc(intel_dig_port->base.base.crtc);
> - u8 buf[1];
> + u8 buf;
> + int test_crc_count;
> + int attempts = 6;
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, buf) < 0)
> + if (drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, ) < 0)
>   return -EAGAIN;
>  
> - if (!(buf[0] & DP_TEST_CRC_SUPPORTED))
> + if (!(buf & DP_TEST_CRC_SUPPORTED))
>   return -ENOTTY;
>  
> + test_crc_count = buf & DP_TEST_COUNT_MASK;
> +
>   if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_SINK,
>  DP_TEST_SINK_START) < 0)
>   return -EAGAIN;
>  
> - /* Wait 2 vblanks to be sure we will have the correct CRC value */
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> + do {
> + drm_dp_dpcd_readb(_dp->aux, DP_TEST_SINK_MISC, );
> + intel_wait_for_vblank(dev, intel_crtc->pipe);
> + } while(attempts-- && (buf & DP_TEST_COUNT_MASK) <= test_crc_count);

Shouldn't this here fest for (buf & MAS) != test_crc_count?
-Daniel

> +
> + if (attempts == 0)
> + return -EAGAIN;
>  
>   if (drm_dp_dpcd_read(_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
>   return -EAGAIN;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 9305c71..8edeed0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -303,7 +303,8 @@
>  #define DP_TEST_CRC_B_CB 0x244
>  
>  #define DP_TEST_SINK_MISC0x246
> -#define DP_TEST_CRC_SUPPORTED(1 << 5)
> +# define DP_TEST_CRC_SUPPORTED   (1 << 5)
> +# define DP_TEST_COUNT_MASK  0x7
>  
>  #define DP_TEST_RESPONSE 0x260
>  # define DP_TEST_ACK (1 << 0)
> @@ -313,7 +314,7 @@
>  #define DP_TEST_EDID_CHECKSUM0x261
>  
>  #define DP_TEST_SINK 0x270
> -#define DP_TEST_SINK_START   (1 << 0)
> +# define DP_TEST_SINK_START  (1 << 0)
>  
>  #define DP_PAYLOAD_TABLE_UPDATE_STATUS  0x2c0   /* 1.2 MST */
>  # define DP_PAYLOAD_TABLE_UPDATED   (1 << 0)
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

[Daniel Vetter]

On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
> The current drm-next misses Ville's original Patch 14/19, the one i first
> objected, then objected to my objection. It is needed to avoid actual
> regressions. Attached a trivially rebased (v2) of Ville's patch to go on top
> of drm-next, also as tgz in case my e-mail client mangles the patch again,
> because it's one of those "email hates me" weeks.

Oh dear, I've made a decent mess of all of this really. Picked up to make
sure it doesn't get lost again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Question on UAPI for fences

[Daniel Vetter]

On Sun, Sep 14, 2014 at 12:36:43PM +0200, Christian K?nig wrote:
> Yeah, right. Providing the fd to reassign to a fence would indeed reduce the
> create/close overhead.
> 
> But it would still be more overhead than for example a simple on demand
> growing ring buffer which then uses 64bit sequence numbers in userspace to
> refer to a fence in the kernel.
> 
> Apart from that I'm pretty sure that when we do the syncing completely in
> userspace we need more fences open at the same time than fds are available
> by default.

If you do the syncing completely in userspace you don't need kernel fences
at all. Kernel fences are only required if you sync with a different
process (where the pure userspace syncing might not work out) or with
different devices.

tbh I don't see any use-case at all where you'd need 10k such fences. That
means your driver gets to deal with 2 kinds of fences, but so be it. Since
not using fds for cross-device or cross-process syncing imo just doesn't
make sense, so that one pretty much will have to stick.

> As long as our internal handle or sequence based fence are easily
> convertible to a fence fd I actually don't really see a problem with that.
> Going to hack that approach into my prototype and then we can see how bad
> the code looks after all.

My plan for i915 is to start out with fd fences only, and once we have
some clarity on the exact requirements probably add some pure
userspace-controlled fences for tightly coupled stuff. Those might be
fully internal to the opencl userspace driver though and never get out of
there, ever.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83742] [radeonsi KMS] Monitors on DP outputs not enabled

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

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

--- Comment #7 from Ralf-Peter Rohbeck  ---
I can reproduce this at will now; let me know if I should run more tests.

-- 
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/20140915/f3fee2c0/attachment-0001.html>

[Bug 83742] [radeonsi KMS] Monitors on DP outputs not enabled

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

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

--- Comment #6 from Ralf-Peter Rohbeck  ---
Created attachment 106310
  --> https://bugs.freedesktop.org/attachment.cgi?id=106310=edit
kern.log without explicit mode settings on kernel line; monitors work

-- 
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/20140915/67ecc8af/attachment.html>

[Bug 83742] [radeonsi KMS] Monitors on DP outputs not enabled

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

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

--- Comment #5 from Ralf-Peter Rohbeck  ---
Created attachment 106309
  --> https://bugs.freedesktop.org/attachment.cgi?id=106309=edit
kern.log with explicit settings; monitors don't work

-- 
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/20140915/093aca8d/attachment.html>

[PATCH] nouveau: bump driver patchlevel to 1.2.1

[Maarten Lankhorst]

Allows userspace to detect shared fences are supported.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Dave, can you include this in drm-next? It should allow me to optimize 
nouveau's vdpau decoding a bit.

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h 
b/drivers/gpu/drm/nouveau/nouveau_drm.h
index b02b02452c85..8ae36f265fb8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
@@ -10,7 +10,7 @@

 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   2
-#define DRIVER_PATCHLEVEL  0
+#define DRIVER_PATCHLEVEL  1

 /*
  * 1.1.1:
@@ -26,6 +26,8 @@
  * 1.2.0:
  * - object api exposed to userspace
  * - fermi,kepler,maxwell zbc
+ * 1.2.1:
+ *  - allow concurrent access to bo's mapped read/write.
  */

 #include 
-- 
2.0.4

[Bug 83742] [radeonsi KMS] Monitors on DP outputs not enabled

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

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

--- Comment #4 from Ralf-Peter Rohbeck  ---
Resolution to the mystery: It seems that I had changed /etc/default/grub before
today's testing but not run update-grub. When I installed the 3.13-0.bpo.1
kernel the kernel command lines were fixed.

What caused the original failure were the explicit mode settings I had on the
kernel command line, namely "video=DP-1:2560x1440-24 at 60e
video=DP-2:2560x1440-24 at 60e video=DVI-0:2560x1440-24 at 60e". I had to add 
those
settings in the past (see https://bugs.freedesktop.org/show_bug.cgi?id=72167.)
Without them settings it works.

I'll attach some kern.logs - there all sorts of interesting things going on
that are apparently needed to get the DP outputs up and running with my DP->DVI
converters. Setting the resolutions explicitly keeps those interesting things
from happening.

-- 
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/20140915/2556e768/attachment.html>

[Bug 83810] Blender Weight paint mode doesn't work with enabled VBOs.

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

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

--- Comment #3 from sunweb at hotmail.ru ---
(In reply to comment #2)
> The weight paint not showing was fixed by
> https://bugs.freedesktop.org/show_bug.cgi?id=81967 which will be included in
> the 10.3 mesa release (isn't quite out the door yet though).
> 
> Three questions: is it a 512MB or 1GB 5770, and how much system RAM do you
> have? Do you get any messages in dmesg while running blender?

Well, fix is there and sooner or later i could use it, thank you!

5770 is 1Gb and i have 12Gb of RAM. I'll answer on dmesg question as soon as
i'm home.

-- 
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/20140915/017bd1ff/attachment.html>

[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support

[Ezequiel Garcia]

Dave,

On 03 Sep 08:08 AM, Johannes Pointner wrote:
> 2014-09-02 14:51 GMT+02:00 Ezequiel Garcia :
> > Dave,
> >
> > I'm resending this, hoping it can be pushed for v3.18. The patchset was
> > ready for v3.17, but it got no maintainer feedback or review. Maybe it fell
> > through some crack?
> >
> > Just for reference, here goes the details about this series and why it's
> > needed:
> >
> > This patchset adds the required changes to support an optional backlight
> > and GPIO for the tilcdc panel driver.
> >
> > There was some code to support a backlight, but it was broken and 
> > undocumented.
> > I've followed the nice implementation in panel-simple and added a similar
> > one here.
> >
> > The enable GPIO is required to turn on and off devices with such capability.
> > Also here, I've followed panel-simple which looks correct.
> >
> > In addition to this there are very minor cosmetic cleanups and a larger
> > fix for the error path in tilcdc's DRM driver .load error path.
> >
> 
> I tested the series with 3.16.1 (with additonal patches from Guido and
> Sachin) and with 3.17-rc3 with a custom AM335x board and it worked for
> me without an issue. I tried it with and without the backlight
> addition in the dts file.
> 
> For the series:
> Tested-by: Johannes Pointner 
> 

Any feedback for this series?

If at all possible, it'd be great to not miss the merge this time.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

[Bug 83742] [radeonsi KMS] Monitors on DP outputs not enabled

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

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

--- Comment #3 from Ralf-Peter Rohbeck  ---
Looking for older kernels I found 3.13-0.bpo.1-amd64 and voila, it fixed the
behavior.
Then I booted 3.14-2 and 3.16-1 and both worked again!
I compared the initramfs for 3.16-1 before and after and the only changes were
in etc/modprobe.d/radeon-kms.conf and etc/boottime.kmap.gz but copying those
changes by hand into the now-working initramfs did not duplicate the failure.

-- 
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/20140915/b56bcc06/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

--- Comment #32 from charlie <407883775 at qq.com> ---
>>radeon: The kernel rejected CS, see dmesg for more information
This error is showed in the drm_ioctl function.The part code show as follow:

468 if (cmd & IOC_OUT) { //error place,
469 printk(KERN_EMERG "cmd & IOC_OUT\n");
470 if (copy_to_user((void __user *)arg, kdata,
471  usize) != 0){
472 printk(KERN_EMERG "cmd & IOC_OUT error\n");
473 retcode = -EFAULT;
474 }
475 }

The copy_from_user havn't error, So the error is cause by parameter.
Or, PAGE_SIZE cause it ?

-- 
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/20140915/fde6d031/attachment.html>

[Bug 83835] Multi Stream Transport (MST) 1.2 Support

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

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

Alex Deucher  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Alex Deucher  ---
MST support is not implemented yet. Dave started hacking on it, but as far as I
know, it's not working yet:
http://cgit.freedesktop.org/~airlied/linux/log/?h=radeon-mst-hacks

-- 
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/20140915/79b31175/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #103 from Aaron B  ---
It seems the more often the build has this bug, the most it ALSO randomly has
"blank" and "garbled" frames. Every so often, the screen will shift, or
sometimes seem to just go completely blank. I notice in the builds where chrome
crashes a ton, this happens a ton. When it doesn't, it also doesn't crash as
often.

What are the chances our other hardware could help find this? I dunno what you
guys on the AMD dev side run, but I did get an FX-8350, and maybe this has
something to do with the vblank patches I saw you guys post, as I remember
seeing errors I saw with the vblank patches and talk. I don't know if they were
scrapped or what, but could this be tied to any external hardware or bus or
something just racing something else? Any way to test for the race conditions,
successfully? I mean, I'm back on this current build of mesa, and it's just a
mess.

-- 
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/20140915/11825963/attachment.html>

[PATCH 0/9 linux-next] drivers/gpu/drm: use container_of where possible

[One Thousand Gnomes]

On Sun, 14 Sep 2014 18:40:13 +0200
Fabian Frederick  wrote:

> Small patchset using container_of instead of casting on first structure 
> member address.

Why. Container_of is useful for random offsets but its just convoluting
and confusing code which is designed with the fields intentionally at the
start.

Alan