[Bug 93615] Tonga does not recover from standby
https://bugs.freedesktop.org/show_bug.cgi?id=93615 --- Comment #2 from EoD --- (In reply to Alex Deucher from comment #1) > Does it work any better with the latest code in: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.5-wip Yes, there are improvements: When I go into standby in a virtual terminal it can recover, but still writing the following error to dmesg: kernel: PM: resume of devices complete after 6591.636 msecs kernel: Restarting tasks ... done. kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0f080008 kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001001E1 kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0208 kernel: VM fault (0x08, vmid 1) at page 1049057, read from 'TC2' (0x54433200) (0) When I switch back to X11 the system locks up, but unlike before I still can execute SysRq. This is a major improvement to the drm-next-4.5 branch! -- 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/20160107/0d6c5b33/attachment.html>
[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm
https://bugs.freedesktop.org/show_bug.cgi?id=93614 --- Comment #2 from Michel Dänzer --- We need to see a backtrace of a crash. -- 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/20160107/b5add0db/attachment.html>
[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm
https://bugs.freedesktop.org/show_bug.cgi?id=93614 --- Comment #3 from Brian Paterni --- Created attachment 120850 --> https://bugs.freedesktop.org/attachment.cgi?id=120850&action=edit gdb captured backtrace of segmentation fault So it turns out I am able to stream successfully from di.fm, I think I may have just needed to sign up(!) :-) Regardless though, launching of the web player does seem to be a bit spotty. Though I'm not sure if it caused by this bug or something else... (In reply to Michel Dänzer from comment #2) > We need to see a backtrace of a crash. I was able to get the attached backtrace by attaching to the browser's flashplugin subprocess! Hopefully it does help. To reproduce, all that seems necessary is to visit di.fm. -- 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/20160107/5be9089e/attachment.html>
[RFC PATCH v1 0/2] Add RK3229 HDMI support
RK3229 have integrated an DesignedWare HDMI controller and an INNO HDMI phy, so we can still reuse the dw-hdmi driver for RK3229 HDMI controller, but we need to create an separate driver for RK3229 HDMI PHY. Yakir Yang (2): drm: rockchip: hdmi: add RK3229 HDMI support dt-bindings: add document for rk3229-hdmi .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +- drivers/gpu/drm/bridge/dw-hdmi.c | 33 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 380 +++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h| 137 include/drm/bridge/dw_hdmi.h | 5 +- 5 files changed, 519 insertions(+), 40 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h -- 2.1.2
[RFC PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support
RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/bridge/dw-hdmi.c| 33 ++-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 380 +---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 ++
include/drm/bridge/dw_hdmi.h| 5 +-
4 files changed, 516 insertions(+), 39 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6fbec99..60b1dcf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
{
unsigned res_idx;
u8 val, msec;
+ int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+ int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
if (prep)
return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
return -EINVAL;
}
+ if (hdmi->plat_data->extphy_config) {
+ /* gen2 tx power off */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+ /* gen2 tx power on */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+ return ret;
+ }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- mpll_config->mpixelclock)
+ if (mpixelclock <= mpll_config->mpixelclock)
break;
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- curr_ctrl->mpixelclock)
+ if (mpixelclock <= curr_ctrl->mpixelclock)
break;
for (; phy_config->mpixelclock != ~0UL; phy_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- phy_config->mpixelclock)
+ if (mpixelclock <= phy_config->mpixelclock)
break;
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
- hdmi->hdmi_data.video_mode.mpixelclock);
+ mpixelclock);
return -EINVAL;
}
@@ -1476,14 +1489,16 @@ dw_hdmi_connector_mode_valid(struct drm_connector
*connector,
{
struct dw_hdmi *hdmi = container_of(connector,
struct dw_hdmi, connector);
+ struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
enum drm_mode_status mode_status = MODE_OK;
/* We don't support double-clocked modes */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_BAD;
- if (hdmi->plat_data->mode_valid)
- mode_status = hdmi->plat_data->mode_valid(connector, mode);
+ if (plat_data->mode_valid)
+ mode_status = plat_data->mode_valid(plat_data, mode);
+
return mode_status;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..424d548 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -21,18 +22,135 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
-#define GRF_SOC_CON60x025c
-#define HDMI_SEL_VOP_LIT(1 << 4)
+#include "dw_hdmi-rockchip.h"
struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+ struct dw_hdmi_plat_data plat_data;
+
+ void __iomem *extphy_regbase;
+ struct clk *extphy_pclk;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
-static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
+static const struct extphy_config_tab rk3229_extphy_cfg[] = {
+ { .mpixelclock = 16500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
+ .data0_level = 4, 4, 4,
+ },
+
+ { .mpixelcloc
[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-hdmi
Signed-off-by: Yakir Yang
---
.../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 668091f..1cdc627 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip specific extensions to the Synopsys Designware HDMI
Required properties:
-- compatible: "rockchip,rk3288-dw-hdmi";
+- compatible: "rockchip,rk3288-dw-hdmi", "rockchip,rk3229-dw-hdmi";
- reg: Physical base address and length of the controller's registers.
- clocks: phandle to hdmi iahb and isfr clocks.
- clock-names: should be "iahb" "isfr"
@@ -15,8 +15,10 @@ Required properties:
rk3288 platform
Optional properties
+- reg: Physical base address and length of the external HDMI PHY's registers.
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+ phandle to the external HDMI PHY clock, name should be
"extphy"
Example:
hdmi: hdmi at ff98 {
--
2.1.2
[PATCH v2 1/2] drm: bridge: sil902x
On 01/06/2016 05:55 PM, Boris Brezillon wrote: > Add basic support for the sil902x RGB -> HDMI bridge. > This driver does not support audio output yet. > > Signed-off-by: Boris Brezillon > --- > Hello, > > This patch is only adding basic support for the sil9022 chip. > As stated in the commit log, there's no audio support, but the > driver also hardcodes a lot of things (like the RGB input format to > use). > There are two reasons for this: > 1/ the DRM framework does not allow for advanced link description > between an encoder and a bridge (that's for the RGB format > limitation). Any idea how this should be described? The adv7511 driver uses a DT param "input_colorspace" to chose between RGB or YUV. I don't think DT is the best idea, but I don't know of a better way either. The connector's display_info.color_formats field gives us some info about the color formats supported by the monitor, but I guess that isn't sufficient data to know what format the encoder is pushing out. We get around this problem in case the case of DSI encoders by using the mipi_dsi_device api, where a DSI based bridge or panel can pass color format/lane info to the DSI host (i.e, encoder) by using mipi_dsi_attach(). > > 2/ I don't have the datasheet of this HDMI encoder, and all logic > has been extracted from those two drivers [1][2], which means > I may miss some important things in my encoder setup. > > Another thing I find weird in the drm_bridge interface is the fact > that we have a ->attach() method, but no ->detach(), which can be > a problem if we allow drm bridges and KMS drivers to be compiled as > modules. Any reason for that? I guess the drm_bridge_add/remove ops make can ensure that the bridge driver itself can be compiled as a module. However, you're right that we would need a bridge detach op that the kms driver should call before it is removed (to unregister the connector we created). Someone would still need to make sure about the order in which the modules are removed. If the bridge driver is removed first, then it would really mess up the kms driver using the bridge. Would the kms driver using this chip really have an encoder? Since the chip takes in RGB input, I'm assuming that the encoder in the kms driver would more or less be nop funcs, giving their way to bridge ops. In such cases, I think the bridge still doesn't fit in so well. The best fit here is how the current tda998x driver is modeled. It adds itself as a component that creates both an encoder and connector, which the kms driver can use directly. This approach, of course, prevents us using tda998x in kms drivers that don't accept any encoders that it didn't create itself. Thanks, Archit > > That's all for the questions part :-). > > Best Regards, > > Boris > > Changes in v2: > - fix errors reported by kbuild test robot > > --- > drivers/gpu/drm/bridge/Kconfig | 8 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/sil902x.c | 491 > +++ > 3 files changed, 500 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/sil902x.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 27e2022..9701fd2 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -40,4 +40,12 @@ config DRM_PARADE_PS8622 > ---help--- > Parade eDP-LVDS bridge chip driver. > > +config DRM_SIL902X > + tristate "Silicon Image sil902x RGB/HDMI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + ---help--- > + Silicon Image sil902x bridge chip driver. > + > endmenu > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index f13c33d..a689aad 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o > obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o > +obj-$(CONFIG_DRM_SIL902X) += sil902x.o > diff --git a/drivers/gpu/drm/bridge/sil902x.c > b/drivers/gpu/drm/bridge/sil902x.c > new file mode 100644 > index 000..2657031 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/sil902x.c > @@ -0,0 +1,491 @@ > +/* > + * Copyright (C) 2014 Atmel > + * Bo Shen > + * > + * Authors:Bo Shen > + * Boris Brezillon > + * Wu, Songjun > + * > + * > + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WA
[RFC PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support
Thanks for "Kbuild test robot" reminding, I forget to update
"mode_valid" function define in imx-hdmi side, would send new version out,
--
>> drivers/gpu/drm/imx/dw_hdmi-imx.c:181:2: warning: initialization from
>> incompatible pointer type
.mode_valid = imx6q_hdmi_mode_valid,
^
drivers/gpu/drm/imx/dw_hdmi-imx.c:181:2: warning: (near initialization for
'imx6q_hdmi_drv_data.mode_valid')
drivers/gpu/drm/imx/dw_hdmi-imx.c:189:2: warning: initialization from
incompatible pointer type
.mode_valid = imx6dl_hdmi_mode_valid,
^
drivers/gpu/drm/imx/dw_hdmi-imx.c:189:2: warning: (near initialization for
'imx6dl_hdmi_drv_data.mode_valid')
Sorry,
- Yakir
On 01/07/2016 12:37 PM, Yakir Yang wrote:
> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
> the max output resolution is 4K.
>
> Signed-off-by: Yakir Yang
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c| 33 ++-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 380
> +---
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 ++
> include/drm/bridge/dw_hdmi.h| 5 +-
> 4 files changed, 516 insertions(+), 39 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 6fbec99..60b1dcf 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> unsigned char prep,
> {
> unsigned res_idx;
> u8 val, msec;
> + int ret;
> const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
> const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
> const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
> + int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
>
> if (prep)
> return -EINVAL;
> @@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> unsigned char prep,
> return -EINVAL;
> }
>
> + if (hdmi->plat_data->extphy_config) {
> + /* gen2 tx power off */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> + ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
> + mpixelclock);
> + /* gen2 tx power on */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> + dw_hdmi_phy_gen2_pddq(hdmi, 0);
> +
> + return ret;
> + }
> +
> /* PLL/MPLL Cfg - always match on final entry */
> for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
> break;
>
> for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
> break;
>
> for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
> break;
>
> if (mpll_config->mpixelclock == ~0UL ||
> curr_ctrl->mpixelclock == ~0UL ||
> phy_config->mpixelclock == ~0UL) {
> dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + mpixelclock);
> return -EINVAL;
> }
>
> @@ -1476,14 +1489,16 @@ dw_hdmi_connector_mode_valid(struct drm_connector
> *connector,
> {
> struct dw_hdmi *hdmi = container_of(connector,
> struct dw_hdmi, connector);
> + struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
> enum drm_mode_status mode_status = MODE_OK;
>
> /* We don't support double-clocked modes */
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> return MODE_BAD;
>
> - if (hdmi->plat_data->mode_valid)
> - mode_status = hdmi->plat_data->mode_valid(connector, mode);
> + if (plat_data->mode_valid)
> + mode_status = plat_data->mode_valid(plat_data, mode);
> +
>
> return mode_status;
> }
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index c65ce8c..424d548 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -7,6 +7,7 @@
>* (at your option) any later version.
>*/
>
[PATCH 1/2] drm: bridge: sil902x
On Wed, Jan 06, 2016 at 10:35:37AM -0500, Ilia Mirkin wrote: > On Wed, Jan 6, 2016 at 10:26 AM, Sascha Hauer > wrote: > > On Wed, Jan 06, 2016 at 02:53:30PM +0100, Boris Brezillon wrote: > >> Hi Sascha, > >> > >> On Wed, 6 Jan 2016 14:47:36 +0100 > >> Sascha Hauer wrote: > >> > >> > Hi Boris, > >> > > >> > On Wed, Jan 06, 2016 at 12:25:50PM +0100, Boris Brezillon wrote: > >> > > Add basic support for the sil902x RGB -> HDMI bridge. > >> > > This driver does not support audio output yet. > >> > > > >> > > Signed-off-by: Boris Brezillon > >> > > --- > >> > > Hello, > >> > > > >> > > This patch is only adding basic support for the sil9022 chip. > >> > > >> > This thing is a SiI9022 for camel case "Silicon Image" with a capital > >> > 'I', > >> > not a small 'l'. > >> > >> Oh, my bad, I'll fix that, but the vendor prefix defined in > >> Documentation/devicetree/bindings/vendor-prefixes.txt is not helping in > >> getting this right. > > > > No, indeed not. Unfortunately sii is already taken by Seiko. > > > >> > >> Should I also change the driver name? > > > > I would suggest so, yes. > > For opposing opinions: > > drivers/gpu/drm/i2c/sil164_drv.c > drivers/media/platform/s5p-tv/sii9234_drv.c > > One of each :) So we have examples for both, then we can continue with the correct name ;) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 103561] unable to handle kernel paging request with csgo in wine+nine, ttm_bo_del_from_lru
https://bugzilla.kernel.org/show_bug.cgi?id=103561 --- Comment #6 from Michel Dänzer --- This is the same as bug 96721, isn't it? https://bugs.freedesktop.org/show_bug.cgi?id=92258 might be related. -- You are receiving this mail because: You are watching the assignee of the bug.
[alsa-devel] [PATCH 0/9] dw-hdmi audio support
Hi Russell, 2016-01-05 17:04 GMT+01:00 Russell King - ARM Linux : > On Tue, Jan 05, 2016 at 04:40:54PM +0100, Jean-Michel Hautbois wrote: >> Hi Russell, >> >> 2015-08-27 10:42 GMT+02:00 Philipp Zabel : >> > >> > Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM >> > Linux: >> > > Following on from the previous sub-series, this sub-series adds audio >> > > support to dw-hdmi. >> > > >> > > The two different variants are now in this patch: AHB audio support >> > > found on iMX6 platforms, and I2S support found on Rockchip patches. >> > > Thanks to Yakir Yang for contributing the I2S support. >> > > >> > > I suspect that there is still some discussion to be had on this >> > > series, though I would like to see it moving forward so that we can >> > > get something merged. >> > >> > Tested-by: Philipp Zabel >> > on i.MX6 GK802 via HDMI connected to a TV (stereo only). >> > >> > except for the i2s patch, which is broken in this series. >> > >> > regards >> > Philipp >> >> >> What is the status of this series ? >> I would like to use audio output in HDMI on my i.MX6 board, but I >> don't know if you have some pending WIP on this ? > > The I2S part has been dropped. The DesignWare HDMI block is configurable > when it is synthesized - it can contain either the AHB audio interface or > an I2S interface. Freescale chose to synthesize it with the AHB audio > interface, and this is what my patches are geared up to provide. > > On Rockchip devices, they chose to synthesize it with the I2S audio > block, and so they need a different driver for it. Yakir Yang has been > working on that, but I've not seen anything recently. After merging > his I2S patch, I found some problems and decided with Yakir that the > best thing to do was to drop it. > > So, the result is we support HDMI audio on iMX6. > > The changes were merged into mainline during the 4.4 merge window, so > Linux 4.4 will support iMX6 HDMI audio. > Thank you for this detailed answer. I will rebase onto 4.4 then :). JM
bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d
On Wed, 06 Jan 2016, Meelis Roos wrote: >> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote: >> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC. >> >> That would seem to be SNB. > > Yes. > >> > Instead of seeing the new dense graphics mode, I see the last VGA text >> > lines and no X appears either. >> >> That's a bit weird. SNB has no power power wells, so only runtime PM >> could be a factor, but it should not kick in that fast during boot even >> if you enable it before loading the driver since we set the delay to 10 >> seconds. >> >> And in any case the commit you list shouldn't really change anything >> for SNB. We used to grab a rpm reference for gmbus via >> intel_aux_display_runtime_get() and now we get it via the GMBUS power >> domain instead. > > I captured dmesg from failing boot, from system logs. gmbus has > something to do with it: > > [drm:i915_dump_device_info] i915 device info: gen=6, pciid=0x0102 > rev=0x09 flags=need_gfx_hws,has_fbc,has_hotplug,has_llc, > [drm:intel_detect_pch] Found CougarPoint PCH > [drm] Memory usable by graphics device = 2048M > [drm:i915_gem_gtt_init] GMADR size = 256M > [drm:i915_gem_gtt_init] GTT stolen size = 32M > [drm:i915_gem_gtt_init] ppgtt mode: 1 > [drm] Replacing VGA console driver > Console: switching to colour dummy device 80x25 > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [] __mutex_lock_slowpath+0x74/0x100 > PGD 0 > Oops: 0002 [#1] SMP > Modules linked in: i915(+) x86_pkg_temp_thermal kvm_intel kvm irqbypass video > crc32c_intel i2c_algo_bit aesni_intel aes_x86_64 glue_helper lrw > drm_kms_helper syscopyarea sysfillrect ablk_helper cryptd iTCO_wdt sysimgblt > iTCO_vendor_support fb_sys_fops snd_hda_codec_realtek drm psmouse > snd_hda_codec_generic e1000e xhci_pci xhci_hcd snd_hda_intel pcspkr > snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_mixer_oss i2c_i801 > snd_pcm ehci_pci ehci_hcd nuvoton_cir usbcore snd_timer parport_pc ptp > pps_core evdev rc_core parport snd usb_common soundcore tpm_tis tpm floppy > lpc_ich mfd_core md_mod w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core > loop autofs4 > CPU: 0 PID: 390 Comm: systemd-udevd Not tainted 4.4.0-rc2-6-gac9b823 #185 > Hardware name: /DQ67OW, BIOS > SWQ6710H.86A.0066.2012.1105.1504 11/05/2012 > task: 8800b7e48c40 ti: 88023342 task.ti: 88023342 > RIP: 0010:[] [] > __mutex_lock_slowpath+0x74/0x100 > RSP: 0018:880233423620 EFLAGS: 00010282 > RAX: RBX: 8800b6a594f8 RCX: 8800b7e48c40 > RDX: 0001 RSI: 8800b7e48c40 RDI: 8800b6a594fc > RBP: 880233423670 R08: R09: 0001 > R10: 8800b6a507e8 R11: 0013 R12: 8800b7e48c40 > R13: 8800b6a594fc R14: R15: 8800b6a59500 > FS: 7f58846428c0() GS:88023e20() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: CR3: 000233424000 CR4: 000406f0 > Stack: > 8800b6a59500 8802353b7148 0206 > 8800b6a5 8800b6a594f8 001d 8800b6a594f8 > 8800b6a5 8800b6a5 fffeea06 81519d1b > Call Trace: > [] ? mutex_lock+0x1b/0x30 > [] ? intel_display_power_get+0x29/0xe0 [i915] > [] ? gmbus_xfer+0x38/0x680 [i915] > [] ? try_to_wake_up+0x43/0x320 > [] ? __i2c_transfer+0x106/0x380 [i2c_core] > [] ? i2c_transfer+0x6d/0xa0 [i2c_core] > [] ? i2c_smbus_xfer_emulated+0x105/0x4c0 [i2c_core] > [] ? __wake_up_common+0x4e/0x90 > [] ? idr_get_empty_slot+0x18b/0x390 > [] ? i2c_smbus_xfer+0x118/0x2e0 [i2c_core] > [] ? i2c_default_probe+0xc5/0x110 [i2c_core] > [] ? i2c_check_addr_busy+0x39/0x60 [i2c_core] > [] ? i2c_do_add_adapter+0x159/0x260 [i2c_core] > [] ? i2c_do_add_adapter+0x260/0x260 [i2c_core] > [] ? bus_for_each_drv+0x55/0x90 > [] ? i2c_register_adapter+0x1c6/0x320 [i2c_core] > [] ? intel_setup_gmbus+0x220/0x310 [i915] intel_setup_gmbus registers the i2c adapters, which does transfers on the i2c bus on probe, and this happens before intel_power_domains_init which initializes the power domain lock. The bisect and backtrace make sense and are not mysterious at all. Not sure of the fix though, are we better off changing the init order, or making sure the probes don't happen or don't screw us up. BR, Jani. > [] ? i915_driver_load+0x4eb/0x15e0 [i915] > [] ? drm_dev_register+0x9c/0xb0 [drm] > [] ? drm_get_pci_dev+0x89/0x1d0 [drm] > [] ? pci_device_probe+0x81/0xe0 > [] ? driver_probe_device+0x147/0x310 > [] ? __driver_attach+0x7b/0x80 > [] ? driver_probe_device+0x310/0x310 > [] ? bus_for_each_dev+0x5a/0x90 > [] ? bus_add_driver+0x1a4/0x220 > [] ? 0xa033c000 > [] ? driver_register+0x57/0xc0 > [] ? do_one_initcall+0x81/0x1b0 > [] ? kmem_cache_alloc_trace+0x31/0x120 > [] ? do_init_module+0x5b/0x1dc > [] ? load_module+0x1e52/0x2220 >
[RFC PATCH v2 0/4] Add RK3229 HDMI support
RK3229 have integrated an DesignedWare HDMI controller and an INNO HDMI phy, so we can still reuse the dw-hdmi driver for RK3229 HDMI controller, but we need to create an separate driver for RK3229 HDMI PHY. This series is based on Mark Yao's drm-next branch [https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2015-12-28] After picking my "Add RK3229 vop support" series, HDMI monitor could light up normally on RK3229 SDK board. Changes in v2: - Split some dw-hdmi driver changes into separate patches [01/04] & [02/04] Yakir Yang (4): drm: dw-hdmi: make it easy to recovery the platform data for platform driver drm: dw-hdmi: passing the "plat_data" when calling platform mode_valid drm: rockchip: hdmi: add RK3229 HDMI support dt-bindings: add document for rk3229-hdmi .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +- drivers/gpu/drm/bridge/dw-hdmi.c | 32 +- drivers/gpu/drm/imx/dw_hdmi-imx.c | 17 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 376 +++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h| 137 include/drm/bridge/dw_hdmi.h | 5 +- 6 files changed, 529 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h -- 2.1.2
[Bug 93594] Flickering Shadows in The Talos Principle
https://bugs.freedesktop.org/show_bug.cgi?id=93594 EoD changed: What|Removed |Added CC||EoD at xmw.de --- Comment #4 from EoD --- I rendered the apitrace on llvmpipe. If there is still flickering it is much less compared to the radeonsi replay: https://www.youtube.com/watch?v=InHA4RAVvfM -- 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/20160107/5c35d9e2/attachment-0001.html>
[RFC PATCH v2 1/4] drm: dw-hdmi: make it easy to recovery the platform data for platform driver
Signed-off-by: Yakir Yang
---
Changes in v2: None
drivers/gpu/drm/imx/dw_hdmi-imx.c | 7 ---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 063825f..0968610 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -26,6 +26,7 @@ struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
struct regmap *regmap;
+ struct dw_hdmi_plat_data plat_data;
};
static const struct dw_hdmi_mpll_config imx_mpll_cfg[] = {
@@ -204,7 +205,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -221,7 +221,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_imx_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ hdmi->plat_data = *(const struct dw_hdmi_plat_data *)match->data;
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
@@ -253,7 +253,8 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+ return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
+ &hdmi->plat_data);
}
static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c65ce8c..d5816b3 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -28,6 +28,7 @@ struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+ struct dw_hdmi_plat_data plat_data;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -242,7 +243,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -259,7 +259,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ hdmi->plat_data = *(const struct dw_hdmi_plat_data *)match->data;
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
@@ -293,7 +293,8 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+ return dw_hdmi_bind(dev, master, data, encoder, iores, irq,
+ &hdmi->plat_data);
}
static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
--
2.1.2
[RFC PATCH v2 2/4] drm: dw-hdmi: passing the "plat_data" when calling platform mode_valid
Make it easy for platform driver could recovery the private data that
would help to valid the display mode.
Signed-off-by: Yakir Yang
---
Changes in v2: None
drivers/gpu/drm/bridge/dw-hdmi.c| 5 +++--
drivers/gpu/drm/imx/dw_hdmi-imx.c | 10 ++
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
include/drm/bridge/dw_hdmi.h| 2 +-
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6fbec99..5ad72ec 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1476,14 +1476,15 @@ dw_hdmi_connector_mode_valid(struct drm_connector
*connector,
{
struct dw_hdmi *hdmi = container_of(connector,
struct dw_hdmi, connector);
+ const struct dw_hdmi_plat_data *plat_data = hdmi->plat_data;
enum drm_mode_status mode_status = MODE_OK;
/* We don't support double-clocked modes */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_BAD;
- if (hdmi->plat_data->mode_valid)
- mode_status = hdmi->plat_data->mode_valid(connector, mode);
+ if (plat_data->mode_valid)
+ mode_status = plat_data->mode_valid(plat_data, mode);
return mode_status;
}
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 0968610..8b0a7da 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -150,8 +150,9 @@ static const struct drm_encoder_funcs
dw_hdmi_imx_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-static enum drm_mode_status imx6q_hdmi_mode_valid(struct drm_connector *con,
- struct drm_display_mode *mode)
+static enum drm_mode_status
+imx6q_hdmi_mode_valid(const struct dw_hdmi_plat_data *plat_data,
+ struct drm_display_mode *mode)
{
if (mode->clock < 13500)
return MODE_CLOCK_LOW;
@@ -162,8 +163,9 @@ static enum drm_mode_status imx6q_hdmi_mode_valid(struct
drm_connector *con,
return MODE_OK;
}
-static enum drm_mode_status imx6dl_hdmi_mode_valid(struct drm_connector *con,
- struct drm_display_mode
*mode)
+static enum drm_mode_status
+imx6dl_hdmi_mode_valid(const struct dw_hdmi_plat_data *plat_data,
+ struct drm_display_mode *mode)
{
if (mode->clock < 13500)
return MODE_CLOCK_LOW;
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index d5816b3..8164823 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -156,7 +156,7 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
}
static enum drm_mode_status
-dw_hdmi_rockchip_mode_valid(struct drm_connector *connector,
+dw_hdmi_rockchip_mode_valid(const struct dw_hdmi_plat_data *plat_data,
struct drm_display_mode *mode)
{
const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3..f8dec64 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -52,7 +52,7 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_mpll_config *mpll_cfg;
const struct dw_hdmi_curr_ctrl *cur_ctr;
const struct dw_hdmi_phy_config *phy_config;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
+ enum drm_mode_status (*mode_valid)(const struct dw_hdmi_plat_data *pd,
struct drm_display_mode *mode);
};
--
2.1.2
[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support
RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
the max output resolution is 4K.
Signed-off-by: Yakir Yang
---
Changes in v2:
- Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]
drivers/gpu/drm/bridge/dw-hdmi.c| 27 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367 ++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
include/drm/bridge/dw_hdmi.h| 3 +
4 files changed, 507 insertions(+), 27 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 5ad72ec..5e03d83 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
{
unsigned res_idx;
u8 val, msec;
+ int ret;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
+ int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
if (prep)
return -EINVAL;
@@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
return -EINVAL;
}
+ if (hdmi->plat_data->extphy_config) {
+ /* gen2 tx power off */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
+mpixelclock);
+ /* gen2 tx power on */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+ return ret;
+ }
+
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- mpll_config->mpixelclock)
+ if (mpixelclock <= mpll_config->mpixelclock)
break;
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- curr_ctrl->mpixelclock)
+ if (mpixelclock <= curr_ctrl->mpixelclock)
break;
for (; phy_config->mpixelclock != ~0UL; phy_config++)
- if (hdmi->hdmi_data.video_mode.mpixelclock <=
- phy_config->mpixelclock)
+ if (mpixelclock <= phy_config->mpixelclock)
break;
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
phy_config->mpixelclock == ~0UL) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
- hdmi->hdmi_data.video_mode.mpixelclock);
+ mpixelclock);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8164823..24fffaa 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -7,6 +7,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -21,18 +22,134 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
-#define GRF_SOC_CON60x025c
-#define HDMI_SEL_VOP_LIT(1 << 4)
+#include "dw_hdmi-rockchip.h"
struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
struct dw_hdmi_plat_data plat_data;
+
+ void __iomem *extphy_regbase;
+ struct clk *extphy_pclk;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
+static const struct extphy_config_tab rockchip_extphy_cfg[] = {
+ { .mpixelclock = 16500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
+ .data0_level = 4, 4, 4,
+ },
+
+ { .mpixelclock = 22500,
+ .pre_emphasis = 0, .slopeboost = 0, .clk_level = 6,
+ .data0_level = 6, 6, 6,
+ },
+
+ { .mpixelclock = 34000,
+ .pre_emphasis = 1, .slopeboost = 0, .clk_level = 6,
+ .data0_level = 10, 10, 10,
+ },
+
+ { .mpixelclock = 59400,
+ .pre_emphasis = 1, .slopeboost = 0, .clk_level = 7,
+ .data0_level = 10, 10, 10,
+ },
+
+ { .mpixelclock = ~0UL},
+};
+
+static const struct extphy_pll_config_tab rockchip_extphy_pll_cfg[] = {
+ {
+ .mpixelclock = 2700, .param = {
+ { .pll_nd = 1, .pll_nf = 45,
+ .tmsd_divider_a = 3, 1
[RFC PATCH v2 4/4] dt-bindings: add document for rk3229-hdmi
Signed-off-by: Yakir Yang
---
Changes in v2: None
.../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 668091f..1cdc627 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -2,7 +2,7 @@ Rockchip specific extensions to the Synopsys Designware HDMI
Required properties:
-- compatible: "rockchip,rk3288-dw-hdmi";
+- compatible: "rockchip,rk3288-dw-hdmi", "rockchip,rk3229-dw-hdmi";
- reg: Physical base address and length of the controller's registers.
- clocks: phandle to hdmi iahb and isfr clocks.
- clock-names: should be "iahb" "isfr"
@@ -15,8 +15,10 @@ Required properties:
rk3288 platform
Optional properties
+- reg: Physical base address and length of the external HDMI PHY's registers.
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
+ phandle to the external HDMI PHY clock, name should be
"extphy"
Example:
hdmi: hdmi at ff98 {
--
2.1.2
[PATCH] drm/i915: Init power domains early in driver load
Since
commit ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
Cc: Ville Syrjälä
Cc: Patrik Jakobsson
Cc: Imre Deak
Cc: Jani Nikula
Cc: Meelis Roos
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
Cc: stable at vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b4741d121a74..405aba2ca736 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -396,8 +396,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_switcheroo;
- intel_power_domains_init_hw(dev_priv);
-
ret = intel_irq_install(dev_priv);
if (ret)
goto cleanup_gem_stolen;
@@ -1025,6 +1023,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
intel_irq_init(dev_priv);
intel_uncore_sanitize(dev);
+ intel_power_domains_init(dev_priv);
+ intel_power_domains_init_hw(dev_priv);
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev);
@@ -1057,8 +1057,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto out_gem_unload;
}
- intel_power_domains_init(dev_priv);
-
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
--
2.6.4
[Intel-gfx] [PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 07, 2016 at 10:10:56AM +0100, Daniel Vetter wrote:
> Since
>
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b4741d121a74..405aba2ca736 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -396,8 +396,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_vga_switcheroo;
>
> - intel_power_domains_init_hw(dev_priv);
> -
> ret = intel_irq_install(dev_priv);
> if (ret)
> goto cleanup_gem_stolen;
> @@ -1025,6 +1023,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_irq_init(dev_priv);
> intel_uncore_sanitize(dev);
> + intel_power_domains_init(dev_priv);
> + intel_power_domains_init_hw(dev_priv);
A long time ago you wished for static/runtime analysis to check the
ordering constraints, so do I :|
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> @@ -1057,8 +1057,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_gem_unload;
> }
>
> - intel_power_domains_init(dev_priv);
Wouldn't you also have to update the unwind-on-error paths?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 1/2] drm: bridge: sil902x
Hi Archit, On Thu, 7 Jan 2016 11:12:47 +0530 Archit Taneja wrote: > > > On 01/06/2016 05:55 PM, Boris Brezillon wrote: > > Add basic support for the sil902x RGB -> HDMI bridge. > > This driver does not support audio output yet. > > > > Signed-off-by: Boris Brezillon > > --- > > Hello, > > > > This patch is only adding basic support for the sil9022 chip. > > As stated in the commit log, there's no audio support, but the > > driver also hardcodes a lot of things (like the RGB input format to > > use). > > There are two reasons for this: > > 1/ the DRM framework does not allow for advanced link description > > between an encoder and a bridge (that's for the RGB format > > limitation). Any idea how this should be described? > > The adv7511 driver uses a DT param "input_colorspace" to chose between > RGB or YUV. I don't think DT is the best idea, but I don't know of a > better way either. Yes, maybe not the best place, but I must admit that's a convenient way to set the link format. > > The connector's display_info.color_formats field gives us some info > about the color formats supported by the monitor, but I guess that > isn't sufficient data to know what format the encoder is pushing out. I created the ->bus_formats field in drm_display_info exactly for this purpose (it's used to detect the appropriate output format when connecting panels), but as you said, this is only describing the link between the connector and the display, not the link between the encoder and the bridge. I'm currently abusing this field (setting bus_formats to RGB888 in the sii902x driver), but that would be better to have this description at the encoder/bridge level. > > We get around this problem in case the case of DSI encoders by using > the mipi_dsi_device api, where a DSI based bridge or panel can pass > color format/lane info to the DSI host (i.e, encoder) by using > mipi_dsi_attach(). Yep, that's also an approach I considered a while ago: creating a DPI bus layer (not sure DPI is the correct name here), and implementing a DPI driver in atmel_hlcdc drivers and using DPI APIs on the slave side (panels and bridges/encoders). But I never had any feedback. > > > > > > 2/ I don't have the datasheet of this HDMI encoder, and all logic > > has been extracted from those two drivers [1][2], which means > > I may miss some important things in my encoder setup. > > > > Another thing I find weird in the drm_bridge interface is the fact > > that we have a ->attach() method, but no ->detach(), which can be > > a problem if we allow drm bridges and KMS drivers to be compiled as > > modules. Any reason for that? > > I guess the drm_bridge_add/remove ops make can ensure that the bridge > driver itself can be compiled as a module. However, you're right that > we would need a bridge detach op that the kms driver should call > before it is removed (to unregister the connector we created). > > Someone would still need to make sure about the order in which the > modules are removed. If the bridge driver is removed first, then > it would really mess up the kms driver using the bridge. Yes, the remove order is another problem we have to deal with > > > Would the kms driver using this chip really have an encoder? No, I have to create an encoder of type NONE to make everybody happy (we need an encoder + a connector to attach to a panel), but as I understand, when the KMS device outputs the pixel stream in raw RGB it's not considered as an encoder (which IMO is not such a good idea, because I have no way to represent my raw RGB connector :-/). > Since the chip takes in RGB input, I'm assuming that the encoder in > the kms driver would more or less be nop funcs, giving their way to > bridge ops. Exactly, that's a nop unless you have a panel connected to it. In the case it calls the drm_panel_xxx() functions. > > In such cases, I think the bridge still doesn't fit in so well. The > best fit here is how the current tda998x driver is modeled. It adds > itself as a component that creates both an encoder and connector, > which the kms driver can use directly. This approach, of course, > prevents us using tda998x in kms drivers that don't accept any > encoders that it didn't create itself. Actually that's what I did first [1], but I asked for some advice to other DRM developers, and they suggested to expose it as a drm_bridge. Now, I don't know what's the best option: I heard that some work was being done to merge the encoder slave and bridge concepts. I just thought external encoders were falling in that case too. And BTW, the different between all those components is still obscure to me. Thanks for the suggestions. Best Regards, Boris [1]https://github.com/linux4sam/linux-at91/blob/linux-3.18-at91/drivers/gpu/drm/i2c/sil902x.c -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH 0/5] Add encoder_mask to crtc_state, v2.
Another attempt at adding encoder_mask, with some behavioral fixes. Maarten Lankhorst (5): drm/core: Add drm_encoder_index. drm/core: Add drm_for_each_encoder_mask, v2. drm/i915: Do not touch best_encoder for load detect. drm/atomic: Do not unset crtc when an encoder is stolen drm/atomic: Add encoder_mask to crtc_state, v2. drivers/gpu/drm/drm_atomic_helper.c | 46 ++-- drivers/gpu/drm/drm_crtc.c | 23 ++ drivers/gpu/drm/i915/intel_display.c | 5 ++-- include/drm/drm_crtc.h | 14 +++ 4 files changed, 79 insertions(+), 9 deletions(-) -- 2.1.0
[PATCH 3/5] drm/i915: Do not touch best_encoder for load detect.
This should only be touched by drm_atomic_helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 391cc7f000da..d77968092ce4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10549,7 +10549,6 @@ retry:
}
connector_state->crtc = crtc;
- connector_state->best_encoder = &intel_encoder->base;
crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
if (IS_ERR(crtc_state)) {
@@ -10645,7 +10644,6 @@ void intel_release_load_detect_pipe(struct
drm_connector *connector,
if (IS_ERR(crtc_state))
goto fail;
- connector_state->best_encoder = NULL;
connector_state->crtc = NULL;
crtc_state->base.enable = crtc_state->base.active = false;
--
2.1.0
[PATCH 4/5] drm/atomic: Do not unset crtc when an encoder is stolen
While we steal the encoder away from the connector the connector may be updated to use a different encoder. Without this change if 2 connectors swap encoders one of them will end up without a crtc. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 57cccd68ca52..9c84b3b37631 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -134,7 +134,6 @@ steal_encoder(struct drm_atomic_state *state, struct drm_crtc_state *crtc_state; struct drm_connector *connector; struct drm_connector_state *connector_state; - int ret; /* * We can only steal an encoder coming from a connector, which means we @@ -165,9 +164,6 @@ steal_encoder(struct drm_atomic_state *state, if (IS_ERR(connector_state)) return PTR_ERR(connector_state); - ret = drm_atomic_set_crtc_for_connector(connector_state, NULL); - if (ret) - return ret; connector_state->best_encoder = NULL; } -- 2.1.0
[PATCH 2/5] drm/core: Add drm_for_each_encoder_mask, v2.
This is similar to the other drm_for_each_*_mask functions.
Changes since v1:
- Use for_each_if
Signed-off-by: Maarten Lankhorst
---
include/drm/drm_crtc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fd2ace4a18de..c0226f945d62 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2153,6 +2153,17 @@ struct drm_mode_config {
list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
+/**
+ * drm_for_each_encoder_mask - iterate over encoders specified by bitmask
+ * @encoder: the loop cursor
+ * @dev: the DRM device
+ * @encoder_mask: bitmask of encoder indices
+ *
+ * Iterate over all encoders specified by bitmask.
+ */
+#define drm_for_each_encoder_mask(encoder, dev, encoder_mask) \
+ list_for_each_entry((encoder), &(dev)->mode_config.encoder_list, head) \
+ for_each_if ((encoder_mask) & (1 << drm_encoder_index(encoder)))
#define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
--
2.1.0
[PATCH 1/5] drm/core: Add drm_encoder_index.
This is useful for adding encoder_mask in crtc_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_crtc.c | 23 +++
include/drm/drm_crtc.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 62fa95fa5471..b7c990e0c8b4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1161,6 +1161,29 @@ out_unlock:
EXPORT_SYMBOL(drm_encoder_init);
/**
+ * drm_encoder_index - find the index of a registered encoder
+ * @encoder: encoder to find index for
+ *
+ * Given a registered encoder, return the index of that encoder within a DRM
+ * device's list of encoders.
+ */
+unsigned int drm_encoder_index(struct drm_encoder *encoder)
+{
+ unsigned int index = 0;
+ struct drm_encoder *tmp;
+
+ drm_for_each_encoder(tmp, encoder->dev) {
+ if (tmp == encoder)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_encoder_index);
+
+/**
* drm_encoder_cleanup - cleans up an initialised encoder
* @encoder: encoder to cleanup
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c65a212db77e..fd2ace4a18de 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2225,6 +2225,7 @@ int drm_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
const struct drm_encoder_funcs *funcs,
int encoder_type, const char *name, ...);
+extern unsigned int drm_encoder_index(struct drm_encoder *encoder);
/**
* drm_encoder_crtc_ok - can a given crtc drive a given encoder?
--
2.1.0
[PATCH 5/5] drm/atomic: Add encoder_mask to crtc_state, v2.
This allows iteration over encoders using drm_for_each_encoder_mask
without inspecting all connector_states, which requires connection_mutex.
Changes since v1:
- Add a set_best_encoder helper function and update encoder_mask inside it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 42 +---
drivers/gpu/drm/i915/intel_display.c | 3 +++
include/drm/drm_crtc.h | 2 ++
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9c84b3b37631..a33c7a2aaa78 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -125,6 +125,41 @@ get_current_crtc_for_encoder(struct drm_device *dev,
return NULL;
}
+static void
+set_best_encoder(struct drm_atomic_state *state,
+struct drm_connector_state *conn_state,
+struct drm_encoder *encoder)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+
+ if (conn_state->best_encoder) {
+ /* Unset the encoder_mask in the old crtc state. */
+ crtc = conn_state->connector->state->crtc;
+
+ WARN_ON(!crtc);
+ if (crtc) {
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
crtc);
+
+ crtc_state->encoder_mask &=
+ ~(1 <<
drm_encoder_index(conn_state->best_encoder));
+ }
+ }
+
+ if (encoder) {
+ crtc = conn_state->crtc;
+ WARN_ON(!crtc);
+ if (crtc) {
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
crtc);
+
+ crtc_state->encoder_mask |=
+ 1 << drm_encoder_index(encoder);
+ }
+ }
+
+ conn_state->best_encoder = encoder;
+}
+
static int
steal_encoder(struct drm_atomic_state *state,
struct drm_encoder *encoder,
@@ -164,7 +199,7 @@ steal_encoder(struct drm_atomic_state *state,
if (IS_ERR(connector_state))
return PTR_ERR(connector_state);
- connector_state->best_encoder = NULL;
+ set_best_encoder(state, connector_state, NULL);
}
return 0;
@@ -212,7 +247,7 @@ update_connector_routing(struct drm_atomic_state *state,
int conn_idx)
connector->base.id,
connector->name);
- connector_state->best_encoder = NULL;
+ set_best_encoder(state, connector_state, NULL);
return 0;
}
@@ -275,7 +310,8 @@ update_connector_routing(struct drm_atomic_state *state,
int conn_idx)
if (WARN_ON(!connector_state->crtc))
return -EINVAL;
- connector_state->best_encoder = new_encoder;
+ set_best_encoder(state, connector_state, new_encoder);
+
idx = drm_crtc_index(connector_state->crtc);
crtc_state = state->crtc_states[idx];
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d77968092ce4..2d9cc848f294 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15604,6 +15604,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc)
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
crtc->base.state->connector_mask = 0;
+ crtc->base.state->encoder_mask = 0;
/* Because we only establish the connector -> encoder ->
* crtc links if something is active, this means the
@@ -15843,6 +15844,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
*/
encoder->base.crtc->state->connector_mask |=
1 <<
drm_connector_index(&connector->base);
+ encoder->base.crtc->state->encoder_mask |=
+ 1 << drm_encoder_index(&encoder->base);
}
} else {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c0226f945d62..51287f36b214 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -307,6 +307,7 @@ struct drm_plane_helper_funcs;
* @connectors_changed: connectors to this crtc have been updated
* @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
* @connector_mask: bitmask of (1 << drm_connector_index(connector)) of
attached connectors
+ * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached
encoders
* @last_vblank_count: for helpers and drivers to capture the vblank of the
* update to ensure framebuffer cleanup isn't done too early
* @adjusted_mode: for use by helpers and drivers to compute a
[PATCH v2 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms
Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission (32-192kHz Fs) using IEC60958 and IEC 61937 - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle Changes in v2: - Using DRM atomic helper functions for connector init (Mark) - Remove "hdmi->connector.encoder = encoder;" (Mark) - Correct the misspell "rk3036-dw-hdmi" (Heiko) Yakir Yang (2): drm: rockchip/hdmi: add Innosilicon HDMI support dt-bindings: add document for Innosilicon HDMI on Rockchip platform .../display/rockchip/inno_hdmi-rockchip.txt| 50 + drivers/gpu/drm/rockchip/Kconfig |8 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/inno_hdmi.c | 1010 drivers/gpu/drm/rockchip/inno_hdmi.h | 364 +++ 5 files changed, 1433 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h -- 2.1.2
[PATCH v2 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Signed-off-by: Yakir Yang
---
Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
drivers/gpu/drm/rockchip/Kconfig |8 +
drivers/gpu/drm/rockchip/Makefile|1 +
drivers/gpu/drm/rockchip/inno_hdmi.c | 1010 ++
drivers/gpu/drm/rockchip/inno_hdmi.h | 364
4 files changed, 1383 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..a5014e0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,11 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_INNO_HDMI
+ tristate "Rockchip specific extensions for Innosilicon HDMI"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a9d380f..da2bf76 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..9327617
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,1010 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ *Yakir Yang
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+ int vic;
+ bool sink_is_hdmi;
+ bool sink_has_audio;
+ unsigned int enc_in_format;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+
+ struct mutex lock;
+ struct completion cmp;
+};
+
+struct inno_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+
+ int irq;
+ struct clk *pclk;
+ void __iomem *regs;
+
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct inno_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ int dpms_mode;
+ unsigned int tmds_rate;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+enum {
+ CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
+ CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
+ CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
+ CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
+ CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
+ CSC_RGB_0_255_TO_RGB_16_235_8BIT,
+};
+
+static const char coeff_csc[][24] = {
+ /*
+* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
+* R = 1.164*Y + 1.596*V - 204
+* G = 1.164*Y - 0.391*U - 0.813*V + 154
+* B = 1.164*Y + 2.018*U - 258
+*/
+ {
+ 0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
+ 0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
+ 0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
+ },
+ /*
+* YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
+* R = Y + 1.402*V - 248
+* G = Y - 0.344*U - 0.714*V + 135
+* B = Y + 1.772*U - 227
+*/
+ {
+ 0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
+ 0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
+
[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support
Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang:
> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
> the max output resolution is 4K.
>
> Signed-off-by: Yakir Yang
It sounds like the INNO HDMI2.0 phy is not necessarily specific to
RK3229 but might also appear in other SoCs? If so, I think this should
be implemented in a separate phy driver and be used by dw_hdmi-rockchip.
regards
Philipp
> ---
> Changes in v2:
> - Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]
>
> drivers/gpu/drm/bridge/dw-hdmi.c| 27 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367
> ++--
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
> include/drm/bridge/dw_hdmi.h| 3 +
> 4 files changed, 507 insertions(+), 27 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 5ad72ec..5e03d83 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> unsigned char prep,
> {
> unsigned res_idx;
> u8 val, msec;
> + int ret;
> const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
> const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
> const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
> const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
> + int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
>
> if (prep)
> return -EINVAL;
> @@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> unsigned char prep,
> return -EINVAL;
> }
>
> + if (hdmi->plat_data->extphy_config) {
> + /* gen2 tx power off */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> + dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> + ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
> + mpixelclock);
> + /* gen2 tx power on */
> + dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> + dw_hdmi_phy_gen2_pddq(hdmi, 0);
> +
> + return ret;
> + }
> +
> /* PLL/MPLL Cfg - always match on final entry */
> for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
> break;
>
> for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
> break;
>
> for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
> break;
>
> if (mpll_config->mpixelclock == ~0UL ||
> curr_ctrl->mpixelclock == ~0UL ||
> phy_config->mpixelclock == ~0UL) {
> dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + mpixelclock);
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 8164823..24fffaa 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -7,6 +7,7 @@
> * (at your option) any later version.
> */
>
> +#include
> #include
> #include
> #include
> @@ -21,18 +22,134 @@
> #include "rockchip_drm_drv.h"
> #include "rockchip_drm_vop.h"
>
> -#define GRF_SOC_CON60x025c
> -#define HDMI_SEL_VOP_LIT(1 << 4)
> +#include "dw_hdmi-rockchip.h"
>
> struct rockchip_hdmi {
> struct device *dev;
> struct regmap *regmap;
> struct drm_encoder encoder;
> struct dw_hdmi_plat_data plat_data;
> +
> + void __iomem *extphy_regbase;
> + struct clk *extphy_pclk;
> };
>
> #define to_rockchip_hdmi(x) container_of(x, struct rockchip_hdmi, x)
>
> +static const struct extphy_config_tab rockchip_extphy_cfg[] = {
> + { .mpixelclock = 16500,
> + .pre_emphasis = 0, .slopeboost = 0, .clk_level = 4,
> + .data0_level = 4, 4, 4,
> + },
> +
> + { .mpixelclock = 22500,
> + .pre_emphasis = 0, .slopeboost = 0, .clk_level = 6,
> + .data0_level = 6, 6, 6,
> + },
> +
> + { .mpixelclock = 34000,
> + .pre_emphasis = 1, .slopeboost = 0, .clk_level = 6,
> + .data0_level = 10, 10, 10,
>
[PATCH v2 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v2:
- Correct the misspell "rk3036-dw-hdmi" (Heiko)
.../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
new file mode 100644
index 000..8096a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
@@ -0,0 +1,50 @@
+Rockchip specific extensions to the Innosilicon HDMI
+
+
+Required properties:
+- compatible:
+ "rockchip,rk3036-inno-hdmi";
+- reg:
+ Physical base address and length of the controller's registers.
+- clocks, clock-names:
+ Phandle to hdmi controller clock, name should be "pclk"
+- interrupts:
+ HDMI interrupt number
+- ports:
+ Contain one port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/graph.txt.
+- pinctrl-0, pinctrl-name:
+ Switch the iomux of HPD/CEC pins to HDMI function.
+
+Example:
+hdmi: hdmi at 20034000 {
+ compatible = "rockchip,rk3036-inno-hdmi";
+ reg = <0x20034000 0x4000>;
+ interrupts = ;
+ clocks = <&cru PCLK_HDMI>;
+ clock-names = "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_ctl>;
+ status = "disabled";
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_lcdc: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_hdmi>;
+ };
+ };
+};
+
+&pinctrl {
+ hdmi {
+ hdmi_ctl: hdmi-ctl {
+ rockchip,pins = <1 8 RK_FUNC_1 &pcfg_pull_none>,
+ <1 9 RK_FUNC_1 &pcfg_pull_none>,
+ <1 10 RK_FUNC_1 &pcfg_pull_none>,
+ <1 11 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
+};
--
2.1.2
[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support
Hi Philipp,
Thanks for your fast respond :)
On 01/07/2016 06:04 PM, Philipp Zabel wrote:
> Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang:
>> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy,
>> the max output resolution is 4K.
>>
>> Signed-off-by: Yakir Yang
> It sounds like the INNO HDMI2.0 phy is not necessarily specific to
> RK3229 but might also appear in other SoCs? If so, I think this should
> be implemented in a separate phy driver and be used by dw_hdmi-rockchip.
Do you mean I should create a new phy driver that place in "driver/phy"
directly ?
I have think about this idea, and it would make things much clean. But
INNO PHY
driver need the target pixel clock in drm_display_mode, I didn't find a
good way
to pass this variable to separate phy driver. Do you have some idea ?
Thanks,
- Yakir
> regards
> Philipp
>
>> ---
>> Changes in v2:
>> - Split some dw-hdmi driver changes into separate patches [01/04] & [02/04]
>>
>> drivers/gpu/drm/bridge/dw-hdmi.c| 27 +-
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 367
>> ++--
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h | 137 +++
>> include/drm/bridge/dw_hdmi.h| 3 +
>> 4 files changed, 507 insertions(+), 27 deletions(-)
>> create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.h
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/dw-hdmi.c
>> index 5ad72ec..5e03d83 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
>> @@ -735,10 +735,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
>> unsigned char prep,
>> {
>> unsigned res_idx;
>> u8 val, msec;
>> +int ret;
>> const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>> const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>> const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
>> const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
>> +int mpixelclock = hdmi->hdmi_data.video_mode.mpixelclock;
>>
>> if (prep)
>> return -EINVAL;
>> @@ -758,27 +760,38 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
>> unsigned char prep,
>> return -EINVAL;
>> }
>>
>> +if (hdmi->plat_data->extphy_config) {
>> +/* gen2 tx power off */
>> +dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>> +dw_hdmi_phy_gen2_pddq(hdmi, 1);
>> +
>> +ret = hdmi->plat_data->extphy_config(hdmi->plat_data, res_idx,
>> + mpixelclock);
>> +/* gen2 tx power on */
>> +dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>> +dw_hdmi_phy_gen2_pddq(hdmi, 0);
>> +
>> +return ret;
>> +}
>> +
>> /* PLL/MPLL Cfg - always match on final entry */
>> for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
>> -if (hdmi->hdmi_data.video_mode.mpixelclock <=
>> -mpll_config->mpixelclock)
>> +if (mpixelclock <= mpll_config->mpixelclock)
>> break;
>>
>> for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
>> -if (hdmi->hdmi_data.video_mode.mpixelclock <=
>> -curr_ctrl->mpixelclock)
>> +if (mpixelclock <= curr_ctrl->mpixelclock)
>> break;
>>
>> for (; phy_config->mpixelclock != ~0UL; phy_config++)
>> -if (hdmi->hdmi_data.video_mode.mpixelclock <=
>> -phy_config->mpixelclock)
>> +if (mpixelclock <= phy_config->mpixelclock)
>> break;
>>
>> if (mpll_config->mpixelclock == ~0UL ||
>> curr_ctrl->mpixelclock == ~0UL ||
>> phy_config->mpixelclock == ~0UL) {
>> dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
>> -hdmi->hdmi_data.video_mode.mpixelclock);
>> +mpixelclock);
>> return -EINVAL;
>> }
>>
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> index 8164823..24fffaa 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -7,6 +7,7 @@
>>* (at your option) any later version.
>>*/
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -21,18 +22,134 @@
>> #include "rockchip_drm_drv.h"
>> #include "rockchip_drm_vop.h"
>>
>> -#define GRF_SOC_CON60x025c
>> -#define HDMI_SEL_VOP_LIT(1 << 4)
>> +#include "dw_hdmi-rockchip.h"
>>
>> struct rockchip_hdmi {
>> struct device *dev;
>> struct regmap *regmap;
>> struct drm_encoder encoder;
>> struct dw_hdmi_plat_data plat_data;
>> +
>> +void __iomem *extphy_regbase;
>> +struct clk *extphy_pclk;
>> };
>>
>> #define to_rockchip_hdmi(x)container_of
[PATCH] x86: Add an explicit barrier() to clflushopt()
On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: > During testing we observed that the last cacheline was not being flushed > from a > > mb() > for (addr = addr & -clflush_size; addr < end; addr += clflush_size) > clflushopt(); > mb() > > loop (where the initial addr and end were not cacheline aligned). > > Changing the loop from addr < end to addr <= end, or replacing the > clflushopt() with clflush() both fixed the testcase. Hinting that GCC > was miscompling the assembly within the loop and specifically the > alternative within clflushopt() was confusing the loop optimizer. > > Adding a barrier() into clflushopt() is enough for GCC to dtrt, but > solving why GCC is not seeing the constraints from the alternative_io() > would be smarter... > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92501 > Testcase: gem_tiled_partial_pwrite_pread/read > Signed-off-by: Chris Wilson > Cc: Ross Zwisler > Cc: H. Peter Anvin > Cc: Imre Deak > Cc: Daniel Vetter > Cc: dri-devel at lists.freedesktop.org > --- > arch/x86/include/asm/special_insns.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/include/asm/special_insns.h > b/arch/x86/include/asm/special_insns.h > index 2270e41b32fd..0c7aedbf8930 100644 > --- a/arch/x86/include/asm/special_insns.h > +++ b/arch/x86/include/asm/special_insns.h > @@ -199,6 +199,11 @@ static inline void clflushopt(volatile void *__p) > ".byte 0x66; clflush %P0", > X86_FEATURE_CLFLUSHOPT, > "+m" (*(volatile char __force *)__p)); > + /* GCC (4.9.1 and 5.2.1 at least) appears to be very confused when > + * meeting this alternative() and demonstrably miscompiles loops > + * iterating over clflushopts. > + */ > + barrier(); > } Or an alternative: +#define alternative_output(oldinstr, newinstr, feature, output)\ + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ + : output : "i" (0) : "memory") I would really appreciate some knowledgeable folks taking a look at the asm for clflushopt() as it still affects today's kernel and gcc. Fwiw, I have confirmed that arch/x86/mm/pageattr.c clflush_cache_range() is similarly affected. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/i915: Init power domains early in driver load
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Signed-off-by: Daniel Vetter
Tested-by: Meelis Roos
Worked fine on my SNB computer.
> ---
> drivers/gpu/drm/i915/i915_dma.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b4741d121a74..405aba2ca736 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -396,8 +396,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_vga_switcheroo;
>
> - intel_power_domains_init_hw(dev_priv);
> -
> ret = intel_irq_install(dev_priv);
> if (ret)
> goto cleanup_gem_stolen;
> @@ -1025,6 +1023,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_irq_init(dev_priv);
> intel_uncore_sanitize(dev);
> + intel_power_domains_init(dev_priv);
> + intel_power_domains_init_hw(dev_priv);
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> @@ -1057,8 +1057,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_gem_unload;
> }
>
> - intel_power_domains_init(dev_priv);
> -
> ret = i915_load_modeset_init(dev);
> if (ret < 0) {
> DRM_ERROR("failed to init modeset\n");
>
--
Meelis Roos (mroos at ut.ee) http://www.cs.ut.ee/~mroos/
bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d
On Thu, 07 Jan 2016, Jani Nikula wrote: > On Wed, 06 Jan 2016, Meelis Roos wrote: >>> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote: >>> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC. >>> >>> That would seem to be SNB. >> >> Yes. >> >>> > Instead of seeing the new dense graphics mode, I see the last VGA text >>> > lines and no X appears either. >>> >>> That's a bit weird. SNB has no power power wells, so only runtime PM >>> could be a factor, but it should not kick in that fast during boot even >>> if you enable it before loading the driver since we set the delay to 10 >>> seconds. >>> >>> And in any case the commit you list shouldn't really change anything >>> for SNB. We used to grab a rpm reference for gmbus via >>> intel_aux_display_runtime_get() and now we get it via the GMBUS power >>> domain instead. >> >> I captured dmesg from failing boot, from system logs. gmbus has >> something to do with it: >> >> [drm:i915_dump_device_info] i915 device info: gen=6, pciid=0x0102 >> rev=0x09 flags=need_gfx_hws,has_fbc,has_hotplug,has_llc, >> [drm:intel_detect_pch] Found CougarPoint PCH >> [drm] Memory usable by graphics device = 2048M >> [drm:i915_gem_gtt_init] GMADR size = 256M >> [drm:i915_gem_gtt_init] GTT stolen size = 32M >> [drm:i915_gem_gtt_init] ppgtt mode: 1 >> [drm] Replacing VGA console driver >> Console: switching to colour dummy device 80x25 >> BUG: unable to handle kernel NULL pointer dereference at (null) >> IP: [] __mutex_lock_slowpath+0x74/0x100 >> PGD 0 >> Oops: 0002 [#1] SMP >> Modules linked in: i915(+) x86_pkg_temp_thermal kvm_intel kvm irqbypass >> video crc32c_intel i2c_algo_bit aesni_intel aes_x86_64 glue_helper lrw >> drm_kms_helper syscopyarea sysfillrect ablk_helper cryptd iTCO_wdt sysimgblt >> iTCO_vendor_support fb_sys_fops snd_hda_codec_realtek drm psmouse >> snd_hda_codec_generic e1000e xhci_pci xhci_hcd snd_hda_intel pcspkr >> snd_hda_codec snd_hwdep snd_hda_core snd_pcm_oss snd_mixer_oss i2c_i801 >> snd_pcm ehci_pci ehci_hcd nuvoton_cir usbcore snd_timer parport_pc ptp >> pps_core evdev rc_core parport snd usb_common soundcore tpm_tis tpm floppy >> lpc_ich mfd_core md_mod w83627ehf hwmon_vid coretemp hwmon eeprom i2c_core >> loop autofs4 >> CPU: 0 PID: 390 Comm: systemd-udevd Not tainted 4.4.0-rc2-6-gac9b823 #185 >> Hardware name: /DQ67OW, BIOS >> SWQ6710H.86A.0066.2012.1105.1504 11/05/2012 >> task: 8800b7e48c40 ti: 88023342 task.ti: 88023342 >> RIP: 0010:[] [] >> __mutex_lock_slowpath+0x74/0x100 >> RSP: 0018:880233423620 EFLAGS: 00010282 >> RAX: RBX: 8800b6a594f8 RCX: 8800b7e48c40 >> RDX: 0001 RSI: 8800b7e48c40 RDI: 8800b6a594fc >> RBP: 880233423670 R08: R09: 0001 >> R10: 8800b6a507e8 R11: 0013 R12: 8800b7e48c40 >> R13: 8800b6a594fc R14: R15: 8800b6a59500 >> FS: 7f58846428c0() GS:88023e20() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: CR3: 000233424000 CR4: 000406f0 >> Stack: >> 8800b6a59500 8802353b7148 0206 >> 8800b6a5 8800b6a594f8 001d 8800b6a594f8 >> 8800b6a5 8800b6a5 fffeea06 81519d1b >> Call Trace: >> [] ? mutex_lock+0x1b/0x30 >> [] ? intel_display_power_get+0x29/0xe0 [i915] >> [] ? gmbus_xfer+0x38/0x680 [i915] >> [] ? try_to_wake_up+0x43/0x320 >> [] ? __i2c_transfer+0x106/0x380 [i2c_core] >> [] ? i2c_transfer+0x6d/0xa0 [i2c_core] >> [] ? i2c_smbus_xfer_emulated+0x105/0x4c0 [i2c_core] >> [] ? __wake_up_common+0x4e/0x90 >> [] ? idr_get_empty_slot+0x18b/0x390 >> [] ? i2c_smbus_xfer+0x118/0x2e0 [i2c_core] >> [] ? i2c_default_probe+0xc5/0x110 [i2c_core] >> [] ? i2c_check_addr_busy+0x39/0x60 [i2c_core] >> [] ? i2c_do_add_adapter+0x159/0x260 [i2c_core] >> [] ? i2c_do_add_adapter+0x260/0x260 [i2c_core] >> [] ? bus_for_each_drv+0x55/0x90 >> [] ? i2c_register_adapter+0x1c6/0x320 [i2c_core] >> [] ? intel_setup_gmbus+0x220/0x310 [i915] > > intel_setup_gmbus registers the i2c adapters, which does transfers on > the i2c bus on probe, and this happens before intel_power_domains_init > which initializes the power domain lock. > > The bisect and backtrace make sense and are not mysterious at all. > > Not sure of the fix though, are we better off changing the init order, > or making sure the probes don't happen or don't screw us up. So I started wondering why we are not seeing this. To reproduce, looks like you'll need to have an i2c driver with class I2C_CLASS_DDC for the i2c detect (and the bug) to happen. In tree, the only ones seem to be drivers/misc/eeprom/eeprom.c drivers/staging/olpc_dcon/olpc_dcon.c I presume you have one or the other. No matter what, userspace can access the adapter right away when we register it, so this needs to be fixe
[Bug 80868] Support screen scaling modes for external monitors
https://bugs.freedesktop.org/show_bug.cgi?id=80868 --- Comment #20 from Kamil Páral --- Glad that it helped :) I have created an RFE for xrandr to ignore case for scaling mode values - bug 93624. -- 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/20160107/a309f60c/attachment.html>
[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #10 from Vedran MiletiÄ --- Further information: this bug does not occur on R9 380, tested with 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1) (prog-if 00 [VGA controller]) Dual DVI using DVI-I and DVI-D works fine. -- 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/20160107/ad4be2f9/attachment.html>
bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d
> > intel_setup_gmbus registers the i2c adapters, which does transfers on > > the i2c bus on probe, and this happens before intel_power_domains_init > > which initializes the power domain lock. > > > > The bisect and backtrace make sense and are not mysterious at all. > > > > Not sure of the fix though, are we better off changing the init order, > > or making sure the probes don't happen or don't screw us up. > > So I started wondering why we are not seeing this. To reproduce, looks > like you'll need to have an i2c driver with class I2C_CLASS_DDC for the > i2c detect (and the bug) to happen. In tree, the only ones seem to be > > drivers/misc/eeprom/eeprom.c Yes, I have that for DIMM SPD information access. > drivers/staging/olpc_dcon/olpc_dcon.c > > I presume you have one or the other. > > No matter what, userspace can access the adapter right away when we > register it, so this needs to be fixed along the lines of [1]. > > BR, > Jani. > > > [1] > http://patchwork.freedesktop.org/patch/msgid/1452157856-27360-1-git-send-email-daniel.vetter > at ffwll.ch -- Meelis Roos (mroos at linux.ee)
[PATCH] drm/i915: Init power domains early in driver load
Since
commit ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
Cc: Ville Syrjälä
Cc: Patrik Jakobsson
Cc: Imre Deak
Cc: Jani Nikula
Cc: Meelis Roos
Cc: Chris Wilson
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
Cc: stable at vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Tested-by: Meelis Roos
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 988a3806512a..490d8b0d931e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_switcheroo;
- intel_power_domains_init_hw(dev_priv, false);
intel_csr_ucode_init(dev_priv);
@@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
intel_irq_init(dev_priv);
intel_uncore_sanitize(dev);
+ intel_power_domains_init(dev_priv);
+ intel_power_domains_init_hw(dev_priv);
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev);
@@ -1057,12 +1058,10 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto out_gem_unload;
}
- intel_power_domains_init(dev_priv);
-
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
- goto out_power_well;
+ goto out_vblank;
}
/*
@@ -1091,8 +1090,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
return 0;
-out_power_well:
- intel_power_domains_fini(dev_priv);
+out_vblank:
drm_vblank_cleanup(dev);
out_gem_unload:
WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
@@ -1103,6 +1101,7 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
+ intel_power_domains_fini(dev_priv);
pm_qos_remove_request(&dev_priv->pm_qos);
destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
out_freedpwq:
--
2.6.4
[PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote:
> Since
>
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Tested-by: Meelis Roos
> Signed-off-by: Daniel Vetter
Onion looks fine to me,
Acked-by: Chris Wilson
I don't feel comfortable enough with the power domains dependencies to
know if the init sequence is correct.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [PATCH] drm/i915: Init power domains early in driver load
Hi Daniel, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160106] [cannot apply to v4.4-rc8] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-i915-Init-power-domains-early-in-driver-load/20160107-194542 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x007-01060743 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': >> drivers/gpu/drm/i915/i915_dma.c:1028:2: error: too few arguments to function >> 'intel_power_domains_init_hw' intel_power_domains_init_hw(dev_priv); ^ In file included from drivers/gpu/drm/i915/i915_dma.c:35:0: drivers/gpu/drm/i915/intel_drv.h:1417:6: note: declared here void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool resume); ^ vim +/intel_power_domains_init_hw +1028 drivers/gpu/drm/i915/i915_dma.c 1022 goto out_freedpwq; 1023 } 1024 1025 intel_irq_init(dev_priv); 1026 intel_uncore_sanitize(dev); 1027 intel_power_domains_init(dev_priv); > 1028 intel_power_domains_init_hw(dev_priv); 1029 1030 /* Try to make sure MCHBAR is enabled before poking at it */ 1031 intel_setup_mchbar(dev); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 24308 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/9b3539a1/attachment-0001.obj>
[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #11 from EoD --- (In reply to Vedran MiletiÄ from comment #9) > EoD did testing on Sapphire R9 380X Nitro, details at > https://gist.github.com/EoD/2baa78b81e233218a59c and copied below: This has been tested on drm-next-4.5 geafbbd9 and drm-next-4.5-wip gbc48ef9, although only the trivial cases. -- 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/20160107/6f07c4e1/attachment.html>
[PATCH] drm/i915: Init power domains early in driver load
On Thu, 07 Jan 2016, Daniel Vetter wrote:
> Since
>
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Tested-by: Meelis Roos
> Signed-off-by: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93608
> ---
> drivers/gpu/drm/i915/i915_dma.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 988a3806512a..490d8b0d931e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_vga_switcheroo;
>
> - intel_power_domains_init_hw(dev_priv, false);
>
> intel_csr_ucode_init(dev_priv);
>
> @@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_irq_init(dev_priv);
> intel_uncore_sanitize(dev);
> + intel_power_domains_init(dev_priv);
> + intel_power_domains_init_hw(dev_priv);
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> @@ -1057,12 +1058,10 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_gem_unload;
> }
>
> - intel_power_domains_init(dev_priv);
> -
> ret = i915_load_modeset_init(dev);
> if (ret < 0) {
> DRM_ERROR("failed to init modeset\n");
> - goto out_power_well;
> + goto out_vblank;
> }
>
> /*
> @@ -1091,8 +1090,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> return 0;
>
> -out_power_well:
> - intel_power_domains_fini(dev_priv);
> +out_vblank:
> drm_vblank_cleanup(dev);
> out_gem_unload:
> WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
> @@ -1103,6 +1101,7 @@ out_gem_unload:
>
> intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
> + intel_power_domains_fini(dev_priv);
> pm_qos_remove_request(&dev_priv->pm_qos);
> destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
> out_freedpwq:
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote:
> Since
>
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Tested-by: Meelis Roos
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 988a3806512a..490d8b0d931e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_vga_switcheroo;
>
> - intel_power_domains_init_hw(dev_priv, false);
>
> intel_csr_ucode_init(dev_priv);
>
> @@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> intel_irq_init(dev_priv);
> intel_uncore_sanitize(dev);
> + intel_power_domains_init(dev_priv);
> + intel_power_domains_init_hw(dev_priv);
I think intel_init_dpio() needs to be moved too. We need to know the
DPIO IOSF ports before attempting to talk to the PHY (which can happen
from intel_power_domains_init_hw()).
I'm also wondering why we're doing gmbus init this early. We shouldn't
need it until modeset init.
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> @@ -1057,12 +1058,10 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> goto out_gem_unload;
> }
>
> - intel_power_domains_init(dev_priv);
> -
> ret = i915_load_modeset_init(dev);
> if (ret < 0) {
> DRM_ERROR("failed to init modeset\n");
> - goto out_power_well;
> + goto out_vblank;
> }
>
> /*
> @@ -1091,8 +1090,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> return 0;
>
> -out_power_well:
> - intel_power_domains_fini(dev_priv);
> +out_vblank:
> drm_vblank_cleanup(dev);
> out_gem_unload:
> WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
> @@ -1103,6 +1101,7 @@ out_gem_unload:
>
> intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
> + intel_power_domains_fini(dev_priv);
> pm_qos_remove_request(&dev_priv->pm_qos);
> destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
> out_freedpwq:
> --
> 2.6.4
--
Ville Syrjälä
Intel OTC
[PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä
wrote:
> On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote:
>> Since
>>
>> commit ac9b8236551d1177fd07b56aef9b565d1864420d
>> Author: Ville Syrjälä
>> Date: Fri Nov 27 18:55:26 2015 +0200
>>
>> drm/i915: Introduce a gmbus power domain
>>
>> gmbus also needs the power domain infrastructure right from the start,
>> since as soon as we register the i2c controllers someone can use them.
>>
>> v2: Adjust cleanup paths too (Chris).
>>
>> Cc: Ville Syrjälä
>> Cc: Patrik Jakobsson
>> Cc: Imre Deak
>> Cc: Jani Nikula
>> Cc: Meelis Roos
>> Cc: Chris Wilson
>> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
>> Cc: stable at vger.kernel.org
>> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
>> Tested-by: Meelis Roos
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_dma.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 988a3806512a..490d8b0d931e 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
>> if (ret)
>> goto cleanup_vga_switcheroo;
>>
>> - intel_power_domains_init_hw(dev_priv, false);
>>
>> intel_csr_ucode_init(dev_priv);
>>
>> @@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
>> long flags)
>>
>> intel_irq_init(dev_priv);
>> intel_uncore_sanitize(dev);
>> + intel_power_domains_init(dev_priv);
>> + intel_power_domains_init_hw(dev_priv);
>
> I think intel_init_dpio() needs to be moved too. We need to know the
> DPIO IOSF ports before attempting to talk to the PHY (which can happen
> from intel_power_domains_init_hw()).
Ugh, will change.
> I'm also wondering why we're doing gmbus init this early. We shouldn't
> need it until modeset init.
Anyone can access the gmbus controller once we register it. Userspace
can (like what seems to happen on Meelis' box), but also the i2c core
has some auto-probed stuff in some configs afaik.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/i915: Init power domains early in driver load
Since
commit ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).
Cc: Ville Syrjälä
Cc: Patrik Jakobsson
Cc: Imre Deak
Cc: Jani Nikula
Cc: Meelis Roos
Cc: Chris Wilson
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
Cc: stable at vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Tested-by: Meelis Roos
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 988a3806512a..fcefd3beef50 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_switcheroo;
- intel_power_domains_init_hw(dev_priv, false);
intel_csr_ucode_init(dev_priv);
@@ -1025,6 +1024,9 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
intel_irq_init(dev_priv);
intel_uncore_sanitize(dev);
+ intel_power_domains_init(dev_priv);
+ intel_init_dpio(dev_priv);
+ intel_power_domains_init_hw(dev_priv, false);
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev);
@@ -1049,20 +1051,16 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
intel_device_info_runtime_init(dev);
- intel_init_dpio(dev_priv);
-
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
goto out_gem_unload;
}
- intel_power_domains_init(dev_priv);
-
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
- goto out_power_well;
+ goto out_vblank;
}
/*
@@ -1091,8 +1089,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
return 0;
-out_power_well:
- intel_power_domains_fini(dev_priv);
+out_vblank:
drm_vblank_cleanup(dev);
out_gem_unload:
WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
@@ -1103,6 +1100,7 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
+ intel_power_domains_fini(dev_priv);
pm_qos_remove_request(&dev_priv->pm_qos);
destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
out_freedpwq:
--
2.6.4
[PATCH] MAINTAINERS: update for Freescale DCU DRM driver
Acked-by: Jianwei Wang On Thu, Jan 7, 2016 at 2:02 PM, Stefan Agner wrote: > Promote myself as new maintainer of the Freescale DCU DRM driver. > > Signed-off-by: Stefan Agner > --- > This has been previously discussed privately. The original driver > author and maintainer Jianwei does not work for Freescale anymore > and can not carve out spare time to maintain the driver. > > As I started to make use of the driver on the Freescale Vybrid SoC > and already posted several fixes and improvements, I am willing to > maintain the driver. > > Thanks Jianwei for your work on that driver! > > Dave, I hope you are OK with that? > > I plan to send a pull request with the patches which have been on the > ml lately, specifically the "Fix no fb check bug" and my fixes and > enhancements patchset, along with this maintainer change, does that > sound reasonable? > > There is one more pending patchset for this drivers, the TCON and > Vybrid support patchset, but this is probably not ready yet. I also > plan to post another patchset which enables multiple overlay planes > and a cursor plane. > > -- > Stefan > > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e9caa4b..3f0aea3 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3678,7 +3678,7 @@ F:include/drm/exynos* > F: include/uapi/drm/exynos* > > DRM DRIVERS FOR FREESCALE DCU > -M: Jianwei Wang > +M: Stefan Agner > M: Alison Wang > L: dri-devel at lists.freedesktop.org > S: Supported > -- > 2.6.4 >
[PATCH] drm/i915: Init power domains early in driver load
On Thu, 07 Jan 2016, Daniel Vetter wrote:
> On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä
> wrote:
>> On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote:
>>> Since
>>>
>>> commit ac9b8236551d1177fd07b56aef9b565d1864420d
>>> Author: Ville Syrjälä
>>> Date: Fri Nov 27 18:55:26 2015 +0200
>>>
>>> drm/i915: Introduce a gmbus power domain
>>>
>>> gmbus also needs the power domain infrastructure right from the start,
>>> since as soon as we register the i2c controllers someone can use them.
>>>
>>> v2: Adjust cleanup paths too (Chris).
>>>
>>> Cc: Ville Syrjälä
>>> Cc: Patrik Jakobsson
>>> Cc: Imre Deak
>>> Cc: Jani Nikula
>>> Cc: Meelis Roos
>>> Cc: Chris Wilson
>>> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
>>> Cc: stable at vger.kernel.org
>>> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
>>> Tested-by: Meelis Roos
>>> Signed-off-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/i915/i915_dma.c | 11 +--
>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>>> b/drivers/gpu/drm/i915/i915_dma.c
>>> index 988a3806512a..490d8b0d931e 100644
>>> --- a/drivers/gpu/drm/i915/i915_dma.c
>>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>>> @@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device
>>> *dev)
>>> if (ret)
>>> goto cleanup_vga_switcheroo;
>>>
>>> - intel_power_domains_init_hw(dev_priv, false);
>>>
>>> intel_csr_ucode_init(dev_priv);
>>>
>>> @@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
>>> long flags)
>>>
>>> intel_irq_init(dev_priv);
>>> intel_uncore_sanitize(dev);
>>> + intel_power_domains_init(dev_priv);
>>> + intel_power_domains_init_hw(dev_priv);
>>
>> I think intel_init_dpio() needs to be moved too. We need to know the
>> DPIO IOSF ports before attempting to talk to the PHY (which can happen
>> from intel_power_domains_init_hw()).
>
> Ugh, will change.
>
>> I'm also wondering why we're doing gmbus init this early. We shouldn't
>> need it until modeset init.
>
> Anyone can access the gmbus controller once we register it. Userspace
> can (like what seems to happen on Meelis' box), but also the i2c core
> has some auto-probed stuff in some configs afaik.
Ville's question was why we register the i2c adapters this early.
As I explained in [1], the auto-probing happens when there's an i2c
driver with matching class (I2C_CLASS_DDC). That's what happens on
Meelis' box. But yes, we need to take userspace into account as well.
In short, when we call intel_gmbus_setup(), we need to be ready for i2c
communication.
BR,
Jani.
[1] http://mid.gmane.org/87vb75znpz.fsf at intel.com
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 07, 2016 at 02:15:50PM +0100, Daniel Vetter wrote:
> On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä
> wrote:
> > On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote:
> >> Since
> >>
> >> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> >> Author: Ville Syrjälä
> >> Date: Fri Nov 27 18:55:26 2015 +0200
> >>
> >> drm/i915: Introduce a gmbus power domain
> >>
> >> gmbus also needs the power domain infrastructure right from the start,
> >> since as soon as we register the i2c controllers someone can use them.
> >>
> >> v2: Adjust cleanup paths too (Chris).
> >>
> >> Cc: Ville Syrjälä
> >> Cc: Patrik Jakobsson
> >> Cc: Imre Deak
> >> Cc: Jani Nikula
> >> Cc: Meelis Roos
> >> Cc: Chris Wilson
> >> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> >> Cc: stable at vger.kernel.org
> >> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> >> Tested-by: Meelis Roos
> >> Signed-off-by: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/i915/i915_dma.c | 11 +--
> >> 1 file changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> index 988a3806512a..490d8b0d931e 100644
> >> --- a/drivers/gpu/drm/i915/i915_dma.c
> >> +++ b/drivers/gpu/drm/i915/i915_dma.c
> >> @@ -398,7 +398,6 @@ static int i915_load_modeset_init(struct drm_device
> >> *dev)
> >> if (ret)
> >> goto cleanup_vga_switcheroo;
> >>
> >> - intel_power_domains_init_hw(dev_priv, false);
> >>
> >> intel_csr_ucode_init(dev_priv);
> >>
> >> @@ -1025,6 +1024,8 @@ int i915_driver_load(struct drm_device *dev,
> >> unsigned long flags)
> >>
> >> intel_irq_init(dev_priv);
> >> intel_uncore_sanitize(dev);
> >> + intel_power_domains_init(dev_priv);
> >> + intel_power_domains_init_hw(dev_priv);
> >
> > I think intel_init_dpio() needs to be moved too. We need to know the
> > DPIO IOSF ports before attempting to talk to the PHY (which can happen
> > from intel_power_domains_init_hw()).
>
> Ugh, will change.
I think I placed the dpio init in the current place so that it sits next
to intel_device_info_runtime_init(). Doing a lot of hw bashing before
all this runtime device info stuff has been set up seems rather wrong
to me.
>
> > I'm also wondering why we're doing gmbus init this early. We shouldn't
> > need it until modeset init.
>
> Anyone can access the gmbus controller once we register it. Userspace
> can (like what seems to happen on Meelis' box), but also the i2c core
> has some auto-probed stuff in some configs afaik.
Sure, but I don't see any reason why we'd need to init it that
early. The only requirement is that we need to init before we ourselves
use it, which I think means we don't actually need it until output setup.
And gmbus being a component of the display engine means the init should
really be part of the modeset init.
So I tend to think the better fix would be to move gmbus init to happen
later.
--
Ville Syrjälä
Intel OTC
[PATCH 0/5] sti fix to enable atomic modesetting
Those patches fix the issues found by using atomictest on sti driver. After testing we are confident to enable atomic modesetting so we decide to set DRIVER_ATOMIC flag. Benjamin Gaignard (4): drm: sti: fix potential crash in gdp drm: sti: add atomic get/set properties for planes drm: sti: set CRTC modesetting parameters drm: sti: set DRIVER_ATOMIC for sti Fabien Dessenne (1): drm: sti: fix cursor coordinates drivers/gpu/drm/sti/sti_crtc.c | 1 + drivers/gpu/drm/sti/sti_cursor.c | 2 +- drivers/gpu/drm/sti/sti_drv.c| 2 +- drivers/gpu/drm/sti/sti_gdp.c| 13 +++-- drivers/gpu/drm/sti/sti_plane.c | 40 5 files changed, 50 insertions(+), 8 deletions(-) -- 1.9.1
[PATCH 1/5] drm: sti: fix potential crash in gdp
In some cases last_close() could be called before sti_gdp_disable()
and make kernel crash because mixer structure has been destroy.
Let's gdp keep a reference on vtg to fix that (like it is already done
in HQVDP)
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_gdp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index f9a1d92..990b28e 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -97,6 +97,7 @@ struct sti_gdp_node_list {
* @vtg_field_nb: callback for VTG FIELD (top or bottom) notification
* @is_curr_top:true if the current node processed is the top field
* @node_list: array of node list
+ * @vtg:registered vtg
*/
struct sti_gdp {
struct sti_plane plane;
@@ -108,6 +109,7 @@ struct sti_gdp {
struct notifier_block vtg_field_nb;
bool is_curr_top;
struct sti_gdp_node_list node_list[GDP_NODE_NB_BANK];
+ struct sti_vtg *vtg;
};
#define to_sti_gdp(x) container_of(x, struct sti_gdp, plane)
@@ -240,9 +242,6 @@ end:
*/
static void sti_gdp_disable(struct sti_gdp *gdp)
{
- struct drm_plane *drm_plane = &gdp->plane.drm_plane;
- struct sti_mixer *mixer = to_sti_mixer(drm_plane->crtc);
- struct sti_compositor *compo = dev_get_drvdata(gdp->dev);
unsigned int i;
DRM_DEBUG_DRIVER("%s\n", sti_plane_to_str(&gdp->plane));
@@ -253,8 +252,7 @@ static void sti_gdp_disable(struct sti_gdp *gdp)
gdp->node_list[i].btm_field->gam_gdp_ppt |= GAM_GDP_PPT_IGNORE;
}
- if (sti_vtg_unregister_client(mixer->id == STI_MIXER_MAIN ?
- compo->vtg_main : compo->vtg_aux, &gdp->vtg_field_nb))
+ if (sti_vtg_unregister_client(gdp->vtg, &gdp->vtg_field_nb))
DRM_DEBUG_DRIVER("Warning: cannot unregister VTG notifier\n");
if (gdp->clk_pix)
@@ -490,7 +488,10 @@ static void sti_gdp_atomic_update(struct drm_plane
*drm_plane,
if (first_prepare) {
/* Register gdp callback */
- if (sti_vtg_register_client(mixer->id == STI_MIXER_MAIN ?
+ gdp->vtg = mixer->id == STI_MIXER_MAIN ?
+ compo->vtg_main : compo->vtg_aux;
+
+ if (sti_vtg_register_client(gdp->vtg == STI_MIXER_MAIN ?
compo->vtg_main : compo->vtg_aux,
&gdp->vtg_field_nb, crtc)) {
DRM_ERROR("Cannot register VTG notifier\n");
--
1.9.1
[PATCH 2/5] drm: sti: add atomic get/set properties for planes
Without those function zpos property isn't displayed in atomic mode.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_plane.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 2e5c751..e739c5a 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -69,6 +69,44 @@ static int sti_plane_set_property(struct drm_plane
*drm_plane,
return -EINVAL;
}
+static int sti_plane_atomic_set_property(struct drm_plane *drm_plane,
+struct drm_plane_state *state,
+struct drm_property *property,
+uint64_t val)
+{
+ struct drm_device *dev = drm_plane->dev;
+ struct sti_private *private = dev->dev_private;
+ struct sti_plane *plane = to_sti_plane(drm_plane);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ if (property == private->plane_zorder_property) {
+ plane->zorder = val;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int sti_plane_atomic_get_property(struct drm_plane *drm_plane,
+const struct drm_plane_state *state,
+struct drm_property *property,
+uint64_t *val)
+{
+ struct drm_device *dev = drm_plane->dev;
+ struct sti_private *private = dev->dev_private;
+ struct sti_plane *plane = to_sti_plane(drm_plane);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ if (property == private->plane_zorder_property) {
+ *val = plane->zorder;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
{
struct drm_device *dev = drm_plane->dev;
@@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .atomic_set_property = sti_plane_atomic_set_property,
+ .atomic_get_property = sti_plane_atomic_get_property,
};
--
1.9.1
[PATCH 3/5] drm: sti: set CRTC modesetting parameters
Set CRTC modesetting parameters to avoid warnings in atomic mode.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index de11c7c..505620c 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -56,6 +56,7 @@ static bool sti_crtc_mode_fixup(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode)
{
/* accept the provided drm_display_mode, do not fix it up */
+ drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
return true;
}
--
1.9.1
[PATCH 4/5] drm: sti: fix cursor coordinates
From: Fabien Dessenne x/y typo. Change-Id: I1ddc0a7e59090a10471db45d862e76756b967236 Signed-off-by: Fabien Dessenne Reviewed-on: https://gerrit.st.com/47166 Reviewed-by: Denis HUMEAU Tested-by: Denis HUMEAU Reviewed-by: Romuald JEANNE --- drivers/gpu/drm/sti/sti_cursor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c index 8078631..a19693a 100644 --- a/drivers/gpu/drm/sti/sti_cursor.c +++ b/drivers/gpu/drm/sti/sti_cursor.c @@ -205,7 +205,7 @@ static void sti_cursor_atomic_update(struct drm_plane *drm_plane, writel(cursor->height << 16 | cursor->width, cursor->regs + CUR_SIZE); y = sti_vtg_get_line_number(*mode, dst_y); - x = sti_vtg_get_pixel_number(*mode, dst_y); + x = sti_vtg_get_pixel_number(*mode, dst_x); writel((y << 16) | x, cursor->regs + CUR_VPO); plane->status = STI_PLANE_UPDATED; -- 1.9.1
[PATCH 5/5] drm: sti: set DRIVER_ATOMIC for sti
sti now support of atomic modesetting so set the flag to enable it.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 1469987..a6f9ff2 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -191,7 +191,7 @@ static struct dma_buf *sti_gem_prime_export(struct
drm_device *dev,
static struct drm_driver sti_driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
- DRIVER_GEM | DRIVER_PRIME,
+ DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
.load = sti_load,
.gem_free_object = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
--
1.9.1
[PATCH 2/5] drm: sti: add atomic get/set properties for planes
On Thu, Jan 07, 2016 at 02:30:38PM +0100, Benjamin Gaignard wrote:
> Without those function zpos property isn't displayed in atomic mode.
>
> Signed-off-by: Benjamin Gaignard
Oh, another iteration of a driver-private zpos property. This _really_
should be generic, with some consistent cross-driver semantics. Marek from
samsung has started with a patch series for that.
Can you please work together with him, and rebase the sti zpos support on
top of his work? And hold of this patch for now meanwhile?
Also adding Marek.
Thanks, Daniel
> ---
> drivers/gpu/drm/sti/sti_plane.c | 40
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
> index 2e5c751..e739c5a 100644
> --- a/drivers/gpu/drm/sti/sti_plane.c
> +++ b/drivers/gpu/drm/sti/sti_plane.c
> @@ -69,6 +69,44 @@ static int sti_plane_set_property(struct drm_plane
> *drm_plane,
> return -EINVAL;
> }
>
> +static int sti_plane_atomic_set_property(struct drm_plane *drm_plane,
> + struct drm_plane_state *state,
> + struct drm_property *property,
> + uint64_t val)
> +{
> + struct drm_device *dev = drm_plane->dev;
> + struct sti_private *private = dev->dev_private;
> + struct sti_plane *plane = to_sti_plane(drm_plane);
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + if (property == private->plane_zorder_property) {
> + plane->zorder = val;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int sti_plane_atomic_get_property(struct drm_plane *drm_plane,
> + const struct drm_plane_state *state,
> + struct drm_property *property,
> + uint64_t *val)
> +{
> + struct drm_device *dev = drm_plane->dev;
> + struct sti_private *private = dev->dev_private;
> + struct sti_plane *plane = to_sti_plane(drm_plane);
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + if (property == private->plane_zorder_property) {
> + *val = plane->zorder;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
> {
> struct drm_device *dev = drm_plane->dev;
> @@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs = {
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .atomic_set_property = sti_plane_atomic_set_property,
> + .atomic_get_property = sti_plane_atomic_get_property,
> };
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/i915: Init power domains early in driver load
Since
commit ac9b8236551d1177fd07b56aef9b565d1864420d
Author: Ville Syrjälä
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).
v4: Ville instead suggested to move gmbus setup later in the sequence,
since it's only needed by the modeset code.
v5: Move even close to the actual user, right next to the comment that
states where we really need gmbus (and interrupts!).
Cc: Ville Syrjälä
Cc: Patrik Jakobsson
Cc: Imre Deak
Cc: Jani Nikula
Cc: Meelis Roos
Cc: Chris Wilson
Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
Cc: stable at vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Signed-off-by: Daniel Vetter
---
Meelis, can you pls retest this one?
Thanks, Daniel
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 988a3806512a..d70d96fe553b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -406,6 +406,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_gem_stolen;
+ intel_setup_gmbus(dev);
+
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
@@ -455,6 +457,7 @@ cleanup_gem:
cleanup_irq:
intel_guc_ucode_fini(dev);
drm_irq_uninstall(dev);
+ intel_teardown_gmbus(dev);
cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
cleanup_vga_switcheroo:
@@ -1028,7 +1031,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev);
- intel_setup_gmbus(dev);
intel_opregion_setup(dev);
i915_gem_load(dev);
@@ -1101,7 +1103,6 @@ out_gem_unload:
if (dev->pdev->msi_enabled)
pci_disable_msi(dev->pdev);
- intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
pm_qos_remove_request(&dev_priv->pm_qos);
destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
@@ -1203,7 +1204,6 @@ int i915_driver_unload(struct drm_device *dev)
intel_csr_ucode_fini(dev_priv);
- intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv->hotplug.dp_wq);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 37945ddb4dad..ac0038bf4fbf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15971,6 +15971,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
mutex_lock(&dev->struct_mutex);
intel_cleanup_gt_powersave(dev);
mutex_unlock(&dev->struct_mutex);
+
+ intel_teardown_gmbus(dev);
}
/*
--
2.6.4
[PATCH 4/5] drm: sti: fix cursor coordinates
fix x/y typo while setting cursor coordinates Signed-off-by: Fabien Dessenne --- drivers/gpu/drm/sti/sti_cursor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c index 8078631..a19693a 100644 --- a/drivers/gpu/drm/sti/sti_cursor.c +++ b/drivers/gpu/drm/sti/sti_cursor.c @@ -205,7 +205,7 @@ static void sti_cursor_atomic_update(struct drm_plane *drm_plane, writel(cursor->height << 16 | cursor->width, cursor->regs + CUR_SIZE); y = sti_vtg_get_line_number(*mode, dst_y); - x = sti_vtg_get_pixel_number(*mode, dst_y); + x = sti_vtg_get_pixel_number(*mode, dst_x); writel((y << 16) | x, cursor->regs + CUR_VPO); plane->status = STI_PLANE_UPDATED; -- 1.9.1
[PATCH 3/5] drm: sti: set CRTC modesetting parameters
On Thu, Jan 07, 2016 at 02:30:39PM +0100, Benjamin Gaignard wrote:
> Set CRTC modesetting parameters to avoid warnings in atomic mode.
Hm, should we extend the documentation for the mode_fixup hooks that this
should be done? Care to submit a patch against drm-misc/linux-next (since
there's more doc work queued in there)?
Thanks, Daniel
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/sti/sti_crtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index de11c7c..505620c 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -56,6 +56,7 @@ static bool sti_crtc_mode_fixup(struct drm_crtc *crtc,
> struct drm_display_mode *adjusted_mode)
> {
> /* accept the provided drm_display_mode, do not fix it up */
> + drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
> return true;
> }
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/5] drm: sti: add atomic get/set properties for planes
zpos property isn't new in sti driver only the atomic set/get functions are
new.
Without those functions atomictest failed to discover any of the other
atomic planes properties.
I agree with you, zpos should be generic and I could work with Marek for
that
but if this patch isn't merge sti atomic modesetting support will be
limited to primary planes...
Benjamin
2016-01-07 14:50 GMT+01:00 Daniel Vetter :
> On Thu, Jan 07, 2016 at 02:30:38PM +0100, Benjamin Gaignard wrote:
> > Without those function zpos property isn't displayed in atomic mode.
> >
> > Signed-off-by: Benjamin Gaignard
>
> Oh, another iteration of a driver-private zpos property. This _really_
> should be generic, with some consistent cross-driver semantics. Marek from
> samsung has started with a patch series for that.
>
> Can you please work together with him, and rebase the sti zpos support on
> top of his work? And hold of this patch for now meanwhile?
>
> Also adding Marek.
>
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/sti/sti_plane.c | 40
>
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sti/sti_plane.c
> b/drivers/gpu/drm/sti/sti_plane.c
> > index 2e5c751..e739c5a 100644
> > --- a/drivers/gpu/drm/sti/sti_plane.c
> > +++ b/drivers/gpu/drm/sti/sti_plane.c
> > @@ -69,6 +69,44 @@ static int sti_plane_set_property(struct drm_plane
> *drm_plane,
> > return -EINVAL;
> > }
> >
> > +static int sti_plane_atomic_set_property(struct drm_plane *drm_plane,
> > + struct drm_plane_state *state,
> > + struct drm_property *property,
> > + uint64_t val)
> > +{
> > + struct drm_device *dev = drm_plane->dev;
> > + struct sti_private *private = dev->dev_private;
> > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > +
> > + DRM_DEBUG_DRIVER("\n");
> > +
> > + if (property == private->plane_zorder_property) {
> > + plane->zorder = val;
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +static int sti_plane_atomic_get_property(struct drm_plane *drm_plane,
> > + const struct drm_plane_state
> *state,
> > + struct drm_property *property,
> > + uint64_t *val)
> > +{
> > + struct drm_device *dev = drm_plane->dev;
> > + struct sti_private *private = dev->dev_private;
> > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > +
> > + DRM_DEBUG_DRIVER("\n");
> > +
> > + if (property == private->plane_zorder_property) {
> > + *val = plane->zorder;
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > static void sti_plane_attach_zorder_property(struct drm_plane
> *drm_plane)
> > {
> > struct drm_device *dev = drm_plane->dev;
> > @@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs = {
> > .reset = drm_atomic_helper_plane_reset,
> > .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > + .atomic_set_property = sti_plane_atomic_set_property,
> > + .atomic_get_property = sti_plane_atomic_get_property,
> > };
> > --
> > 1.9.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org <http://www.linaro.org/> *â *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/3abdde43/attachment-0001.html>
[PATCH] drm/i915: Init power domains early in driver load
On Thu, Jan 07, 2016 at 02:51:05PM +0100, Daniel Vetter wrote:
> Since
>
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> v3: Rebase onto -nightly (totally bogus tree I had lying around) and
> also move dpio init head (Ville).
>
> v4: Ville instead suggested to move gmbus setup later in the sequence,
> since it's only needed by the modeset code.
>
> v5: Move even close to the actual user, right next to the comment that
> states where we really need gmbus (and interrupts!).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Signed-off-by: Daniel Vetter
> ---
>
> Meelis, can you pls retest this one?
>
> Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_dma.c | 6 +++---
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 988a3806512a..d70d96fe553b 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -406,6 +406,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_gem_stolen;
>
> + intel_setup_gmbus(dev);
> +
> /* Important: The output setup functions called by modeset_init need
>* working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
> @@ -455,6 +457,7 @@ cleanup_gem:
> cleanup_irq:
> intel_guc_ucode_fini(dev);
> drm_irq_uninstall(dev);
> + intel_teardown_gmbus(dev);
> cleanup_gem_stolen:
> i915_gem_cleanup_stolen(dev);
> cleanup_vga_switcheroo:
> @@ -1028,7 +1031,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> - intel_setup_gmbus(dev);
> intel_opregion_setup(dev);
>
> i915_gem_load(dev);
> @@ -1101,7 +1103,6 @@ out_gem_unload:
> if (dev->pdev->msi_enabled)
> pci_disable_msi(dev->pdev);
>
> - intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
> pm_qos_remove_request(&dev_priv->pm_qos);
> destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
> @@ -1203,7 +1204,6 @@ int i915_driver_unload(struct drm_device *dev)
>
> intel_csr_ucode_fini(dev_priv);
>
> - intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
>
> destroy_workqueue(dev_priv->hotplug.dp_wq);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 37945ddb4dad..ac0038bf4fbf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15971,6 +15971,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
> mutex_lock(&dev->struct_mutex);
> intel_cleanup_gt_powersave(dev);
> mutex_unlock(&dev->struct_mutex);
> +
> + intel_teardown_gmbus(dev);
The cleanup path is where things might still be a bit wonky. Should we be
doing this before turning off the interrupts? But then that might mean
that the hpd cleanup needs to be rehashed somewhat to make sure we shut
down hpd before unregistering gmbus. The whole init/cleanup sequence is
a bit of a mess tbh, so a major overhaul might be required to make it
actually sane.
In any case, I'm thinking this is at least no worse that what we had, so
Reviewed-by: Ville Syrjälä
> }
>
> /*
> --
> 2.6.4
--
Ville Syrjälä
Intel OTC
[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain
On 10 November 2015 at 10:33, Daniel Kurtz wrote: [snip] > > The problem appears to be that: > * On boot, platform_drv_probe() calls dev_pm_domain_attach() before > drv->probe(); thus, it calls dev_pm_domain_attach() while the device > is unbound. > > * However, for a platform_device, the reboot path calls > device_shutdown(), but not __device_release_driver(): > device_shutdown() > dev->driver->shutdown => platform_drv_shutdown() > dev_pm_domain_detach() >dev->pm_domain->detach() => genpd_dev_pm_detach() > pm_genpd_remove_device() > dev_pm_domain_set(dev, NULL); > > So, for a platform_device in a genpd power domain with .shutdown > installed, platform_drv_shutdown() calls dev_pm_domain_detach() while > the device is still bound, which triggers the WARN(). Hi Rafael, Alan and Ulf, do you have any suggestion about this? I don't really understand why the device is detached from the domain on shutdown. Thanks, Tomeu > Thanks, > -Dan > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: sti: add atomic get/set properties for planes
On Thu, Jan 07, 2016 at 03:05:02PM +0100, Benjamin Gaignard wrote:
> zpos property isn't new in sti driver only the atomic set/get functions are
> new.
> Without those functions atomictest failed to discover any of the other
> atomic planes properties.
>
> I agree with you, zpos should be generic and I could work with Marek for
> that
> but if this patch isn't merge sti atomic modesetting support will be
> limited to primary planes...
These two hooks should be optional. The only downside of not adding them
is that zpos property can't be read, everything else should still work ...
And yeah everyone added zpos without a hole lot of thought about
cross-driver consistency, which is not great. Now everyone gets to clean
things up again I'd say.
-Daniel
>
> Benjamin
>
>
> 2016-01-07 14:50 GMT+01:00 Daniel Vetter :
>
> > On Thu, Jan 07, 2016 at 02:30:38PM +0100, Benjamin Gaignard wrote:
> > > Without those function zpos property isn't displayed in atomic mode.
> > >
> > > Signed-off-by: Benjamin Gaignard
> >
> > Oh, another iteration of a driver-private zpos property. This _really_
> > should be generic, with some consistent cross-driver semantics. Marek from
> > samsung has started with a patch series for that.
> >
> > Can you please work together with him, and rebase the sti zpos support on
> > top of his work? And hold of this patch for now meanwhile?
> >
> > Also adding Marek.
> >
> > Thanks, Daniel
> >
> > > ---
> > > drivers/gpu/drm/sti/sti_plane.c | 40
> >
> > > 1 file changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sti/sti_plane.c
> > b/drivers/gpu/drm/sti/sti_plane.c
> > > index 2e5c751..e739c5a 100644
> > > --- a/drivers/gpu/drm/sti/sti_plane.c
> > > +++ b/drivers/gpu/drm/sti/sti_plane.c
> > > @@ -69,6 +69,44 @@ static int sti_plane_set_property(struct drm_plane
> > *drm_plane,
> > > return -EINVAL;
> > > }
> > >
> > > +static int sti_plane_atomic_set_property(struct drm_plane *drm_plane,
> > > + struct drm_plane_state *state,
> > > + struct drm_property *property,
> > > + uint64_t val)
> > > +{
> > > + struct drm_device *dev = drm_plane->dev;
> > > + struct sti_private *private = dev->dev_private;
> > > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > > +
> > > + DRM_DEBUG_DRIVER("\n");
> > > +
> > > + if (property == private->plane_zorder_property) {
> > > + plane->zorder = val;
> > > + return 0;
> > > + }
> > > +
> > > + return -EINVAL;
> > > +}
> > > +
> > > +static int sti_plane_atomic_get_property(struct drm_plane *drm_plane,
> > > + const struct drm_plane_state
> > *state,
> > > + struct drm_property *property,
> > > + uint64_t *val)
> > > +{
> > > + struct drm_device *dev = drm_plane->dev;
> > > + struct sti_private *private = dev->dev_private;
> > > + struct sti_plane *plane = to_sti_plane(drm_plane);
> > > +
> > > + DRM_DEBUG_DRIVER("\n");
> > > +
> > > + if (property == private->plane_zorder_property) {
> > > + *val = plane->zorder;
> > > + return 0;
> > > + }
> > > +
> > > + return -EINVAL;
> > > +}
> > > +
> > > static void sti_plane_attach_zorder_property(struct drm_plane
> > *drm_plane)
> > > {
> > > struct drm_device *dev = drm_plane->dev;
> > > @@ -116,4 +154,6 @@ struct drm_plane_funcs sti_plane_helpers_funcs = {
> > > .reset = drm_atomic_helper_plane_reset,
> > > .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > + .atomic_set_property = sti_plane_atomic_set_property,
> > > + .atomic_get_property = sti_plane_atomic_get_property,
> > > };
> > > --
> > > 1.9.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
>
>
>
> --
>
> Benjamin Gaignard
>
> Graphic Working Group
>
> Linaro.org | Twitter
> | Blog
>
[PATCH v3] drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
This fixes reprobing of display connectors on resume. After some
talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on
resume hasn't been working (this was observed on a T440s):
- We call hpd_init()
- We check each connector for a couple of things before marking
connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
active encoder. Of course, a disconnected port won't have an
active encoder, so we don't add the flag to any of the
connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
so we skip reprobing each connector except that one.
In addition, we also now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
handled by the mst helpers. This is probably what was originally
intended to happen here.
Changes since V1:
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a
check for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
Changes since V2:
* Put patch changelog above Signed-off-by
* Follow Daniel Vetter's suggestion for making the code here a bit more
legible
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: stable at vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_hotplug.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index b177857..d7a6437 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -468,9 +468,14 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
list_for_each_entry(connector, &mode_config->connector_list, head) {
struct intel_connector *intel_connector =
to_intel_connector(connector);
connector->polled = intel_connector->polled;
- if (connector->encoder && !connector->polled &&
I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
- connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+ /* MST has a dynamic intel_connector->encoder and it's reprobing
+* is all handled by the MST helpers. */
if (intel_connector->mst_port)
+ continue;
+
+ if (!connector->polled && I915_HAS_HOTPLUG(dev) &&
+ intel_connector->encoder->hpd_pin > HPD_NONE)
connector->polled = DRM_CONNECTOR_POLL_HPD;
}
--
2.5.0
[PATCH v12 0/4] Allow USB devices to remain runtime-suspended when sleeping
Hi, this is v12 of an attempt to make it easier for devices to remain in runtime PM when the system goes to sleep, mainly to reduce the time spent resuming devices. For this, we interpret the absence of all PM callback implementations as it being safe to do direct_complete, so their ancestors aren't prevented from remaining runtime-suspended. Additionally, the prepare() callback of USB devices will return 1 if runtime PM is enabled and the current wakeup settings are correct. With these changes, a uvcvideo device (for example) stays in runtime suspend when the system goes to sleep and is left in that state when the system resumes, not delaying it unnecessarily. Thanks, Tomeu Changes in v12: - Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set() Changes in v11: - Move calls to dev_pm_domain_set() out from &dev->power.lock as that isn't needed for dev->pm_domain. Changes in v10: - Remove superfluous call to pm_runtime_enabled() as suggested by Alan Changes in v9: - Add docs noting the need for the device lock to be held before calling device_is_bound() - Add docs noting the need for the device lock to be held before calling dev_pm_domain_set() - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. - Rename from device_check_pm_callbacks to device_pm_check_callbacks to follow with the naming convention of existing API. - Re-add calling to device_pm_check_callbacks from device registration and when updating the PM domain of a device. Changes in v8: - Add device_is_bound() - Add dev_pm_domain_set() and update code to use it - Move no_pm_callbacks field into CONFIG_PM_SLEEP - Call device_check_pm_callbacks only after a device is bound or unbound Changes in v7: - Reduce indentation by adding a label in device_prepare() Changes in v6: - Add stub for !CONFIG_PM. - Move implementation of device_check_pm_callbacks to power/main.c as it doesn't belong to CONFIG_PM_SLEEP. - Take dev->power.lock before modifying flag. Changes in v5: - Check for all dev_pm_ops instances associated to a device, updating a no_pm_callbacks flag at the times when that could change. Tomeu Vizoso (4): device core: add device_is_bound() PM / Domains: add setter for dev.pm_domain PM / sleep: Go direct_complete if driver has no callbacks USB / PM: Allow USB devices to remain runtime-suspended when sleeping arch/arm/mach-omap2/omap_device.c | 7 --- drivers/acpi/acpi_lpss.c | 5 - drivers/acpi/device_pm.c | 5 +++-- drivers/base/dd.c | 21 +++-- drivers/base/power/clock_ops.c| 5 +++-- drivers/base/power/common.c | 24 drivers/base/power/domain.c | 8 ++-- drivers/base/power/main.c | 35 +++ drivers/base/power/power.h| 3 +++ drivers/gpu/vga/vga_switcheroo.c | 11 ++- drivers/misc/mei/pci-me.c | 5 +++-- drivers/misc/mei/pci-txe.c| 5 +++-- drivers/usb/core/port.c | 6 ++ drivers/usb/core/usb.c| 8 +++- include/linux/device.h| 2 ++ include/linux/pm.h| 1 + include/linux/pm_domain.h | 3 +++ 17 files changed, 132 insertions(+), 22 deletions(-) -- 2.5.0
[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Ulf Hansson
---
Changes in v12:
- Include linux/pm_domain.h in vga_switcheroo.c for dev_pm_domain_set()
Changes in v11:
- Move calls to dev_pm_domain_set() out from &dev->power.lock as that
isn't needed for dev->pm_domain.
Changes in v9:
- Add docs noting the need for the device lock to be held before calling
dev_pm_domain_set()
Changes in v8:
- Add dev_pm_domain_set() and update code to use it
arch/arm/mach-omap2/omap_device.c | 7 ---
drivers/acpi/acpi_lpss.c | 5 -
drivers/acpi/device_pm.c | 5 +++--
drivers/base/power/clock_ops.c| 5 +++--
drivers/base/power/common.c | 21 +
drivers/base/power/domain.c | 6 --
drivers/gpu/vga/vga_switcheroo.c | 11 ++-
drivers/misc/mei/pci-me.c | 5 +++--
drivers/misc/mei/pci-txe.c| 5 +++--
include/linux/pm_domain.h | 3 +++
10 files changed, 54 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 3750ed14f8c5..0437537751bc 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r->name = dev_name(&pdev->dev);
}
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
- pdev->dev.pm_domain = &omap_device_fail_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_fail_pm_domain);
return ret;
}
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
{
pr_debug("omap_device: %s: registering\n", pdev->name);
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
return platform_device_add(pdev);
}
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 047281a6ae11..c570b1d9f094 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -875,13 +876,14 @@ static int acpi_lpss_platform_notify(struct
notifier_block *nb,
switch (action) {
case BUS_NOTIFY_BIND_DRIVER:
- pdev->dev.pm_domain = &acpi_lpss_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
break;
case BUS_NOTIFY_DRIVER_NOT_BOUND:
case BUS_NOTIFY_UNBOUND_DRIVER:
pdev->dev.pm_domain = NULL;
break;
case BUS_NOTIFY_ADD_DEVICE:
+ dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
@@ -889,6 +891,7 @@ static int acpi_lpss_platform_notify(struct notifier_block
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
+ dev_pm_domain_set(&pdev->dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 08a02cdc737c..cd2c3d6d40e0 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -1059,7 +1060,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);
if (adev && dev->pm_domain == &acpi_general_pm_domain) {
- dev->pm_domain = NULL;
+ dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -,7 +1112,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
- dev->pm_domain = &acpi_general_pm_domain;
+ dev_pm_domain_set(dev, &acpi_general_pm_domain);
if (power_on) {
acpi_dev_pm_fu
[PATCH] drm/i915: Init power domains early in driver load
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> v3: Rebase onto -nightly (totally bogus tree I had lying around) and
> also move dpio init head (Ville).
>
> v4: Ville instead suggested to move gmbus setup later in the sequence,
> since it's only needed by the modeset code.
>
> v5: Move even close to the actual user, right next to the comment that
> states where we really need gmbus (and interrupts!).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Signed-off-by: Daniel Vetter
> ---
>
> Meelis, can you pls retest this one?
Tested successfully on SNB computer.
>
> Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_dma.c | 6 +++---
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 988a3806512a..d70d96fe553b 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -406,6 +406,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_gem_stolen;
>
> + intel_setup_gmbus(dev);
> +
> /* Important: The output setup functions called by modeset_init need
>* working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
> @@ -455,6 +457,7 @@ cleanup_gem:
> cleanup_irq:
> intel_guc_ucode_fini(dev);
> drm_irq_uninstall(dev);
> + intel_teardown_gmbus(dev);
> cleanup_gem_stolen:
> i915_gem_cleanup_stolen(dev);
> cleanup_vga_switcheroo:
> @@ -1028,7 +1031,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
>
> /* Try to make sure MCHBAR is enabled before poking at it */
> intel_setup_mchbar(dev);
> - intel_setup_gmbus(dev);
> intel_opregion_setup(dev);
>
> i915_gem_load(dev);
> @@ -1101,7 +1103,6 @@ out_gem_unload:
> if (dev->pdev->msi_enabled)
> pci_disable_msi(dev->pdev);
>
> - intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
> pm_qos_remove_request(&dev_priv->pm_qos);
> destroy_workqueue(dev_priv->gpu_error.hangcheck_wq);
> @@ -1203,7 +1204,6 @@ int i915_driver_unload(struct drm_device *dev)
>
> intel_csr_ucode_fini(dev_priv);
>
> - intel_teardown_gmbus(dev);
> intel_teardown_mchbar(dev);
>
> destroy_workqueue(dev_priv->hotplug.dp_wq);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 37945ddb4dad..ac0038bf4fbf 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15971,6 +15971,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
> mutex_lock(&dev->struct_mutex);
> intel_cleanup_gt_powersave(dev);
> mutex_unlock(&dev->struct_mutex);
> +
> + intel_teardown_gmbus(dev);
> }
>
> /*
>
--
Meelis Roos (mroos at ut.ee) http://www.cs.ut.ee/~mroos/
[Intel-gfx] [PATCH v3] drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
On Thu, Jan 07, 2016 at 10:43:28AM -0500, Lyude wrote:
> This fixes reprobing of display connectors on resume. After some
> talking with danvet on IRC, I learned that calling
> drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
> connector's status. It turns out this is the actual reason reprobing on
> resume hasn't been working (this was observed on a T440s):
>
> - We call hpd_init()
> - We check each connector for a couple of things before marking
> connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
> active encoder. Of course, a disconnected port won't have an
> active encoder, so we don't add the flag to any of the
> connectors.
> - We call drm_helper_hpd_irq_event()
> - drm_helper_irq_event() checks each connector for the
> DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
> so we skip reprobing each connector except that one.
>
> In addition, we also now avoid setting connector->polled to
> DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is
> handled by the mst helpers. This is probably what was originally
> intended to happen here.
>
> Changes since V1:
> * Use the explanation of the issue as the commit message instead
> * Change the title of the commit, since this does more then just stop a
> check for an encoder now
> * Add "Fixes" line for the patch that introduced this regression
> * Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors
>
> Changes since V2:
> * Put patch changelog above Signed-off-by
> * Follow Daniel Vetter's suggestion for making the code here a bit more
> legible
>
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: stable at vger.kernel.org
> Signed-off-by: Lyude
Awesome, and merged to drm-intel.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_hotplug.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index b177857..d7a6437 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -468,9 +468,14 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
> list_for_each_entry(connector, &mode_config->connector_list, head) {
> struct intel_connector *intel_connector =
> to_intel_connector(connector);
> connector->polled = intel_connector->polled;
> - if (connector->encoder && !connector->polled &&
> I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
> - connector->polled = DRM_CONNECTOR_POLL_HPD;
> +
> + /* MST has a dynamic intel_connector->encoder and it's reprobing
> + * is all handled by the MST helpers. */
> if (intel_connector->mst_port)
> + continue;
> +
> + if (!connector->polled && I915_HAS_HOTPLUG(dev) &&
> + intel_connector->encoder->hpd_pin > HPD_NONE)
> connector->polled = DRM_CONNECTOR_POLL_HPD;
> }
>
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[GIT PULL] drm-etnaviv-fixes for current -next
Hi Dave, 2 small fixes for the etnaviv driver, both noticed by the smatch checker and reported/fixed by Dan Carpenter. Regards, Lucas The following changes since commit c11b8989635166c5a1e6aac1853a847bd664f8db: Merge tag 'omapdrm-4.5-resolved' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next (2016-01-01 07:41:52 +1000) are available in the git repository at: git://git.pengutronix.de/git/lst/linux.git drm-etnaviv-fixes for you to fetch changes up to c33246d793b5bb9d8be7c67918136c310185c23d: drm/etnaviv: fix workaround for GC500 (2016-01-07 11:57:57 +0100) Dan Carpenter (1): drm/etnaviv: unlock on error in etnaviv_gem_get_iova() Lucas Stach (1): drm/etnaviv: fix workaround for GC500 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 6 -- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +-- 2 files changed, 9 insertions(+), 4 deletions(-)
[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support
Hi Yakir, Am Donnerstag, den 07.01.2016, 18:15 +0800 schrieb Yakir Yang: > Hi Philipp, > > Thanks for your fast respond :) > > On 01/07/2016 06:04 PM, Philipp Zabel wrote: > > Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang: > >> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 > >> phy, > >> the max output resolution is 4K. > >> > >> Signed-off-by: Yakir Yang > > It sounds like the INNO HDMI2.0 phy is not necessarily specific to > > RK3229 but might also appear in other SoCs? If so, I think this should > > be implemented in a separate phy driver and be used by dw_hdmi-rockchip. > > Do you mean I should create a new phy driver that place in "driver/phy" > directly ? Possibly, yes. The exynos video phys are already there. I have kept the mediatek dsi/hdmi phys together with the DRM driver, but I suppose I could move them there, too. > I have think about this idea, and it would make things much clean. But > INNO PHY > driver need the target pixel clock in drm_display_mode, I didn't find a > good way > to pass this variable to separate phy driver. Do you have some idea ? We'd need to extend the PHY API for this. For the mediatek phys we have side-stepped the issue by wiring up the PLL output to the common clock framework. I expect besides the pixel clock frequency, it might also be necessary to inform the PHY about cycles per pixel for deep color modes. regards Philipp
DRM support in Android
On Tue, Jan 5, 2016 at 12:06 AM, vijay kumar wrote: > Hii all, > I want to know some information regarding DRI and DRM > support in android.Does Android uses DRI drivers in MESA for Direct > rendering. > The vendor needs to supply an EGL implementation at a well-known path ( https://android.googlesource.com/platform/frameworks/native/+/android-6.0.1_r5/opengl/libs/EGL/Loader.cpp#41). This can be Mesa or a proprietary library. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/f242d5de/attachment.html>
[PATCH libdrm] Fix memory leak with drmModeGetConnectorCurrent()
On Tue, Dec 15, 2015 at 02:05:45PM +, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 03:59:28PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > drmModeGetConnectorCurrent() must provide temporary storage for the
> > kernel to fill in at least one mode (asking for !=0 modes is how
> > you prevent the heavyweight probe in the kernel). Currently we malloc
> > that temp storage but we fail to free it before overwriting the
> > pointer with the address of the actual storage we use to store the
> > real mode list we get from the kernel in the second ioctl call.
> >
> > Let's just keep the temporary storage on the stack and thus we avoid the
> > leak and also eliminate some pointless mallocs.
> >
> > Cc: Chris Wilson
> > Fixes: 5ed5fa10600f ("mode: Retrieve only the current information for a
> > Connector")
> > Signed-off-by: Ville Syrjälä
> > ---
> > xf86drmMode.c | 11 +++
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/xf86drmMode.c b/xf86drmMode.c
> > index ab6b5195e8d3..7710061865ee 100644
> > --- a/xf86drmMode.c
> > +++ b/xf86drmMode.c
> > @@ -475,12 +475,13 @@ _drmModeGetConnector(int fd, uint32_t connector_id,
> > int probe)
> > {
> > struct drm_mode_get_connector conn, counts;
> > drmModeConnectorPtr r = NULL;
> > + struct drm_mode_modeinfo stack_mode;
> >
> > memclear(conn);
> > conn.connector_id = connector_id;
> > if (!probe) {
> > conn.count_modes = 1;
> > - conn.modes_ptr = VOID2U64(drmMalloc(sizeof(struct
> > drm_mode_modeinfo)));
> > + conn.modes_ptr = VOID2U64(&stack_mode);
> > }
>
> If you just made this change, we wouldn't need the hunks below (and I
> wouln't have to look at so much shouting).
>
> Either way,
> Reviewed-by: Chris Wilson
Pushed to master. Thanks for the review.
--
Ville Syrjälä
Intel OTC
[PATCH] x86: Add an explicit barrier() to clflushopt()
On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson wrote: > On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: >> During testing we observed that the last cacheline was not being flushed >> from a >> >> mb() >> for (addr = addr & -clflush_size; addr < end; addr += clflush_size) >> clflushopt(); >> mb() >> >> loop (where the initial addr and end were not cacheline aligned). >> >> Changing the loop from addr < end to addr <= end, or replacing the >> clflushopt() with clflush() both fixed the testcase. Hinting that GCC >> was miscompling the assembly within the loop and specifically the >> alternative within clflushopt() was confusing the loop optimizer. >> >> Adding a barrier() into clflushopt() is enough for GCC to dtrt, but >> solving why GCC is not seeing the constraints from the alternative_io() >> would be smarter... >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92501 >> Testcase: gem_tiled_partial_pwrite_pread/read >> Signed-off-by: Chris Wilson >> Cc: Ross Zwisler >> Cc: H. Peter Anvin >> Cc: Imre Deak >> Cc: Daniel Vetter >> Cc: dri-devel at lists.freedesktop.org >> --- >> arch/x86/include/asm/special_insns.h | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/x86/include/asm/special_insns.h >> b/arch/x86/include/asm/special_insns.h >> index 2270e41b32fd..0c7aedbf8930 100644 >> --- a/arch/x86/include/asm/special_insns.h >> +++ b/arch/x86/include/asm/special_insns.h >> @@ -199,6 +199,11 @@ static inline void clflushopt(volatile void *__p) >> ".byte 0x66; clflush %P0", >> X86_FEATURE_CLFLUSHOPT, >> "+m" (*(volatile char __force *)__p)); >> + /* GCC (4.9.1 and 5.2.1 at least) appears to be very confused when >> + * meeting this alternative() and demonstrably miscompiles loops >> + * iterating over clflushopts. >> + */ >> + barrier(); >> } > > Or an alternative: > > +#define alternative_output(oldinstr, newinstr, feature, output)\ > + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ > + : output : "i" (0) : "memory") > > I would really appreciate some knowledgeable folks taking a look at the > asm for clflushopt() as it still affects today's kernel and gcc. > > Fwiw, I have confirmed that arch/x86/mm/pageattr.c clflush_cache_range() > is similarly affected. Unless I'm mis-reading the asm, clflush_cache_range() is compiled correctly for me. (I don't know what the %P is for in the asm, but that shouldn't matter.) The ALTERNATIVE shouldn't even be visible to the optimizer. Can you attach a bad .s file and let us know what gcc version this is? (You can usually do 'make foo/bar/baz.s' to get a .s file.) I'd also be curious whether changing clflushopt to clwb works around the issue. --Andy
[Bug 108561] nouveau: external monitor can not be enabled with hindsight
https://bugzilla.kernel.org/show_bug.cgi?id=108561 --- Comment #6 from Elmar Stellnberger --- It is really a pity that my NVIDIA Corporation G96M [GeForce 9600M GT] has been crossed out of the list of supported cards since an update to kernel 4.3.3-2. It has worked well with the nouveau driver except for this bug. Latest tests have shown that the monitor can now be enabled with hindsight after booting; however the monitor being disabled by s2ram is a problem that has persisted up to now. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915: Init power domains early in driver load
> commit ac9b8236551d1177fd07b56aef9b565d1864420d
> Author: Ville Syrjälä
> Date: Fri Nov 27 18:55:26 2015 +0200
>
> drm/i915: Introduce a gmbus power domain
>
> gmbus also needs the power domain infrastructure right from the start,
> since as soon as we register the i2c controllers someone can use them.
>
> v2: Adjust cleanup paths too (Chris).
>
> v3: Rebase onto -nightly (totally bogus tree I had lying around) and
> also move dpio init head (Ville).
>
> v4: Ville instead suggested to move gmbus setup later in the sequence,
> since it's only needed by the modeset code.
>
> v5: Move even close to the actual user, right next to the comment that
> states where we really need gmbus (and interrupts!).
>
> Cc: Ville Syrjälä
> Cc: Patrik Jakobsson
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Meelis Roos
> Cc: Chris Wilson
> Fixes: ac9b8236551d ("drm/i915: Introduce a gmbus power domain")
> Cc: stable at vger.kernel.org
> References: http://www.spinics.net/lists/intel-gfx/msg83075.html
> Signed-off-by: Daniel Vetter
> ---
>
> Meelis, can you pls retest this one?
I also confirmed that my 865G chipset computer was suffering from the
same problem and the patch also helps on D865GLC mainboard with my
userspace that autoloads eeprom driver.
--
Meelis Roos (mroos at linux.ee)
[PATCH] x86: Add an explicit barrier() to clflushopt()
On Thu, Jan 07, 2016 at 09:55:51AM -0800, Andy Lutomirski wrote: > On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson > wrote: > >> + /* GCC (4.9.1 and 5.2.1 at least) appears to be very confused when > >> + * meeting this alternative() and demonstrably miscompiles loops > >> + * iterating over clflushopts. > >> + */ > >> + barrier(); > >> } > > > > Or an alternative: > > > > +#define alternative_output(oldinstr, newinstr, feature, output)\ > > + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ > > + : output : "i" (0) : "memory") > > > > I would really appreciate some knowledgeable folks taking a look at the > > asm for clflushopt() as it still affects today's kernel and gcc. > > > > Fwiw, I have confirmed that arch/x86/mm/pageattr.c clflush_cache_range() > > is similarly affected. > > Unless I'm mis-reading the asm, clflush_cache_range() is compiled > correctly for me. (I don't know what the %P is for in the asm, but > that shouldn't matter.) The ALTERNATIVE shouldn't even be visible to > the optimizer. > > Can you attach a bad .s file and let us know what gcc version this is? > (You can usually do 'make foo/bar/baz.s' to get a .s file.) I'd also > be curious whether changing clflushopt to clwb works around the issue. Now I feel silly. Looking at the .s, there is no difference with the addition of the barrier to clflush_cache_range(). And sure enough letting the test run for longer, we see a failure. I fell for a placebo. The failing assertion is always on the last cacheline and is always one value behind. Oh well, back to wondering where we miss the flush. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 108561] nouveau: external monitor can not be enabled with hindsight
https://bugzilla.kernel.org/show_bug.cgi?id=108561 --- Comment #7 from Elmar Stellnberger --- Comment #6 is now resolved: Please excuse the panic; I think that there was just a temporary configuration issue with Arch Linux (see also: https://bugs.freedesktop.org/show_bug.cgi?id=93405); i.e. /dev/card0 needs some time to appear; now let us go on with the s2ram issue as the issue with enabling the monitor after boot is already resolved! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 78987] black screen when trying to enable external VGA screen on Trinity APU laptop
https://bugs.freedesktop.org/show_bug.cgi?id=78987 --- Comment #6 from Lucas Stach --- Coming back to this after a long time. Meanwhile the APU is a Richland based chip in the same laptop chassis. Behaviour stays the same. What I found out is that VGA lights up if it is connected at boot up, but when GDM tries to switch modes the ATOMBIOS hang is encountered again. So it seems like disabling the encoder does not work properly and it's not coming back to life when trying to enable it again. I've tried to disable various parts of the encoder disable sequence, but didn't find anything that would make a difference. I would be very glad if someone with some more clue about this than me could take a look at this. Do you need any more traces/registerdumps/infos? -- 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/20160107/9bde0936/attachment.html>
drm/amd/powerplay: show gpu load when print gpu performance for Cz. (v2)
Hello Rex Zhu,
The patch 605ed21929fe: "drm/amd/powerplay: show gpu load when print
gpu performance for Cz. (v2)" from Dec 17, 2015, leads to the
following static checker warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1545
cz_print_current_perforce_level()
warn: 'result' can be either negative or positive
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c
1535 }
1536
1537 result = smum_send_msg_to_smc(hwmgr->smumgr,
PPSMC_MSG_GetAverageGraphicsActivity);
^^^
1538 if (0 == result) {
^^
smum_send_msg_to_smc() returns either a negative error code or zero or
one. There is no documentation. What does it mean when it returns 1?
Btw, Yoda code is just makes it harder to understand for no reason. It
triggers a checkpatch.pl warning these days.
I studied this back in 2002 and == vs = bugs were very rare even then.
These days the tools are much stricter so normally we get about 2 bugs
caused by == vs = typos per year. We might not have had any in 2015?
Let's say you write it as:
if (result = 0)
1) First we get a GCC warning:
CC [M] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.o
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c: In function
âcz_print_current_perforce_levelâ:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1538:2: warning:
suggest parentheses around assignment used as truth value [-Wparentheses]
if (result = 0) {
It's true that some people use extra parenthesis around every condition
which disables the GCC warning. Don't do that.
2) Second that code will also trigger a checkpatch.pl warning.
ERROR: do not use assignment in if condition
#1538: FILE: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1538:
+ if (result = 0) {
It can be easy to miss that warning if your code has a ton of warnings
like this driver does. If you care about bugs, you should probably take
the energy from writing in Yoda code and use it fix checkpatch.pl
warnings instead.
3) Third it triggers a Smatch warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1538
cz_print_current_perforce_level() warn: was '== 0' instead of '='
We miss Smatch warnings for non-x86 arches. So yes it's still possible
to have a == vs = bug in 2016 era but it's unlikely and it's sort of
your fault if that happens because it means you write messy code to foil
GCC, have checkpatch warnings and don't run Smatch. Also testing, I
suppose.
1539 active_percent = cgs_read_register(hwmgr->device,
mmSMU_MP1_SRBM2P_ARG_0);
1540 active_percent = active_percent > 100 ? 100 :
active_percent;
1541 } else {
1542 active_percent = 50;
1543 }
1544
1545 seq_printf(m, "\n [GPU load]: %u %%\n\n", active_percent);
regards,
dan carpenter
[git pull] drm fixes
Hi Linus, still not back to work, but I decided to forward this fix. Dave. The following changes since commit b06f3a168cdcd80026276898fd1fee443ef25743: Merge tag 'for-linus-20160106' of git://git.infradead.org/linux-mtd (2016-01-06 20:32:08 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 3bea6a4c7895fc94965a219a8da9bcf753667901: Merge branch 'linux-4.4' of git://github.com/skeggsb/linux into drm-fixes (2016-01-07 17:18:45 +1000) Ben Skeggs (1): drm/nouveau/gr/nv40: fix oops in interrupt handler Dave Airlie (1): Merge branch 'linux-4.4' of git://github.com/skeggsb/linux into drm-fixes drivers/gpu/drm/nouveau/nvkm/engine/gr/nv40.c | 1 + 1 file changed, 1 insertion(+)
[PATCH] x86: Add an explicit barrier() to clflushopt()
On 01/07/16 11:44, Chris Wilson wrote: > > Now I feel silly. Looking at the .s, there is no difference with the > addition of the barrier to clflush_cache_range(). And sure enough > letting the test run for longer, we see a failure. I fell for a placebo. > > The failing assertion is always on the last cacheline and is always one > value behind. Oh well, back to wondering where we miss the flush. > -Chris > Could you include the assembly here? -hpa
[PATCH] x86: Add an explicit barrier() to clflushopt()
On Thu, Jan 07, 2016 at 01:05:35PM -0800, H. Peter Anvin wrote:
> On 01/07/16 11:44, Chris Wilson wrote:
> >
> > Now I feel silly. Looking at the .s, there is no difference with the
> > addition of the barrier to clflush_cache_range(). And sure enough
> > letting the test run for longer, we see a failure. I fell for a placebo.
> >
> > The failing assertion is always on the last cacheline and is always one
> > value behind. Oh well, back to wondering where we miss the flush.
> > -Chris
> >
>
> Could you include the assembly here?
Sure, here you go:
.LHOTB18:
.p2align 4,,15
.globl clflush_cache_range
.type clflush_cache_range, @function
clflush_cache_range:
.LFB2505:
.loc 1 131 0
.cfi_startproc
.LVL194:
1: call__fentry__
.loc 1 132 0
movzwl boot_cpu_data+198(%rip), %eax
.loc 1 131 0
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
.loc 1 133 0
movl%esi, %esi
.LVL195:
addq%rdi, %rsi
.LVL196:
.loc 1 131 0
movq%rsp, %rbp
.cfi_def_cfa_register 6
.loc 1 132 0
subl$1, %eax
cltq
.LVL197:
.loc 1 136 0
#APP
# 136 "arch/x86/mm/pageattr.c" 1
mfence
# 0 "" 2
.loc 1 138 0
#NO_APP
notq%rax
.LVL198:
andq%rax, %rdi
.LVL199:
cmpq%rdi, %rsi
jbe .L216
.L217:
.LBB1741:
.LBB1742:
.loc 8 198 0
#APP
# 198 "./arch/x86/include/asm/special_insns.h" 1
661:
.byte 0x3e; clflush (%rdi)
662:
.skip -(((6651f-6641f)-(662b-661b)) > 0) * ((6651f-6641f)-(662b-661b)),0x90
663:
.pushsection .altinstructions,"a"
.long 661b - .
.long 6641f - .
.word ( 9*32+23)
.byte 663b-661b
.byte 6651f-6641f
.byte 663b-662b
.popsection
.pushsection .altinstr_replacement, "ax"
6641:
.byte 0x66; clflush (%rdi)
6651:
.popsection
# 0 "" 2
#NO_APP
.LBE1742:
.LBE1741:
.loc 1 141 0
.loc 1 139 0
movzwl boot_cpu_data+198(%rip), %eax
addq%rax, %rdi
.loc 1 138 0
cmpq%rdi, %rsi
ja .L217
.L216:
.loc 1 144 0
#APP
# 144 "arch/x86/mm/pageattr.c" 1
mfence
# 0 "" 2
.loc 1 145 0
#NO_APP
popq%rbp
.cfi_restore 6
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2505:
.size clflush_cache_range, .-clflush_cache_range
.section.text.unlikely
Whilst you are looking at this asm, note that we reload
boot_cpu_data.x86_cflush_size everytime around the loop. That's a small
but noticeable extra cost (especially when we are only flushing a single
cacheline).
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index a3137a4..2cd2b4b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -129,14 +129,13 @@ within(unsigned long addr, unsigned long start, unsigned
long end)
*/
void clflush_cache_range(void *vaddr, unsigned int size)
{
- unsigned long clflush_mask = boot_cpu_data.x86_clflush_size - 1;
+ unsigned long clflush_size = boot_cpu_data.x86_clflush_size;
void *vend = vaddr + size;
- void *p;
+ void *p = (void *)((unsigned long)vaddr & ~(clflush_size - 1));
mb();
- for (p = (void *)((unsigned long)vaddr & ~clflush_mask);
-p < vend; p += boot_cpu_data.x86_clflush_size)
+ for (; p < vend; p += clflush_size)
clflushopt(p);
mb();
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] x86: Add an explicit barrier() to clflushopt()
On 01/07/16 13:54, Chris Wilson wrote:
>
> Whilst you are looking at this asm, note that we reload
> boot_cpu_data.x86_cflush_size everytime around the loop. That's a small
> but noticeable extra cost (especially when we are only flushing a single
> cacheline).
>
I did notice that; I don't know if this is a compiler failure to do an
obvious hoisting (which should then be merged with the other load) or a
consequence of the volatile. It might be useful to report this to the
gcc bugzilla to let them look at it.
Either way, the diff looks good and you can add my:
Acked-by: H. Peter Anvin
However, I see absolutely nothing wrong with the assembly other than
minor optimization possibilities: since gcc generates an early-out test
as well as a late-out test anyway, we could add an explicit:
if (p < vend)
return;
before the first mb() at no additional cost (assuming gcc is smart
enough to skip the second test; otherwise that can easily be done
manually by replacing the for loop with a do { } while loop.
I would be very interested in knowing if replacing the final clflushopt
with a clflush would resolve your problems (in which case the last mb()
shouldn't be necessary either.)
Something like:
void clflush_cache_range(void *vaddr, unsigned int size)
{
unsigned long clflush_size = boot_cpu_data.x86_clflush_size;
char *vend = (char *)vaddr + size;
char *p = (char *)((unsigned long)vaddr & ~(clflush_size - 1);
if (p >= vend)
return;
mb();
for (; p < vend - clflush_size; p += clflush_size)
clflushopt(p);
clflush(p); /* Serializing and thus a barrier */
}
[PATCH] x86: Add an explicit barrier() to clflushopt()
On 01/07/16 14:29, H. Peter Anvin wrote: > > I would be very interested in knowing if replacing the final clflushopt > with a clflush would resolve your problems (in which case the last mb() > shouldn't be necessary either.) > Nevermind. CLFLUSH is not ordered with regards to CLFLUSHOPT to the same cache line. Could you add a sync_cpu(); call to the end (can replace the final mb()) and see if that helps your case? -hpa
[pull] radeon and amdgpu drm-next-4.5
Hi Dave, Misc fixes for amdgpu and radeon for 4.5. The bulk of the changes are smatch fixes and cleanups. This also includes the DP MST fixes from Mykola. Beyond that some fixes from Christian to avoid -ENOMEM errors in some corner cases in the CS ioctl, some suspend and resume fixes, and some powerplay fixes. The following changes since commit c11b8989635166c5a1e6aac1853a847bd664f8db: Merge tag 'omapdrm-4.5-resolved' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next (2016-01-01 07:41:52 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.5 for you to fetch changes up to 9cf452d68290c83862f2456e18c515aa63adb37d: amdgpu/pm: Change strncmp to strcmp to match the parameters precisely. (2016-01-07 17:10:49 -0500) Arnd Bergmann (1): drm: powerplay: use div64_s64 instead of do_div Christian König (13): drm/ttm: add ttm_bo_move_to_lru_tail function drm/amdgpu: move VM page tables to the LRU end on CS drm/amdgpu: validate duplicates first drm/amdgpu: fix amdgpu_cs_get_threshold_for_moves handling drm/amdgpu: cleanup amdgpu_cs_list_validate drm/amdgpu: group VM mapping tree with it's lock (v2) drm/amdgpu: cleanup amdgpu_cs_parser structure drm/amdgpu: cleanup amdgpu_cs_parser_relocs drm/amdgpu: cleanup bo list bucket handling drm/amdgpu: keep the prefered/allowed domains in the BO drm/amdgpu: search only the BO list for VM mappings drm/amdgpu: try to find BO VAs only for the BOs in the list drm/amdgpu: add warning to amdgpu_bo_gpu_offset() v2 Chunming Zhou (1): drm/amdgpu: fix NULL in vm_grab_id while S3 back Dan Carpenter (3): drm/amd/powerplay: fix a reversed condition drm/amdgpu/cgs: cleanup some indenting drm/amd/powerplay: precedence bug in init_non_clock_fields() Mykola Lysenko (4): drm/dp/mst: process broadcast messages correctly drm/dp/mst: always send reply for UP request drm/dp/mst: fix in MSTB RAD initialization drm/dp/mst: fix in RAD element access Rex Zhu (12): drm/amd/powerplay: fix bug that NULL checks are reversed. drm/amd/powerplay: fix Smatch static checker warnings with indenting (v2) drm/amd/powerplay: fix Smatch static checker warnings drm/amd/powerplay: add powerplay valid check to avoid null point. (v2) drm/amd/powerplay: Reload and initialize the smc firmware on powerplay resume. drm/amdgpu: Show gpu load when display gpu performance for Ci. drm/amdgpu: Show gpu load when display gpu performance for Fiji of VI. drm/amdgpu: fix hex/decimal bug when show gpu load. drm/amd/powerplay: add thermal control task when resume. drm/amd/powerplay: enable set boot state task drm/amd/powerplay: enable power down asic task. (v2) drm/amd/powerplay: implement power down asic task for CZ Thierry Reding (1): drm/radeon: Drop unnecessary unsigned int < 0 check Tom St Denis (9): amdgpu/vce3: Cleanup harvest config function. amdgpu/vce3: Simplify idle and wait for idle code amdgpu/vce3: Simplify vce_v3_0_soft_reset() amdgpu/vce3: Simplify vce_v3_0_process_interrupt() amdgpu/vce3: Remove magic constants from harvest register masks. amdgpu/vce3: Simplify vce_v3_0_hw_init and ensure both rings default to not ready. amdgpu/dce11: Remove division from dce_v11_0_vblank_wait() amdgpu/dce11: Add test for crtc < 0 to various DCEv11 functions amdgpu/pm: Change strncmp to strcmp to match the parameters precisely. drivers/gpu/drm/amd/amdgpu/amdgpu.h| 33 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c| 51 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 186 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 15 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 +- drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 14 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 16 +- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 - drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 - drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 89 +--- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 32 +- .../drm/amd/powerplay/eventmgr/eventactionchains.c | 1 + .../gpu/drm/amd/powerplay/eventmgr/eventtasks.c| 9 +- drivers/gpu/drm/amd/powerplay/eventmgr/psm.c | 3 +- drivers/gpu/drm/amd/powerplay/eventmgr/psm.h | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 75 ++- drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 64 ++- .../gpu/drm/amd/powe
[Bug 93594] Flickering Shadows in The Talos Principle
https://bugs.freedesktop.org/show_bug.cgi?id=93594 --- Comment #5 from EoD --- (In reply to Michel Dänzer from comment #1) > (In reply to Christoph Haag from comment #0) > > When replaying the trace on intel, the shadows don't seem to flicker. > > Not at all? I see pretty bad flickering on my Verde, but while I can still > see some on my Kaveri, it's hardly noticeable. So this might be at least > partly an SI specific issue. While changing a few settings I observed, the lower the "Max Shadow Size" setting is, the easier you can see the heavy flickering. When you set the setting "No dynamic lightning", all the flicker is gone. I made a new and smaller apitrace with every setting on LOWEST. The new apitrace shows the difference between a scene with dynamic lightning (no flickering) and the same scene without dynamic lightning (massive flickering). https://drive.google.com/file/d/0B42CQY2wGHumalYyWEJNRXAzWFE/view?usp=sharing It evens runs semi-smoothly on llvmpipe. -- 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/20160107/0bd741db/attachment.html>
[Bug 93594] Flickering Shadows in The Talos Principle
https://bugs.freedesktop.org/show_bug.cgi?id=93594 --- Comment #6 from EoD --- (In reply to EoD from comment #5) > I made a new and smaller apitrace with every setting on LOWEST. The new > apitrace shows the difference between a scene with dynamic lightning (no > flickering) and the same scene without dynamic lightning (massive > flickering). > > https://drive.google.com/file/d/0B42CQY2wGHumalYyWEJNRXAzWFE/view?usp=sharing Correction. It should be called: The new apitrace shows the difference between a scene without dynamic lightning (no flickering) and the same scene with dynamic lightning (massive flickering). The setting is called "No Dynamic Lightning" (On = Good, Off = Flickering) -- 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/20160107/17b79612/attachment.html>
[PATCH] drm/radeon: fix trivial typo in warning message
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index c566993..4197ca1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1150,7 +1150,7 @@ static void radeon_check_arguments(struct radeon_device
*rdev)
}
if (radeon_vm_size < 1) {
- dev_warn(rdev->dev, "VM size (%d) to small, min is 1GB\n",
+ dev_warn(rdev->dev, "VM size (%d) too small, min is 1GB\n",
radeon_vm_size);
radeon_vm_size = 4;
}
--
2.6.4
[PATCH v4.4-rc8] radeon: r100: Silence 'may be used uninitialized' warnings
From: Tim Gardner
CC [M] drivers/gpu/drm/radeon/r100.o
In file included from drivers/gpu/drm/radeon/radeon_mode.h:37:0,
from drivers/gpu/drm/radeon/radeon.h:80,
from drivers/gpu/drm/radeon/r100.c:33:
drivers/gpu/drm/radeon/r100.c: In function 'r100_bandwidth_update':
include/drm/drm_fixed.h:64:13: warning: 'crit_point_ff.full' may be used
uninitialized in this function [-Wmaybe-uninitialized]
u64 tmp = ((u64)A.full << 13);
^
drivers/gpu/drm/radeon/r100.c:3153:63: note: 'crit_point_ff.full' was declared
here
fixed20_12 peak_disp_bw, mem_bw, pix_clk, pix_clk2, temp_ff, crit_point_ff;
^
drivers/gpu/drm/radeon/r100.c:3583:42: warning: 'disp_drain_rate.full' may be
used uninitialized in this function [-Wmaybe-uninitialized]
temp_ff.full = read_return_rate.full - disp_drain_rate.full;
gcc version 5.3.1 20151219 (Ubuntu 5.3.1-4ubuntu1)
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Signed-off-by: Tim Gardner
---
I think this warning is bogus, but I don't know how else to make gcc shut up.
drivers/gpu/drm/radeon/r100.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9e7e2bf..5eae0a8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3150,7 +3150,8 @@ void r100_bandwidth_update(struct radeon_device *rdev)
{
fixed20_12 trcd_ff, trp_ff, tras_ff, trbs_ff, tcas_ff;
fixed20_12 sclk_ff, mclk_ff, sclk_eff_ff, sclk_delay_ff;
- fixed20_12 peak_disp_bw, mem_bw, pix_clk, pix_clk2, temp_ff,
crit_point_ff;
+ fixed20_12 peak_disp_bw, mem_bw, pix_clk, pix_clk2, temp_ff;
+ fixed20_12 crit_point_ff = {0};
uint32_t temp, data, mem_trcd, mem_trp, mem_tras;
fixed20_12 memtcas_ff[8] = {
dfixed_init(1),
@@ -3204,7 +3205,7 @@ void r100_bandwidth_update(struct radeon_device *rdev)
fixed20_12 min_mem_eff;
fixed20_12 mc_latency_sclk, mc_latency_mclk, k1;
fixed20_12 cur_latency_mclk, cur_latency_sclk;
- fixed20_12 disp_latency, disp_latency_overhead, disp_drain_rate,
+ fixed20_12 disp_latency, disp_latency_overhead, disp_drain_rate = {0},
disp_drain_rate2, read_return_rate;
fixed20_12 time_disp1_drop_priority;
int c;
--
1.9.1
