[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #4 from Mike Lothian --- It locks up the machine Output from journalctl -f will be attached which was captured by sshing from another machine It froze up the laptop completely and the connection died -- 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/20131126/6308f04b/attachment-0001.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #5 from Mike Lothian --- Created attachment 89797 --> https://bugs.freedesktop.org/attachment.cgi?id=89797&action=edit Dmesg of switcheroo -- 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/20131126/261ebcf2/attachment.html>
[Bug 41375] VDPAU not working on RS880
https://bugs.freedesktop.org/show_bug.cgi?id=41375 Mike Lothian changed: What|Removed |Added CC||mike at fireburn.co.uk --- Comment #9 from Mike Lothian --- It is indeed working - it's just a lot slower than xv Fingers crossed that UVD support is added for the RS880 one day -- 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/20131126/9c8618a9/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #6 from Mike Lothian --- X is now starting with runpm=1 but I get a kworker eating lots of cpu and a slight freeze / stutter every few seconds Looks like the card is initialised every few seconds in the 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/20131126/e1439ff5/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #7 from Mike Lothian --- Created attachment 89800 --> https://bugs.freedesktop.org/attachment.cgi?id=89800&action=edit Dmesg dynpm=1 -- 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/20131126/aa3e3e18/attachment.html>
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
Hi Shirish,
2013/11/25 Shirish S :
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt | 31
> drivers/gpu/drm/exynos/exynos_hdmi.c | 77
> +++-
> 2 files changed, 104 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 323983b..6eeb333 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -13,6 +13,30 @@ Required properties:
> b) pin number within the gpio controller.
> c) optional flags and pull up/down.
>
> +- hdmiphy-configs: following information about the hdmiphy config settings.
> + a) "config: config" specifies the phy configuration settings,
> + where 'N' denotes the number of configuration, since every
> + pixel clock can have its unique configuration.
> + "pixel-clock" specifies the pixel clock
> + "conifig-de-emphasis-level" provides fine control of TMDS data
> +pre emphasis, below shown is example for
> + data de-emphasis register at address 0x145D0040.
> + hdmiphy at 38[16] for bits[3:0] permitted values are
> in
> + the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
> + increments for every LSB
> + hdmiphy at 38[16] for bits[7:4] permitted values are
> in
> + the range of 0dB to -7.45dB at increments of -0.45dB
> + for every LSB.
> + "config-clock-level" provides fine control of TMDS data
> + amplitude for each channel,
> + for example if 0x145D005C is the address of clock level
> + register then,
> + hdmiphy at 38[23] for bits [1:0] permitted values are
> in
> + the range of 0 mVdiff & 60 mVdiff for each channel at
> + increments 20 mVdiff of amplitude levels for every
> LSB,
> + hdmiphy at 38[23] for bits [7:3] permitted values are
> in
> + the range of 790 and 1430 mV at 20mV increments for
> + every LSB.
> Example:
>
> hdmi {
> @@ -20,4 +44,11 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + hdmiphy-configs {
> + config0: config0 {
> + pixel-clock = <2520>;
> + config-de-emphasis-level = /bits/ 8 <0x26>;
> + config-clock-level = /bits/ 8 < 0x66>;
> + };
> + }
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 32ce9a6..5f599e3 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -197,6 +197,9 @@ struct hdmi_context {
>
> struct hdmi_resources res;
>
> + struct hdmiphy_config *confs;
> + int nr_confs;
> +
> int hpd_gpio;
>
> enum hdmi_type type;
> @@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[]
> = {
> },
> };
>
> -static const struct hdmiphy_config hdmiphy_v14_configs[] = {
> +static struct hdmiphy_config hdmiphy_v14_configs[] = {
> {
> .pixel_clock = 2520,
> .conf = {
> @@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata,
> u32 pixel_clock)
> confs = hdmiphy_v13_configs;
> count = ARRAY_SIZE(hdmiphy_v13_configs);
> } else if (hdata->type == HDMI_TYPE14) {
> - confs = hdmiphy_v14_configs;
> - count = ARRAY_SIZE(hdmiphy_v14_configs);
> + confs = hdata->confs;
> + count = hdata->nr_confs;
> } else
> return -EINVAL;
>
> @@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context
> *hdata)
> if (hdata->type == HDMI_TYPE13)
> hdmiphy_data = hdmiphy_v13_configs[i].conf;
> else
> - hdmiphy_data = hdmiphy_v14_configs[i].conf;
> + hdmiphy_data = hdata->confs[i].conf;
>
> memcpy(buffer, hdmiphy_data, 32);
> ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
> @@ -1894,6 +1897,63 @@ fail:
> return -ENODEV;
> }
>
> +static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
> + st
[PATCH 0/4] Add dt support for exynos hdmiphy settings
CCing Kukjin, Sylwester, and Tomasz. Hi Kukjin, Sylwester, and Tomasz, Shirish has investigated hdmiphy configuration in more detail, and updated it since we gave comments to him. Shouldn't this patch series be reviewed again? Plz, give him your feedback if necessary. Thanks, Inki Dae > -Original Message- > From: Shirish S [mailto:s.shirish at samsung.com] > Sent: Monday, November 25, 2013 5:55 PM > To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com; > devicetree at vger.kernel.org; mark.rutland at arm.com > Cc: airlied at redhat.com; shirish at chromium.org; Shirish S > Subject: [PATCH 0/4] Add dt support for exynos hdmiphy settings > > For various revisions of a chipset if the signal pattern is changed for > every > revision, then the phy setting need to be updated correspondingly by > measuring > the signal. > For getting correct signals the clock level and data de-emphasis > levels needs to be adjusted. > Since only these 2 values matter,we can move the same to dt, > wherein we can have different dt files for every revision. > > This is an initial patchset towards achieving the same > for exynos 5250 and can be later extended to future chipsets. > > V2: replaced moving of entire phy config structure with only > required and justifiable conf registers. > > V3: Incorporated Mark Rutland's comments. > > V4: Rebased and included cros5250-common.dtsi. > > V5: removed nr-configs feild and also the constraint > of having the exact number of configs in the dt file > as in the driver, the programmer can add only the pixel > clock that needs to be updated. > > V6: > V7: removed nr-configs form the dtsi files. > > Shirish S (4): > ARM: dts: smdk5250: Add hdmi phy settings > ARM: dts: arndale: Add hdmi phy settings > ARM: exynos: dts: cros5250: Add hdmi phy settings > drm: exynos: hdmi: Add dt support for hdmiphy settings > > .../devicetree/bindings/video/exynos_hdmi.txt | 31 > arch/arm/boot/dts/cros5250-common.dtsi | 74 +++ > arch/arm/boot/dts/exynos5250-arndale.dts | 74 > +++ > arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 > +++ > drivers/gpu/drm/exynos/exynos_hdmi.c | 77 > +++- > 5 files changed, 326 insertions(+), 4 deletions(-) > > -- > 1.7.9.5
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #161 from Sergey --- Hi Alex, Is there anything we can do to try help fixing the issues left? -- 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/20131126/4a15e06d/attachment.html>
[PATCH] of: Add simple panel device tree binding
Hi Thierry,
Thank you for the patch.
On Friday 22 November 2013 19:41:54 Thierry Reding wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
>
> Bindings for three specific panels are provided to show how the simple
> panel binding can be used.
>
> Signed-off-by: Thierry Reding
> ---
> This binding has already been discussed earlier. Both Laurent and Tomi
> seemed to be generally fine with this.
That's correct, I'm generally fine with your approach, but there's still one
point I'd like to see addressed.
As I mentioned previously, I would like to avoid adding zillions of compatible
properties to the driver, when we could use a single property in the DT
bindings that would specify the timings instead. This would lower the amount
of changes made to the simple panel driver, while keeping DT simple enough (at
least in my opinion).
Specifying the full timings in every DT source file would be pretty verbose
and could be error-prone. However, using a single property to specify one of
the standard display timings, as orinally proposed by Hans de Goede (CC'ed)
during a chat at the kernel summit would in my opinion be a good middle-ground
solution.
Would you consider adding such a property to the simple panel bindings, and
define a common compatible string ? Each panel should of course list its own
compatibility string in addition to the common compatible string in case the
need for extensions arises in the future.
> The fact that the binding targets simple (dumb) panels only and the reduced
> set of properties make it easy to be extended in backwards-compatible ways
> should the need arise, while at the same time allowing to support a wide
> variety of panels out there.
>
> .../devicetree/bindings/panel/auo,b101aw03.txt | 7 +++
> .../bindings/panel/chunghwa,claa101wb03.txt | 7 +++
> .../bindings/panel/panasonic,vvx10f004b00.txt | 7 +++
> .../devicetree/bindings/panel/simple-panel.txt | 21 ++
> 4 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> create mode 100644
> Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt create
> mode 100644
> Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt create
> mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt new file mode
> 100644
> index ..72e088a4fb3a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,b101aw03"
> +
> +This binding is compatible with the simple-panel binding, which is
> specified +in simple-panel.txt in this directory.
> diff --git
> a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt new file
> mode 100644
> index ..0ab2c05a4c22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> @@ -0,0 +1,7 @@
> +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "chunghwa,claa101wb03"
> +
> +This binding is compatible with the simple-panel binding, which is
> specified +in simple-panel.txt in this directory.
> diff --git
> a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt new
> file mode 100644
> index ..d328b0341bf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> @@ -0,0 +1,7 @@
> +Panasonic Corporation 10.1" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "panasonic,vvx10f004b00"
> +
> +This binding is compatible with the simple-panel binding, which is
> specified +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
> b/Documentation/devicetree/bindings/panel/simple-panel.txt new file mode
> 100644
> index ..1341bbf4aa3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
> @@ -0,0 +1,21 @@
> +Simple display panel
> +
> +Required properties:
> +- power-supply: regulator to provide the supply voltage
> +
> +Optional properties:
> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> +- enable-gpios: GPIO pin to enable or disable the panel
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + panel: panel {
> + compatible = "cptt,claa101wb01";
> + ddc-i2c-bus = <&panelddc>;
> +
> + power-supply = <&vdd_pnl_reg>;
> + enable-gpio
[PATCH] of: Add simple panel device tree binding
On Sat, Nov 23, 2013 at 2:41 AM, Thierry Reding
wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
>
> Bindings for three specific panels are provided to show how the simple
> panel binding can be used.
>
> Signed-off-by: Thierry Reding
> ---
> This binding has already been discussed earlier. Both Laurent and Tomi
> seemed to be generally fine with this. The fact that the binding targets
> simple (dumb) panels only and the reduced set of properties make it easy
> to be extended in backwards-compatible ways should the need arise, while
> at the same time allowing to support a wide variety of panels out there.
>
> .../devicetree/bindings/panel/auo,b101aw03.txt | 7 +++
> .../bindings/panel/chunghwa,claa101wb03.txt | 7 +++
> .../bindings/panel/panasonic,vvx10f004b00.txt | 7 +++
> .../devicetree/bindings/panel/simple-panel.txt | 21
> +
> 4 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> create mode 100644
> Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> create mode 100644
> Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> create mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> new file mode 100644
> index ..72e088a4fb3a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,b101aw03"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> new file mode 100644
> index ..0ab2c05a4c22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> @@ -0,0 +1,7 @@
> +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "chunghwa,claa101wb03"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git
> a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> new file mode 100644
> index ..d328b0341bf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> @@ -0,0 +1,7 @@
> +Panasonic Corporation 10.1" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "panasonic,vvx10f004b00"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
> b/Documentation/devicetree/bindings/panel/simple-panel.txt
> new file mode 100644
> index ..1341bbf4aa3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
> @@ -0,0 +1,21 @@
> +Simple display panel
> +
> +Required properties:
> +- power-supply: regulator to provide the supply voltage
> +
> +Optional properties:
> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> +- enable-gpios: GPIO pin to enable or disable the panel
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + panel: panel {
> + compatible = "cptt,claa101wb01";
> + ddc-i2c-bus = <&panelddc>;
> +
> + power-supply = <&vdd_pnl_reg>;
> + enable-gpios = <&gpio 90 0>;
> +
> + backlight = <&backlight>;
> + };
Pardon the question if this has been discussed before, but, would this
also be a good binding in which to store a panel's physical dimensions
(mmWidth, mmHeight)? Or is there another binding more appropriate?
> --
> 1.8.4.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 Tom Stellard changed: What|Removed |Added Attachment #89615|0 |1 is obsolete|| --- Comment #10 from Tom Stellard --- Created attachment 89805 --> https://bugs.freedesktop.org/attachment.cgi?id=89805&action=edit Fix This new patch is an actual fix, not just a workaround. It fixes the crash for me, can you verify? -- 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/20131126/51d1dd2a/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 Tom Stellard changed: What|Removed |Added Attachment #89671|0 |1 is obsolete|| --- Comment #30 from Tom Stellard --- Created attachment 89806 --> https://bugs.freedesktop.org/attachment.cgi?id=89806&action=edit Possible Fix Can you try this patch? If you get a lockup or a hang, please post the output of R600_DEBUG=ps,vs -- 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/20131126/eba17dec/attachment.html>
[PATCH v2] drm/radeon/dpm: simplifying low state adjustment's logic for NI
While working on a dpm bug
(https://bugs.freedesktop.org/show_bug.cgi?id=69723), I stumbled upon a couple
of lines in NI dpm where we were reading and setting back the same values for
no obvious reason. Simplified the logic.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/ni_dpm.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index f263390..2a10bbe 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -841,21 +841,12 @@ static void ni_apply_state_adjust_rules(struct
radeon_device *rdev,
if (disable_mclk_switching) {
mclk = ps->performance_levels[ps->performance_level_count -
1].mclk;
- sclk = ps->performance_levels[0].sclk;
- vddc = ps->performance_levels[0].vddc;
vddci = ps->performance_levels[ps->performance_level_count -
1].vddci;
- } else {
- sclk = ps->performance_levels[0].sclk;
- mclk = ps->performance_levels[0].mclk;
- vddc = ps->performance_levels[0].vddc;
- vddci = ps->performance_levels[0].vddci;
- }
- /* adjusted low state */
- ps->performance_levels[0].sclk = sclk;
- ps->performance_levels[0].mclk = mclk;
- ps->performance_levels[0].vddc = vddc;
- ps->performance_levels[0].vddci = vddci;
+ /* adjusted low state */
+ ps->performance_levels[0].mclk = mclk;
+ ps->performance_levels[0].vddci = vddci;
+ }
btc_skip_blacklist_clocks(rdev, max_limits->sclk, max_limits->mclk,
&ps->performance_levels[0].sclk,
--
1.8.4
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #6 from Michel D?nzer --- Created attachment 89812 --> https://bugs.freedesktop.org/attachment.cgi?id=89812&action=edit SI: Update unaligned offset for 2D->1D transition Does this patch fix the problem? -- 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/20131126/eeafb2be/attachment.html>
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #7 from Arek Ru?niak --- Yes it does, thank you Michel. -- 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/20131126/e0474c5b/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #7 from ?ukasz Skocz --- (In reply to comment #6) > I can't reproduce the problem. Can you try this with mesa master branch? > > Thanks in advance. I just compiled Mesa master using https://aur.archlinux.org/packages/me/mesa-r300-r600-radeonsi-git/PKGBUILD , just added --disable-dri3 flag. The same thing happens, but it seems that i was mistaken about it happening always on the same frame of the video. The mkv file i posted sometimes plays fully without a problem, and sometimes it causes corruption with a seemingly random frame. Same thing happens with my own videos. Could it be that it's a kernel driver bug, not related to Mesa? -- 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/20131126/26128390/attachment.html>
[PATCH] of: Add simple panel device tree binding
On Tue, Nov 26, 2013 at 02:54:41AM +0100, Laurent Pinchart wrote: > Hi Thierry, > > Thank you for the patch. > > On Friday 22 November 2013 19:41:54 Thierry Reding wrote: > > This binding specifies a set of common properties for display panels. It > > can be used as a basis by bindings for specific panels. > > > > Bindings for three specific panels are provided to show how the simple > > panel binding can be used. > > > > Signed-off-by: Thierry Reding > > --- > > This binding has already been discussed earlier. Both Laurent and Tomi > > seemed to be generally fine with this. > > That's correct, I'm generally fine with your approach, but there's still one > point I'd like to see addressed. > > As I mentioned previously, I would like to avoid adding zillions of > compatible > properties to the driver, when we could use a single property in the DT > bindings that would specify the timings instead. This would lower the amount > of changes made to the simple panel driver, while keeping DT simple enough > (at > least in my opinion). > > Specifying the full timings in every DT source file would be pretty verbose > and could be error-prone. However, using a single property to specify one of > the standard display timings, as orinally proposed by Hans de Goede (CC'ed) > during a chat at the kernel summit would in my opinion be a good > middle-ground > solution. > > Would you consider adding such a property to the simple panel bindings, and > define a common compatible string ? Each panel should of course list its own > compatibility string in addition to the common compatible string in case the > need for extensions arises in the future. My gripe with this is that it duplicates information. By definition a simple panel supports a limited number of display modes (typically only a single one), so once you know the compatible value (which needs to be there anyway) you can derive the mode from it. Adding a property that specifies the display mode is redundant. Dave Airlie proposed something else, namely to keep a list of common modes within the driver and have each device reference that mode instead. I think that could work similarily well. It still requires the driver to be touched for each new panel, but the changes will be very small. They'll be more of the "add a new table entry" sort of change that we have in drivers like the 8250/16550-compatible serial. Most of that could probably be wrapped into a macro to make it concise. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/2dc9b0f7/attachment.pgp>
[PATCH] of: Add simple panel device tree binding
On Tue, Nov 26, 2013 at 10:01:54AM +0800, Daniel Kurtz wrote:
> On Sat, Nov 23, 2013 at 2:41 AM, Thierry Reding
> wrote:
> > This binding specifies a set of common properties for display panels. It
> > can be used as a basis by bindings for specific panels.
> >
> > Bindings for three specific panels are provided to show how the simple
> > panel binding can be used.
[...]
> > +Example:
> > +
> > + panel: panel {
> > + compatible = "cptt,claa101wb01";
> > + ddc-i2c-bus = <&panelddc>;
> > +
> > + power-supply = <&vdd_pnl_reg>;
> > + enable-gpios = <&gpio 90 0>;
> > +
> > + backlight = <&backlight>;
> > + };
>
>
> Pardon the question if this has been discussed before, but, would this
> also be a good binding in which to store a panel's physical dimensions
> (mmWidth, mmHeight)? Or is there another binding more appropriate?
This binding doesn't define those properties because they are implied by
the compatible string. The corresponding driver defines a structure like
this:
struct panel_desc {
const struct drm_display_mode *modes;
unsigned int num_modes;
struct {
unsigned int width;
unsigned int height;
} size;
};
The panel_desc.size structure contains the physical panel dimensions,
specified in mm. With that, a panel will be supported by defining
something like this:
static const struct drm_display_mode foo_mode = {
...
};
static const struct panel_desc foo = {
.modes = &foo_mode,
.num_modes = 1,
.size {
.width = 223,
.height = 125,
},
};
static const struct of_device_id platform_of_match[] = {
...
{
.compatible = "vendor,foo",
.data = &foo,
},
...
};
I assume you have a specific use-case in mind. Does this provide what
you need? The driver patches were posted earlier[0][1]. They have
changed slightly since then to address review comments, but nothing
significant.
Thierry
[0]: http://www.spinics.net/lists/devicetree/msg08498.html
[1]: http://www.spinics.net/lists/devicetree/msg08499.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/7411b98c/attachment.pgp>
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 Michel D?nzer changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #8 from Michel D?nzer --- Thanks for testing! Fixed in Git: commit c8a437f4c76527b3c8385699ccee07f35fe3f166 Author: Michel D?nzer Date: Tue Nov 26 18:16:03 2013 +0900 radeon: Update unaligned offset for 2D->1D tiling transition on SI -- 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/20131126/b72ab580/attachment-0001.html>
[PATCH] intel: Track known prime buffers for re-use
On Mon, Nov 25, 2013 at 01:22:41PM -0800, Keith Packard wrote:
> If the application sends us a file descriptor pointing at a prime
> buffer that we've already got, we have to re-use the same bo_gem
> structure or chaos will result.
>
> Track the set of all known prime objects and look to see if the kernel
> has returned one of those for a new file descriptor.
>
> Also checks for prime buffers in the flink case.
>
> Signed-off-by: Keith Packard
> ---
> intel/intel_bufmgr_gem.c | 50
> +---
> 1 file changed, 43 insertions(+), 7 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index df6fcec..2b7fe07 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -149,6 +149,8 @@ struct _drm_intel_bo_gem {
>
> /**
>* Kenel-assigned global name for this object
> + *
> + * List contains both flink named and prime fd'd objects
>*/
> unsigned int global_name;
> drmMMListHead name_list;
> @@ -862,10 +864,6 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr
> *bufmgr,
> }
> }
>
> - bo_gem = calloc(1, sizeof(*bo_gem));
> - if (!bo_gem)
> - return NULL;
> -
> VG_CLEAR(open_arg);
> open_arg.name = handle;
> ret = drmIoctl(bufmgr_gem->fd,
> @@ -874,9 +872,26 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr
> *bufmgr,
> if (ret != 0) {
> DBG("Couldn't reference %s handle 0x%08x: %s\n",
> name, handle, strerror(errno));
> - free(bo_gem);
> return NULL;
> }
> +/* Now see if someone has used a prime handle to get this
> + * object from the kernel before by looking through the list
> + * again for a matching gem_handle
> + */
> + for (list = bufmgr_gem->named.next;
> + list != &bufmgr_gem->named;
> + list = list->next) {
> + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
> + if (bo_gem->gem_handle == open_arg.handle) {
> + drm_intel_gem_bo_reference(&bo_gem->bo);
> + return &bo_gem->bo;
> + }
> + }
The kernel actually doesn't bother with this, i.e. an open on an flink
name will always create a new handle. Given that it was a major pita to
get the prime reimporting going (due to a pile of funny lifetime issues
around reference loops and some assorted locking fun) I'm not volunteering
to fix this ;-) And I also think that a piece of userspace which both
flink-opens and prime imports on the same buffer gets both pieces.
Otoh this can't hurt either, so if you want to stick with this hunk maybe
add a small comment saying that the kernel lies. Or just remove it. Either
way:
Reviewed-by: Daniel Vetter
Aside: I think drm is the only subsystem that goes out of it's way to
ensure a unique relationship between dmabuf and other handles and
underlying objects. If you throw v4l into the mix (e.g. by building a
gstreamer pipe that feeds into an egl image or so) I expect some fun to
happen. Otoh no open-source v4l driver for intel socs, so lalala ;-)
> +
> + bo_gem = calloc(1, sizeof(*bo_gem));
> + if (!bo_gem)
> + return NULL;
> +
> bo_gem->bo.size = open_arg.size;
> bo_gem->bo.offset = 0;
> bo_gem->bo.virtual = NULL;
> @@ -2451,8 +2466,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
> *bufmgr, int prime_fd, int s
> uint32_t handle;
> drm_intel_bo_gem *bo_gem;
> struct drm_i915_gem_get_tiling get_tiling;
> + drmMMListHead *list;
>
> ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
> +
> + /*
> + * See if the kernel has already returned this buffer to us. Just as
> + * for named buffers, we must not create two bo's pointing at the same
> + * kernel object
> + */
> + for (list = bufmgr_gem->named.next;
> + list != &bufmgr_gem->named;
> + list = list->next) {
> + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
> + if (bo_gem->gem_handle == handle) {
> + drm_intel_gem_bo_reference(&bo_gem->bo);
> + return &bo_gem->bo;
> + }
> + }
> +
> if (ret) {
> fprintf(stderr,"ret is %d %d\n", ret, errno);
> return NULL;
> @@ -2487,8 +2519,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
> *bufmgr, int prime_fd, int s
> bo_gem->has_error = false;
> bo_gem->reusable = false;
>
> - DRMINITLISTHEAD(&bo_gem->name_list);
> DRMINITLISTHEAD(&bo_gem->vma_list);
> + DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
>
> VG_CLEAR(get_tiling);
> get_tiling.handle = bo_gem->gem_handle;
> @@ -2513,6 +2545,9 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int
> *prime_fd)
> drm_intel_bufmgr_gem *bufmgr_gem = (drm_inte
[Bug 41375] VDPAU not working on RS880
https://bugs.freedesktop.org/show_bug.cgi?id=41375 Christian K?nig changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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/20131126/e7c6699f/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #8 from Christian K?nig --- (In reply to comment #7) > Could it be that it's a kernel driver bug, not related to Mesa? Not really. The kernel is complaining that mesa is sending down invalid commands, but I have no idea how that can happen. Either we have a very subtile and rare bug somewhere in the userspace driver stack or something is corrupting our command buffer while it gets send to the kernel. What application do you use? Could you try playing with a different one? -- 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/20131126/2fbb5328/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 Arek Ru?niak changed: What|Removed |Added Attachment #89631|0 |1 is obsolete|| Attachment #89640|0 |1 is obsolete|| Attachment #89659|0 |1 is obsolete|| Attachment #89719|0 |1 is obsolete|| --- Comment #31 from Arek Ru?niak --- Created attachment 89825 --> https://bugs.freedesktop.org/attachment.cgi?id=89825&action=edit v4 log with R600_DEBUG=ps,pv it's not hung anymore, but new log: Sam3: SIInstrInfo.cpp:98: virtual void llvm::SIInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::iterator, llvm::DebugLoc, unsigned int, unsigned int, bool) const: Assertion `AMDGPU::SReg_32RegClass.contains(SrcReg)' failed. BTW stalker & xonotic works perfectly with this fix. (32bit 10.1 git-ddc77c5 + llvm 3.5 r195722+fix) -- 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/20131126/5b8afcb0/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #9 from ?ukasz Skocz --- > What application do you use? Could you try playing with a different one? It happens with mplayer and mpv while using vdpau. I tried to reproduce this in vlc and it doesn't happen, although i'm not sure it's using vdpau, the ui is a bit confusing. -- 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/20131126/5efa785f/attachment.html>
[PATCH] intel: Track known prime buffers for re-use
Daniel Vetter writes: > The kernel actually doesn't bother with this, i.e. an open on an flink > name will always create a new handle. Given that it was a major pita to > get the prime reimporting going (due to a pile of funny lifetime issues > around reference loops and some assorted locking fun) I'm not volunteering > to fix this ;-) And I also think that a piece of userspace which both > flink-opens and prime imports on the same buffer gets both pieces. That seems pretty dangerous to me -- you'll end up with aliases to the same buffer this way if user space isn't careful. I bet you check duplicate buffer usage by pointer and not ID though, which means user space will get errors when this happens. That's not terrible, but it isn't great either as there's this nasty call to exit(1) when the execbuffers fails... > Otoh this can't hurt either, so if you want to stick with this hunk maybe > add a small comment saying that the kernel lies. Or just remove it. Either > way: Not being able to test it is a bit sub-optimal; the duplicate handle case for prime was well tested by the time I submitted that patch... > Reviewed-by: Daniel Vetter thanks. > Aside: I think drm is the only subsystem that goes out of it's way to > ensure a unique relationship between dmabuf and other handles and > underlying objects. If you throw v4l into the mix (e.g. by building a > gstreamer pipe that feeds into an egl image or so) I expect some fun to > happen. Otoh no open-source v4l driver for intel socs, so lalala ;-) Some kind of standard of conduct is clearly needed here - not letting user space know they've got aliasing going on is pretty mean. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/5e8e2da0/attachment-0001.pgp>
[PATCH] drm/sysfs: fix OOM verification
Copy/Paste typo.. we need to test for ->kdev instead of ->dev.
Reported-by: Juha Lepp?nen
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index bd2bca3..c22c309 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -516,7 +516,7 @@ int drm_sysfs_device_add(struct drm_minor *minor)
minor_str = "card%d";
minor->kdev = kzalloc(sizeof(*minor->kdev), GFP_KERNEL);
- if (!minor->dev) {
+ if (!minor->kdev) {
r = -ENOMEM;
goto error;
}
--
1.8.4.2
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #32 from darkbasic --- Stalker? When did they release stalker for linux??? -- 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/20131126/2d736646/attachment.html>
[PATCH edid-decode] Read extension blocks in xrandr EDID property
Extend the parsing of the xrandr EDID property block to read extension
blocks, not just the basic block.
Signed-off-by: Simon Farnsworth
---
edid-decode.c | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/edid-decode.c b/edid-decode.c
index 4265843..e26ad3e 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -1126,38 +1126,56 @@ extract_edid(int fd)
start = strstr(ret, "EDID_DATA:");
if (start == NULL)
start = strstr(ret, "EDID:");
-/* Look for xrandr --verbose output (8 lines of 16 hex bytes) */
+/* Look for xrandr --verbose output (lines of 16 hex bytes) */
if (start != NULL) {
const char indentation1[] = "";
const char indentation2[] = "\t\t";
+ /* Used to detect that we've gone past the EDID property */
+ const char half_indentation1[] = "";
+ const char half_indentation2[] = "\t";
const char *indentation;
char *s;
- out = malloc(128);
- if (out == NULL) {
- free(ret);
- return NULL;
- }
-
- for (i = 0; i < 8; i++) {
+ lines = 0;
+ for (i = 0;; i++) {
int j;
- /* Get the next start of the line of EDID hex. */
+ /* Get the next start of the line of EDID hex, assuming spaces for
indentation */
s = strstr(start, indentation = indentation1);
- if (!s)
+ /* Did we skip the start of another property? */
+ if (s && s > strstr(start, half_indentation1))
+ break;
+
+ /* If we failed, retry assuming tabs for indentation */
+ if (!s) {
s = strstr(start, indentation = indentation2);
- if (s == NULL) {
+/* Did we skip the start of another property? */
+if (s && s > strstr(start, half_indentation2))
+break;
+}
+
+ if (!s)
+ break;
+
+ lines++;
+ start = s + strlen(indentation);
+
+ s = realloc(out, lines * 16);
+ if (!s) {
free(ret);
free(out);
return NULL;
}
- start = s + strlen(indentation);
-
+ out = (unsigned char *)s;
c = start;
for (j = 0; j < 16; j++) {
char buf[3];
/* Read a %02x from the log */
if (!isxdigit(c[0]) || !isxdigit(c[1])) {
+if (j != 0) {
+lines--;
+break;
+}
free(ret);
free(out);
return NULL;
@@ -1171,6 +1189,7 @@ extract_edid(int fd)
}
free(ret);
+ edid_lines = lines;
return out;
}
--
1.8.3.1
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #33 from Arek Ru?niak --- We have wine don't you forget;) Now [thanks Tom] it works with dynamic lighting etc. -- 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/20131126/d3aac6bf/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #162 from Anonymous Helper --- I had a similar problem with my HD 5730M. But I'm not sure if it belongs to this bug. For me it's possible to workaround by delaying the boot process manually: e.g. wait ~20 seconds in the GRUB-Menu or pause the bios booting with the key "Break" Can somebody confirm that? -- 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/20131126/d2fbdc3d/attachment.html>
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #3 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #4 from Alex Deucher --- If you boot with radeon.runpm=0, are you still able to manually enable/disable the radeon card with vgaswitcheroo? If not, can you bisect what broke that? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/2] drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
On Mon, Nov 25, 2013 at 1:07 PM, Guenter Roeck wrote: > On Fri, Nov 22, 2013 at 09:52:00PM -0800, Guenter Roeck wrote: >> Simplify the code and fix race condition seen because >> attribute files were created after hwmon device registration. >> >> Signed-off-by: Guenter Roeck >> --- >> Compile tested only; unfortunately I don't have the the necessary hardware. >> > Update: Tested working on actual hardware. Applied. thanks! Alex > > Guenter > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: add VMID allocation trace point
On Mon, Nov 25, 2013 at 9:42 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Signed-off-by: Christian K?nig
Applied. thanks! I fixed the %x argument size warnings in the second patch.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_gart.c | 2 ++
> drivers/gpu/drm/radeon/radeon_trace.h | 15 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 3044e50..aa8f778 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -29,6 +29,7 @@
> #include
> #include "radeon.h"
> #include "radeon_reg.h"
> +#include "radeon_trace.h"
>
> /*
> * GART
> @@ -737,6 +738,7 @@ struct radeon_fence *radeon_vm_grab_id(struct
> radeon_device *rdev,
> for (i = 0; i < 2; ++i) {
> if (choices[i]) {
> vm->id = choices[i];
> + trace_radeon_vm_grab_id(vm->id, ring);
> return rdev->vm_manager.active[choices[i]];
> }
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_trace.h
> b/drivers/gpu/drm/radeon/radeon_trace.h
> index 9f0e181..8c13aec 100644
> --- a/drivers/gpu/drm/radeon/radeon_trace.h
> +++ b/drivers/gpu/drm/radeon/radeon_trace.h
> @@ -47,6 +47,21 @@ TRACE_EVENT(radeon_cs,
> __entry->fences)
> );
>
> +TRACE_EVENT(radeon_vm_grab_id,
> + TP_PROTO(unsigned vmid, int ring),
> + TP_ARGS(vmid, ring),
> + TP_STRUCT__entry(
> +__field(u32, vmid)
> +__field(u32, ring)
> +),
> +
> + TP_fast_assign(
> + __entry->vmid = vmid;
> + __entry->ring = ring;
> + ),
> + TP_printk("vmid=%u, ring=%u", __entry->vmid, __entry->ring)
> +);
> +
> TRACE_EVENT(radeon_vm_set_page,
> TP_PROTO(uint64_t pe, uint64_t addr, unsigned count,
> uint32_t incr, uint32_t flags),
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 71983] libdrm 2.4.49 makes gpu crash (HD7770)
https://bugs.freedesktop.org/show_bug.cgi?id=71983 --- Comment #9 from Dave Witbrodt --- (In reply to comment #8) Confirmed. Thanks! -- 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/20131126/97f9a87c/attachment.html>
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #11 from Rafael Castillo --- sorry for the delay, about your previous patch it worked as you say. ill test this one tonight many thanks for your time -- 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/20131126/fb2259d9/attachment.html>
[PATCH v2] drm/radeon/dpm: simplifying low state adjustment's logic for NI
On Tue, Nov 26, 2013 at 1:13 AM, Alexandre Demers
wrote:
> While working on a dpm bug
> (https://bugs.freedesktop.org/show_bug.cgi?id=69723), I stumbled upon a
> couple of lines in NI dpm where we were reading and setting back the same
> values for no obvious reason. Simplified the logic.
>
This patch creates some unused variable warnings. While fixing them
up, I found the logic could be further cleaned up. See attached.
Alex
> Signed-off-by: Alexandre Demers
> ---
> drivers/gpu/drm/radeon/ni_dpm.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
> index f263390..2a10bbe 100644
> --- a/drivers/gpu/drm/radeon/ni_dpm.c
> +++ b/drivers/gpu/drm/radeon/ni_dpm.c
> @@ -841,21 +841,12 @@ static void ni_apply_state_adjust_rules(struct
> radeon_device *rdev,
>
> if (disable_mclk_switching) {
> mclk = ps->performance_levels[ps->performance_level_count -
> 1].mclk;
> - sclk = ps->performance_levels[0].sclk;
> - vddc = ps->performance_levels[0].vddc;
> vddci = ps->performance_levels[ps->performance_level_count -
> 1].vddci;
> - } else {
> - sclk = ps->performance_levels[0].sclk;
> - mclk = ps->performance_levels[0].mclk;
> - vddc = ps->performance_levels[0].vddc;
> - vddci = ps->performance_levels[0].vddci;
> - }
>
> - /* adjusted low state */
> - ps->performance_levels[0].sclk = sclk;
> - ps->performance_levels[0].mclk = mclk;
> - ps->performance_levels[0].vddc = vddc;
> - ps->performance_levels[0].vddci = vddci;
> + /* adjusted low state */
> + ps->performance_levels[0].mclk = mclk;
> + ps->performance_levels[0].vddci = vddci;
> + }
>
> btc_skip_blacklist_clocks(rdev, max_limits->sclk, max_limits->mclk,
> &ps->performance_levels[0].sclk,
> --
> 1.8.4
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-dpm-simply-state-adjust-logic-for-NI.patch
Type: text/x-diff
Size: 3047 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/ee01faa6/attachment.patch>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #8 from Alex Deucher --- (In reply to comment #4) > It locks up the machine Can you bisect to see what broke vgaswitcheroo on your system? Both runpm and switcheroo use the same acpi method, so fixing one with likely fix both. -- 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/20131126/45fa42de/attachment.html>
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
On Tue, Nov 12, 2013 at 10:35 AM, Tomasz Figa wrote: > On Tuesday 12 of November 2013 12:51:11 Sean Paul wrote: >> On Sun, Nov 10, 2013 at 4:09 PM, Tomasz Figa >> wrote: >> > Hi Sean, >> > >> > On Tuesday 29 of October 2013 12:12:58 Sean Paul wrote: >> >> This patch splits display and manager from subdrv. The result is that >> >> crtc functions can directly call into manager callbacks and encoder >> >> functions can directly call into display callbacks. This will allow >> >> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp >> >> with common code. >> >> >> >> Signed-off-by: Sean Paul >> >> --- >> >> >> >> Changes in v2: >> >> - Pass display into display_ops instead of context >> >> Changes in v3: >> >> - Changed vidi args to exynos_drm_display instead of void >> >> - Moved exynos_drm_hdmi.c removal into next patch >> >> >> >> drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++--- >> >> drivers/gpu/drm/exynos/exynos_drm_core.c | 181 +- >> >> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +--- >> >> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +- >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +-- >> >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++ >> >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258 >> >> -- >> >> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +- >> >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +- >> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161 >> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 211 + >> >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 + >> >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +- >> >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 129 ++--- >> >> 14 files changed, 615 insertions(+), 684 deletions(-) >> > >> > This patch is really heavy, making it very hard to review. I wonder if it >> > couldn't really be split into several smaller patches... >> > >> >> I've distilled it down as much as possible. Unfortunately the >> encoder/crtc were fused pretty tightly and the effects of that are >> far-reaching. > > I was afraid of this. Well, I guess nothing can be done about it then. > >> >> > Anyway, please see my comments below, for the points I haven't overlooked >> > due to the complexity of this patch. >> > >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c >> >> b/drivers/gpu/drm/exynos/exynos_drm_core.c >> >> index 08ca4f9..e76098d 100644 >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c >> >> @@ -16,11 +16,14 @@ >> >> #include >> >> #include >> > >> > Huh? Including a specific bridge chip inside a generic Exynos DRM core? >> > I know this is not a part of this patch, but... this is _broken_. >> > >> > You may want to support multiple bridge chips in Exynos DRM core and you >> > may also want to support PTN3460 in other DRM cores. It can't be done this >> > way. >> > >> > This series is very nice, but the whole effect is destroyed by basing it >> > on top of such insanity... Please rebase it on top of something more >> > reasonable (preferably Inki's next branch directly). >> > >> >> Well, that was blunt. Unfortunately, I don't know how else to do this >> other than this broken, unreasonable and insane way. > > Sorry, this might have been a bit too harsh, but just imagine myself doing > my regular patch review round, hoping (as usual) to see only code that is > not less than great, while suddenly stumbling upon a line of code that > I would expect at most in some vendor tree or maybe several years ago in > sources of a 2.4 kernel. More like code written in the same style as x86 DRM stuff, where they're not used to overabstracting things from day one to make things generic instead of supporting the only known chip combination to date. >> This has already been discussed at length in a few other places. >> Without some help from the drm layer, I don't see any other way to do >> this than to enumerate the possible bridges in each drm driver. >> >> I based the current set off the "Add some missing bits for >> exynos5250-snow" series I sent up a little while ago. This set was >> sent to the relevant dt people, acked by Olof, and there are no >> outstanding review comments. Since it's required for me to test on >> Real Hardware, I assumed this was an appropriate base. >> >> If you think this is _broken_, unreasonable, and insane, I'd love to >> hear an alternative. > > Well, I should say that Laurent would probably have something to say about > this, but I understand that the really good solution need to take some > time to be developed, so... > > What about at least creating a minimal, temporary abstraction layer that > would provide all you originally needed from drm/bridge/ptn3460.h, but in > a bridge chip agnostic way? > > I believe we already have establis
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 Tom Stellard changed: What|Removed |Added Attachment #89806|0 |1 is obsolete|| --- Comment #34 from Tom Stellard --- Created attachment 89853 --> https://bugs.freedesktop.org/attachment.cgi?id=89853&action=edit Patch 1 -- 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/20131126/c542fa90/attachment-0001.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #35 from Tom Stellard --- Created attachment 89854 --> https://bugs.freedesktop.org/attachment.cgi?id=89854&action=edit Patch 2 Can you try these two patches? -- 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/20131126/806730b4/attachment.html>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #36 from Tom Stellard --- (In reply to comment #35) > Created attachment 89854 [details] [review] > Patch 2 > > Can you try these two patches? You should apply them both together. -- 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/20131126/7771e636/attachment.html>
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #9 from Mike Lothian --- I bisected back to [bbd34fcdd1b201e996235731a7c98fd5197d9e51] ACPI / hotplug / PCI: Register all devices under the given bridge Which was during the 3.11 cycle I believe - I guess there's a chance I picked up on a previous bug I'll do some more testing -- 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/20131126/6787d614/attachment.html>
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #5 from Alex Deucher --- This looks like a duplicate of bug 65761. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #10 from Alex Deucher --- (In reply to comment #9) > I bisected back to [bbd34fcdd1b201e996235731a7c98fd5197d9e51] ACPI / hotplug > / PCI: Register all devices under the given bridge > > Which was during the 3.11 cycle I believe - I guess there's a chance I > picked up on a previous bug I'll do some more testing Does reverting that commit fix the 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/20131126/ee6c129c/attachment.html>
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com, ||rjw at sisk.pl --- Comment #2 from Alex Deucher --- >From the bisect in https://bugs.freedesktop.org/show_bug.cgi?id=71930 it looks like commit bbd34fcdd1b201e996235731a7c98fd5197d9e51 caused a regression in vgaswitcheroo and hence runpm. Adding Rafael. Also bug 65811 looks like a duplicate of this one. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 72051] New: [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 Priority: medium Bug ID: 72051 Assignee: dri-devel at lists.freedesktop.org Summary: [JUNIPER] with kernel 3.12 some HDMI screens are not recognized Severity: normal Classification: Unclassified OS: Linux (All) Reporter: eugene.shalygin+bugzilla.FDO at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 89860 --> https://bugs.freedesktop.org/attachment.cgi?id=89860&action=edit xrandr -q --verbose with screen 1 connected I have two external screens, say screen 1 and 2. Screen 1 have HDMI input and screens 2 is connected via HDMI-to-DVI adapter. With kernel 3.12 screen 1 is not recognized on connect anymore. Booting kernel 3.11.9 makes it work again. When I connect screen 1 nothing appears not in Xorg.0.log nor 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/20131126/d3fee2fb/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #1 from Eugene Shalygin --- Created attachment 89861 --> https://bugs.freedesktop.org/attachment.cgi?id=89861&action=edit xrandr -q --verbose with screen 2 connected -- 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/20131126/8c56938a/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #2 from Eugene Shalygin --- Created attachment 89862 --> https://bugs.freedesktop.org/attachment.cgi?id=89862&action=edit 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/20131126/1f1f8a7b/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #3 from Eugene Shalygin --- Created attachment 89863 --> https://bugs.freedesktop.org/attachment.cgi?id=89863&action=edit xorg log -- 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/20131126/f8ceaa2a/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #4 from Eugene Shalygin --- "xrandr -q --verbose with screen 1 connected" was obtained under kernel 3.11.9 -- 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/20131126/58bd1017/attachment.html>
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #6 from Jack --- I'll try with runpm=0 in a moment, will also try reverting commit bbd34fcdd1b201e996235731a7c98fd5197d9e51 as mentioned in 65761 and see if that does anything shiny. I noticed that in bug 65671 his system crashes, however using linux-git (specifically the AUR package) my system runs fine, it just seems to ignore runpm entirely. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65811] AMD 7970M (PowerXpress) power management not functioning properly when using Xrandr to offload rendering
https://bugzilla.kernel.org/show_bug.cgi?id=65811 --- Comment #7 from Jack --- running the kernel with radeon.runpm=0 allows me to successfully disable the discrete card with `echo OFF > /sys/kernel/debug/vgaswitcheroo/switch` [root at localhost linux-git]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :Off::01:00.0 1:IGD:+:Pwr::00:02.0 [root at localhost linux-git]# I should have more tests (and some logs) later this evening -- didn't have a clone of the kernel repo and 5mbps internet at the relatives makes for a lengthy download ;P -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #11 from Mike Lothian --- I've just tried but it doesn't revert cleanly - not even on 3.11 -- 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/20131126/7d2af1a8/attachment.html>
[Bug 65481] Page allocation failure errors on Trinity when playing a HL2 mod (i386 code on 64 bit kernel )
https://bugzilla.kernel.org/show_bug.cgi?id=65481 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk --- Comment #3 from Alan --- Not actually a bug - it's just the machine warning a lot that its struggling to find enough memory immediately. I guess the game is stretching it to the limit. Its dumped as a log warning as for server setups its often very useful to know and adjust workload parameters at that point. The DRM one looks like a graphics out of memory case so I don't think this is actually a bug. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65121] Possible memory leak in qxl drm driver
https://bugzilla.kernel.org/show_bug.cgi?id=65121 Alan changed: What|Removed |Added Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org --- Comment #4 from Alan --- Thanks for confirming -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71930] Kernel Bug and X fails to start when using radeon.runpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=71930 --- Comment #12 from Mike Lothian --- I think that was when I was playing around with the dynamic shutdown patches in one of Dave's git branches - which explains why I haven't really noticed this until now - I rarely used switcheroo This is also possibly related to https://bugzilla.kernel.org/show_bug.cgi?id=61891 -- 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/20131126/ddd55654/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #5 from Alex Deucher --- Can you bisect? This sounds like it might be related to the hotplug breakage fixed by this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=760c960bd6880cf22a57c0af9ff60c96250aad39 but the problematic change wasn't introduced until 3.13. -- 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/20131126/f72537db/attachment.html>
[Bug 72051] [JUNIPER] with kernel 3.12 some HDMI screens are not recognized
https://bugs.freedesktop.org/show_bug.cgi?id=72051 --- Comment #6 from Alex Deucher --- Actually do you have radeon.hw_i2c=1 set somewhere? If so, it should be fixed with this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fae009d15a44e5f1d938340facf4b8bc7dc69a09 -- 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/20131126/961c6f7d/attachment.html>
[Bug 65481] Page allocation failure errors on Trinity when playing a HL2 mod (i386 code on 64 bit kernel )
https://bugzilla.kernel.org/show_bug.cgi?id=65481 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #4 from Alex Deucher --- (In reply to Alan from comment #3) > The DRM one looks like a graphics out of memory case so I don't think this > is actually a bug. Yes, the drm one is also an out of memory case. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #38 from Alexandre Demers --- A couple of observations. I've forced power state to performance and performance state to high. Here is the result: [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info uvdvclk: 0 dclk: 0 power level 2sclk: 83000 mclk: 13 vddc: 1060 vddci: 1150 Now, keeping this configuration, I launched a video relying on UVD. The result downclocks the core clock from 830 (probably limited to 800 as we know) to 725. [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info uvdvclk: 54000 dclk: 4 power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 However, if I don't force this power and performance states combination (letting it as balanced and auto or performance and auto), I have the following: [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info uvdvclk: 54000 dclk: 4 power level 0sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info uvdvclk: 54000 dclk: 4 power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 As you can see, it will adapt to the needed performance state. - So, first question: is it expected to see a lowered sclk when UVD is active? - Second one: when the performance is changed automatically (auto), could we be triggering a performance state change too quickly? - Third one: it was previously said mclk is tied to vddci AND vddc. Wouldn't there be a chance we could encounter a problem here if vddc=1000 and not 1060 when running at full speed? - Last one: is there a way to monitor the GPU temperature and/or the GPU fan speed? (even at full speed when highly solicited, the fan is not running as fast as when dpm=0. I'm wondering if I'm not overheating from time to time). -- 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/20131126/4704e220/attachment-0001.html>
[Bug 65481] Page allocation failure errors on Trinity when playing a HL2 mod (i386 code on 64 bit kernel )
https://bugzilla.kernel.org/show_bug.cgi?id=65481 Alan changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WILL_NOT_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #39 from Alex Deucher --- (In reply to comment #38) > A couple of observations. I've forced power state to performance and > performance state to high. Here is the result: > [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info > uvdvclk: 0 dclk: 0 > power level 2sclk: 83000 mclk: 13 vddc: 1060 vddci: 1150 > > Now, keeping this configuration, I launched a video relying on UVD. The > result downclocks the core clock from 830 (probably limited to 800 as we > know) to 725. > [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info > uvdvclk: 54000 dclk: 4 > power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 > > However, if I don't force this power and performance states combination > (letting it as balanced and auto or performance and auto), I have the > following: > [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info > uvdvclk: 54000 dclk: 4 > power level 0sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 > [root at Xander device]# more /sys/kernel/debug/dri/64/radeon_pm_info > uvdvclk: 54000 dclk: 4 > power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 > > As you can see, it will adapt to the needed performance state. > Not exactly. Here are the power states defined for your system: == power state 0 == ui class: none internal class: boot caps: uvdvclk: 0 dclk: 0 power level 0sclk: 25000 mclk: 15000 vddc: 1000 vddci: 1000 power level 1sclk: 25000 mclk: 15000 vddc: 1000 vddci: 1000 power level 2sclk: 25000 mclk: 15000 vddc: 1000 vddci: 1000 status: c r b == power state 1 == ui class: performance internal class: none caps: uvdvclk: 0 dclk: 0 power level 0sclk: 25000 mclk: 15000 vddc: 900 vddci: 950 power level 1sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 power level 2sclk: 83000 mclk: 13 vddc: 1060 vddci: 1150 status: == power state 2 == ui class: none internal class: uvd caps: video uvdvclk: 54000 dclk: 4 power level 0sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 power level 1sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 status: == power state 3 == ui class: none internal class: uvd_mvc caps: video uvdvclk: 7 dclk: 56000 power level 0sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 power level 1sclk: 5 mclk: 13 vddc: 1000 vddci: 1150 power level 2sclk: 72500 mclk: 13 vddc: 1060 vddci: 1150 status: When you select performance, battery, or balanced state on your system, power state 1 is used. When you activate UVD, the driver selects power state 2. When UVD is not in use, the previously active power state (1 in this case) is selected again. The driver only selects the power state. The power levels (0-2) within the power state are either selected automatically by the hw based on GPU load (auto) or forced to power level 0 or 2 (low or high) is you force the performance level. When you force the performance level to high, it will apply to all power states that you select (both power state 1 and 2) which is why you see the UVD state using 500 vs. 725 Mhz. > - So, first question: is it expected to see a lowered sclk when UVD is > active? Yes since the driver selects a different power state (one tailored to the requirements of the UVD block for smooth video playback). > - Second one: when the performance is changed automatically (auto), could we > be triggering a performance state change too quickly? The driver doesn't trigger performance level changes, the hw does. The driver just selects the overall power state. > - Third one: it was previously said mclk is tied to vddci AND vddc. Wouldn't > there be a chance we could encounter a problem here if vddc=1000 and not > 1060 when running at full speed? Sure. That's why we have the ni_apply_state_adjust_rules() to make sure the power state is valid based on the current requirements. > - Last one: is there a way to monitor the GPU temperature and/or the GPU fan > speed? (even at full speed when highly solicited, the fan is not running as > fast as when dpm=0. I'm wondering if I'm not overheating from time to time). You can see the temperature in sysfs. There should be a entry under /sys/class/hwmon/ for radeon. -- 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/20131126/d248e382/attachment.html>
nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann wrote: > v3.11 is fine, with and without monitor attached. > v3.12 is fine as long as X.org isn't started (but may fail to reboot > cleanly). If a monitor is connected I don't observe any problems, > it freezes without a monitor connected. > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > (I didn't confirm that it's fine with a monitor attached), but I > end up with the following Oops (this is before X.org is started). > > [drm] hdmi device not found 1 0 1 > nouveau [ DEVICE][:01:00.0] BOOT0 : 0x011000a1 > nouveau [ DEVICE][:01:00.0] Chipset: NV11 (NV11) > nouveau [ DEVICE][:01:00.0] Family : NV11 > nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > nouveau [ VBIOS][:01:00.0] ... appears to be valid > nouveau [ VBIOS][:01:00.0] using image from PRAMIN > nouveau [ VBIOS][:01:00.0] BMP version 5.11 > nouveau [ VBIOS][:01:00.0] version 03.11.00.18.00 > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ PTIMER][:01:00.0] unknown input clock freq > nouveau [ PFB][:01:00.0] RAM type: SDRAM > nouveau [ PFB][:01:00.0] RAM size: 32 MiB > nouveau [ PFB][:01:00.0]ZCOMP: 0 tags > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] > *pde = > Oops: [#1] PREEMPT SMP > Modules linked in: snd arc4 psmouse serio_raw pcspkr i2c_viapro soundcore > nouveau(+) video rtl8180 mxm_wmi eeprom_93cx6 wmi mac80211 i2c_algo_bit > drm_kms_helper ttm cfg80211 parport_pc processor button parport drm rfkill > via_agp ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod crc_t10dif cdrom > crct10dif_common ata_generic pata_acpi 8139too 8139cp mii uhci_hcd ehci_pci > ehci_hcd floppy pata_via libata usbcore usb_common scsi_mod > CPU: 0 PID: 360 Comm: modprobe Not tainted 3.13.0-rc1-00095-gb975dc3 #42 > Hardware name:/GA-7VT600, BIOS F5 08/16/2004 > task: dee1e880 ti: de33c000 task.ti: de33c000 > EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > EIP is at _nouveau_clock_init+0x2a/0xaf [nouveau] > EAX: de19c94c EBX: de19c900 ECX: EDX: e0f3689c > ESI: EDI: de19c9c8 EBP: de19c944 ESP: de33db90 > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > CR0: 8005003b CR2: CR3: 1e078000 CR4: 0790 > Stack: > 0013 e0ebe0da de29d600 0005 de19c900 de29d600 0013 > e0ebe17d de19c900 0005 e0f2e8ca 0001 0012 0012 e0ee7f01 > 0012 de2caa38 000c 00c0 de33dc00 > Call Trace: > [] ? nouveau_object_inc+0x30/0x15a [nouveau] > [] ? nouveau_object_inc+0xd3/0x15a [nouveau] > [] ? nouveau_devobj_ctor+0x58c/0x5cd [nouveau] > [] ? nouveau_object_ctor+0x31/0xb7 [nouveau] > [] ? nouveau_object_new+0x14e/0x1e8 [nouveau] > [] ? nouveau_object_ref+0x67/0x98 [nouveau] > [] ? nouveau_drm_load+0x1ea/0x724 [nouveau] > [] ? drm_dev_register+0xd6/0x16c [drm] > [] ? drm_get_pci_dev+0x8c/0x110 [drm] > [] ? pci_read_config_byte+0x14/0x17 > [] ? nouveau_drm_probe+0x17c/0x19e [nouveau] > [] ? pci_device_probe+0x50/0x9d > [] ? sysfs_create_link+0x24/0x2d > [] ? driver_probe_device+0x8c/0x191 > [] ? kobject_add_internal+0x105/0x1ae > [] ? pci_match_id+0x18/0x36 > [] ? __driver_attach+0x44/0x5f > [] ? bus_for_each_dev+0x50/0x5a > [] ? driver_attach+0x14/0x16 > [] ? __device_attach+0x28/0x28 > [] ? bus_add_driver+0xd9/0x190 > [] ? driver_register+0x77/0xab > [] ? 0xe0a83fff > [] ? 0xe0a83fff > [] ? do_one_initcall+0x8f/0x12c > [] ? jump_label_module_notify+0x139/0x15a > [] ? notifier_call_chain+0x29/0x42 > [] ? __blocking_notifier_call_chain+0x45/0x51 > [] ? load_module+0x13e3/0x18e1 > [] ? SyS_init_module+0x72/0x88 > [] ? sysenter_do_call+0x12/0x28 > Code: d2 55 b9 21 00 00 00 57 56 53 89 c3 8d 68 44 83 ec 10 8b 70 40 89 ef 31 > c0 f3 ab 8d 43 4c 89 43 4c 89 43 50 c6 83 c4 00 00 00 ff <8b> 16 83 fa 19 74 > 39 89 d8 ff 93 e8 00 00 00 89 c7 8b 06 85 ff > EIP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] SS:ESP 0068:de33db90 > CR2: > ---[ end trace 0f90bffd76312ecf ]--- The oops in 3.13-rc1 should be fixed by applying the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba . Also note that libdrm had a bug when compiled with gcc-4.8 for pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). Lastly, another thing to try if you're getting random hangs is booting with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still work ok). If that helps, it can be added to the quirks list.
drm/nvd0/disp: initial crtc object implementation
- Original Message -
> From: "Dan Carpenter"
> To: bskeggs at redhat.com
> Cc: dri-devel at lists.freedesktop.org
> Sent: Wednesday, 27 November, 2013 7:30:27 AM
> Subject: re: drm/nvd0/disp: initial crtc object implementation
>
> Hello Ben Skeggs,
>
> The patch 438d99e3b175: "drm/nvd0/disp: initial crtc object
> implementation" from Jul 5, 2011, leads to the following
> static checker warning: "drivers/gpu/drm/nouveau/nv50_display.c:1272
> nv50_crtc_gamma_set()
>error: buffer overflow 'nv_crtc->lut.r' 256 <= 256"
>
> drivers/gpu/drm/nouveau/nv50_display.c
> 1263 static void
> 1264 nv50_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
> 1265 uint32_t start, uint32_t size)
> 1266 {
> 1267 struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
> 1268 u32 end = max(start + size, (u32)256);
> 1269 u32 i;
> 1270
> 1271 for (i = start; i < end; i++) {
> 1272 nv_crtc->lut.r[i] = r[i];
>
> These arrays have 256 elements so going beyond seems like a bug. Should
> the end = max() be a min() or something?
Yes, should definitely be a min. Did you want to cook the patch or shall I?
Thanks,
Ben.
>
> 1273 nv_crtc->lut.g[i] = g[i];
> 1274 nv_crtc->lut.b[i] = b[i];
> 1275 }
> 1276
> 1277 nv50_crtc_lut_load(crtc);
> 1278 }
>
> regards,
> dan carpenter
>
>
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #12 from Rafael Castillo --- well it compiles just fine but since llvm 3.5 xonotic and pepper flash hard reset the GPU. im trying to get a dump of 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/20131126/17f31f7b/attachment-0001.html>
[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cee55fa..48b00f7 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -475,6 +475,80 @@
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
regulators {
--
1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
Hi,
On Tue, Nov 26, 2013 at 6:30 AM, Inki Dae wrote:
> Hi Shirish,
>
> 2013/11/25 Shirish S :
>> This patch adds dt support to hdmiphy config settings
>> as it is board specific and depends on the signal pattern
>> of board.
>>
>> Signed-off-by: Shirish S
>> ---
>> .../devicetree/bindings/video/exynos_hdmi.txt | 31
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 77
>> +++-
>> 2 files changed, 104 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 323983b..6eeb333 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -13,6 +13,30 @@ Required properties:
>> b) pin number within the gpio controller.
>> c) optional flags and pull up/down.
>>
>> +- hdmiphy-configs: following information about the hdmiphy config settings.
>> + a) "config: config" specifies the phy configuration settings,
>> + where 'N' denotes the number of configuration, since every
>> + pixel clock can have its unique configuration.
>> + "pixel-clock" specifies the pixel clock
>> + "conifig-de-emphasis-level" provides fine control of TMDS
>> data
>> +pre emphasis, below shown is example for
>> + data de-emphasis register at address 0x145D0040.
>> + hdmiphy at 38[16] for bits[3:0] permitted values are
>> in
>> + the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
>> + increments for every LSB
>> + hdmiphy at 38[16] for bits[7:4] permitted values are
>> in
>> + the range of 0dB to -7.45dB at increments of -0.45dB
>> + for every LSB.
>> + "config-clock-level" provides fine control of TMDS data
>> + amplitude for each channel,
>> + for example if 0x145D005C is the address of clock level
>> + register then,
>> + hdmiphy at 38[23] for bits [1:0] permitted values
>> are in
>> + the range of 0 mVdiff & 60 mVdiff for each channel at
>> + increments 20 mVdiff of amplitude levels for every
>> LSB,
>> + hdmiphy at 38[23] for bits [7:3] permitted values
>> are in
>> + the range of 790 and 1430 mV at 20mV increments for
>> + every LSB.
>> Example:
>>
>> hdmi {
>> @@ -20,4 +44,11 @@ Example:
>> reg = <0x1453 0x10>;
>> interrupts = <0 95 0>;
>> hpd-gpio = <&gpx3 7 1>;
>> + hdmiphy-configs {
>> + config0: config0 {
>> + pixel-clock = <2520>;
>> + config-de-emphasis-level = /bits/ 8 <0x26>;
>> + config-clock-level = /bits/ 8 < 0x66>;
>> + };
>> + }
>> };
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 32ce9a6..5f599e3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -197,6 +197,9 @@ struct hdmi_context {
>>
>> struct hdmi_resources res;
>>
>> + struct hdmiphy_config *confs;
>> + int nr_confs;
>> +
>> int hpd_gpio;
>>
>> enum hdmi_type type;
>> @@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[]
>> = {
>> },
>> };
>>
>> -static const struct hdmiphy_config hdmiphy_v14_configs[] = {
>> +static struct hdmiphy_config hdmiphy_v14_configs[] = {
>> {
>> .pixel_clock = 2520,
>> .conf = {
>> @@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context
>> *hdata, u32 pixel_clock)
>> confs = hdmiphy_v13_configs;
>> count = ARRAY_SIZE(hdmiphy_v13_configs);
>> } else if (hdata->type == HDMI_TYPE14) {
>> - confs = hdmiphy_v14_configs;
>> - count = ARRAY_SIZE(hdmiphy_v14_configs);
>> + confs = hdata->confs;
>> + count = hdata->nr_confs;
>> } else
>> return -EINVAL;
>>
>> @@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context
>> *hdata)
>> if (hdata->type == HDMI_TYPE13)
>> hdmiphy_data = hdmiphy_v13_configs[i].conf;
>> else
>> - hdmiphy_data = hdmiphy_v14_configs[i].conf;
>> + hdmiphy_data = hdata->confs[i].conf;
>>
>> memcpy(buffer, hdmiphy_data, 32);
>> ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
>> @@ -1894,
[PATCH 0/4] Add dt support for exynos hdmiphy settings
For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values matter,we can move the same to dt, wherein we can have different dt files for every revision. This is an initial patchset towards achieving the same for exynos 5250 and can be later extended to future chipsets. V2: replaced moving of entire phy config structure with only required and justifiable conf registers. V3: Incorporated Mark Rutland's comments. V4: Rebased and included cros5250-common.dtsi. V5: removed nr-configs feild and also the constraint of having the exact number of configs in the dt file as in the driver, the programmer can add only the pixel clock that needs to be updated. V6: V7: removed nr-configs form the dtsi files. V8: Fixed build error Shirish S (4): ARM: dts: smdk5250: Add hdmi phy settings ARM: dts: arndale: Add hdmi phy settings ARM: exynos: dts: cros5250: Add hdmi phy settings drm: exynos: hdmi: Add dt support for hdmiphy settings .../devicetree/bindings/video/exynos_hdmi.txt | 31 arch/arm/boot/dts/cros5250-common.dtsi | 74 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 74 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++- 5 files changed, 326 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 31
drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++-
2 files changed, 104 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..6eeb333 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -13,6 +13,30 @@ Required properties:
b) pin number within the gpio controller.
c) optional flags and pull up/down.
+- hdmiphy-configs: following information about the hdmiphy config settings.
+ a) "config: config" specifies the phy configuration settings,
+ where 'N' denotes the number of configuration, since every
+ pixel clock can have its unique configuration.
+ "pixel-clock" specifies the pixel clock
+ "conifig-de-emphasis-level" provides fine control of TMDS data
+pre emphasis, below shown is example for
+ data de-emphasis register at address 0x145D0040.
+ hdmiphy at 38[16] for bits[3:0] permitted values are in
+ the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
+ increments for every LSB
+ hdmiphy at 38[16] for bits[7:4] permitted values are in
+ the range of 0dB to -7.45dB at increments of -0.45dB
+ for every LSB.
+ "config-clock-level" provides fine control of TMDS data
+ amplitude for each channel,
+ for example if 0x145D005C is the address of clock level
+ register then,
+ hdmiphy at 38[23] for bits [1:0] permitted values are in
+ the range of 0 mVdiff & 60 mVdiff for each channel at
+ increments 20 mVdiff of amplitude levels for every LSB,
+ hdmiphy at 38[23] for bits [7:3] permitted values are in
+ the range of 790 and 1430 mV at 20mV increments for
+ every LSB.
Example:
hdmi {
@@ -20,4 +44,11 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
+ hdmiphy-configs {
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 32ce9a6..7934c6e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -197,6 +197,9 @@ struct hdmi_context {
struct hdmi_resources res;
+ struct hdmiphy_config *confs;
+ int nr_confs;
+
int hpd_gpio;
enum hdmi_type type;
@@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = {
},
};
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
+static struct hdmiphy_config hdmiphy_v14_configs[] = {
{
.pixel_clock = 2520,
.conf = {
@@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata,
u32 pixel_clock)
confs = hdmiphy_v13_configs;
count = ARRAY_SIZE(hdmiphy_v13_configs);
} else if (hdata->type == HDMI_TYPE14) {
- confs = hdmiphy_v14_configs;
- count = ARRAY_SIZE(hdmiphy_v14_configs);
+ confs = hdata->confs;
+ count = hdata->nr_confs;
} else
return -EINVAL;
@@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmiphy_v13_configs[i].conf;
else
- hdmiphy_data = hdmiphy_v14_configs[i].conf;
+ hdmiphy_data = hdata->confs[i].conf;
memcpy(buffer, hdmiphy_data, 32);
ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
@@ -1894,6 +1897,63 @@ fail:
return -ENODEV;
}
+static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
+ struct hdmi_context *hdata)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dev_np = dev->of_node;
+ struct device_node *phy_conf, *cfg_np;
+ int i, pixel_clock = 0;
+
+ /* Initialize with default config */
+ hdata->confs
nouveau/ NV11: 3.12 freezes if X.org is started headless
0679-ga1bfacf.gz Type: application/x-gzip Size: 20676 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0006.bin> -- next part -- A non-text attachment was scrubbed... Name: dmesg-3.11.log.gz Type: application/x-gzip Size: 11188 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0007.bin> -- next part -- A non-text attachment was scrubbed... Name: dmesg-3.12.log.gz Type: application/x-gzip Size: 11497 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0008.bin> -- next part -- A non-text attachment was scrubbed... Name: dmesg-3.13.log.gz Type: application/x-gzip Size: 12335 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0009.bin> -- next part -- A non-text attachment was scrubbed... Name: Xorg-3.11.log.gz Type: application/x-gzip Size: 3979 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0010.bin> -- next part -- A non-text attachment was scrubbed... Name: Xorg-3.13.log.gz Type: application/x-gzip Size: 1147 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131126/bf99276f/attachment-0011.bin>
[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..96e2cad 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -220,6 +220,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
codec at 1100 {
--
1.7.9.5
[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 74
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..77408c6 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -301,6 +301,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
gpio-keys {
--
1.7.9.5
nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann wrote: > Hi > > On Tuesday 26 November 2013, Ilia Mirkin wrote: >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann >> wrote: >> > v3.11 is fine, with and without monitor attached. >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot >> > cleanly). If a monitor is connected I don't observe any problems, >> > it freezes without a monitor connected. >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore >> > (I didn't confirm that it's fine with a monitor attached), but I >> > end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. -ilia
nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann wrote: > Hi > > On Wednesday 27 November 2013, Ilia Mirkin wrote: >> On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann >> wrote: >> > Hi >> > >> > On Tuesday 26 November 2013, Ilia Mirkin wrote: >> >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann > >> gmx.de> wrote: >> >> > v3.11 is fine, with and without monitor attached. >> >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot >> >> > cleanly). If a monitor is connected I don't observe any problems, >> >> > it freezes without a monitor connected. >> >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore >> >> > (I didn't confirm that it's fine with a monitor attached), but I >> >> > end up with the following Oops (this is before X.org is started). >> >> One more idea -- try it with nouveau.runpm=0 -- I've had some odd >> results with it on my older cards (but I don't remember hangs, but I >> also didn't spend a lot of time on it, just plopped the option in and >> moved on). This is a feature that got in in 3.12, and is really the >> only major nouveau-affecting change in that kernel for your card >> revision. > > You're spot on, that does the trick. Great to hear! > > # cat /sys/module/nouveau/parameters/agpmode > -1 > # cat /sys/module/nouveau/parameters/runpm > 0 > > v3.13-rc1-95-gb975dc3 > + > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba > + nouveau.runpm=0 > is now stable, with and without a monitor attached; as is > > 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) > + nouveau.runpm=0 > Dave, looking at the code, it seems like runtime pm should only be getting activated by default for optimus systems. Stefan's is clearly not one of those, neither is mine. Unfortunately I have no clue how the runtime pm subsystem works, but it seems like runtime_suspend() may be getting called directly, e.g. if there are no monitors attached to nouveau, perhaps as a result of nouveau_crtc_set_config in dispnv04/crtc.c. Does the same if (runpm == -1 && !optimus) return -EBUSY check belong in the runtime_suspend callback? -ilia
