[PATCH] drm/imx: Remove unneeded definition for structure imx_drm_component
No one is using the structure imx_drm_component, so let's remove the
definition to save several lines.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/imx-drm-core.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 9e7310e..8a043b5 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -34,11 +34,6 @@
#define MAX_CRTC 4
-struct imx_drm_component {
- struct device_node *of_node;
- struct list_head list;
-};
-
struct imx_drm_device {
struct drm_device *drm;
unsigned intpipes;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings
The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and
connected to DSI using four lanes.
Signed-off-by: Chris Zhong
---
Changes in v2: None
.../bindings/display/panel/innolux,p079zca.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
new file mode 100644
index 000..5c70a83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
@@ -0,0 +1,23 @@
+Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,p079zca"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ &mipi_dsi {
+ panel {
+ compatible = "innolux,p079zca";
+ reg = <0>;
+ power-supply = <...>;
+ backlight = <&backlight>;
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+ };
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver
Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Chris Zhong
---
Changes in v2:
- add some error check
- always use Low power mode to send commend
- add comments for all the sleep
- use DRM_DEV_ERROR instead of dev_err
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 ++
3 files changed, 356 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..99dd010 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_INNOLUX_P079ZCA
+ tristate "Innolux P079ZCA panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Innolux P079ZCA
+ TFT-LCD modules. The panel has a 1024x768 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
config DRM_PANEL_JDI_LT070ME05000
tristate "JDI LT070ME05000 WUXGA DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..bda2aa4 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
new file mode 100644
index 000..b8c34e0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -0,0 +1,344 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct innolux_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+
+ struct backlight_device *backlight;
+ struct regulator *supply;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct innolux_panel *to_innolux_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct innolux_panel, base);
+}
+
+static int innolux_panel_disable(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err;
+
+ if (!innolux->enabled)
+ return 0;
+
+ if (innolux->backlight) {
+ innolux->backlight->props.power = FB_BLANK_POWERDOWN;
+ backlight_update_status(innolux->backlight);
+ }
+
+ err = mipi_dsi_dcs_set_display_off(innolux->link);
+ if (err < 0)
+ DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
+ innolux->enabled = false;
+
+ return 0;
+}
+
+static int innolux_panel_unprepare(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err;
+
+ if (!innolux->prepared)
+ return 0;
+
+ err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
+ if (err < 0) {
+ DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
+ err);
+ return err;
+ }
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+ /* T8: 80ms - 1000ms */
+ msleep(80);
+
+ err = regulator_disable(innolux->supply);
+ if (err < 0)
+ return err;
+
+ innolux->prepared = false;
+
+ return 0;
+}
+
+static int innolux_panel_prepare(struct drm_panel *panel)
+{
+ struct innolux_panel *innolux = to_innolux_panel(panel);
+ int err, ret;
+
+ if (innolux->prepared)
+ return 0;
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 0);
+
+ err = regulator_enable(innolux->supply);
+ if (err < 0)
+ return err;
+
+ /* T2: 15ms - 1000ms */
+ usleep_range(15000, 16000);
+
+ gpiod_set_value_cansleep(innolux->enable_gpio, 1);
+
+ /* T4: 15ms - 1000ms */
+ usleep_range(15000, 16000);
+
+
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> 4 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3b81ded..905ded9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
> *adev, struct ttm_tt *ttm,
> struct ttm_mem_reg *mem);
> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
> u64 base);
> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
> int amdgpu_ttm_init(struct amdgpu_device *adev);
> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 118f4e6..92955fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> }
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> + int r;
> +
> + r = pci_resize_resource(adev->pdev, 0, size);
> +
> + if (r == -ENOTSUPP) {
> + /* The hardware don't support the extension. */
> + return;
> +
> + } else if (r == -ENOSPC) {
> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> + } else if (r) {
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
> +}
> +
> /*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index dc9b6d6..36a7aa5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index c087b00..7761ad3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> --
> 2.7.4
>
> _
Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form
Hi Tobias, On 14.03.2017 21:41, Tobias Jakobi wrote: > Krzysztof Kozlowski wrote: >> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: >>> Krzysztof Kozlowski wrote: On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: > Hello Krzysztof, > > I was wondering about the benefit of this. From a quick look these are > all messages that end up in the kernel log / dmesg. > > IIRC %pK does nothing there, since dmest_restrict is supposed to be used > to deny an unpriviliged user the access to the kernel log. > > Or am I missing something here? These are regular printks so depending on kernel options (e.g. dynamic debug, drm.debug) these might be printed also in the console. Of course we could argue then if access to one of the consoles is worth securing. >>> This here suggests otherwise. >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 >>> >>> I have not tested this, but IIRC %pK is not honored by the kernel >>> logging infrastucture. That's why dmesg_restrict is there. >>> >>> Correct me if I'm wrong. >> The %pK will not help for dmesg or /proc/kmsg but it will help for >> console (/dev/ttySACN, ttySN etc) because effectively it uses the same >> vsprintf()/pointer() functions. > Thanks for the explanation, I didn't know that there was a difference > there. In that case, looks good to me. > > Just to clarify %pK: Documentation/printk-formats.txt: %pK 0x01234567 or 0x0123456789abcdef For printing kernel pointers which should be hidden from unprivileged users. The behaviour of %pK depends on the kptr_restrict sysctl - see Documentation/sysctl/kernel.txt for more details. Documentation/sysctl/kernel.txt: kptr_restrict: This toggle indicates whether restrictions are placed on exposing kernel addresses via /proc and other interfaces. When kptr_restrict is set to (0), the default, there are no restrictions. When kptr_restrict is set to (1), kernel pointers printed using the %pK format specifier will be replaced with 0's unless the user has CAP_SYSLOG and effective user and group ids are equal to the real ids. This is because %pK checks are done at read() time rather than open() time, so if permissions are elevated between the open() and the read() (e.g via a setuid binary) then %pK will not leak kernel pointers to unprivileged users. Note, this is a temporary solution only. The correct long-term solution is to do the permission checks at open() time. Consider removing world read permissions from files that use %pK, and using dmesg_restrict to protect against uses of %pK in dmesg(8) if leaking kernel pointer values to unprivileged users is a concern. When kptr_restrict is set to (2), kernel pointers printed using %pK will be replaced with 0's regardless of privileges. --- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all
Polaris variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc
Re: [PATCH] drm/exynos/dsi: make te-gpios optional
On 15.03.2017 04:48, Inki Dae wrote:
>
> 2017년 03월 14일 00:30에 Andrzej Hajda 이(가) 쓴 글:
>> In case of HW-TRIGGER te-gpios interrupt is not necessary. With this
>> patch we can get rid of 60 interrupt callbacks per second.
> Andrzej,
>
> Sorry but above description is not clear.
I agree, it could be improved.
>
> If panel device node of command mode panel device doesn't provide te-gpios
> property then now the panel driver will fail to probe.
> Seems this patch makes it to allow the panel driver probing is always ok even
> if gpio is invalid.
I guess you mean DSI driver.
>
> So how about handling this at top of this function like below?
>
> if (!of_property_read_bool(node, "te-gpios"))
> return 0;
Looks OK, it can be also done without additional call:
dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
if (dsi->te_gpio == -ENOENT)
return 0;
>
> And I think the description should be modified properly including subject of
> this patch.
OK, I will post v2.
BTW, I though little bit about it and:
1. te-gpios property is in panel node, but panel driver do not use it at
all.
2. it is parsed by DSI driver, but DSI driver does not need it at all,
it just forwards it to DECON.
3. DECON driver uses it, but it does not control it at all: parsing,
switching on/off, life time.
So maybe it would better to move whole te-gpios property to DECON node,
maybe even make it interrupt property instead of gpio, as it servers
only to irq.
After move DECON driver would know when this property is required and
probe should fail (SW mode), it could control enable/disable of
associated irq - currently the code is racy,
and finally there will not be parsing of panel node by DSI driver - it
violates DT principles.
What do you think about it?
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 812e2ec..f95fac5 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1349,9 +1349,8 @@ static int exynos_dsi_register_te_irq(struct
>> exynos_dsi *dsi)
>>
>> dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
>> if (!gpio_is_valid(dsi->te_gpio)) {
>> -dev_err(dsi->dev, "no te-gpios specified\n");
>> -ret = dsi->te_gpio;
>> -goto out;
>> +dev_info(dsi->dev, "no te-gpios specified\n");
>> +return 0;
>> }
>>
>> ret = gpio_request(dsi->te_gpio, "te_gpio");
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> Is it possible on Carrizo asics? Or only supports on newer asics?
>
> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> wrote:
>> From: Christian König
>>
>> Try to resize BAR0 to let CPU access all of VRAM.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>> +
>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>> 4 files changed, 40 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 3b81ded..905ded9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
>> *adev, struct ttm_tt *ttm,
>> struct ttm_mem_reg *mem);
>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>> *mc, u64 base);
>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct
>> amdgpu_mc *mc);
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>> void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 118f4e6..92955fe 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>> struct amdgpu_mc *mc)
>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>> }
>>
>> +/**
>> + * amdgpu_resize_bar0 - try to resize BAR0
>> + *
>> + * @adev: amdgpu_device pointer
>> + *
>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>> + */
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>> + int r;
>> +
>> + r = pci_resize_resource(adev->pdev, 0, size);
>> +
>> + if (r == -ENOTSUPP) {
>> + /* The hardware don't support the extension. */
>> + return;
>> +
>> + } else if (r == -ENOSPC) {
>> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
>> + } else if (r) {
>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>> + }
>> +
>> + /* Reinit the doorbell mapping, it is most likely moved as well */
>> + amdgpu_doorbell_fini(adev);
>> + BUG_ON(amdgpu_doorbell_init(adev));
>> +}
>> +
>> /*
>>* GPU helpers function.
>>*/
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> index dc9b6d6..36a7aa5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
>> break;
>> }
>> adev->mc.vram_width = numchan * chansize;
>> - /* Could aper size report 0 ? */
>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> /* size in MB on si */
>> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>> 1024ULL;
>> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
>> * 1024ULL;
>>
>> + if (!(adev->flags & AMD_IS_APU))
>> + amdgpu_resize_bar0(adev);
>> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> +
>> #ifdef CONFIG_X86_64
>> if (adev->flags & AMD_IS_APU) {
>> adev->mc.aper_base =
>> ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
>> a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> index c087b00..7761ad3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> @@ -459,13 +459,15 @
[PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 188f6f7..7e17a60 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -10,7 +10,7 @@ Required properties: - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference clock(ref) and APB clock(pclk). For RK3399, a phy config clock - (phy_cfg) is additional required. As described in [1]. + (phy_cfg) and a grf clock(grf) are additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/rockchip/dsi: enable the grf clk before writing grf registers
For RK3399, the grf clk should be enabled before writing grf registers,
otherwise the register value can not be changed.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f84f9ae..d8f24f2 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -291,6 +291,7 @@ struct dw_mipi_dsi {
struct regmap *grf_regmap;
void __iomem *base;
+ struct clk *grf_clk;
struct clk *pllref_clk;
struct clk *pclk;
struct clk *phy_cfg_clk;
@@ -979,6 +980,16 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
dw_mipi_dsi_dphy_interface_config(dsi);
dw_mipi_dsi_clear_err(dsi);
+ /*
+* For the RK3399, the clk of grf must be enabled before writing grf
+* register.
+*/
+ ret = clk_prepare_enable(dsi->grf_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable grf_clk\n");
+ return;
+ }
+
if (pdata->grf_dsi0_mode_reg)
regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
pdata->grf_dsi0_mode);
@@ -1003,6 +1014,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
dsi->dpms_mode = DRM_MODE_DPMS_ON;
+
+ clk_disable_unprepare(dsi->grf_clk);
}
static int
@@ -1238,6 +1251,17 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_dbg(dev, "have not phy_cfg_clk\n");
}
+ dsi->grf_clk = devm_clk_get(dev, "grf");
+ if (IS_ERR(dsi->grf_clk)) {
+ ret = PTR_ERR(dsi->grf_clk);
+ if (ret != -ENOENT) {
+ dev_err(dev, "Unable to get grf_clk: %d\n", ret);
+ return ret;
+ }
+ dsi->grf_clk = NULL;
+ dev_dbg(dev, "have not grf_clk\n");
+ }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/rockchip/dsi: correct the grf_switch_reg name
For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20,
not RK3399_GRF_SOC_CON19.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d8f24f2..ddd5dba 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -34,7 +34,7 @@
#define RK3288_DSI0_SEL_VOP_LITBIT(6)
#define RK3288_DSI1_SEL_VOP_LITBIT(9)
-#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_DSI0_SEL_VOP_LITBIT(0)
#define RK3399_DSI1_SEL_VOP_LITBIT(4)
@@ -1146,7 +1146,7 @@ static struct dw_mipi_dsi_plat_data
rk3288_mipi_dsi_drv_data = {
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3399_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3399_DSI1_SEL_VOP_LIT,
- .grf_switch_reg = RK3399_GRF_SOC_CON19,
+ .grf_switch_reg = RK3399_GRF_SOC_CON20,
.grf_dsi0_mode = RK3399_GRF_DSI_MODE,
.grf_dsi0_mode_reg = RK3399_GRF_SOC_CON22,
.max_data_lanes = 4,
--
2.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [rfc] amdgpu/sync_file shared semaphores
On Wed, Mar 15, 2017 at 11:09:39AM +1000, Dave Airlie wrote: > On 14 March 2017 at 18:53, Daniel Vetter wrote: > > On Tue, Mar 14, 2017 at 10:50:49AM +1000, Dave Airlie wrote: > >> This contains one libdrm patch and 4 kernel patches. > >> > >> The goal is to implement the Vulkan KHR_external_semaphore_fd interface > >> for permanent semaphore behaviour for radv. > >> > >> This code tries to enhance sync file to add the required behaviour > >> (which is mostly being able to replace the fence backing the sync file), > >> it also introduces new API to amdgpu to create/destroy/export/import the > >> sync_files which we store in an idr there, rather than fds. > >> > >> There is a possibility we should share the amdgpu_sem object tracking > >> code for other drivers, maybe we should move that to sync_file as well, > >> but I'm open to suggestions for whether this is a useful approach for > >> other drivers. > > > > Yeah, makes sense. I couldn't google the spec and didn't bother to figure > > out where my intel khronos login went, so didn't double-check precise > > semantics, just dropped a question. Few more things on the actual > > sync_file stuff itself. > > > > Really big wish here is for some igts using the debug/testing fence stuff > > we have in vgem so that we can validate the corner-cases of fence > > replacement and make sure nothing falls over. Especially with all the rcu > > dancing sync_file/dma_fence have become non-trival, exhaustive testing is > > needed here imo. > > We'd have to add vgem specific interfaces to trigger the replacement > path though, > since the replacement path is only going to be used for the semaphore > sematics. > > Suggestions on how to test better welcome! Yeah, vgem semaphore replacement ioctl is what I had in mind. And I guess if you don't get around to it, we will when we do the i915 side of this :-) -Daniel > > > > > Also, NULL sync_file->fence is probably what we want for the future fences > > (which android wants to keep tilers well-fed by essentially looping the > > entire render pipeline on itself), so this goes into the right direction > > for sure. I think, but coffee kicked in already :-) > > Dave. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
On Wed, Mar 15, 2017 at 01:01:19AM +0100, Marek Olšák wrote: > While it's nice that you are all having fun here, I don't think that's > the way to communicate this. > > The truth is, if AMD had an open source driver using the semaphores > (e.g. Vulkan) and if the libdrm semaphore code was merged, Dave > wouldn't be able to change it, ever. If a dependent open source > project relies on some libdrm interface, that interface is set in > stone. So AMD wouldn't be able to change it either. Unfortunately, > such an open source project doesn't exist, so the community can assume > that this libdrm code is still in the "initial design phase". Dave has > an upper hand here, because he actually has an open source project > that will use this, while AMD doesn't (yet). However, AMD can still > negotiate some details here, i.e. do a proper review. Fully agreed, that's why there was this "internal" qualifier. If you do this internally, then it's not final, if you discuss it here on the m-l, it actually matters. So drag your internal teams into the public, and it's all fine. -Daniel > > Marek > > > On Tue, Mar 14, 2017 at 7:10 PM, Christian König > wrote: > > Am 14.03.2017 um 18:45 schrieb Harry Wentland: > >> > >> On 2017-03-14 06:04 AM, zhoucm1 wrote: > >>> > >>> > >>> > >>> On 2017年03月14日 17:20, Christian König wrote: > > Am 14.03.2017 um 09:54 schrieb Daniel Vetter: > > > > On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote: > >> > >> > >> On 2017年03月14日 10:52, Dave Airlie wrote: > >>> > >>> On 14 March 2017 at 12:00, zhoucm1 wrote: > > Hi Dave, > > Could you tell me why you create your new one patch? I remember I > send out > our the whole implementation, Why not directly review our patches? > >>> > >>> This is patch review, I'm not sure what you are expecting in terms of > >>> direct review. > >>> > >>> The patches you sent out were reviewed by Christian, he stated he > >>> thinks this should > >>> use sync_file, I was interested to see if this was actually possible, > >>> so I just adapted > >>> the patches to check if it was possible to avoid adding a lot of amd > >>> specific code > >>> for something that isn't required to be. Hence why I've sent this as > >>> an rfc, as I want > >>> to see if others think using sync_file is a good or bad idea. We may > >>> end up going > >>> back to the non-sync_file based patches if this proves to be a bad > >>> idea, so far it > >>> doesn't look like one. > >>> > >>> I also reviewed the patches and noted it shouldn't add the > >>> wait/signal > >>> interfaces, > >>> that it should use the chunks on command submission, so while I was > >>> in > >>> there I re > >>> wrote that as well. > >> > >> Yeah, then I'm ok with this, just our internal team has used this > >> implementation, they find some gaps between yours and previous, they > >> could > >> need to change their's again, they are annoyance for this. > > > > This is why you _must_ get anything you're doing discussed in upstream > > first. Your internal teams simply do not have design authority on stuff > > like that. And yes it takes forever to get formerly proprietary > > internal-only teams to understand this, speaking from years of > > experience > > implement a proper upstream-design-first approach to feature > > development > > here at intel. > > > "internal teams simply do not have design authority on stuff like that" > > Can I print that on a t-shirt and start to sell it? > >>> > >>> I guess you cannot dress it to go to office..:) > >>> > >> > >> I'd wear it to the office. > >> > >> https://www.customink.com/lab?cid=hkp0-00ay-6vjg > > > > > > I'm only at an AMD office every few years, so that's probably not worth it. > > > > Anyway it's really something we should keep in mind if we want to upstream > > things. > > > > Christian. > > > > > >> > >> Harry > >> > >>> David Zhou > > > Christian. > > > -Daniel > > > > >>> > >>> ___ > >>> amd-gfx mailing list > >>> amd-...@lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > > > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] sync_file: add replace and export some functionality
On Wed, Mar 15, 2017 at 02:19:16PM +1000, Dave Airlie wrote:
> >
> > uabi semantics question: Should we wake up everyone when the fence gets
> > replaced? What's the khr semaphore expectation here?
>
> There are no real semantics for this case, you either wait the semaphore and
> replace it with NULL, or signal it where you replace the fence with a new
> fence.
>
> Nobody should be using the sync_fence interfaces to poll on these fence fds.
>
> So not crashing for non-vulkan behaviour is what we need.
>
> The spec doesn't know anything other than this is an opaque fd,
> it shouldn't be doing operations on it, execpt importing it.
>
> >> static int sync_file_set_fence(struct sync_file *sync_file,
> >> struct dma_fence **fences, int num_fences)
> >> {
> >> @@ -292,8 +328,10 @@ static void sync_file_free(struct kref *kref)
> >> struct sync_file *sync_file = container_of(kref, struct sync_file,
> >>kref);
> >>
> >> - if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
> >> - dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
> >> + if (sync_file->fence) {
> >> + if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
> >> + dma_fence_remove_callback(sync_file->fence,
> >> &sync_file->cb);
> >> + }
> >> dma_fence_put(sync_file->fence);
> >> kfree(sync_file);
> >> }
> >
> > I think you've missed _poll, won't that oops now?
>
> I don't think it will, all the stuff do inside the poll handler is
> protected by the mutex
> or do you think we should hook the new fence if the old fence has poll
> enabled?
Yeah, or at least wake them up somehow and restart it. Or well at least
think what would happen when that does, and whether we care. If vk says
you get undefined behaviour when you replace the fence of a semaphore when
the old one hasn't signalled yet, then we don't need to do anything.
But if they spec some behaviour poll returning "ready" way after you've
replaced the fence and the new one is definitely not ready is a bit
confusing semantics. Or maybe that's exactly the semantics vulkan once,
but then we need to be careful with restarts and stuff.
wrt the oops I think there's a possibility of a use-after-free: Thus far
the wait inherited the fence reference from the sync_file (since poll
stops before the file ref is gone), but now the fence could disappear
underneath it. add_callback itself doesn't grab a reference on its own.
So either we need synchronous replacement for poll or grab a reference
there. I think at least ... coffee not yet entirely working. In any case,
this kind of nasty corner case is perfect for some vgem testing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: Remove unneeded definition for structure imx_drm_component
On Wed, 2017-03-15 at 14:52 +0800, Liu Ying wrote:
> No one is using the structure imx_drm_component, so let's remove the
> definition to save several lines.
>
> Signed-off-by: Liu Ying
Thanks, applied to imx-drm/next.
regards
Philipp
> ---
> drivers/gpu/drm/imx/imx-drm-core.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 9e7310e..8a043b5 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -34,11 +34,6 @@
>
> #define MAX_CRTC 4
>
> -struct imx_drm_component {
> - struct device_node *of_node;
> - struct list_head list;
> -};
> -
> struct imx_drm_device {
> struct drm_device *drm;
> unsigned intpipes;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This creates a new interface for amdgpu with ioctls to
> create/destroy/import and export shared semaphores using
> sem object backed by the sync_file code. The semaphores
> are not installed as fd (except for export), but rather
> like other driver internal objects in an idr. The idr
> holds the initial reference on the sync file.
>
> The command submission interface is enhanced with two new
> chunks, one for semaphore waiting, one for semaphore signalling
> and just takes a list of handles for each.
>
> This is based on work originally done by David Zhou at AMD,
> with input from Christian Konig on what things should look like.
>
> NOTE: this interface addition needs a version bump to expose
> it to userspace.
>
> Signed-off-by: Dave Airlie
Another uapi corner case: Since you allow semaphores to be created before
they have a first fence attached, that essentially creates future fences.
I.e. sync_file fd with no fence yet attached. We want that anyway, but
maybe not together with semaphores (since there's some more implications).
I think it'd be good to attach a dummy fence which already starts out as
signalled to sync_file->fence for semaphores. That way userspace can't go
evil, create a semaphore, then pass it to a driver which then promptly
oopses or worse because it assumes then when it has a sync_file, it also
has a fence. And the dummy fence could be globally shared, so not really
overhead.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
>
> include/uapi/drm/amdgpu_drm.h | 28 +
> 6 files changed, 322 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 2814aad..404bcba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> - amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> + amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
>
> # add asic specific block
> amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index c1b9135..4ed8811 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -702,6 +702,8 @@ struct amdgpu_fpriv {
> struct mutexbo_list_lock;
> struct idr bo_list_handles;
> struct amdgpu_ctx_mgr ctx_mgr;
> + spinlock_t sem_handles_lock;
> + struct idr sem_handles;
> };
>
> /*
> @@ -1814,5 +1816,15 @@ amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
> uint64_t addr, struct amdgpu_bo **bo);
> int amdgpu_cs_sysvm_access_required(struct amdgpu_cs_parser *parser);
>
> +int amdgpu_sem_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp);
> +void amdgpu_sem_destroy(struct amdgpu_fpriv *fpriv, u32 handle);
> +int amdgpu_sem_lookup_and_signal(struct amdgpu_fpriv *fpriv,
> + uint32_t handle,
> + struct dma_fence *fence);
> +int amdgpu_sem_lookup_and_sync(struct amdgpu_device *adev,
> +struct amdgpu_fpriv *fpriv,
> +struct amdgpu_sync *sync,
> +uint32_t handle);
> #include "amdgpu_object.h"
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 4671432..80fc94b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -217,6 +217,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p,
> void *data)
> break;
>
> case AMDGPU_CHUNK_ID_DEPENDENCIES:
> + case AMDGPU_CHUNK_ID_SEM_WAIT:
> + case AMDGPU_CHUNK_ID_SEM_SIGNAL:
> break;
>
> default:
> @@ -1009,6 +1011,28 @@ static int amdgpu_process_fence_dep(struct
> amdgpu_device *adev,
> return 0;
> }
>
> +static int amdgpu_process_sem_wait_dep(struct amdgpu_device *adev,
> +struct amdgpu_cs_parser *p,
> +struct amdgpu_cs_chunk *chunk)
> +{
> + struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> + unsigne
Re: [PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
Am Mittwoch, 15. März 2017, 16:42:30 CET schrieb Chris Zhong: > For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, > add the description for this clock. > > Signed-off-by: Chris Zhong > --- > > .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 > +- 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt index 188f6f7..7e17a60 100644 > --- > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt +++ > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t > xt @@ -10,7 +10,7 @@ Required properties: > - interrupts: Represent the controller's interrupt to the CPU(s). > - clocks, clock-names: Phandles to the controller's pll reference >clock(ref) and APB clock(pclk). For RK3399, a phy config clock > - (phy_cfg) is additional required. As described in [1]. > + (phy_cfg) and a grf clock(grf) are additional required. As described in > [1]. your "grf" clock is optional, as it is not present on all socs (like the rk3288) so should probably move to a separate section and not be in the required properties Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/dsi: make te-gpios optional
2017년 03월 15일 16:58에 Andrzej Hajda 이(가) 쓴 글:
> On 15.03.2017 04:48, Inki Dae wrote:
>>
>> 2017년 03월 14일 00:30에 Andrzej Hajda 이(가) 쓴 글:
>>> In case of HW-TRIGGER te-gpios interrupt is not necessary. With this
>>> patch we can get rid of 60 interrupt callbacks per second.
>> Andrzej,
>>
>> Sorry but above description is not clear.
>
> I agree, it could be improved.
>
>>
>> If panel device node of command mode panel device doesn't provide te-gpios
>> property then now the panel driver will fail to probe.
>> Seems this patch makes it to allow the panel driver probing is always ok
>> even if gpio is invalid.
>
> I guess you mean DSI driver.
mipi_dsi_attach function call fails and this function is called by panel driver
so panel driver probing would fail.
>
>>
>> So how about handling this at top of this function like below?
>>
>> if (!of_property_read_bool(node, "te-gpios"))
>> return 0;
>
> Looks OK, it can be also done without additional call:
> dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
> if (dsi->te_gpio == -ENOENT)
> return 0;
>
>>
>> And I think the description should be modified properly including subject of
>> this patch.
>
> OK, I will post v2.
>
> BTW, I though little bit about it and:
> 1. te-gpios property is in panel node, but panel driver do not use it at
> all.
Right but panel driver don't have to use this because te(Tearing Effect) signal
means that MCU completed to transter all data of SRAM - internal framebuffer of
panel device - to Display panel. So TE is used to notify the completion to
Display controller.
> 2. it is parsed by DSI driver, but DSI driver does not need it at all,
> it just forwards it to DECON.
The reason - te interrupt handler is registered by DSI driver - is that te
interrupt handler should be registered at driver probing but display controller
- FIMD and DECON - drivers cannot know the te gpio pin until crtc and connector
is connected.
So DSI driver just registers te interrupt handler and this handler just calls
crct's handler at ready status.
> 3. DECON driver uses it, but it does not control it at all: parsing,
> switching on/off, life time.
>
> So maybe it would better to move whole te-gpios property to DECON node,
> maybe even make it interrupt property instead of gpio, as it servers
> only to irq.
> After move DECON driver would know when this property is required and
> probe should fail (SW mode), it could control enable/disable of
> associated irq - currently the code is racy,
> and finally there will not be parsing of panel node by DSI driver - it
> violates DT principles.
>
> What do you think about it?
About this, we had already discussion before and Thierry gave us good comments,
https://lists.freedesktop.org/archives/dri-devel/2014-July/063201.html
I believe above discussion would give you some help to understand why we handle
TE interrupt like now.
Anyway, agree. now code is not good so it could be more cleanned up.
Thanks,
Inki Dae
>
> Regards
> Andrzej
>
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 ++---
>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index 812e2ec..f95fac5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -1349,9 +1349,8 @@ static int exynos_dsi_register_te_irq(struct
>>> exynos_dsi *dsi)
>>>
>>> dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
>>> if (!gpio_is_valid(dsi->te_gpio)) {
>>> - dev_err(dsi->dev, "no te-gpios specified\n");
>>> - ret = dsi->te_gpio;
>>> - goto out;
>>> + dev_info(dsi->dev, "no te-gpios specified\n");
>>> + return 0;
>>> }
>>>
>>> ret = gpio_request(dsi->te_gpio, "te_gpio");
>>>
>>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks
2017년 03월 15일 09:54에 Inki Dae 이(가) 쓴 글:
>
>
> 2017년 03월 14일 22:28에 Daniel Vetter 이(가) 쓴 글:
>> On Mon, Mar 13, 2017 at 03:18:05PM -0400, Sean Paul wrote:
>>> On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote:
Again no apparent explanation for the split except hysterical raisins.
Merging them also makes it a bit more obviuos what's going on wrt the
runtime pm refdancing.
>>>
>>> Commit message copypasta.
>>
>> Hm, yeah. Inki, can you pls adjust that when merging to exynos-next? Just
>> drop the last sentence that talks about pm refdancing.
>> -Daniel
>
> No problem. :)
Seems you want this patch to be tested enough on each maintainer tree. Picked
it up.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>>>
>>> The code is
>>>
>>> Reviewed-by: Sean Paul
>>>
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b4522f67b3cb..180e3c9884e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -194,14 +194,9 @@ static int exynos_drm_open(struct drm_device *dev,
struct drm_file *file)
return ret;
}
-static void exynos_drm_preclose(struct drm_device *dev,
- struct drm_file *file)
-{
- exynos_drm_subdrv_close(dev, file);
-}
-
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
*file)
{
+ exynos_drm_subdrv_close(dev, file);
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -259,7 +254,6 @@ static struct drm_driver exynos_drm_driver = {
.load = exynos_drm_load,
.unload = exynos_drm_unload,
.open = exynos_drm_open,
- .preclose = exynos_drm_preclose,
.lastclose = exynos_drm_lastclose,
.postclose = exynos_drm_postclose,
.gem_free_object_unlocked = exynos_drm_gem_free_object,
--
2.11.0
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Yes, exactly that.
Christian.
Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct
amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev) {
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
* 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base =
((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
Am 15.03.2017 um 09:48 schrieb Daniel Vetter: On Wed, Mar 15, 2017 at 01:01:19AM +0100, Marek Olšák wrote: While it's nice that you are all having fun here, I don't think that's the way to communicate this. The truth is, if AMD had an open source driver using the semaphores (e.g. Vulkan) and if the libdrm semaphore code was merged, Dave wouldn't be able to change it, ever. If a dependent open source project relies on some libdrm interface, that interface is set in stone. So AMD wouldn't be able to change it either. Unfortunately, such an open source project doesn't exist, so the community can assume that this libdrm code is still in the "initial design phase". Dave has an upper hand here, because he actually has an open source project that will use this, while AMD doesn't (yet). However, AMD can still negotiate some details here, i.e. do a proper review. Fully agreed, that's why there was this "internal" qualifier. If you do this internally, then it's not final, if you discuss it here on the m-l, it actually matters. So drag your internal teams into the public, and it's all fine. Unfortunately it's not done with that. You also need to raise company wide awareness of changed needs. For example the concept that changes aren't allowed to break older upstream components is completely new to most teams inside AMD. It's a rather painful learning curve when you want to move projects from closed source to open source. Christian. -Daniel Marek On Tue, Mar 14, 2017 at 7:10 PM, Christian König wrote: Am 14.03.2017 um 18:45 schrieb Harry Wentland: On 2017-03-14 06:04 AM, zhoucm1 wrote: On 2017年03月14日 17:20, Christian König wrote: Am 14.03.2017 um 09:54 schrieb Daniel Vetter: On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote: On 2017年03月14日 10:52, Dave Airlie wrote: On 14 March 2017 at 12:00, zhoucm1 wrote: Hi Dave, Could you tell me why you create your new one patch? I remember I send out our the whole implementation, Why not directly review our patches? This is patch review, I'm not sure what you are expecting in terms of direct review. The patches you sent out were reviewed by Christian, he stated he thinks this should use sync_file, I was interested to see if this was actually possible, so I just adapted the patches to check if it was possible to avoid adding a lot of amd specific code for something that isn't required to be. Hence why I've sent this as an rfc, as I want to see if others think using sync_file is a good or bad idea. We may end up going back to the non-sync_file based patches if this proves to be a bad idea, so far it doesn't look like one. I also reviewed the patches and noted it shouldn't add the wait/signal interfaces, that it should use the chunks on command submission, so while I was in there I re wrote that as well. Yeah, then I'm ok with this, just our internal team has used this implementation, they find some gaps between yours and previous, they could need to change their's again, they are annoyance for this. This is why you _must_ get anything you're doing discussed in upstream first. Your internal teams simply do not have design authority on stuff like that. And yes it takes forever to get formerly proprietary internal-only teams to understand this, speaking from years of experience implement a proper upstream-design-first approach to feature development here at intel. "internal teams simply do not have design authority on stuff like that" Can I print that on a t-shirt and start to sell it? I guess you cannot dress it to go to office..:) I'd wear it to the office. https://www.customink.com/lab?cid=hkp0-00ay-6vjg I'm only at an AMD office every few years, so that's probably not worth it. Anyway it's really something we should keep in mind if we want to upstream things. Christian. Harry David Zhou Christian. -Daniel ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
Am 15.03.2017 um 10:01 schrieb Daniel Vetter:
On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
From: Dave Airlie
This creates a new interface for amdgpu with ioctls to
create/destroy/import and export shared semaphores using
sem object backed by the sync_file code. The semaphores
are not installed as fd (except for export), but rather
like other driver internal objects in an idr. The idr
holds the initial reference on the sync file.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for semaphore signalling
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
NOTE: this interface addition needs a version bump to expose
it to userspace.
Signed-off-by: Dave Airlie
Another uapi corner case: Since you allow semaphores to be created before
they have a first fence attached, that essentially creates future fences.
I.e. sync_file fd with no fence yet attached. We want that anyway, but
maybe not together with semaphores (since there's some more implications).
I think it'd be good to attach a dummy fence which already starts out as
signalled to sync_file->fence for semaphores. That way userspace can't go
evil, create a semaphore, then pass it to a driver which then promptly
oopses or worse because it assumes then when it has a sync_file, it also
has a fence. And the dummy fence could be globally shared, so not really
overhead.
Sounds fishy to me, what happens in case of a race condition and the
receiver sometimes waits on the dummy and sometimes on the real fence?
I would rather teach the users of sync_file to return a proper error
code when you want to wait on a sync_file which doesn't have a fence yet.
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
include/uapi/drm/amdgpu_drm.h | 28 +
6 files changed, 322 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 2814aad..404bcba 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
- amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
+ amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
# add asic specific block
amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b9135..4ed8811 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -702,6 +702,8 @@ struct amdgpu_fpriv {
struct mutexbo_list_lock;
struct idr bo_list_handles;
struct amdgpu_ctx_mgr ctx_mgr;
+ spinlock_t sem_handles_lock;
+ struct idr sem_handles;
};
/*
@@ -1814,5 +1816,15 @@ amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
uint64_t addr, struct amdgpu_bo **bo);
int amdgpu_cs_sysvm_access_required(struct amdgpu_cs_parser *parser);
+int amdgpu_sem_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
+void amdgpu_sem_destroy(struct amdgpu_fpriv *fpriv, u32 handle);
+int amdgpu_sem_lookup_and_signal(struct amdgpu_fpriv *fpriv,
+uint32_t handle,
+struct dma_fence *fence);
+int amdgpu_sem_lookup_and_sync(struct amdgpu_device *adev,
+ struct amdgpu_fpriv *fpriv,
+ struct amdgpu_sync *sync,
+ uint32_t handle);
#include "amdgpu_object.h"
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4671432..80fc94b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -217,6 +217,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void
*data)
break;
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SEM_WAIT:
+ case AMDGPU_CHUNK_ID_SEM_SIGNAL:
break;
default:
@@ -1009,6 +1011,28 @@ static int amdgpu_process_fence_dep(struct amdgpu_device
*adev,
return 0;
}
+static int amdgpu_process_sem_wait_dep(struct amdgpu_device *adev,
+
Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks
On Wed, Mar 15, 2017 at 06:09:25PM +0900, Inki Dae wrote: > > > 2017년 03월 15일 09:54에 Inki Dae 이(가) 쓴 글: > > > > > > 2017년 03월 14일 22:28에 Daniel Vetter 이(가) 쓴 글: > >> On Mon, Mar 13, 2017 at 03:18:05PM -0400, Sean Paul wrote: > >>> On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote: > Again no apparent explanation for the split except hysterical raisins. > Merging them also makes it a bit more obviuos what's going on wrt the > runtime pm refdancing. > >>> > >>> Commit message copypasta. > >> > >> Hm, yeah. Inki, can you pls adjust that when merging to exynos-next? Just > >> drop the last sentence that talks about pm refdancing. > >> -Daniel > > > > No problem. :) > > Seems you want this patch to be tested enough on each maintainer tree. Picked > it up. Thanks a lot. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
Hi Heiko On 03/15/2017 05:03 PM, Heiko Stübner wrote: Am Mittwoch, 15. März 2017, 16:42:30 CET schrieb Chris Zhong: For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Signed-off-by: Chris Zhong --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t xt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t xt index 188f6f7..7e17a60 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t xt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.t xt @@ -10,7 +10,7 @@ Required properties: - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference clock(ref) and APB clock(pclk). For RK3399, a phy config clock - (phy_cfg) is additional required. As described in [1]. + (phy_cfg) and a grf clock(grf) are additional required. As described in [1]. your "grf" clock is optional, as it is not present on all socs (like the rk3288) so should probably move to a separate section and not be in the required properties For RK3399, the grf clock is required, according to the advice provided by rob[0], put it into "required properties " is better. [0] https://patchwork.kernel.org/patch/9220187/ Heiko -- Chris Zhong ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
On Wed, Mar 15, 2017 at 10:43:01AM +0100, Christian König wrote:
> Am 15.03.2017 um 10:01 schrieb Daniel Vetter:
> > On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > This creates a new interface for amdgpu with ioctls to
> > > create/destroy/import and export shared semaphores using
> > > sem object backed by the sync_file code. The semaphores
> > > are not installed as fd (except for export), but rather
> > > like other driver internal objects in an idr. The idr
> > > holds the initial reference on the sync file.
> > >
> > > The command submission interface is enhanced with two new
> > > chunks, one for semaphore waiting, one for semaphore signalling
> > > and just takes a list of handles for each.
> > >
> > > This is based on work originally done by David Zhou at AMD,
> > > with input from Christian Konig on what things should look like.
> > >
> > > NOTE: this interface addition needs a version bump to expose
> > > it to userspace.
> > >
> > > Signed-off-by: Dave Airlie
> > Another uapi corner case: Since you allow semaphores to be created before
> > they have a first fence attached, that essentially creates future fences.
> > I.e. sync_file fd with no fence yet attached. We want that anyway, but
> > maybe not together with semaphores (since there's some more implications).
> >
> > I think it'd be good to attach a dummy fence which already starts out as
> > signalled to sync_file->fence for semaphores. That way userspace can't go
> > evil, create a semaphore, then pass it to a driver which then promptly
> > oopses or worse because it assumes then when it has a sync_file, it also
> > has a fence. And the dummy fence could be globally shared, so not really
> > overhead.
>
> Sounds fishy to me, what happens in case of a race condition and the
> receiver sometimes waits on the dummy and sometimes on the real fence?
>
> I would rather teach the users of sync_file to return a proper error code
> when you want to wait on a sync_file which doesn't have a fence yet.
Races in userspace are races in userspace :-) And it's only a problem
initially when you use a semaphore for the first time. After that you
still have the same race, but because there's always a fence attached,
your userspace won't ever notice the fail. It will simply complete
immediately (because most likely the old fence has completed already).
And it also doesn't mesh with the rough future fence plan, where the idea
is that sync_file_get_fence blocks until the fence is there, and only
drivers who can handle the risk of a fence loop (through hangcheck and
hang recovery) will use a __get_fence function to peek at the future
fence. I think the assumption that a sync_file always comes with a fence
is a good principle for code robustness in the kernel.
If you really want the userspace debugging, we can make it a module
option, or even better, sprinkle a pile of tracepoints all over fences to
make it easier to watch. But when the tradeoff is between userspace
debugging and kernel robustness, I think we need to go with kernel
robustness, for security reasons and all that.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
> > >
> > > include/uapi/drm/amdgpu_drm.h | 28 +
> > > 6 files changed, 322 insertions(+), 2 deletions(-)
> > > create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > index 2814aad..404bcba 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > @@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> > > atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> > > amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> > > amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> > > - amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> > > + amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
> > > # add asic specific block
> > > amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > index c1b9135..4ed8811 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > @@ -702,6 +702,8 @@ struct amdgpu_fpriv {
> > > struct mutexbo_list_lock;
> > > struct idr bo_list_handles;
> > > struct amdgpu_ctx_mgr ctx_mgr;
> > > + spinlock_t sem_handles_lock;
> > > + struct idr sem_handl
Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module
On Tue, Mar 14, 2017 at 01:30:30PM -0700, Laura Abbott wrote: > On 03/14/2017 01:13 PM, Daniel Vetter wrote: > > On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote: > >> > >> dma-buf is designed to share buffers. Sharing means that there needs to > >> be another subsystem to accept those buffers. Introduce a simple test > >> module to act as a dummy system to accept dma_bufs from elsewhere. The > >> goal is to provide a very simple interface to validate exported buffers > >> do something reasonable. This is based on ion_test.c that existed for > >> the Ion framework. > >> > >> Signed-off-by: Laura Abbott > >> --- > >> This is basically a drop in of what was available as > >> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific > >> parts it might be useful as a more general test module. RFC mostly > >> to see if this is generally useful or not. > > > > We already have a test dma-buf driver, which also handles reservation > > objects and can create fences to provoke signalling races an all kinds of > > other fun. It's drivers/gpu/drm/vgem. > > > > If there's anything missing in there, patches very much welcome. > > -Daniel > > > > Thanks for that pointer. It certainly looks more complete vs. allocating > a platform_device. I'll look and see if there's anything that needs > extension. Plus this means I can probably delete more code from Ion (woo) \o/ for less code! btw for the tests, I think we should really hard to either get them into kselftests or igt. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: add the grf clock for dw-mipi-dsi
Am Mittwoch, 15. März 2017, 17:55:23 CET schrieb Chris Zhong: > Hi Heiko > > On 03/15/2017 05:03 PM, Heiko Stübner wrote: > > Am Mittwoch, 15. März 2017, 16:42:30 CET schrieb Chris Zhong: > >> For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, > >> add the description for this clock. > >> > >> Signed-off-by: Chris Zhong > >> --- > >> > >> .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt > >> | 2 > >> > >> +- 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip > >> .t > >> xt > >> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip > >> .t > >> xt index 188f6f7..7e17a60 100644 > >> --- > >> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip > >> .t > >> xt +++ > >> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip > >> .t > >> > >> xt @@ -10,7 +10,7 @@ Required properties: > >> - interrupts: Represent the controller's interrupt to the CPU(s). > >> - clocks, clock-names: Phandles to the controller's pll reference > >> > >> clock(ref) and APB clock(pclk). For RK3399, a phy config clock > >> > >> - (phy_cfg) is additional required. As described in [1]. > >> + (phy_cfg) and a grf clock(grf) are additional required. As described > >> in > >> [1]. > > > > your "grf" clock is optional, as it is not present on all socs (like the > > rk3288) so should probably move to a separate section and not be in the > > required properties > > For RK3399, the grf clock is required, according to the advice provided > by rob[0], > put it into "required properties " is better. > [0] https://patchwork.kernel.org/patch/9220187/ ok, but it should probably be made clear, that this is rk3399-specific ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/omapdrm: Separate ids for planes and CRTCs in omap_modeset_init()
Hi, On 14/03/17 22:35, Jyri Sarha wrote: > Add separate local id variables for indexing planes and CRTCs in > omap_modeset_init(). This is to make it more explicit what each local > variable is used for. "id" should be used for DRM object ids. I think here plane_id and crtc_id are really idx. And the code still mixes up at least plane index and DSS plane (enum omap_plane from omapdss.h). For crtcs I think we already separate the DRM crtc idx and the DSS "enum omap_channel". But I belive omap_drv.c shouldn't even care about those omap_channels, it should all be in omap_crtc.c. These patches are in the correct direction, but see if you can take it further and get the code to be something like this: For each display, we create a crtc. Each crtc will figure out the omap_channel to use, based on the display (out->dispc_channel), in omap_crtc.c. Each crtc will get a primary plane. omap_plane.c will figure out which "enum omap_plane" to to use for a plane. I think it can be a direct mapping from plane idx to enum omap_plane, but that has to be explicit in the code. Each crtc will also get an encoder and a connector. We can configure an encoder and a connector to be usable only with a single crtc. The rest of the planes will be created as overlay planes. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/omapdrm: Change possible_crtcs to possible_crtcs_for_planes
On 14/03/17 22:35, Jyri Sarha wrote: > Rename possible_crtcs local variable to possible_crtcs_for_planes in > omap_modeset_init() and add a comment about its initialization. This > is to make it more explicit what the variable is used for. > > Signed-off-by: Jyri Sarha > --- > drivers/gpu/drm/omapdrm/omap_drv.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c > b/drivers/gpu/drm/omapdrm/omap_drv.c > index 17c40aa..3d30f29 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > @@ -320,7 +320,7 @@ static int omap_modeset_init(struct drm_device *dev) > int num_crtcs = 0; > int i, id = 0; > int ret; > - u32 possible_crtcs; > + u32 possible_crtcs_for_planes; Maybe "crtc_mask"? Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
Hi Dave,
Barring the other discussions, allow me to put a couple of trivial suggestions:
Please re-wrap the long lines to follow existing code style.
On 14 March 2017 at 00:50, Dave Airlie wrote:
> @@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
> struct amdgpu_cs_request *ibs_request,
> uint32_t number_of_requests);
>
> +int amdgpu_cs_submit_sem(amdgpu_context_handle context,
> +uint64_t flags,
> +struct amdgpu_cs_request *ibs_request,
> +struct amdgpu_cs_request_sem *ibs_sem,
> +uint32_t number_of_requests);
> +
> /**
> * Query status of Command Buffer Submission
> *
> @@ -1255,4 +1273,14 @@ int
> amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle sem);
> */
> const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
>
> +int amdgpu_cs_create_sem(amdgpu_device_handle dev,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_export_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem,
> +int *shared_handle);
> +int amdgpu_cs_import_sem(amdgpu_device_handle dev,
> + int shared_handle,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem);
The new symbols should be added to the amdgpu-symbol-check test.
If in doubt - run `make -C amdgpu check'
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
Please sync this as PATCH 1/2 via "make headers_install" + cp + git
commit -asm "Generated using make headers_install.\nGenerated from
$tree/branch commit $sha."
There's a handful of other changes that are missing/should be merged.
> @@ -50,6 +50,7 @@ extern "C" {
> +struct drm_amdgpu_cs_chunk_sem {
> + uint32_t handle;
> +};
> +
Seems unused in the UAPI header - might what to add a note ?
Also sizeof(struct drm_amdgpu_cs_chunk_sem) is not multiple of 64bit -
worth mentioning that it's safe and/or why ?
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
It also needs any support from VBIOS side ? I mean PCIe large bar support?
Thanks,
Ayyappa.
On Wed, Mar 15, 2017 at 1:07 PM, Christian König
wrote:
> Carizzo is an APU and resizing BARs isn't needed nor supported there. The
> CPU can access the full stolen VRAM directly on that hardware.
>
> As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
> variants.
>
> Christian.
>
>
> Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
>>
>> Is it possible on Carrizo asics? Or only supports on newer asics?
>>
>> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
>> wrote:
>>>
>>> From: Christian König
>>>
>>> Try to resize BAR0 to let CPU access all of VRAM.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>>> +
>>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>>> 4 files changed, 40 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 3b81ded..905ded9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
>>> amdgpu_device *adev, struct ttm_tt *ttm,
>>> struct ttm_mem_reg *mem);
>>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc, u64 base);
>>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc);
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
>>> size);
>>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>>> void amdgpu_ttm_fini(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index 118f4e6..92955fe 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>>> struct amdgpu_mc *mc)
>>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>>> }
>>>
>>> +/**
>>> + * amdgpu_resize_bar0 - try to resize BAR0
>>> + *
>>> + * @adev: amdgpu_device pointer
>>> + *
>>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>>> + */
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
>>> +{
>>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>>> + int r;
>>> +
>>> + r = pci_resize_resource(adev->pdev, 0, size);
>>> +
>>> + if (r == -ENOTSUPP) {
>>> + /* The hardware don't support the extension. */
>>> + return;
>>> +
>>> + } else if (r == -ENOSPC) {
>>> + DRM_INFO("Not enoigh PCI address space for a large
>>> BAR.");
>>> + } else if (r) {
>>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>>> + }
>>> +
>>> + /* Reinit the doorbell mapping, it is most likely moved as well
>>> */
>>> + amdgpu_doorbell_fini(adev);
>>> + BUG_ON(amdgpu_doorbell_init(adev));
>>> +}
>>> +
>>> /*
>>>* GPU helpers function.
>>>*/
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> index dc9b6d6..36a7aa5 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
>>> *adev)
>>> break;
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> - /* Could aper size report 0 ? */
>>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> /* size in MB on si */
>>> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>>> 1024ULL;
>>> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>>> 1024ULL;
>>>
>>> + if (!(adev->flags & AMD_IS_APU))
>>> + amdgpu_resize_bar0(adev);
>>> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> +
>>> #ifdef CONFIG_X86_64
>>> if (adev->flags & AMD_IS_APU) {
>>> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) <<
>>> 22;
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> index c087b00..7761ad3 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device
>>> *adev)
>>> break;
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> - /* Could aper size report 0 ? */
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
No, we resize the BAR on the fly during driver load without help from
the BIOS or VBIOS.
Christian.
Am 15.03.2017 um 11:42 schrieb Ayyappa Ch:
It also needs any support from VBIOS side ? I mean PCIe large bar support?
Thanks,
Ayyappa.
On Wed, Mar 15, 2017 at 1:07 PM, Christian König
wrote:
Carizzo is an APU and resizing BARs isn't needed nor supported there. The
CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
+
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
amdgpu_device *adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc, u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large
BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well
*/
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
*adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) <<
22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device
*adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) *
Re: [PATCH 0/7] omapdrm: Fix GEM objects DMA unmapping
On 10/03/17 11:39, Laurent Pinchart wrote: > Hello, > > Memory leaks have been reported when allocating a cached omap_bo (with > OMAP_BO_CACHED. Investigation showed that this can only come from the DMA > mapping debug layer, as on ARM32 the non-coherent, non-IOMMU DMA mapping code > doesn't allocate memory to map a page (and kmemcheck facility is only > available on x86, so it can't be a source of memory leaks either on ARM). > > The DMA debug layer pre-allocates DMA debugging entries and stores them in a > list. As the omapdrm driver maps cached buffer page by page, the list of 4096 > pre-allocated entries is starved very soon. However, raising the number of DMA > mapping debug entries to 32 * 4096 (through the dma_debug_entries kernel > command line argument) led to more interesting results. > > The number of entries being large enough to handle all the pages mapped by > kmstest, monitoring the DMA mapping statistics through > /sys/kernel/debug/dma-api/ showed that the number of free entries dropped > significantly when kmstest was started and didn't raise when it was stopped. > In particular, running kmstest without flipping resulting in a drop of 1266 > free entries, which corresponds to one 1440x900 framebuffer in XR24. The > proved that the pages backing the framebuffer, while freed when the > framebuffer was destroyed, were not unmapped. > > I've thus started investigating the driver GEM implementation. After a few > confusing moments that resulted in the 1/7 to 6/7 cleanup patches, I wrote > patch 7/7 that should fix the issue. So, possibly this series could be applied with the one issue fixed that I reported, as it looks like a nice cleanup, but I think this is still far from making cached bos usable and I would rather have it all in one series. One issue is that if creating a cached buffer without DMM, omap_gem_mmap_obj() will hit if (WARN_ON(!obj->filp)) and break. The other is that the cached bos are unusably slow. I hope that is because of the constant fault, map, unmap cycle, and can be fixed by keeping the buffer mapped and using explicit sync ioctls. But if the performance issue cannot be solved, then I think we should just drop the cached bo support as it's unusable at the moment. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos/dsi: make te-gpios optional
DSI forwards te-gpios interrupts to display controller, but if display
controller works in HW-TRIGGER mode this interrupt is not necessary.
Making te-gpios property optional allows to avoid generating spare
interrupts.
With this patch we can get rid of 60 interrupt callbacks per second.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 812e2ec..822094d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1348,9 +1348,12 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi)
int te_gpio_irq;
dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
+ if (dsi->te_gpio == -ENOENT)
+ return 0;
+
if (!gpio_is_valid(dsi->te_gpio)) {
- dev_err(dsi->dev, "no te-gpios specified\n");
ret = dsi->te_gpio;
+ dev_err(dsi->dev, "cannot get te-gpios, %d\n", ret);
goto out;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Jean Delvare (jdelv...@suse.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #7 from Jean Delvare (jdelv...@suse.de) ---
Fixed in kernel v4.10.3 by reverting commit 8d9422ef80c ("drm/amdgpu: update
tile table for oland/hainan").
Fixed in kernel v4.11 by the commits mentioned in comment #1.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 Jean Delvare (jdelv...@suse.de) changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100212] Implement vstore_* to make Theano/libgpuarray working
https://bugs.freedesktop.org/show_bug.cgi?id=100212 Bug ID: 100212 Summary: Implement vstore_* to make Theano/libgpuarray working Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: ved...@miletic.net QA Contact: dri-devel@lists.freedesktop.org We miss at least vload_half and vstore_half_rtn. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100212] Implement vstore_* to make Theano/libgpuarray working
https://bugs.freedesktop.org/show_bug.cgi?id=100212 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||100212 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=100212 [Bug 100212] Implement vstore_* to make Theano/libgpuarray working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()
Den 14.03.2017 08.17, skrev Daniel Vetter:
On Mon, Mar 13, 2017 at 01:30:40PM +0100, Noralf Trønnes wrote:
Den 12.03.2017 19.00, skrev Daniel Vetter:
On Sat, Mar 11, 2017 at 10:35:32PM +0100, Noralf Trønnes wrote:
Add tinydrm_rgb565_buf_copy() function that copies buffer rectangle to
destination buffer and also handles XRGB and byte swap conversions.
Useful for displays that only support RGB565 and can do partial updates.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56
+-
include/drm/tinydrm/tinydrm-helpers.h | 2 +
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d4cda33..e639453 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -7,13 +7,15 @@
* (at your option) any later version.
*/
-#include
-#include
#include
+#include
#include
#include
#include
+#include
+#include
+
static unsigned int spi_max;
module_param(spi_max, uint, 0400);
MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
@@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
So I noticed that we already have the xrgb to rgb565 function, so I'm
a bit late on this, but: DRM doesn't do format conversions, with the
single exception that the legacy cursor interface is specced to be
argb.
Imo this should be removed (and preferrably before we ship tinydrm in a
stable kernel). Why did you add it?
I added it from the start because plymouth can only do xrgb and I
thought that this was probably the format that most apps/libs/tools
supported, ensuring that tinydrm would work with everything. But I was
aware that this was the kernel patching up userspace, so I knew that it
might be shot down.
But after your comment, I thought that this was in the clear:
https://lists.freedesktop.org/archives/dri-devel/2017-January/130551.html
+EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
I wonder whether the above would make sense in drm core as some kind of fb
helpers. But we can do that once there's a clear need.
I can make a patch that removes this format conversion.
I have no idea what I thought back then :-) But most likely I slightly
misread it as argb_to_rgb565 (it works the same really) used for
cursor compat, which is ok-ish.
But then I just looked through all drivers, and I found exactly one driver
which doesn't support XRGB, and that was probably an oversight. So
there's some arguments for always supporting that. Otoh if you do buffer
sharing and have a nice hw spi engine, touching a wc buffer with the cpu
is _real_ slow (because of the uncached reads), so we really shouldn't let
userspace stumble over this pitfall by accident. The trouble is that by
exposing both, most userspace will pick XRGB, even when they support
RGB565.
And uncached reads are as a rule of thumb 1000x slower, so you don't need
a big panel to feel the pain.
Given that I think we should remove the fake XRGB support.
The Raspberry Pi, which is by far the largest user of these displays,
has a DMA capable SPI controller that can only do 8-bit words.
Since it is little endian, 16-bit RGB565 has to be byte swapped using
a ordinary kmalloc buffer.
Theoretical maximum at 48MHz is:
1 / (320 * 240 * 16 * (1/4800.0)) = 39.0625Hz
The actual numbers isn't very far off:
$ modetest -M "mi0283qt" -s 25:320x240@RG16 -v
setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27
freq: 39.36Hz
freq: 31.16Hz
freq: 31.21Hz
$ modetest -M "mi0283qt" -s 25:320x240@XR24 -v
setting mode 320x240-0Hz@XR24 on connectors 25, crtc 27
freq: 37.30Hz
freq: 29.76Hz
freq: 29.84Hz
Disabling byte swapping, passing cma_obj->vaddr through to SPI, doesn't
improve the numbers much:
$ modetest -M "mi0283qt" -s 25:320x240@RG16 -v
setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27
freq: 43.90Hz
freq: 33.49Hz
freq: 33.49Hz
The SPI bus is sooo slow that the cpu can jump through all kinds of
hoops without affecting throughput much.
Wrt plymouth, I'm a bit surprised that one falls over: We have a pile of
chips that (in some circumstances) prefer RGB565 (mostly big resolutions
with little vram), that's controlled by the preferred_bpp parameter of
drm_fb_helper_single_fb_probe(). You seem to have wired that up all
correctly, plymouth still fails?
I tried to get plymouth to work on the Raspberry Pi, but gave up.
I couldn't get it to use the display.
But here's an extract from the plymouth code:
create_output_buffer():
if (drmModeAddFB (backend->device_fd, width, height,
24, 32, buffer->row_stride, buffer->handle,
&buffer->id) != 0) {
bpp=32 and depth=24 -> DRM_FORMAT_XRGB
And the has_32bpp_support() function makes it clear that 32bp
Re: [PATCH] drm/exynos: Print kernel pointers in a restricted form
Hello Andrzej, note that i had already pointed Krzysztof to that documentation in my previous mail. - Tobias Andrzej Hajda wrote: > Hi Tobias, > > On 14.03.2017 21:41, Tobias Jakobi wrote: >> Krzysztof Kozlowski wrote: >>> On Tue, Mar 14, 2017 at 08:17:35PM +0100, Tobias Jakobi wrote: Krzysztof Kozlowski wrote: > On Tue, Mar 14, 2017 at 08:01:41PM +0100, Tobias Jakobi wrote: >> Hello Krzysztof, >> >> I was wondering about the benefit of this. From a quick look these are >> all messages that end up in the kernel log / dmesg. >> >> IIRC %pK does nothing there, since dmest_restrict is supposed to be used >> to deny an unpriviliged user the access to the kernel log. >> >> Or am I missing something here? > These are regular printks so depending on kernel options (e.g. dynamic > debug, drm.debug) these might be printed also in the console. Of course > we could argue then if access to one of the consoles is worth > securing. This here suggests otherwise. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt#n388 I have not tested this, but IIRC %pK is not honored by the kernel logging infrastucture. That's why dmesg_restrict is there. Correct me if I'm wrong. >>> The %pK will not help for dmesg or /proc/kmsg but it will help for >>> console (/dev/ttySACN, ttySN etc) because effectively it uses the same >>> vsprintf()/pointer() functions. >> Thanks for the explanation, I didn't know that there was a difference >> there. In that case, looks good to me. >> >> > > Just to clarify %pK: > > Documentation/printk-formats.txt: > %pK 0x01234567 or 0x0123456789abcdef > > For printing kernel pointers which should be hidden from > unprivileged > users. The behaviour of %pK depends on the kptr_restrict sysctl > - see > Documentation/sysctl/kernel.txt for more details. > > Documentation/sysctl/kernel.txt: > > kptr_restrict: > > This toggle indicates whether restrictions are placed on > exposing kernel addresses via /proc and other interfaces. > > When kptr_restrict is set to (0), the default, there are no restrictions. > > When kptr_restrict is set to (1), kernel pointers printed using the %pK > format specifier will be replaced with 0's unless the user has CAP_SYSLOG > and effective user and group ids are equal to the real ids. This is > because %pK checks are done at read() time rather than open() time, so > if permissions are elevated between the open() and the read() (e.g via > a setuid binary) then %pK will not leak kernel pointers to unprivileged > users. Note, this is a temporary solution only. The correct long-term > solution is to do the permission checks at open() time. Consider removing > world read permissions from files that use %pK, and using dmesg_restrict > to protect against uses of %pK in dmesg(8) if leaking kernel pointer > values to unprivileged users is a concern. > > When kptr_restrict is set to (2), kernel pointers printed using > %pK will be replaced with 0's regardless of privileges. > --- > > Regards > Andrzej > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()
On Wed, Mar 15, 2017 at 01:15:37PM +0100, Noralf Trønnes wrote: > > Den 14.03.2017 08.17, skrev Daniel Vetter: > > On Mon, Mar 13, 2017 at 01:30:40PM +0100, Noralf Trønnes wrote: > > > Den 12.03.2017 19.00, skrev Daniel Vetter: > > > > On Sat, Mar 11, 2017 at 10:35:32PM +0100, Noralf Trønnes wrote: > > > > > Add tinydrm_rgb565_buf_copy() function that copies buffer rectangle to > > > > > destination buffer and also handles XRGB and byte swap > > > > > conversions. > > > > > Useful for displays that only support RGB565 and can do partial > > > > > updates. > > > > > > > > > > Signed-off-by: Noralf Trønnes > > > > > --- > > > > >drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 > > > > > +- > > > > >include/drm/tinydrm/tinydrm-helpers.h | 2 + > > > > >2 files changed, 56 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > index d4cda33..e639453 100644 > > > > > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > @@ -7,13 +7,15 @@ > > > > > * (at your option) any later version. > > > > > */ > > > > > -#include > > > > > -#include > > > > >#include > > > > > +#include > > > > >#include > > > > >#include > > > > >#include > > > > > +#include > > > > > +#include > > > > > + > > > > >static unsigned int spi_max; > > > > >module_param(spi_max, uint, 0400); > > > > >MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size"); > > > > > @@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void > > > > > *vaddr, > > > > >EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); > > > > So I noticed that we already have the xrgb to rgb565 function, so > > > > I'm > > > > a bit late on this, but: DRM doesn't do format conversions, with the > > > > single exception that the legacy cursor interface is specced to be > > > > argb. > > > > > > > > Imo this should be removed (and preferrably before we ship tinydrm in a > > > > stable kernel). Why did you add it? > > > I added it from the start because plymouth can only do xrgb and I > > > thought that this was probably the format that most apps/libs/tools > > > supported, ensuring that tinydrm would work with everything. But I was > > > aware that this was the kernel patching up userspace, so I knew that it > > > might be shot down. > > > > > > But after your comment, I thought that this was in the clear: > > > https://lists.freedesktop.org/archives/dri-devel/2017-January/130551.html > > > > > > > > +EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); > > > > I wonder whether the above would make sense in drm core as some kind of > > > > fb > > > > helpers. But we can do that once there's a clear need. > > > I can make a patch that removes this format conversion. > > I have no idea what I thought back then :-) But most likely I slightly > > misread it as argb_to_rgb565 (it works the same really) used for > > cursor compat, which is ok-ish. > > > > But then I just looked through all drivers, and I found exactly one driver > > which doesn't support XRGB, and that was probably an oversight. So > > there's some arguments for always supporting that. Otoh if you do buffer > > sharing and have a nice hw spi engine, touching a wc buffer with the cpu > > is _real_ slow (because of the uncached reads), so we really shouldn't let > > userspace stumble over this pitfall by accident. The trouble is that by > > exposing both, most userspace will pick XRGB, even when they support > > RGB565. > > > > And uncached reads are as a rule of thumb 1000x slower, so you don't need > > a big panel to feel the pain. > > > > Given that I think we should remove the fake XRGB support. > > The Raspberry Pi, which is by far the largest user of these displays, > has a DMA capable SPI controller that can only do 8-bit words. > Since it is little endian, 16-bit RGB565 has to be byte swapped using > a ordinary kmalloc buffer. I always get endianess wrong, but why do we need to swap if the controller shuffles 8bit blocks around? If the panel is big endian, then we just need to use big endian drm_fourcc (they exist). > Theoretical maximum at 48MHz is: > 1 / (320 * 240 * 16 * (1/4800.0)) = 39.0625Hz > > The actual numbers isn't very far off: > > $ modetest -M "mi0283qt" -s 25:320x240@RG16 -v > setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27 > freq: 39.36Hz > freq: 31.16Hz > freq: 31.21Hz > > $ modetest -M "mi0283qt" -s 25:320x240@XR24 -v > setting mode 320x240-0Hz@XR24 on connectors 25, crtc 27 > freq: 37.30Hz > freq: 29.76Hz > freq: 29.84Hz > > > Disabling byte swapping, passing cma_obj->vaddr through to SPI, doesn't > improve the numbers much: > > $ modetest -M "mi0283qt" -s 25:320x240@RG16 -v > setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27 > freq: 4
Re: [PATCH] drm/etnaviv: add etnaviv cooling device
Am Sonntag, den 12.03.2017, 19:00 + schrieb Russell King:
> Each Vivante GPU contains a clock divider which can divide the GPU clock
> by 2^n, which can lower the power dissipation from the GPU. It has been
> suggested that the GC600 on Dove is responsible for 20-30% of the power
> dissipation from the SoC, so lowering the GPU clock rate provides a way
> to throttle the power dissiptation, and reduce the temperature when the
> SoC gets hot.
>
> This patch hooks the Etnaviv driver into the kernel's thermal management
> to allow the GPUs to be throttled when necessary, allowing a reduction in
> GPU clock rate from /1 to /64 in power of 2 steps.
Are those power of 2 steps a hardware limitation, or is it something you
implemented this way to get a smaller number of steps, with a more
meaningful difference in clock speed?
My understanding was that the FSCALE value is just a regular divider
with all steps values in the range of 1-64 being usable.
Regards,
Lucas
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 84
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 2 +
> 2 files changed, 71 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 130d7d517a19..bd95182d0852 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include "etnaviv_cmdbuf.h"
> #include "etnaviv_dump.h"
> @@ -409,6 +410,17 @@ static void etnaviv_gpu_load_clock(struct etnaviv_gpu
> *gpu, u32 clock)
> gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, clock);
> }
>
> +static void etnaviv_gpu_update_clock(struct etnaviv_gpu *gpu)
> +{
> + unsigned int fscale = 1 << (6 - gpu->freq_scale);
> + u32 clock;
> +
> + clock = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
> + VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
> +
> + etnaviv_gpu_load_clock(gpu, clock);
> +}
> +
> static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
> {
> u32 control, idle;
> @@ -426,11 +438,10 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
> timeout = jiffies + msecs_to_jiffies(1000);
>
> while (time_is_after_jiffies(timeout)) {
> - control = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
> - VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(0x40);
> -
> /* enable clock */
> - etnaviv_gpu_load_clock(gpu, control);
> + etnaviv_gpu_update_clock(gpu);
> +
> + control = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
>
> /* Wait for stable clock. Vivante's code waited for 1ms */
> usleep_range(1000, 1);
> @@ -490,11 +501,7 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu)
> }
>
> /* We rely on the GPU running, so program the clock */
> - control = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
> - VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(0x40);
> -
> - /* enable clock */
> - etnaviv_gpu_load_clock(gpu, control);
> + etnaviv_gpu_update_clock(gpu);
>
> return 0;
> }
> @@ -1526,17 +1533,13 @@ static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu
> *gpu)
> #ifdef CONFIG_PM
> static int etnaviv_gpu_hw_resume(struct etnaviv_gpu *gpu)
> {
> - u32 clock;
> int ret;
>
> ret = mutex_lock_killable(&gpu->lock);
> if (ret)
> return ret;
>
> - clock = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
> - VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(0x40);
> -
> - etnaviv_gpu_load_clock(gpu, clock);
> + etnaviv_gpu_update_clock(gpu);
> etnaviv_gpu_hw_init(gpu);
>
> gpu->switch_context = true;
> @@ -1548,6 +1551,47 @@ static int etnaviv_gpu_hw_resume(struct etnaviv_gpu
> *gpu)
> }
> #endif
>
> +static int
> +etnaviv_gpu_cooling_get_max_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + *state = 6;
> +
> + return 0;
> +}
> +
> +static int
> +etnaviv_gpu_cooling_get_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long *state)
> +{
> + struct etnaviv_gpu *gpu = cdev->devdata;
> +
> + *state = gpu->freq_scale;
> +
> + return 0;
> +}
> +
> +static int
> +etnaviv_gpu_cooling_set_cur_state(struct thermal_cooling_device *cdev,
> + unsigned long state)
> +{
> + struct etnaviv_gpu *gpu = cdev->devdata;
> +
> + mutex_lock(&gpu->lock);
> + gpu->freq_scale = state;
> + if (!pm_runtime_suspended(gpu->dev))
> + etnaviv_gpu_update_clock(gpu);
> + mutex_unlock(&gpu->lock);
> +
> + return 0;
> +}
> +
> +static struct thermal_cooling_device_ops cooling_ops = {
> + .get_max_state = etnaviv_gpu_cooling_get_max_state,
> + .get_cur_state = etnaviv_gpu_cooling_get_cur_state,
> +
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 91556, which changed state. Bug 91556 Summary: [Clover / OpenCL] struct and union arguments handled incorrectly, producing CL_INVALID_ARG_SIZE https://bugs.freedesktop.org/show_bug.cgi?id=91556 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly
https://bugs.freedesktop.org/show_bug.cgi?id=99484 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Samuel Pitoiset --- Just pushed a workaround for this issue in Mesa. https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API
https://bugs.freedesktop.org/show_bug.cgi?id=97988 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #30 from Samuel Pitoiset --- Just pushed a workaround for this issue in Mesa. https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=100105 Vedran Miletić changed: What|Removed |Added Depends on||100212 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=100212 [Bug 100212] Implement vload_* and vstore_* to make Theano/libgpuarray working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100212] Implement vload_* and vstore_* to make Theano/libgpuarray working
https://bugs.freedesktop.org/show_bug.cgi?id=100212 Vedran Miletić changed: What|Removed |Added Summary|Implement vstore_* to make |Implement vload_* and |Theano/libgpuarray working |vstore_* to make ||Theano/libgpuarray working Blocks||100105 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=100105 [Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.
https://bugs.freedesktop.org/show_bug.cgi?id=99780 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Samuel Pitoiset --- Just pushed a workaround for this issue in Mesa. https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/rockchip: Refactor the component match logic.
On Wed, Mar 15, 2017 at 06:20:47PM +0800, Jeffy Chen wrote:
> Currently we are adding all components from the dts, if one of their
> drivers been disabled, we would not be able to bring up others.
>
> Refactor component match logic, follow exynos drm.
>
> Signed-off-by: Jeffy Chen
> Reviewed-by: Andrzej Hajda
Still looks good to me. If Mark doesn't object in the next 24 hours, I'll apply.
Sean
>
> ---
>
> Changes in v3:
> Address Andrzej Hajda 's comments.
>
> Changes in v2:
> Address Sean Paul 's comments.
>
> drivers/gpu/drm/rockchip/Kconfig| 10 +-
> drivers/gpu/drm/rockchip/Makefile | 16 +--
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 8 +-
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c| 10 +-
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 154
>
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 6 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 +-
> 10 files changed, 131 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0e4eb84..50c41c0 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -13,7 +13,7 @@ config DRM_ROCKCHIP
> IP found on the SoC.
>
> config ROCKCHIP_ANALOGIX_DP
> - tristate "Rockchip specific extensions for Analogix DP driver"
> + bool "Rockchip specific extensions for Analogix DP driver"
> depends on DRM_ROCKCHIP
> select DRM_ANALOGIX_DP
> help
> @@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
> on RK3288 based SoC, you should selet this option.
>
> config ROCKCHIP_CDN_DP
> -tristate "Rockchip cdn DP"
> +bool "Rockchip cdn DP"
> depends on DRM_ROCKCHIP
> depends on EXTCON
> select SND_SOC_HDMI_CODEC if SND_SOC
> @@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
> option.
>
> config ROCKCHIP_DW_HDMI
> -tristate "Rockchip specific extensions for Synopsys DW HDMI"
> +bool "Rockchip specific extensions for Synopsys DW HDMI"
> depends on DRM_ROCKCHIP
> select DRM_DW_HDMI
> help
> @@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
> option.
>
> config ROCKCHIP_DW_MIPI_DSI
> - tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
> + bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
> depends on DRM_ROCKCHIP
> select DRM_MIPI_DSI
> help
> @@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
>option.
>
> config ROCKCHIP_INNO_HDMI
> - tristate "Rockchip specific extensions for Innosilicon HDMI"
> + bool "Rockchip specific extensions for Innosilicon HDMI"
> depends on DRM_ROCKCHIP
> help
> This selects support for Rockchip SoC specific extensions
> diff --git a/drivers/gpu/drm/rockchip/Makefile
> b/drivers/gpu/drm/rockchip/Makefile
> index c931e2a..fa8dc9d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -3,14 +3,14 @@
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> - rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
> + rockchip_drm_gem.o rockchip_drm_psr.o \
> + rockchip_drm_vop.o rockchip_vop_reg.o
> rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
> -obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
> -cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
> -obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> -obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>
> -obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 8548e82..91ebe5c 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -507,7 +507,7 @@ static const struct of_device_id rockchip_dp_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
>
> -static struct platform_driver rockchip_dp_driver = {
> +struct platform_driver rockchip_dp_driver = {
> .probe = rockchip_dp_probe,
> .remove = rockchip_dp_remove,
> .driver = {
> @@ -5
[Bug 99136] Blood Effects Total War: Warhammer
https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #37 from Samuel Pitoiset --- Not sure but this might help for your issue. https://cgit.freedesktop.org/mesa/mesa/commit/?id=7751ed39e40e08e5aa0633d018c9f25ad17f9bb0 Let me know if you get a chance to try. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194867] DRM BUG while initializing cape verde (2nd card)
https://bugzilla.kernel.org/show_bug.cgi?id=194867 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 255263 --> https://bugzilla.kernel.org/attachment.cgi?id=255263&action=edit patch 1/2 Does this patch set fix the issue? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194867] DRM BUG while initializing cape verde (2nd card)
https://bugzilla.kernel.org/show_bug.cgi?id=194867 --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 255265 --> https://bugzilla.kernel.org/attachment.cgi?id=255265&action=edit patch 2/2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93050] Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR* amdgpu: ring 0 test failed" result in Kernel Panic
https://bugs.freedesktop.org/show_bug.cgi?id=93050 --- Comment #3 from s...@list.ru --- (In reply to Alexander Tsoy from comment #2) > These I/O page faults errors are quite annoying and delay boot for about 5 > seconds. Should I open a separate bug report? IMHO these should be reported. I had such boot-up delays due to iommu page_fault flood on HD 3870 and they are quite annoying. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99392] Ark survival evolved won't start
https://bugs.freedesktop.org/show_bug.cgi?id=99392 --- Comment #5 from Samuel Pitoiset --- Quick update: The issue has been fixed since v255.2. You no longer need any override envvars. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||91315, 91305, 87071 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87071 [Bug 87071] LLVM triggered Diagnostic Handler: unsupported call to function S2KItSaltedSHA1Generator in gpg https://bugs.freedesktop.org/show_bug.cgi?id=91305 [Bug 91305] When running JohnTheRipper OpenCL tests: radeon :01:00.0: ring 0 stalled for more than ...msec https://bugs.freedesktop.org/show_bug.cgi?id=91315 [Bug 91315] When running JohnTheRipper OpenCL tests: The kernel rejected CS, see dmesg for more information. / [mi] EQ overflowing. Additional events will be discarded until existing events are processed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87071] LLVM triggered Diagnostic Handler: unsupported call to function S2KItSaltedSHA1Generator in gpg
https://bugs.freedesktop.org/show_bug.cgi?id=87071 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91315] When running JohnTheRipper OpenCL tests: The kernel rejected CS, see dmesg for more information. / [mi] EQ overflowing. Additional events will be discarded until existing events are proce
https://bugs.freedesktop.org/show_bug.cgi?id=91315 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91305] When running JohnTheRipper OpenCL tests: radeon 0000:01:00.0: ring 0 stalled for more than ...msec
https://bugs.freedesktop.org/show_bug.cgi?id=91305 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm: amd: remove broken include path
On Tue, Mar 14, 2017 at 5:27 PM, Arnd Bergmann wrote: > The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command > line, which makes no sense, since these are evaluated relative to the > build directory. When we build with "make W=1", they instead cause > a warning: > > cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs] > cc1: error: ../acp/include: No such file or directory > [-Werror=missing-include-dirs] > cc1: all warnings being treated as errors > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o' failed > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_device.o' failed > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o' failed > > This removes the subdir-ccflags variable that evidently did not > serve any purpose here. > > Signed-off-by: Arnd Bergmann Applied. thanks! Alex > --- > Originally submitted in June 2016. All other patches for this warning got > merged, once this gets in we can turn on the warning flag for everyone. > --- > drivers/gpu/drm/amd/acp/Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/acp/Makefile > b/drivers/gpu/drm/amd/acp/Makefile > index 8363cb57915b..8a08e81ee90d 100644 > --- a/drivers/gpu/drm/amd/acp/Makefile > +++ b/drivers/gpu/drm/amd/acp/Makefile > @@ -3,6 +3,4 @@ > # of AMDSOC/AMDGPU drm driver. > # It provides the HW control for ACP related functionalities. > > -subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include > - > AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o > -- > 2.9.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/10] drm/exynos: kill mode_set_nofb callback
All Exynos CRTCs are fully configured by .enable callback. The only users
of mode_set_nofb actually did nothing in their callbacks - they immediately
returned because devices were in suspend state - mode_set_nofb is always
called on disabled device.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 --
drivers/gpu/drm/exynos/exynos_drm_drv.h| 2 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 -
4 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 1ffb0b1..3e88269 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -581,7 +581,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
- .commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 2d0aa11..d72777f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -49,15 +49,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
}
}
-static void
-exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
-{
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
- if (exynos_crtc->ops->commit)
- exynos_crtc->ops->commit(exynos_crtc);
-}
-
static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -93,7 +84,6 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.enable = exynos_drm_crtc_enable,
.disable= exynos_drm_crtc_disable,
- .mode_set_nofb = exynos_drm_crtc_mode_set_nofb,
.atomic_check = exynos_crtc_atomic_check,
.atomic_begin = exynos_crtc_atomic_begin,
.atomic_flush = exynos_crtc_atomic_flush,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 7ef2b36..527bf1d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -115,7 +115,6 @@ struct exynos_drm_plane_config {
*
* @enable: enable the device
* @disable: disable the device
- * @commit: set current hw specific display mode to hw.
* @enable_vblank: specific driver callback for enabling vblank interrupt.
* @disable_vblank: specific driver callback for disabling vblank interrupt.
* @atomic_check: validate state
@@ -130,7 +129,6 @@ struct exynos_drm_crtc;
struct exynos_drm_crtc_ops {
void (*enable)(struct exynos_drm_crtc *crtc);
void (*disable)(struct exynos_drm_crtc *crtc);
- void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
u32 (*get_vblank_counter)(struct exynos_drm_crtc *crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0b74e57..bf5135c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -942,7 +942,6 @@ static void fimd_dp_clock_enable(struct exynos_drm_clk
*clk, bool enable)
static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.enable = fimd_enable,
.disable = fimd_disable,
- .commit = fimd_commit,
.enable_vblank = fimd_enable_vblank,
.disable_vblank = fimd_disable_vblank,
.atomic_begin = fimd_atomic_begin,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/10] drm/exynos: kill pipe field from drivers contexts
Since possible_crtcs are set by Exynos core helper pipe fields have no
raison d'etre. The only place it was used, as a hack, is
fimd_clear_channels, to avoid calling drm_crtc_handle_vblank, but DRM core
has already other protection mechanism (vblank->enabled), so it could be
safely removed.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 4 +---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 2 --
5 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5931bea..a91f46b 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -64,7 +64,6 @@ struct decon_context {
void __iomem*addr;
struct regmap *sysreg;
struct clk *clks[ARRAY_SIZE(decon_clks_name)];
- int pipe;
unsigned long flags;
unsigned long out_type;
int first_win;
@@ -592,7 +591,6 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
drm_dev->max_vblank_count = 0x;
for (win = ctx->first_win; win < WINDOWS_NR; win++) {
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4320b3b..1ffb0b1 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -55,7 +55,6 @@ struct decon_context {
unsigned long irq_flags;
booli80_if;
boolsuspended;
- int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -131,7 +130,6 @@ static int decon_ctx_initialize(struct decon_context *ctx,
struct drm_device *drm_dev)
{
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
decon_clear_channels(ctx->crtc);
@@ -605,7 +603,7 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
writel(clear_bit, ctx->regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
goto out;
if (!ctx->i80_if) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index ef27757..0b74e57 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -191,7 +191,6 @@ struct fimd_context {
u32 i80ifcon;
booli80_if;
boolsuspended;
- int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
atomic_twin_updated;
@@ -368,18 +367,13 @@ static void fimd_clear_channels(struct exynos_drm_crtc
*crtc)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- int pipe = ctx->pipe;
-
- /* ensure that vblank interrupt won't be reported to core */
ctx->suspended = false;
- ctx->pipe = -1;
fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);
ctx->suspended = true;
- ctx->pipe = pipe;
}
clk_disable_unprepare(ctx->lcd_clk);
@@ -913,7 +907,7 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
u32 trg_type = ctx->driver_data->trg_type;
/* Checks the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
return;
if (trg_type == I80_HW_TRG)
@@ -971,7 +965,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
writel(clear_bit, ctx->regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
goto out;
if (!ctx->i80_if)
@@ -1001,7 +995,6 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
for (i = 0; i < WINDOWS_NR; i++) {
[PATCH v3 04/10] drm/exynos: kill exynos_drm_private::pipe
The field duplicates drm_dev->mode_config.num_crtc.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 11 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 9 ++---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +---
drivers/gpu/drm/exynos/exynos_mixer.c | 8 ++--
6 files changed, 11 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 421fd94..3a70351f 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -586,14 +586,13 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
{
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
- struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
enum exynos_drm_output_type out_type;
unsigned int win;
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = priv->pipe++;
+ ctx->pipe = drm_dev->mode_config.num_crtc;
drm_dev->max_vblank_count = 0x;
for (win = ctx->first_win; win < WINDOWS_NR; win++) {
@@ -615,21 +614,12 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
: EXYNOS_DISPLAY_TYPE_LCD;
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
out_type, &decon_crtc_ops, ctx);
- if (IS_ERR(ctx->crtc)) {
- ret = PTR_ERR(ctx->crtc);
- goto err;
- }
+ if (IS_ERR(ctx->crtc))
+ return PTR_ERR(ctx->crtc);
decon_clear_channels(ctx->crtc);
- ret = drm_iommu_attach_device(drm_dev, dev);
- if (ret)
- goto err;
-
- return ret;
-err:
- priv->pipe--;
- return ret;
+ return drm_iommu_attach_device(drm_dev, dev);
}
static void decon_unbind(struct device *dev, struct device *master, void *data)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 0ccb334..206e779 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -130,19 +130,12 @@ static void decon_clear_channels(struct exynos_drm_crtc
*crtc)
static int decon_ctx_initialize(struct decon_context *ctx,
struct drm_device *drm_dev)
{
- struct exynos_drm_private *priv = drm_dev->dev_private;
- int ret;
-
ctx->drm_dev = drm_dev;
- ctx->pipe = priv->pipe++;
+ ctx->pipe = drm_dev->mode_config.num_crtc;
decon_clear_channels(ctx->crtc);
- ret = drm_iommu_attach_device(drm_dev, ctx->dev);
- if (ret)
- priv->pipe--;
-
- return ret;
+ return drm_iommu_attach_device(drm_dev, ctx->dev);
}
static void decon_ctx_remove(struct decon_context *ctx)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 7e54be1..7ef2b36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -196,7 +196,6 @@ struct drm_exynos_file_private {
* otherwise default one.
* @da_space_size: size of device address space.
* if 0 then default value is used for it.
- * @pipe: the pipe number for this crtc/manager.
* @pending: the crtcs that have pending updates to finish
* @lock: protect access to @pending
* @wait: wait an atomic commit to finish
@@ -207,8 +206,6 @@ struct exynos_drm_private {
struct device *dma_dev;
void *mapping;
- unsigned int pipe;
-
/* for atomic commit */
u32 pending;
spinlock_t lock;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index caaccd8..588723d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -996,13 +996,12 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
{
struct fimd_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
- struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
unsigned int i;
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = priv->pipe++;
+ ctx->pipe = drm_dev->mode_config.num_crtc;
for (i = 0; i < WINDOWS_NR; i++) {
ctx->configs[i].pixel_formats = fimd_formats;
@@ -1032,11 +1031,7 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
if (is_drm_iommu_supported(drm_dev))
fimd_clear_channels(ctx->crtc);
- re
[PATCH v3 00/10] drm/exynos: rework vblank handling - next
Hi Inki, This is -next part of my patchset 'drm/exynos: rework vblank handling'. With three additional cleanup patches. The patchset contains one improvement and cleanups/reworks: - adds frame counter callback, - removes redundant pipe related fields, - simplifies event handling. I have successfully tested it on TM2 panel, TV and both. Regards Andrzej Andrzej Hajda (10): drm/exynos: simplify completion event handling drm/exynos/decon5433: implement frame counter drm/exynos: kill exynos_drm_crtc::pipe drm/exynos: kill exynos_drm_private::pipe drm/exynos: set plane possible_crtcs in exynos_plane_init drm/exynos: kill pipe field from drivers contexts drm/exynos: kill mode_set_nofb callback drm/exynos/decon5433: kill DECON_UPDATE workaround drm/exynos/decon5433: kill BIT_IRQS_ENABLED drm/exynos/decon5433: simplify shadow protect code drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 85 +++ drivers/gpu/drm/exynos/exynos7_drm_decon.c| 19 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.c | 50 +++- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 14 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.c | 5 +- drivers/gpu/drm/exynos/exynos_drm_plane.h | 1 - drivers/gpu/drm/exynos/exynos_drm_vidi.c | 22 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 13 +--- include/video/exynos5433_decon.h | 1 + 11 files changed, 74 insertions(+), 161 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/10] drm/exynos/decon5433: simplify shadow protect code
There is no point in protecting only particular windows during update.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 +++-
include/video/exynos5433_decon.h | 1 +
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index a68f0cc..03c6a5c 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -313,23 +313,20 @@ static void decon_win_set_pixfmt(struct decon_context
*ctx, unsigned int win,
writel(val, ctx->addr + DECON_WINCONx(win));
}
-static void decon_shadow_protect_win(struct decon_context *ctx, int win,
- bool protect)
+static void decon_shadow_protect(struct decon_context *ctx, bool protect)
{
- decon_set_bits(ctx, DECON_SHADOWCON, SHADOWCON_Wx_PROTECT(win),
+ decon_set_bits(ctx, DECON_SHADOWCON, SHADOWCON_PROTECT_MASK,
protect ? ~0 : 0);
}
static void decon_atomic_begin(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
- int i;
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;
- for (i = ctx->first_win; i < WINDOWS_NR; i++)
- decon_shadow_protect_win(ctx, i, true);
+ decon_shadow_protect(ctx, true);
}
#define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
@@ -412,15 +409,13 @@ static void decon_atomic_flush(struct exynos_drm_crtc
*crtc)
{
struct decon_context *ctx = crtc->ctx;
unsigned long flags;
- int i;
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;
spin_lock_irqsave(&ctx->vblank_lock, flags);
- for (i = ctx->first_win; i < WINDOWS_NR; i++)
- decon_shadow_protect_win(ctx, i, false);
+ decon_shadow_protect(ctx, false);
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
@@ -540,11 +535,10 @@ static void decon_clear_channels(struct exynos_drm_crtc
*crtc)
goto err;
}
- for (win = 0; win < WINDOWS_NR; win++) {
- decon_shadow_protect_win(ctx, win, true);
+ decon_shadow_protect(ctx, true);
+ for (win = 0; win < WINDOWS_NR; win++)
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
- decon_shadow_protect_win(ctx, win, false);
- }
+ decon_shadow_protect(ctx, false);
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index 6b083d3..78957c9 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -118,6 +118,7 @@
#define WINCONx_ENWIN_F(1 << 0)
/* SHADOWCON */
+#define SHADOWCON_PROTECT_MASK GENMASK(14, 10)
#define SHADOWCON_Wx_PROTECT(n)(1 << (10 + (n)))
/* VIDOSDxD */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/10] drm/exynos/decon5433: implement frame counter
DECON in Exynos5433 has frame counter, it can be used to implement
get_vblank_counter callback.
Signed-off-by: Andrzej Hajda
---
v2:
- reuse decon_get_frame_count function already implemented
in previous patch
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index c336a9b2..12f6c27 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -166,6 +166,16 @@ static u32 decon_get_frame_count(struct decon_context
*ctx, bool end)
return frm;
}
+static u32 decon_get_vblank_counter(struct exynos_drm_crtc *crtc)
+{
+ struct decon_context *ctx = crtc->ctx;
+
+ if (test_bit(BIT_SUSPENDED, &ctx->flags))
+ return 0;
+
+ return decon_get_frame_count(ctx, false);
+}
+
static void decon_setup_trigger(struct decon_context *ctx)
{
if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
@@ -564,6 +574,7 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.disable= decon_disable,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
+ .get_vblank_counter = decon_get_vblank_counter,
.atomic_begin = decon_atomic_begin,
.update_plane = decon_update_plane,
.disable_plane = decon_disable_plane,
@@ -583,6 +594,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->drm_dev = drm_dev;
ctx->pipe = priv->pipe++;
+ drm_dev->max_vblank_count = 0x;
for (win = ctx->first_win; win < WINDOWS_NR; win++) {
int tmp = (win == ctx->first_win) ? 0 : win;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9184974..c02378b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -142,6 +142,16 @@ static void exynos_drm_crtc_disable_vblank(struct drm_crtc
*crtc)
exynos_crtc->ops->disable_vblank(exynos_crtc);
}
+static u32 exynos_drm_crtc_get_vblank_counter(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+
+ if (exynos_crtc->ops->get_vblank_counter)
+ return exynos_crtc->ops->get_vblank_counter(exynos_crtc);
+
+ return 0;
+}
+
static const struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -151,6 +161,7 @@ static const struct drm_crtc_funcs exynos_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.enable_vblank = exynos_drm_crtc_enable_vblank,
.disable_vblank = exynos_drm_crtc_disable_vblank,
+ .get_vblank_counter = exynos_drm_crtc_get_vblank_counter,
};
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cb31769..906ab7a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -133,6 +133,7 @@ struct exynos_drm_crtc_ops {
void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
+ u32 (*get_vblank_counter)(struct exynos_drm_crtc *crtc);
int (*atomic_check)(struct exynos_drm_crtc *crtc,
struct drm_crtc_state *state);
void (*atomic_begin)(struct exynos_drm_crtc *crtc);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/10] drm/exynos/decon5433: kill DECON_UPDATE workaround
Since fixing CMU code (drm/exynos/decon5433: fix CMU programming)
DECON started behave predictable and does not need special care
during DECON_UPDATE writes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index a91f46b..8a2cd4f 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -51,8 +51,7 @@ enum decon_flag_bits {
BIT_CLKS_ENABLED,
BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
- BIT_SUSPENDED,
- BIT_REQUEST_UPDATE
+ BIT_SUSPENDED
};
struct decon_context {
@@ -399,7 +398,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
/* window enable */
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
- set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_disable_plane(struct exynos_drm_crtc *crtc,
@@ -412,7 +410,6 @@ static void decon_disable_plane(struct exynos_drm_crtc
*crtc,
return;
decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
- set_bit(BIT_REQUEST_UPDATE, &ctx->flags);
}
static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
@@ -429,8 +426,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);
- if (test_and_clear_bit(BIT_REQUEST_UPDATE, &ctx->flags))
- decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
+ decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
if (ctx->out_type & IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/10] drm/exynos/decon5433: kill BIT_IRQS_ENABLED
BIT_IRQS_ENABLED flag duplicates drm_vblank_crtc::refcount, it could be
safely removed.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 8a2cd4f..a68f0cc 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -49,7 +49,6 @@ static const char * const decon_clks_name[] = {
enum decon_flag_bits {
BIT_CLKS_ENABLED,
- BIT_IRQS_ENABLED,
BIT_WIN_UPDATED,
BIT_SUSPENDED
};
@@ -98,15 +97,13 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return -EPERM;
- if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
- val = VIDINTCON0_INTEN;
- if (ctx->out_type & IFTYPE_I80)
- val |= VIDINTCON0_FRAMEDONE;
- else
- val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
+ val = VIDINTCON0_INTEN;
+ if (ctx->out_type & IFTYPE_I80)
+ val |= VIDINTCON0_FRAMEDONE;
+ else
+ val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
- writel(val, ctx->addr + DECON_VIDINTCON0);
- }
+ writel(val, ctx->addr + DECON_VIDINTCON0);
return 0;
}
@@ -118,8 +115,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;
- if (test_and_clear_bit(BIT_IRQS_ENABLED, &ctx->flags))
- writel(0, ctx->addr + DECON_VIDINTCON0);
+ writel(0, ctx->addr + DECON_VIDINTCON0);
}
/* return number of starts/ends of frame transmissions since reset */
@@ -489,10 +485,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
decon_swreset(ctx);
- /* if vblank was enabled status, enable it again. */
- if (test_and_clear_bit(BIT_IRQS_ENABLED, &ctx->flags))
- decon_enable_vblank(ctx->crtc);
-
decon_commit(ctx->crtc);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/10] drm/exynos: simplify completion event handling
All Exynos CRTC drivers shouldn't fail at referencing vblank events,
alternate path is actually dead code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0620d3c..9184974 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -105,16 +105,15 @@ void exynos_crtc_handle_event(struct exynos_drm_crtc
*exynos_crtc)
struct drm_pending_vblank_event *event = crtc->state->event;
unsigned long flags;
- if (event) {
- crtc->state->event = NULL;
- spin_lock_irqsave(&crtc->dev->event_lock, flags);
- if (drm_crtc_vblank_get(crtc) == 0)
- drm_crtc_arm_vblank_event(crtc, event);
- else
- drm_crtc_send_vblank_event(crtc, event);
- spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
- }
+ if (!event)
+ return;
+ crtc->state->event = NULL;
+
+ WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+ spin_lock_irqsave(&crtc->dev->event_lock, flags);
+ drm_crtc_arm_vblank_event(crtc, event);
+ spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
}
static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/10] drm/exynos: kill exynos_drm_crtc::pipe
Since crtc index is stored in drm_crtc pipe field became redundant.
The patch beside removing the field simplifies also
exynos_drm_crtc_get_pipe_from_type.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +--
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 3 +--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 +++-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 3 +--
8 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 12f6c27..421fd94 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -614,8 +614,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
out_type = (ctx->out_type & IFTYPE_HDMI) ? EXYNOS_DISPLAY_TYPE_HDMI
: EXYNOS_DISPLAY_TYPE_LCD;
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
- ctx->pipe, out_type,
- &decon_crtc_ops, ctx);
+ out_type, &decon_crtc_ops, ctx);
if (IS_ERR(ctx->crtc)) {
ret = PTR_ERR(ctx->crtc);
goto err;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4881180..0ccb334 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -656,8 +656,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
exynos_plane = &ctx->planes[DEFAULT_WIN];
ctx->crtc = exynos_drm_crtc_create(drm_dev, &exynos_plane->base,
- ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
- &decon_crtc_ops, ctx);
+ EXYNOS_DISPLAY_TYPE_LCD, &decon_crtc_ops, ctx);
if (IS_ERR(ctx->crtc)) {
decon_ctx_remove(ctx);
return PTR_ERR(ctx->crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index c02378b..2d0aa11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -166,7 +166,6 @@ static const struct drm_crtc_funcs exynos_crtc_funcs = {
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
- int pipe,
enum exynos_drm_output_type type,
const struct exynos_drm_crtc_ops *ops,
void *ctx)
@@ -179,7 +178,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
if (!exynos_crtc)
return ERR_PTR(-ENOMEM);
- exynos_crtc->pipe = pipe;
exynos_crtc->type = type;
exynos_crtc->ops = ops;
exynos_crtc->ctx = ctx;
@@ -206,13 +204,9 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
{
struct drm_crtc *crtc;
- list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head) {
- struct exynos_drm_crtc *exynos_crtc;
-
- exynos_crtc = to_exynos_crtc(crtc);
- if (exynos_crtc->type == out_type)
- return exynos_crtc->pipe;
- }
+ drm_for_each_crtc(crtc, drm_dev)
+ if (to_exynos_crtc(crtc)->type == out_type)
+ return drm_crtc_index(crtc);
return -EPERM;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 9634fe5..ef58b64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -19,7 +19,6 @@
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
- int pipe,
enum exynos_drm_output_type type,
const struct exynos_drm_crtc_ops *ops,
void *context);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 906ab7a..7e54be1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -154,13 +154,6 @@ struct exynos_drm_clk {
*
* @base: crtc object.
* @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
- * @pipe: a crtc index created at load() with a new crtc object creation
- * and
[PATCH v3 05/10] drm/exynos: set plane possible_crtcs in exynos_plane_init
All Exynos planes are assigned to exactly one CRTC, it allows to simplify
initialization by moving setting of possible_crtcs to exynos_plane_init.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
7 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 3a70351f..5931bea 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -604,7 +604,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[win].type = decon_win_types[tmp];
ret = exynos_plane_init(drm_dev, &ctx->planes[win], win,
- 1 << ctx->pipe, &ctx->configs[win]);
+ &ctx->configs[win]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 206e779..4320b3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -642,7 +642,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[i].type = decon_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &ctx->configs[i]);
+ &ctx->configs[i]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 588723d..ef27757 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1009,7 +1009,7 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &ctx->configs[i]);
+ &ctx->configs[i]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c2f17f3..611b6fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -273,14 +273,13 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
}
int exynos_plane_init(struct drm_device *dev,
- struct exynos_drm_plane *exynos_plane,
- unsigned int index, unsigned long possible_crtcs,
+ struct exynos_drm_plane *exynos_plane, unsigned int index,
const struct exynos_drm_plane_config *config)
{
int err;
err = drm_universal_plane_init(dev, &exynos_plane->base,
- possible_crtcs,
+ 1 << dev->mode_config.num_crtc,
&exynos_plane_funcs,
config->pixel_formats,
config->num_pixel_formats,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index 9aafad1..497047b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -11,5 +11,4 @@
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane, unsigned int index,
- unsigned long possible_crtcs,
const struct exynos_drm_plane_config *config);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index cb5e3c6..8860ff4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -408,7 +408,7 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
plane_config.type = vidi_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &plane_config);
+ &plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 1474982..3722b5f 100644
--- a/drivers/gpu/drm/ex
Re: [PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()
Den 15.03.2017 13.39, skrev Daniel Vetter: On Wed, Mar 15, 2017 at 01:15:37PM +0100, Noralf Trønnes wrote: Den 14.03.2017 08.17, skrev Daniel Vetter: On Mon, Mar 13, 2017 at 01:30:40PM +0100, Noralf Trønnes wrote: Den 12.03.2017 19.00, skrev Daniel Vetter: On Sat, Mar 11, 2017 at 10:35:32PM +0100, Noralf Trønnes wrote: Add tinydrm_rgb565_buf_copy() function that copies buffer rectangle to destination buffer and also handles XRGB and byte swap conversions. Useful for displays that only support RGB565 and can do partial updates. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 +- include/drm/tinydrm/tinydrm-helpers.h | 2 + 2 files changed, 56 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c index d4cda33..e639453 100644 --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c @@ -7,13 +7,15 @@ * (at your option) any later version. */ -#include -#include #include +#include #include #include #include +#include +#include + static unsigned int spi_max; module_param(spi_max, uint, 0400); MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size"); @@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr, EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); So I noticed that we already have the xrgb to rgb565 function, so I'm a bit late on this, but: DRM doesn't do format conversions, with the single exception that the legacy cursor interface is specced to be argb. Imo this should be removed (and preferrably before we ship tinydrm in a stable kernel). Why did you add it? I added it from the start because plymouth can only do xrgb and I thought that this was probably the format that most apps/libs/tools supported, ensuring that tinydrm would work with everything. But I was aware that this was the kernel patching up userspace, so I knew that it might be shot down. But after your comment, I thought that this was in the clear: https://lists.freedesktop.org/archives/dri-devel/2017-January/130551.html +EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); I wonder whether the above would make sense in drm core as some kind of fb helpers. But we can do that once there's a clear need. I can make a patch that removes this format conversion. I have no idea what I thought back then :-) But most likely I slightly misread it as argb_to_rgb565 (it works the same really) used for cursor compat, which is ok-ish. But then I just looked through all drivers, and I found exactly one driver which doesn't support XRGB, and that was probably an oversight. So there's some arguments for always supporting that. Otoh if you do buffer sharing and have a nice hw spi engine, touching a wc buffer with the cpu is _real_ slow (because of the uncached reads), so we really shouldn't let userspace stumble over this pitfall by accident. The trouble is that by exposing both, most userspace will pick XRGB, even when they support RGB565. And uncached reads are as a rule of thumb 1000x slower, so you don't need a big panel to feel the pain. Given that I think we should remove the fake XRGB support. The Raspberry Pi, which is by far the largest user of these displays, has a DMA capable SPI controller that can only do 8-bit words. Since it is little endian, 16-bit RGB565 has to be byte swapped using a ordinary kmalloc buffer. I always get endianess wrong, but why do we need to swap if the controller shuffles 8bit blocks around? If the panel is big endian, then we just need to use big endian drm_fourcc (they exist). But does userspace use it? A quick google search for DRM_FORMAT_BIG_ENDIAN yielded only weston which drops the field when looking at the format in libweston/gl-renderer.c. In fact 3 months ago you said it was broken: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473034.html > Trying to fix up everything is probably going to be lots of work, but > assuming that everything is broken for big endian is probably correct. > -Daniel Theoretical maximum at 48MHz is: 1 / (320 * 240 * 16 * (1/4800.0)) = 39.0625Hz The actual numbers isn't very far off: $ modetest -M "mi0283qt" -s 25:320x240@RG16 -v setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27 freq: 39.36Hz freq: 31.16Hz freq: 31.21Hz $ modetest -M "mi0283qt" -s 25:320x240@XR24 -v setting mode 320x240-0Hz@XR24 on connectors 25, crtc 27 freq: 37.30Hz freq: 29.76Hz freq: 29.84Hz Disabling byte swapping, passing cma_obj->vaddr through to SPI, doesn't improve the numbers much: $ modetest -M "mi0283qt" -s 25:320x240@RG16 -v setting mode 320x240-0Hz@RG16 on connectors 25, crtc 27 freq: 43.90Hz freq: 33.49Hz freq: 33.49Hz The SPI bus is sooo slow that the cpu can jump through all kinds of hoops without affecting throughput much. Hey, 4 m
Re: [PATCH v2] drm/rockchip: Refactor the component match logic.
Hi Andrzej,
On 03/14/2017 08:05 PM, Andrzej Hajda wrote:
Hi Jeffy,
On 14.03.2017 11:45, Jeffy Chen wrote:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic, follow exynos drm.
Signed-off-by: Jeffy Chen
Reviewed-by: Andrzej Hajda
Below few nitpicks.
(...)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index b360e62..b6bccfc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -356,34 +356,52 @@ static const struct dev_pm_ops rockchip_drm_pm_ops = {
rockchip_drm_sys_resume)
};
-static int compare_of(struct device *dev, void *data)
-{
- struct device_node *np = data;
+static struct platform_driver *rockchip_drm_comp_drvs[] = {
+ &vop_platform_driver,
+#ifdef CONFIG_ROCKCHIP_ANALOGIX_DP
+ &rockchip_dp_driver,
+#endif
+#ifdef CONFIG_ROCKCHIP_CDN_DP
+ &cdn_dp_driver,
+#endif
+#ifdef CONFIG_ROCKCHIP_DW_HDMI
+ &dw_hdmi_rockchip_pltfm_driver,
+#endif
+#ifdef CONFIG_ROCKCHIP_DW_MIPI_DSI
+ &dw_mipi_dsi_driver,
+#endif
+#ifdef CONFIG_ROCKCHIP_INNO_HDMI
+ &inno_hdmi_driver,
+#endif
+};
To avoid #ifdefs, you can use DRV_PTR [1], but it depends what do you
hate more? ifdefs or macro magic :)
[1]:
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_drv.c#L472
Done.
- return dev->of_node == np;
+static int compare_dev(struct device *dev, void *data)
+{
+ return dev == (struct device *)data;
}
-static void rockchip_add_endpoints(struct device *dev,
- struct component_match **match,
- struct device_node *port)
+static struct component_match *rockchip_drm_match_add(struct device *dev)
{
- struct device_node *ep, *remote;
+ struct component_match *match = NULL;
+ int i;
- for_each_child_of_node(port, ep) {
- remote = of_graph_get_remote_port_parent(ep);
- if (!remote || !of_device_is_available(remote)) {
- of_node_put(remote);
- continue;
- } else if (!of_device_is_available(remote->parent)) {
- dev_warn(dev, "parent device of %s is not available\n",
-remote->full_name);
- of_node_put(remote);
- continue;
- }
+ for (i = 0; i < ARRAY_SIZE(rockchip_drm_comp_drvs); i++) {
+ struct platform_driver *drv = rockchip_drm_comp_drvs[i];
+ struct device *p = NULL, *d;
- drm_of_component_match_add(dev, match, compare_of, remote);
- of_node_put(remote);
+ do {
+ d = bus_find_device(&platform_bus_type, p, &drv->driver,
+ (void *)platform_bus_type.match);
+ put_device(p);
+ p = d;
+
+ if (!d)
+ break;
+ component_match_add(dev, &match, compare_dev, d);
+ } while (true);
}
+
+ return match ?: ERR_PTR(-ENODEV);
}
static const struct component_master_ops rockchip_drm_ops = {
@@ -391,21 +409,16 @@ static const struct component_master_ops rockchip_drm_ops
= {
.unbind = rockchip_drm_unbind,
};
-static int rockchip_drm_platform_probe(struct platform_device *pdev)
+static int rockchip_drm_platform_of_probe(struct device *dev)
{
- struct device *dev = &pdev->dev;
- struct component_match *match = NULL;
struct device_node *np = dev->of_node;
struct device_node *port;
+ bool found = false;
int i;
if (!np)
return -ENODEV;
- /*
-* Bind the crtc ports first, so that
-* drm_of_find_possible_crtcs called from encoder .bind callbacks
-* works as expected.
-*/
+
for (i = 0;; i++) {
struct device_node *iommu;
@@ -429,9 +442,9 @@ static int rockchip_drm_platform_probe(struct
platform_device *pdev)
is_support_iommu = false;
}
+ found = true;
+
of_node_put(iommu);
- drm_of_component_match_add(dev, &match, compare_of,
- port->parent);
of_node_put(port);
}
@@ -440,27 +453,27 @@ static int rockchip_drm_platform_probe(struct
platform_device *pdev)
return -ENODEV;
}
- if (!match) {
+ if (!found) {
dev_err(dev, "No available vop found for display-subsystem.\n");
return -ENODEV;
}
- /*
-* For each bound crtc, bind the encoders attached to its
-* remote en
[PATCH v3] drm/rockchip: Refactor the component match logic.
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Refactor component match logic, follow exynos drm.
Signed-off-by: Jeffy Chen
Reviewed-by: Andrzej Hajda
---
Changes in v3:
Address Andrzej Hajda 's comments.
Changes in v2:
Address Sean Paul 's comments.
drivers/gpu/drm/rockchip/Kconfig| 10 +-
drivers/gpu/drm/rockchip/Makefile | 16 +--
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 8 +-
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 +-
drivers/gpu/drm/rockchip/inno_hdmi.c| 10 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 154
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 6 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 +-
10 files changed, 131 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0e4eb84..50c41c0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -13,7 +13,7 @@ config DRM_ROCKCHIP
IP found on the SoC.
config ROCKCHIP_ANALOGIX_DP
- tristate "Rockchip specific extensions for Analogix DP driver"
+ bool "Rockchip specific extensions for Analogix DP driver"
depends on DRM_ROCKCHIP
select DRM_ANALOGIX_DP
help
@@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
on RK3288 based SoC, you should selet this option.
config ROCKCHIP_CDN_DP
-tristate "Rockchip cdn DP"
+bool "Rockchip cdn DP"
depends on DRM_ROCKCHIP
depends on EXTCON
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
option.
config ROCKCHIP_DW_HDMI
-tristate "Rockchip specific extensions for Synopsys DW HDMI"
+bool "Rockchip specific extensions for Synopsys DW HDMI"
depends on DRM_ROCKCHIP
select DRM_DW_HDMI
help
@@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
option.
config ROCKCHIP_DW_MIPI_DSI
- tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
+ bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
depends on DRM_ROCKCHIP
select DRM_MIPI_DSI
help
@@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
option.
config ROCKCHIP_INNO_HDMI
- tristate "Rockchip specific extensions for Innosilicon HDMI"
+ bool "Rockchip specific extensions for Innosilicon HDMI"
depends on DRM_ROCKCHIP
help
This selects support for Rockchip SoC specific extensions
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index c931e2a..fa8dc9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,14 +3,14 @@
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
- rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
+ rockchip_drm_gem.o rockchip_drm_psr.o \
+ rockchip_drm_vop.o rockchip_vop_reg.o
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
-obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
-cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
-obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
-obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..91ebe5c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -507,7 +507,7 @@ static const struct of_device_id rockchip_dp_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
-static struct platform_driver rockchip_dp_driver = {
+struct platform_driver rockchip_dp_driver = {
.probe = rockchip_dp_probe,
.remove = rockchip_dp_remove,
.driver = {
@@ -516,10 +516,3 @@ static struct platform_driver rockchip_dp_driver = {
.of_match_table = of_match_ptr(rockchip_dp_dt_ids),
},
};
-
-module_platform_driver(rockchip_dp_driver);
-
-MODULE_AUTHOR("Yakir Yang ");
-MODULE_AUTHOR("Jeff chen ");
-MODULE_DESCRIPTION("Rockchip Specific Analogix-DP Driver Extension");
-MO
Re: [PATCH] drm/etnaviv: add etnaviv cooling device
On Wed, Mar 15, 2017 at 02:03:09PM +0100, Lucas Stach wrote: > Am Sonntag, den 12.03.2017, 19:00 + schrieb Russell King: > > Each Vivante GPU contains a clock divider which can divide the GPU clock > > by 2^n, which can lower the power dissipation from the GPU. It has been > > suggested that the GC600 on Dove is responsible for 20-30% of the power > > dissipation from the SoC, so lowering the GPU clock rate provides a way > > to throttle the power dissiptation, and reduce the temperature when the > > SoC gets hot. > > > > This patch hooks the Etnaviv driver into the kernel's thermal management > > to allow the GPUs to be throttled when necessary, allowing a reduction in > > GPU clock rate from /1 to /64 in power of 2 steps. > > Are those power of 2 steps a hardware limitation, or is it something you > implemented this way to get a smaller number of steps, with a more > meaningful difference in clock speed? > My understanding was that the FSCALE value is just a regular divider > with all steps values in the range of 1-64 being usable. I don't share your understanding. The Vivante GAL kernel driver only ever sets power-of-two values. I have no evidence to support your suggestion. There's evidence that says your understanding is incorrect however. It isn't a divider. A value of 0x40 gives the fastest clock rate, a value of 0x01 gives the slowest. If it were a binary divider, a value of 0x7f would give the slowest rate - so why doesn't Vivante use that in galcore when putting the GPU into idle/lower power - why do they just 0x01. This all leads me to believe that it's not a binary divider, but a set of bits that select the clock from a set of divide-by-two stages, and having more than one bit set is invalid. However, without definitive information from Vivante, we'll never really know. We're unlikely to get that. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()
On Wed, Mar 15, 2017 at 04:14:49PM +0100, Noralf Trønnes wrote: > > Den 15.03.2017 13.39, skrev Daniel Vetter: > > On Wed, Mar 15, 2017 at 01:15:37PM +0100, Noralf Trønnes wrote: > > > Den 14.03.2017 08.17, skrev Daniel Vetter: > > > > On Mon, Mar 13, 2017 at 01:30:40PM +0100, Noralf Trønnes wrote: > > > > > Den 12.03.2017 19.00, skrev Daniel Vetter: > > > > > > On Sat, Mar 11, 2017 at 10:35:32PM +0100, Noralf Trønnes wrote: > > > > > > > Add tinydrm_rgb565_buf_copy() function that copies buffer > > > > > > > rectangle to > > > > > > > destination buffer and also handles XRGB and byte swap > > > > > > > conversions. > > > > > > > Useful for displays that only support RGB565 and can do partial > > > > > > > updates. > > > > > > > > > > > > > > Signed-off-by: Noralf Trønnes > > > > > > > --- > > > > > > > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 > > > > > > > +- > > > > > > > include/drm/tinydrm/tinydrm-helpers.h | 2 + > > > > > > > 2 files changed, 56 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > > > b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > > > index d4cda33..e639453 100644 > > > > > > > --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > > > +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c > > > > > > > @@ -7,13 +7,15 @@ > > > > > > > * (at your option) any later version. > > > > > > > */ > > > > > > > -#include > > > > > > > -#include > > > > > > > #include > > > > > > > +#include > > > > > > > #include > > > > > > > #include > > > > > > > #include > > > > > > > +#include > > > > > > > +#include > > > > > > > + > > > > > > > static unsigned int spi_max; > > > > > > > module_param(spi_max, uint, 0400); > > > > > > > MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer > > > > > > > size"); > > > > > > > @@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, > > > > > > > void *vaddr, > > > > > > > EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); > > > > > > So I noticed that we already have the xrgb to rgb565 function, > > > > > > so I'm > > > > > > a bit late on this, but: DRM doesn't do format conversions, with the > > > > > > single exception that the legacy cursor interface is specced to be > > > > > > argb. > > > > > > > > > > > > Imo this should be removed (and preferrably before we ship tinydrm > > > > > > in a > > > > > > stable kernel). Why did you add it? > > > > > I added it from the start because plymouth can only do xrgb and I > > > > > thought that this was probably the format that most apps/libs/tools > > > > > supported, ensuring that tinydrm would work with everything. But I was > > > > > aware that this was the kernel patching up userspace, so I knew that > > > > > it > > > > > might be shot down. > > > > > > > > > > But after your comment, I thought that this was in the clear: > > > > > https://lists.freedesktop.org/archives/dri-devel/2017-January/130551.html > > > > > > > > > > > > +EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565); > > > > > > I wonder whether the above would make sense in drm core as some > > > > > > kind of fb > > > > > > helpers. But we can do that once there's a clear need. > > > > > I can make a patch that removes this format conversion. > > > > I have no idea what I thought back then :-) But most likely I slightly > > > > misread it as argb_to_rgb565 (it works the same really) used for > > > > cursor compat, which is ok-ish. > > > > > > > > But then I just looked through all drivers, and I found exactly one > > > > driver > > > > which doesn't support XRGB, and that was probably an oversight. So > > > > there's some arguments for always supporting that. Otoh if you do buffer > > > > sharing and have a nice hw spi engine, touching a wc buffer with the cpu > > > > is _real_ slow (because of the uncached reads), so we really shouldn't > > > > let > > > > userspace stumble over this pitfall by accident. The trouble is that by > > > > exposing both, most userspace will pick XRGB, even when they support > > > > RGB565. > > > > > > > > And uncached reads are as a rule of thumb 1000x slower, so you don't > > > > need > > > > a big panel to feel the pain. > > > > > > > > Given that I think we should remove the fake XRGB support. > > > The Raspberry Pi, which is by far the largest user of these displays, > > > has a DMA capable SPI controller that can only do 8-bit words. > > > Since it is little endian, 16-bit RGB565 has to be byte swapped using > > > a ordinary kmalloc buffer. > > I always get endianess wrong, but why do we need to swap if the controller > > shuffles 8bit blocks around? If the panel is big endian, then we just need > > to use big endian drm_fourcc (they exist). > > But does userspace use it? > A quick google search for DRM_FORMAT_BIG_ENDIAN yielded only weston > which drops the fiel
Re: [PATCH 2/3] drm/rockchip/dsi: enable the grf clk before writing grf registers
On Wed, 15 Mar 2017 09:47:29 -0700, Brian Norris wrote:
> On Wed, Mar 15, 2017 at 04:42:31PM +0800, Chris Zhong wrote:
> > For RK3399, the grf clk should be enabled before writing grf registers,
> > otherwise the register value can not be changed.
> >
> > Signed-off-by: Chris Zhong
> > ---
> >
> > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index f84f9ae..d8f24f2 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -291,6 +291,7 @@ struct dw_mipi_dsi {
> > struct regmap *grf_regmap;
> > void __iomem *base;
> >
> > + struct clk *grf_clk;
> > struct clk *pllref_clk;
> > struct clk *pclk;
> > struct clk *phy_cfg_clk;
> > @@ -979,6 +980,16 @@ static void dw_mipi_dsi_encoder_enable(struct
> > drm_encoder *encoder)
> > dw_mipi_dsi_dphy_interface_config(dsi);
> > dw_mipi_dsi_clear_err(dsi);
> >
> > + /*
> > +* For the RK3399, the clk of grf must be enabled before writing grf
> > +* register.
> > +*/
> > + ret = clk_prepare_enable(dsi->grf_clk);
> > + if (ret) {
> > + dev_err(dsi->dev, "Failed to enable grf_clk\n");
> > + return;
> > + }
> > +
> > if (pdata->grf_dsi0_mode_reg)
> > regmap_write(dsi->grf_regmap, pdata->grf_dsi0_mode_reg,
> > pdata->grf_dsi0_mode);
> > @@ -1003,6 +1014,8 @@ static void dw_mipi_dsi_encoder_enable(struct
> > drm_encoder *encoder)
> > regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
> > dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
> > dsi->dpms_mode = DRM_MODE_DPMS_ON;
> > +
> > + clk_disable_unprepare(dsi->grf_clk);
> > }
> >
> > static int
> > @@ -1238,6 +1251,17 @@ static int dw_mipi_dsi_bind(struct device *dev,
> > struct device *master,
> > dev_dbg(dev, "have not phy_cfg_clk\n");
> > }
> >
> > + dsi->grf_clk = devm_clk_get(dev, "grf");
> > + if (IS_ERR(dsi->grf_clk)) {
> > + ret = PTR_ERR(dsi->grf_clk);
> > + if (ret != -ENOENT) {
> > + dev_err(dev, "Unable to get grf_clk: %d\n", ret);
>
> If you're going to print an error, you should probably check for
> -EPROBE_DEFER. This driver isn't quite consistent about this.
>
> > + return ret;
> > + }
> > + dsi->grf_clk = NULL;
> > + dev_dbg(dev, "have not grf_clk\n");
>
> The wording is a little awkward; maybe "no grf_clk provided\n"?
>
> Also, to be clear, this clock is required for RK3399, but not for others
> (e.g., RK3288) right? I guess this makes sense then, to just treat it as
> optional for all cases, even if you document it as "required" for
> RK3399.
If RK3399 is broken without grf_clk, I wonder if there should be a flag
in dw_mipi_dsi_plat_data so that the driver can enforce "required for
RK3399".
John
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/rockchip: Refactor the component match logic.
Am Mittwoch, 15. März 2017, 18:20:47 CET schrieb Jeffy Chen: > Currently we are adding all components from the dts, if one of their > drivers been disabled, we would not be able to bring up others. > > Refactor component match logic, follow exynos drm. > > Signed-off-by: Jeffy Chen > Reviewed-by: Andrzej Hajda This reliably produces null pointer dereference errors in __platform_driver_register called from rockchip_drm_init on at least rk3036 and rk3288 (probably more) when applied on top of Linus' tree from today. Log attached and Rockchip drm compiled as module. I'm currently dug into other areas, so hadn't have time to investigate further yet. Heiko^C U-Boot SPL 2016.11-01442-g5699f71-dirty (Nov 29 2016 - 23:23:39) U-Boot 2016.11-01442-g5699f71-dirty (Nov 29 2016 - 23:23:39 +0100) Model: Firefly-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c: 0, dwmmc@ff0f: 1 Card did not respond to voltage select! *** Warning - MMC init failed, using default environment In:serial Out: serial Err: serial Net: Warning: ethernet@ff29 (eth0) using random MAC address - ca:ff:bf:e6:3b:7d eth0: ethernet@ff29 Hit any key to stop autoboot: 2 1 0 ethernet@ff29 Waiting for PHY auto negotiation to complete. done Speed: 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.140.51 (15 ms) Using ethernet@ff29 device TFTP from server 192.168.140.1; our IP address is 192.168.140.51 Filename 'hstuebner/firefly.vmlinuz'. Load address: 0x400 Loading: *# # # # # # # ## 2.6 MiB/s done Bytes transferred = 7350967 (702ab7 hex) ## Loading kernel from FIT Image at 0400 ... Using 'conf@1' configuration Trying 'kernel@1' kernel subimage Description: Mainline kernel Type: Kernel Image Compression: uncompressed Data Start: 0x04e4 Data Size:7311440 Bytes = 7 MiB Architecture: ARM OS: Linux Load Address: 0x0028 Entry Point: 0x0028 Verifying Hash Integrity ... OK ## Loading fdt from FIT Image at 0400 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: RK3288-Firefly Type: Flat Device Tree Compression: uncompressed Data Start: 0x046f91d8 Data Size:37834 Bytes = 36.9 KiB Architecture: ARM Verifying Hash Integrity ... OK Booting using the fdt blob at 0x46f91d8 Loading Kernel Image ... OK Loading Device Tree to 0fff3000, end 03c9 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x500 [0.00] Linux version 4.11.0-rc2-01650-gaa6c2d83ac0f-dirty (hstuebner@phil) (gcc version 6.2.1 20161124 (Debian 6.2.1-5) ) #234 SMP Wed Mar 15 17:42:52 CET 2017 [0.00] CPU: ARMv7 Processor [410fc0d1] revision 1 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Firefly-RK3288 [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] cma: Reserved 64 MiB at 0x7c00 [0.00] Memory policy: Data cache writealloc [0.00] percpu: Embedded 16 pages/cpu @eef98000 s34380 r8192 d22964 u65536 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522752 [0.00] Kernel command line: earlyprintk console=ttyS2,115200n8 init=/sbin/init ip=dhcp nfsroot=192.168.140.1:/home/devel/nfs/rootfs-firefly root=/dev/nfs rw noinitrd [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1994840K/2097152K available (10240K kernel code, 1192K rwdata, 4012K rodata, 2048K init, 535K bss, 36776K reserved, 65536K cma-reserved, 1245184K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0208000 - 0xc0d0 (11232 kB) [0.00
Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties
On Mon, Mar 06, 2017 at 05:25:56PM +0100, Geert Uytterhoeven wrote: > Document the optional properties for describing module resets, to > support resetting display channels and LVDS encoders on R-Car Gen2 and > Gen3. > > Signed-off-by: Geert Uytterhoeven > --- > See "[v2,1/4] dt-bindings: clock: renesas: cpg-mssr: Document reset control > support" (https://patchwork.kernel.org/patch/9536627/) for the format of > a reset specifier in the Renesas CPG/MSSR case. > > E.g. "resets = <&cpg 310>;" > > v2: > - s/phandles/phandle/. > --- > Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt > b/Documentation/devicetree/bindings/display/renesas,du.txt > index 1a02f099a0ff0a3a..3db418c827193e82 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -36,6 +36,16 @@ Required Properties: >When supplied they must be named "dclkin.x" with "x" being the input >clock numerical index. > > +Optional properties: > + - resets: A list of phandle + reset-specifier pairs, one for each entry in > +the reset-names property. > + - reset-names: Names of the resets. This property is model-dependent. > +- R8A779[0123456] use one reset for a group of one or more successive > + channels, and one reset per LVDS encoder (if available). The resets > + must be named "du.x" with "x" being the numerical index of the lowest > + channel in the group. The LVDS resets must be named "lvds.x" with "x" > + being the LVDS encoder numerical index. LVDS is not a separate block? > + > Required nodes: > > The connections to the DU output video ports are modeled using the OF graph > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/8] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
Signed-off-by: Yannick Fertre
---
.../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
new file mode 100644
index 000..e70111f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
@@ -0,0 +1,26 @@
+Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "ampire,am-480272h3tmqw-t01h"
+
+Optional properties:
+- power-supply: regulator to provide the supply voltage
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for RGB input.
+
+Example:
+ panel_rgb: panel-rgb {
+ compatible = "ampire,am-480272h3tmqw-t01h";
+ enable-gpios = <&gpioa 8 1>;
+ port {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <&controler_out_rgb>;
+ };
+ };
+ };
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/8] ARM: dts: stm32: Add ltdc support on stm32f429 MCU
Add LTDC (Lcd-tft Display Controller) support.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32f429.dtsi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 7c7dfbd..531e632 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,6 +48,8 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include
+#include
+#include
/ {
clocks {
@@ -212,7 +214,7 @@
reg = <0x40007000 0x400>;
};
- pin-controller {
+ pinctrl: pin-controller {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
@@ -432,6 +434,21 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+ ltdc: display-controller@40016800 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x40016800 0x200>;
+ interrupts = <88>, <89>;
+ resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
+ clocks = <&rcc 1 CLK_LCD>;
+ clock-names = "lcd";
+ status = "disabled";
+
+ port {
+ ltdc_out_rgb: endpoint {
+ };
+ };
+ };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 8/8] ARM: configs: Add STM32 panel simple support in STM32 defconfig
Signed-off-by: Yannick Fertre --- arch/arm/configs/stm32_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index 9c6ba54e..f7ddf29b 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -50,6 +50,8 @@ CONFIG_SERIAL_STM32_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set CONFIG_DRM=y +CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_MFD_SYSCON=y # CONFIG_USB_SUPPORT is not set CONFIG_NEW_LEDS=y -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/8] ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board
Enable ltdc & enable am-480272h3tmqw-t01h panel.
Signed-off-by: Yannick Fertre
---
arch/arm/boot/dts/stm32429i-eval.dts | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 601a22a..5a5f941 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -110,6 +110,52 @@
clocks = <&rcc 0 30>;
clock-names = "main_clk";
};
+
+ panel_rgb: panel-rgb {
+ compatible = "ampire,am-480272h3tmqw-t01h";
+ status = "okay";
+ port {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ pinctrl_ltdc: ltdc@0 {
+ pins {
+ pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ slew-rate = <2>;
+ };
+ };
};
&clk_hse {
@@ -146,3 +192,16 @@
pinctrl-names = "default";
status = "okay";
};
+
+;
+ pinctrl-names = "default";
+ dma-ranges;
+
+ port {
+ ltdc_out_rgb: endpoint {
+ remote-endpoint = <&panel_in_rgb>;
+ };
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/8] STM32 LCD-TFT display controller
Version 4: - Update "ampire,am-480272h3tmqw-t01h.txt" binding with more details on gpios. - Update ltdc.c. Remove regmap, solve some typo & warnings. Version 3: - Update "st,stm32-ltdc.txt" binding. - Add a commit to "ARM: configs: stm32: ADD LDTC support" patch. Version 2: - Rename driver directory from st to stm. - Rename compatiblity from st,ltdc to st,stm32-ltdc. - Remove compatibility st,display-subsystem. - Rename driver from st-drm to stm-drm. - Rework probe sequence & remove display-subsystem part. - I keep clock name which is necessary for devm_regmap_init_mmio_clk call. Version 1: - Initial commit The purpose of this set of patches is to add a new driver for stm32f429. This driver was developed and tested on evaluation board stm32429i. Stm32f4 is a MCU platform which don't have MMU so the last patches developed by Benjamin Gaignard regarding "DRM: allow to use mmuless devices" are necessary. The board stm429i embeds a Ampire AM-480272H3TMQW-T01H screen. A new simple panel am-480272h3tmqw-t01h have been added to support it. Yannick Fertre (8): dt-bindings: display: add STM32 LTDC driver drm/stm: Add STM32 LTDC driver dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H ARM: dts: stm32: Add ltdc support on stm32f429 MCU ARM: dts: stm32: Enable ltdc & simple panel on stm32f429-Eval board ARM: configs: Add STM32 LTDC support in STM32 defconfig ARM: configs: Add STM32 panel simple support in STM32 defconfig .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26 + .../devicetree/bindings/display/st,stm32-ltdc.txt | 36 + arch/arm/boot/dts/stm32429i-eval.dts | 59 + arch/arm/boot/dts/stm32f429.dtsi | 19 +- arch/arm/configs/stm32_defconfig |3 + drivers/gpu/drm/Kconfig|3 +- drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/panel/panel-simple.c | 29 + drivers/gpu/drm/stm/Kconfig| 16 + drivers/gpu/drm/stm/Makefile |7 + drivers/gpu/drm/stm/drv.c | 232 drivers/gpu/drm/stm/drv.h | 22 + drivers/gpu/drm/stm/ltdc.c | 1422 drivers/gpu/drm/stm/ltdc.h | 22 + 14 files changed, 1895 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt create mode 100644 drivers/gpu/drm/stm/Kconfig create mode 100644 drivers/gpu/drm/stm/Makefile create mode 100644 drivers/gpu/drm/stm/drv.c create mode 100644 drivers/gpu/drm/stm/drv.h create mode 100644 drivers/gpu/drm/stm/ltdc.c create mode 100644 drivers/gpu/drm/stm/ltdc.h -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/8] ARM: configs: Add STM32 LTDC support in STM32 defconfig
Signed-off-by: Yannick Fertre --- arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig index 436240d..9c6ba54e 100644 --- a/arch/arm/configs/stm32_defconfig +++ b/arch/arm/configs/stm32_defconfig @@ -49,6 +49,7 @@ CONFIG_SERIAL_STM32=y CONFIG_SERIAL_STM32_CONSOLE=y # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set +CONFIG_DRM=y CONFIG_MFD_SYSCON=y # CONFIG_USB_SUPPORT is not set CONFIG_NEW_LEDS=y -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/8] dt-bindings: display: add STM32 LTDC driver
Acked-by: Rob Herring
Signed-off-by: Yannick Fertre
---
.../devicetree/bindings/display/st,stm32-ltdc.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
new file mode 100644
index 000..e8d39c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -0,0 +1,36 @@
+* STMicroelectronics STM32 lcd-tft display controller
+
+- ltdc: lcd-tft display controller host
+ must be a sub-node of st-display-subsystem
+ Required properties:
+ - compatible: "st,stm32-ltdc"
+ - reg: Physical base address of the IP registers and length of memory mapped
region.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For ltdc it should contain:
+ - "clk-lcd" for the clock feeding the output pixel clock & IP clock.
+ - resets: reset to be used by the device (defined by use of RCC macro).
+ Required nodes:
+- Video port for RGB output.
+
+Example:
+
+/ {
+ ...
+ soc {
+ ...
+ ltdc: display-controller@40016800 {
+ compatible = "st,stm32-ltdc";
+ reg = <0x40016800 0x200>;
+ interrupts = <88>, <89>;
+ resets = <&rcc STM32F4_APB2_RESET(LTDC)>;
+ clocks = <&rcc 1 CLK_LCD>;
+ clock-names = "lcd";
+
+ port {
+ ltdc_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/8] drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H
Add simple-panel support for the Ampire AM-480272H3TMQW-T01H,
which is a 4.3" WQVGA panel.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-simple.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 89eb042..7818755 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -386,6 +386,32 @@ static void panel_simple_shutdown(struct device *dev)
panel_simple_disable(&panel->base);
}
+static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 2,
+ .hsync_end = 480 + 2 + 41,
+ .htotal = 480 + 2 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 10,
+ .vtotal = 272 + 2 + 10 + 2,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc ampire_am_480272h3tmqw_t01h = {
+ .modes = &ire_am_480272h3tmqw_t01h_mode,
+ .num_modes = 1,
+ .bpc = 8,
+
+ .size = {
+ .width = 105,
+ .height = 67,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 3,
.hdisplay = 800,
@@ -1808,6 +1834,9 @@ static void panel_simple_shutdown(struct device *dev)
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "ampire,am-480272h3tmqw-t01h",
+ .data = &ire_am_480272h3tmqw_t01h,
+ }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
}, {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/8] drm/stm: Add STM32 LTDC driver
This controller provides output signals to interface directly a variety
of LCD and TFT panels. These output signals are: RGB signals
(up to 24bpp), vertical & horizontal synchronisations, data enable and
the pixel clock.
Change-Id: Ic1d6ade06ab7115c62e98dd21dc3981fb5948d1c
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/Kconfig |3 +-
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/stm/Kconfig | 16 +
drivers/gpu/drm/stm/Makefile |7 +
drivers/gpu/drm/stm/drv.c| 232 +++
drivers/gpu/drm/stm/drv.h| 22 +
drivers/gpu/drm/stm/ltdc.c | 1422 ++
drivers/gpu/drm/stm/ltdc.h | 22 +
8 files changed, 1724 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/stm/Kconfig
create mode 100644 drivers/gpu/drm/stm/Makefile
create mode 100644 drivers/gpu/drm/stm/drv.c
create mode 100644 drivers/gpu/drm/stm/drv.h
create mode 100644 drivers/gpu/drm/stm/ltdc.c
create mode 100644 drivers/gpu/drm/stm/ltdc.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0..dd5762a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -203,7 +203,6 @@ config DRM_VGEM
as used by Mesa's software renderer for enhanced performance.
If M is selected the module will be called vgem.
-
source "drivers/gpu/drm/exynos/Kconfig"
source "drivers/gpu/drm/rockchip/Kconfig"
@@ -246,6 +245,8 @@ source "drivers/gpu/drm/fsl-dcu/Kconfig"
source "drivers/gpu/drm/tegra/Kconfig"
+source "drivers/gpu/drm/stm/Kconfig"
+
source "drivers/gpu/drm/panel/Kconfig"
source "drivers/gpu/drm/bridge/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59aae43..320fd86 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_DRM_BOCHS) += bochs/
obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
obj-$(CONFIG_DRM_MSM) += msm/
obj-$(CONFIG_DRM_TEGRA) += tegra/
+obj-$(CONFIG_DRM_STM) += stm/
obj-$(CONFIG_DRM_STI) += sti/
obj-$(CONFIG_DRM_IMX) += imx/
obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
new file mode 100644
index 000..8ef8a09
--- /dev/null
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -0,0 +1,16 @@
+config DRM_STM
+ tristate "DRM Support for STMicroelectronics SoC Series"
+ depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM)
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_PANEL
+ select VIDEOMODE_HELPERS
+ select FB_PROVIDE_GET_FB_UNMAPPED_AREA
+ default y
+
+ help
+ Enable support for the on-chip display controller on
+ STMicroelectronics STM32 MCUs.
+ To compile this driver as a module, choose M here: the module
+ will be called stm-drm.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
new file mode 100644
index 000..e114d45
--- /dev/null
+++ b/drivers/gpu/drm/stm/Makefile
@@ -0,0 +1,7 @@
+ccflags-y := -Iinclude/drm
+
+stm-drm-y := \
+ drv.o \
+ ltdc.o
+
+obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
new file mode 100644
index 000..d5c46c5
--- /dev/null
+++ b/drivers/gpu/drm/stm/drv.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2017
+ *
+ * Authors: Philippe Cornu
+ * Yannick Fertre
+ * Fabien Dessenne
+ * Mickael Reulier
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "drv.h"
+#include "ltdc.h"
+
+#define DRIVER_NAME"stm"
+#define DRIVER_DESC"STMicroelectronics SoC DRM"
+#define DRIVER_DATE"20170209"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCH_LEVEL 0
+
+#define STM_MAX_FB_WIDTH 2048
+#define STM_MAX_FB_HEIGHT 2048 /* same as width to handle orientation */
+
+static void drv_output_poll_changed(struct drm_device *ddev)
+{
+ struct stm_private *priv = ddev->dev_private;
+
+ drm_fbdev_cma_hotplug_event(priv->fbdev);
+}
+
+static const struct drm_mode_config_funcs drv_mode_config_funcs = {
+ .fb_create = drm_fb_cma_create,
+ .output_poll_changed = drv_output_poll_changed,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static const struct file_operations drv_driver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .unlocked_ioctl = drm_ioctl,
+ .compat_ioctl = drm_compat_ioctl,
+ .poll = drm_poll,
+ .read = drm_read,
+ .mmap = drm_gem_cma_mmap,
+ .get_unmapped_area = drm_gem_cma_get_unmapped_area,
+};
+
+static void drv_lastclose(struct drm_device *ddev)
+{
+ struct stm_private *priv = ddev->dev_pri
Re: [PATCH v3] drm/rockchip: Refactor the component match logic.
Am Mittwoch, 15. März 2017, 18:00:04 CET schrieb Heiko Stuebner:
> Am Mittwoch, 15. März 2017, 18:20:47 CET schrieb Jeffy Chen:
> > Currently we are adding all components from the dts, if one of their
> > drivers been disabled, we would not be able to bring up others.
> >
> > Refactor component match logic, follow exynos drm.
> >
> > Signed-off-by: Jeffy Chen
> > Reviewed-by: Andrzej Hajda
>
> This reliably produces null pointer dereference errors in
> __platform_driver_register called from rockchip_drm_init
> on at least rk3036 and rk3288 (probably more) when applied on top of
> Linus' tree from today. Log attached and Rockchip drm compiled as module.
>
> I'm currently dug into other areas, so hadn't have time to investigate
> further yet.
> +#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? &drv : NULL)
> +
> +static struct platform_driver *rockchip_drm_comp_drvs[] = {
> + &vop_platform_driver,
> + DRV_PTR(rockchip_dp_driver, CONFIG_ROCKCHIP_ANALOGIX_DP),
> + DRV_PTR(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP),
> + DRV_PTR(dw_hdmi_rockchip_pltfm_driver, CONFIG_ROCKCHIP_DW_HDMI),
> + DRV_PTR(dw_mipi_dsi_driver, CONFIG_ROCKCHIP_DW_MIPI_DSI),
> + DRV_PTR(inno_hdmi_driver, CONFIG_ROCKCHIP_INNO_HDMI),
> +};
[...]
> +static int rockchip_drm_register_drivers(void)
> +{
> + int i, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(rockchip_drm_comp_drvs); i++) {
> + ret = platform_driver_register(rockchip_drm_comp_drvs[i]);
> + if (ret)
> + goto err_unreg;
> + }
This of course won't work in the NULL case, as platform_driver_register always
dereferences its parameter [0], so you should only call it for the actual non-
null array elements - of course same for unregister.
Heiko
[0] http://lxr.free-electrons.com/source/drivers/base/platform.c#L617
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings
On Tue, Mar 07, 2017 at 09:56:25AM +0100, Maxime Ripard wrote: > One of the possible output of the display pipeline, on the SoCs that have > it, is the HDMI controller. > > Add a binding for it. > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 21 +++- > 1 file changed, 21 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index b82c00449468..4b280672658e 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -4,6 +4,27 @@ Allwinner A10 Display Pipeline > The Allwinner A10 Display pipeline is composed of several components > that are going to be documented below: > > +HDMI Encoder > + > + > +The HDMI Encoder supports the HDMI video and audio outputs, and does > +CEC. It is one end of the pipeline. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun5i-a10s-hdmi > + - reg: base address and size of memory-mapped region > + - clocks: phandles to the clocks feeding the HDMI encoder > +* ahb: the HDMI interface clock > +* mod: the HDMI module clock > +* pll-0: the first video PLL > +* pll-1: the second video PLL > + - clock-names: the clock names mentioned above > + > + - ports: A ports node with endpoint definitions as defined in > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > +first port should be the input endpoint. You need an output port to an HDMI connector node and an audio port. > + > TV Encoder > -- > > -- > git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/15] dt-bindings: display: sun4i: Add allwinner,tcon-channel property
On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote: > The Allwinner Timings Controller has two, mutually exclusive, channels. > When the binding has been introduced, it was assumed that there would be > only a single user per channel in the system. > > While this is likely for the channel 0 which only connects to LCD displays, > it turns out that the channel 1 can be connected to multiple controllers in > the SoC (HDMI and TV encoders for example). And while the simultaneous use > of HDMI and TV outputs cannot be achieved, switching from one to the other > at runtime definitely sounds plausible. > > Add an extra property, allwinner,tcon-channel, to specify for a given > endpoint which TCON channel it is connected to, while falling back to the > previous mechanism if that property is missing. I think perhaps TCON channels should have been ports rather than endpoints. The fact that the channels are mutually exclusive can be handled in the driver and doesn't really matter in the binding. How painful would it be to rework things to move TCON channel 1 from port 0, endpoint 1 to port 1? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99841] Switching to VT freezes X only on a dual screen
https://bugs.freedesktop.org/show_bug.cgi?id=99841 --- Comment #17 from Elimar Riesebieter --- Thanks Michel for your efforts. Hereby I confirm that your patch against 4.11 works fine as well ;-) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Wednesday, March 15, 2017 3:38 AM
> To: Ayyappa Ch
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>
> Carizzo is an APU and resizing BARs isn't needed nor supported there.
> The CPU can access the full stolen VRAM directly on that hardware.
>
> As far as I know ASICs with support for this are Tonga, Fiji and all
> Polaris variants.
I think resizable BARs are supported as far back as evergreen or NI.
Alex
>
> Christian.
>
> Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> > Is it possible on Carrizo asics? Or only supports on newer asics?
> >
> > On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> > wrote:
> >> From: Christian König
> >>
> >> Try to resize BAR0 to let CPU access all of VRAM.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> +
> >> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> >> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> >> 4 files changed, 40 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> index 3b81ded..905ded9 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> amdgpu_device *adev, struct ttm_tt *ttm,
> >> struct ttm_mem_reg *mem);
> >> void amdgpu_vram_location(struct amdgpu_device *adev, struct
> amdgpu_mc *mc, u64 base);
> >> void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> amdgpu_mc *mc);
> >> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev,
> u64 size);
> >> int amdgpu_ttm_init(struct amdgpu_device *adev);
> >> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> index 118f4e6..92955fe 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device
> *adev, struct amdgpu_mc *mc)
> >> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> >> }
> >>
> >> +/**
> >> + * amdgpu_resize_bar0 - try to resize BAR0
> >> + *
> >> + * @adev: amdgpu_device pointer
> >> + *
> >> + * Try to resize BAR0 to make all VRAM CPU accessible.
> >> + */
> >> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> >> +{
> >> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> >> + int r;
> >> +
> >> + r = pci_resize_resource(adev->pdev, 0, size);
> >> +
> >> + if (r == -ENOTSUPP) {
> >> + /* The hardware don't support the extension. */
> >> + return;
> >> +
> >> + } else if (r == -ENOSPC) {
> >> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> >> + } else if (r) {
> >> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> >> + }
> >> +
> >> + /* Reinit the doorbell mapping, it is most likely moved as well */
> >> + amdgpu_doorbell_fini(adev);
> >> + BUG_ON(amdgpu_doorbell_init(adev));
> >> +}
> >> +
> >> /*
> >>* GPU helpers function.
> >>*/
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> index dc9b6d6..36a7aa5 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct
> amdgpu_device *adev)
> >> break;
> >> }
> >> adev->mc.vram_width = numchan * chansize;
> >> - /* Could aper size report 0 ? */
> >> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> >> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> >> /* size in MB on si */
> >> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) *
> 1024ULL * 1024ULL;
> >> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) *
> 1024ULL * 1024ULL;
> >>
> >> + if (!(adev->flags & AMD_IS_APU))
> >> + amdgpu_resize_bar0(adev);
> >> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> >> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> >> +
> >> #ifdef CONFIG_X86_64
> >> if (adev->flags & AMD_IS_APU) {
> >> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET))
> << 22;
> >> diff --git a/drivers/gpu/drm/am
[PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive. However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.
After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.
v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.
Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:
"* Skip this step if there isn't any high precision timestamp
* available. In that case we can't account for this and just
* hope for the best.
*/
With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.
Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.
v3: Patch before coffee needs extra coffee.
Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9bdca69f754c..e64b05ea95ea 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1198,9 +1198,9 @@ static void drm_vblank_put(struct drm_device *dev,
unsigned int pipe)
if (atomic_dec_and_test(&vblank->refcount)) {
if (drm_vblank_offdelay == 0)
return;
- else if (dev->vblank_disable_immediate || drm_vblank_offdelay <
0)
+ else if (drm_vblank_offdelay < 0)
vblank_disable_fn((unsigned long)vblank);
- else
+ else if (!dev->vblank_disable_immediate)
mod_timer(&vblank->disable_timer,
jiffies + ((drm_vblank_offdelay * HZ)/1000));
}
@@ -1734,6 +1734,16 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned
int pipe)
wake_up(&vblank->queue);
drm_handle_vblank_events(dev, pipe);
+ /* With instant-off, we defer disabling the interrupt until after
+* we finish processing the following vblank. The disable has to
+* be last (after drm_handle_vblank_events) so that the timestamp
+* is always accurate.
+*/
+ if (dev->vblank_disable_immediate &&
+ drm_vblank_offdelay > 0 &&
+ !atomic_read(&vblank->refcount))
+ vblank_disable_fn((unsigned long)vblank);
+
spin_unlock_irqrestore(&dev->event_lock, irqflags);
return true;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: Skip the waitqueue setup for vblank queries
Avoid adding to the waitqueue and reprobing the current vblank if the
caller is only querying the current vblank sequence and timestamp, where
we know that the wait would return immediately.
v2: Add CRTC identifier to debug messages
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
Reviewed-by: Michel Dänzer
Reviewed-and-tested-by: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index e64b05ea95ea..53a526c7b24d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1610,7 +1610,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
ret = drm_vblank_get(dev, pipe);
if (ret) {
- DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
+ DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n",
pipe, ret);
return ret;
}
seq = drm_vblank_count(dev, pipe);
@@ -1638,13 +1638,15 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
return drm_queue_vblank_event(dev, pipe, vblwait, file_priv);
}
- DRM_DEBUG("waiting on vblank count %u, crtc %u\n",
- vblwait->request.sequence, pipe);
- DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
- (((drm_vblank_count(dev, pipe) -
- vblwait->request.sequence) <= (1 << 23)) ||
-!vblank->enabled ||
-!dev->irq_enabled));
+ if (vblwait->request.sequence != seq) {
+ DRM_DEBUG("waiting on vblank count %u, crtc %u\n",
+ vblwait->request.sequence, pipe);
+ DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
+ (((drm_vblank_count(dev, pipe) -
+ vblwait->request.sequence) <= (1 << 23)) ||
+!vblank->enabled ||
+!dev->irq_enabled));
+ }
if (ret != -EINTR) {
struct timeval now;
@@ -1653,10 +1655,10 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
vblwait->reply.tval_sec = now.tv_sec;
vblwait->reply.tval_usec = now.tv_usec;
- DRM_DEBUG("returning %u to client\n",
- vblwait->reply.sequence);
+ DRM_DEBUG("crtc %d returning %u to client\n",
+ pipe, vblwait->reply.sequence);
} else {
- DRM_DEBUG("vblank wait interrupted by signal\n");
+ DRM_DEBUG("crtc %d vblank wait interrupted by signal\n", pipe);
}
done:
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: Peek at the current counter/timestamp for vblank queries
Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.
This is dependent upon the both the hardware and driver to provide the
proper barriers to facilitate reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 53a526c7b24d..c55abce152a2 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1559,6 +1559,17 @@ static int drm_queue_vblank_event(struct drm_device
*dev, unsigned int pipe,
return ret;
}
+static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
+{
+ if (vblwait->request.sequence)
+ return false;
+
+ return _DRM_VBLANK_RELATIVE ==
+ (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
+ _DRM_VBLANK_EVENT |
+ _DRM_VBLANK_NEXTONMISS));
+}
+
/*
* Wait for VBLANK.
*
@@ -1608,6 +1619,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
vblank = &dev->vblank[pipe];
+ /* If the counter is currently enabled and accurate, short-circuit
queries
+* to return the cached timestamp of the last vblank.
+*/
+ if (dev->vblank_disable_immediate &&
+ drm_wait_vblank_is_query(vblwait) &&
+ vblank->enabled) {
+ struct timeval now;
+
+ vblwait->reply.sequence =
+ drm_vblank_count_and_time(dev, pipe, &now);
+ vblwait->reply.tval_sec = now.tv_sec;
+ vblwait->reply.tval_usec = now.tv_usec;
+ return 0;
+ }
+
ret = drm_vblank_get(dev, pipe);
if (ret) {
DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n",
pipe, ret);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
On Wed, Mar 15, 2017 at 08:40:25PM +, Chris Wilson wrote:
> On vblank instant-off systems, we can get into a situation where the cost
> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> dominates. And with the advent of even deeper hardware sleep state,
> touching registers becomes ever more expensive. However, we know that if
> the user wants the current vblank counter, they are also very likely to
> immediately queue a vblank wait and so we can keep the interrupt around
> and only turn it off if we have no further vblank requests queued within
> the interrupt interval.
>
> After vblank event delivery, this patch adds a shadow of one vblank where
> the interrupt is kept alive for the user to query and queue another vblank
> event. Similarly, if the user is using blocking drmWaitVblanks, the
> interrupt will be disabled on the IRQ following the wait completion.
> However, if the user is simply querying the current vblank counter and
> timestamp, the interrupt will be disabled after every IRQ and the user
> will enabled it again on the first query following the IRQ.
>
> v2: Mario Kleiner -
> After testing this, one more thing that would make sense is to move
> the disable block at the end of drm_handle_vblank() instead of at the
> top.
>
> Turns out that if high precision timestaming is disabled or doesn't
> work for some reason (as can be simulated by echo 0 >
> /sys/module/drm/parameters/timestamp_precision_usec), then with your
> delayed disable code at its current place, the vblank counter won't
> increment anymore at all for instant queries, ie. with your other
> "instant query" patches. Clients which repeatedly query the counter
> and wait for it to progress will simply hang, spinning in an endless
> query loop. There's that comment in vblank_disable_and_save:
>
> "* Skip this step if there isn't any high precision timestamp
> * available. In that case we can't account for this and just
> * hope for the best.
> */
>
> With the disable happening after leading edge of vblank (== hw counter
> increment already happened) but before the vblank counter/timestamp
> handling in drm_handle_vblank, that step is needed to keep the counter
> progressing, so skipping it is bad.
>
> Now without high precision timestamping support, a kms driver must not
> set dev->vblank_disable_immediate = true, as this would cause problems
> for clients, so this shouldn't matter, but it would be good to still
> make this robust against a future kms driver which might have
> unreliable high precision timestamping, e.g., high precision
> timestamping that intermittently doesn't work.
>
> v3: Patch before coffee needs extra coffee.
>
> Testcase: igt/kms_vblank
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Michel Dänzer
> Cc: Laurent Pinchart
> Cc: Dave Airlie ,
> Cc: Mario Kleiner
Yep. This seems like a good idea to me. I just neglected to review it
last time around (and maybe even before that?) for some reason. Locks
seem to be taken in the right order, so it at least looks safe to me.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_irq.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 9bdca69f754c..e64b05ea95ea 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1198,9 +1198,9 @@ static void drm_vblank_put(struct drm_device *dev,
> unsigned int pipe)
> if (atomic_dec_and_test(&vblank->refcount)) {
> if (drm_vblank_offdelay == 0)
> return;
> - else if (dev->vblank_disable_immediate || drm_vblank_offdelay <
> 0)
> + else if (drm_vblank_offdelay < 0)
> vblank_disable_fn((unsigned long)vblank);
> - else
> + else if (!dev->vblank_disable_immediate)
> mod_timer(&vblank->disable_timer,
> jiffies + ((drm_vblank_offdelay * HZ)/1000));
> }
> @@ -1734,6 +1734,16 @@ bool drm_handle_vblank(struct drm_device *dev,
> unsigned int pipe)
> wake_up(&vblank->queue);
> drm_handle_vblank_events(dev, pipe);
>
> + /* With instant-off, we defer disabling the interrupt until after
> + * we finish processing the following vblank. The disable has to
> + * be last (after drm_handle_vblank_events) so that the timestamp
> + * is always accurate.
> + */
> + if (dev->vblank_disable_immediate &&
> + drm_vblank_offdelay > 0 &&
> + !atomic_read(&vblank->refcount))
> + vblank_disable_fn((unsigned long)vblank);
> +
> spin_unlock_irqrestore(&dev->event_lock, irqflags);
>
> return true;
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: Peek at the current counter/timestamp for vblank queries
On Wed, Mar 15, 2017 at 08:40:27PM +, Chris Wilson wrote:
> Bypass all the spinlocks and return the last timestamp and counter from
> the last vblank if the driver delcares that it is accurate (and stable
> across on/off), and the vblank is currently enabled.
>
> This is dependent upon the both the hardware and driver to provide the
> proper barriers to facilitate reading our bookkeeping outside of the
> vblank interrupt and outside of the explicit vblank locks.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Michel Dänzer
> Cc: Laurent Pinchart
> Cc: Dave Airlie ,
> Cc: Mario Kleiner
> ---
> drivers/gpu/drm/drm_irq.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 53a526c7b24d..c55abce152a2 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1559,6 +1559,17 @@ static int drm_queue_vblank_event(struct drm_device
> *dev, unsigned int pipe,
> return ret;
> }
>
> +static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
> +{
> + if (vblwait->request.sequence)
> + return false;
> +
> + return _DRM_VBLANK_RELATIVE ==
> + (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
> + _DRM_VBLANK_EVENT |
> + _DRM_VBLANK_NEXTONMISS));
> +}
> +
> /*
> * Wait for VBLANK.
> *
> @@ -1608,6 +1619,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>
> vblank = &dev->vblank[pipe];
>
> + /* If the counter is currently enabled and accurate, short-circuit
> queries
> + * to return the cached timestamp of the last vblank.
> + */
> + if (dev->vblank_disable_immediate &&
> + drm_wait_vblank_is_query(vblwait) &&
> + vblank->enabled) {
Hmm. I'm wondering if this could give us something stale if we're just
about to enable the vblank interrupt.
We seem to set enabled=true before we update the count/ts. So I'm
thinking we'd need to flip those around and make sure proper barriers
are in place.
> + struct timeval now;
> +
> + vblwait->reply.sequence =
> + drm_vblank_count_and_time(dev, pipe, &now);
> + vblwait->reply.tval_sec = now.tv_sec;
> + vblwait->reply.tval_usec = now.tv_usec;
> + return 0;
> + }
> +
> ret = drm_vblank_get(dev, pipe);
> if (ret) {
> DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n",
> pipe, ret);
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-fixes-4.11
Hi Dave, A few fixes for 4.11. The following changes since commit 3f81e1340706e9a7f854808e2f580c3106805d0c: drm: mxsfb: Implement drm_panel handling (2017-03-10 11:11:14 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 for you to fetch changes up to 801a6aa9a63c90724e8899982ad8c7f16be1e2cd: drm/amd/amdgpu: Fix debugfs reg read/write address width (2017-03-15 16:21:34 -0400) Alex Deucher (2): drm/radeon/si: add dpm quirk for Oland drm/amdgpu/si: add dpm quirk for Oland Arnd Bergmann (1): drm: amd: remove broken include path Dave Airlie (1): drm/amdgpu: fix parser init error path to avoid crash in parser fini Rex Zhu (1): drm/amd/powerplay: fix copy error in smu7_clockpoweragting.c Tom St Denis (2): drm/amd/amdgpu: Disable GFX_PG on Carrizo until compute issues solved drm/amd/amdgpu: Fix debugfs reg read/write address width drivers/gpu/drm/amd/acp/Makefile| 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/si_dpm.c | 6 ++ drivers/gpu/drm/amd/amdgpu/vi.c | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c | 2 +- drivers/gpu/drm/radeon/si_dpm.c | 6 ++ 7 files changed, 18 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99841] Switching to VT freezes X only on a dual screen
https://bugs.freedesktop.org/show_bug.cgi?id=99841 --- Comment #18 from Joseph Thommes --- The patch also solves the problem for me on 4.10.2-gentoo. Thank You. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
