Device loses its IRQ number on driver unload?
On 10 March 2015 at 22:55, Thomas Hellstrom wrote: > On 03/09/2015 09:25 PM, Dave Airlie wrote: >> On 10 March 2015 at 02:02, Thomas Hellstrom wrote: >>> On 03/09/2015 04:22 PM, Daniel Vetter wrote: On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote: > Hi, > > I'm not sure this started with 4.0 but when I rmmod the device driver > like so > rmmod vmwgfx > > The device loses its IRQ line as shown in lscpi: >Flags: bus master, medium devsel, latency 64 > > and a subsequent modprobe will fail since pdev->irq is 0. > > Is anyone else seeing this with other drivers? I seen occasionally (over the past couple of kernels) random zeros in pdev but dismissed it as broken machines or bugs in i915 (we have them ...). Usually the box died chasing a NULL pointer from pdev. Otherwise no. -Daniel >>> OK. Thanks for the info. Since in my case this is 100% reproducible I >>> guess I have an excellent opportunity to bisect the problem :-/ >>> >> does lspci -H1, or some option like to direct access hw show it? >> >> just whether this is the kernel copy or the hw register getting messed up. >> >> Dave. > Hi, Dave, > > lspci -H1 indeed shows the IRQ number. It turns out that the commit > introduced in 4.0 breaking this is > > b4b55cda587442477a3a9f0669e26bba4b7800c0 is the first bad commit > commit b4b55cda587442477a3a9f0669e26bba4b7800c0 > Author: Jiang Liu > Date: Thu Feb 5 13:44:47 2015 +0800 > > x86/PCI: Refine the way to release PCI IRQ resources > > > It's obvious from the commit message that unloading the driver *should* > drop the irq resource but its not > obvious what's reallocating that resource on driver load... > > Anyway, it turns out that adding a > pci_disable_device(pdev) in the pci driver's remove() method > (vmw_remove() in my case) appears to fix the problem: > The device irq is removed on driver unload and enabled again on driver > load There appears to be no pci_disable_device() on driver exit in core drm. Yes that is because at one time pre kms if you pci disabled the VGA device, bad things would happen. I think with modesetting driver it shouldn't be a problem anymore. Dave.
[v3] libdrm: improvements to userspace exynos component
Hi Tobias and Emil On 2015ë 03ì 11ì¼ 04:36, Emil Velikov wrote: > On 08/03/15 23:12, Tobias Jakobi wrote: >> Hello Emil, >> Emil Velikov wrote: >>> I'm planning to push the above mentioned patches around lunchtime this >>> Tuesday. If anyone has objections please speak up. >> I doubt you're going to hear anything from Inki Dae. > Despite that it might sound a bit rude, I sincerely hope that you're > wrong on this one. I'm would assume that the lack of reply from Inki was > due to being him busy, rather than ignoring you. > I was busy so I didn't care of it. Sorry for this. >> Anyway, thanks for considering to merge this, even though it lacks the >> review of the exynos-drm maintainer. >> >> At least this gives me confidence to continue to work on this (I also >> want to expose async g2d operation to userspace). >> > Glad that you're still planning to work on this. Ideally the > Exynos/Samsung guys will take a look at the rest of your patches which > require someone with greater knowledge of the hardware than me :-) > Right. We will review this patch and reply at least until tomorrow. Thanks, Inki Dae > Cheers, > Emil > >
drm: Check in setcrtc if the primary plane supports the fb pixel format
Hi Dan,
(CC'ing Daniel Vetter)
On Tuesday 10 March 2015 23:30:45 Dan Carpenter wrote:
> Hello Laurent Pinchart,
>
> The patch eca93e28c256: "drm: Check in setcrtc if the primary plane
> supports the fb pixel format" from Mar 9, 2015, leads to the
> following static checker warning:
>
> drivers/gpu/drm/drm_plane_helper.c:360 create_primary_plane()
> info: ignoring unreachable code.
>
> drivers/gpu/drm/drm_plane_helper.c
>347 static struct drm_plane *create_primary_plane(struct drm_device
> *dev) 348 {
>349 struct drm_plane *primary;
>350 int ret;
>351
>352 primary = kzalloc(sizeof(*primary), GFP_KERNEL);
>353 if (primary == NULL) {
>354 DRM_DEBUG_KMS("Failed to allocate primary plane\n");
> 355 return NULL;
>
>356 /*
>357 * Remove the format_default field from drm_plane
> when dropping 358 * this helper.
>359 */
>360 primary->format_default = true;
>361 }
This looks like a failed conflict resolution. Daniel ?
--
Regards,
Laurent Pinchart
[PATCH 1/2] dt-bindings: drm/bridge: Add IT6151 bridge chip driver bindings.
Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
---
Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/it6151.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/it6151.txt
b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
new file mode 100644
index 000..ad0ad60
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
@@ -0,0 +1,15 @@
+it6151 bridge bindings
+
+Required properties:
+ - compatible: "ite,it6151"
+ - reg: i2c address of the bridge's dp tx.
+ - rxreg: i2c address of the bridge's mipi rx.
+ - reset-gpio: OF device-tree gpio specification
+
+Example:
+ ite6151: edp-bridge at 5c {
+ compatible = "ite,it6151";
+ reg = <0x5c>;
+ rxreg = <0x6c>;
+ reset-gpio = <&pio 94 GPIO_ACTIVE_HIGH>;
+ };
--
1.8.1.1.dirty
* Email Confidentiality Notice
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
[PATCH 2/2] drm/bridge: Add IT6151 bridge driver
This patch adds a drm_bridge driver for the IT6151 MIPI to eDP
bridge chip.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/it6151.c | 601
include/drm/bridge/it6151.h | 34 +++
4 files changed, 646 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/it6151.c
create mode 100644 include/drm/bridge/it6151.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f38bbcd..2b3a78e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -11,3 +11,13 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_IT6151
+ bool "Enable IT6151FN : MIPI to eDP Converter"
+ depends on DRM
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have IT6151 for display
+ The IT6151 is a high-performance and low-power
+ MIPI to eDP converter
+
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d8a8cfd..98edb74 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_DRM_IT6151) += it6151.o
diff --git a/drivers/gpu/drm/bridge/it6151.c b/drivers/gpu/drm/bridge/it6151.c
new file mode 100644
index 000..039fe4b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/it6151.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+
+
+
+#define MIPI_RX_SW_RST0x05
+#define MIPI_RX_INT_MASK 0x09
+#define MIPI_RX_SYS_CFG 0x0c
+#define MIPI_RX_MCLK 0x11
+#define MIPI_RX_PHY_IF_1 0x19
+#define MIPI_RX_PKT_DEC 0x27
+#define MIPI_RX_UFO_BLK_HIGH 0x28
+#define MIPI_RX_UFO_BLK_LOW 0x29
+#define MIPI_RX_UFO_HDE_DELAY 0x2e
+#define MIPI_RX_UFO_RESYNC0x2f
+#define MIPI_RX_RESYNC_POL0x4e
+#define MIPI_RX_PCLK_HSCLK0x80
+#define MIPI_RX_AMP_TERM 0x84
+#define MIPI_RX_TIMER_INT_CNT 0x92
+
+#define DP_TX_VEN_ID_LOW0x00
+#define DP_TX_VEN_ID_HIGH 0x01
+#define DP_TX_DEV_ID_LOW0x02
+#define DP_TX_DEV_ID_HIGH 0x03
+#define DP_TX_REV_ID0x04
+#define DP_TX_SW_RST0x05
+#define DP_TX_INT_STA_0 0x06
+#define DP_TX_INT_STA_1 0x07
+#define DP_TX_INT_STA_2 0x08
+#define DP_TX_INT_MASK_00x09
+#define DP_TX_INT_MASK_10x0a
+#define DP_TX_INT_MASK_20x0b
+#define DP_TX_SYS_CFG 0x0c
+#define DP_TX_SYS_DBG 0x0f
+#define DP_TX_LANE 0x16
+#define DP_TX_TRAIN 0x17
+#define DP_TX_AUX_CH_FIFO 0x21
+#define DP_TX_AUX_CLK 0x22
+#define DP_TX_PC_REQ_FIFO 0x23
+#define DP_TX_PC_REQ_OFST_0 0x24
+#define DP_TX_PC_REQ_OFST_1 0x25
+#define DP_TX_PC_REQ_OFST_2 0x26
+#define DP_TX_PC_REQ_WD_0 0x27
+#define DP_TX_PC_REQ_SEL0x2b
+#define DP_TX_HDP 0x3a
+#define DP_TX_LNPWDB0x5c
+#define DP_TX_EQ0x5f
+#define DP_TX_COL_CONV_19 0x76
+#define DP_TX_COL_CONV_20 0x77
+#define DP_TX_PG_H_DE_END_L 0x7e
+#define DP_TX_PG_H_DE_END_H 0x7f
+#define DP_TX_PG_H_SYNC_START_L 0x80
+#define DP_TX_PG_H_SYNC_START_H 0x81
+#define DP_TX_PG_H_SYNC_END_L 0x82
+#define DP_TX_PG_H_SYNC_END_H 0x83
+#define DP_TX_PG_V_DE_END_L 0x88
+#define DP_TX_PG_V_DE_END_H 0x89
+#define DP_TX_PG_V_DE_START_L 0x8a
+#define DP_TX_IN_VDO_TM_15 0xb5
+#define DP_TX_IN_VDO_TM_17 0xb7
+#define DP_TX_PSR_CTRL_00xc4
+#define DP_TX_PSR_CTRL_10xc5
+#define DP_TX_HDP_IRQ_TM0xc9
+#define DP_TX_AUX_DBG 0xca
+#define DP_TX_AUX_MASTER0xcb
+#define DP_TX_PKT_OPT 0xce
+#define DP_TX_VDO_FIFO 0xd3
+#define DP_TX_VDO_STMP 0xd4
+#define DP_TX_PKT 0xe8
+#define DP_TX_PKT_AVI_VIC 0xec
+#define DP_TX_MIPI_PORT 0xfd
+
+enum {
+ MIPI_1_LANE = 0,
+ MIPI_2_LANE = 1,
+ MIPI_3_LANE = 2,
+ MIPI_4_LANE = 3,
+};
+
+enum {
+ RGB_24b = 0x3E,
+ RGB_30b = 0x0D,
+ RGB_36b = 0x1D,
+ RGB_18b_P = 0x1E,
+ RGB_1
[RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
On 03/10/2015 04:24 PM, Philipp Zabel wrote: > Hi Archit, > > thanks for the cleanup! > > Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja: >> DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation >> for >> the imx kms driver. >> >> Remove this local config option and use the top level DRM_FBDEV_EMULATION >> config >> option where applicable. Using this config lets us also prevent wrapping >> around >> drm_fb_helper_* calls with #ifdefs in certain places. >> >> We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION. >> It's probably okay to get remove the #ifdef itself, but just left it here for >> now to be safe. It can be removed after some testing. >> >> Signed-off-by: Archit Taneja > > Tested-by: Philipp Zabel > (Both with and without the #ifdef CONFIG_DRM_FBDEV_EMULATION removed.) > Thanks for testing it out. > Although this is for another patch, I think the legacyfb_depth > module_param should be removed altogether if CONFIG_DRM_FBDEV_EMULATION > is disabled, so maybe that #ifdef should stay. I'll create a patch for that for future revs of this patch set. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 09:03 PM, Jani Nikula wrote: > On Tue, 10 Mar 2015, Archit Taneja wrote: >> On 03/10/2015 03:35 PM, Daniel Vetter wrote: >>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: > On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? >>> >>> Hm right I've missed that. Reminds me that you need one more patch at the >>> end to remove all the various select DRM_KMS_FB_HELPER from all drm >>> drivers. Otherwise this knob here won't work by default if you e.g. select >>> radeon. In general we can't mix explicit options with menu entries with a >>> select. >> >> I was trying that out. Removing DRM_KMS_FB_HELPER and having >> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff >> internally in their respective xyz_fbdev.c files. >> >> Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers >> and replace them with 'select DRM_FBDEV_EMULATION'? > > Slightly tangential: As a rule of thumb, you should not "select" > anything that is visible in menuconfig or has dependencies [1]. This > will break the build eventually, and attempts to fix it are troublesome > [2]. Thanks, I'll keep this in mind! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/2] dt-bindings: drm/bridge: Add IT6151 bridge chip driver bindings.
Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/it6151.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/it6151.txt
b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
new file mode 100644
index 000..ad0ad60
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
@@ -0,0 +1,15 @@
+it6151 bridge bindings
+
+Required properties:
+ - compatible: "ite,it6151"
+ - reg: i2c address of the bridge's dp tx.
+ - rxreg: i2c address of the bridge's mipi rx.
+ - reset-gpio: OF device-tree gpio specification
+
+Example:
+ ite6151: edp-bridge at 5c {
+ compatible = "ite,it6151";
+ reg = <0x5c>;
+ rxreg = <0x6c>;
+ reset-gpio = <&pio 94 GPIO_ACTIVE_HIGH>;
+ };
--
1.8.1.1.dirty
[PATCH 2/2] drm/bridge: Add IT6151 bridge driver
This patch adds a drm_bridge driver for the IT6151 MIPI to eDP
bridge chip.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/it6151.c | 601
include/drm/bridge/it6151.h | 34 +++
4 files changed, 646 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/it6151.c
create mode 100644 include/drm/bridge/it6151.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f38bbcd..2b3a78e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -11,3 +11,13 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_IT6151
+ bool "Enable IT6151FN : MIPI to eDP Converter"
+ depends on DRM
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have IT6151 for display
+ The IT6151 is a high-performance and low-power
+ MIPI to eDP converter
+
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d8a8cfd..98edb74 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
+obj-$(CONFIG_DRM_IT6151) += it6151.o
diff --git a/drivers/gpu/drm/bridge/it6151.c b/drivers/gpu/drm/bridge/it6151.c
new file mode 100644
index 000..039fe4b
--- /dev/null
+++ b/drivers/gpu/drm/bridge/it6151.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+
+
+
+#define MIPI_RX_SW_RST0x05
+#define MIPI_RX_INT_MASK 0x09
+#define MIPI_RX_SYS_CFG 0x0c
+#define MIPI_RX_MCLK 0x11
+#define MIPI_RX_PHY_IF_1 0x19
+#define MIPI_RX_PKT_DEC 0x27
+#define MIPI_RX_UFO_BLK_HIGH 0x28
+#define MIPI_RX_UFO_BLK_LOW 0x29
+#define MIPI_RX_UFO_HDE_DELAY 0x2e
+#define MIPI_RX_UFO_RESYNC0x2f
+#define MIPI_RX_RESYNC_POL0x4e
+#define MIPI_RX_PCLK_HSCLK0x80
+#define MIPI_RX_AMP_TERM 0x84
+#define MIPI_RX_TIMER_INT_CNT 0x92
+
+#define DP_TX_VEN_ID_LOW0x00
+#define DP_TX_VEN_ID_HIGH 0x01
+#define DP_TX_DEV_ID_LOW0x02
+#define DP_TX_DEV_ID_HIGH 0x03
+#define DP_TX_REV_ID0x04
+#define DP_TX_SW_RST0x05
+#define DP_TX_INT_STA_0 0x06
+#define DP_TX_INT_STA_1 0x07
+#define DP_TX_INT_STA_2 0x08
+#define DP_TX_INT_MASK_00x09
+#define DP_TX_INT_MASK_10x0a
+#define DP_TX_INT_MASK_20x0b
+#define DP_TX_SYS_CFG 0x0c
+#define DP_TX_SYS_DBG 0x0f
+#define DP_TX_LANE 0x16
+#define DP_TX_TRAIN 0x17
+#define DP_TX_AUX_CH_FIFO 0x21
+#define DP_TX_AUX_CLK 0x22
+#define DP_TX_PC_REQ_FIFO 0x23
+#define DP_TX_PC_REQ_OFST_0 0x24
+#define DP_TX_PC_REQ_OFST_1 0x25
+#define DP_TX_PC_REQ_OFST_2 0x26
+#define DP_TX_PC_REQ_WD_0 0x27
+#define DP_TX_PC_REQ_SEL0x2b
+#define DP_TX_HDP 0x3a
+#define DP_TX_LNPWDB0x5c
+#define DP_TX_EQ0x5f
+#define DP_TX_COL_CONV_19 0x76
+#define DP_TX_COL_CONV_20 0x77
+#define DP_TX_PG_H_DE_END_L 0x7e
+#define DP_TX_PG_H_DE_END_H 0x7f
+#define DP_TX_PG_H_SYNC_START_L 0x80
+#define DP_TX_PG_H_SYNC_START_H 0x81
+#define DP_TX_PG_H_SYNC_END_L 0x82
+#define DP_TX_PG_H_SYNC_END_H 0x83
+#define DP_TX_PG_V_DE_END_L 0x88
+#define DP_TX_PG_V_DE_END_H 0x89
+#define DP_TX_PG_V_DE_START_L 0x8a
+#define DP_TX_IN_VDO_TM_15 0xb5
+#define DP_TX_IN_VDO_TM_17 0xb7
+#define DP_TX_PSR_CTRL_00xc4
+#define DP_TX_PSR_CTRL_10xc5
+#define DP_TX_HDP_IRQ_TM0xc9
+#define DP_TX_AUX_DBG 0xca
+#define DP_TX_AUX_MASTER0xcb
+#define DP_TX_PKT_OPT 0xce
+#define DP_TX_VDO_FIFO 0xd3
+#define DP_TX_VDO_STMP 0xd4
+#define DP_TX_PKT 0xe8
+#define DP_TX_PKT_AVI_VIC 0xec
+#define DP_TX_MIPI_PORT 0xfd
+
+enum {
+ MIPI_1_LANE = 0,
+ MIPI_2_LANE = 1,
+ MIPI_3_LANE = 2,
+ MIPI_4_LANE = 3,
+};
+
+enum {
+ RGB_24b = 0x3E,
+ RGB_30b = 0x0D,
+ RGB_36b = 0x1D,
+ RGB_18b_P = 0x1E,
+ RGB_1
[Intel-gfx] [PATCH] RFC: drm: add support for tiled/compressed/etc modifier in addfb2
> + > +#define fourcc_mod_code(vendor, val) \ > + u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & > 0x00ffL)) eh, yeah no, /home/airlied/kernel/drm-2.6/drivers/gpu/drm/i915/intel_pm.c: In function âskl_wm_method2â: /home/airlied/kernel/drm-2.6/drivers/gpu/drm/i915/intel_pm.c:2631: warning: integer constant is too large for âlongâ type /home/airlied/kernel/drm-2.6/drivers/gpu/drm/i915/intel_pm.c:2632: warning: integer constant is too large for âlongâ type I think you meant ULL here. Dave.
Device loses its IRQ number on driver unload?
On 03/10/2015 10:05 PM, Dave Airlie wrote: > On 10 March 2015 at 22:55, Thomas Hellstrom wrote: >> On 03/09/2015 09:25 PM, Dave Airlie wrote: >>> On 10 March 2015 at 02:02, Thomas Hellstrom >>> wrote: On 03/09/2015 04:22 PM, Daniel Vetter wrote: > On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote: >> Hi, >> >> I'm not sure this started with 4.0 but when I rmmod the device driver >> like so >> rmmod vmwgfx >> >> The device loses its IRQ line as shown in lscpi: >>Flags: bus master, medium devsel, latency 64 >> >> and a subsequent modprobe will fail since pdev->irq is 0. >> >> Is anyone else seeing this with other drivers? > I seen occasionally (over the past couple of kernels) random zeros in pdev > but dismissed it as broken machines or bugs in i915 (we have them ...). > Usually the box died chasing a NULL pointer from pdev. Otherwise no. > -Daniel OK. Thanks for the info. Since in my case this is 100% reproducible I guess I have an excellent opportunity to bisect the problem :-/ >>> does lspci -H1, or some option like to direct access hw show it? >>> >>> just whether this is the kernel copy or the hw register getting messed up. >>> >>> Dave. >> Hi, Dave, >> >> lspci -H1 indeed shows the IRQ number. It turns out that the commit >> introduced in 4.0 breaking this is >> >> b4b55cda587442477a3a9f0669e26bba4b7800c0 is the first bad commit >> commit b4b55cda587442477a3a9f0669e26bba4b7800c0 >> Author: Jiang Liu >> Date: Thu Feb 5 13:44:47 2015 +0800 >> >> x86/PCI: Refine the way to release PCI IRQ resources >> >> >> It's obvious from the commit message that unloading the driver *should* >> drop the irq resource but its not >> obvious what's reallocating that resource on driver load... >> >> Anyway, it turns out that adding a >> pci_disable_device(pdev) in the pci driver's remove() method >> (vmw_remove() in my case) appears to fix the problem: >> The device irq is removed on driver unload and enabled again on driver >> load There appears to be no pci_disable_device() on driver exit in core drm. > Yes that is because at one time pre kms if you pci disabled the VGA device, > bad things would happen. > > I think with modesetting driver it shouldn't be a problem anymore. > > Dave. So what's the preferred remedy here? should I file a bug against the above commit or should we go ahead modifying the DRM drivers? Thanks, Thomas > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] clk: provide clk_is_match() dummy for non-common clk
Hello,
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> +static inline bool clk_is_match(struct clk *p, struct clk *q)
> +{
> + return p == q ? true : false;
OK, this is only a move, but I wonder why Russell's comment that this is
equivalent to the easier
return p == q;
wasn't addressed?!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[Intel-gfx] [Beignet] [PATCH i-g-t 2/2] configure: Bump required libdrm version to 2.4.60
On Tue, Mar 10, 2015 at 01:06:44PM -0700, Jeff McGee wrote: > On Tue, Mar 10, 2015 at 07:47:03PM +0100, Daniel Vetter wrote: > > On Tue, Mar 10, 2015 at 01:58:52PM -0400, Rob Clark wrote: > > > On Tue, Mar 10, 2015 at 12:59 PM, Jeff McGee > > > wrote: > > > > On Tue, Mar 10, 2015 at 08:37:30AM +0100, Daniel Vetter wrote: > > > >> On Mon, Mar 09, 2015 at 04:41:02PM -0700, jeff.mcgee at intel.com > > > >> wrote: > > > >> > From: Jeff McGee > > > >> > > > > >> > tests/core_getparams needs the new libdrm interfaces for > > > >> > querying subslice and EU counts. > > > >> > > > > >> > For: VIZ-4636 > > > >> > Signed-off-by: Jeff McGee > > > >> > --- > > > >> > configure.ac | 2 +- > > > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > > >> > diff --git a/configure.ac b/configure.ac > > > >> > index 16d6a2e..88a1c3d 100644 > > > >> > --- a/configure.ac > > > >> > +++ b/configure.ac > > > >> > @@ -82,7 +82,7 @@ if test "x$GCC" = "xyes"; then > > > >> > fi > > > >> > AC_SUBST(ASSEMBLER_WARN_CFLAGS) > > > >> > > > > >> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.52 libdrm]) > > > >> > +PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.60 libdrm]) > > > >> > > > >> Please don't and instead copypaste the new structs/defines with a > > > >> local_ > > > >> prefix like we do it for all the other new igt testcases. Forcing > > > >> libdrm > > > >> to get updated for igt all the time can get annoying fast. > > > >> -Daniel > > > >> > > > > In this case I'm trying to exercise new API functions in libdrm which > > > > wrap the GETPARAM ioctl. Would you rather me bypass the wrapper to > > > > avoid requiring updated libdrm? I can do that, but it fails to test the > > > > complete path that client would use. > > > > > > > > > Am I missing something, or does 2.4.60 not exist yet? > > > > > > That said dependency bumps for igt seem like less of an issue than > > > dependency bumps for mesa.. I mean if you are using igt you are > > > probably on the latest anyways.. I'm not sure why Daniel is so > > > concerned about that.. > > > > > > (but dependency bumps to something that doesn't exist yet should > > > perhaps be avoided) > > > > I'd like to avoid massive depency loops for igt tests so that I can merge > > the testcase right when the patches land in -nightly. Otherwise there's > > always a small delay involved where regression can creep in. Also if I > > have to update libdrm every time I update igt that's annoying since > > without that I don't have to install/update anything at all - I run igt > > in-place. And we've used the LOCAL_ prefixes for pretty much every abi > > addition in igt tests thus far. > > -Daniel > > I understand that and it certainly makes sense when libdrm is only > providing defines or structs. But as I said, in this case there is > code in libdrm (the wrapper) that we could test as part of the > complete path. Are you recommending that I implement duplicate > wrapper functions in igt with the local prefix? Sorry I totally didn't realize that. Generally we don't have a lot of igt testcase for libdrm really, imo it's usually simpler to just add the interface to each part. Since this is such a simple one there's no need to have a low-level test and the libdrm test on top, but that's what I'd do if there's something worth testing in libdrm. Because for complex functionality I really want to get the bare-metal tests in together with the kernel part. Stalling for libdrm release could take longer. And yes, personally I'd just have open-coded the getparam call here in igt, but that's just a bikeshed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Device loses its IRQ number on driver unload?
>> >> I think with modesetting driver it shouldn't be a problem anymore. >> >> Dave. > > So what's the preferred remedy here? should I file a bug against the > above commit or should we go ahead modifying > the DRM drivers? I'd file against that first, and maybe see why it clears the value. Dave.
[PATCH 1/2] drm/fourcc: 64 #defines need ULL postfix
I have no idea about the exact rules, but this angered Dave's 32bit rhel gcc. Reported-by: Dave Airlie Signed-off-by: Daniel Vetter --- include/uapi/drm/drm_fourcc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index e6efac23c7ea..07735822a28f 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -151,7 +151,7 @@ /* add more to the end as needed */ #define fourcc_mod_code(vendor, val) \ - u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffL)) + u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 0x00ffULL)) /* * Format Modifier tokens: -- 2.1.4
[PATCH 2/2] drm/i915: Add ULL postfix to VGT_MAGIC constant
Without this Dave's 32bit rhel compiler is annoyed. Don't ask me about the exact rules for this stuff though, but this should be safe. Reported-by: Dave Airlie Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_vgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h index 0db9ccf32605..97a88b5f6a26 100644 --- a/drivers/gpu/drm/i915/i915_vgpu.h +++ b/drivers/gpu/drm/i915/i915_vgpu.h @@ -32,7 +32,7 @@ * The following structure pages are defined in GEN MMIO space * for virtualization. (One page for now) */ -#define VGT_MAGIC 0x4776544776544776 /* 'vGTvGTvG' */ +#define VGT_MAGIC 0x4776544776544776ULL/* 'vGTvGTvG' */ #define VGT_VERSION_MAJOR 1 #define VGT_VERSION_MINOR 0 -- 2.1.4
[PATCH 0/4] drm: constify all helper_private/func pointers
On Tue, Mar 10, 2015 at 05:34:35PM +0200, Ville Syrjälä wrote: > On Tue, Mar 10, 2015 at 05:14:58PM +0200, Jani Nikula wrote: > > On Tue, 10 Mar 2015, ville.syrjala at linux.intel.com wrote: > > > Make the helper function pointer structs const to make it clear they > > > should not be modified. > > > > So why not fix this once and for all? See the following patches. > > Why not indeed. I was being lazy and only hit the ones that caught my > eye while crawling through the atomic helper stuff. Well I pulled in your patch to drm-misc. Sounds like Jani still needs to fine-tune his cocci. -Daniel > > > > > This was quick cocci, can be split by driver too if so desired. > > > > BR, > > Jani. > > > > > > Jani Nikula (4): > > drm: constify all struct drm_encoder_helper_funcs pointers > > drm: constify all struct drm_connector_helper_funcs pointers > > drm: constify all struct drm_crtc_helper_funcs pointers > > drm: make encoder/connector/crtc helper_private a const pointer > > > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++-- > > drivers/gpu/drm/drm_atomic_helper.c | 24 > > > > drivers/gpu/drm/drm_crtc_helper.c | 24 > > > > drivers/gpu/drm/drm_fb_helper.c | 8 > > drivers/gpu/drm/drm_plane_helper.c | 2 +- > > drivers/gpu/drm/drm_probe_helper.c | 2 +- > > drivers/gpu/drm/exynos/exynos_hdmi.c| 2 +- > > drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- > > drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- > > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- > > drivers/gpu/drm/gma500/gma_display.c| 10 +- > > drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +- > > drivers/gpu/drm/gma500/mdfld_intel_display.c| 2 +- > > drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +- > > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- > > drivers/gpu/drm/gma500/psb_intel_display.c | 2 +- > > drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- > > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > > drivers/gpu/drm/nouveau/dispnv04/dac.c | 6 +++--- > > drivers/gpu/drm/nouveau/dispnv04/dfp.c | 6 +++--- > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +++--- > > drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 ++-- > > drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++-- > > drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++-- > > drivers/gpu/drm/qxl/qxl_drv.c | 2 +- > > drivers/gpu/drm/radeon/radeon_connectors.c | 16 > > drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +- > > include/drm/drm_crtc.h | 6 +++--- > > include/drm/drm_crtc_helper.h | 6 +++--- > > 30 files changed, 81 insertions(+), 81 deletions(-) > > > > -- > > 2.1.4 > > -- > Ville Syrjälä > Intel OTC > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/plane-helper: Fixup mismerge
I somehow manage to screw up applying Laurent's patch in eca93e28c256:
"drm: Check in setcrtc if the primary plane supports the fb pixel
format". It was a conflict with
commit 3461b30b3e171e16498f3d7bc59ab703aec475c8
Author: Daniel Vetter
Date: Thu Mar 5 10:32:44 2015 +0100
drm/plane-helper: unexport drm_primary_helper_create_plane
and I just didn't check that the solution from wiggle made sense.
Cc: Dan Carpenter
Cc: laurent.pinchart at ideasonboard.com
Reported-by: Dan Carpenter
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index b62b03635050..33807e0adac7 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -353,13 +353,14 @@ static struct drm_plane *create_primary_plane(struct
drm_device *dev)
if (primary == NULL) {
DRM_DEBUG_KMS("Failed to allocate primary plane\n");
return NULL;
- /*
-* Remove the format_default field from drm_plane when dropping
-* this helper.
-*/
- primary->format_default = true;
}
+ /*
+* Remove the format_default field from drm_plane when dropping
+* this helper.
+*/
+ primary->format_default = true;
+
/* possible_crtc's will be filled in later by crtc_init */
ret = drm_universal_plane_init(dev, primary, 0,
&drm_primary_helper_funcs,
--
2.1.4
commit 440fd52 drm/mm: Support 4GiB and larger ranges oops on 32bit kernel
[cc'ing lists] On Tue, Mar 10, 2015 at 07:17:22PM +0100, Krzysztof Kolasa wrote: > System ( 32bit, Intel 945GM ) hangs after some short time, oops: > > [ cut here ] > kernel BUG at drivers/gpu/drm/drm_mm.c:305! > invalid opcode: [#1] SMP > Modules linked in: arc4 md4 cfg80211 8192cu(O) pci_stub vboxpci(O) > vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_si3054 > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel > snd_hda_controller snd_hda_codec snd_hwdep snd_pcm microcode > snd_seq_midi snd_seq_midi_event snd_rawmidi joydev serio_raw snd_seq > snd_timer snd_seq_device rfcomm bnep bluetooth i915 snd lpc_ich > drm_kms_helper soundcore drm i2c_algo_bit parport_pc ppdev video > mac_hid coretemp lp parport nls_utf8 cifs usb_storage psmouse > 8139too 8139cp mii > CPU: 0 PID: 1165 Comm: Xorg Tainted: G O > 4.0.0-rc3-winsoft-x86+ #11 > Hardware name: FUJITSU SIEMENS AMILO Pro Edition V3405/AMILO > Pro Edition V3405, BIOS R01-B0E03/20/2007 > task: f64e0db0 ti: f4566000 task.ti: f4566000 > EIP: 0060:[] EFLAGS: 00213206 CPU: 0 > EIP is at drm_mm_insert_node_in_range_generic+0x432/0x4d0 [drm] > EAX: 0100 EBX: 00c78000 ECX: f6d4c908 EDX: > ESI: f6d4c900 EDI: f6d4c900 EBP: f4567c78 ESP: f4567bf8 > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > CR0: 8005003b CR2: b4a02000 CR3: 345f2000 CR4: 07f0 > Stack: > f4567c64 0080 0080 f6d4c900 f4882700 > 00a88000 1000 00478000 > 00f0 f472c33c > Call Trace: > [] i915_gem_object_pin_view+0x3ce/0x840 [i915] > [] ? i915_gem_obj_lookup_or_create_vma_view+0x41/0x160 [i915] > [] i915_gem_execbuffer_reserve_vma.isra.11+0x62/0x100 [i915] > [] i915_gem_execbuffer_reserve+0x291/0x2e0 [i915] > [] i915_gem_do_execbuffer.isra.16+0x4f0/0xd10 [i915] > [] ? poll_select_copy_remaining+0x100/0x100 > [] ? __kmalloc+0x4d/0x190 > [] i915_gem_execbuffer2+0x8b/0x2c0 [i915] > [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915] > [] drm_ioctl+0x1b7/0x510 [drm] > [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915] > [] ? ktime_get_ts64+0x52/0x1a0 > [] ? drm_getmap+0xb0/0xb0 [drm] > [] do_vfs_ioctl+0x30a/0x530 > [] ? _copy_to_user+0x26/0x30 > [] ? ktime_get_ts64+0x52/0x1a0 > [] ? __fget_light+0x22/0x60 > [] SyS_ioctl+0x60/0x90 > [] sysenter_do_call+0x12/0x12 > Code: ff ff 3b 55 e8 8d 74 26 00 77 10 73 04 0f 0b 66 90 3b 45 e4 90 > 8d 74 26 00 72 f2 8b 75 94 03 46 20 13 56 24 3b 55 f0 72 0d 76 06 > <0f> 0b 8d 74 26 00 3b 45 ec 77 f5 39 55 c4 77 10 73 04 0f 0b 66 > EIP: [] drm_mm_insert_node_in_range_generic+0x432/0x4d0 > [drm] SS:ESP 0068:f4567bf8 > ---[ end trace 4648f53699b9eb32 ]--- > > after revert commit 440fd52 system working OK > > Krzysztof > -- Chris Wilson, Intel Open Source Technology Centre
[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 05:47 PM, Daniel Vetter wrote: > On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: >> On 03/10/2015 03:35 PM, Daniel Vetter wrote: >>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: > On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >> index 151a050..38f83a0 100644 >> --- a/drivers/gpu/drm/Kconfig >> +++ b/drivers/gpu/drm/Kconfig >> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER >> help >>FBDEV helpers for KMS drivers. >> >> +config DRM_FBDEV_EMULATION >> +bool "Enable legacy fbdev support for your modesetting driver" >> +depends on DRM >> +select DRM_KMS_HELPER >> +select DRM_KMS_FB_HELPER >> +select FB_SYS_FILLRECT >> +select FB_SYS_COPYAREA >> +select FB_SYS_IMAGEBLIT >> +select FB_SYS_FOPS >> +select FB_CFB_FILLRECT >> +select FB_CFB_COPYAREA >> +select FB_CFB_IMAGEBLIT >> +default y >> +help >> + Choose this option if you have a need for the legacy fbdev >> + support. Note that this support also provide the linux console >> + support on top of your modesetting driver. > > Maybe clarify that for linux console support you also need > CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? >>> >>> Hm right I've missed that. Reminds me that you need one more patch at the >>> end to remove all the various select DRM_KMS_FB_HELPER from all drm >>> drivers. Otherwise this knob here won't work by default if you e.g. select >>> radeon. In general we can't mix explicit options with menu entries with a >>> select. >> >> I was trying that out. Removing DRM_KMS_FB_HELPER and having >> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in >> their respective xyz_fbdev.c files. > > But with the stubbed out functions that should work, right? Why doesn't > it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. > >> Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and >> replace them with 'select DRM_FBDEV_EMULATION'? >> >> Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds >> for fb related function calls/declarations in each driver, something that's >> already done for i915 and msm drivers. > > The problem with the patch as-is the massive amounts of selects the FB > helper still has. We need to get rid of them so that when you disable > fbdev emulation you can indeed disable fbcon and the entire fbdev > subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER > and moving all the selects to DRM_FBDEV_EMULATION should work out? If that > doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #41 from Christian König --- (In reply to Alex Deucher from comment #40) > (In reply to Christian König from comment #39) > > Created attachment 113654 [details] [review] [review] > > Possible fix > > > > Wow, nice catch! > > > > I have to admit that i just copied the sleep mode handling from previous > > generations. > > > > Well, in this case please everybody on this bug take a look at the attached > > patch and see if it does the trick. > > > > Thanks a lot for the help, > > Christian. > > Do you want me to pick this up for -fixes? I hoped for some more feedback before we do this, but yeah go ahead. The patch shouldn't break anything and so should be save for -fixes. Just add the link to this bugreport. Thanks, Christian. -- 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/20150311/e169ce59/attachment.html>
[Bug 84920] Radeon UVD error
https://bugs.freedesktop.org/show_bug.cgi?id=84920 --- Comment #4 from Christian König --- (In reply to Alexander from comment #3) > I observe the same issue on virtual machine with VGA passthrough. The > virtual guest runs only Kodi media center session with autologin from > lightdm display manager. > The issue is easily reproducible when I do fast forward (FF). Do you run Kodi with the VA-API wrapper or the native VDPAU backend? The VA-API wrapper isn't really supported any more, so the issue is most likely somewhere there. What happens here is that the hardware runs out of UVD handles because the software stack is trying to play a lot of streams at the same time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/0125e425/attachment.html>
GSoC 2015 OpenGL
Hey, By way of introduction, my name is Alex Mourtziapis and i am a student at the Department of Computing Science at the University of Piraeus,in Greece.I have noticed GL/GLSL tests at (http://www.x.org/wiki/SummerOfCodeIdeas/) and i would like to give it a bash in this years GSoC. A little bit information about the project 'd be helpful cause some parts are unclear. I have knowledge in proramming and other tools(git,etc) and i also have published an Android Game(Nitrocity https://play.google.com/store/apps/details?id=com.ShunlessStudio.Nitrocity&hl=en ).Also , i have worked in the past with vast frameworks like cinder and openframeworks.Additionally i would like to know anything else that is not directly part of the project, but related. maybe elaborate on the working alone part ? Regards, Alex -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/247b47e6/attachment.html>
Device loses its IRQ number on driver unload?
On 03/11/2015 08:22 AM, Dave Airlie wrote: >>> I think with modesetting driver it shouldn't be a problem anymore. >>> >>> Dave. >> So what's the preferred remedy here? should I file a bug against the >> above commit or should we go ahead modifying >> the DRM drivers? > I'd file against that first, and maybe see why it clears the value. > > Dave. https://bugzilla.kernel.org/show_bug.cgi?id=94721 /Thomas
[PATCH v2 1/2] drm/bridge: dw-hdmi: support optional supply regulators
Hi Heiko, Am Dienstag, den 10.03.2015, 22:45 +0100 schrieb Heiko Stuebner: > At least the Rockchip variant of the dw_hdmi can have controllable power > supplies > providing 1.0 and 1.8V. Therefore add the possibility for the generic bridge > driver to enable supplies provided by the hw-specific drivers. > > Signed-off-by: Heiko Stuebner > --- > changes since v1: > - follow suggestion from Russell King to keep regulator handling local > to the rockchip implementation for the time being and only generalize > when a real second implementation needs regulator handling > > .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 5 > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 > +- > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > index a905c14..bb74640 100644 > --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > @@ -22,6 +22,11 @@ Optional properties > - 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" > > +Optional supplies: > +rockchip,rk3288-dw-hdmi handles two optional power supplies: > +- avdd1v0-supply: 1.0V power supply > +- avdd1v8-supply: 1.8V power supply Are these the names used in the Rockchip documentation? Since the older implementation on i.MX6 uses 1.1V (HDMI_VP) and 2.5V (HDMI_VPH), I wonder whether each SoC should use their own name or whether there should be common names that don't include the voltage. I don't have the Synopsys HDMI TX docs, but I've seen avddhv and avddlv used of other cores' analog supplies. regards Philipp
[PATCH 0/9] drm: constify all helper_private/func pointers
Per driver and core constification with cocci, final patch manually. Inspired by Ville in [1]. BR, Jani. [1] http://mid.gmane.org/1425990920-17379-1-git-send-email-ville.syrjala at linux.intel.com Jani Nikula (9): drm/exynos: constify all struct drm_*_helper funcs pointers drm/mgag200: constify all struct drm_*_helper funcs pointers drm/gma500: constify all struct drm_*_helper funcs pointers drm/radeon: constify all struct drm_*_helper funcs pointers drm/atmel-hlcdc: constify all struct drm_*_helper funcs pointers drm/nouveau: constify all struct drm_*_helper funcs pointers drm/qxl: constify all struct drm_*_helper funcs pointers drm/drm: constify all struct drm_*_helper funcs pointers drm: make crtc/encoder/connector/plane helper_private a const pointer drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++-- drivers/gpu/drm/drm_crtc_helper.c | 24 drivers/gpu/drm/drm_fb_helper.c | 8 drivers/gpu/drm/drm_plane_helper.c | 4 ++-- drivers/gpu/drm/drm_probe_helper.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c| 2 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/gma_display.c| 10 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +- drivers/gpu/drm/gma500/mdfld_intel_display.c| 2 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- drivers/gpu/drm/gma500/psb_intel_display.c | 2 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv04/dac.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +++--- drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 ++-- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++-- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/radeon/radeon_connectors.c | 16 drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +- include/drm/drm_crtc.h | 8 include/drm/drm_crtc_helper.h | 6 +++--- include/drm/drm_plane_helper.h | 2 +- 30 files changed, 70 insertions(+), 70 deletions(-) -- 2.1.4
[PATCH 1/9] drm/exynos: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 229b3613c60b..c8952b057879 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2101,7 +2101,7 @@ static void hdmi_dpms(struct exynos_drm_display *display,
int mode)
struct hdmi_context *hdata = display_to_hdmi(display);
struct drm_encoder *encoder = hdata->encoder;
struct drm_crtc *crtc = encoder->crtc;
- struct drm_crtc_helper_funcs *funcs = NULL;
+ const struct drm_crtc_helper_funcs *funcs = NULL;
DRM_DEBUG_KMS("mode %d\n", mode);
--
2.1.4
[PATCH 2/9] drm/mgag200: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 9872ba9abf1a..6e84df9369a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1222,7 +1222,7 @@ static void mga_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = dev->dev_private;
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
u8 tmp;
if (mdev->type == G200_WB)
--
2.1.4
[PATCH 3/9] drm/gma500: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +-
drivers/gpu/drm/gma500/gma_display.c | 10 +-
drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +-
drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 66727328832d..7d47b3d5cc0d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -823,7 +823,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
/* Flush the plane changes */
{
- struct drm_crtc_helper_funcs *crtc_funcs =
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
crtc_funcs->mode_set_base(crtc, x, y, old_fb);
}
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 4268bf210034..6b1d3340ba14 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -195,7 +195,7 @@ static int cdv_hdmi_set_property(struct drm_connector
*connector,
encoder->crtc->x, encoder->crtc->y,
encoder->crtc->primary->fb))
return -1;
} else {
- struct drm_encoder_helper_funcs *helpers
+ const struct drm_encoder_helper_funcs *helpers
= encoder->helper_private;
helpers->mode_set(encoder, &crtc->saved_mode,
&crtc->saved_adjusted_mode);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 0b770396548c..211069b2b951 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -505,7 +505,7 @@ static int cdv_intel_lvds_set_property(struct drm_connector
*connector,
else
gma_backlight_set(encoder->dev, value);
} else if (!strcmp(property->name, "DPMS") && encoder) {
- struct drm_encoder_helper_funcs *helpers =
+ const struct drm_encoder_helper_funcs *helpers =
encoder->helper_private;
helpers->dpms(encoder, value);
}
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index 9bb9bddd881a..001b450b27b3 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -501,20 +501,20 @@ bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
void gma_crtc_prepare(struct drm_crtc *crtc)
{
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
}
void gma_crtc_commit(struct drm_crtc *crtc)
{
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_ON);
}
void gma_crtc_disable(struct drm_crtc *crtc)
{
struct gtt_range *gt;
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
@@ -656,7 +656,7 @@ void gma_crtc_restore(struct drm_crtc *crtc)
void gma_encoder_prepare(struct drm_encoder *encoder)
{
- struct drm_encoder_helper_funcs *encoder_funcs =
+ const struct drm_encoder_helper_funcs *encoder_funcs =
encoder->helper_private;
/* lvds has its own version of prepare see psb_intel_lvds_prepare */
encoder_funcs->dpms(encoder, DRM_MODE_DPMS_OFF);
@@ -664,7 +664,7 @@ void gma_encoder_prepare(struct drm_encoder
[PATCH 4/9] drm/radeon: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/radeon/radeon_connectors.c | 16
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 27def67cb6be..7c44c9d929d6 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -135,7 +135,7 @@ int radeon_get_monitor_bpc(struct drm_connector *connector)
if (connector->display_info.bpc)
bpc = connector->display_info.bpc;
else if (ASIC_IS_DCE41(rdev) || ASIC_IS_DCE5(rdev)) {
- struct drm_connector_helper_funcs *connector_funcs =
+ const struct drm_connector_helper_funcs
*connector_funcs =
connector->helper_private;
struct drm_encoder *encoder =
connector_funcs->best_encoder(connector);
struct radeon_encoder *radeon_encoder =
to_radeon_encoder(encoder);
@@ -225,7 +225,7 @@ radeon_connector_update_scratch_regs(struct drm_connector
*connector, enum drm_c
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *best_encoder = NULL;
struct drm_encoder *encoder = NULL;
- struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
+ const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
int i;
@@ -702,7 +702,7 @@ static int radeon_connector_set_property(struct
drm_connector *connector, struct
if (connector->encoder)
radeon_encoder = to_radeon_encoder(connector->encoder);
else {
- struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
+ const struct drm_connector_helper_funcs
*connector_funcs = connector->helper_private;
radeon_encoder =
to_radeon_encoder(connector_funcs->best_encoder(connector));
}
@@ -896,7 +896,7 @@ static int radeon_lvds_set_property(struct drm_connector
*connector,
if (connector->encoder)
radeon_encoder = to_radeon_encoder(connector->encoder);
else {
- struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
+ const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
radeon_encoder =
to_radeon_encoder(connector_funcs->best_encoder(connector));
}
@@ -964,7 +964,7 @@ radeon_vga_detect(struct drm_connector *connector, bool
force)
struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder;
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
bool dret = false;
enum drm_connector_status ret = connector_status_disconnected;
int r;
@@ -1094,7 +1094,7 @@ static enum drm_connector_status
radeon_tv_detect(struct drm_connector *connector, bool force)
{
struct drm_encoder *encoder;
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
enum drm_connector_status ret = connector_status_disconnected;
int r;
@@ -1174,7 +1174,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder = NULL;
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
int i, r;
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false, broken_edid = false;
@@ -1635,7 +1635,7 @@ radeon_dp_detect(struct drm_connector *connector, bool
force)
if (radeon_ddc_probe(radeon_connector, true)) /* try
DDC */
ret = connector_status_connected;
[PATCH 5/9] drm/atmel-hlcdc: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index c4bb1f9f95c6..e79afe7d3459 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -570,7 +570,7 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
drm_modeset_lock_all(drm_dev);
list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head) {
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
if (crtc->enabled) {
crtc_funcs->disable(crtc);
/* save enable state for resume */
@@ -591,7 +591,7 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
drm_modeset_lock_all(drm_dev);
list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head) {
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
if (crtc->enabled) {
crtc->enabled = false;
crtc_funcs->enable(crtc);
--
2.1.4
[PATCH v2 1/2] drm/bridge: dw-hdmi: support optional supply regulators
Hi Philipp, Am Mittwoch, 11. März 2015, 10:28:29 schrieb Philipp Zabel: > Am Dienstag, den 10.03.2015, 22:45 +0100 schrieb Heiko Stuebner: > > At least the Rockchip variant of the dw_hdmi can have controllable power > > supplies providing 1.0 and 1.8V. Therefore add the possibility for the > > generic bridge driver to enable supplies provided by the hw-specific > > drivers. > > > > Signed-off-by: Heiko Stuebner > > --- > > changes since v1: > > - follow suggestion from Russell King to keep regulator handling local > > > > to the rockchip implementation for the time being and only generalize > > when a real second implementation needs regulator handling > > > > .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 5 > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 > > +- 2 files changed, 36 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt index > > a905c14..bb74640 100644 > > --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt > > @@ -22,6 +22,11 @@ Optional properties > > > > - 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" > > > > +Optional supplies: > > +rockchip,rk3288-dw-hdmi handles two optional power supplies: > > +- avdd1v0-supply: 1.0V power supply > > +- avdd1v8-supply: 1.8V power supply > > Are these the names used in the Rockchip documentation? > > Since the older implementation on i.MX6 uses 1.1V (HDMI_VP) and 2.5V > (HDMI_VPH), I wonder whether each SoC should use their own name or > whether there should be common names that don't include the voltage. > I don't have the Synopsys HDMI TX docs, but I've seen avddhv and avddlv > used of other cores' analog supplies. The pins of the soc connected to the regulators are named: HDMI_AVDD_1V0 HDMI_AVDD_1V8 The datasheet only calls both "DC supply voltage for Analog part of HDMI" and never mentions them again. The databook of the IP block itself seems to really call this VPH and VP as phy supplies, but documentation is a bit sparse about them. I guess as we already use the databook clock-names I should also switch to the databook supply names (avdd1v0 -> vp and avdd1v8 -> vph). Heiko
[PATCH 6/9] drm/nouveau: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv04/dac.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
7 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 542bb266a0ab..3d96b49fe662 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -703,7 +703,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
if (nv_two_heads(dev))
NVSetOwner(dev, nv_crtc->index);
@@ -724,7 +724,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
static void nv_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
- struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
nouveau_hw_load_state(dev, nv_crtc->index,
&nv04_display(dev)->mode_reg);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index d7b495a5f30c..af7249ca0f4b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -358,7 +358,7 @@ static bool nv04_dac_mode_fixup(struct drm_encoder *encoder,
static void nv04_dac_prepare(struct drm_encoder *encoder)
{
- struct drm_encoder_helper_funcs *helper = encoder->helper_private;
+ const struct drm_encoder_helper_funcs *helper = encoder->helper_private;
struct drm_device *dev = encoder->dev;
int head = nouveau_crtc(encoder->crtc)->index;
@@ -409,7 +409,7 @@ static void nv04_dac_commit(struct drm_encoder *encoder)
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_drm *drm = nouveau_drm(encoder->dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
- struct drm_encoder_helper_funcs *helper = encoder->helper_private;
+ const struct drm_encoder_helper_funcs *helper = encoder->helper_private;
helper->dpms(encoder, DRM_MODE_DPMS_ON);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index f6ca343fd34a..7cfb0cbc9b6e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -244,7 +244,7 @@ static void nv04_dfp_prepare_sel_clk(struct drm_device *dev,
static void nv04_dfp_prepare(struct drm_encoder *encoder)
{
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
- struct drm_encoder_helper_funcs *helper = encoder->helper_private;
+ const struct drm_encoder_helper_funcs *helper = encoder->helper_private;
struct drm_device *dev = encoder->dev;
int head = nouveau_crtc(encoder->crtc)->index;
struct nv04_crtc_reg *crtcstate = nv04_display(dev)->mode_reg.crtc_reg;
@@ -445,7 +445,7 @@ static void nv04_dfp_commit(struct drm_encoder *encoder)
{
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_encoder_helper_funcs *helper = encoder->helper_private;
+ const struct drm_encoder_helper_funcs *helper = encoder->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct dcb_output *dcbe = nv_encoder->dcb;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index f96237ef2a6b..4131be5507ab 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -109,7 +109,7 @@ nv04_display_create(struct drm_device *dev)
crtc->funcs->save(crtc);
list_for_each_entry(encoder, &dev->mode_config.encoder_list
[PATCH 7/9] drm/qxl: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 1d9b80c91a15..e2d07085b6a5 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -102,7 +102,7 @@ static int qxl_drm_freeze(struct drm_device *dev)
/* unpin the front buffers */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
if (crtc->enabled)
(*crtc_funcs->disable)(crtc);
}
--
2.1.4
[PATCH 8/9] drm/drm: constify all struct drm_*_helper funcs pointers
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_encoder_helper_funcs *
)
@@
@@
(
const struct drm_connector_helper_funcs *
|
- struct drm_connector_helper_funcs *
+ const struct drm_connector_helper_funcs *
)
@@
@@
(
const struct drm_plane_helper_funcs *
|
- struct drm_plane_helper_funcs *
+ const struct drm_plane_helper_funcs *
)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_helper.c | 24
drivers/gpu/drm/drm_fb_helper.c| 8
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
drivers/gpu/drm/drm_probe_helper.c | 2 +-
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 3053aab968f9..e4a55bbe698d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -161,7 +161,7 @@ EXPORT_SYMBOL(drm_helper_crtc_in_use);
static void
drm_encoder_disable(struct drm_encoder *encoder)
{
- struct drm_encoder_helper_funcs *encoder_funcs =
encoder->helper_private;
+ const struct drm_encoder_helper_funcs *encoder_funcs =
encoder->helper_private;
if (encoder->bridge)
encoder->bridge->funcs->disable(encoder->bridge);
@@ -191,7 +191,7 @@ static void __drm_helper_disable_unused_functions(struct
drm_device *dev)
}
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
crtc->enabled = drm_helper_crtc_in_use(crtc);
if (!crtc->enabled) {
if (crtc_funcs->disable)
@@ -229,7 +229,7 @@ EXPORT_SYMBOL(drm_helper_disable_unused_functions);
static void
drm_crtc_prepare_encoders(struct drm_device *dev)
{
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
struct drm_encoder *encoder;
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
@@ -271,8 +271,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct drm_display_mode *adjusted_mode, saved_mode;
- struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
int saved_x, saved_y;
bool saved_enabled;
struct drm_encoder *encoder;
@@ -472,7 +472,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
bool fb_changed = false; /* if true and !mode_changed just do a flip */
struct drm_connector *save_connectors, *connector;
int count = 0, ro, fail = 0;
- struct drm_crtc_helper_funcs *crtc_funcs;
+ const struct drm_crtc_helper_funcs *crtc_funcs;
struct drm_mode_set save_set;
int ret;
int i;
@@ -572,7 +572,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
/* a) traverse passed in connector list and get encoders for them */
count = 0;
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- struct drm_connector_helper_funcs *connector_funcs =
+ const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
new_encoder = connector->encoder;
for (ro = 0; ro < set->num_connectors; ro++) {
@@ -732,7 +732,7 @@ static int drm_helper_choose_encoder_dpms(struct
drm_encoder *encoder)
static void drm_helper_encoder_dpms(struct drm_encoder *encoder, int mode)
{
struct drm_bridge *bridge = encoder->bridge;
- struct drm_encoder_helper_funcs *encoder_funcs;
+ const struct drm_encoder_helper_funcs *encoder_funcs;
if (bridge) {
if (mode == DRM_MODE_DPMS_ON)
@@ -794,7 +794,7 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
/* from off to on, do crtc then encoder */
if (mode < old_dpms) {
if (crtc) {
- struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
+ const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
if (crtc_funcs->dpms)
(*crtc_funcs->dpms) (crtc,
drm_helper_choose_crtc_dpms(crtc));
@@ -808,7 +808,7 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
if (encode
[PATCH 9/9] drm: make crtc/encoder/connector/plane helper_private a const pointer
They're only used to store const pointers anyway. This helps to keep
Ville and the compiler happy.
Signed-off-by: Jani Nikula
---
include/drm/drm_crtc.h | 8
include/drm/drm_crtc_helper.h | 6 +++---
include/drm/drm_plane_helper.h | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adc9ea5acf02..db1059d20a9c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -467,7 +467,7 @@ struct drm_crtc {
int framedur_ns, linedur_ns, pixeldur_ns;
/* if you are using the helper */
- void *helper_private;
+ const void *helper_private;
struct drm_object_properties properties;
@@ -597,7 +597,7 @@ struct drm_encoder {
struct drm_crtc *crtc;
struct drm_bridge *bridge;
const struct drm_encoder_funcs *funcs;
- void *helper_private;
+ const void *helper_private;
};
/* should we poll this connector for connects and disconnects */
@@ -701,7 +701,7 @@ struct drm_connector {
/* requested DPMS state */
int dpms;
- void *helper_private;
+ const void *helper_private;
/* forced on connector */
struct drm_cmdline_mode cmdline_mode;
@@ -864,7 +864,7 @@ struct drm_plane {
enum drm_plane_type type;
- void *helper_private;
+ const void *helper_private;
struct drm_plane_state *state;
};
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 92d5135b55d2..c8fc187061de 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -197,19 +197,19 @@ extern void drm_helper_mode_fill_fb_struct(struct
drm_framebuffer *fb,
static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
const struct drm_crtc_helper_funcs
*funcs)
{
- crtc->helper_private = (void *)funcs;
+ crtc->helper_private = funcs;
}
static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
const struct drm_encoder_helper_funcs
*funcs)
{
- encoder->helper_private = (void *)funcs;
+ encoder->helper_private = funcs;
}
static inline void drm_connector_helper_add(struct drm_connector *connector,
const struct
drm_connector_helper_funcs *funcs)
{
- connector->helper_private = (void *)funcs;
+ connector->helper_private = funcs;
}
extern void drm_helper_resume_force_mode(struct drm_device *dev);
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index e48157a5a59c..96e16283afb9 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -76,7 +76,7 @@ struct drm_plane_helper_funcs {
static inline void drm_plane_helper_add(struct drm_plane *plane,
const struct drm_plane_helper_funcs
*funcs)
{
- plane->helper_private = (void *)funcs;
+ plane->helper_private = funcs;
}
extern int drm_plane_helper_check_update(struct drm_plane *plane,
--
2.1.4
[PATCH] clk: provide clk_is_match() dummy for non-common clk
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> ARM randconfig build tests found a new error for configurations
> with COMMON_CLK disabled but HAS_CLK selected by the platform:
>
> ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
>
> This moves the declaration around, so this case is covered
> by the existing static inline helper function.
>
> Signed-off-by: Arnd Bergmann
> Fixes: c69e182e51d89 ("clk: introduce clk_is_match")
>
> BTW, we have a preexisting problem in clk_get_parent,
> clk_round_rate and clk_set_parent, which I've worked around in
> my randconfig builds so far. Should we do that the same way?
NAK, as Uwe points out, you didn't address my comment.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[PATCH 0/9] drm: constify all helper_private/func pointers
Sounds logical to me to do so. Patch #4 and #9 are Reviewed-by: Christian König Regards, Christian. On 11.03.2015 10:50, Jani Nikula wrote: > Per driver and core constification with cocci, final patch > manually. Inspired by Ville in [1]. > > BR, > Jani. > > [1] http://mid.gmane.org/1425990920-17379-1-git-send-email-ville.syrjala at > linux.intel.com > > > Jani Nikula (9): >drm/exynos: constify all struct drm_*_helper funcs pointers >drm/mgag200: constify all struct drm_*_helper funcs pointers >drm/gma500: constify all struct drm_*_helper funcs pointers >drm/radeon: constify all struct drm_*_helper funcs pointers >drm/atmel-hlcdc: constify all struct drm_*_helper funcs pointers >drm/nouveau: constify all struct drm_*_helper funcs pointers >drm/qxl: constify all struct drm_*_helper funcs pointers >drm/drm: constify all struct drm_*_helper funcs pointers >drm: make crtc/encoder/connector/plane helper_private a const pointer > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 4 ++-- > drivers/gpu/drm/drm_crtc_helper.c | 24 > > drivers/gpu/drm/drm_fb_helper.c | 8 > drivers/gpu/drm/drm_plane_helper.c | 4 ++-- > drivers/gpu/drm/drm_probe_helper.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c| 2 +- > drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- > drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- > drivers/gpu/drm/gma500/gma_display.c| 10 +- > drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +- > drivers/gpu/drm/gma500/mdfld_intel_display.c| 2 +- > drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +- > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_display.c | 2 +- > drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- > drivers/gpu/drm/nouveau/dispnv04/dac.c | 4 ++-- > drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 ++-- > drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +++--- > drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 ++-- > drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++-- > drivers/gpu/drm/qxl/qxl_drv.c | 2 +- > drivers/gpu/drm/radeon/radeon_connectors.c | 16 > drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +- > include/drm/drm_crtc.h | 8 > include/drm/drm_crtc_helper.h | 6 +++--- > include/drm/drm_plane_helper.h | 2 +- > 30 files changed, 70 insertions(+), 70 deletions(-) >
[PATCH 4/8] pwm: atmel-hlcdc: fix struct clk pointer comparing
On Wed, Feb 25, 2015 at 10:53:34PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
> simply comparing two pointers. That's because with the per-user clk
> change, a brand new struct clk is created whenever clients try to look
> up the clock by calling clk_get() or sister functions like clk_get_sys()
> and of_clk_get(). This changes the original behavior where the struct
> clk is only created for once when clock driver registers the clock to
> CCF in the first place. The net change here is before commit
> 035a61c314eb the struct clk pointer is unique for given hardware
> clock, while after the commit the pointers returned by clk lookup calls
> become different for the same hardware clock.
>
> That said, the struct clk pointer comparing in the code doesn't work any
> more. Call helper function clk_is_match() instead to fix the problem.
>
> Signed-off-by: Shawn Guo
> ---
> drivers/pwm/pwm-atmel-hlcdc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/8ec93d5f/attachment.sig>
[Bug 88968] Unit mouseover in World of Warcraft (wine, D3D) freezes up the entire system
https://bugs.freedesktop.org/show_bug.cgi?id=88968 --- Comment #5 from rubykuby at gmail.com --- This bug is no longer reproducible on my system. Two variables have changed: I'm now running Mesa 10.4.6 (small point update) & WoW has had an update to version 6.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/02132629/attachment.html>
[PATCH] clk: provide clk_is_match() dummy for non-common clk
Hey Russell,
On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > ARM randconfig build tests found a new error for configurations
> > with COMMON_CLK disabled but HAS_CLK selected by the platform:
> >
> > ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
> >
> > This moves the declaration around, so this case is covered
> > by the existing static inline helper function.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: c69e182e51d89 ("clk: introduce clk_is_match")
> >
> > BTW, we have a preexisting problem in clk_get_parent,
> > clk_round_rate and clk_set_parent, which I've worked around in
> > my randconfig builds so far. Should we do that the same way?
>
> NAK, as Uwe points out, you didn't address my comment.
You commented on the patch that is c69e182e51d8 ("clk: introduce
clk_is_match") now in next. Arnd just moved this around.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 3/9] drm/gma500: constify all struct drm_*_helper funcs pointers
On Wed, Mar 11, 2015 at 10:51 AM, Jani Nikula wrote:
> They are not to be modified.
>
> Generated using the semantic patch:
>
> @@
> @@
> (
> const struct drm_crtc_helper_funcs *
> |
> - struct drm_crtc_helper_funcs *
> + const struct drm_crtc_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_encoder_helper_funcs *
> |
> - struct drm_encoder_helper_funcs *
> + const struct drm_encoder_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_connector_helper_funcs *
> |
> - struct drm_connector_helper_funcs *
> + const struct drm_connector_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_plane_helper_funcs *
> |
> - struct drm_plane_helper_funcs *
> + const struct drm_plane_helper_funcs *
> )
>
> Signed-off-by: Jani Nikula
Reviewed-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +-
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 10 +-
> drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +-
> drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +-
> drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +-
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +-
> 10 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
> b/drivers/gpu/drm/gma500/cdv_intel_display.c
> index 66727328832d..7d47b3d5cc0d 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_display.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
> @@ -823,7 +823,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
>
> /* Flush the plane changes */
> {
> - struct drm_crtc_helper_funcs *crtc_funcs =
> + const struct drm_crtc_helper_funcs *crtc_funcs =
> crtc->helper_private;
> crtc_funcs->mode_set_base(crtc, x, y, old_fb);
> }
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> index 4268bf210034..6b1d3340ba14 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> @@ -195,7 +195,7 @@ static int cdv_hdmi_set_property(struct drm_connector
> *connector,
> encoder->crtc->x,
> encoder->crtc->y, encoder->crtc->primary->fb))
> return -1;
> } else {
> - struct drm_encoder_helper_funcs *helpers
> + const struct drm_encoder_helper_funcs *helpers
> = encoder->helper_private;
> helpers->mode_set(encoder, &crtc->saved_mode,
> &crtc->saved_adjusted_mode);
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 0b770396548c..211069b2b951 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -505,7 +505,7 @@ static int cdv_intel_lvds_set_property(struct
> drm_connector *connector,
> else
> gma_backlight_set(encoder->dev, value);
> } else if (!strcmp(property->name, "DPMS") && encoder) {
> - struct drm_encoder_helper_funcs *helpers =
> + const struct drm_encoder_helper_funcs *helpers =
> encoder->helper_private;
> helpers->dpms(encoder, value);
> }
> diff --git a/drivers/gpu/drm/gma500/gma_display.c
> b/drivers/gpu/drm/gma500/gma_display.c
> index 9bb9bddd881a..001b450b27b3 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -501,20 +501,20 @@ bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
>
> void gma_crtc_prepare(struct drm_crtc *crtc)
> {
> - struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> }
>
> void gma_crtc_commit(struct drm_crtc *crtc)
> {
> - struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> crtc_funcs->dpms(crtc, DRM_MODE_DPMS_ON);
> }
>
> void gma_crtc_disable(struct drm_crtc *crtc)
> {
> struct gtt_range *gt;
> - struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
>
> crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>
> @@ -656,7 +656,7 @@ void gma_crtc_restore(struct drm_crtc *crtc)
>
> void gma_encoder_prepare(struct drm_encoder *encoder)
> {
> - struct
[RFC v2 2/7] media: rc: Add cec protocol handling
Hi Mauro,
I have some more comments/questions below.
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
>
> Em Thu, 22 Jan 2015 17:04:34 +0100
> Kamil Debski escreveu:
>
> (c/c linux-input ML)
>
> > Add cec protocol handling the RC framework.
>
> I added some comments, that reflects my understanding from what's there
> at the keymap definitions found at:
> http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
>
>
> >
> > Signed-off-by: Kamil Debski
> > ---
> > drivers/media/rc/keymaps/Makefile |1 +
> > drivers/media/rc/keymaps/rc-cec.c | 133
> +
> > drivers/media/rc/rc-main.c|1 +
> > include/media/rc-core.h |1 +
> > include/media/rc-map.h|5 +-
> > 5 files changed, 140 insertions(+), 1 deletion(-) create mode
[snip]
>
> > + { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
> > + { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
> > + { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
> > + { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */
> > + { 0x64, KEY_STOP }, /* XXX CEC Spec: Stop Function */
> > + { 0x65, KEY_MUTE }, /* XXX CEC Spec: Mute Function */
> > + /* 0x66: CEC Spec: Restore Volume Function */
> > + { 0x67, KEY_TUNER }, /* XXX CEC Spec: Tune Function */
> > + { 0x68, KEY_MEDIA }, /* CEC Spec: Select Media Function */
> > + { 0x69, KEY_SWITCHVIDEOMODE} /* XXX CEC Spec: Select A/V Input
> Function */,
> > + { 0x6a, KEY_AUDIO} /* CEC Spec: Select Audio Input Function */,
> > + { 0x6b, KEY_POWER} /* CEC Spec: Power Toggle Function */,
> > + { 0x6c, KEY_SLEEP} /* XXX CEC Spec: Power Off Function */,
> > + { 0x6d, KEY_WAKEUP} /* XXX CEC Spec: Power On Function */,
>
> Those "function" keycodes look weird. What's the difference between
> those and the pure non-function variants?
The note 2 applies to most of these function buttons. It says:
"2 During a recording or timed recording, a device may ask the user
for confirmation of this action before executing it."
> The spec (CEC 13.13.3) says that:
>
> "Unlike the other codes, which just pass remote control presses
>to the target (often with manufacturer-specific results),
>the Functions are deterministic, ie they specify exactly the
> state
>after executing these commands. Several of these also have
> further
>operands, specifying the function in more detail, immediately
>following the relevant [UI Command] operand."
>
> Some codes are actually compund ones. For example, 0x60 has a "play
> mode"
> operand. So, the actual mapping would be:
>
> 0x60 + 0x24 - "play forward"
> 0x61 + 0x20 - "play reverse"
> ...
> (see CEC17 for operand descriptions)
>
> So, IMHO, the mapping should be
>
> { 0x6024, KEY_PLAY },
> { 0x6020, KEY_PLAY_REVERSE }, // to be created
The note 1 says that they can be issued without the additional operand
specified:
"1 Functions with additional operands may also be used without the
additional operand: in this case the behavior is manufacturer-specific."
Will this do?
{ 0x60, KEY_PLAY },
{ 0x6024, KEY_PLAY },
{ 0x6020, KEY_PLAY_REVERSE }, // to be created
Or will the framework get confused that an incomplete key code was
received?
Another question I have is about the following operations:
0x67 Tune Function
0x68 Select Media Function
0x69 Select A/V Input Function
0x6a Select Audio Input Function
These operations take an additional operand that is large number.
1-255 for 0x68-0x6a or even a more complex operand such as the channel
number for 0x67.
Any suggestion on how to implement these correctly?
> ...
>
>
> > + /* 0x6e-0x70: Reserved */
> > + { 0x71, KEY_BLUE }, /* XXX CEC Spec: F1 (Blue) */
> > + { 0x72, KEY_RED }, /* XXX CEC Spec: F2 (Red) */
> > + { 0x73, KEY_GREEN }, /* XXX CEC Spec: F3 (Green) */
> > + { 0x74, KEY_YELLOW }, /* XXX CEC Spec: F4 (Yellow) */
> > + { 0x75, KEY_F5 },
> > + { 0x76, KEY_CONNECT }, /* XXX CEC Spec: Data - see Note 3 */
> > + /* Note 3: This is used, for example, to enter or leave a digital
> TV
> > +* data broadcast application. */
>
[snip]
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
[PATCH] clk: provide clk_is_match() dummy for non-common clk
On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
> Hey Russell,
>
> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> > On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > > ARM randconfig build tests found a new error for configurations
> > > with COMMON_CLK disabled but HAS_CLK selected by the platform:
> > >
> > > ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
> > >
> > > This moves the declaration around, so this case is covered
> > > by the existing static inline helper function.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > Fixes: c69e182e51d89 ("clk: introduce clk_is_match")
> > >
> > > BTW, we have a preexisting problem in clk_get_parent,
> > > clk_round_rate and clk_set_parent, which I've worked around in
> > > my randconfig builds so far. Should we do that the same way?
> >
> > NAK, as Uwe points out, you didn't address my comment.
> You commented on the patch that is c69e182e51d8 ("clk: introduce
> clk_is_match") now in next. Arnd just moved this around.
*Sigh*
Mike - please remove this commit until proper kernel patch process is
honoured. We'll have some order here, and mutual respect of fellow
kernel developers, rather than people selectively ignoring people.
Yes, I realise that it fixes a bug, but it's utterly disgusting that
comments on a patch are ignored and it's just picked up irrespective
of comments being addressed.
If you don't like that, bloody well do a better job.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
[PATCH v3 14/17] exynos: fimg2d: fix comment for G2D_COEFF_MODE_GB_COLOR
Hi Tobias,
On 2015ë
02ì 24ì¼ 23:20, Tobias Jakobi wrote:
> The coefficient mode enables use of global color, not alpha.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
> index dbcb764..418757f 100644
> --- a/exynos/exynos_fimg2d.h
> +++ b/exynos/exynos_fimg2d.h
> @@ -159,7 +159,7 @@ enum e_g2d_coeff_mode {
> G2D_COEFF_MODE_DST_COLOR,
> /* Global Alpha : Set by ALPHA_REG(0x618) */
> G2D_COEFF_MODE_GB_ALPHA,
> - /* Global Alpha : Set by ALPHA_REG(0x618) */
> + /* Global Color : Set by ALPHA_REG(0x618) */
Actually, above register sets not only global color value but also
global alpha value. Below shows fields of the register,
ColorValue [31:8] Global color value (RGB order)
AlphaValue [7:0] Global alpha value
So right comment would be "Global Color and Global Alpha".
Thanks,
Inki Dae
> G2D_COEFF_MODE_GB_COLOR,
> /* (1-SRC alpha)/DST Alpha */
> G2D_COEFF_MODE_DISJOINT_S,
>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 Bug ID: 89534 Summary: GPU lockup with wine Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: john.ettedgui at gmail.com Created attachment 114220 --> https://bugs.freedesktop.org/attachment.cgi?id=114220&action=edit dmesg part for the lockup Hi there, I have found some games that cause some GPU lockups, some more violent than others. All of them unfortunately are running through wine. I am not exactly sure if they are all related or not, but I'll give a small summary of these, they are all using the Unreal Engine 3. I started with Injustice Gods Among US: I didn't see any crash with pure wine, only with nine. They seemed more likely with higher graphical settings, though there was one stage that I had to play without nine as it always crashed. With the same configuration using Nine I played Batman Arkham Asylum with no crash (older game same engine, maybe less demanding?). Then Batman Arkham City has been similar to Injustice, but it also has crashed with standard wine (meaning without nine), just less frequently. And finally, the one that really brings me here now, Batman Arkham Origins, I can't get past the main screen, with nine or pure wine it crashes at the same place. I've tried with both linux 3.19 and linux 4.0rc3, with the radeon and the generic modesetting ddx and it's all the same. I am on latest mesa-git and llvm-svn. The end results is the screen is dead, but I can still remote ssh in the machine most times, then there's not much I can do but restart the machine... I'll attach the dmesg I grabbed from my last try with Batman Arkham Origins. I am not exactly sure where the issue really is, so for now I've put it in DRI. My specs are: Radeon 280x Xorg 1.17 Linux 3.19/4.0rc3 x64 mesa-git llvm-svn As always I'm open to trying patches, bisect etc... though since I never played these games before, I cannot say if it worked or not better in previous releases. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/85b5870d/attachment.html>
[Bug 89327] Loss of HDMI audio on auto screen off (energy saving)
https://bugs.freedesktop.org/show_bug.cgi?id=89327 --- Comment #24 from John --- It seems rc3 includes these already, so that's all good. -- 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/20150311/8f162572/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 Alex Deucher changed: What|Removed |Added Component|DRM/Radeon |Drivers/Gallium/radeonsi Version|XOrg git|git Product|DRI |Mesa QA Contact||dri-devel at lists.freedesktop ||.org -- 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/20150311/2ae89be6/attachment.html>
[v3] libdrm: improvements to userspace exynos component
Hi, On 2015ë 02ì 24ì¼ 23:20, Tobias Jakobi wrote: > Hello, > > here are some miscellaneous improvements (small features, bugfixes, spelling > fixes, etc.) for the exynos component of libdrm. The general idea is to let > userspace use the G2D engine functionality more > efficiently. > > If someone is interested in an application that actually makes use of this, > the RetroArch frontend has a custom video backend: > https://github.com/libretro/RetroArch/blob/master/gfx/drivers/exynos_gfx.c > > > Please review and let me know what I can improve. > > v2: > - Mention value of G2D scaling normalization factor (02/15). > - Moved patch (04/15) description from commit message to source itself, like > suggested by Joonyoung Shim. > > v3: > I integrated the suggestions by Emil Velikov and added two additional patches > to the series. One doing the header cleanup that Emil point out, another one > just a trivial whitespace thing. I'm resending > the whole series, since number of patches and order changed. Looks good to me except for 14/17 patch. For the patch, I commented already, which may be very trivial but should be fixed correctly. I think Emil could fix it before merging it. To Emil, Could you please fix the patch 14/17 like below?, before - /* Global Alpha : Set by ALPHA_REG(0x618) */ + /* Global Color : Set by ALPHA_REG(0x618) */ after - /* Global Alpha : Set by ALPHA_REG(0x618) */ + /* Global Color and Alpha: Set by ALPHA_REG(0x618) */ for all patches - 1 though 17, Signed-off-by : Inki Dae Thanks, Inki Dae > > > With best wishes, > Tobias > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 2/5] drm/exynos: use correct fb width/height
On 2015ë
03ì 07ì¼ 06:23, Rob Clark wrote:
> Signed-off-by: Rob Clark
Signed-off-by : Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 84f8dfe..e71e331 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -76,6 +76,7 @@ static struct fb_ops exynos_drm_fb_ops = {
> };
>
> static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
> + struct drm_fb_helper_surface_size *sizes,
>struct drm_framebuffer *fb)
> {
> struct fb_info *fbi = helper->fbdev;
> @@ -85,7 +86,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
> *helper,
> unsigned long offset;
>
> drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
> - drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height);
> + drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
>
> /* RGB formats use only one buffer */
> buffer = exynos_drm_fb_buffer(fb, 0);
> @@ -189,7 +190,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> goto err_destroy_framebuffer;
> }
>
> - ret = exynos_drm_fbdev_update(helper, helper->fb);
> + ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
> if (ret < 0)
> goto err_dealloc_cmap;
>
>
[RFC 6/6] drm/sti: Remove local fbdev emulation Kconfig option
I was close the send a patch it remove this flag but more inspired by what Rob has done few weeks ago: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 2015-03-10 10:41 GMT+01:00 Archit Taneja : > DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation > for > the sti kms driver. > > Remove this local config option and use the top level DRM_FBDEV_EMULATION > config > option instead where applicable. > > We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION. It's > probably okay to get remove the #ifdef itself, but just left it here for > now to > be safe. It can be removed after some testing. > > Signed-off-by: Archit Taneja > --- > drivers/gpu/drm/sti/Kconfig | 6 -- > drivers/gpu/drm/sti/sti_drm_drv.c | 2 +- > 2 files changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig > index fbccc10..e3aa5af 100644 > --- a/drivers/gpu/drm/sti/Kconfig > +++ b/drivers/gpu/drm/sti/Kconfig > @@ -9,9 +9,3 @@ config DRM_STI > select FW_LOADER_USER_HELPER_FALLBACK > help > Choose this option to enable DRM on STM stiH41x chipset > - > -config DRM_STI_FBDEV > - bool "DRM frame buffer device for STMicroelectronics SoC stiH41x > Serie" > - depends on DRM_STI > - help > - Choose this option to enable FBDEV on top of DRM for STM stiH41x > chipset > diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c > b/drivers/gpu/drm/sti/sti_drm_drv.c > index 5239fa1..90f121d 100644 > --- a/drivers/gpu/drm/sti/sti_drm_drv.c > +++ b/drivers/gpu/drm/sti/sti_drm_drv.c > @@ -76,7 +76,7 @@ static int sti_drm_load(struct drm_device *dev, unsigned > long flags) > > drm_helper_disable_unused_functions(dev); > > -#ifdef CONFIG_DRM_STI_FBDEV > +#ifdef CONFIG_DRM_FBDEV_EMULATION > drm_fbdev_cma_init(dev, 32, >dev->mode_config.num_crtc, >dev->mode_config.num_connector); > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > > -- 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/20150311/cd86a7b4/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #1 from John --- Created attachment 114222 --> https://bugs.freedesktop.org/attachment.cgi?id=114222&action=edit part of DMESG where BAC lockup but came back after about 20 seconds -- 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/20150311/bbd504fa/attachment.html>
[Bug 89534] GPU lockup with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #2 from John --- Created attachment 114224 --> https://bugs.freedesktop.org/attachment.cgi?id=114224&action=edit and 2 minutes later BAC crashed the computer and didn't recover Though I could not log in through SSH right away... It took a few minutes before it worked, not sure what the kernel was blocked on then, but I thought I'd mention it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/868c449f/attachment.html>
[PATCH v2 0/7] drm/fb: width/height cleanups/fixes
In the process of fixing fb_width/fb_height problems with tiled displays (such as DP MST), I realized there were a few drivers having confusion about drm_fb_helper_surface_size. So, document the struct, fix the drivers, simplify the logic in drm_fb_helper_single_fb_probe() that figures out the sizes, and finally fix the logic for tiled displays. Oh and a minor completely unrelated kerneldoc fix for a typo that I noticed. Rob Clark (7): drm/fb: document drm_fb_helper_surface_size drm/atomic: minor kerneldoc typo fix drm/cma: use correct fb width/height drm/exynos: use correct fb width/height drm/rockchip: use correct fb width/height drm/fb: small cleanup drm/fb: handle tiled connectors better drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 48 +++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +-- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- include/drm/drm_crtc.h| 2 +- include/drm/drm_fb_helper.h | 19 +++ 6 files changed, 60 insertions(+), 18 deletions(-) -- 2.1.0
[PATCH v2 1/7] drm/fb: document drm_fb_helper_surface_size
There has been some confusion about this struct. Lack of documentation
probably didn't help.
Signed-off-by: Rob Clark
---
include/drm/drm_fb_helper.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c..0dfd94def 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -44,6 +44,25 @@ struct drm_fb_helper_crtc {
int x, y;
};
+/**
+ * struct drm_fb_helper_surface_size - describes fbdev size and scanout
surface size
+ * @fb_width: fbdev width
+ * @fb_height: fbdev height
+ * @surface_width: scanout buffer width
+ * @surface_height: scanout buffer height
+ * @surface_bpp: scanout buffer bpp
+ * @surface_depth: scanout buffer depth
+ *
+ * Note that the scanout surface width/height may be larger than the fbdev
+ * width/height. In case of multiple displays, the scanout surface is sized
+ * according to the largest width/height (so it is large enough for all CRTCs
+ * to scanout). But the fbdev width/height is sized to the minimum width/
+ * height of all the displays. This ensures that fbcon fits on the smallest
+ * of the attached displays.
+ *
+ * So what is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
+ * rather than the surface size.
+ */
struct drm_fb_helper_surface_size {
u32 fb_width;
u32 fb_height;
--
2.1.0
[PATCH v2 2/7] drm/atomic: minor kerneldoc typo fix
Signed-off-by: Rob Clark
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adc9ea5..7b5c661 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -915,7 +915,7 @@ struct drm_bridge {
};
/**
- * struct struct drm_atomic_state - the global state object for atomic updates
+ * struct drm_atomic_state - the global state object for atomic updates
* @dev: parent DRM device
* @allow_modeset: allow full modeset
* @legacy_cursor_update: hint to enforce legacy cursor ioctl semantics
--
2.1.0
[PATCH v2 3/7] drm/cma: use correct fb width/height
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height, rather than the surface size. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index cc0ae04..5c1aca4 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -304,7 +304,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper *helper, } drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth); - drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height); + drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height); offset = fbi->var.xoffset * bytes_per_pixel; offset += fbi->var.yoffset * fb->pitches[0]; -- 2.1.0
[PATCH v2 4/7] drm/exynos: use correct fb width/height
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 84f8dfe..e71e331 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -76,6 +76,7 @@ static struct fb_ops exynos_drm_fb_ops = {
};
static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
+struct drm_fb_helper_surface_size *sizes,
struct drm_framebuffer *fb)
{
struct fb_info *fbi = helper->fbdev;
@@ -85,7 +86,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper
*helper,
unsigned long offset;
drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
- drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height);
+ drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
/* RGB formats use only one buffer */
buffer = exynos_drm_fb_buffer(fb, 0);
@@ -189,7 +190,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
goto err_destroy_framebuffer;
}
- ret = exynos_drm_fbdev_update(helper, helper->fb);
+ ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
if (ret < 0)
goto err_dealloc_cmap;
--
2.1.0
[PATCH v2 5/7] drm/rockchip: use correct fb width/height
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height, rather than the surface size. Signed-off-by: Rob Clark --- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c index a5d889a8..ff04877 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c @@ -106,7 +106,7 @@ static int rockchip_drm_fbdev_create(struct drm_fb_helper *helper, fb = helper->fb; drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth); - drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height); + drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height); offset = fbi->var.xoffset * bytes_per_pixel; offset += fbi->var.yoffset * fb->pitches[0]; -- 2.1.0
[PATCH v2 6/7] drm/fb: small cleanup
Flip conditional to reduce indentation level of rest of fxn, and use
min/max to make the code clearer.
v2: surface_width -> surface_height typo
Signed-off-by: Rob Clark
Reviewed-by: Daniel Kurtz
---
drivers/gpu/drm/drm_fb_helper.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1e6a0c7..dca98a4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1035,22 +1035,24 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
int x, y;
+
desired_mode = fb_helper->crtc_info[i].desired_mode;
+
+ if (!desired_mode)
+ continue;
+
+ crtc_count++;
+
x = fb_helper->crtc_info[i].x;
y = fb_helper->crtc_info[i].y;
- if (desired_mode) {
- if (gamma_size == 0)
- gamma_size =
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
- if (desired_mode->hdisplay + x < sizes.fb_width)
- sizes.fb_width = desired_mode->hdisplay + x;
- if (desired_mode->vdisplay + y < sizes.fb_height)
- sizes.fb_height = desired_mode->vdisplay + y;
- if (desired_mode->hdisplay + x > sizes.surface_width)
- sizes.surface_width = desired_mode->hdisplay +
x;
- if (desired_mode->vdisplay + y > sizes.surface_height)
- sizes.surface_height = desired_mode->vdisplay +
y;
- crtc_count++;
- }
+
+ if (gamma_size == 0)
+ gamma_size =
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
+
+ sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
sizes.surface_width);
+ sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
sizes.surface_height);
+ sizes.fb_width = min_t(u32, desired_mode->hdisplay + x,
sizes.fb_width);
+ sizes.fb_height = min_t(u32, desired_mode->vdisplay + y,
sizes.fb_height);
}
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
--
2.1.0
[PATCH v2 7/7] drm/fb: handle tiled connectors better
We don't want tile 0,0 to artificially constrain the size of the legacy
fbdev device. Instead when reducing fb_size to be the minimum of all
displays, only consider the rightmost and bottommost tiles.
Signed-off-by: Rob Clark
Tested-by: Hai Li
---
drivers/gpu/drm/drm_fb_helper.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index dca98a4..1a20db7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1034,9 +1034,16 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
- int x, y;
+ struct drm_mode_set *mode_set;
+ int x, y, j;
+ /* in case of tile group, are we the last tile vert or horiz?
+* If no tile group you are always the last one both vertically
+* and horizontally
+*/
+ bool lastv = true, lasth = true;
desired_mode = fb_helper->crtc_info[i].desired_mode;
+ mode_set = &fb_helper->crtc_info[i].mode_set;
if (!desired_mode)
continue;
@@ -1051,8 +1058,21 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
sizes.surface_width);
sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
sizes.surface_height);
- sizes.fb_width = min_t(u32, desired_mode->hdisplay + x,
sizes.fb_width);
- sizes.fb_height = min_t(u32, desired_mode->vdisplay + y,
sizes.fb_height);
+
+ for (j = 0; j < mode_set->num_connectors; j++) {
+ struct drm_connector *connector =
mode_set->connectors[j];
+ if (connector->has_tile) {
+ lasth = (connector->tile_h_loc ==
(connector->num_h_tile - 1));
+ lastv = (connector->tile_v_loc ==
(connector->num_v_tile - 1));
+ /* cloning to multiple tiles is just
crazy-talk, so: */
+ break;
+ }
+ }
+
+ if (lasth)
+ sizes.fb_width = min_t(u32, desired_mode->hdisplay +
x, sizes.fb_width);
+ if (lastv)
+ sizes.fb_height = min_t(u32, desired_mode->vdisplay +
y, sizes.fb_height);
}
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
--
2.1.0
[PATCH] drm: sti: convert driver to atomic modeset
This patch does the minimum to make sti driver use atomic helpers.
No big bang, only adapt some functions to new call order.
Later it will allow to clean the mess around sti_mixer_* functions
which are use either in plane and crtc.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_compositor.c | 3 --
drivers/gpu/drm/sti/sti_drm_crtc.c | 85 ++--
drivers/gpu/drm/sti/sti_drm_drv.c| 5 +++
drivers/gpu/drm/sti/sti_drm_plane.c | 45 +--
drivers/gpu/drm/sti/sti_dvo.c| 4 ++
drivers/gpu/drm/sti/sti_hda.c| 4 ++
drivers/gpu/drm/sti/sti_hdmi.c | 4 ++
7 files changed, 92 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_compositor.c
b/drivers/gpu/drm/sti/sti_compositor.c
index 43215d3..9b2cc40 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -104,9 +104,6 @@ static int sti_compositor_bind(struct device *dev, struct
device *master,
enum sti_layer_type type = desc & STI_LAYER_TYPE_MASK;
enum drm_plane_type plane_type = DRM_PLANE_TYPE_OVERLAY;
- if (crtc < compo->nb_mixers)
- plane_type = DRM_PLANE_TYPE_PRIMARY;
-
switch (type) {
case STI_CUR:
cursor = sti_drm_plane_init(drm_dev,
diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c
b/drivers/gpu/drm/sti/sti_drm_crtc.c
index e6f6ef7..67a175b 100644
--- a/drivers/gpu/drm/sti/sti_drm_crtc.c
+++ b/drivers/gpu/drm/sti/sti_drm_crtc.c
@@ -9,6 +9,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -77,22 +79,18 @@ static bool sti_drm_crtc_mode_fixup(struct drm_crtc *crtc,
}
static int
-sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb)
+sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode)
{
struct sti_mixer *mixer = to_sti_mixer(crtc);
struct device *dev = mixer->dev;
struct sti_compositor *compo = dev_get_drvdata(dev);
- struct sti_layer *layer;
struct clk *clk;
int rate = mode->clock * 1000;
int res;
- unsigned int w, h;
- DRM_DEBUG_KMS("CRTC:%d (%s) fb:%d mode:%d (%s)\n",
+ DRM_DEBUG_KMS("CRTC:%d (%s) mode:%d (%s)\n",
crtc->base.id, sti_mixer_to_str(mixer),
- crtc->primary->fb->base.id, mode->base.id, mode->name);
+ mode->base.id, mode->name);
DRM_DEBUG_KMS("%d %d %d %d %d %d %d %d %d %d 0x%x 0x%x\n",
mode->vrefresh, mode->clock,
@@ -122,35 +120,13 @@ sti_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
sti_vtg_set_config(mixer->id == STI_MIXER_MAIN ?
compo->vtg_main : compo->vtg_aux, &crtc->mode);
- /* a GDP is reserved to the CRTC FB */
- layer = to_sti_layer(crtc->primary);
- if (!layer) {
- DRM_ERROR("Can not find GDP0)\n");
- return -EINVAL;
- }
-
- /* copy the mode data adjusted by mode_fixup() into crtc->mode
-* so that hardware can be set to proper mode
-*/
- memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
-
- res = sti_mixer_set_layer_depth(mixer, layer);
- if (res) {
- DRM_ERROR("Can not set layer depth\n");
- return -EINVAL;
- }
res = sti_mixer_active_video_area(mixer, &crtc->mode);
if (res) {
DRM_ERROR("Can not set active video area\n");
return -EINVAL;
}
- w = crtc->primary->fb->width - x;
- h = crtc->primary->fb->height - y;
-
- return sti_layer_prepare(layer, crtc,
- crtc->primary->fb, &crtc->mode,
- mixer->id, 0, 0, w, h, x, y, w, h);
+ return res;
}
static int sti_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
@@ -195,7 +171,6 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc)
struct sti_mixer *mixer = to_sti_mixer(crtc);
struct device *dev = mixer->dev;
struct sti_compositor *compo = dev_get_drvdata(dev);
- struct sti_layer *layer;
if (!mixer->enabled)
return;
@@ -205,24 +180,6 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc)
/* Disable Background */
sti_mixer_set_background_status(mixer, false);
- /* Disable GDP */
- layer = to_sti_layer(crtc->primary);
- if (!layer) {
- DRM_ERROR("Cannot find GDP0\n");
- return;
- }
-
- /* Disable layer at mixer level */
- if (sti_mixer_set_layer_status(mixer, layer, false))
- DRM_ERROR("Can not disable %s layer at mixer\n",
[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: > > > On 03/10/2015 05:47 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: > >>On 03/10/2015 03:35 PM, Daniel Vetter wrote: > >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: > On 03/10/2015 03:17 PM, Daniel Vetter wrote: > >On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: > >>diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > >>index 151a050..38f83a0 100644 > >>--- a/drivers/gpu/drm/Kconfig > >>+++ b/drivers/gpu/drm/Kconfig > >>@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER > >>help > >> FBDEV helpers for KMS drivers. > >> > >>+config DRM_FBDEV_EMULATION > >>+ bool "Enable legacy fbdev support for your modesetting driver" > >>+ depends on DRM > >>+ select DRM_KMS_HELPER > >>+ select DRM_KMS_FB_HELPER > >>+ select FB_SYS_FILLRECT > >>+ select FB_SYS_COPYAREA > >>+ select FB_SYS_IMAGEBLIT > >>+ select FB_SYS_FOPS > >>+ select FB_CFB_FILLRECT > >>+ select FB_CFB_COPYAREA > >>+ select FB_CFB_IMAGEBLIT > >>+ default y > >>+ help > >>+ Choose this option if you have a need for the legacy fbdev > >>+ support. Note that this support also provide the linux console > >>+ support on top of your modesetting driver. > > > >Maybe clarify that for linux console support you also need > >CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. > > DRM_KMS_FB_HELPER selects that for us, right? > >>> > >>>Hm right I've missed that. Reminds me that you need one more patch at the > >>>end to remove all the various select DRM_KMS_FB_HELPER from all drm > >>>drivers. Otherwise this knob here won't work by default if you e.g. select > >>>radeon. In general we can't mix explicit options with menu entries with a > >>>select. > >> > >>I was trying that out. Removing DRM_KMS_FB_HELPER and having > >>DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in > >>their respective xyz_fbdev.c files. > > > >But with the stubbed out functions that should work, right? Why doesn't > >it? > > There are still calls to functions from fb core like fb_set_suspend and > register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? > >>Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and > >>replace them with 'select DRM_FBDEV_EMULATION'? > >> > >>Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds > >>for fb related function calls/declarations in each driver, something that's > >>already done for i915 and msm drivers. > > > >The problem with the patch as-is the massive amounts of selects the FB > >helper still has. We need to get rid of them so that when you disable > >fbdev emulation you can indeed disable fbcon and the entire fbdev > >subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER > >and moving all the selects to DRM_FBDEV_EMULATION should work out? If that > >doesn't work we need to look again how to better stub things out I think. > > That's true. Also, as Jani pointed out, maybe it isn't the best idea to make > every kms driver select DRM_FBDEV_EMULATION? > > Maybe the drivers that are currently built with fbdev emulation by default > can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, > the drivers should run as is. Later, we could take up each driver and build > the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 > and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about "where is my fbcon with kms?". -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/9] drm/mgag200: constify all struct drm_*_helper funcs pointers
On 03/11/2015 02:51 AM, Jani Nikula wrote:
> They are not to be modified.
>
> Generated using the semantic patch:
>
> @@
> @@
> (
> const struct drm_crtc_helper_funcs *
> |
> - struct drm_crtc_helper_funcs *
> + const struct drm_crtc_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_encoder_helper_funcs *
> |
> - struct drm_encoder_helper_funcs *
> + const struct drm_encoder_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_connector_helper_funcs *
> |
> - struct drm_connector_helper_funcs *
> + const struct drm_connector_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_plane_helper_funcs *
> |
> - struct drm_plane_helper_funcs *
> + const struct drm_plane_helper_funcs *
> )
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 9872ba9abf1a..6e84df9369a6 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -1222,7 +1222,7 @@ static void mga_crtc_commit(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> struct mga_device *mdev = dev->dev_private;
> - struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
Presumably cases like this one could be 'const struct
drm_crtc_helper_funcs *const' but meh.
This patch is
Reviewed-by: Ian Romanick
...who hasn't had a patch in the Matrox driver in almost a decade.
> u8 tmp;
>
> if (mdev->type == G200_WB)
>
[PATCH] drm/radeon: fix TOPDOWN handling for bo_create
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false.
Noticed-by: Oded Gabbay
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h| 3 ++-
drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 17 ++---
drivers/gpu/drm/radeon/radeon_ttm.c| 12
5 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5587603..726e89f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2970,7 +2970,8 @@ extern void radeon_surface_init(struct radeon_device
*rdev);
extern int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data);
extern void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
-extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
+extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain,
+u64 size);
extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
uint32_t flags);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index ac3c131..d613d0c 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -337,7 +337,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
goto release_object;
}
- radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT);
+ radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT,
bo->tbo.mem.size);
r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
radeon_bo_unreserve(bo);
up_read(¤t->mm->mmap_sem);
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index a69bd44..e51f09b 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -141,7 +141,7 @@ static void radeon_mn_invalidate_range_start(struct
mmu_notifier *mn,
DRM_ERROR("(%d) failed to wait for user bo\n",
r);
}
- radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU);
+ radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU,
bo->tbo.mem.size);
r = ttm_bo_validate(&bo->tbo, &bo->placement, false, false);
if (r)
DRM_ERROR("(%d) failed to validate user bo\n", r);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 43e0994..07f8fd5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -93,7 +93,8 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo)
return false;
}
-void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
+void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain,
+ u64 size)
{
u32 c = 0, i;
@@ -179,7 +180,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
*rbo, u32 domain)
* improve fragmentation quality.
* 512kb was measured as the most optimal number.
*/
- if (rbo->tbo.mem.size > 512 * 1024) {
+ if (size > 512 * 1024) {
for (i = 0; i < c; i++) {
rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
}
@@ -252,7 +253,7 @@ int radeon_bo_create(struct radeon_device *rdev,
bo->flags &= ~RADEON_GEM_GTT_WC;
#endif
- radeon_ttm_placement_from_domain(bo, domain);
+ radeon_ttm_placement_from_domain(bo, domain, size);
/* Kernel allocation are uninterruptible */
down_read(&rdev->pm.mclk_lock);
r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
@@ -350,7 +351,7 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
return 0;
}
- radeon_ttm_placement_from_domain(bo, domain);
+ radeon_ttm_placement_from_domain(bo, domain, bo->tbo.mem.size);
for (i = 0; i < bo->placement.num_placement; i++) {
/* force to pin into visible video ram */
if ((bo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
@@ -557,7 +558,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
}
retry:
- radeon_ttm_placeme
[PATCH v2 0/7] drm/fb: width/height cleanups/fixes
On Wed, Mar 11, 2015 at 10:23 AM, Rob Clark wrote: > In the process of fixing fb_width/fb_height problems with tiled displays > (such as DP MST), I realized there were a few drivers having confusion > about drm_fb_helper_surface_size. > > So, document the struct, fix the drivers, simplify the logic in > drm_fb_helper_single_fb_probe() that figures out the sizes, and finally > fix the logic for tiled displays. > > Oh and a minor completely unrelated kerneldoc fix for a typo that I > noticed. Series is: Reviewed-by: Alex Deucher > > Rob Clark (7): > drm/fb: document drm_fb_helper_surface_size > drm/atomic: minor kerneldoc typo fix > drm/cma: use correct fb width/height > drm/exynos: use correct fb width/height > drm/rockchip: use correct fb width/height > drm/fb: small cleanup > drm/fb: handle tiled connectors better > > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > drivers/gpu/drm/drm_fb_helper.c | 48 > +++ > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +-- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- > include/drm/drm_crtc.h| 2 +- > include/drm/drm_fb_helper.h | 19 +++ > 6 files changed, 60 insertions(+), 18 deletions(-) > > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 89536] GPU lockup and kernel OOPS when using PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=89536 Bug ID: 89536 Summary: GPU lockup and kernel OOPS when using PRIME Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: rafael.ristovski at gmail.com Created attachment 114225 --> https://bugs.freedesktop.org/attachment.cgi?id=114225&action=edit Two of the kernel hangs, note one is an OOPS, while the other is not, I was able to shut down the machine normally after the first OOPS as the kernel was still responsive to power button events. When running OpenGL applications with PRIME, the screen freezes and a kernel OOPS is generated. This seems to happen either when the application starts, or the window of the application is re-drawn (moving workspaces, minimizing/maximizing) Crashes seem to be inconsistent as sometimes the kernel just freezes and no OOPS is generated. OS Details: Archlinux with kernel 3.19.1-1 xorg-server 1.17.1-3 xf86-video-intel 2.99.917-4 xf86-video-ati 1:7.5.0-2 libdrm 2.4.59-1 Below is an attached kernel log with _TWO_ separate kernel hang, both caused by running an OpenGL application with PRIME. -- 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/20150311/5521e900/attachment.html>
[Bug 89536] GPU lockup and kernel OOPS when using PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=89536 --- Comment #1 from Alex Deucher --- Please attach your full dmesg from boot, xorg log, and lspci -nn output. -- 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/20150311/202c3206/attachment.html>
[Bug 89536] GPU lockup and kernel OOPS when using PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=89536 --- Comment #2 from Rafael Ristovski --- Created attachment 114226 --> https://bugs.freedesktop.org/attachment.cgi?id=114226&action=edit lspci output -- 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/20150311/66a4123c/attachment.html>
[Bug 89536] GPU lockup and kernel OOPS when using PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=89536 --- Comment #3 from Rafael Ristovski --- Created attachment 114227 --> https://bugs.freedesktop.org/attachment.cgi?id=114227&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/74273960/attachment.html>
[Bug 89536] GPU lockup and kernel OOPS when using PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=89536 --- Comment #4 from Rafael Ristovski --- Created attachment 114228 --> https://bugs.freedesktop.org/attachment.cgi?id=114228&action=edit dmesg, ends when login prompt appears (non-graphical) -- 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/20150311/620f8b29/attachment.html>
[Bug 89544] Opaque light shader in the game Urban Terror
https://bugs.freedesktop.org/show_bug.cgi?id=89544 Bug ID: 89544 Summary: Opaque light shader in the game Urban Terror Product: Mesa Version: 10.4 Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: thomas-lange2 at gmx.de QA Contact: dri-devel at lists.freedesktop.org Created attachment 114229 --> https://bugs.freedesktop.org/attachment.cgi?id=114229&action=edit Screenshot On the map "Uptown" of the game Urban Terror [1] some light shaders are not transparent. Attached is a screenshot which shows the incorrect rendering. How to reproduce: 1. Start Urban Terror 2. Open the console with SHIFT+ESC 3. Type "/map ut4_uptown" 4. Search the parking deck on the map System: Up-to-date Arch Linux with - Linux 3.19.1 - Mesa 10.4.6 - Xorg-server 1.17.1 - xf86-video-ati 7.5.0 - Urban Terror 4.2.023 The GPU is a HD6850 (AMD BARTS). [1] http://www.urbanterror.info/home/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/6273da69/attachment.html>
[Bug 89544] Opaque light shader in the game Urban Terror
https://bugs.freedesktop.org/show_bug.cgi?id=89544 Ilia Mirkin changed: What|Removed |Added Attachment #114229|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/c79af503/attachment-0001.html>
[Bug 89544] Opaque light shader in the game Urban Terror
https://bugs.freedesktop.org/show_bug.cgi?id=89544 Thomas Lange changed: What|Removed |Added Attachment #114229|0 |1 is obsolete|| --- Comment #1 from Thomas Lange --- Created attachment 114230 --> https://bugs.freedesktop.org/attachment.cgi?id=114230&action=edit Screenshot -- 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/20150311/c36d5308/attachment.html>
[PATCH v2 6/7] drm/fb: small cleanup
Hi Rob,
Thank you for the patch.
On Wednesday 11 March 2015 10:23:13 Rob Clark wrote:
> Flip conditional to reduce indentation level of rest of fxn, and use
> min/max to make the code clearer.
>
> v2: surface_width -> surface_height typo
>
> Signed-off-by: Rob Clark
> Reviewed-by: Daniel Kurtz
> ---
> drivers/gpu/drm/drm_fb_helper.c | 28 +++-
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c index 1e6a0c7..dca98a4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1035,22 +1035,24 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper, for (i = 0; i < fb_helper->crtc_count; i++) {
> struct drm_display_mode *desired_mode;
> int x, y;
> +
> desired_mode = fb_helper->crtc_info[i].desired_mode;
> +
> + if (!desired_mode)
> + continue;
> +
> + crtc_count++;
> +
> x = fb_helper->crtc_info[i].x;
> y = fb_helper->crtc_info[i].y;
> - if (desired_mode) {
> - if (gamma_size == 0)
> - gamma_size =
> fb_helper->crtc_info[i].mode_set.crtc-
>gamma_size;
> - if (desired_mode->hdisplay + x < sizes.fb_width)
> - sizes.fb_width = desired_mode->hdisplay + x;
> - if (desired_mode->vdisplay + y < sizes.fb_height)
> - sizes.fb_height = desired_mode->vdisplay + y;
> - if (desired_mode->hdisplay + x > sizes.surface_width)
> - sizes.surface_width = desired_mode->hdisplay +
> x;
> - if (desired_mode->vdisplay + y > sizes.surface_height)
> - sizes.surface_height = desired_mode->vdisplay +
> y;
> - crtc_count++;
> - }
> +
> + if (gamma_size == 0)
> + gamma_size =
> fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
> +
> + sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
> sizes.surface_width);
> + sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
> sizes.surface_height);
> + sizes.fb_width = min_t(u32, desired_mode->hdisplay + x,
> sizes.fb_width);
> + sizes.fb_height = min_t(u32, desired_mode->vdisplay + y,
> sizes.fb_height); }
Nitpicking, reducing the indentation level is nice, but you're making lines
longer. I would add line breaks here.
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
--
Regards,
Laurent Pinchart
[PATCH v2 0/7] drm/fb: width/height cleanups/fixes
Hi Rob, Thank you for the patches. On Wednesday 11 March 2015 10:23:07 Rob Clark wrote: > In the process of fixing fb_width/fb_height problems with tiled displays > (such as DP MST), I realized there were a few drivers having confusion > about drm_fb_helper_surface_size. > > So, document the struct, fix the drivers, simplify the logic in > drm_fb_helper_single_fb_probe() that figures out the sizes, and finally > fix the logic for tiled displays. > > Oh and a minor completely unrelated kerneldoc fix for a typo that I > noticed. > > Rob Clark (7): > drm/fb: document drm_fb_helper_surface_size > drm/atomic: minor kerneldoc typo fix > drm/cma: use correct fb width/height > drm/exynos: use correct fb width/height > drm/rockchip: use correct fb width/height > drm/fb: small cleanup > drm/fb: handle tiled connectors better For patches 1 to 5, Acked-by: Laurent Pinchart > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > drivers/gpu/drm/drm_fb_helper.c | 48 > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +-- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- > include/drm/drm_crtc.h| 2 +- > include/drm/drm_fb_helper.h | 19 +++ > 6 files changed, 60 insertions(+), 18 deletions(-) -- Regards, Laurent Pinchart
[PATCH] drm/plane-helper: Fixup mismerge
Hi Daniel,
Thank you for the patch.
On Wednesday 11 March 2015 09:00:26 Daniel Vetter wrote:
> I somehow manage to screw up applying Laurent's patch in eca93e28c256:
> "drm: Check in setcrtc if the primary plane supports the fb pixel
> format". It was a conflict with
>
> commit 3461b30b3e171e16498f3d7bc59ab703aec475c8
> Author: Daniel Vetter
> Date: Thu Mar 5 10:32:44 2015 +0100
>
> drm/plane-helper: unexport drm_primary_helper_create_plane
>
> and I just didn't check that the solution from wiggle made sense.
>
> Cc: Dan Carpenter
> Cc: laurent.pinchart at ideasonboard.com
> Reported-by: Dan Carpenter
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_plane_helper.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c index b62b03635050..33807e0adac7
> 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -353,13 +353,14 @@ static struct drm_plane *create_primary_plane(struct
> drm_device *dev) if (primary == NULL) {
> DRM_DEBUG_KMS("Failed to allocate primary plane\n");
> return NULL;
> - /*
> - * Remove the format_default field from drm_plane when dropping
> - * this helper.
> - */
> - primary->format_default = true;
> }
>
> + /*
> + * Remove the format_default field from drm_plane when dropping
> + * this helper.
> + */
> + primary->format_default = true;
> +
> /* possible_crtc's will be filled in later by crtc_init */
> ret = drm_universal_plane_init(dev, primary, 0,
> &drm_primary_helper_funcs,
--
Regards,
Laurent Pinchart
[Bug 89544] Opaque light shader in the game Urban Terror
https://bugs.freedesktop.org/show_bug.cgi?id=89544 Thomas Lange changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Thomas Lange --- Sorry for the noise, I just noticed this does not happen with a clean game profile. Further testing revealed that the issue occurs only when the user downloaded the custom map "ut4_druglord2". Marking as "Resolved -> NotOurBug". -- 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/20150311/05b16043/attachment.html>
[PATCH] drm/radeon: fix TOPDOWN handling for bo_create
On 11.03.2015 16:44, Alex Deucher wrote:
> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
> uses the ttm bo size to determine when to select top down
> allocation but since the ttm bo is not initialized yet the
> check is always false.
>
> Noticed-by: Oded Gabbay
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
And I was already wondering why the heck the BOs always made this
ping/pong in memory after creation.
Patch is Reviewed-by: Christian König
Regards,
Christian.
> ---
> drivers/gpu/drm/radeon/radeon.h| 3 ++-
> drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
> drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 17 ++---
> drivers/gpu/drm/radeon/radeon_ttm.c| 12
> 5 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 5587603..726e89f 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2970,7 +2970,8 @@ extern void radeon_surface_init(struct radeon_device
> *rdev);
> extern int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data);
> extern void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int
> enable);
> extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
> enable);
> -extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
> domain);
> +extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
> domain,
> + u64 size);
> extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
> extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
>uint32_t flags);
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index ac3c131..d613d0c 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -337,7 +337,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
> *data,
> goto release_object;
> }
>
> - radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT);
> + radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT,
> bo->tbo.mem.size);
> r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
> radeon_bo_unreserve(bo);
> up_read(¤t->mm->mmap_sem);
> diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
> b/drivers/gpu/drm/radeon/radeon_mn.c
> index a69bd44..e51f09b 100644
> --- a/drivers/gpu/drm/radeon/radeon_mn.c
> +++ b/drivers/gpu/drm/radeon/radeon_mn.c
> @@ -141,7 +141,7 @@ static void radeon_mn_invalidate_range_start(struct
> mmu_notifier *mn,
> DRM_ERROR("(%d) failed to wait for user bo\n",
> r);
> }
>
> - radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU);
> + radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_CPU,
> bo->tbo.mem.size);
> r = ttm_bo_validate(&bo->tbo, &bo->placement, false, false);
> if (r)
> DRM_ERROR("(%d) failed to validate user bo\n", r);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 43e0994..07f8fd5 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -93,7 +93,8 @@ bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object
> *bo)
> return false;
> }
>
> -void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
> +void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain,
> + u64 size)
> {
> u32 c = 0, i;
>
> @@ -179,7 +180,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
> *rbo, u32 domain)
>* improve fragmentation quality.
>* 512kb was measured as the most optimal number.
>*/
> - if (rbo->tbo.mem.size > 512 * 1024) {
> + if (size > 512 * 1024) {
> for (i = 0; i < c; i++) {
> rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
> }
> @@ -252,7 +253,7 @@ int radeon_bo_create(struct radeon_device *rdev,
> bo->flags &= ~RADEON_GEM_GTT_WC;
> #endif
>
> - radeon_ttm_placement_from_domain(bo, domain);
> + radeon_ttm_placement_from_domain(bo, domain, size);
> /* Kernel allocation are uninterruptible */
> down_read(&rdev->pm.mclk_lock);
> r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
> @@ -350,7 +351,7 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
> domain, u64 max_offset,
>
> return 0;
> }
> - radeon_ttm_placement_from_domain(bo, domain);
> + radeon_ttm_placement_from_domain(bo,
[PATCH libdrm] modetest: include into the build when libkms is not selected.
Hi Emil, Thank you for the patch. On Tuesday 10 March 2015 18:12:28 Emil Velikov wrote: > With commit d7c0a08bc57(modetest: Allocate dumb buffers with the correct > bpp) we moved away from the libkms dependency. As such we are safe with > including the Makefile/subdir, even as we opt out of building the > library. > > Cc: Laurent Pinchart > Signed-off-by: Emil Velikov Acked-by: Laurent Pinchart > --- > tests/Makefile.am | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index d5269f9..0ca5a39 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -1,7 +1,7 @@ > -SUBDIRS = modeprint proptest > +SUBDIRS = modeprint proptest modetest > > if HAVE_LIBKMS > -SUBDIRS += kmstest modetest > +SUBDIRS += kmstest > endif > > if HAVE_RADEON -- Regards, Laurent Pinchart
[PULL] vmwgfx-fixes-4.0
Hi, Dave. A couple of fixes for vmwgfx. The following changes since commit cd961bb9eebb630452f49dcbf3e5f0059428614a: drm/mst: fix recursive sleep warning on qlock (2015-03-10 13:44:31 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux for you to fetch changes up to fd3e4d6e26288d12b566912f692e278e8db15b82: drm/vmwgfx: Fix an issue with the device losing its irq line on module unload (2015-03-11 11:47:41 -0700) Colin Ian King (1): drm/vmwgfx: Correctly NULLify dma buffer pointer on failure Thomas Hellstrom (3): drm/vmwgfx: Fix a couple of lock dependency violations drm/vmwgfx: Reorder device takedown somewhat drm/vmwgfx: Fix an issue with the device losing its irq line on module unload drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 78 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 18 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 14 ++ 3 files changed, 53 insertions(+), 57 deletions(-)
[v3] libdrm: improvements to userspace exynos component
On 11 March 2015 at 13:31, Inki Dae wrote: > Hi, > > On 2015ë 02ì 24ì¼ 23:20, Tobias Jakobi wrote: >> Hello, >> >> here are some miscellaneous improvements (small features, bugfixes, spelling >> fixes, etc.) for the exynos component of libdrm. The general idea is to let >> userspace use the G2D engine functionality more >> efficiently. >> >> If someone is interested in an application that actually makes use of this, >> the RetroArch frontend has a custom video backend: >> https://github.com/libretro/RetroArch/blob/master/gfx/drivers/exynos_gfx.c >> >> >> Please review and let me know what I can improve. >> >> v2: >> - Mention value of G2D scaling normalization factor (02/15). >> - Moved patch (04/15) description from commit message to source itself, like >> suggested by Joonyoung Shim. >> >> v3: >> I integrated the suggestions by Emil Velikov and added two additional >> patches to the series. One doing the header cleanup that Emil point out, >> another one just a trivial whitespace thing. I'm resending >> the whole series, since number of patches and order changed. > Wohoo Inki's back ! > Looks good to me except for 14/17 patch. For the patch, I commented > already, which may be very trivial but should be fixed correctly. I > think Emil could fix it before merging it. > > To Emil, > Could you please fix the patch 14/17 like below?, > > before > - /* Global Alpha : Set by ALPHA_REG(0x618) */ > + /* Global Color : Set by ALPHA_REG(0x618) */ > > after > - /* Global Alpha : Set by ALPHA_REG(0x618) */ > + /* Global Color and Alpha: Set by ALPHA_REG(0x618) */ > > If you don't mind I'll leave this to Tobias as a follow up patch, as the one you've looked at is already in master. > for all patches - 1 though 17, Signed-off-by : Inki Dae > > I believe you mean Reviewed-by, isn't that right ? Tobias, Can you please re-spin the remaining patches on top of master, and address Inki's comment. Also please add Inki's and Joonyoung Shim's tags. Thanks Emil
[PULL] vmwgfx-next
Dave, The first pull request for 4.1. Mainly Sinclair's screen target work. The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127: Merge tag 'topic/drm-misc-2015-03-10' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11 12:15:06 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash for you to fetch changes up to 51850be6365084dc3ff6516bb9d89c6d7e3a98f1: drm/ttm: Add lockdep annotation to the TTM lock (2015-03-11 11:57:40 -0700) Sinclair Yeh (4): drm/vmwgfx: SVGA device definition update drm/vmwgfx: Refactor vmw_gb_surface_define_ioctl() drm/vmwgfx: Major KMS refactoring / cleanup in preparation of screen targets drm/vmwgfx: Implement screen targets Thomas Hellstrom (3): drm/vmwgfx: Add an interface to pin a resource v3 drm/vmwgfx: Add "quirk" to handling command verification exceptions drm/ttm: Add lockdep annotation to the TTM lock drivers/gpu/drm/ttm/ttm_lock.c | 73 +- drivers/gpu/drm/vmwgfx/Makefile |2 +- drivers/gpu/drm/vmwgfx/svga3d_reg.h | 56 +- drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h | 67 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 21 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 52 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 10 + drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |4 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 608 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 97 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 45 +- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |3 +- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |6 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 91 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 433 - drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 1360 +++ drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 199 ++-- include/drm/ttm/ttm_lock.h | 13 +- include/uapi/drm/vmwgfx_drm.h |1 + 20 files changed, 2470 insertions(+), 675 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wed, Feb 11, 2015 at 02:05:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 10, 2015 at 06:38:08PM +, Simon Farnsworth wrote:
> > Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
> > in their I2C over AUX implementation (fixed in newer revisions). They work
> > fine with Windows, but fail with Linux.
> >
> > It turns out that they cannot keep an I2C transaction open unless the
> > previous read was 16 bytes; shorter reads can only be followed by a zero
> > byte transfer ending the I2C transaction.
> >
> > Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
> > reply, assume that there's a hardware bottleneck, and shrink our read size
> > to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
> > in the hopes that it'll be closest to what Windows does.
> >
> > Also provide an unsafe module parameter for testing smaller transfer sizes,
> > in case there are sinks out there that cannot work with Windows.
> >
> > Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
> > up native DP EDID reads; Ville Syrjälä
> > found
> > the following changes in his testing:
> >
> > Device under test: old -> with this patch
> > DP->DVI (OUI 001cf8): 40ms -> 35ms
> > DP->VGA (OUI 0022b9): 45ms -> 38ms
> > Zotac DP->2xHDMI: 25ms -> 4ms
> > Asus PB278 monitor:22ms -> 3ms
> >
> > A back of the envelope calculation shows that peak theoretical transfer rate
> > for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
> > around 500 kbit/s, which explains the increase in speed.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
> > Tested-by: Aidan Marks
> > Signed-off-by: Simon Farnsworth
> > ---
> >
> > v4 changes:
> >
> > * Change short reply algorithm after suggestions from Ville.
> >
> > * Expanded commit message.
> >
> > * Mark the module parameter unsafe.
> >
> > * Use clamp() to bring the module parameter into range when used.
> >
> > v3 changes, after feedback from Ville and more testing of Windows:
> >
> > * Change the short reply algorithm to match Ville's description of the
> >DisplayPort 1.2 spec wording.
> >
> > * Add a module parameter to set the default transfer size for
> >experiments. Requested over IRC by Ville.
> >
> > No-one's been able to find a device that does short replies, but experiments
> > show that bigger reads are faster on most devices. Ville got:
> >
> > DP->DVI (OUI 001cf8): 40ms -> 35ms
> > DP->VGA (OUI 0022b9): 45ms -> 38ms
> > Zotac DP->2xHDMI: 25ms -> 4ms
> >
> > v2 changes, after feedback from Thierry and Ville:
> >
> > * Handle short replies. I've decided (arbitrarily) that a short reply
> >results in us dropping back to the newly chosen size for the rest of this
> >I2C transaction. Thus, given an attempt to read the first 16 bytes of
> >EDID, and a sink that only does 4 bytes of buffering, we will see the
> >following AUX transfers for the EDID read (after address is set):
> >
> >
> >Read 16 bytes from I2C over AUX.
> >Reply with 4 bytes
> >Read 4 bytes
> >Reply with 4 bytes
> >Read 4 bytes
> >Reply with 4 bytes
> >Read 4 bytes
> >Reply with 4 bytes
> >
> >
> > Note that I've not looked at MST support - I have neither the DP 1.2 spec
> > nor any MST branch devices, so I can't test anything I write or check it
> > against a spec. It looks from the code, however, as if MST has the branch
> > device do the split from a big request into small transactions.
> >
> > drivers/gpu/drm/drm_dp_helper.c | 76
> > +++--
> > include/drm/drm_dp_helper.h | 5 +++
> > 2 files changed, 63 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 79968e3..105fd66 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct
> > i2c_adapter *adapter)
> > * retrying the transaction as appropriate. It is assumed that the
> > * aux->transfer function does not modify anything in the msg other than
> > the
> > * reply field.
> > + *
> > + * Returns bytes transferred on success, or a negative error code on
> > failure.
> > */
> > static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> > *msg)
> > {
> > unsigned int retry;
> > - int err;
> > + int ret;
> >
> > /*
> > * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
> > @@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> > struct drm_dp_aux_msg *msg)
> > */
> > for (retry = 0; retry < 7; retry++) {
> > mutex_lock(&aux->hw_mutex);
> > - err = aux->transfer(aux, msg);
> > + ret = aux->transfer(aux, msg);
> > mutex_unlock(&aux->hw_mutex);
> > -
[PATCH] drm/radeon: fix TOPDOWN handling for bo_create
gt; * improve fragmentation quality.
>> * 512kb was measured as the most optimal number.
>> */
>> - if (rbo->tbo.mem.size > 512 * 1024) {
>> + if (size > 512 * 1024) {
>> for (i = 0; i < c; i++) {
>> rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
>> }
>> @@ -252,7 +253,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>> bo->flags &= ~RADEON_GEM_GTT_WC;
>> #endif
>> - radeon_ttm_placement_from_domain(bo, domain);
>> + radeon_ttm_placement_from_domain(bo, domain, size);
>> /* Kernel allocation are uninterruptible */
>> down_read(&rdev->pm.mclk_lock);
>> r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
>> @@ -350,7 +351,7 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
>> domain, u64 max_offset,
>> return 0;
>> }
>> - radeon_ttm_placement_from_domain(bo, domain);
>> + radeon_ttm_placement_from_domain(bo, domain, bo->tbo.mem.size);
>> for (i = 0; i < bo->placement.num_placement; i++) {
>> /* force to pin into visible video ram */
>> if ((bo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
>> @@ -557,7 +558,7 @@ int radeon_bo_list_validate(struct radeon_device
>> *rdev,
>> }
>> retry:
>> - radeon_ttm_placement_from_domain(bo, domain);
>> + radeon_ttm_placement_from_domain(bo, domain,
>> bo->tbo.mem.size);
>> if (ring == R600_RING_TYPE_UVD_INDEX)
>> radeon_uvd_force_into_uvd_segment(bo,
>> allowed);
>> @@ -800,7 +801,8 @@ int radeon_bo_fault_reserve_notify(struct
>> ttm_buffer_object *bo)
>> return 0;
>> /* hurrah the memory is not visible ! */
>> - radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_VRAM);
>> + radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_VRAM,
>> +rbo->tbo.mem.size);
>> lpfn = rdev->mc.visible_vram_size >> PAGE_SHIFT;
>> for (i = 0; i < rbo->placement.num_placement; i++) {
>> /* Force into visible VRAM */
>> @@ -810,7 +812,8 @@ int radeon_bo_fault_reserve_notify(struct
>> ttm_buffer_object *bo)
>> }
>> r = ttm_bo_validate(bo, &rbo->placement, false, false);
>> if (unlikely(r == -ENOMEM)) {
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT,
>> +rbo->tbo.mem.size);
>> return ttm_bo_validate(bo, &rbo->placement, false, false);
>> } else if (unlikely(r != 0)) {
>> return r;
>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>> b/drivers/gpu/drm/radeon/radeon_ttm.c
>> index d02aa1d..ce8ed2d 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>> @@ -197,7 +197,8 @@ static void radeon_evict_flags(struct
>> ttm_buffer_object *bo,
>> switch (bo->mem.mem_type) {
>> case TTM_PL_VRAM:
>> if
>> (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready == false)
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU,
>> +
>> rbo->tbo.mem.size);
>> else if (rbo->rdev->mc.visible_vram_size <
>> rbo->rdev->mc.real_vram_size &&
>> bo->mem.start < (rbo->rdev->mc.visible_vram_size
>> >> PAGE_SHIFT)) {
>> unsigned fpfn = rbo->rdev->mc.visible_vram_size >>
>> PAGE_SHIFT;
>> @@ -209,7 +210,8 @@ static void radeon_evict_flags(struct
>> ttm_buffer_object *bo,
>> * BOs to be evicted from VRAM
>> */
>> radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_VRAM |
>> -
>> RADEON_GEM_DOMAIN_GTT);
>> +
>> RADEON_GEM_DOMAIN_GTT,
>> +
>> rbo->tbo.mem.size);
>> rbo->placement.num_busy_placement = 0;
>> for (i = 0; i < rbo->placement.num_placement; i++)
>> {
>> if (rbo->placements[i].flags &
>> TTM_PL_FLAG_VRAM) {
>> @@ -222,11 +224,13 @@ static void radeon_evict_flags(struct
>> ttm_buffer_object *bo,
>> }
>> }
>> } else
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT,
>> +
>> rbo->tbo.mem.size);
>> break;
>> case TTM_PL_TT:
>> default:
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU,
>> +rbo->tbo.mem.size);
>> }
>> *placement = rbo->placement;
>> }
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-TOPDOWN-handling-for-bo_create-v2.patch
Type: text/x-patch
Size: 9510 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/a386eb08/attachment-0001.bin>
[PATCH] drm/dp: Use large transactions for I2C over AUX
On Wed, Mar 11, 2015 at 09:28:20PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 11, 2015 at 02:05:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 10, 2015 at 06:38:08PM +, Simon Farnsworth wrote:
> > > Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have
> > > bugs
> > > in their I2C over AUX implementation (fixed in newer revisions). They work
> > > fine with Windows, but fail with Linux.
> > >
> > > It turns out that they cannot keep an I2C transaction open unless the
> > > previous read was 16 bytes; shorter reads can only be followed by a zero
> > > byte transfer ending the I2C transaction.
> > >
> > > Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
> > > reply, assume that there's a hardware bottleneck, and shrink our read size
> > > to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
> > > in the hopes that it'll be closest to what Windows does.
> > >
> > > Also provide an unsafe module parameter for testing smaller transfer
> > > sizes,
> > > in case there are sinks out there that cannot work with Windows.
> > >
> > > Note also that despite the previous comment in drm_dp_i2c_xfer, this
> > > speeds
> > > up native DP EDID reads; Ville Syrjälä > > linux.intel.com> found
> > > the following changes in his testing:
> > >
> > > Device under test: old -> with this patch
> > > DP->DVI (OUI 001cf8): 40ms -> 35ms
> > > DP->VGA (OUI 0022b9): 45ms -> 38ms
> > > Zotac DP->2xHDMI: 25ms -> 4ms
> > > Asus PB278 monitor:22ms -> 3ms
> > >
> > > A back of the envelope calculation shows that peak theoretical transfer
> > > rate
> > > for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases
> > > to
> > > around 500 kbit/s, which explains the increase in speed.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
> > > Tested-by: Aidan Marks
> > > Signed-off-by: Simon Farnsworth
> > > ---
> > >
> > > v4 changes:
> > >
> > > * Change short reply algorithm after suggestions from Ville.
> > >
> > > * Expanded commit message.
> > >
> > > * Mark the module parameter unsafe.
> > >
> > > * Use clamp() to bring the module parameter into range when used.
> > >
> > > v3 changes, after feedback from Ville and more testing of Windows:
> > >
> > > * Change the short reply algorithm to match Ville's description of the
> > >DisplayPort 1.2 spec wording.
> > >
> > > * Add a module parameter to set the default transfer size for
> > >experiments. Requested over IRC by Ville.
> > >
> > > No-one's been able to find a device that does short replies, but
> > > experiments
> > > show that bigger reads are faster on most devices. Ville got:
> > >
> > > DP->DVI (OUI 001cf8): 40ms -> 35ms
> > > DP->VGA (OUI 0022b9): 45ms -> 38ms
> > > Zotac DP->2xHDMI: 25ms -> 4ms
> > >
> > > v2 changes, after feedback from Thierry and Ville:
> > >
> > > * Handle short replies. I've decided (arbitrarily) that a short reply
> > >results in us dropping back to the newly chosen size for the rest of
> > > this
> > >I2C transaction. Thus, given an attempt to read the first 16 bytes of
> > >EDID, and a sink that only does 4 bytes of buffering, we will see the
> > >following AUX transfers for the EDID read (after address is set):
> > >
> > >
> > >Read 16 bytes from I2C over AUX.
> > >Reply with 4 bytes
> > >Read 4 bytes
> > >Reply with 4 bytes
> > >Read 4 bytes
> > >Reply with 4 bytes
> > >Read 4 bytes
> > >Reply with 4 bytes
> > >
> > >
> > > Note that I've not looked at MST support - I have neither the DP 1.2 spec
> > > nor any MST branch devices, so I can't test anything I write or check it
> > > against a spec. It looks from the code, however, as if MST has the branch
> > > device do the split from a big request into small transactions.
> > >
> > > drivers/gpu/drm/drm_dp_helper.c | 76
> > > +++--
> > > include/drm/drm_dp_helper.h | 5 +++
> > > 2 files changed, 63 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 79968e3..105fd66 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct
> > > i2c_adapter *adapter)
> > > * retrying the transaction as appropriate. It is assumed that the
> > > * aux->transfer function does not modify anything in the msg other than
> > > the
> > > * reply field.
> > > + *
> > > + * Returns bytes transferred on success, or a negative error code on
> > > failure.
> > > */
> > > static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
> > > drm_dp_aux_msg *msg)
> > > {
> > > unsigned int retry;
> > > - int err;
> > > + int ret;
> > >
> > > /*
> > >* DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device
> > > @@ -409,14
[PATCH v2 7/7] drm/fb: handle tiled connectors better
On Wed, Mar 11, 2015 at 10:23:14AM -0400, Rob Clark wrote:
> We don't want tile 0,0 to artificially constrain the size of the legacy
> fbdev device. Instead when reducing fb_size to be the minimum of all
> displays, only consider the rightmost and bottommost tiles.
>
> Signed-off-by: Rob Clark
> Tested-by: Hai Li
Yeah checkpatch isn't really happy about this and the previous one now,
but I didn't really see a easy way to fix it and it's late ;-) So pulled
them all into drm-misc.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index dca98a4..1a20db7 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1034,9 +1034,16 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> crtc_count = 0;
> for (i = 0; i < fb_helper->crtc_count; i++) {
> struct drm_display_mode *desired_mode;
> - int x, y;
> + struct drm_mode_set *mode_set;
> + int x, y, j;
> + /* in case of tile group, are we the last tile vert or horiz?
> + * If no tile group you are always the last one both vertically
> + * and horizontally
> + */
> + bool lastv = true, lasth = true;
>
> desired_mode = fb_helper->crtc_info[i].desired_mode;
> + mode_set = &fb_helper->crtc_info[i].mode_set;
>
> if (!desired_mode)
> continue;
> @@ -1051,8 +1058,21 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>
> sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
> sizes.surface_width);
> sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
> sizes.surface_height);
> - sizes.fb_width = min_t(u32, desired_mode->hdisplay + x,
> sizes.fb_width);
> - sizes.fb_height = min_t(u32, desired_mode->vdisplay + y,
> sizes.fb_height);
> +
> + for (j = 0; j < mode_set->num_connectors; j++) {
> + struct drm_connector *connector =
> mode_set->connectors[j];
> + if (connector->has_tile) {
> + lasth = (connector->tile_h_loc ==
> (connector->num_h_tile - 1));
> + lastv = (connector->tile_v_loc ==
> (connector->num_v_tile - 1));
> + /* cloning to multiple tiles is just
> crazy-talk, so: */
> + break;
> + }
> + }
> +
> + if (lasth)
> + sizes.fb_width = min_t(u32, desired_mode->hdisplay +
> x, sizes.fb_width);
> + if (lastv)
> + sizes.fb_height = min_t(u32, desired_mode->vdisplay +
> y, sizes.fb_height);
> }
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> --
> 2.1.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/radeon: fix TOPDOWN handling for bo_create
else if (rbo->rdev->mc.visible_vram_size <
>>> rbo->rdev->mc.real_vram_size &&
>>> bo->mem.start < (rbo->rdev->mc.visible_vram_size
>>> >> PAGE_SHIFT)) {
>>> unsigned fpfn = rbo->rdev->mc.visible_vram_size >>
>>> PAGE_SHIFT;
>>> @@ -209,7 +210,8 @@ static void radeon_evict_flags(struct
>>> ttm_buffer_object *bo,
>>> * BOs to be evicted from VRAM
>>> */
>>> radeon_ttm_placement_from_domain(rbo,
>>> RADEON_GEM_DOMAIN_VRAM |
>>> -
>>> RADEON_GEM_DOMAIN_GTT);
>>> +
>>> RADEON_GEM_DOMAIN_GTT,
>>> +
>>> rbo->tbo.mem.size);
>>> rbo->placement.num_busy_placement = 0;
>>> for (i = 0; i < rbo->placement.num_placement; i++)
>>> {
>>> if (rbo->placements[i].flags &
>>> TTM_PL_FLAG_VRAM) {
>>> @@ -222,11 +224,13 @@ static void radeon_evict_flags(struct
>>> ttm_buffer_object *bo,
>>> }
>>> }
>>> } else
>>> - radeon_ttm_placement_from_domain(rbo,
>>> RADEON_GEM_DOMAIN_GTT);
>>> + radeon_ttm_placement_from_domain(rbo,
>>> RADEON_GEM_DOMAIN_GTT,
>>> +
>>> rbo->tbo.mem.size);
>>> break;
>>> case TTM_PL_TT:
>>> default:
>>> - radeon_ttm_placement_from_domain(rbo,
>>> RADEON_GEM_DOMAIN_CPU);
>>> + radeon_ttm_placement_from_domain(rbo,
>>> RADEON_GEM_DOMAIN_CPU,
>>> +rbo->tbo.mem.size);
>>> }
>>> *placement = rbo->placement;
>>> }
>>
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-TOPDOWN-handling-for-bo_create-v3.patch
Type: text/x-patch
Size: 12758 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/a330c6f7/attachment-0001.bin>
[PATCH v2 7/7] drm/fb: handle tiled connectors better
On Wed, Mar 11, 2015 at 5:13 PM, Daniel Vetter wrote:
> On Wed, Mar 11, 2015 at 10:23:14AM -0400, Rob Clark wrote:
>> We don't want tile 0,0 to artificially constrain the size of the legacy
>> fbdev device. Instead when reducing fb_size to be the minimum of all
>> displays, only consider the rightmost and bottommost tiles.
>>
>> Signed-off-by: Rob Clark
>> Tested-by: Hai Li
>
> Yeah checkpatch isn't really happy about this and the previous one now,
> but I didn't really see a easy way to fix it and it's late ;-) So pulled
> them all into drm-misc.
>
yeah, I was going with the "lines were already too long to begin with,
and adding some line breaks made it more ugly" exception ;-)
BR,
-R
> Thanks, Daniel
>
>> ---
>> drivers/gpu/drm/drm_fb_helper.c | 26 +++---
>> 1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index dca98a4..1a20db7 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -1034,9 +1034,16 @@ static int drm_fb_helper_single_fb_probe(struct
>> drm_fb_helper *fb_helper,
>> crtc_count = 0;
>> for (i = 0; i < fb_helper->crtc_count; i++) {
>> struct drm_display_mode *desired_mode;
>> - int x, y;
>> + struct drm_mode_set *mode_set;
>> + int x, y, j;
>> + /* in case of tile group, are we the last tile vert or horiz?
>> + * If no tile group you are always the last one both vertically
>> + * and horizontally
>> + */
>> + bool lastv = true, lasth = true;
>>
>> desired_mode = fb_helper->crtc_info[i].desired_mode;
>> + mode_set = &fb_helper->crtc_info[i].mode_set;
>>
>> if (!desired_mode)
>> continue;
>> @@ -1051,8 +1058,21 @@ static int drm_fb_helper_single_fb_probe(struct
>> drm_fb_helper *fb_helper,
>>
>> sizes.surface_width = max_t(u32, desired_mode->hdisplay + x,
>> sizes.surface_width);
>> sizes.surface_height = max_t(u32, desired_mode->vdisplay + y,
>> sizes.surface_height);
>> - sizes.fb_width = min_t(u32, desired_mode->hdisplay + x,
>> sizes.fb_width);
>> - sizes.fb_height = min_t(u32, desired_mode->vdisplay + y,
>> sizes.fb_height);
>> +
>> + for (j = 0; j < mode_set->num_connectors; j++) {
>> + struct drm_connector *connector =
>> mode_set->connectors[j];
>> + if (connector->has_tile) {
>> + lasth = (connector->tile_h_loc ==
>> (connector->num_h_tile - 1));
>> + lastv = (connector->tile_v_loc ==
>> (connector->num_v_tile - 1));
>> + /* cloning to multiple tiles is just
>> crazy-talk, so: */
>> + break;
>> + }
>> + }
>> +
>> + if (lasth)
>> + sizes.fb_width = min_t(u32, desired_mode->hdisplay +
>> x, sizes.fb_width);
>> + if (lastv)
>> + sizes.fb_height = min_t(u32, desired_mode->vdisplay +
>> y, sizes.fb_height);
>> }
>>
>> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
>> --
>> 2.1.0
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/7] exynos: add g2d_scale_and_blend
This is a combination of g2d_copy_with_scale and g2d_scale.
It is a pretty common operation to scale one buffer and then
blend it on top of another, so provide a direct way to that
operation.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.c | 129 +
exynos/fimg2d.h| 5 ++
2 files changed, 134 insertions(+)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 7a3da82..20c3179 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -638,3 +638,132 @@ g2d_blend(struct g2d_context *ctx, struct g2d_image *src,
return 0;
}
+/**
+ * g2d_scale_and_blend - apply scaling to source buffer and then blend to
destination buffer
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @src: a pointer to g2d_image structure including image and buffer
+ * information to source.
+ * @dst: a pointer to g2d_image structure including image and buffer
+ * information to destination.
+ * @src_x: x start position to source buffer.
+ * @src_y: y start position to source buffer.
+ * @src_w: width value to source buffer.
+ * @src_h: height value to source buffer.
+ * @dst_x: x start position to destination buffer.
+ * @dst_y: y start position to destination buffer.
+ * @dst_w: width value to destination buffer.
+ * @dst_h: height value to destination buffer.
+ * @op: blend operation type.
+ */
+drm_public int
+g2d_scale_and_blend(struct g2d_context *ctx, struct g2d_image *src,
+ struct g2d_image *dst, unsigned int src_x, unsigned int src_y,
+ unsigned int src_w, unsigned int src_h, unsigned int dst_x,
+ unsigned int dst_y, unsigned int dst_w, unsigned int dst_h,
+ enum e_g2d_op op)
+{
+ union g2d_point_val pt;
+ union g2d_bitblt_cmd_val bitblt;
+ union g2d_blend_func_val blend;
+ unsigned int scale;
+ unsigned int scale_x, scale_y;
+
+ bitblt.val = 0;
+ blend.val = 0;
+
+ if (op == G2D_OP_SRC || op == G2D_OP_CLEAR)
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
+ else
+ g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_NORMAL);
+
+ g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
+ if (dst->buf_type == G2D_IMGBUF_USERPTR)
+ g2d_add_cmd(ctx, DST_BASE_ADDR_REG | G2D_BUF_USERPTR,
+ (unsigned long)&dst->user_ptr[0]);
+ else
+ g2d_add_cmd(ctx, DST_BASE_ADDR_REG, dst->bo[0]);
+
+ g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
+
+ g2d_add_cmd(ctx, SRC_SELECT_REG, src->select_mode);
+ g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
+
+ switch (src->select_mode) {
+ case G2D_SELECT_MODE_NORMAL:
+ if (src->buf_type == G2D_IMGBUF_USERPTR)
+ g2d_add_cmd(ctx, SRC_BASE_ADDR_REG | G2D_BUF_USERPTR,
+ (unsigned long)&src->user_ptr[0]);
+ else
+ g2d_add_cmd(ctx, SRC_BASE_ADDR_REG, src->bo[0]);
+
+ g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
+ break;
+ case G2D_SELECT_MODE_FGCOLOR:
+ g2d_add_cmd(ctx, FG_COLOR_REG, src->color);
+ break;
+ case G2D_SELECT_MODE_BGCOLOR:
+ g2d_add_cmd(ctx, BG_COLOR_REG, src->color);
+ break;
+ default:
+ fprintf(stderr , "failed to set src.\n");
+ return -EINVAL;
+ }
+
+ if (src_w == dst_w && src_h == dst_h)
+ scale = 0;
+ else {
+ scale = 1;
+ scale_x = g2d_get_scaling(src_w, dst_w);
+ scale_y = g2d_get_scaling(src_h, dst_h);
+ }
+
+ if (src_x + src_w > src->width)
+ src_w = src->width - src_x;
+ if (src_y + src_h > src->height)
+ src_h = src->height - src_y;
+
+ if (dst_x + dst_w > dst->width)
+ dst_w = dst->width - dst_x;
+ if (dst_y + dst_h > dst->height)
+ dst_h = dst->height - dst_y;
+
+ if (src_w <= 0 || src_h <= 0 || dst_w <= 0 || dst_h <= 0) {
+ fprintf(stderr, "invalid width or height.\n");
+ g2d_reset(ctx);
+ return -EINVAL;
+ }
+
+ if (scale) {
+ g2d_add_cmd(ctx, SRC_SCALE_CTRL_REG, G2D_SCALE_MODE_BILINEAR);
+ g2d_add_cmd(ctx, SRC_XSCALE_REG, scale_x);
+ g2d_add_cmd(ctx, SRC_YSCALE_REG, scale_y);
+ }
+
+ bitblt.data.alpha_blend_mode = G2D_ALPHA_BLEND_MODE_ENABLE;
+ blend.val = g2d_get_blend_op(op);
+ g2d_add_cmd(ctx, BITBLT_COMMAND_REG, bitblt.val);
+ g2d_add_cmd(ctx, BLEND_FUNCTION_REG, blend.val);
+
+ pt.val = 0;
+ pt.data.x = src_x;
+ pt.data.y = src_y;
+ g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val);
+ pt.val = 0;
+ pt.data.x
[PATCH 6/7] exynos: add fimg2d header to common includes
The reason for this change is to let userspace use the header.
Currently 'make install' does not install it.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/Makefile.am | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index 1715a85..35bc71f 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -14,11 +14,10 @@ libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
libdrm_exynos_la_SOURCES = \
exynos_drm.c \
exynos_fimg2d.c \
- exynos_fimg2d.h \
fimg2d_reg.h
libdrm_exynoscommonincludedir = ${includedir}/exynos
-libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
+libdrm_exynoscommoninclude_HEADERS = exynos_drm.h exynos_fimg2d.h
libdrm_exynosincludedir = ${includedir}/libdrm
libdrm_exynosinclude_HEADERS = exynos_drmif.h
--
2.0.5
[v3] libdrm: improvements to userspace exynos component
On 2015-03-11 19:56, Emil Velikov wrote: > Tobias, > Can you please re-spin the remaining patches on top of master, and > address Inki's comment. > Also please add Inki's and Joonyoung Shim's tags. Done. I hope I did the tagging correctly. With best wishes, Tobias
[PATCH] clk: provide clk_is_match() dummy for non-common clk
On 03/11/15 05:29, Russell King - ARM Linux wrote:
> On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
>> Hey Russell,
>>
>> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
>>> On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
ARM randconfig build tests found a new error for configurations
with COMMON_CLK disabled but HAS_CLK selected by the platform:
ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
This moves the declaration around, so this case is covered
by the existing static inline helper function.
Signed-off-by: Arnd Bergmann
Fixes: c69e182e51d89 ("clk: introduce clk_is_match")
BTW, we have a preexisting problem in clk_get_parent,
clk_round_rate and clk_set_parent, which I've worked around in
my randconfig builds so far. Should we do that the same way?
>>> NAK, as Uwe points out, you didn't address my comment.
>> You commented on the patch that is c69e182e51d8 ("clk: introduce
>> clk_is_match") now in next. Arnd just moved this around.
> *Sigh*
>
> Mike - please remove this commit until proper kernel patch process is
> honoured. We'll have some order here, and mutual respect of fellow
> kernel developers, rather than people selectively ignoring people.
> Yes, I realise that it fixes a bug, but it's utterly disgusting that
> comments on a patch are ignored and it's just picked up irrespective
> of comments being addressed.
>
> If you don't like that, bloody well do a better job.
>
The patch was *not* picked up after your mail was sent. The patch was
picked up the same day it was posted to the list (Feb 25). You sent
review comments a week later (March 4). I don't see any selective
ignoring here.
I'll fold the const comments from Geert, your comments, and Arnd's fix
into the patch. Here's the new patch:
8<
From: Michael Turquette
Subject: [PATCH] clk: introduce clk_is_match
Some drivers compare struct clk pointers as a means of knowing
if the two pointers reference the same clock hardware. This behavior is
dubious (drivers must not dereference struct clk), but did not cause any
regressions until the per-user struct clk patch was merged. Now the test
for matching clk's will always fail with per-user struct clk's.
clk_is_match is introduced to fix the regression and prevent drivers
from comparing the pointers manually.
Fixes: 035a61c314eb ("clk: Make clk API return per-user struct clk instances")
Cc: Russell King
Cc: Shawn Guo
Cc: Tomeu Vizoso
Signed-off-by: Michael Turquette
[arnd at arndb.de: Fix COMMON_CLK=N && HAS_CLK=Y config]
Signed-off-by: Arnd Bergmann
[sboyd at codeaurora.org: const arguments to clk_is_match() and
remove unnecessary ternary operation]
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 26 ++
include/linux/clk.h | 18 ++
2 files changed, 44 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b9f85fc2ce3f..237f23f68bfc 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2170,6 +2170,32 @@ int clk_get_phase(struct clk *clk)
}
/**
+ * clk_is_match - check if two clk's point to the same hardware clock
+ * @p: clk compared against q
+ * @q: clk compared against p
+ *
+ * Returns true if the two struct clk pointers both point to the same hardware
+ * clock node. Put differently, returns true if struct clk *p and struct clk *q
+ * share the same struct clk_core object.
+ *
+ * Returns false otherwise. Note that two NULL clks are treated as matching.
+ */
+bool clk_is_match(const struct clk *p, const struct clk *q)
+{
+ /* trivial case: identical struct clk's or both NULL */
+ if (p == q)
+ return true;
+
+ /* true if clk->core pointers match. Avoid derefing garbage */
+ if (!IS_ERR_OR_NULL(p) && !IS_ERR_OR_NULL(q))
+ if (p->core == q->core)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(clk_is_match);
+
+/**
* __clk_init - initialize the data structures in a struct clk
* @dev: device initializing this clk, placeholder for now
* @clk: clk being initialized
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 8381bbfbc308..68c16a6bedb3 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -125,6 +125,19 @@ int clk_set_phase(struct clk *clk, int degrees);
*/
int clk_get_phase(struct clk *clk);
+/**
+ * clk_is_match - check if two clk's point to the same hardware clock
+ * @p: clk compared against q
+ * @q: clk compared against p
+ *
+ * Returns true if the two struct clk pointers both point to the same hardware
+ * clock node. Put differently, returns true if struct clk *p and struct clk *q
+ * share the same struct clk_core object.
+ *
+ * Returns false otherwise. Note that two NULL clks are treated as matching.
+ */
+bool clk_is_match(const struct clk *p, const struct clk *q);
+
#else
static inline long clk_get_accu
[RFC v2 2/7] media: rc: Add cec protocol handling
Em Wed, 11 Mar 2015 12:24:53 +0100
Kamil Debski escreveu:
> Hi Mauro,
>
> I have some more comments/questions below.
>
> From: Mauro Carvalho Chehab [mailto:mchehab at osg.samsung.com]
> Sent: Sunday, March 08, 2015 3:21 PM
> >
> > Em Thu, 22 Jan 2015 17:04:34 +0100
> > Kamil Debski escreveu:
> >
> > (c/c linux-input ML)
> >
> > > Add cec protocol handling the RC framework.
> >
> > I added some comments, that reflects my understanding from what's there
> > at the keymap definitions found at:
> > http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
> >
> >
> > >
> > > Signed-off-by: Kamil Debski
> > > ---
> > > drivers/media/rc/keymaps/Makefile |1 +
> > > drivers/media/rc/keymaps/rc-cec.c | 133
> > +
> > > drivers/media/rc/rc-main.c|1 +
> > > include/media/rc-core.h |1 +
> > > include/media/rc-map.h|5 +-
> > > 5 files changed, 140 insertions(+), 1 deletion(-) create mode
>
> [snip]
>
> >
> > > + { 0x60, KEY_PLAY }, /* XXX CEC Spec: Play Function */
> > > + { 0x61, KEY_PLAYPAUSE }, /* XXX CEC Spec: Pause-Play Function */
> > > + { 0x62, KEY_RECORD }, /* XXX CEC Spec: Record Function */
> > > + { 0x63, KEY_PAUSE }, /* XXX CEC Spec: Pause-Record Function */
> > > + { 0x64, KEY_STOP }, /* XXX CEC Spec: Stop Function */
> > > + { 0x65, KEY_MUTE }, /* XXX CEC Spec: Mute Function */
> > > + /* 0x66: CEC Spec: Restore Volume Function */
> > > + { 0x67, KEY_TUNER }, /* XXX CEC Spec: Tune Function */
> > > + { 0x68, KEY_MEDIA }, /* CEC Spec: Select Media Function */
> > > + { 0x69, KEY_SWITCHVIDEOMODE} /* XXX CEC Spec: Select A/V Input
> > Function */,
> > > + { 0x6a, KEY_AUDIO} /* CEC Spec: Select Audio Input Function */,
> > > + { 0x6b, KEY_POWER} /* CEC Spec: Power Toggle Function */,
> > > + { 0x6c, KEY_SLEEP} /* XXX CEC Spec: Power Off Function */,
> > > + { 0x6d, KEY_WAKEUP} /* XXX CEC Spec: Power On Function */,
> >
> > Those "function" keycodes look weird. What's the difference between
> > those and the pure non-function variants?
>
> The note 2 applies to most of these function buttons. It says:
> "2 During a recording or timed recording, a device may ask the user
> for confirmation of this action before executing it."
Ok. So, it seems that we need to add new keycodes for those function variants,
as they should be handled on a different way than the usual keycodes.
>
> > The spec (CEC 13.13.3) says that:
> >
> > "Unlike the other codes, which just pass remote control presses
> > to the target (often with manufacturer-specific results),
> > the Functions are deterministic, ie they specify exactly the
> > state
> > after executing these commands. Several of these also have
> > further
> > operands, specifying the function in more detail, immediately
> > following the relevant [UI Command] operand."
> >
> > Some codes are actually compund ones. For example, 0x60 has a "play
> > mode"
> > operand. So, the actual mapping would be:
> >
> > 0x60 + 0x24 - "play forward"
> > 0x61 + 0x20 - "play reverse"
> > ...
> > (see CEC17 for operand descriptions)
> >
> > So, IMHO, the mapping should be
> >
> > { 0x6024, KEY_PLAY },
> > { 0x6020, KEY_PLAY_REVERSE }, // to be created
>
> The note 1 says that they can be issued without the additional operand
> specified:
> "1 Functions with additional operands may also be used without the
> additional operand: in this case the behavior is manufacturer-specific."
>
> Will this do?
> { 0x60, KEY_PLAY },
> { 0x6024, KEY_PLAY },
> { 0x6020, KEY_PLAY_REVERSE }, // to be created
> Or will the framework get confused that an incomplete key code was
> received?
The above should work.
> Another question I have is about the following operations:
> 0x67 Tune Function
> 0x68 Select Media Function
> 0x69 Select A/V Input Function
> 0x6a Select Audio Input Function
> These operations take an additional operand that is large number.
> 1-255 for 0x68-0x6a or even a more complex operand such as the channel
> number for 0x67.
>
> Any suggestion on how to implement these correctly?
Well, the scancode may have any size. The current rc core implementation
is limited to u64. The scancode seek uses binary search, so it should
be fast, even for a big 64 bits table.
So, supporting a big number is not an issue to the core.
For the channel number, however, I suspect that we need to think on a
better alternative, like sending a sequence of numeric keycodes.
Maybe Dmitry has a better suggestion.
>
> > ...
> >
> >
> > > + /* 0x6e-0x70: Reserved */
> > > + { 0x71, KEY_BLUE }, /* XXX CEC Spec: F1 (Blue) */
> > > + { 0x72, KEY_RED }, /* XXX CEC Spec: F2 (Red) */
> > > + { 0x73, KEY_GREEN }, /* XXX CEC Spec: F3 (Green) */
> > > + { 0x74, KEY_YELLOW }, /* XXX CEC Spec: F4 (Yellow) */
> > > + { 0x75, KEY_F5 },
> > > + { 0x76, KEY_CONNECT }, /* XXX CEC Spec: Data - see Note 3 */
> > > + /* Note 3: This is used, for example, to ent
[RESEND] nouveau regression 3.19: unable to load BIOS from ACPI
Hi Ben, Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP laptop. Looking at the recent changes (ad4a3626 split out shadow methods) in the bios shadow code, I think this happens: - nvbios_shadow loops over all possible bios sources - shadow_method - shadow_score - shadow_image tries to validate the image contents *before* loading it via ACPI calls - nvbios_imagen calls nv_ro16 on the bios object which tries to read 16 bytes directly from memory. Before the change, the code was: - mthd->shadow(bios); - which for ACPI calls nouveau_bios_shadow_acpi which doesn't try to validate the image mthd->score = nouveau_bios_score(bios, mthd->rw); which validates the image So shadowing always happened *before* trying to look at the bios data. The relevant log is below. Ortwin 3.18: Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e63c0a1 Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] Chipset: GK106 (NVE6) Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] Family : NVE0 Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... signature not found Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PROM for image... Feb 15 11:28:50 localhost kernel: fbcon: inteldrmfb (fb0) is primary device Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... signature not found Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... appears to be valid Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] using image from ACPI Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] BIT signature found 3.19: Feb 15 11:30:40 localhost kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEGP.DGFX handle Feb 15 11:30:40 localhost kernel: nouveau :01:00.0: enabling device (0004 -> 0007) Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e63c0a1 Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] Chipset: GK106 (NVE6) Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] Family : NVE0 Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau E[ VBIOS][:01:00.0] ACPI invalid Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking (null) for image... Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying PRAMIN... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] ... not enabled Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PROM for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying PROM... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : ROM signature () unknown Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] image 0 invalid Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PCIROM for image... Feb 15 11:30:40 loca
[PATCH 1/7] tests/exynos: fimg2d: add a checkerboard test
This makes it easier to spot memory corruptions which don't become
visible when using a plain buffer filled with a solid color (so
corruptions that are just a permutation of the bytes in the buffer).
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
tests/exynos/exynos_fimg2d_test.c | 117 ++
1 file changed, 117 insertions(+)
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index 14b38a9..da23f58 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -57,6 +57,9 @@ struct fimg2d_test_case {
int (*blend)(struct exynos_device *dev,
struct exynos_bo *src, struct exynos_bo *dst,
enum e_g2d_buf_type);
+ int (*checkerboard)(struct exynos_device *dev,
+ struct exynos_bo *src, struct exynos_bo *dst,
+ enum e_g2d_buf_type);
};
struct connector {
@@ -209,6 +212,33 @@ static struct exynos_bo *exynos_create_buffer(struct
exynos_device *dev,
return bo;
}
+/* Allocate buffer and fill it with checkerboard pattern, where the tiles *
+ * have a random color. The caller has to free the buffer.*/
+void *create_checkerboard_pattern(unsigned int num_tiles_x,
+ unsigned int num_tiles_y,
unsigned int tile_size)
+{
+ unsigned int *buf;
+ unsigned int x, y, i, j;
+ const unsigned int stride = num_tiles_x * tile_size;
+
+ if (posix_memalign((void*)&buf, 64, num_tiles_y * tile_size * stride *
4) != 0)
+ return NULL;
+
+ for (x = 0; x < num_tiles_x; ++x) {
+ for (y = 0; y < num_tiles_y; ++y) {
+ const unsigned int color = 0xff00 + (random() &
0xff);
+
+ for (i = 0; i < tile_size; ++i) {
+ for (j = 0; j < tile_size; ++j) {
+ buf[x * tile_size + y * stride *
tile_size + i + j * stride] = color;
+ }
+ }
+ }
+ }
+
+ return buf;
+}
+
static void exynos_destroy_buffer(struct exynos_bo *bo)
{
exynos_bo_destroy(bo);
@@ -540,11 +570,90 @@ err_free_userptr:
return 0;
}
+static int g2d_checkerboard_test(struct exynos_device *dev,
+ struct exynos_bo *src,
+ struct exynos_bo *dst,
+ enum e_g2d_buf_type type)
+{
+ struct g2d_context *ctx;
+ struct g2d_image src_img = {0}, dst_img = {0};
+ unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
+ void *checkerboard = NULL;
+ int ret;
+
+ ctx = g2d_init(dev->fd);
+ if (!ctx)
+ return -EFAULT;
+
+ dst_img.bo[0] = dst->handle;
+
+ src_x = 0;
+ src_y = 0;
+ dst_x = 0;
+ dst_y = 0;
+
+ checkerboard = create_checkerboard_pattern(screen_width / 32,
screen_height / 32, 32);
+ if (checkerboard == NULL) {
+ ret = -1;
+ goto fail;
+ }
+
+ img_w = screen_width - (screen_width % 32);
+ img_h = screen_height - (screen_height % 32);
+
+ switch (type) {
+ case G2D_IMGBUF_GEM:
+ memcpy(src->vaddr, checkerboard, img_w * img_h * 4);
+ src_img.bo[0] = src->handle;
+ break;
+ case G2D_IMGBUF_USERPTR:
+ src_img.user_ptr[0].userptr = (unsigned long)checkerboard;
+ src_img.user_ptr[0].size = img_w * img_h * 4;
+ break;
+ default:
+ ret = -EFAULT;
+ goto fail;
+ }
+
+ printf("checkerboard test with %s.\n",
+ type == G2D_IMGBUF_GEM ? "gem" : "userptr");
+
+ src_img.width = img_w;
+ src_img.height = img_h;
+ src_img.stride = src_img.width * 4;
+ src_img.buf_type = type;
+ src_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+
+ dst_img.width = screen_width;
+ dst_img.height = screen_height;
+ dst_img.stride = dst_img.width * 4;
+ dst_img.buf_type = G2D_IMGBUF_GEM;
+ dst_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+ src_img.color = 0xff00;
+ ret = g2d_solid_fill(ctx, &dst_img, src_x, src_y, screen_width,
screen_height);
+ if (ret < 0)
+ goto fail;
+
+ ret = g2d_copy(ctx, &src_img, &dst_img, src_x, src_y, dst_x, dst_y,
+ img_w, img_h);
+ if (ret < 0)
+ goto fail;
+
+ g2d_exec(ctx);
+
+fail:
+ free(checkerboard);
+ g2d_fini(ctx);
+
+ return ret;
+}
+
static struct fimg2d_test_case test_case = {
.solid_fill = &g2d_solid_fill_test,
.copy = &g2d_copy_test,
.copy_with_scal
[PATCH 3/7] exynos: honor the repeat mode in g2d_copy_with_scale
This is useful when the default repeat mode, which is 'repeat' produces artifacts at the borders of the copied image. Choose the 'pad' mode to make use of the color of the destination image. In my usage case the destination is the framebuffer, which is solid filled with a background color. Scaling with 'pad' mode would then just do the right thing and also produces nice borders on the output. Signed-off-by: Tobias Jakobi Reviewed-by: Inki Dae Tested-by: Joonyoung Shim --- exynos/exynos_fimg2d.c | 5 + 1 file changed, 5 insertions(+) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 20c3179..5f9e9a7 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -462,6 +462,11 @@ g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src, g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL); g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode); + + g2d_add_cmd(ctx, SRC_REPEAT_MODE_REG, src->repeat_mode); + if (src->repeat_mode == G2D_REPEAT_MODE_PAD) + g2d_add_cmd(ctx, SRC_PAD_VALUE_REG, dst->color); + g2d_add_base_addr(ctx, src, g2d_src); g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride); -- 2.0.5
[PATCH 4/7] exynos: use structure initialization instead of memset
Keeps the code cleaner, since the structs have to be initialized
once anyway.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.c| 4 +---
tests/exynos/exynos_fimg2d_test.c | 15 ---
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 5f9e9a7..aecd1c3 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -188,7 +188,7 @@ static void g2d_reset(struct g2d_context *ctx)
static int g2d_flush(struct g2d_context *ctx)
{
int ret;
- struct drm_exynos_g2d_set_cmdlist cmdlist;
+ struct drm_exynos_g2d_set_cmdlist cmdlist = {0};
if (ctx->cmd_nr == 0 && ctx->cmd_buf_nr == 0)
return -1;
@@ -198,8 +198,6 @@ static int g2d_flush(struct g2d_context *ctx)
return -EINVAL;
}
- memset(&cmdlist, 0, sizeof(struct drm_exynos_g2d_set_cmdlist));
-
cmdlist.cmd = (uint64_t)(uintptr_t)&ctx->cmd[0];
cmdlist.cmd_buf = (uint64_t)(uintptr_t)&ctx->cmd_buf[0];
cmdlist.cmd_nr = ctx->cmd_nr;
diff --git a/tests/exynos/exynos_fimg2d_test.c
b/tests/exynos/exynos_fimg2d_test.c
index da23f58..b7003c4 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -255,7 +255,7 @@ static void wait_for_user_input(int last)
static int g2d_solid_fill_test(struct exynos_device *dev, struct exynos_bo
*dst)
{
struct g2d_context *ctx;
- struct g2d_image img;
+ struct g2d_image img = {0};
unsigned int count, img_w, img_h;
int ret = 0;
@@ -263,7 +263,6 @@ static int g2d_solid_fill_test(struct exynos_device *dev,
struct exynos_bo *dst)
if (!ctx)
return -EFAULT;
- memset(&img, 0, sizeof(struct g2d_image));
img.bo[0] = dst->handle;
printf("solid fill test.\n");
@@ -306,7 +305,7 @@ static int g2d_copy_test(struct exynos_device *dev, struct
exynos_bo *src,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -315,8 +314,6 @@ static int g2d_copy_test(struct exynos_device *dev, struct
exynos_bo *src,
if (!ctx)
return -EFAULT;
- memset(&src_img, 0, sizeof(struct g2d_image));
- memset(&dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst->handle;
src_x = 0;
@@ -389,7 +386,7 @@ static int g2d_copy_with_scale_test(struct exynos_device
*dev,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -398,8 +395,6 @@ static int g2d_copy_with_scale_test(struct exynos_device
*dev,
if (!ctx)
return -EFAULT;
- memset(&src_img, 0, sizeof(struct g2d_image));
- memset(&dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst->handle;
src_x = 0;
@@ -477,7 +472,7 @@ static int g2d_blend_test(struct exynos_device *dev,
enum e_g2d_buf_type type)
{
struct g2d_context *ctx;
- struct g2d_image src_img, dst_img;
+ struct g2d_image src_img = {0}, dst_img = {0};
unsigned int src_x, src_y, dst_x, dst_y, img_w, img_h;
unsigned long userptr, size;
int ret;
@@ -486,8 +481,6 @@ static int g2d_blend_test(struct exynos_device *dev,
if (!ctx)
return -EFAULT;
- memset(&src_img, 0, sizeof(struct g2d_image));
- memset(&dst_img, 0, sizeof(struct g2d_image));
dst_img.bo[0] = dst->handle;
src_x = 0;
--
2.0.5
[PATCH 5/7] exynos: add exynos prefix to fimg2d header
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/Makefile.am| 2 +-
exynos/exynos_fimg2d.c| 2 +-
exynos/exynos_fimg2d.h| 322 ++
exynos/fimg2d.h | 322 --
tests/exynos/exynos_fimg2d_test.c | 2 +-
5 files changed, 325 insertions(+), 325 deletions(-)
create mode 100644 exynos/exynos_fimg2d.h
delete mode 100644 exynos/fimg2d.h
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index 06bee00..1715a85 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -14,7 +14,7 @@ libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
libdrm_exynos_la_SOURCES = \
exynos_drm.c \
exynos_fimg2d.c \
- fimg2d.h \
+ exynos_fimg2d.h \
fimg2d_reg.h
libdrm_exynoscommonincludedir = ${includedir}/exynos
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index aecd1c3..fc605ed 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -27,7 +27,7 @@
#include "libdrm.h"
#include "exynos_drm.h"
#include "fimg2d_reg.h"
-#include "fimg2d.h"
+#include "exynos_fimg2d.h"
#defineSET_BF(val, sc, si, scsa, scda, dc, di, dcsa, dcda) \
val.data.src_coeff = sc;\
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
new file mode 100644
index 000..f76f2a9
--- /dev/null
+++ b/exynos/exynos_fimg2d.h
@@ -0,0 +1,322 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics Co.Ltd
+ * Authors:
+ * Inki Dae
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef _FIMG2D_H_
+#define _FIMG2D_H_
+
+#define G2D_MAX_CMD_NR 64
+#define G2D_MAX_GEM_CMD_NR 64
+#define G2D_MAX_CMD_LIST_NR64
+#define G2D_PLANE_MAX_NR 2
+
+enum e_g2d_color_mode {
+ /* COLOR FORMAT */
+ G2D_COLOR_FMT_XRGB,
+ G2D_COLOR_FMT_ARGB,
+ G2D_COLOR_FMT_RGB565,
+ G2D_COLOR_FMT_XRGB1555,
+ G2D_COLOR_FMT_ARGB1555,
+ G2D_COLOR_FMT_XRGB,
+ G2D_COLOR_FMT_ARGB,
+ G2D_COLOR_FMT_PRGB888,
+ G2D_COLOR_FMT_YCbCr444,
+ G2D_COLOR_FMT_YCbCr422,
+ G2D_COLOR_FMT_YCbCr420,
+ /* alpha 8bit */
+ G2D_COLOR_FMT_A8,
+ /* Luminance 8bit: gray color */
+ G2D_COLOR_FMT_L8,
+ /* alpha 1bit */
+ G2D_COLOR_FMT_A1,
+ /* alpha 4bit */
+ G2D_COLOR_FMT_A4,
+ G2D_COLOR_FMT_MASK, /* VER4.1 */
+
+ /* COLOR ORDER */
+ G2D_ORDER_AXRGB = (0 << 4), /* VER4.1 */
+ G2D_ORDER_RGBAX = (1 << 4), /* VER4.1 */
+ G2D_ORDER_AXBGR = (2 << 4), /* VER4.1 */
+ G2D_ORDER_BGRAX = (3 << 4), /* VER4.1 */
+ G2D_ORDER_MASK = (3 << 4), /* VER4.1 */
+
+ /* Number of YCbCr plane */
+ G2D_YCbCr_1PLANE= (0 << 8), /* VER4.1 */
+ G2D_YCbCr_2PLANE= (1 << 8), /* VER4.1 */
+ G2D_YCbCr_PLANE_MASK= (3 << 8), /* VER4.1 */
+
+ /* Order in YCbCr */
+ G2D_YCbCr_ORDER_CrY1CbY0 = (0 << 12), /* VER4.1 */
+ G2D_YCbCr_ORDER_CbY1CrY0 = (1 << 12), /* VER4.1 */
+ G2D_YCbCr_ORDER_Y1CrY0Cb = (2 << 12), /* VER4.1 */
+ G2D_YCbCr_ORDER_Y1CbY0Cr = (3 << 12), /* VER4.1 */
+ G2D_YCbCr_ORDER_CrCb = G2D_YCbCr_ORDER_CrY1CbY0,/* VER4.1 */
+ G2D_YCbCr_ORDER_CbCr = G2D_YCbCr_ORDER_CbY1CrY0,/* VER4.1 */
+ G2D_YCbCr_ORDER_MASK = (3 < 12),/* VER4.1 */
+
+ /* CSC */
+ G2D_CSC_601 = (0 << 16),/* VER4.1 */
+ G2D_CSC_709 = (1 << 16),/* VER4.1 */
+ G2D_CSC_MASK = (1 << 16), /* VER4.1 */
+
+ /* Valid value range of YCbCr */
+ G2D_YCbCr_RANGE_NARROW = (0 << 17), /* VER4.1 */
+ G2D_YCbCr_RANGE_WIDE = (1 << 17), /* VER4.1 */
+ G2D_YCbCr_RANGE_MASK = (1 << 17), /* VER4.1 */
+
+ G2D_COLOR_MODE_MASK = 0x,
+};
+
+enum e_g2d_select_mode {
+ G2D_SELECT_MODE_NORMAL = (0 << 0),
+ G2D_SELECT_MODE_FGCOLOR = (1 << 0),
+ G2D_SELECT_MODE_BGCOLOR = (2 << 0),
+};
+
+enum e_g2d_repeat_mode {
+ G2D_REPEAT_MODE_REPEAT,
+ G2D_REPEAT_MODE_PAD,
+ G2D_REPEAT_MODE_REFLECT,
+ G2D_REPEAT_MODE_CLAMP,
+ G2D_REPEAT_MODE_NONE,
+};
+
+enum e_g2d_scale_mode {
+ G2D_SCALE_MODE_NONE = 0,
+ G2D_SCALE_MODE_NEAREST,
+ G2D_SCALE_MODE_BILINEAR,
+ G2D_SCALE_MODE_MAX,
+};
+
+enum e_g2d_buf_type {
+ G2D_IMGBUF_COLOR,
+ G2D_IMGBUF_GEM
[PATCH 7/7] exynos: fimg2d: follow-up fix for G2D_COEFF_MODE_GB_COLOR
Also add the register field formatting info provided by
Inki Dae .
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index f76f2a9..9db0c88 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -151,6 +151,12 @@ enum e_g2d_op {
G2D_OP_CONJOINT_DST = 0x22,
};
+/*
+ * The G2D_COEFF_MODE_DST_{COLOR,ALPHA} modes both use the ALPHA_REG(0x618)
+ * register. The registers fields are as follows:
+ * bits 31:8 = color value (RGB order)
+ * bits 7:0 = alpha value
+ */
enum e_g2d_coeff_mode {
G2D_COEFF_MODE_ONE,
G2D_COEFF_MODE_ZERO,
@@ -160,7 +166,7 @@ enum e_g2d_coeff_mode {
G2D_COEFF_MODE_DST_COLOR,
/* Global Alpha : Set by ALPHA_REG(0x618) */
G2D_COEFF_MODE_GB_ALPHA,
- /* Global Color : Set by ALPHA_REG(0x618) */
+ /* Global Color and Alpha : Set by ALPHA_REG(0x618) */
G2D_COEFF_MODE_GB_COLOR,
/* (1-SRC alpha)/DST Alpha */
G2D_COEFF_MODE_DISJOINT_S,
--
2.0.5
