[git pull] drm fixes
Hi Linus, I got a bit behind last week, so here is a delayed fixes pull, A bunch of radeon/amd gpu fixes, some nouveau regression fixes (ppc bios reading and runtime pm fix) one drm core oops fix, two qxl locking fixes, one qxl regression fix, Dave. The following changes since commit f6702681a0af186db8518793fbe46f45cce967dd: Merge tag 'for-linus-4.3b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip (2015-10-06 15:05:02 +0100) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 7b98040a7718663903bb25c06c7aed9801abbd9d: Merge branch 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2015-10-12 13:59:04 +1000) Alex Deucher (8): drm/radeon: add pm sysfs files late drm/amdgpu: add pm sysfs files late drm/radeon: add quirk for ASUS R7 370 drm/radeon: restore the fbdev mode in lastclose drm/amdgpu: restore the fbdev mode in lastclose drm/amdgpu: fix num_crtc on CZ drm/amdgpu: check before checking pci bridge registers drm/amdgpu: flag iceland as experimental Arnd Bergmann (1): drm/amdgpu: fix 32-bit compiler warning Ben Skeggs (2): drm/nouveau/bios: translate devinit pri/sec i2c bus to internal identifiers drm/nouveau/fbcon: take runpm reference when userspace has an open fd Daniel Vetter (1): drm: Fix locking for sysfs dpms file Dave Airlie (2): Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Frediano Ziglio (2): drm/qxl: avoid buffer reservation in qxl_crtc_page_flip drm/qxl: avoid dependency lock Gerd Hoffmann (1): drm/qxl: fix framebuffer dirty rectangle tracking. Ilia Mirkin (2): drm/nouveau/display: allow up to 16k width/height for fermi+ drm/nouveau/bios: fix OF loading Ondrej Zary (1): drm/nouveau/nouveau: Disable AGP for SiS 761 Sudip Mukherjee (1): drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 10 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 16 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +- drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 8 +-- drivers/gpu/drm/amd/amdgpu/cik.c | 3 ++ drivers/gpu/drm/amd/amdgpu/cz_dpm.c| 10 ++-- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/kv_dpm.c| 9 ++-- drivers/gpu/drm/amd/amdgpu/vi.c| 3 ++ drivers/gpu/drm/drm_sysfs.c| 12 ++--- drivers/gpu/drm/nouveau/nouveau_display.c | 6 ++- drivers/gpu/drm/nouveau/nouveau_fbcon.c| 24 + drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c| 6 +++ drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h| 3 ++ drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 27 ++ .../gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c| 17 +- drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c | 8 ++- drivers/gpu/drm/qxl/qxl_display.c | 10 +++- drivers/gpu/drm/qxl/qxl_fb.c | 19 --- drivers/gpu/drm/qxl/qxl_release.c | 4 +- drivers/gpu/drm/radeon/radeon_display.c| 14 + drivers/gpu/drm/radeon/radeon_fb.c | 16 ++ drivers/gpu/drm/radeon/radeon_kms.c| 5 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/radeon_pm.c | 63 +- drivers/gpu/drm/radeon/si_dpm.c| 1 + 29 files changed, 219 insertions(+), 94 deletions(-)
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #28 from Barto --- another discovery : in qemu I can set a type of CPU ( pentium, pentium2, pentium2, core2duo, SandyBridge and many more ), you can see the CPUs list with the command "qemu-i386 -cpu ?", until now I used the qemu option "-cpu host", which means that it's the CPU of the host who is emulated ( my pentium dual core E6800 ), then I decided to set a different CPU name in my qemu script : -cpu core2duo -enable-kvm -machine type=pc,accel=kvm -smp 2 with this setting the bug disapears, all is ok in my virtual machine, glxgears and all openGL programs can run without crash, the mesa driver llvmpipe doesn't crash, after that I decided to do set again another CPU in qemu : -cpu Penryn -enable-kvm -machine type=pc,accel=kvm -smp 2 \ with "Penryn" CPU the bug is back in my virtual machine, which means that the bug seems related to the type of CPU, llvm 3.7.0 lib may have a bug when he tries to generate binary code, it fails with some CPUs, this problem doesn't exist with llvm 3.6.2 lib -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151013/9eab7baa/attachment.html>
[PATCH v6 11/17] Documentation: phy: add document for rockchip dp phy
Hi,
On Saturday 10 October 2015 09:28 PM, Yakir Yang wrote:
> This phy driver is binded with the Rockchip DisplayPort
> driver, here are the brief properties:
> edp_phy: edp-phy at ff770274 {
> compatible = "rockchip,rk3288-dp-phy";
> rockchip,grf = <&grf>;
> clocks = <&cru SCLK_EDP_24M>;
> clock-names = "24m";
> #phy-cells = <0>;
> };
The commit message can simply be "Add dt binding documentation for
rockchip display port PHY".
Thanks
Kishon
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v6: None
> Changes in v5:
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
> elemets in document. (Rob & Heiko)
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> new file mode 100644
> index 000..505194e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip Soc Seroes Display Port PHY
> +
> +
> +Required properties:
> +- compatible : should be one of the following supported values:
> + - "rockchip.rk3288-dp-phy"
> +- clocks: from common clock binding: handle to dp clock.
> + of memory mapped region.
> +- clock-names: from common clock binding:
> + Required elements: "24m"
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +- #phy-cells : from the generic PHY bindings, must be 0;
> +
> +Example:
> +
> +edp_phy: edp-phy at ff770274 {
> + compatible = "rockchip,rk3288-dp-phy";
> + rockchip,grf = <&grf>;
> + clocks = <&cru SCLK_EDP_24M>;
> + clock-names = "24m";
> + #phy-cells = <0>;
> +};
>
[PATCH v6 10/17] phy: Add driver for rockchip Display Port PHY
Hi Kishon
On 10/12/2015 11:02 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
>> This phy driver would control the Rockchip DisplayPort module
>> phy clock and phy power, it is relate to analogix_dp-rockchip
>> dp driver. If you want DP works rightly on rockchip platform,
>> then you should select both of them.
> Add phy driver for the Rockchip DisplayPort PHY module. This is required
> to get DisplayPort working in Rockchip SoCs.
Thanks, take point.
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v6: None
>> Changes in v5:
>> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>>the exist "grf" syscon already. And rename the example DT node from
>>"edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
>> - Add deivce_node at the front of driver, update phy_ops type from "static
>>struct" to "static const struct". And correct the input paramters of
>>devm_phy_create() interfaces. (Heiko)
>>
>> Changes in v4:
>> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>>function, move those code to probe() method. And remove driver .owner
>>number. (Kishon)
>>
>> Changes in v3:
>> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>>power control. (Heiko)
>>
>> Changes in v2: None
>>
>> drivers/phy/Kconfig | 7 ++
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-rockchip-dp.c | 151
>> ++
>> 3 files changed, 159 insertions(+)
>> create mode 100644 drivers/phy/phy-rockchip-dp.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 47da573..8f2bc4f 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
>> help
>>Enable this to support the Rockchip USB 2.0 PHY.
>>
>> +config PHY_ROCKCHIP_DP
>> +tristate "Rockchip Display Port PHY Driver"
>> +depends on ARCH_ROCKCHIP && OF
>> +select GENERIC_PHY
>> +help
>> + Enable this to support the Rockchip Display Port PHY.
>> +
>> config PHY_ST_SPEAR1310_MIPHY
>> tristate "ST SPEAR1310-MIPHY driver"
>> select GENERIC_PHY
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a5b18c1..e281f35 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) +=
>> phy-s5pv210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
>> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>> +obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o
>> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
>> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
>> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
>> new file mode 100644
>> index 000..3a2ac120
>> --- /dev/null
>> +++ b/drivers/phy/phy-rockchip-dp.c
>> @@ -0,0 +1,151 @@
>> +/*
>> + * Rockchip DP PHY driver
>> + *
>> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
>> + * Author: Yakir Yang
>> + *
>> + * 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.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define GRF_SOC_CON12 0x0274
>> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
>> +#define GRF_EDP_PHY_SIDDQ_WRITE_EN BIT(21)
>> +#define GRF_EDP_PHY_SIDDQ_ON0
>> +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
>> +
>> +struct rockchip_dp_phy {
>> +struct device *dev;
>> +struct regmap *grf;
>> +struct clk *phy_24m;
>> +};
>> +
>> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
>> +{
>> +struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
>> +int ret;
>> +
>> +if (enable) {
>> +ret = clk_prepare_enable(dp->phy_24m);
>> +if (ret < 0) {
>> +dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = regmap_write(dp->grf, GRF_SOC_CON12,
>> + GRF_EDP_PHY_SIDDQ_WRITE_EN |
>> + GRF_EDP_PHY_SIDDQ_ON);
>> +} else {
>> +clk_disable_unprepare(dp->phy_24m);
> should clk_disable come after regmap_write? It'll be symmetric to enable?
I don't see there is a strict limit about this, but thanks for your point, I
would like to change this order to:
if (enable) {
// Enable SIDDQ power
// Enable Clock
} else {
/
[PATCH v6 11/17] Documentation: phy: add document for rockchip dp phy
Hi Kishon,
On 10/13/2015 06:28 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 10 October 2015 09:28 PM, Yakir Yang wrote:
>> This phy driver is binded with the Rockchip DisplayPort
>> driver, here are the brief properties:
>> edp_phy: edp-phy at ff770274 {
>> compatible = "rockchip,rk3288-dp-phy";
>> rockchip,grf = <&grf>;
>> clocks = <&cru SCLK_EDP_24M>;
>> clock-names = "24m";
>> #phy-cells = <0>;
>> };
> The commit message can simply be "Add dt binding documentation for
> rockchip display port PHY".
Okay, thanks.
- Yakir
>
> Thanks
> Kishon
>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v6: None
>> Changes in v5:
>> - Split binding doc's from driver changes. (Rob)
>> - Update the rockchip,grf explain in document, and correct the clock required
>>elemets in document. (Rob & Heiko)
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>>
>> .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22
>> ++
>> 1 file changed, 22 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> new file mode 100644
>> index 000..505194e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>> @@ -0,0 +1,22 @@
>> +Rockchip Soc Seroes Display Port PHY
>> +
>> +
>> +Required properties:
>> +- compatible : should be one of the following supported values:
>> + - "rockchip.rk3288-dp-phy"
>> +- clocks: from common clock binding: handle to dp clock.
>> +of memory mapped region.
>> +- clock-names: from common clock binding:
>> +Required elements: "24m"
>> +- rockchip,grf: phandle to the syscon managing the "general register files"
>> +- #phy-cells : from the generic PHY bindings, must be 0;
>> +
>> +Example:
>> +
>> +edp_phy: edp-phy at ff770274 {
>> +compatible = "rockchip,rk3288-dp-phy";
>> +rockchip,grf = <&grf>;
>> +clocks = <&cru SCLK_EDP_24M>;
>> +clock-names = "24m";
>> +#phy-cells = <0>;
>> +};
>>
>
>
[PATCH] drm/exynos: fix to detach device of iommu
Merged. Thanks, Inki Dae 2015ë 10ì 02ì¼ 09:30ì Joonyoung Shim ì´(ê°) ì´ ê¸: > The arm_iommu_detach_device() is a function to detach device of iommu > attached by arm_iommu_attach_device(). The exynos-drm uses > arm_iommu_attach_device() so it should use arm_iommu_detach_device() to > detach device of iommu, not iommu_detach_device(). > > The drm_release_iommu_mapping() is a function to release mapping of > iommu created by arm_iommu_create_mapping(). It is called by > exynos_drm_unload() so shouldn't be called by drm_iommu_detach_device(). > > Signed-off-by: Joonyoung Shim > Cc: # v3.8+ > --- > drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > index 055e8ec..d73b9ad 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > @@ -139,6 +139,5 @@ void drm_iommu_detach_device(struct drm_device *drm_dev, > if (!mapping || !mapping->domain) > return; > > - iommu_detach_device(mapping->domain, subdrv_dev); > - drm_release_iommu_mapping(drm_dev); > + arm_iommu_detach_device(subdrv_dev); > } >
[PATCH] drm/exynos: cleanup name of gem object for exynos_drm
Merged.
Thanks,
Inki Dae
2015ë
10ì 02ì¼ 09:33ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> Struct of gem object in exynos_drm driver is struct exynos_drm_gem_obj.
> It's too long and we can know its meaning of name without _obj postfix.
>
> We use several names to variable name of gem object for exynos_drm -
> exynos_gem_obj, gem_obj and obj. Especially "obj" name can cause
> misunderstanding with variable name "obj" of struct drm_gem_object.
>
> This will clean about name of gem object for exynos_drm as follows.
> s/struct exynos_drm_gem_obj/struct exynos_drm_gem
> s/exynos_gem_obj or gem_obj or obj/exynos_gem
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c| 45 +++---
> drivers/gpu/drm/exynos/exynos_drm_fb.h| 5 +-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 53 +++
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 239
> +++---
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 15 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 9 +-
> 6 files changed, 184 insertions(+), 182 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 0842808..fcea28b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -32,15 +32,15 @@
>* exynos specific framebuffer structure.
>*
>* @fb: drm framebuffer obejct.
> - * @exynos_gem_obj: array of exynos specific gem object containing a gem
> object.
> + * @exynos_gem: array of exynos specific gem object containing a gem object.
>*/
> struct exynos_drm_fb {
> - struct drm_framebuffer fb;
> - struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
> + struct drm_framebuffer fb;
> + struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
> };
>
> static int check_fb_gem_memory_type(struct drm_device *drm_dev,
> - struct exynos_drm_gem_obj *exynos_gem_obj)
> + struct exynos_drm_gem *exynos_gem)
> {
> unsigned int flags;
>
> @@ -51,7 +51,7 @@ static int check_fb_gem_memory_type(struct drm_device
> *drm_dev,
> if (is_drm_iommu_supported(drm_dev))
> return 0;
>
> - flags = exynos_gem_obj->flags;
> + flags = exynos_gem->flags;
>
> /*
>* without iommu support, not support physically non-continuous memory
> @@ -75,13 +75,13 @@ static void exynos_drm_fb_destroy(struct drm_framebuffer
> *fb)
>
> drm_framebuffer_cleanup(fb);
>
> - for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem_obj); i++) {
> + for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem); i++) {
> struct drm_gem_object *obj;
>
> - if (exynos_fb->exynos_gem_obj[i] == NULL)
> + if (exynos_fb->exynos_gem[i] == NULL)
> continue;
>
> - obj = &exynos_fb->exynos_gem_obj[i]->base;
> + obj = &exynos_fb->exynos_gem[i]->base;
> drm_gem_object_unreference_unlocked(obj);
> }
>
> @@ -96,7 +96,7 @@ static int exynos_drm_fb_create_handle(struct
> drm_framebuffer *fb,
> struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
>
> return drm_gem_handle_create(file_priv,
> - &exynos_fb->exynos_gem_obj[0]->base, handle);
> + &exynos_fb->exynos_gem[0]->base, handle);
> }
>
> static int exynos_drm_fb_dirty(struct drm_framebuffer *fb,
> @@ -118,7 +118,7 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs =
> {
> struct drm_framebuffer *
> exynos_drm_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> - struct exynos_drm_gem_obj **gem_obj,
> + struct exynos_drm_gem **exynos_gem,
> int count)
> {
> struct exynos_drm_fb *exynos_fb;
> @@ -130,11 +130,11 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
> return ERR_PTR(-ENOMEM);
>
> for (i = 0; i < count; i++) {
> - ret = check_fb_gem_memory_type(dev, gem_obj[i]);
> + ret = check_fb_gem_memory_type(dev, exynos_gem[i]);
> if (ret < 0)
> goto err;
>
> - exynos_fb->exynos_gem_obj[i] = gem_obj[i];
> + exynos_fb->exynos_gem[i] = exynos_gem[i];
> }
>
> drm_helper_mode_fill_fb_struct(&exynos_fb->fb, mode_cmd);
> @@ -156,7 +156,7 @@ static struct drm_framebuffer *
> exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - struct exynos_drm_gem_obj *gem_objs[MAX_FB_BUFFER];
> + struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
> struct drm_gem_object *obj;
> struct drm_framebuffer *fb;
> int i;
> @@ -171,10 +171,10 @@ exynos_user_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
>
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
Merged.
Thanks,
Inki Dae
2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
> ioctl") removed it same with the ioctl that this patch adds. The reason
> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>
> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
> include/uapi/drm/exynos_drm.h | 17 -
> 4 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index f0a5839..8fd7201 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
> exynos_drm_gem_vm_ops = {
> static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
> + DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
> DRM_UNLOCKED | DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index f1dcdd0..29f4875 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_exynos_gem_map *args = data;
> +
> + return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
> + &args->offset);
> +}
> +
> dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
> unsigned int gem_handle,
> struct drm_file *filp)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 37ab8b2..0d0ab27 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
> drm_device *dev,
> int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
>
> +/* get fake-offset of gem object that can be used with mmap. */
> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> +
> /*
>* get dma address from gem handle and this function could be used for
>* other drivers such as 2d/3d acceleration drivers.
> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
> index 5575ed1..18f0601 100644
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
> };
>
> /**
> + * A structure for getting a fake-offset that can be used with mmap.
> + *
> + * @handle: handle of gem object.
> + * @reserved: just padding to be 64-bit aligned.
> + * @offset: a fake-offset of gem object.
> + */
> +struct drm_exynos_gem_map {
> + __u32 handle;
> + __u32 reserved;
> + __u64 offset;
> +};
> +
> +/**
>* A structure to gem information.
>*
>* @handle: a handle to gem object created.
> @@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
> };
>
> #define DRM_EXYNOS_GEM_CREATE 0x00
> +#define DRM_EXYNOS_GEM_MAP 0x01
> /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
> #define DRM_EXYNOS_GEM_GET 0x04
> #define DRM_EXYNOS_VIDI_CONNECTION 0x07
> @@ -301,7 +315,8 @@ struct drm_exynos_ipp_cmd_ctrl {
>
> #define DRM_IOCTL_EXYNOS_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
> DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
> -
> +#define DRM_IOCTL_EXYNOS_GEM_MAP DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_EXYNOS_GEM_MAP, struct drm_exynos_gem_map)
> #define DRM_IOCTL_EXYNOS_GEM_GETDRM_IOWR(DRM_COMMAND_BASE + \
> DRM_EXYNOS_GEM_GET, struct drm_exynos_gem_info)
>
>
[PATCH] drm/vmwgfx: switch from ioremap_cache to memremap
Hi!
On 10/13/2015 12:35 AM, Dan Williams wrote:
> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
> expects the fifo registers to be cacheable. In preparation for
> deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
>
> Cc: David Airlie
> Cc: Thomas Hellstrom
> Cc: Sinclair Yeh
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Dan Williams
While I have nothing against the conversion, what's stopping the
compiler from reordering writes on a generic architecture and caching
and reordering reads on x86 in particular? At the very least it looks to
me like the memory accesses of the memremap'd memory needs to be
encapsulated within READ_ONCE and WRITE_ONCE.
How is this handled in the other conversions?
Thanks,
Thomas
> ---
>
> This is part of the tree-wide conversion of ioremap_cache() to
> memremap() targeted for v4.4 [1]
>
> As noted in that cover letter feel free to apply or ack. These
> individual conversions can go in independently given the base memremap()
> implementation is already upstream in v4.3-rc1.
>
> This passes a clean run of sparse, but I have not tried to run the
> result.
>
> [1]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2015_10_9_699&d=BQICaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=XuVtQ3_28jin5hdK6wBcLigEiRc-1TuelYa3zm94m44&s=kN3-2XStWWU0f20wNGpmQiwZTTiBBzwD4LShvfokwkQ&e=
>
>
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |8 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 23 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 102
> -
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |9 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_irq.c |8 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24
> 7 files changed, 84 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 2c7a25c71af2..d6152cd7c634 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -752,8 +752,8 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> ttm_lock_set_kill(&dev_priv->fbdev_master.lock, false, SIGTERM);
> dev_priv->active_master = &dev_priv->fbdev_master;
>
> - dev_priv->mmio_virt = ioremap_cache(dev_priv->mmio_start,
> - dev_priv->mmio_size);
> + dev_priv->mmio_virt = memremap(dev_priv->mmio_start,
> +dev_priv->mmio_size, MEMREMAP_WB);
>
> if (unlikely(dev_priv->mmio_virt == NULL)) {
> ret = -ENOMEM;
> @@ -907,7 +907,7 @@ out_no_irq:
> out_no_device:
> ttm_object_device_release(&dev_priv->tdev);
> out_err4:
> - iounmap(dev_priv->mmio_virt);
> + memunmap(dev_priv->mmio_virt);
> out_err3:
> vmw_ttm_global_release(dev_priv);
> out_err0:
> @@ -958,7 +958,7 @@ static int vmw_driver_unload(struct drm_device *dev)
> pci_release_regions(dev->pdev);
>
> ttm_object_device_release(&dev_priv->tdev);
> - iounmap(dev_priv->mmio_virt);
> + memunmap(dev_priv->mmio_virt);
> if (dev_priv->ctx.staged_bindings)
> vmw_binding_state_free(dev_priv->ctx.staged_bindings);
> vmw_ttm_global_release(dev_priv);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index f19fd39b43e1..7ff1db23de80 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -375,7 +375,7 @@ struct vmw_private {
> uint32_t stdu_max_height;
> uint32_t initial_width;
> uint32_t initial_height;
> - u32 __iomem *mmio_virt;
> + u32 *mmio_virt;
> uint32_t capabilities;
> uint32_t max_gmr_ids;
> uint32_t max_gmr_pages;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> index 567ddede51d1..97f75adc080d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
> @@ -141,9 +141,9 @@ static bool vmw_fence_enable_signaling(struct fence *f)
>
> struct vmw_fence_manager *fman = fman_from_fence(fence);
> struct vmw_private *dev_priv = fman->dev_priv;
> + u32 *fifo_mem = dev_priv->mmio_virt;
> + u32 seqno = *(fifo_mem + SVGA_FIFO_FENCE);
>
> - u32 __iomem *fifo_mem = dev_priv->mmio_virt;
> - u32 seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE);
> if (seqno - fence->base.seqno < VMW_FENCE_WRAP)
> return false;
>
>
Here, for example.
/Thomas
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
On 10/13/2015 02:11 PM, Inki Dae wrote:
>
> Merged.
>
Thanks for merge but this will be conflicted with the patch of Daniel,
http://patchwork.freedesktop.org/patch/60565/
I found it on next-20151012, do you want v2 patch that DRM_UNLOCKED flag
is dropped?
Thanks.
> Thanks,
> Inki Dae
>
> 2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
>> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
>> ioctl") removed it same with the ioctl that this patch adds. The reason
>> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
>> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>>
>> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
>> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
>> include/uapi/drm/exynos_drm.h | 17 -
>> 4 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index f0a5839..8fd7201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
>> exynos_drm_gem_vm_ops = {
>> static const struct drm_ioctl_desc exynos_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>> DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>> +DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
>> +DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
>> DRM_UNLOCKED | DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index f1dcdd0..29f4875 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev,
>> void *data,
>> return 0;
>> }
>>
>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>> + struct drm_file *file_priv)
>> +{
>> +struct drm_exynos_gem_map *args = data;
>> +
>> +return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
>> + &args->offset);
>> +}
>> +
>> dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
>> unsigned int gem_handle,
>> struct drm_file *filp)
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> index 37ab8b2..0d0ab27 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
>> drm_device *dev,
>> int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
>> struct drm_file *file_priv);
>>
>> +/* get fake-offset of gem object that can be used with mmap. */
>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>> + struct drm_file *file_priv);
>> +
>> /*
>>* get dma address from gem handle and this function could be used for
>>* other drivers such as 2d/3d acceleration drivers.
>> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
>> index 5575ed1..18f0601 100644
>> --- a/include/uapi/drm/exynos_drm.h
>> +++ b/include/uapi/drm/exynos_drm.h
>> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
>> };
>>
>> /**
>> + * A structure for getting a fake-offset that can be used with mmap.
>> + *
>> + * @handle: handle of gem object.
>> + * @reserved: just padding to be 64-bit aligned.
>> + * @offset: a fake-offset of gem object.
>> + */
>> +struct drm_exynos_gem_map {
>> +__u32 handle;
>> +__u32 reserved;
>> +__u64 offset;
>> +};
>> +
>> +/**
>>* A structure to gem information.
>>*
>>* @handle: a handle to gem object created.
>> @@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
>> };
>>
>> #define DRM_EXYNOS_GEM_CREATE0x00
>> +#define DRM_EXYNOS_GEM_MAP0x01
>> /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
>> #define DRM_EXYNOS_GEM_GET0x04
>> #define DRM_EXYNOS_VIDI_CONNECTION0x07
>> @@ -301,7 +315,8 @@ struct drm_exynos_ipp_cmd_ctrl {
>>
>> #define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
>> DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
>> -
>> +#define DRM_IOCTL_EXYNOS_GEM_MAPDRM_IOWR(DRM_COMMAND_BASE + \
>> +DRM_EXYNOS_GEM_MAP, struct drm_exynos_gem_map)
>> #define DRM_IOCTL_EXYNOS_GEM_GETDRM_IOWR(DRM_COMMAND_BASE + \
>>
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
On 10/13/2015 02:23 PM, Joonyoung Shim wrote:
> On 10/13/2015 02:11 PM, Inki Dae wrote:
>>
>> Merged.
>>
>
> Thanks for merge but this will be conflicted with the patch of Daniel,
> http://patchwork.freedesktop.org/patch/60565/
>
Oops, wrong link,
http://lists.freedesktop.org/archives/intel-gfx/2015-September/075368.html
Thanks.
> I found it on next-20151012, do you want v2 patch that DRM_UNLOCKED flag
> is dropped?
>
> Thanks.
>
>> Thanks,
>> Inki Dae
>>
>> 2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
>>> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
>>> ioctl") removed it same with the ioctl that this patch adds. The reason
>>> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
>>> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>>>
>>> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
>>> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
>>> include/uapi/drm/exynos_drm.h | 17 -
>>> 4 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index f0a5839..8fd7201 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
>>> exynos_drm_gem_vm_ops = {
>>> static const struct drm_ioctl_desc exynos_ioctls[] = {
>>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>>> DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>> +DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
>>> +DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
>>> DRM_UNLOCKED | DRM_RENDER_ALLOW),
>>> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index f1dcdd0..29f4875 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device
>>> *dev, void *data,
>>> return 0;
>>> }
>>>
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv)
>>> +{
>>> +struct drm_exynos_gem_map *args = data;
>>> +
>>> +return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
>>> + &args->offset);
>>> +}
>>> +
>>> dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
>>> unsigned int gem_handle,
>>> struct drm_file *filp)
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 37ab8b2..0d0ab27 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
>>> drm_device *dev,
>>> int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
>>> struct drm_file *file_priv);
>>>
>>> +/* get fake-offset of gem object that can be used with mmap. */
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv);
>>> +
>>> /*
>>>* get dma address from gem handle and this function could be used for
>>>* other drivers such as 2d/3d acceleration drivers.
>>> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
>>> index 5575ed1..18f0601 100644
>>> --- a/include/uapi/drm/exynos_drm.h
>>> +++ b/include/uapi/drm/exynos_drm.h
>>> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
>>> };
>>>
>>> /**
>>> + * A structure for getting a fake-offset that can be used with mmap.
>>> + *
>>> + * @handle: handle of gem object.
>>> + * @reserved: just padding to be 64-bit aligned.
>>> + * @offset: a fake-offset of gem object.
>>> + */
>>> +struct drm_exynos_gem_map {
>>> +__u32 handle;
>>> +__u32 reserved;
>>> +__u64 offset;
>>> +};
>>> +
>>> +/**
>>>* A structure to gem information.
>>>*
>>>* @handle: a handle to gem object created.
>>> @@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
>>> };
>>>
>>> #define DRM_EXYNOS_GEM_CREATE0x00
>>> +#define DRM_EXYNOS_GEM_MAP0x01
>>> /* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
>>> #define DRM_EXYNOS_GEM_GET0x04
>>> #define DRM_EXYNOS_VIDI_CONNECTION0x07
>>> @@ -301,7 +315,8 @@ struct drm_exynos_ipp_cmd_ctrl {
>>>
>>> #define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
2015ë
10ì 13ì¼ 14:23ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> On 10/13/2015 02:11 PM, Inki Dae wrote:
>>
>> Merged.
>>
>
> Thanks for merge but this will be conflicted with the patch of Daniel,
> http://patchwork.freedesktop.org/patch/60565/
Right. With Daniel patch, DRM_UNLOCKED flag isn't needed anymore for
driver specific ioctls.
>
> I found it on next-20151012, do you want v2 patch that DRM_UNLOCKED flag
> is dropped?
It'd be better to drop the flag for cleanup. Anyway, I can do it.
Thanks,
Inki Dae
>
> Thanks.
>
>> Thanks,
>> Inki Dae
>>
>> 2015ë
10ì 05ì¼ 12:04ì Joonyoung Shim ì´(ê°) ì´ ê¸:
>>> The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
>>> ioctl") removed it same with the ioctl that this patch adds. The reason
>>> that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
>>> DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
>>>
>>> Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
>>> node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>>drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
>>>drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>>>drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
>>>include/uapi/drm/exynos_drm.h | 17 -
>>>4 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index f0a5839..8fd7201 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -404,6 +404,8 @@ static const struct vm_operations_struct
>>> exynos_drm_gem_vm_ops = {
>>>static const struct drm_ioctl_desc exynos_ioctls[] = {
>>>DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>>>DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>> +DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
>>> +DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
>>>DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
>>>DRM_UNLOCKED | DRM_RENDER_ALLOW),
>>>DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index f1dcdd0..29f4875 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device
>>> *dev, void *data,
>>>return 0;
>>>}
>>>
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv)
>>> +{
>>> +struct drm_exynos_gem_map *args = data;
>>> +
>>> +return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
>>> + &args->offset);
>>> +}
>>> +
>>>dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
>>>unsigned int gem_handle,
>>>struct drm_file *filp)
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 37ab8b2..0d0ab27 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
>>> drm_device *dev,
>>>int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
>>>struct drm_file *file_priv);
>>>
>>> +/* get fake-offset of gem object that can be used with mmap. */
>>> +int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
>>> + struct drm_file *file_priv);
>>> +
>>>/*
>>> * get dma address from gem handle and this function could be used for
>>> * other drivers such as 2d/3d acceleration drivers.
>>> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
>>> index 5575ed1..18f0601 100644
>>> --- a/include/uapi/drm/exynos_drm.h
>>> +++ b/include/uapi/drm/exynos_drm.h
>>> @@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
>>>};
>>>
>>>/**
>>> + * A structure for getting a fake-offset that can be used with mmap.
>>> + *
>>> + * @handle: handle of gem object.
>>> + * @reserved: just padding to be 64-bit aligned.
>>> + * @offset: a fake-offset of gem object.
>>> + */
>>> +struct drm_exynos_gem_map {
>>> +__u32 handle;
>>> +__u32 reserved;
>>> +__u64 offset;
>>> +};
>>> +
>>> +/**
>>> * A structure to gem information.
>>> *
>>> * @handle: a handle to gem object created.
>>> @@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
>>>};
>>>
>>>#define DRM_EXYNOS_GEM_CREATE0x00
>>> +#define DRM_EXYNOS_GEM_MAP0x01
>>>/* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
>>>#define DRM_EXYNOS_GEM_GET0x04
>>>#define DRM_EXYNOS_VIDI_CONNECTION0x07
>>> @@ -301,7 +315,
[Bug 105871] New: UVD decoder fails after hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=105871 Bug ID: 105871 Summary: UVD decoder fails after hibernate Product: Drivers Version: 2.5 Kernel Version: 4.1.8 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: jjorge at free.fr Regression: No [AMD/ATI] RS780 [Radeon HD 3200] works nicely, even after suspend/resume. But after a hibernate/resume, the UVD decoder fails, while OpenGL apps run ok. Full dmesg joined, here are the interesting lines : [ 258.694723] ACPI: Waking up from system sleep state S4 [ 258.696487] PM: noirq restore of devices complete after 0.724 msecs [ 258.696783] PM: early restore of devices complete after 0.260 msecs [ 258.735733] rtc_cmos 00:01: System wakeup disabled by ACPI [ 258.744344] [drm] PCIE GART of 512M enabled (table at 0xC0258000). [ 258.744394] radeon :01:05.0: WB enabled [ 258.744397] radeon :01:05.0: fence driver on ring 0 use gpu addr 0xac00 and cpu addr 0x88003758dc00 [ 258.750826] radeon :01:05.0: fence driver on ring 5 use gpu addr 0xc0056038 and cpu addr 0xc9816038 [ 258.783182] [drm] ring test on 0 succeeded in 0 usecs [ 258.959618] [drm] ring test on 5 succeeded in 1 usecs [ 258.959622] [drm] UVD initialized successfully. [ 258.959645] [drm] ib test on ring 0 succeeded in 0 usecs [ 269.631608] radeon :01:05.0: ring 5 stalled for more than 10020msec [ 269.631610] radeon :01:05.0: GPU lockup (current fence id 0x0862 last fence id 0x0864 on ring 5) [ 269.631693] [drm:uvd_v1_0_ib_test [radeon]] *ERROR* radeon: fence wait failed (-35). [ 269.631719] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on ring 5 (-35). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 105871] UVD decoder fails after hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=105871 --- Comment #1 from Jose --- Created attachment 190111 --> https://bugzilla.kernel.org/attachment.cgi?id=190111&action=edit Full hibernate/resume log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 105871] UVD decoder fails after hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=105871 --- Comment #2 from Jose --- I forgot to mention that as workaround a suspend/resume works, so it is only the hibernate resume that triggers the bug. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3+, still broken on 11.0.2)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 noga.dany at gmail.com changed: What|Removed |Added Version|10.3|11.0 Summary|[radeon] Europa Universalis |[radeon] Europa Universalis |4 freezing during game |4 freezing during game |start (10.3.3) |start (10.3.3+, still ||broken on 11.0.2) --- Comment #31 from noga.dany at gmail.com --- Tested on 11.0.2 and still it freezes -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151013/2429017a/attachment.html>
[PATCH 4/9] drm/exynos: split buffer allocation using DMA mapping API on non-iommu
This introduces new functions to allocate/free buffer using DMA mapping
API. Now already exynos-drm uses DMA mapping API to allocate/free buffer
but it is used on both iommu and non-iommu, so split it. It will be
added new buffer allocation not to use DMA mapping API later.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 90 +++--
1 file changed, 64 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index d5951f75c774..88196edd4ade 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,6 +20,63 @@
#include "exynos_drm_gem.h"
#include "exynos_drm_iommu.h"
+static int exynos_drm_alloc_dma(struct exynos_drm_gem *exynos_gem)
+{
+ struct drm_device *dev = exynos_gem->base.dev;
+ unsigned int nr_pages;
+ unsigned int i;
+ dma_addr_t addr;
+
+ init_dma_attrs(&exynos_gem->dma_attrs);
+
+ if (exynos_gem->flags & EXYNOS_BO_WC ||
+ !(exynos_gem->flags & EXYNOS_BO_CACHABLE))
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &exynos_gem->dma_attrs);
+
+ dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &exynos_gem->dma_attrs);
+
+ nr_pages = exynos_gem->size >> PAGE_SHIFT;
+
+ exynos_gem->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
+ if (!exynos_gem->pages) {
+ DRM_ERROR("failed to allocate pages\n");
+ return -ENOMEM;
+ }
+
+ exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
+&exynos_gem->dma_addr, GFP_KERNEL,
+&exynos_gem->dma_attrs);
+ if (!exynos_gem->cookie) {
+ DRM_ERROR("failed to allocate buffer\n");
+ drm_free_large(exynos_gem->pages);
+ return -ENOMEM;
+ }
+
+ addr = exynos_gem->dma_addr;
+ for (i = 0; i < nr_pages; i++) {
+ exynos_gem->pages[i] =
+ pfn_to_page(dma_to_pfn(dev->dev, addr));
+ addr += PAGE_SIZE;
+ }
+
+ DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
+ (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
+
+ return 0;
+}
+
+static void exynos_drm_free_dma(struct exynos_drm_gem *exynos_gem)
+{
+ struct drm_device *dev = exynos_gem->base.dev;
+
+ DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
+ (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
+
+ dma_free_attrs(dev->dev, exynos_gem->size, exynos_gem->cookie,
+ exynos_gem->dma_addr, &exynos_gem->dma_attrs);
+ drm_free_large(exynos_gem->pages);
+}
+
static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem)
{
struct drm_device *dev = exynos_gem->base.dev;
@@ -31,6 +88,9 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
return 0;
}
+ if (!is_drm_iommu_supported(dev))
+ return exynos_drm_alloc_dma(exynos_gem);
+
init_dma_attrs(&exynos_gem->dma_attrs);
/*
@@ -51,15 +111,6 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
nr_pages = exynos_gem->size >> PAGE_SHIFT;
- if (!is_drm_iommu_supported(dev)) {
- exynos_gem->pages = drm_calloc_large(nr_pages,
-sizeof(struct page *));
- if (!exynos_gem->pages) {
- DRM_ERROR("failed to allocate pages.\n");
- return -ENOMEM;
- }
- }
-
exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
&exynos_gem->dma_addr, GFP_KERNEL,
&exynos_gem->dma_attrs);
@@ -70,20 +121,7 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
return -ENOMEM;
}
- if (exynos_gem->pages) {
- dma_addr_t start_addr;
- unsigned int i = 0;
-
- start_addr = exynos_gem->dma_addr;
- while (i < nr_pages) {
- exynos_gem->pages[i] =
- pfn_to_page(dma_to_pfn(dev->dev, start_addr));
- start_addr += PAGE_SIZE;
- i++;
- }
- } else {
- exynos_gem->pages = exynos_gem->cookie;
- }
+ exynos_gem->pages = exynos_gem->cookie;
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)exynos_gem->dma_addr, exynos_gem->size);
@@ -100,15 +138,15 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
*exynos_gem)
return;
}
+ if (!is_drm_iommu_supported(dev))
+ return exynos_drm_free_dma(exynos_gem);
+
DRM_D
[PATCH 0/9] drm/exynos: update codes related with gem
Hi, This patchset is about gem codes update of exynos-drm. The first and second patches are cleanup to remove useless codes. The rest is to support cachable gem allocation. The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it doesn't give any effects. This patchset introduces new buffer allocation to use drm_gem_get/put_pages() instead of DMA mapping API. It will be used for the rest except allocation of physically continuous buffer on non-iommu, then exynos-drm can support cachable buffer of gem. Also it can support physically non-continuous buffer on non-iommu. EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care whether buffer is continuous physically if iommu is supported. This patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can mean that the buffer is continuous for device. There is no user API to control cache coherence for the cpu and device about cachable buffer. This patchset introduces two ioctls for cpu access of gem object from user. It will be synced properly in order for the cpu and device if buffer of gem object is cachable. Thanks. Joonyoung Shim (9): drm/exynos: eliminate useless codes of exynos_drm_gem.h drm/exynos: use directly DMA mapping APIs on g2d drm/exynos: remove using non-consistent DMA attribute drm/exynos: split buffer allocation using DMA mapping API on non-iommu drm/exynos: introduce buffer allocation using drm_gem_get/put_pages() drm/exynos: switch to new buffer allocation drm/exynos: always use EXYNOS_BO_CONTIG flag on iommu drm/exynos: use DMA_ERROR_CODE drm/exynos: add ioctls for cpu access of gem object from user drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 + drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 +--- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 288 ++ drivers/gpu/drm/exynos/exynos_drm_gem.h | 56 ++ include/uapi/drm/exynos_drm.h | 23 ++- 7 files changed, 225 insertions(+), 202 deletions(-) -- 1.9.1
[PATCH 1/9] drm/exynos: eliminate useless codes of exynos_drm_gem.h
This eliminates declaration of functions that is removed by the
commit 63540f01917c ("[media] drm/exynos: Convert
g2d_userptr_get_dma_addr() to use get_vaddr_frames()") and eliminate
vma_is_io() that isn't used anywhere now.
Also remove exynos_gem_get_pages() and exynos_drm_gem_userptr_ioctl(),
there is no body for them.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.h | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 0d0ab27b48fa..00223052b87b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -55,8 +55,6 @@ struct exynos_drm_gem {
struct sg_table *sgt;
};
-struct page **exynos_gem_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
-
/* destroy a buffer with gem object */
void exynos_drm_gem_destroy(struct exynos_drm_gem *exynos_gem);
@@ -95,10 +93,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp);
-/* map user space allocated by malloc to pages. */
-int exynos_drm_gem_userptr_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-
/* get buffer information to memory region allocated by gem. */
int exynos_drm_gem_get_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
@@ -127,28 +121,6 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
struct vm_fault *vmf);
/* set vm_flags and we can change the vm attribute to other one at here. */
int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-static inline int vma_is_io(struct vm_area_struct *vma)
-{
- return !!(vma->vm_flags & (VM_IO | VM_PFNMAP));
-}
-
-/* get a copy of a virtual memory region. */
-struct vm_area_struct *exynos_gem_get_vma(struct vm_area_struct *vma);
-
-/* release a userspace virtual memory area. */
-void exynos_gem_put_vma(struct vm_area_struct *vma);
-
-/* get pages from user space. */
-int exynos_gem_get_pages_from_userptr(unsigned long start,
- unsigned int npages,
- struct page **pages,
- struct vm_area_struct *vma);
-
-/* drop the reference to pages. */
-void exynos_gem_put_pages_to_userptr(struct page **pages,
- unsigned int npages,
- struct vm_area_struct *vma);
-
/* map sgt with dma region. */
int exynos_gem_map_sgt_with_dma(struct drm_device *drm_dev,
struct sg_table *sgt,
--
1.9.1
[PATCH 7/9] drm/exynos: always use EXYNOS_BO_CONTIG flag on iommu
It doesn't care whether memory is continuous physically if iommu is
supported but we will always use EXYNOS_BO_CONTIG flag on iommu, so it
can mean that the memory is continuous memory for device.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 ---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 31 ++
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
include/uapi/drm/exynos_drm.h | 5 -
5 files changed, 23 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index fcea28bdbc42..8fbae903c7ed 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -39,32 +39,6 @@ struct exynos_drm_fb {
struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
};
-static int check_fb_gem_memory_type(struct drm_device *drm_dev,
- struct exynos_drm_gem *exynos_gem)
-{
- unsigned int flags;
-
- /*
-* if exynos drm driver supports iommu then framebuffer can use
-* all the buffer types.
-*/
- if (is_drm_iommu_supported(drm_dev))
- return 0;
-
- flags = exynos_gem->flags;
-
- /*
-* without iommu support, not support physically non-continuous memory
-* for framebuffer.
-*/
- if (IS_NONCONTIG_BUFFER(flags)) {
- DRM_ERROR("cannot use this gem memory type for fb.\n");
- return -EINVAL;
- }
-
- return 0;
-}
-
static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
{
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
@@ -130,9 +104,11 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
for (i = 0; i < count; i++) {
- ret = check_fb_gem_memory_type(dev, exynos_gem[i]);
- if (ret < 0)
+ /* Not support physically non-continuous memory for FB */
+ if (exynos_gem[i]->flags & EXYNOS_BO_NONCONTIG) {
+ ret = -EINVAL;
goto err;
+ }
exynos_fb->exynos_gem[i] = exynos_gem[i];
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index f6118baa8e3e..fcbe43a580c1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -124,7 +124,6 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
struct exynos_drm_gem *exynos_gem;
struct drm_device *dev = helper->dev;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
- struct platform_device *pdev = dev->platformdev;
unsigned long size;
int ret;
@@ -142,18 +141,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- exynos_gem = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
- /*
-* If physically contiguous memory allocation fails and if IOMMU is
-* supported then try to get buffer from non physically contiguous
-* memory area.
-*/
- if (IS_ERR(exynos_gem) && is_drm_iommu_supported(dev)) {
- dev_warn(&pdev->dev, "contiguous FB allocation failed, falling
back to non-contiguous\n");
- exynos_gem = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG,
- size);
- }
-
+ exynos_gem = exynos_drm_gem_create(dev, 0, size);
if (IS_ERR(exynos_gem)) {
ret = PTR_ERR(exynos_gem);
goto out;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 163d113df1ab..96a69468283b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -135,6 +135,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
if (!is_drm_iommu_supported(dev)) {
if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
return exynos_drm_alloc_dma(exynos_gem);
+ } else {
+ exynos_gem->flags &= ~EXYNOS_BO_NONCONTIG;
}
ret = exynos_drm_get_pages(exynos_gem);
@@ -440,10 +442,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
args->pitch = args->width * ((args->bpp + 7) / 8);
args->size = args->pitch * args->height;
- if (is_drm_iommu_supported(dev))
- flags = EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC;
- else
- flags = EXYNOS_BO_CONTIG | EXYNOS_BO_WC;
+ flags = EXYNOS_BO_WC;
exynos_gem = exynos_drm_gem_create(dev, flags, args->size);
if (IS_ERR(exynos_gem)) {
@@ -597,6 +596,17 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
*dev,
[PATCH 3/9] drm/exynos: remove using non-consistent DMA attribute
DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it doesn't give any effects to use non-consistent DMA attribute. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 17a52f89a690..d5951f75c774 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -41,15 +41,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem) if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG)) dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, &exynos_gem->dma_attrs); - /* -* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping -* else cachable mapping. -*/ + /* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping */ if (exynos_gem->flags & EXYNOS_BO_WC || !(exynos_gem->flags & EXYNOS_BO_CACHABLE)) attr = DMA_ATTR_WRITE_COMBINE; - else - attr = DMA_ATTR_NON_CONSISTENT; dma_set_attr(attr, &exynos_gem->dma_attrs); dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &exynos_gem->dma_attrs); -- 1.9.1
[PATCH 5/9] drm/exynos: introduce buffer allocation using drm_gem_get/put_pages()
This introduces new functions to allocate/free buffer using
drm_gem_get/put_pages() instead of DMA mapping API. They also use sg
list to manage pages.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 48 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 +-
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 88196edd4ade..d982d46b04da 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -20,6 +20,54 @@
#include "exynos_drm_gem.h"
#include "exynos_drm_iommu.h"
+static int exynos_drm_get_pages(struct exynos_drm_gem *exynos_gem)
+{
+ struct drm_device *dev = exynos_gem->base.dev;
+ struct page **pages;
+ struct sg_table *sgt;
+ int ret;
+
+ pages = drm_gem_get_pages(&exynos_gem->base);
+ if (IS_ERR(pages))
+ return PTR_ERR(pages);
+
+ sgt = drm_prime_pages_to_sg(pages, exynos_gem->size >> PAGE_SHIFT);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err;
+ }
+
+ if (!dma_map_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL)) {
+ sg_free_table(sgt);
+ kfree(sgt);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ exynos_gem->dma_addr = sg_dma_address(sgt->sgl);
+ exynos_gem->sgt = sgt;
+ exynos_gem->pages = pages;
+
+ return 0;
+
+err:
+ drm_gem_put_pages(&exynos_gem->base, pages, false, false);
+ return ret;
+}
+
+static void exynos_drm_put_pages(struct exynos_drm_gem *exynos_gem)
+{
+ struct drm_device *dev = exynos_gem->base.dev;
+ struct sg_table *sgt = exynos_gem->sgt;
+
+ dma_unmap_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+
+ sg_free_table(sgt);
+ kfree(sgt);
+
+ drm_gem_put_pages(&exynos_gem->base, exynos_gem->pages, false, false);
+}
+
static int exynos_drm_alloc_dma(struct exynos_drm_gem *exynos_gem)
{
struct drm_device *dev = exynos_gem->base.dev;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index c1df26877b76..f47daec776e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -38,7 +38,7 @@
* - this address could be physical address without IOMMU and
* device address with IOMMU.
* @pages: Array of backing pages.
- * @sgt: Imported sg_table.
+ * @sgt: Converted sg_table of pages or imported sg_table.
*
* P.S. this object would be transferred to user as kms_bo.handle so
* user can access the buffer through kms_bo.handle.
--
1.9.1
[PATCH 2/9] drm/exynos: use directly DMA mapping APIs on g2d
There is no reason to be wapper functions to use DMA mapping APIs. We
can use directly DMA mapping APIs without locking and remove the wapper
functions.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 26 --
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10 --
3 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index c17efdb238a6..24d84a4298ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -365,6 +365,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct sg_table *sgt;
struct page **pages;
if (!obj)
@@ -382,8 +383,8 @@ static void g2d_userptr_put_dma_addr(struct drm_device
*drm_dev,
return;
out:
- exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
- DMA_BIDIRECTIONAL);
+ sgt = g2d_userptr->sgt;
+ dma_unmap_sg(drm_dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
pages = frame_vector_pages(g2d_userptr->vec);
if (!IS_ERR(pages)) {
@@ -500,9 +501,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
drm_device *drm_dev,
g2d_userptr->sgt = sgt;
- ret = exynos_gem_map_sgt_with_dma(drm_dev, g2d_userptr->sgt,
- DMA_BIDIRECTIONAL);
- if (ret < 0) {
+ if (!dma_map_sg(drm_dev->dev, sgt->sgl, sgt->nents,
+ DMA_BIDIRECTIONAL)) {
DRM_ERROR("failed to map sgt with dma region.\n");
goto err_sg_free_table;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 29f48756e72f..17a52f89a690 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -373,32 +373,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-int exynos_gem_map_sgt_with_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir)
-{
- int nents;
-
- mutex_lock(&drm_dev->struct_mutex);
-
- nents = dma_map_sg(drm_dev->dev, sgt->sgl, sgt->nents, dir);
- if (!nents) {
- DRM_ERROR("failed to map sgl with dma.\n");
- mutex_unlock(&drm_dev->struct_mutex);
- return nents;
- }
-
- mutex_unlock(&drm_dev->struct_mutex);
- return 0;
-}
-
-void exynos_gem_unmap_sgt_from_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir)
-{
- dma_unmap_sg(drm_dev->dev, sgt->sgl, sgt->nents, dir);
-}
-
void exynos_drm_gem_free_object(struct drm_gem_object *obj)
{
exynos_drm_gem_destroy(to_exynos_gem(obj));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 00223052b87b..c1df26877b76 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -121,16 +121,6 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
struct vm_fault *vmf);
/* set vm_flags and we can change the vm attribute to other one at here. */
int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-/* map sgt with dma region. */
-int exynos_gem_map_sgt_with_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir);
-
-/* unmap sgt from dma region. */
-void exynos_gem_unmap_sgt_from_dma(struct drm_device *drm_dev,
- struct sg_table *sgt,
- enum dma_data_direction dir);
-
/* low-level interface prime helpers */
struct sg_table *exynos_drm_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
--
1.9.1
[PATCH 9/9] drm/exynos: add ioctls for cpu access of gem object from user
This adds necessary two ioctls for cpu access of gem object from user.
It needs to be synced properly in order for the cpu and device if the
buffer of gem object is cachable.
- DRM_IOCTL_EXYNOS_GEM_CPU_PREP
Should be used explicitly before it will be cpu access of gem object
from user.
- DRM_IOCTL_EXYNOS_GEM_CPU_FINI
Should be used explicitly after it is finished cpu access of gem object
from user.
Signed-off-by: Joonyoung Shim
---
This is based on patch of Daniel dropping DRM_UNLOCKED flag on each
drivers[1] and patch that is droped DRM_UNLOCKED flag from my posted
patch[2].
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-September/075368.html
[2] http://www.spinics.net/lists/dri-devel/msg91465.html
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 48 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 14 ++
include/uapi/drm/exynos_drm.h | 18 -
4 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 74bf3afed519..f15945c1c01d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -408,6 +408,10 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CPU_PREP, exynos_drm_gem_cpu_prep_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CPU_FINI, exynos_drm_gem_cpu_fini_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 01c5e0854016..4907ad3994db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -321,6 +321,54 @@ int exynos_drm_gem_map_ioctl(struct drm_device *dev, void
*data,
&args->offset);
}
+int exynos_drm_gem_cpu_prep_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_exynos_gem_cpu_access *args = data;
+ struct drm_gem_object *obj;
+ struct exynos_drm_gem *exynos_gem;
+
+ obj = drm_gem_object_lookup(dev, file, args->handle);
+ if (!obj) {
+ DRM_ERROR("Failed to lookup gem object\n");
+ return -EINVAL;
+ }
+
+ exynos_gem = to_exynos_gem(obj);
+
+ if (exynos_gem->flags & EXYNOS_BO_CACHABLE)
+ dma_sync_sg_for_cpu(dev->dev, exynos_gem->sgt->sgl,
+ exynos_gem->sgt->nents, DMA_FROM_DEVICE);
+
+ drm_gem_object_unreference_unlocked(obj);
+
+ return 0;
+}
+
+int exynos_drm_gem_cpu_fini_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_exynos_gem_cpu_access *args = data;
+ struct drm_gem_object *obj;
+ struct exynos_drm_gem *exynos_gem;
+
+ obj = drm_gem_object_lookup(dev, file, args->handle);
+ if (!obj) {
+ DRM_ERROR("Failed to lookup gem object\n");
+ return -EINVAL;
+ }
+
+ exynos_gem = to_exynos_gem(obj);
+
+ if (exynos_gem->flags & EXYNOS_BO_CACHABLE)
+ dma_sync_sg_for_device(dev->dev, exynos_gem->sgt->sgl,
+ exynos_gem->sgt->nents, DMA_TO_DEVICE);
+
+ drm_gem_object_unreference_unlocked(obj);
+
+ return 0;
+}
+
dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index e9eb5631f322..d5aac38f455a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -74,6 +74,20 @@ int exynos_drm_gem_map_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
/*
+ * Should be used explicitly before it will be cpu access of gem object
+ * from user.
+ */
+int exynos_drm_gem_cpu_prep_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+/*
+ * Should be used explicitly after it is finished cpu access of gem
+ * object from user.
+ */
+int exynos_drm_gem_cpu_fini_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+/*
* get dma address from gem handle and this function could be used for
* other d
[PATCH 6/9] drm/exynos: switch to new buffer allocation
The buffer allocation using DMA mapping API can't support non-continuous
buffer on non-iommu and cachable buffer, so switch to new buffer
allocation using drm_gem_get/put_pages() and doesn't use DMA mapping API
for mmap except allocation of physically continuous buffer on non-iommu.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 90 +++--
1 file changed, 29 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index d982d46b04da..163d113df1ab 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -77,10 +77,7 @@ static int exynos_drm_alloc_dma(struct exynos_drm_gem
*exynos_gem)
init_dma_attrs(&exynos_gem->dma_attrs);
- if (exynos_gem->flags & EXYNOS_BO_WC ||
- !(exynos_gem->flags & EXYNOS_BO_CACHABLE))
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &exynos_gem->dma_attrs);
-
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &exynos_gem->dma_attrs);
dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &exynos_gem->dma_attrs);
nr_pages = exynos_gem->size >> PAGE_SHIFT;
@@ -128,51 +125,21 @@ static void exynos_drm_free_dma(struct exynos_drm_gem
*exynos_gem)
static int exynos_drm_alloc_buf(struct exynos_drm_gem *exynos_gem)
{
struct drm_device *dev = exynos_gem->base.dev;
- enum dma_attr attr;
- unsigned int nr_pages;
+ int ret;
if (exynos_gem->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}
- if (!is_drm_iommu_supported(dev))
- return exynos_drm_alloc_dma(exynos_gem);
-
- init_dma_attrs(&exynos_gem->dma_attrs);
-
- /*
-* if EXYNOS_BO_CONTIG, fully physically contiguous memory
-* region will be allocated else physically contiguous
-* as possible.
-*/
- if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
- dma_set_attr(DMA_ATTR_FORCE_CONTIGUOUS, &exynos_gem->dma_attrs);
-
- /* if EXYNOS_BO_WC or EXYNOS_BO_NONCACHABLE, writecombine mapping */
- if (exynos_gem->flags & EXYNOS_BO_WC ||
- !(exynos_gem->flags & EXYNOS_BO_CACHABLE))
- attr = DMA_ATTR_WRITE_COMBINE;
-
- dma_set_attr(attr, &exynos_gem->dma_attrs);
- dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &exynos_gem->dma_attrs);
-
- nr_pages = exynos_gem->size >> PAGE_SHIFT;
-
- exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
-&exynos_gem->dma_addr, GFP_KERNEL,
-&exynos_gem->dma_attrs);
- if (!exynos_gem->cookie) {
- DRM_ERROR("failed to allocate buffer.\n");
- if (exynos_gem->pages)
- drm_free_large(exynos_gem->pages);
- return -ENOMEM;
+ if (!is_drm_iommu_supported(dev)) {
+ if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
+ return exynos_drm_alloc_dma(exynos_gem);
}
- exynos_gem->pages = exynos_gem->cookie;
-
- DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
+ ret = exynos_drm_get_pages(exynos_gem);
+ if (ret < 0)
+ return ret;
return 0;
}
@@ -186,15 +153,12 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
*exynos_gem)
return;
}
- if (!is_drm_iommu_supported(dev))
- return exynos_drm_free_dma(exynos_gem);
-
- DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
- (unsigned long)exynos_gem->dma_addr, exynos_gem->size);
+ if (!is_drm_iommu_supported(dev)) {
+ if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
+ return exynos_drm_free_dma(exynos_gem);
+ }
- dma_free_attrs(dev->dev, exynos_gem->size, exynos_gem->cookie,
- (dma_addr_t)exynos_gem->dma_addr,
- &exynos_gem->dma_attrs);
+ exynos_drm_put_pages(exynos_gem);
}
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
@@ -400,8 +364,8 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-static int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem *exynos_gem,
- struct vm_area_struct *vma)
+static int exynos_drm_gem_mmap_dma(struct exynos_drm_gem *exynos_gem,
+ struct vm_area_struct *vma)
{
struct drm_device *drm_dev = exynos_gem->base.dev;
unsigned long vm_size;
@@ -579,6 +543,19 @@ int exynos_drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
DRM_DEBUG_KMS("flags = 0x%x\n", exynos_gem->flags);
+ if (!is_drm_iommu_supported(obj->dev)) {
+
[PATCH 8/9] drm/exynos: use DMA_ERROR_CODE
The dma_addr of gem will be DMA_ERROR_CODE if gem is created and
will keep DMA_ERROR_CODE if gem has EXYNOS_BO_NONCONTIG flag on
non-iommu.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 96a69468283b..01c5e0854016 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -44,7 +44,9 @@ static int exynos_drm_get_pages(struct exynos_drm_gem
*exynos_gem)
goto err;
}
- exynos_gem->dma_addr = sg_dma_address(sgt->sgl);
+ if (is_drm_iommu_supported(dev))
+ exynos_gem->dma_addr = sg_dma_address(sgt->sgl);
+
exynos_gem->sgt = sgt;
exynos_gem->pages = pages;
@@ -127,11 +129,6 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
struct drm_device *dev = exynos_gem->base.dev;
int ret;
- if (exynos_gem->dma_addr) {
- DRM_DEBUG_KMS("already allocated.\n");
- return 0;
- }
-
if (!is_drm_iommu_supported(dev)) {
if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
return exynos_drm_alloc_dma(exynos_gem);
@@ -150,11 +147,6 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
*exynos_gem)
{
struct drm_device *dev = exynos_gem->base.dev;
- if (!exynos_gem->dma_addr) {
- DRM_DEBUG_KMS("dma_addr is invalid.\n");
- return;
- }
-
if (!is_drm_iommu_supported(dev)) {
if (!(exynos_gem->flags & EXYNOS_BO_NONCONTIG))
return exynos_drm_free_dma(exynos_gem);
@@ -256,6 +248,8 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct
drm_device *dev,
return ERR_PTR(ret);
}
+ exynos_gem->dma_addr = DMA_ERROR_CODE;
+
DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
return exynos_gem;
@@ -594,18 +588,18 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
*dev,
return ERR_PTR(ret);
}
- exynos_gem->dma_addr = sg_dma_address(sgt->sgl);
-
/*
* Always physically continuous memory if sgt->nents is 1. It
* doesn't care if IOMMU is supported but EXYNOS_BO_NONCONTIG
* flag will be cleared. It will mean the memory is continuous
* for device. EXYNOS_BO_NONCONTIG flag will be set if not both.
*/
- if (sgt->nents == 1 || is_drm_iommu_supported(dev))
+ if (sgt->nents == 1 || is_drm_iommu_supported(dev)) {
exynos_gem->flags &= ~EXYNOS_BO_NONCONTIG;
- else
+ exynos_gem->dma_addr = sg_dma_address(sgt->sgl);
+ } else {
exynos_gem->flags |= EXYNOS_BO_NONCONTIG;
+ }
npages = exynos_gem->size >> PAGE_SHIFT;
exynos_gem->pages = drm_malloc_ab(npages, sizeof(struct page *));
--
1.9.1
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #29 from Barto --- like Roland said in comment#13 the bug could be in mesa source code, an incorrect initialization of llvm 3.7.0, it worked in 3.6.2, but perhaps in 3.7.0 the same code is not enough, it needs maybe more precise instructions in order to target exactly the CPU platform, to produce correct cpu opcodes, in dmesg I can see these messages when the SIGILL occurs : [13766.649327] traps: tunnel[4095] trap invalid opcode ip:7f68ce8d7183 sp:7fff6c078700 error:0 [35876.638782] traps: llvmpipe-1[8766] trap invalid opcode ip:f77271bd sp:f3536db0 error:0 [35876.638785] traps: llvmpipe-0[8765] trap invalid opcode ip:f77271bd sp:f3d37db0 error:0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151013/de0ed9a1/attachment.html>
[PATCH 5/9] drm/i915: Drop unnecessary #include
On Mon, Oct 12, 2015 at 10:57:43AM +0200, Lukas Wunner wrote:
> Commit 599bbb9de0fe ("drm/i915: i915 cannot provide switcher services.")
> removed all remaining vga_switcheroo symbols from intel_acpi.c but left
> the include. Drop it.
>
> Signed-off-by: Lukas Wunner
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_acpi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
> b/drivers/gpu/drm/i915/intel_acpi.c
> index d96eee1..68119b6 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -5,7 +5,6 @@
> */
> #include
> #include
> -#include
> #include
> #include "i915_drv.h"
>
> --
> 1.8.5.2 (Apple Git-48)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 5/9] drm/i915: Drop unnecessary #include
On Mon, 12 Oct 2015, Lukas Wunner wrote:
> Commit 599bbb9de0fe ("drm/i915: i915 cannot provide switcher services.")
> removed all remaining vga_switcheroo symbols from intel_acpi.c but left
> the include. Drop it.
>
> Signed-off-by: Lukas Wunner
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_acpi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c
> b/drivers/gpu/drm/i915/intel_acpi.c
> index d96eee1..68119b6 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -5,7 +5,6 @@
> */
> #include
> #include
> -#include
> #include
> #include "i915_drv.h"
>
> --
> 1.8.5.2 (Apple Git-48)
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 2/9] vga_switcheroo: Use VGA_SWITCHEROO_UNKNOWN_ID instead of -1
On Mon, Oct 12, 2015 at 12:09:53PM -0400, Alex Deucher wrote:
> On Fri, Aug 28, 2015 at 7:30 AM, Lukas Wunner wrote:
> > Signed-off-by: Lukas Wunner
> Reviewed-by: Alex Deucher
Merged the 3 cleanup patches to drm-misc.
-Daniel
>
> > ---
> > drivers/gpu/vga/vga_switcheroo.c | 17 +
> > include/linux/vga_switcheroo.h | 4
> > 2 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/vga/vga_switcheroo.c
> > b/drivers/gpu/vga/vga_switcheroo.c
> > index a7870d2..9896305 100644
> > --- a/drivers/gpu/vga/vga_switcheroo.c
> > +++ b/drivers/gpu/vga/vga_switcheroo.c
> > @@ -84,9 +84,9 @@
> > * @fb_info: framebuffer to which console is remapped on switching
> > * @pwr_state: current power state
> > * @ops: client callbacks
> > - * @id: client identifier, see enum vga_switcheroo_client_id.
> > - * Determining the id requires the handler, so GPUs are initially
> > - * assigned -1 and later given their true id in vga_switcheroo_enable()
> > + * @id: client identifier. Determining the id requires the handler,
> > + * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> > + * and later given their true id in vga_switcheroo_enable()
> > * @active: whether the outputs are currently switched to this client
> > * @driver_power_control: whether power state is controlled by the driver's
> > * runtime pm. If true, writing ON and OFF to the vga_switcheroo
> > debugfs
> > @@ -145,7 +145,8 @@ struct vgasr_priv {
> >
> > #define ID_BIT_AUDIO 0x100
> > #define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
> > -#define client_is_vga(c) ((c)->id == -1 || !client_is_audio(c))
> > +#define client_is_vga(c) ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
> > +!client_is_audio(c))
> > #define client_id(c) ((c)->id & ~ID_BIT_AUDIO)
> >
> > static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
> > @@ -173,7 +174,7 @@ static void vga_switcheroo_enable(void)
> > vgasr_priv.handler->init();
> >
> > list_for_each_entry(client, &vgasr_priv.clients, list) {
> > - if (client->id != -1)
> > + if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
> > continue;
> > ret = vgasr_priv.handler->get_client_id(client->pdev);
> > if (ret < 0)
> > @@ -277,7 +278,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
> >const struct vga_switcheroo_client_ops
> > *ops,
> >bool driver_power_control)
> > {
> > - return register_client(pdev, ops, -1,
> > + return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
> >pdev == vga_default_device(),
> >driver_power_control);
> > }
> > @@ -583,7 +584,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const
> > char __user *ubuf,
> > int ret;
> > bool delay = false, can_switch;
> > bool just_mux = false;
> > - int client_id = -1;
> > + int client_id = VGA_SWITCHEROO_UNKNOWN_ID;
> > struct vga_switcheroo_client *client = NULL;
> >
> > if (cnt > 63)
> > @@ -652,7 +653,7 @@ vga_switcheroo_debugfs_write(struct file *filp, const
> > char __user *ubuf,
> > client_id = VGA_SWITCHEROO_DIS;
> > }
> >
> > - if (client_id == -1)
> > + if (client_id == VGA_SWITCHEROO_UNKNOWN_ID)
> > goto out;
> > client = find_client_from_id(&vgasr_priv.clients, client_id);
> > if (!client)
> > diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> > index e636617..88909a8 100644
> > --- a/include/linux/vga_switcheroo.h
> > +++ b/include/linux/vga_switcheroo.h
> > @@ -59,6 +59,9 @@ enum vga_switcheroo_state {
> >
> > /**
> > * enum vga_switcheroo_client_id - client identifier
> > + * @VGA_SWITCHEROO_UNKNOWN_ID: initial identifier assigned to vga clients.
> > + * Determining the id requires the handler, so GPUs are given their
> > + * true id in a delayed fashion in vga_switcheroo_enable()
> > * @VGA_SWITCHEROO_IGD: integrated graphics device
> > * @VGA_SWITCHEROO_DIS: discrete graphics device
> > * @VGA_SWITCHEROO_MAX_CLIENTS: currently no more than two GPUs are
> > supported
> > @@ -66,6 +69,7 @@ enum vga_switcheroo_state {
> > * Client identifier. Audio clients use the same identifier & 0x100.
> > */
> > enum vga_switcheroo_client_id {
> > + VGA_SWITCHEROO_UNKNOWN_ID = -1,
> > VGA_SWITCHEROO_IGD,
> > VGA_SWITCHEROO_DIS,
> > VGA_SWITCHEROO_MAX_CLIENTS,
> > --
> > 1.8.5.2 (Apple Git-48)
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http:/
[PATCH v4 2/6] apple-gmux: Add switch_ddc support
On Mon, Oct 12, 2015 at 05:10:20PM -0400, Alex Deucher wrote:
> On Mon, Oct 12, 2015 at 5:07 PM, Alex Deucher
> wrote:
> > On Fri, Aug 14, 2015 at 12:18 PM, Lukas Wunner wrote:
> >> Originally by Seth Forshee , 2012-10-04:
> >> The gmux allows muxing the DDC independently from the display, so
> >> support this functionality. This will allow reading the EDID for the
> >> inactive GPU, fixing issues with machines that either don't have a
> >> VBT or have invalid mode data in the VBT.
> >>
> >> Modified by Lukas Wunner , 2015-10-07:
> >> Advertise ->switch_ddc handler callback only on the pre-retina
> >> Macbook Pro. The retina uses eDP and its mux is incapable of
> >> switching the AUX channel separately from the main link.
> >> It's an NXP CBTL06142 (alternate parts: TI HD3SS212,
> >> Pericom PPI3VDP12412).
> >>
> >> Sources:
> >> http://www.electronicproducts.com/-whatsinside_text-145.aspx
> >>
> >> http://slideshare.net/jjwu6266/apple-2012-wwdc-apple-macbook-pro-with-retina-display
> >>
> >> http://www.techrepublic.com/blog/cracking-open/teardown-shows-retina-macbook-pro-is-nearly-impossible-to-upgrade-difficult-to-work-on/
> >>
> >> Datasheets:
> >> http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> >> http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
> >> https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
> >>
> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
> >> Tested-by: Lukas Wunner
> >> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
> >>
> >> Cc: Seth Forshee
> >> Signed-off-by: Lukas Wunner
> >> ---
> >> drivers/platform/x86/apple-gmux.c | 21 +++--
> >> 1 file changed, 19 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/apple-gmux.c
> >> b/drivers/platform/x86/apple-gmux.c
> >> index 0dec3f5..78997b7 100644
> >> --- a/drivers/platform/x86/apple-gmux.c
> >> +++ b/drivers/platform/x86/apple-gmux.c
> >> @@ -276,11 +276,9 @@ static const struct backlight_ops gmux_bl_ops = {
> >> static int gmux_switchto(enum vga_switcheroo_client_id id)
> >> {
> >> if (id == VGA_SWITCHEROO_IGD) {
> >> - gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
> >> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
> >> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
> >> } else {
> >> - gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
> >> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
> >> gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
> >> }
> >
> > Won't this hunk break manual switching until the later patches land?
> > Seems like you might want to break this out as a separate patch later
> > in the series.
>
> Also. I'm not sure how the gmux works, but this might break ddc on
> external displays that are muxed.
Yeah I think the old desing was less surprising. And the
s/ddc_lock/hw_lock/ change would the make sense again.
Also when resending please also keep a per-patch changelog, not only in
the cover letter. Otherwise you have to jump back&forth all the time
between patches and cover letter. And the kerneldoc still seems to be
missing in this resend, so looks incomplete (or I'm missing something).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/vmwgfx: Fix kernel NULL pointer dereference on older hardware
The commit "drm/vmwgfx: Fix up user_dmabuf refcounting", while fixing a kernel crash introduced a NULL pointer dereference on older hardware. Fix this. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh Reviewed-by: Brian Paul --- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c index 64b5040..03f63c7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c @@ -657,7 +657,8 @@ static void vmw_user_surface_base_release(struct ttm_base_object **p_base) struct vmw_resource *res = &user_srf->srf.res; *p_base = NULL; - ttm_base_object_unref(&user_srf->backup_base); + if (user_srf->backup_base) + ttm_base_object_unref(&user_srf->backup_base); vmw_resource_unreference(&res); } -- 2.1.0
[Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> > > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> > > map it with memremap rather than the implied cache setting of
> > > acpi_os_ioremap().
> > >
> > > Cc: Daniel Vetter
> > > Cc: Jani Nikula
> > > Cc: intel-gfx at lists.freedesktop.org
> > > Cc: David Airlie
> > > Cc: dri-devel at lists.freedesktop.org
> > > Signed-off-by: Dan Williams
> >
> > Assuming you've run sparse over this to make sure you've caught them all,
> > and with the nit below addressed this is
> >
> > Reviewed-by: Daniel Vetter
>
> Indeed, re-running sparse again found a few conversions of ioread* I
> missed as well as moving the force casting out of validate_vbt() to
> find_vbt().
>
> > Feel free to pull v2 into whatever tree you think it's suitable for (but
> > you can also resend and I'll pick it up).
>
> Please pick up v2 below.
Queued for -next, thanks for the patch. Aside: Attached or separate mail
seems easier, somehow git apply-mbox can't auto-eat this for of patch.
-Daniel
>
> >
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > > b/drivers/gpu/drm/i915/intel_panel.c
> > > index e2ab3f6ed022..c8444d5f549f 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
> > >
> > > /* Assume that the BIOS does not lie through the OpRegion... */
> > > if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > > + return *(dev_priv->opregion.lid_state) & 0x1 ?
> >
> > () are redundant now here.
>
> Yup, fixed.
>
> 8<
> Subject: i915: switch from acpi_os_ioremap to memremap
>
> From: Dan Williams
>
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx at lists.freedesktop.org
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Dan Williams
> ---
> drivers/gpu/drm/i915/i915_debugfs.c |2 -
> drivers/gpu/drm/i915/i915_drv.h | 12 ++---
> drivers/gpu/drm/i915/intel_bios.c | 25 +-
> drivers/gpu/drm/i915/intel_opregion.c | 83
> -
> drivers/gpu/drm/i915/intel_panel.c|2 -
> 5 files changed, 62 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e3ec9049081f..15989cc16e92 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void
> *unused)
> goto out;
>
> if (opregion->header) {
> - memcpy_fromio(data, opregion->header, OPREGION_SIZE);
> + memcpy(data, opregion->header, OPREGION_SIZE);
> seq_write(m, data, OPREGION_SIZE);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e1db8de52851..d8684634a31d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -444,14 +444,14 @@ struct opregion_swsci;
> struct opregion_asle;
>
> struct intel_opregion {
> - struct opregion_header __iomem *header;
> - struct opregion_acpi __iomem *acpi;
> - struct opregion_swsci __iomem *swsci;
> + struct opregion_header *header;
> + struct opregion_acpi *acpi;
> + struct opregion_swsci *swsci;
> u32 swsci_gbda_sub_functions;
> u32 swsci_sbcb_sub_functions;
> - struct opregion_asle __iomem *asle;
> - void __iomem *vbt;
> - u32 __iomem *lid_state;
> + struct opregion_asle *asle;
> + void *vbt;
> + u32 *lid_state;
> struct work_struct asle_work;
> };
> #define OPREGION_SIZE(8*1024)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index c19e669ffe50..f6762a5faee8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1231,20 +1231,13 @@ static const struct dmi_system_id
> intel_no_opregion_vbt[] = {
> { }
> };
>
> -static const struct bdb_header *validate_vbt(const void __iomem *_base,
> +static const struct bdb_header *validate_vbt(const void *base,
>size_t size,
> - const void __iomem *_vbt,
> + const void *_vbt,
>const char *source)
> {
> - /*
> - * This is the one place where we explicitly discard the address space
> - * (__iomem) of the BIOS/VBT. (And this will cause a sp
[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]
On Mon, Oct 12, 2015 at 02:29:19PM +0200, Takashi Iwai wrote: > On Mon, 12 Oct 2015 09:04:20 +0200, > Daniel Vetter wrote: > > > > Another pile of regressions for Jairo to track ... > > > > On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote: > > > Hi, > > > > > > I noticed that a HSW laptop gets a few new warnings since 4.2-rc > > > kernels. One error messages pops at each boot time: > > > > > > Console: switching to colour dummy device 80x25 > > > [drm] Replacing VGA console driver > > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [drm] Driver supports precise vblank timestamp query. > > > vgaarb: device changed decodes: > > > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > > > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't > > > calculate constants, dotclock = 0! > > > > There's patches for this one already, but I accidentally applied them for > > -next, not -fixes. They should land for -rc6. > > Could you point commit ids? It was wishful thinking on my side, mixed them up with other patches. I think this one's still open :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 0/9] drm/exynos: update codes related with gem
On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote: > Hi, > > This patchset is about gem codes update of exynos-drm. > > The first and second patches are cleanup to remove useless codes. > The rest is to support cachable gem allocation. > > The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If > it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but > DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it > doesn't give any effects. > > This patchset introduces new buffer allocation to use > drm_gem_get/put_pages() instead of DMA mapping API. It will be used > for the rest except allocation of physically continuous buffer on > non-iommu, then exynos-drm can support cachable buffer of gem. Also it > can support physically non-continuous buffer on non-iommu. > > EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care > whether buffer is continuous physically if iommu is supported. This > patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can > mean that the buffer is continuous for device. > > There is no user API to control cache coherence for the cpu and device > about cachable buffer. This patchset introduces two ioctls for cpu > access of gem object from user. It will be synced properly in order for > the cpu and device if buffer of gem object is cachable. Out of curiosity, where's the userspace part for this work? Usually kernel abi extensions come with a link to the relevant branch for easier review. -Daniel > > Thanks. > > Joonyoung Shim (9): > drm/exynos: eliminate useless codes of exynos_drm_gem.h > drm/exynos: use directly DMA mapping APIs on g2d > drm/exynos: remove using non-consistent DMA attribute > drm/exynos: split buffer allocation using DMA mapping API on non-iommu > drm/exynos: introduce buffer allocation using drm_gem_get/put_pages() > drm/exynos: switch to new buffer allocation > drm/exynos: always use EXYNOS_BO_CONTIG flag on iommu > drm/exynos: use DMA_ERROR_CODE > drm/exynos: add ioctls for cpu access of gem object from user > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 + > drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 +--- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 288 > ++ > drivers/gpu/drm/exynos/exynos_drm_gem.h | 56 ++ > include/uapi/drm/exynos_drm.h | 23 ++- > 7 files changed, 225 insertions(+), 202 deletions(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 00/48] Etnaviv changes RFCv1->RFCv2
Am Mittwoch, den 30.09.2015, 09:53 +0200 schrieb Christian Gmeiner: > Hi Lucas, > > 2015-09-28 12:39 GMT+02:00 Lucas Stach : > > Hi Christian, > > > > Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner: > >> Hi Lucas. > >> > >> I think I have run into a cache flush / cache coherency issue. I will > >> try to reproduce this issue with a small example and will > >> keep you updated. > > > > What are the symptoms of the issue you are hitting? Maybe I can > > reproduce or see if I have an idea right away. > > > > With the help of the etnaviv_2d_test in my libdrm repo on github I was able > to test different bo flags. > > ETNA_BO_UNCACHED and ETNA_BO_CACHED are working as expected. > The rendering result looks as expected. If I try ETNA_BO_WC the rendering > result looks different for every run. > > debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 > Version: 1.0.0 > Name: etnaviv > Date: 20150910 > Description: etnaviv DRM > bo cpu prep: 0 > debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp > 052880d433e1bf495e268206addd4087 /tmp/etna.bmp > debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 > Version: 1.0.0 > Name: etnaviv > Date: 20150910 > Description: etnaviv DRM > bo cpu prep: 0 > debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp > f1a02a52d81c0b79b098877e6b7d9303 /tmp/etna.bmp > debian at cubox:~/libdrm$ tests/etnaviv/etnaviv_2d_test /dev/dri/card1 > Version: 1.0.0 > Name: etnaviv > Date: 20150910 > Description: etnaviv DRM > bo cpu prep: 0 > debian at cubox:~/libdrm$ md5sum /tmp/etna.bmp > de5a428eb1f6567849ef40a944a995b8 /tmp/etna.bmp > > etna_cmd_stream_finish() waits until the submitted command stream was > processed by the GPU. I tried to use etna_bo_cpu_prep(..) but I that did not > help. > > I am doing something wrong? Should this work in theory? > For the record: this is caused by the "shared attribute override enable" bit in the AUX_CTRL register of the PL310 cache controller not being set, which makes it non-compliant with the ARMv7 ARM specified behavior of conflicting memory aliases. The etnaviv kernel driver makes sure to clean the cachable alias before handing out the pages, but without this bit set the L2 controller will turn the userspace bufferable reads into "cachable, no allocate" which will lead to userspace hitting stale, non-evicted cache lines. This can be worked around by adding a "arm,shared-override" property to the L2 cache DT node. This will only work if the kernel is booted in secure state and will fault on a NS kernel. So this should be considered a hack and the bootloader/firmware should make sure to set this bit. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 0/9] drm/exynos: update codes related with gem
On 10/13/2015 05:27 PM, Daniel Vetter wrote: > On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote: >> Hi, >> >> This patchset is about gem codes update of exynos-drm. >> >> The first and second patches are cleanup to remove useless codes. >> The rest is to support cachable gem allocation. >> >> The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If >> it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but >> DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it >> doesn't give any effects. >> >> This patchset introduces new buffer allocation to use >> drm_gem_get/put_pages() instead of DMA mapping API. It will be used >> for the rest except allocation of physically continuous buffer on >> non-iommu, then exynos-drm can support cachable buffer of gem. Also it >> can support physically non-continuous buffer on non-iommu. >> >> EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care >> whether buffer is continuous physically if iommu is supported. This >> patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can >> mean that the buffer is continuous for device. >> >> There is no user API to control cache coherence for the cpu and device >> about cachable buffer. This patchset introduces two ioctls for cpu >> access of gem object from user. It will be synced properly in order for >> the cpu and device if buffer of gem object is cachable. > > Out of curiosity, where's the userspace part for this work? Usually kernel > abi extensions come with a link to the relevant branch for easier review. > -Daniel > Right, thanks for point. I just modified a little bit exynos_fimg2d_test and exynos parts of libdrm to test them as workaround. I will expose it. Thanks. >> >> Thanks. >> >> Joonyoung Shim (9): >> drm/exynos: eliminate useless codes of exynos_drm_gem.h >> drm/exynos: use directly DMA mapping APIs on g2d >> drm/exynos: remove using non-consistent DMA attribute >> drm/exynos: split buffer allocation using DMA mapping API on non-iommu >> drm/exynos: introduce buffer allocation using drm_gem_get/put_pages() >> drm/exynos: switch to new buffer allocation >> drm/exynos: always use EXYNOS_BO_CONTIG flag on iommu >> drm/exynos: use DMA_ERROR_CODE >> drm/exynos: add ioctls for cpu access of gem object from user >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 + >> drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 +--- >> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +- >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 288 >> ++ >> drivers/gpu/drm/exynos/exynos_drm_gem.h | 56 ++ >> include/uapi/drm/exynos_drm.h | 23 ++- >> 7 files changed, 225 insertions(+), 202 deletions(-) >> >> -- >> 1.9.1 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]
On Tue, Oct 13, 2015 at 10:24:58AM +0200, Daniel Vetter wrote: > On Mon, Oct 12, 2015 at 02:29:19PM +0200, Takashi Iwai wrote: > > On Mon, 12 Oct 2015 09:04:20 +0200, > > Daniel Vetter wrote: > > > > > > Another pile of regressions for Jairo to track ... > > > > > > On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote: > > > > Hi, > > > > > > > > I noticed that a HSW laptop gets a few new warnings since 4.2-rc > > > > kernels. One error messages pops at each boot time: > > > > > > > > Console: switching to colour dummy device 80x25 > > > > [drm] Replacing VGA console driver > > > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > > [drm] Driver supports precise vblank timestamp query. > > > > vgaarb: device changed decodes: > > > > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem > > > > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't > > > > calculate constants, dotclock = 0! > > > > > > There's patches for this one already, but I accidentally applied them for > > > -next, not -fixes. They should land for -rc6. > > > > Could you point commit ids? > > It was wishful thinking on my side, mixed them up with other patches. I > think this one's still open :( 7f4c628 drm/i915: Assign hwmode after encoder state readout 0f64614 drm/i915: Fix clock readout when pipes are enabled w/o ports not enough? -- Ville Syrjälä Intel OTC
[PATCH 0/9] drm/exynos: update codes related with gem
On 10/13/2015 05:37 PM, Joonyoung Shim wrote: > On 10/13/2015 05:27 PM, Daniel Vetter wrote: >> On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote: >>> Hi, >>> >>> This patchset is about gem codes update of exynos-drm. >>> >>> The first and second patches are cleanup to remove useless codes. >>> The rest is to support cachable gem allocation. >>> >>> The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If >>> it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but >>> DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it >>> doesn't give any effects. >>> >>> This patchset introduces new buffer allocation to use >>> drm_gem_get/put_pages() instead of DMA mapping API. It will be used >>> for the rest except allocation of physically continuous buffer on >>> non-iommu, then exynos-drm can support cachable buffer of gem. Also it >>> can support physically non-continuous buffer on non-iommu. >>> >>> EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care >>> whether buffer is continuous physically if iommu is supported. This >>> patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can >>> mean that the buffer is continuous for device. >>> >>> There is no user API to control cache coherence for the cpu and device >>> about cachable buffer. This patchset introduces two ioctls for cpu >>> access of gem object from user. It will be synced properly in order for >>> the cpu and device if buffer of gem object is cachable. >> >> Out of curiosity, where's the userspace part for this work? Usually kernel >> abi extensions come with a link to the relevant branch for easier review. >> -Daniel >> > > Right, thanks for point. > > I just modified a little bit exynos_fimg2d_test and exynos parts of > libdrm to test them as workaround. I will expose it. > Please refer follows. https://github.com/dofmind/libdrm/commits/exynos If fimd2d test program uses cachable gem, it will show cache coherency problem, so it adds to use new ioctls to keep cache coherency. Thanks. > Thanks. > >>> >>> Thanks. >>> >>> Joonyoung Shim (9): >>> drm/exynos: eliminate useless codes of exynos_drm_gem.h >>> drm/exynos: use directly DMA mapping APIs on g2d >>> drm/exynos: remove using non-consistent DMA attribute >>> drm/exynos: split buffer allocation using DMA mapping API on non-iommu >>> drm/exynos: introduce buffer allocation using drm_gem_get/put_pages() >>> drm/exynos: switch to new buffer allocation >>> drm/exynos: always use EXYNOS_BO_CONTIG flag on iommu >>> drm/exynos: use DMA_ERROR_CODE >>> drm/exynos: add ioctls for cpu access of gem object from user >>> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 + >>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 32 +--- >>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +- >>> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 +- >>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 288 >>> ++ >>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 56 ++ >>> include/uapi/drm/exynos_drm.h | 23 ++- >>> 7 files changed, 225 insertions(+), 202 deletions(-) >>> >>> -- >>> 1.9.1 >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH v2] MAINTAINERS: add a maintainer for the atmel-hlcdc DRM driver
Add myself as the maintainer of the atmel-hlcdc DRM driver. Signed-off-by: Boris Brezillon Acked-by: Nicolas Ferre --- Changes since v1: - Fix the MAINTAINER entry title --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 797236b..670ff22 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3591,6 +3591,13 @@ F: drivers/gpu/drm/i915/ F: include/drm/i915* F: include/uapi/drm/i915* +DRM DRIVERS FOR ATMEL HLCDC +M: Boris Brezillon +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/atmel-hlcdc/ +F: Documentation/devicetree/bindings/drm/atmel/ + DRM DRIVERS FOR EXYNOS M: Inki Dae M: Joonyoung Shim -- 2.1.4
[PATCH] drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
Exynos GEM objects contains an array of pointers to the pages, which the
allocated buffer consists of. Till now the code used some hacks (like
relying on DMA-mapping internal structures or using ARM-specific
dma_to_pfn helper) to build this array. This patch fixes this by adding
proper call to dma_get_sgtable_attrs() and using the acquired scatter-list
to construct needed array. This approach is more portable (work also for
ARM64) and finally fixes the layering violation that was present in this
code.
Signed-off-by: Marek Szyprowski
---
Patch is based on exynos-drm-next branch.
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 60 +++--
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 29f48756e72f..e998a64a3dd0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -25,6 +25,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
struct drm_device *dev = exynos_gem->base.dev;
enum dma_attr attr;
unsigned int nr_pages;
+ struct sg_table sgt;
+ struct scatterlist *s;
+ int ret = -ENOMEM;
+ int i, j;
if (exynos_gem->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
@@ -56,13 +60,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
nr_pages = exynos_gem->size >> PAGE_SHIFT;
- if (!is_drm_iommu_supported(dev)) {
- exynos_gem->pages = drm_calloc_large(nr_pages,
-sizeof(struct page *));
- if (!exynos_gem->pages) {
- DRM_ERROR("failed to allocate pages.\n");
- return -ENOMEM;
- }
+ exynos_gem->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
+ if (!exynos_gem->pages) {
+ DRM_ERROR("failed to allocate pages.\n");
+ return -ENOMEM;
}
exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
@@ -70,30 +71,40 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
&exynos_gem->dma_attrs);
if (!exynos_gem->cookie) {
DRM_ERROR("failed to allocate buffer.\n");
- if (exynos_gem->pages)
- drm_free_large(exynos_gem->pages);
- return -ENOMEM;
+ goto err_free;
}
- if (exynos_gem->pages) {
- dma_addr_t start_addr;
- unsigned int i = 0;
-
- start_addr = exynos_gem->dma_addr;
- while (i < nr_pages) {
- exynos_gem->pages[i] =
- pfn_to_page(dma_to_pfn(dev->dev, start_addr));
- start_addr += PAGE_SIZE;
- i++;
- }
- } else {
- exynos_gem->pages = exynos_gem->cookie;
+ ret = dma_get_sgtable_attrs(dev->dev, &sgt, exynos_gem->cookie,
+ exynos_gem->dma_addr, exynos_gem->size,
+ &exynos_gem->dma_attrs);
+ if (ret < 0) {
+ DRM_ERROR("failed to get sgtable.\n");
+ goto err_dma_free;
+ }
+
+ j = 0;
+ for_each_sg(sgt.sgl, s, sgt.orig_nents, i) {
+ int size = s->length >> PAGE_SHIFT;
+ struct page *page = sg_page(s);
+
+ while (size-- > 0)
+ exynos_gem->pages[j++] = page++;
}
+ sg_free_table(&sgt);
+
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)exynos_gem->dma_addr, exynos_gem->size);
return 0;
+
+err_dma_free:
+ dma_free_attrs(dev->dev, exynos_gem->size, exynos_gem->cookie,
+ exynos_gem->dma_addr, &exynos_gem->dma_attrs);
+err_free:
+ drm_free_large(exynos_gem->pages);
+
+ return ret;
}
static void exynos_drm_free_buf(struct exynos_drm_gem *exynos_gem)
@@ -112,8 +123,7 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
*exynos_gem)
(dma_addr_t)exynos_gem->dma_addr,
&exynos_gem->dma_attrs);
- if (!is_drm_iommu_supported(dev))
- drm_free_large(exynos_gem->pages);
+ drm_free_large(exynos_gem->pages);
}
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
--
1.9.2
[PATCH 21/22] drm/i915: BDW: Pipe level degamma correction
Thanks for the review Rob.
Regards
Shashank
On 10/12/2015 11:38 PM, Rob Bradford wrote:
> On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
>> BDW/SKL/BXT supports Degamma color correction feature, which
>> linearizes the non-linearity due to gamma encoded color values.
>> This will be applied before Color Transformation.
>>
>> This patch does the following:
>> 1. Adds the core function to program DeGamma correction values for
>> BDW/SKL/BXT platform
>> 2. Adds DeGamma correction macros/defines
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Kausal Malladi
>> ---
>> drivers/gpu/drm/i915/intel_color_manager.c | 59
>> ++
>> 1 file changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> index 74f8fc3..e659382 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev,
>> struct drm_property_blob *blob,
>> return 0;
>> }
>>
>> +static int bdw_set_degamma(struct drm_device *dev,
>> +struct drm_property_blob *blob, struct drm_crtc *crtc)
>> +{
>> +enum pipe pipe;
>> +int num_samples, length;
>> +u32 index, mode;
>> +u32 pal_prec_index, pal_prec_data;
>> +struct drm_palette *degamma_data;
>> +struct drm_crtc_state *state = crtc->state;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct drm_r32g32b32 *correction_values = NULL;
>> +
>> +if (WARN_ON(!blob))
>> +return -EINVAL;
>> +
>> +degamma_data = (struct drm_palette *)blob->data;
>> +pipe = to_intel_crtc(crtc)->pipe;
>> +num_samples = degamma_data->num_samples;
>> +
>> +if (num_samples == GAMMA_DISABLE_VALS) {
>> +/* Disable degamma on Pipe */
>> +mode = I915_READ(GAMMA_MODE(pipe)) &
>> ~GAMMA_MODE_MODE_MASK;
>> +I915_WRITE(GAMMA_MODE(pipe), mode |
>> GAMMA_MODE_MODE_8BIT);
>
> When you turn off gamma you call bdw_reset_gamma() should you do the
> same for degamma?
>
No, we tested this part, its not required, its only required for 12 bit
gamma.
>> +
>> +state->palette_before_ctm_blob = NULL;
>> +DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
>> +pipe_name(pipe));
>> +return 0;
>> +}
>> +
>> +if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
>> +DRM_ERROR("Invalid number of samples\n");
>> +return -EINVAL;
>> +}
>> +
>> +length = num_samples * sizeof(struct drm_r32g32b32);
>
> Uh, you calculate this length and don't use it anywhere? Was your
> intention to check the blob length? And the length check should be in
> the generic DRM code anyway...
>
Yes, this was left over from the previous patch set, will remove this.
> I think it was suggested in the past that the number of samples could
> be derived from the length of the data allowing the removal of the
> struct member.
>
Right now, its better to have the no of samples coming from userspace.
As the platform is under development, its good to have this control
available so that userspace will be clear on what it wants to do, I have
added this in my to do list, when we are sure that we dont need it, we
will remove and optimize it.
>> +mode = I915_READ(GAMMA_MODE(pipe));
>
> Move this closer to where you use it?
>
Agree.
>> +pal_prec_index = _PREC_PAL_INDEX(pipe);
>> +pal_prec_data = _PREC_PAL_DATA(pipe);
>> +
>> +correction_values = (struct drm_r32g32b32 *)°amma_data
>> ->lut;
>
> Why do you need this cast?
>
Not required, agree, will remove.
>> +index = I915_READ(pal_prec_index);
>> +index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
>> +I915_WRITE(pal_prec_index, index);
>> +
>> +bdw_write_10bit_gamma_precision(dev, correction_values,
>> +pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
>> +
>> +/* Enable DeGamma on Pipe */
>> +mode &= ~GAMMA_MODE_MODE_MASK;
>> +I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
>> +DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
>
> Choose your capitalisation DeGamma or degamma. Pick one and use it
> consistently to make it easier to grep through the code.
>
Will stick with degamma now.
> It also looks like you should check if the gamma mode is not something
> other than split / off. Otherwise strange things could happen.
> Similarly in the gamma code you shouldn't be able to program something
> other than split if you have a degamma mode set.
>
We discussed this in the design phase itself. This decision has to go to
userspcae only, whom should know, what its doing. There are various
permutation and combinations possbile which make kernel code unnecessary
complex. Kernel will just follow what is being requested from usp.
>> +pipe_name(pipe));
>> +
>> +return 0;
>> +}
>> +
>> static s16 chv_prepare_csc_coeff(s64 cs
[PATCH] drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
Hi Marek,
On 10/13/2015 07:22 PM, Marek Szyprowski wrote:
> Exynos GEM objects contains an array of pointers to the pages, which the
> allocated buffer consists of. Till now the code used some hacks (like
> relying on DMA-mapping internal structures or using ARM-specific
> dma_to_pfn helper) to build this array. This patch fixes this by adding
> proper call to dma_get_sgtable_attrs() and using the acquired scatter-list
> to construct needed array. This approach is more portable (work also for
> ARM64) and finally fixes the layering violation that was present in this
> code.
I also sent related patches to update codes of Exynos GEM object and i
think this can be applied easily on my patchset or i will be able to
rebase my patchset on your patch.
>
> Signed-off-by: Marek Szyprowski
> ---
> Patch is based on exynos-drm-next branch.
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 60
> +++--
> 1 file changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 29f48756e72f..e998a64a3dd0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -25,6 +25,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
> *exynos_gem)
> struct drm_device *dev = exynos_gem->base.dev;
> enum dma_attr attr;
> unsigned int nr_pages;
> + struct sg_table sgt;
> + struct scatterlist *s;
> + int ret = -ENOMEM;
> + int i, j;
>
> if (exynos_gem->dma_addr) {
> DRM_DEBUG_KMS("already allocated.\n");
> @@ -56,13 +60,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
> *exynos_gem)
>
> nr_pages = exynos_gem->size >> PAGE_SHIFT;
>
> - if (!is_drm_iommu_supported(dev)) {
> - exynos_gem->pages = drm_calloc_large(nr_pages,
> - sizeof(struct page *));
> - if (!exynos_gem->pages) {
> - DRM_ERROR("failed to allocate pages.\n");
> - return -ENOMEM;
> - }
> + exynos_gem->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
> + if (!exynos_gem->pages) {
> + DRM_ERROR("failed to allocate pages.\n");
> + return -ENOMEM;
> }
>
> exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
> @@ -70,30 +71,40 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
> *exynos_gem)
>&exynos_gem->dma_attrs);
> if (!exynos_gem->cookie) {
> DRM_ERROR("failed to allocate buffer.\n");
> - if (exynos_gem->pages)
> - drm_free_large(exynos_gem->pages);
> - return -ENOMEM;
> + goto err_free;
> }
>
> - if (exynos_gem->pages) {
> - dma_addr_t start_addr;
> - unsigned int i = 0;
> -
> - start_addr = exynos_gem->dma_addr;
> - while (i < nr_pages) {
> - exynos_gem->pages[i] =
> - pfn_to_page(dma_to_pfn(dev->dev, start_addr));
> - start_addr += PAGE_SIZE;
> - i++;
> - }
> - } else {
> - exynos_gem->pages = exynos_gem->cookie;
> + ret = dma_get_sgtable_attrs(dev->dev, &sgt, exynos_gem->cookie,
> + exynos_gem->dma_addr, exynos_gem->size,
> + &exynos_gem->dma_attrs);
> + if (ret < 0) {
> + DRM_ERROR("failed to get sgtable.\n");
> + goto err_dma_free;
> + }
> +
> + j = 0;
> + for_each_sg(sgt.sgl, s, sgt.orig_nents, i) {
> + int size = s->length >> PAGE_SHIFT;
> + struct page *page = sg_page(s);
> +
> + while (size-- > 0)
> + exynos_gem->pages[j++] = page++;
> }
drm_prime_sg_to_page_addr_arrays() will do same operation.
Thanks.
[PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
Regards
Shashank
On 10/12/2015 11:39 PM, Rob Bradford wrote:
> On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
>> BDW/SKL/BXT platforms support various Gamma correction modes
>> which are:
>> 1. Legacy 8-bit mode
>> 2. 10-bit Split Gamma mode
>> 3. 12-bit mode
>>
>> This patch does the following:
>> 1. Adds the core function to program Gamma correction values
>> for BDW/SKL/BXT platforms
>> 2. Adds Gamma correction macros/defines
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Kausal Malladi
>> ---
>> drivers/gpu/drm/i915/i915_reg.h| 25 ++-
>> drivers/gpu/drm/i915/intel_color_manager.c | 248
>> +
>> drivers/gpu/drm/i915/intel_color_manager.h | 6 +
>> 3 files changed, 277 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 5825ab2..ed50f75 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -5647,11 +5647,15 @@ enum skl_disp_power_wells {
>> /* legacy palette */
>> #define _LGC_PALETTE_A 0x4a000
>> #define _LGC_PALETTE_B 0x4a800
>> -#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A,
>> _LGC_PALETTE_B) + (i) * 4)
>> +#define _LGC_PALETTE_C 0x4b000
>> +#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A,
>> _LGC_PALETTE_B, \
>> + _LGC_PALETTE_C) + (i) * 4)
>>
>> #define _GAMMA_MODE_A 0x4a480
>> #define _GAMMA_MODE_B 0x4ac80
>> -#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
>> +#define _GAMMA_MODE_C 0x4b480
>> +#define GAMMA_MODE(pipe) \
>> +_PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
>> #define GAMMA_MODE_MODE_MASK (3 << 0)
>> #define GAMMA_MODE_MODE_8BIT (0 << 0)
>> #define GAMMA_MODE_MODE_10BIT (1 << 0)
>> @@ -8062,6 +8066,23 @@ enum skl_disp_power_wells {
>> #define _PIPE_CSC_BASE(pipe) \
>> (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
>>
>> +/* BDW gamma correction */
>> +#define PAL_PREC_INDEX_A 0x4A400
>> +#define PAL_PREC_INDEX_B 0x4AC00
>> +#define PAL_PREC_INDEX_C 0x4B400
>> +#define PAL_PREC_DATA_A0x4A404
>> +#define PAL_PREC_DATA_B0x4AC04
>> +#define PAL_PREC_DATA_C0x4B404
>> +#define PAL_PREC_GCMAX_A0x4A410
>> +#define PAL_PREC_GCMAX_B0x4AC10
>> +#define PAL_PREC_GCMAX_C0x4B410
>> +
>> +#define _PREC_PAL_INDEX(pipe) \
>> +(_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B,
>> PAL_PREC_INDEX_C))
>> +#define _PREC_PAL_DATA(pipe) \
>> +(_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B,
>> PAL_PREC_DATA_C))
>> +#define _PREC_PAL_GCMAX(pipe) \
>> +(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
>> PAL_PREC_GCMAX_C))
>>
>>
>> #endif /* _I915_REG_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> index d5315b2..74f8fc3 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -26,6 +26,252 @@
>>*/
>>
>> #include "intel_color_manager.h"
>> +static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
>> +struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
>> +u32 no_of_coeff)
>> +{
>> +u16 blue_fract, green_fract, red_fract;
>> +u32 word = 0;
>> +u32 count = 0;
>> +u32 blue, green, red;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +
>> +while (count < no_of_coeff) {
>> +
>> +blue = correction_values[count].b32;
>> +green = correction_values[count].g32;
>> +red = correction_values[count].r32;
>> +
>> +/*
>> +* Maximum possible gamma correction value supported
>> +* for BDW is 0x, so clip the values
>> accordingly
>> +*/
>
> I think you mean clamp not clip.
Yes, will fix this.
>
>> +if (blue >= BDW_MAX_GAMMA)
>> +blue = BDW_MAX_GAMMA;
>> +if (green >= BDW_MAX_GAMMA)
>> +green = BDW_MAX_GAMMA;
>> +if (red >= BDW_MAX_GAMMA)
>> +red = BDW_MAX_GAMMA;
>
> So this handles the issue that was raised before that 1.0 in 8.24
> should map to 1023.
Yes.
>
>> +
>> +/*
>> +* Gamma correction values are sent in 8.24 format
>> +* with 8 int and 24 fraction bits. BDW 10 bit gamma
>> +* unit expects correction registers to be programmed
>> in
>> +* 0.10 format, with 0 int and 16 fraction bits. So
>> take
>> +* MSB 10 bit values(bits 23-14) from the fraction
>> part and
>> +* prepare the correction registers.
>> +*/
>> +blue_fract = GET_BITS(b
[PATCH 20/22] drm/i915: BDW: Load degamma correction values
Regards
Shashank
On 10/12/2015 11:43 PM, Rob Bradford wrote:
> On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:
>> I915 color manager registers pipe degamma correction as palette
>> correction before CTM, DRM property.
>>
>> This patch adds the no of coefficients(65) for degamma correction
>> as "num_samples_before_ctm" parameter in device info structures,
>> for BDW and higher platforms.
>
> Did you copy and paste this from the CHV version? The only constant you
> add for degamma here is 512?
Oops, side effects of too many code-refactoring without proper sleep :)
will fix this.
>
> Rob
>
>>
>> Signed-off-by: Shashank Sharma
>> Signed-off-by: Kausal Malladi
>> ---
>> drivers/gpu/drm/i915/i915_drv.c| 7 +++
>> drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 4fa046f..ebf4910 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -303,6 +303,7 @@ static const struct intel_device_info
>> intel_broadwell_d_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -316,6 +317,7 @@ static const struct intel_device_info
>> intel_broadwell_m_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -329,6 +331,7 @@ static const struct intel_device_info
>> intel_broadwell_gt3d_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
>> | BSD2_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -342,6 +345,7 @@ static const struct intel_device_info
>> intel_broadwell_gt3m_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
>> | BSD2_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -368,6 +372,7 @@ static const struct intel_device_info
>> intel_skylake_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -382,6 +387,7 @@ static const struct intel_device_info
>> intel_skylake_gt3_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
>> | BSD2_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .has_llc = 1,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> @@ -396,6 +402,7 @@ static const struct intel_device_info
>> intel_broxton_info = {
>> .need_gfx_hws = 1, .has_hotplug = 1,
>> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>> .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
>> +.num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
>> .num_pipes = 3,
>> .has_ddi = 1,
>> .has_fpga_dbg = 1,
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
>> b/drivers/gpu/drm/i915/intel_color_manager.h
>> index 6c7cb08..e0c486e 100644
>> --- a/drivers/gpu/drm/i915/intel_color_manager.h
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.h
>> @@ -98,3 +98,6 @@
>> #define BDW_MAX_GAMMA ((1 << 24) - 1)
>> #define BDW_INDEX_AUTO_INCREMENT (1 << 15)
>> #define BDW_INDEX_SPLIT_MODE (1 << 31)
>> +
>> +/* Degamma on BDW */
>> +#define BDW_DEGAMMA_MAX_VALS 512
[PATCH v2] drm/exynos/gem: remove DMA-mapping hacks used for constructing page array
Exynos GEM objects contains an array of pointers to the pages, which the
allocated buffer consists of. Till now the code used some hacks (like
relying on DMA-mapping internal structures or using ARM-specific
dma_to_pfn helper) to build this array. This patch fixes this by adding
proper call to dma_get_sgtable_attrs() and using the acquired scatter-list
to construct needed array. This approach is more portable (work also for
ARM64) and finally fixes the layering violation that was present in this
code.
Signed-off-by: Marek Szyprowski
---
Patch is based on exynos-drm-next branch.
v2: use drm_prime_sg_to_page_addr_arrays()
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 58 +++--
1 file changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 29f48756e72f..183aa4a74686 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -25,6 +25,8 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
struct drm_device *dev = exynos_gem->base.dev;
enum dma_attr attr;
unsigned int nr_pages;
+ struct sg_table sgt;
+ int ret = -ENOMEM;
if (exynos_gem->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
@@ -56,13 +58,10 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
nr_pages = exynos_gem->size >> PAGE_SHIFT;
- if (!is_drm_iommu_supported(dev)) {
- exynos_gem->pages = drm_calloc_large(nr_pages,
-sizeof(struct page *));
- if (!exynos_gem->pages) {
- DRM_ERROR("failed to allocate pages.\n");
- return -ENOMEM;
- }
+ exynos_gem->pages = drm_calloc_large(nr_pages, sizeof(struct page *));
+ if (!exynos_gem->pages) {
+ DRM_ERROR("failed to allocate pages.\n");
+ return -ENOMEM;
}
exynos_gem->cookie = dma_alloc_attrs(dev->dev, exynos_gem->size,
@@ -70,30 +69,40 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem
*exynos_gem)
&exynos_gem->dma_attrs);
if (!exynos_gem->cookie) {
DRM_ERROR("failed to allocate buffer.\n");
- if (exynos_gem->pages)
- drm_free_large(exynos_gem->pages);
- return -ENOMEM;
+ goto err_free;
}
- if (exynos_gem->pages) {
- dma_addr_t start_addr;
- unsigned int i = 0;
-
- start_addr = exynos_gem->dma_addr;
- while (i < nr_pages) {
- exynos_gem->pages[i] =
- pfn_to_page(dma_to_pfn(dev->dev, start_addr));
- start_addr += PAGE_SIZE;
- i++;
- }
- } else {
- exynos_gem->pages = exynos_gem->cookie;
+ ret = dma_get_sgtable_attrs(dev->dev, &sgt, exynos_gem->cookie,
+ exynos_gem->dma_addr, exynos_gem->size,
+ &exynos_gem->dma_attrs);
+ if (ret < 0) {
+ DRM_ERROR("failed to get sgtable.\n");
+ goto err_dma_free;
+ }
+
+ if (drm_prime_sg_to_page_addr_arrays(&sgt, exynos_gem->pages, NULL,
+nr_pages)) {
+ DRM_ERROR("invalid sgtable.\n");
+ ret = -EINVAL;
+ goto err_sgt_free;
}
+ sg_free_table(&sgt);
+
DRM_DEBUG_KMS("dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)exynos_gem->dma_addr, exynos_gem->size);
return 0;
+
+err_sgt_free:
+ sg_free_table(&sgt);
+err_dma_free:
+ dma_free_attrs(dev->dev, exynos_gem->size, exynos_gem->cookie,
+ exynos_gem->dma_addr, &exynos_gem->dma_attrs);
+err_free:
+ drm_free_large(exynos_gem->pages);
+
+ return ret;
}
static void exynos_drm_free_buf(struct exynos_drm_gem *exynos_gem)
@@ -112,8 +121,7 @@ static void exynos_drm_free_buf(struct exynos_drm_gem
*exynos_gem)
(dma_addr_t)exynos_gem->dma_addr,
&exynos_gem->dma_attrs);
- if (!is_drm_iommu_supported(dev))
- drm_free_large(exynos_gem->pages);
+ drm_free_large(exynos_gem->pages);
}
static int exynos_drm_gem_handle_create(struct drm_gem_object *obj,
--
1.9.2
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
On 10/6/2015 2:12 PM, Michel Thierry wrote: > On 10/5/2015 7:06 PM, Kristian Høgsberg wrote: >> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry >> wrote: >>> On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote: On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote: > > Gen8+ supports 48-bit virtual addresses, but some objects must > always be > allocated inside the 32-bit address range. > > In specific, any resource used with flat/heapless > (0x-0xf000) > General State Heap (GSH) or Instruction State Heap (ISH) must be in a > 32-bit range, because the General State Offset and Instruction State > Offset > are limited to 32-bits. > > The i915 driver has been modified to provide a flag to set when the > 4GB > limit is not necessary in a given bo > (EXEC_OBJECT_SUPPORTS_48B_ADDRESS). > 48-bit range will only be used when explicitly requested. > > Callers to the existing drm_intel_bo_emit_reloc function should set > the > use_48b_address_range flag beforehand, in order to use full ppgtt > range. > > v2: Make set/clear functions nops on pre-gen8 platforms, and use them > internally in emit_reloc functions (Ben) > s/48BADDRESS/48B_ADDRESS/ (Dave) > v3: Keep set/clear functions internal, no-one needs to use them > directly. > v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type > before enabling set/clear function, print full offsets in debug > statements, using port of lower_32_bits and upper_32_bits > from linux > kernel (MichaÅ) > > References: > http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html > Cc: Ben Widawsky > Cc: MichaÅ Winiarski +Kristian LGTM. Acked-by: MichaÅ Winiarski > Signed-off-by: Michel Thierry >>> >>> >>> >>> Hi Kristian, >>> >>> More comments on this? >>> I've resent the mesa patch with the last changes >>> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html). >>> >>> >>> MichaÅ has agreed with the interface and will use it for his work. >>> If mesa doesn't plan to use this for now, it's ok. The kernel changes >>> have >>> been done to prevent any regressions when the support 48-bit flag is not >>> set. >> >> I didn't get any replies to my last comments on this: >> >> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html >> >> Basically, I tried explicitly placing buffers above 8G and didn't see >> the HW problem described (ie it all worked fine). I still think >> there's some confusion as to what the W/A is about. >> >> Here's my take: the W/A is a SW-only workaround to handle the cases >> where a driver uses heapless and 48-bit ppgtt. The problem is that the >> heaps are limited to 4G but with 48bit ppgtt a buffer can be placed >> anywhere it the 48 bit address space. If that happens it's consideredd >> out-of-bounds for the heap and access fails. To prevent this we need >> to make sure the bos we address in a heapless fashion are placed below >> 4g. >> >> For mesa, we only configure general state base as heap-less, which >> affects scratch bos. What this boils down to is that we need the 4G >> restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS >> and 3DSTATE_PS (and tesselation stage eventually). Look for the >> OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c >> and gen8_ps_state.c > > I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it > isn't exclusive to the scratch bos (the error state points to that > instruction). > > Hi, Anymore inputs about this patch? AFAIK, if changes are required based on further comments from Kristian, these will be in the mesa patch[1], not libdrm. Also, MichaÅ will use this flag in another project. Thanks, -Michel [1]http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html
[Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]
On Tue, 13 Oct 2015, Ville Syrjälä wrote: > On Tue, Oct 13, 2015 at 10:24:58AM +0200, Daniel Vetter wrote: >> On Mon, Oct 12, 2015 at 02:29:19PM +0200, Takashi Iwai wrote: >> > On Mon, 12 Oct 2015 09:04:20 +0200, >> > Daniel Vetter wrote: >> > > >> > > Another pile of regressions for Jairo to track ... >> > > >> > > On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote: >> > > > Hi, >> > > > >> > > > I noticed that a HSW laptop gets a few new warnings since 4.2-rc >> > > > kernels. One error messages pops at each boot time: >> > > > >> > > > Console: switching to colour dummy device 80x25 >> > > > [drm] Replacing VGA console driver >> > > > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> > > > [drm] Driver supports precise vblank timestamp query. >> > > > vgaarb: device changed decodes: >> > > > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >> > > > [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't >> > > > calculate constants, dotclock = 0! >> > > >> > > There's patches for this one already, but I accidentally applied them for >> > > -next, not -fixes. They should land for -rc6. >> > >> > Could you point commit ids? >> >> It was wishful thinking on my side, mixed them up with other patches. I >> think this one's still open :( > > 7f4c628 drm/i915: Assign hwmode after encoder state readout > 0f64614 drm/i915: Fix clock readout when pipes are enabled w/o ports > > not enough? The relevant bug is [1], everyone please let's track this there. BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=91428 > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center
[PATCH 0/9] drm/exynos: update codes related with gem
On Tue, Oct 13, 2015 at 06:32:53PM +0900, Joonyoung Shim wrote: > On 10/13/2015 05:37 PM, Joonyoung Shim wrote: > > On 10/13/2015 05:27 PM, Daniel Vetter wrote: > >> On Tue, Oct 13, 2015 at 04:00:45PM +0900, Joonyoung Shim wrote: > >>> Hi, > >>> > >>> This patchset is about gem codes update of exynos-drm. > >>> > >>> The first and second patches are cleanup to remove useless codes. > >>> The rest is to support cachable gem allocation. > >>> > >>> The exynos-drm uses DMA mapping API to allocate/mmap buffer of gem. If > >>> it is cachable, does it with DMA_ATTR_NON_CONSISTENT attribute, but > >>> DMA_ATTR_NON_CONSISTENT isn't supported in DMA mapping API of ARM, so it > >>> doesn't give any effects. > >>> > >>> This patchset introduces new buffer allocation to use > >>> drm_gem_get/put_pages() instead of DMA mapping API. It will be used > >>> for the rest except allocation of physically continuous buffer on > >>> non-iommu, then exynos-drm can support cachable buffer of gem. Also it > >>> can support physically non-continuous buffer on non-iommu. > >>> > >>> EXYNOS_BO_CONTIG flag on iommu is ambiguous because it doesn't care > >>> whether buffer is continuous physically if iommu is supported. This > >>> patchset always will use EXYNOS_BO_CONTIG flag on iommu and then can > >>> mean that the buffer is continuous for device. > >>> > >>> There is no user API to control cache coherence for the cpu and device > >>> about cachable buffer. This patchset introduces two ioctls for cpu > >>> access of gem object from user. It will be synced properly in order for > >>> the cpu and device if buffer of gem object is cachable. > >> > >> Out of curiosity, where's the userspace part for this work? Usually kernel > >> abi extensions come with a link to the relevant branch for easier review. > >> -Daniel > >> > > > > Right, thanks for point. > > > > I just modified a little bit exynos_fimg2d_test and exynos parts of > > libdrm to test them as workaround. I will expose it. > > > > Please refer follows. > https://github.com/dofmind/libdrm/commits/exynos > > If fimd2d test program uses cachable gem, it will show cache coherency > problem, so it adds to use new ioctls to keep cache coherency. Is there some real userspace too, not just a test/demo app? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v5 00/22] Color Management for DRM
This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color correction/enhancement. Various Hardware platforms can support several color correction capabilities. Color Manager provides abstraction of these capabilities and allows a user space UI agent to correct/enhance the display using the DRM property interface. How is this going to work? == 1. This patch series adds a few new properties in DRM framework. These properties are: a. color_capabilities property (type blob) b. Color Transformation Matrix property for corrections like CSC (called CTM, type blob) c. Palette correction properties for corrections like gamma fixup (called palette_correction, type blob) 2. Also, this patch series adds few structures to indicate specifications of a property like size, no_of_samples for correction etc. 3. These properties are present in mode_config. 4. When the platform's display driver loads, it fills up the values of color_capabilities property using the standard structures (added in step 2). For example, Intel's I915 driver adds following color correction capabilities: a. gamma correction capability as palette correction property, with 257 correction coefficients and a max/min value b. csc correction capability as CTM correction property, with 3x3 transformation matrix values and max/min values 5. Now when userspace comes up, it queries the platform's color capabilities by doing a get_property() on color_capabilities DRM property 6. Reading the blob, the userspace understands the color capabilities of the platform. For example, userspace will understand it can support: a. palette_correction with 257 coefficients b. CSC correction with 3x3 = 9 values 7. To set color correction values, userspace: a. creates a blob using the create_blob_ioctl in standard palette_correction structure format, with the correction values b. calls the set_property_ioctl with the blob_id as value for the property 8. Driver refers to the blob, gets the correction values and applies the correction in HW. 9. To get currently applied color correction values, userspace: a. calls a get_property_ioctl on that color property b. gets the blob_id for the currently applied correction from DRM infrastructure c. gets the blob using get_blob_ioctl and hence the currently applied values That's all! :) About the patch series: === The patch series first adds the color management support in DRM layer. Then it adds the color management framework in I915 layer. After that, it implements platform specific core color correction functios. Intel color manager registers color correction with DRM color manager in this way: - CSC transformation is registered as CTM DRM property - Gamma correction is registered as palette_after_ctm DRM property - Degamma correction is registered as palette_before_ctm DRM property Our thanks to all the reviewers who have given valuable comments in terms of design and implementation to our previous sets of patches. Special mention of thanks should go to Matt Roper for all his inputs/suggestions in implementation of this module, using DRM atomic CRTC commit path. V2: Worked on review comments from Matt, Jim, Thierry, Rob. V3: Worked on review comments from Matt, Jim, Rob: - Jim, Rob: Re-arranged the whole patch series in the sequence of features, currently: First 5 patches add color management support in DRM layer Next 7 patches add Intel color management framework in I915 driver Next 5 patches add color correction for CHV (gamma, degamma and CSC) Next 2 patches enable color management, by attaching the properties to CRTC(Matt) Next 4 patches add color correction for BDW (gamma, degamma) - Matt: = Patch 3: Added refernce/unreference for blob Patch 7: return -EINVAL and added debug message Patch 8: check for valid blob, from create blob moved call to intel_crtc_attach_color_prop in the end of full implementation (CHV) Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case Patch 13: Added static for internal functions Patch 20-24: renamed gen9_* functions to bdw_* Added new variables in device_info structure num_samples_after_ctm and num_samples_before_ctm Added new function in patch 8 to load capabilities based on device_info across all platforms V4: Worked on review comments from Daniel, Matt, Rob, Jim - Rob, Jim: = Patch 15, 22: Prepare CSC coeff properly(chv, bdw). Patch 13, 20: Gamma max should be (1<<24) -1(chv, bdw). - Daniel, Matt: = Patch 2: Create separate properties to query color capabilities, not a single blob. Patch 4, 5, 10: Add set/get property interface in DRM layer, not in I915 layer. V5: Addressed review comments from Emil, Rob. -Emil: == Patch 3: Fixed cha
[PATCH v5 01/22] drm: Create Color Management DRM properties
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.
There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a correction
matrix is used for color correction.
- Palette correction: Where direct LUT values are sent to be applied
on a color palette.
This patch initializes color management framework by:
1. Introducing new pointers in DRM mode_config structure to
carry CTM and Palette color correction properties.
2. Creating these DRM properties in DRM standard properties creation
sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_crtc.c | 19 +++
include/drm/drm_crtc.h | 5 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7c8422..3644342 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1472,6 +1472,25 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
+ /* Color Management properties */
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_after_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_palette_before_ctm_property = prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 33ddedd..5ddc1a2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1148,6 +1148,11 @@ struct drm_mode_config {
struct drm_property *suggested_x_property;
struct drm_property *suggested_y_property;
+ /* Color Management Properties */
+ struct drm_property *cm_palette_before_ctm_property;
+ struct drm_property *cm_palette_after_ctm_property;
+ struct drm_property *cm_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
[PATCH v5 02/22] drm: Create Color Management query properties
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.
Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after/before color
transformation (CTM) unit in the display pipeline.
This patch adds two new read-only properties,
- cm_coeff_before_ctm_property: A platform driver should use this
property to show supported no_of_coefficients for palette correction,
which gets applied before ctm correction.
- cm_coeff_after_ctm_property: A platform driver should use this property
to show supported no_of_coefficients for palette correction, which gets
applied after ctm correction.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_crtc.c | 13 +
include/drm/drm_crtc.h | 4
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3644342..ad13630 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1491,6 +1491,19 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.cm_ctm_property = prop;
+ /* DRM properties to query color capabilities */
+ prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+ "COEFFICIENTS_BEFORE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_coeff_before_ctm_property = prop;
+
+ prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+ "COEFFICIENTS_AFTER_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cm_coeff_after_ctm_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5ddc1a2..1a56596 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1153,6 +1153,10 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
+ /* Color management capabilities query */
+ struct drm_property *cm_coeff_before_ctm_property;
+ struct drm_property *cm_coeff_after_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
1.9.1
[PATCH v5 03/22] drm: Add color correction blobs in CRTC state
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_atomic_helper.c | 12
include/drm/drm_crtc.h | 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 87a2a44..d73ca9b9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2193,6 +2193,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_reference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_reference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2238,6 +2244,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc *crtc,
{
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+ if (state->ctm_blob)
+ drm_property_unreference_blob(state->ctm_blob);
+ if (state->palette_after_ctm_blob)
+ drm_property_unreference_blob(state->palette_after_ctm_blob);
+ if (state->palette_before_ctm_blob)
+ drm_property_unreference_blob(state->palette_before_ctm_blob);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a56596..d416e20 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -304,6 +304,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
+ /* blob properties to hold the color properties' blobs */
+ struct drm_property_blob *palette_before_ctm_blob;
+ struct drm_property_blob *palette_after_ctm_blob;
+ struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
struct drm_atomic_state *state;
--
1.9.1
[PATCH v5 04/22] drm: Add set property support for color manager
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from the blob can referred and applied on display controller
registers.
This patch adds this set_property support for color correction blobs
in drm framework.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal malladi
---
drivers/gpu/drm/drm_atomic.c | 53 ++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..12a34e9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct
drm_crtc_state *state,
EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
/**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+static int drm_atomic_crtc_set_blob(struct drm_device *dev,
+ struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+ struct drm_property_blob *blob;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_DEBUG_KMS("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ if (*state_blob)
+ drm_property_unreference_blob(*state_blob);
+
+ /* Attach the blob to be committed in state */
+ *state_blob = blob;
+ return 0;
+}
+
+/**
* drm_atomic_crtc_set_property - set property on CRTC
* @crtc: the drm CRTC to set a property on
* @state: the state object to update with the new property value
@@ -422,8 +454,25 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (mode)
drm_property_unreference_blob(mode);
return ret;
- }
- else if (crtc->funcs->atomic_set_property)
+ } else if (property == config->cm_palette_after_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->palette_after_ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob palette_after_ctm\n");
+ return ret;
+ } else if (property == config->cm_palette_before_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->palette_before_ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob palette_before_ctm\n");
+ return ret;
+ } else if (property == config->cm_ctm_property) {
+ ret = drm_atomic_crtc_set_blob(dev,
+ &state->ctm_blob, val);
+ if (ret)
+ DRM_ERROR("Failed to load blob ctm\n");
+ return ret;
+ } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
else
return -EINVAL;
--
1.9.1
[PATCH v5 05/22] drm: Add get property support for color manager
As per the DRM get_property implementation for a blob, framework is supposed to return the blob_id to the caller. All the color management blobs are saved in CRTC state during the set call. This patch adds get_property support for color management properties, by referring to the existing blob for the property and passing its blob_id. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_atomic.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 12a34e9..b49aaeb 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -499,6 +499,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc, *val = state->active; else if (property == config->prop_mode_id) *val = (state->mode_blob) ? state->mode_blob->base.id : 0; + else if (property == config->cm_palette_after_ctm_property) + *val = (state->palette_after_ctm_blob) ? + state->palette_after_ctm_blob->base.id : 0; + else if (property == config->cm_palette_before_ctm_property) + *val = (state->palette_before_ctm_blob) ? + state->palette_before_ctm_blob->base.id : 0; + else if (property == config->cm_ctm_property) + *val = (state->ctm_blob) ? state->ctm_blob->base.id : 0; else if (crtc->funcs->atomic_get_property) return crtc->funcs->atomic_get_property(crtc, state, property, val); else -- 1.9.1
[PATCH v5 06/22] drm: Add drm structures for palette color property
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..681d5af 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,32 @@ struct drm_event_vblank {
__u32 reserved;
};
+struct drm_r32g32b32 {
+ /*
+* Data is in U8.24 fixed point format.
+* All platforms support values within [0, 1.0] range,
+* for Red, Green and Blue colors.
+*/
+ __u32 r32;
+ __u32 g32;
+ __u32 b32;
+ __u32 reserved;
+};
+
+struct drm_palette {
+ /*
+* This has to be a supported value during get call.
+* Feature will be disabled if this is 0 while set
+*/
+ __u32 num_samples;
+ /*
+* Starting of palette LUT in R32G32B32 format.
+* Each of RGB value is in U8.24 fixed point format.
+* Actual number of samples will depend upon num_samples
+*/
+ struct drm_r32g32b32 lut[0];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
[PATCH v5 07/22] drm: Add structure to set/get a CTM color property
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for color correction.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 681d5af..f347c69 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -855,6 +855,16 @@ struct drm_palette {
struct drm_r32g32b32 lut[0];
};
+struct drm_ctm {
+ /*
+* Each value is in S31.32 format.
+* This is 3x3 matrix in row major format.
+* Integer part will be clipped to nearest
+* max/min boundary as supported by the HW platform.
+*/
+ __s64 ctm_coeff[9];
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
--
1.9.1
[PATCH v5 08/22] drm/i915: Add set property interface for CRTC
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cddb0c6..d01a524 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13275,6 +13275,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+ .set_property = drm_atomic_helper_crtc_set_property,
};
static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
--
1.9.1
[PATCH v5 09/22] drm/i915: Create color management files
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_color_manager.c | 33
drivers/gpu/drm/i915/intel_color_manager.h | 50 ++
3 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
intel_overlay.o \
intel_psr.o \
intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..7357d99
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+ struct drm_mode_object *mode_obj)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..eec52a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+#include
+#include
+#include "i915_drv.h"
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+ ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+ x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define SET_BITS(target, bit_pattern, start_bit,
[PATCH v5 10/22] drm/i915: Register color correction capabilities
>From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get applied
beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
after color transformation matrix correction.
These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)
Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.
So finally, This patch does the following:
1. Add a function which loads the platform's color correction
capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
"num_samples_before_ctm" in intel_device_info as gamma and
degamma coefficients vary per platform basis.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_color_manager.c | 33 +-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf14096..6044e5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -785,6 +785,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+ u16 num_samples_after_ctm;
+ u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
#include "intel_color_manager.h"
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
- struct drm_mode_object *mode_obj)
+ struct drm_crtc *crtc)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_mode_object *mode_obj = &crtc->base;
+
+ /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the init
+* phase.
+*/
+ if (config->cm_coeff_after_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_after_ctm_property,
+ INTEL_INFO(dev)->num_samples_after_ctm);
+ DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+ }
+
+ if (config->cm_coeff_before_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_before_ctm_property,
+ INTEL_INFO(dev)->num_samples_before_ctm);
+ DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+ }
}
--
1.9.1
[PATCH v5 11/22] drm/i915: CHV: Load gamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit): 257 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 2 ++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 760e0ce..7780de4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_drv.h"
+#include "intel_color_manager.h"
#include
#include
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index eec52a7..a378fe1 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -48,3 +48,6 @@
CLEAR_BITS(target, start_bit, no_bits); \
target |= (bit_pattern << start_bit); \
} while (0)
+
+/* CHV */
+#define CHV_10BIT_GAMMA_MAX_VALS 257
--
1.9.1
[PATCH v5 12/22] drm/i915: CHV: Load degamma color correction values
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coefficitents for degamma color correction
modes possible in CHV, in device info structure, which is:
CGM Degamma(10 bit, CGM HW unit): 65 coeff
These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/intel_color_manager.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7780de4..6adf002 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static const struct intel_device_info intel_cherryview_info
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+ .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index a378fe1..14a1309 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -51,3 +51,4 @@
/* CHV */
#define CHV_10BIT_GAMMA_MAX_VALS 257
+#define CHV_DEGAMMA_MAX_VALS 65
--
1.9.1
[PATCH v5 13/22] drm/i915: CHV: Pipe level Gamma correction
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 12
drivers/gpu/drm/i915/intel_color_manager.c | 96 ++
drivers/gpu/drm/i915/intel_color_manager.h | 13
3 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 88b3da2..8e0a1b1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8148,4 +8148,16 @@ enum skl_disp_power_wells {
#define GEN9_VEBOX_MOCS_0 0xcb00 /* Video MOCS base register*/
#define GEN9_BLT_MOCS_00xcc00 /* Blitter MOCS base register*/
+/* Color Management */
+#define PIPEA_CGM_CONTROL (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e466748..498e048 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,94 @@
#include "intel_color_manager.h"
+static int chv_set_gamma(struct drm_device *dev, struct drm_property_blob
*blob,
+ struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue, num_samples;
+ u32 word = 0;
+ u32 count, cgm_gamma_reg, cgm_control_reg;
+ u64 length;
+ struct drm_r32g32b32 *correction_values;
+ struct drm_palette *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_crtc_state *state = crtc->state;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ gamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ switch (num_samples) {
+ case GAMMA_DISABLE_VALS:
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+ state->palette_after_ctm_blob = NULL;
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+
+ case CHV_8BIT_GAMMA_MAX_VALS:
+ case CHV_10BIT_GAMMA_MAX_VALS:
+
+ count = 0;
+ cgm_gamma_reg = _PIPE_GAMMA_BASE(pipe);
+ correction_values = gamma_data->lut;
+
+ while (count < num_samples) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ if (blue > CHV_MAX_GAMMA)
+ blue = CHV_MAX_GAMMA;
+
+ if (green > CHV_MAX_GAMMA)
+ green = CHV_MAX_GAMMA;
+
+ if (red > CHV_MAX_GAMMA)
+ red = CHV_MAX_GAMMA;
+
+ /* get MSB 10 bits from fraction part (14:23) */
+ blue_fract = GET_BITS(blue, 14, 10);
+ green_fract = GET_BITS(green, 14, 10);
+ red_fract = GET_BITS(red, 14, 10);
+
+ /* Green (25:16) and Blue (9:0) to be written */
+ SET_BITS(word, green_fract, 16, 10);
+ SET_BITS(word, blue_fract, 0, 10);
+ I915_WRITE(cgm_gamma_reg, word);
+ cgm_gamma_reg += 4;
+
+ /* Red (9:0) to be written */
+ word = red_fract;
+ I915_WRITE(cgm_gamma_reg, word);
+
+ cgm_gamma_reg += 4;
+ count++;
+ }
+
+ /* Enable (CGM) Gamma on Pipe */
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe),
[PATCH v5 14/22] drm/i915: CHV: Pipe level degamma correction
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2. Add DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 6 ++
drivers/gpu/drm/i915/intel_color_manager.c | 91 ++
drivers/gpu/drm/i915/intel_color_manager.h | 5 ++
3 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e0a1b1..cbb5fc9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8160,4 +8160,10 @@ enum skl_disp_power_wells {
#define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 498e048..73c0762 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,91 @@
#include "intel_color_manager.h"
+static int chv_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ u16 red_fract, green_fract, blue_fract;
+ u32 red, green, blue;
+ u32 num_samples;
+ u32 word = 0;
+ u32 count, cgm_control_reg, cgm_degamma_reg;
+ u64 length;
+ enum pipe pipe;
+ struct drm_palette *degamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+ struct drm_crtc_state *state = crtc->state;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+ length = num_samples * sizeof(struct drm_r32g32b32);
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
+ /* Disable DeGamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_DEGAMMA_EN;
+ state->palette_before_ctm_blob = NULL;
+
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+ DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+ } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+ cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+ count = 0;
+ correction_values = (struct drm_r32g32b32 *)°amma_data->lut;
+ while (count < CHV_DEGAMMA_MAX_VALS) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ if (blue > CHV_MAX_GAMMA)
+ blue = CHV_MAX_GAMMA;
+
+ if (green > CHV_MAX_GAMMA)
+ green = CHV_MAX_GAMMA;
+
+ if (red > CHV_MAX_GAMMA)
+ red = CHV_MAX_GAMMA;
+
+ blue_fract = GET_BITS(blue, 8, 14);
+ green_fract = GET_BITS(green, 8, 14);
+ red_fract = GET_BITS(red, 8, 14);
+
+ /* Green (29:16) and Blue (13:0) in DWORD1 */
+ SET_BITS(word, green_fract, 16, 14);
+ SET_BITS(word, green_fract, 0, 14);
+ I915_WRITE(cgm_degamma_reg, word);
+ cgm_degamma_reg += 4;
+
+ /* Red (13:0) to be written to DWORD2 */
+ word = red_fract;
+ I915_WRITE(cgm_degamma_reg, word);
+ cgm_degamma_reg += 4;
+ count++;
+ }
+
+ DRM_DEBUG_DRIVER("DeGamma LUT loaded for Pipe %c\n",
+ pipe_name(pipe));
+
+ /* Enable DeGamma on Pipe */
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+ I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+ DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+ } else {
+ DRM_ERROR("Invalid
[PATCH v5 15/22] drm/i915: CHV: Pipe level CSC correction
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 8 +++
drivers/gpu/drm/i915/intel_color_manager.c | 99 ++
drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
3 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cbb5fc9..c395b63 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8166,4 +8166,12 @@ enum skl_disp_power_wells {
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 73c0762..6b17b20 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,98 @@
#include "intel_color_manager.h"
+static s32 chv_prepare_csc_coeff(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s32 csc_s3_12_format;
+
+ if (csc_value >= 0) {
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX)
+ csc_value = CHV_CSC_COEFF_MAX;
+ } else {
+ csc_value = -csc_value;
+ csc_value += CHV_CSC_FRACT_ROUNDOFF;
+ if (csc_value > CHV_CSC_COEFF_MAX + 1)
+ csc_value = CHV_CSC_COEFF_MAX + 1;
+ csc_value = -csc_value;
+ }
+
+ csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+ csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+ if (csc_value < 0)
+ csc_int_value |= CSC_COEFF_SIGN;
+
+ csc_fract_value = csc_value;
+ csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+ csc_s3_12_format = csc_int_value | csc_fract_value;
+
+ return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 reg;
+ enum pipe pipe;
+ s32 word = 0, temp;
+ int count = 0;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+
+ /* Disable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+ DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+ pipe_name(pipe));
+
+ reg = _PIPE_CSC_BASE(pipe);
+
+ /*
+ * First 8 of 9 CSC correction values go in pair, to first
+ * 4 CSC register (bit 0:15 and 16:31)
+ */
+ while (count < CSC_MAX_VALS - 1) {
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+ count++;
+
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+ count++;
+
+ I915_WRITE(reg, word);
+ reg += 4;
+ }
+
+ /* 9th coeff goes to 5th register, bit 0:16 */
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+ I915_WRITE(reg, word);
+
+ /* Enable CSC functionality */
+ reg = _PIPE_CGM_CONTROL(pipe);
+ I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+ DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+ return 0;
+}
+
static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
{
@@ -248,4 +340,11 @@ void intel_attach_color_properties_to_crtc(struct
drm_device *dev,
config->cm_palette_before_ctm_property, 0);
DRM_DEBUG_DRIVER("degamma property attached to CRTC\n");
}
+
+
[PATCH v5 16/22] drm/i915: Commit color correction to CRTC
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 6b17b20..fe95762 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -292,6 +292,50 @@ static int chv_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
}
}
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_property_blob *blob;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ int ret = -EINVAL;
+
+ blob = crtc_state->palette_after_ctm_blob;
+ if (blob) {
+ /* Gamma correction is platform specific */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_gamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set Gamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("Gamma correction success\n");
+ }
+
+ blob = crtc_state->palette_before_ctm_blob;
+ if (blob) {
+ /* Degamma correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_degamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set degamma correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("degamma correction success\n");
+ }
+
+ blob = crtc_state->ctm_blob;
+ if (blob) {
+ /* CSC correction */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_csc(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set CSC correction failed\n");
+ else
+ DRM_DEBUG_DRIVER("CSC correction success\n");
+ }
+}
+
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d01a524..8c7f8d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13564,6 +13564,8 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+ intel_color_manager_crtc_commit(dev, crtc->state);
}
static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 91b6b40..3e79bb4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1474,4 +1474,7 @@ void intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+/* intel_color_manager.c */
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state);
#endif /* __INTEL_DRV_H__ */
--
1.9.1
[PATCH v5 17/22] drm/i915: Attach color properties to CRTC
Function intel_attach_color_properties_to_crtc attaches a color property to its CRTC object. This patch calls this function from crtc initialization sequence. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8c7f8d3..cc284bcd 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13895,6 +13895,7 @@ static void intel_crtc_init(struct drm_device *dev, int pipe) intel_crtc->cursor_size = ~0; intel_crtc->wm.cxsr_allowed = true; + intel_attach_color_properties_to_crtc(dev, &intel_crtc->base); BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) || dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 3e79bb4..ebe776c 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1477,4 +1477,6 @@ extern const struct drm_plane_helper_funcs intel_plane_helper_funcs; /* intel_color_manager.c */ void intel_color_manager_crtc_commit(struct drm_device *dev, struct drm_crtc_state *crtc_state); +void intel_attach_color_properties_to_crtc(struct drm_device *dev, + struct drm_crtc *crtc); #endif /* __INTEL_DRV_H__ */ -- 1.9.1
[PATCH v5 18/22] drm/i915: BDW: Load gamma correction values
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6adf002..8beac5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+ .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 7b96512..271246a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -89,3 +89,6 @@
#define CGM_GAMMA_EN (1 << 2)
#define CGM_CSC_EN (1 << 1)
#define CGM_DEGAMMA_EN (1 << 0)
+
+/* Gamma on BDW */
+#define BDW_SPLITGAMMA_MAX_VALS512
--
1.9.1
[PATCH v5 19/22] drm/i915: BDW: Pipe level Gamma correction
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_reg.h| 25 ++-
drivers/gpu/drm/i915/intel_color_manager.c | 285 +
drivers/gpu/drm/i915/intel_color_manager.h | 6 +
3 files changed, 314 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c395b63..13e268a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5685,11 +5685,15 @@ enum skl_disp_power_wells {
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) +
(i) * 4)
+#define _LGC_PALETTE_C 0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)
#define _GAMMA_MODE_A 0x4a480
#define _GAMMA_MODE_B 0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C 0x4b480
+#define GAMMA_MODE(pipe) \
+ _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
#define GAMMA_MODE_MODE_MASK (3 << 0)
#define GAMMA_MODE_MODE_8BIT (0 << 0)
#define GAMMA_MODE_MODE_10BIT (1 << 0)
@@ -8172,6 +8176,23 @@ enum skl_disp_power_wells {
#define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A 0x4A400
+#define PAL_PREC_INDEX_B 0x4AC00
+#define PAL_PREC_INDEX_C 0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A 0x4A410
+#define PAL_PREC_GCMAX_B 0x4AC10
+#define PAL_PREC_GCMAX_C 0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+ (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+ (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index fe95762..cf85bc3 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,289 @@
#include "intel_color_manager.h"
+static void bdw_write_8bit_gamma_legacy(struct drm_device *dev,
+ struct drm_r32g32b32 *correction_values, u32 palette)
+{
+ u16 blue_fract, green_fract, red_fract;
+ u32 blue, green, red;
+ u32 count = 0;
+ u32 word = 0;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ while (count < BDW_8BIT_GAMMA_MAX_VALS) {
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ /*
+ * Maximum possible gamma correction value supported
+ * for BDW is 0x, so clamp the values accordingly
+ */
+ if (blue >= BDW_MAX_GAMMA)
+ blue = BDW_MAX_GAMMA;
+ if (green >= BDW_MAX_GAMMA)
+ green = BDW_MAX_GAMMA;
+ if (red >= BDW_MAX_GAMMA)
+ red = BDW_MAX_GAMMA;
+
+ blue_fract = GET_BITS(blue, 16, 8);
+ green_fract = GET_BITS(green, 16, 8);
+ red_fract = GET_BITS(red, 16, 8);
+
+ /* Blue (7:0) Green (15:8) and Red (23:16) */
+ SET_BITS(word, blue_fract, 0, 8);
+ SET_BITS(word, green_fract, 8, 8);
+ SET_BITS(word, blue_fract, 16, 8);
+ I915_WRITE(palette, word);
+ palette += 4;
+ count++;
+ }
+}
+
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+ struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+ u32 no_of_coeff)
+{
+ u16 blue_fract, green_fract, red_fract;
+ u32 word = 0;
+ u32 count = 0;
+ u32 blue, green, red;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ while (count < no_of_coeff) {
+
+ blue = correction_values[count].b32;
+ green = correction_values[count].g32;
+ red = correction_values[count].r32;
+
+ /*
+
[PATCH v5 20/22] drm/i915: BDW: Load degamma correction values
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.c| 7 +++
drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8beac5c..1c68e91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+ .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
#define BDW_MAX_GAMMA ((1 << 24) - 1)
#define BDW_INDEX_AUTO_INCREMENT (1 << 15)
#define BDW_INDEX_SPLIT_MODE (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS 512
--
1.9.1
[PATCH v5 21/22] drm/i915: BDW: Pipe level degamma correction
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index cf85bc3..42fd2f5 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -310,6 +310,62 @@ static int bdw_set_gamma(struct drm_device *dev, struct
drm_property_blob *blob,
return 0;
}
+static int bdw_set_degamma(struct drm_device *dev,
+ struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ int num_samples;
+ u32 index, mode;
+ u32 pal_prec_index, pal_prec_data;
+ struct drm_palette *degamma_data;
+ struct drm_crtc_state *state = crtc->state;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_r32g32b32 *correction_values = NULL;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ degamma_data = (struct drm_palette *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = degamma_data->num_samples;
+
+ if (num_samples == GAMMA_DISABLE_VALS) {
+ /* Disable degamma on Pipe */
+ mode = I915_READ(GAMMA_MODE(pipe)) & ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_8BIT);
+
+ state->palette_before_ctm_blob = NULL;
+ DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+ pipe_name(pipe));
+ return 0;
+ }
+
+ if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
+ DRM_ERROR("Invalid number of samples\n");
+ return -EINVAL;
+ }
+
+ pal_prec_index = _PREC_PAL_INDEX(pipe);
+ pal_prec_data = _PREC_PAL_DATA(pipe);
+ correction_values = degamma_data->lut;
+
+ index = I915_READ(pal_prec_index);
+ index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+ I915_WRITE(pal_prec_index, index);
+
+ bdw_write_10bit_gamma_precision(dev, correction_values,
+ pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+ /* Enable degamma on Pipe */
+ mode = I915_READ(GAMMA_MODE(pipe));
+ mode &= ~GAMMA_MODE_MODE_MASK;
+ I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+ DRM_DEBUG_DRIVER("degamma correction enabled on Pipe %c\n",
+ pipe_name(pipe));
+
+ return 0;
+}
+
static s32 chv_prepare_csc_coeff(s64 csc_value)
{
s32 csc_int_value;
@@ -601,6 +657,8 @@ void intel_color_manager_crtc_commit(struct drm_device *dev,
/* Degamma correction */
if (IS_CHERRYVIEW(dev))
ret = chv_set_degamma(dev, blob, crtc);
+ else if (IS_BROADWELL(dev) || IS_GEN9(dev))
+ ret = bdw_set_degamma(dev, blob, crtc);
if (ret)
DRM_ERROR("set degamma correction failed\n");
--
1.9.1
[PATCH v5 22/22] drm/i915: BDW: Pipe level CSC correction
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 7 ++
drivers/gpu/drm/i915/intel_color_manager.c | 113 +
drivers/gpu/drm/i915/intel_color_manager.h | 8 ++
3 files changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13e268a..fa1703d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8195,4 +8195,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+ (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 42fd2f5..8fe0c0b 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -366,6 +366,117 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
}
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+ uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+ int32_t mantissa;
+ uint64_t abs_coeff;
+
+ coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+ coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+ abs_coeff = abs(coeff);
+ if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+ /* abs_coeff < 0.125 */
+ exponent_bits = 3;
+ ls_bit_pos = 19;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+ /* abs_coeff >= 0.125 && val < 0.25 */
+ exponent_bits = 2;
+ ls_bit_pos = 20;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+ && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+ /* abs_coeff >= 0.25 && val < 0.5 */
+ exponent_bits = 1;
+ ls_bit_pos = 21;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+ && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+ /* abs_coeff >= 0.5 && val < 1.0 */
+ exponent_bits = 0;
+ ls_bit_pos = 22;
+ } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+ /* abs_coeff >= 1.0 && val < 2.0 */
+ exponent_bits = 7;
+ ls_bit_pos = 23;
+ } else {
+ /* abs_coeff >= 2.0 && val < 4.0 */
+ exponent_bits = 6;
+ ls_bit_pos = 24;
+ }
+
+ mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+ if (coeff < 0)
+ sign_bit = 1;
+
+ reg_val = 0;
+ SET_BITS(reg_val, exponent_bits, 12, 3);
+ SET_BITS(reg_val, mantissa, 3, 9);
+ SET_BITS(reg_val, sign_bit, 15, 1);
+ return reg_val;
+}
+
+static int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+ struct drm_crtc *crtc)
+{
+ enum pipe pipe;
+ enum plane plane;
+ int temp, word;
+ int count = 0;
+ u32 reg, plane_ctl, mode;
+ struct drm_ctm *csc_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (WARN_ON(!blob))
+ return -EINVAL;
+
+ if (blob->length != sizeof(struct drm_ctm)) {
+ DRM_ERROR("Invalid length of data received\n");
+ return -EINVAL;
+ }
+
+ csc_data = (struct drm_ctm *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ plane = to_intel_crtc(crtc)->plane;
+
+ plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+ plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+ I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+ reg = _PIPE_CSC_COEFF(pipe);
+
+ /*
+ * BDW CSC correction coefficients are written like this:
+ * first two values go in a pair, into first register(0:15 and 16:31)
+ * third one alone goes into second register (16:31). Same
+ * pattern repeats for 3 times = 3 * 3 = 9 values.
+ */
+ while (count < CSC_MAX_VALS) {
+ word = 0;
+ temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+ SET_BITS(word, temp, 16, 16);
+
+ temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+ SET_BI
[PATCH 09/22] drm/i915: Create color management files
On 10 October 2015 at 05:55, Sharma, Shashank
wrote:
> On 10/10/2015 4:17 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:28, Shashank Sharma
>> wrote:
>> [snip]
>>>
>>> +
>>> +/* Color management bit utilities */
>>> +#define GET_BIT_MASK(n) ((1 << n) - 1)
>>> +
>>> +/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
>>> +#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
>>> +
>>> +/* Round off by adding 1 to the immediate lower bit */
>>> +#define GET_BITS_ROUNDOFF(x, start, nbits) \
>>> + ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
>>> +
>>> +/* Clear bits of a word from bit no. 'start' till nbits */
>>> +#define CLEAR_BITS(x, start, nbits) ( \
>>> + x &= ~((GET_BIT_MASK(nbits) << start)))
>>> +
>>> +/* Write bit_pattern of no_bits bits in a target word */
>>> +#define SET_BITS(target, bit_pattern, start_bit, no_bits) \
>>> + do { \
>>> + CLEAR_BITS(target, start_bit, no_bits); \
>>> + target |= (bit_pattern << start_bit); \
>>> + } while (0)
>>
>> It feels suspicious that the kernel does not have macros for either
>> one of these.
>>
>> I would invite you to take a look at include/linux/bitops.h and other
>> kernel headers.
>>
> Thanks for pointing this out, but if you closely observe, these macros are
> well tested, and created for color management operations, which have
> specific requirements, like:
> - pick 8 bits from 16th bit onwards, make them LSB, and give result:
> GET_BITS
> - take these 8 bits and move to bit 17th of the word, clearing the existing
> ones: SET_BITS
> For core register programming, this was required, so we created it. I would
> still have a look
> at the existing ones which you pointed out to avoid any duplication, if they
> fall directly in the implementation, else I would like to continue with
> these.
Unless I'm missing something, these are generic bit manipulation
macros, are they not ? As such I'd imagine we have some of these
already available, but I cannot say which ones off-hand.
Regards,
Emil
[PATCH 10/22] drm/i915: Register color correction capabilities
On 10 October 2015 at 06:01, Sharma, Shashank
wrote:
> On 10/10/2015 3:51 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
>> wrote:
>>>
>>> From DRM color management:
>>>
>>> DRM color manager supports these color properties:
>>> 1. "ctm": Color transformation matrix property, where a
>>> color transformation matrix of 9 correction values gets
>>> applied as correction.
>>> 2. "palette_before_ctm": for corrections which get applied
>>> beore color transformation matrix correction.
>>> 3. "palette_after_ctm": for corrections which get applied
>>> after color transformation matrix correction.
>>>
>>> These color correction capabilities may differ per platform, supporting
>>> various different no. of correction coefficients. So DRM color manager
>>> support few properties using which a user space can query the platform's
>>> capability, and prepare color correction accordingly.
>>> These query properties are:
>>> 1. cm_coeff_after_ctm_property
>>> 2. cm_coeff_before_ctm_property
>>> (CTM is fix to 9 coefficients across industry)
>>>
>>> Now, Intel color manager registers:
>>> ==
>>> 1. Gamma correction property as "palette_after_ctm" property
>>> 2. Degamma correction capability as "palette_bafore_ctm" property
>>> capability as "palette_after_ctm" DRM color property hook.
>>> 3. CSC as "ctm" property.
>>>
>>> So finally, This patch does the following:
>>> 1. Add a function which loads the platform's color correction
>>> capabilities in the cm_crtc_palette_capabilities_property structure.
>>> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
>>> getting initiaized.
>>> 3. Adds two new parameters "num_samples_after_ctm" and
>>> "num_samples_before_ctm" in intel_device_info as gamma and
>>> degamma coefficients vary per platform basis.
>>>
>>> Signed-off-by: Shashank Sharma
>>> Signed-off-by: Kausal Malladi
>>> ---
>>> drivers/gpu/drm/i915/i915_drv.h| 2 ++
>>> drivers/gpu/drm/i915/intel_color_manager.c | 33
>>> +-
>>> 2 files changed, 34 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index ad37b25..8bf1d6f 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -798,6 +798,8 @@ struct intel_device_info {
>>> u8 num_sprites[I915_MAX_PIPES];
>>> u8 gen;
>>> u8 ring_mask; /* Rings supported by the HW */
>>> + u16 num_samples_after_ctm;
>>> + u16 num_samples_before_ctm;
>>> DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
>>> /* Register offsets for the various display pipes and
>>> transcoders */
>>> int pipe_offsets[I915_MAX_TRANSCODERS];
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index 7357d99..e466748 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -28,6 +28,37 @@
>>> #include "intel_color_manager.h"
>>>
>>> void intel_attach_color_properties_to_crtc(struct drm_device *dev,
>>> - struct drm_mode_object *mode_obj)
>>> + struct drm_crtc *crtc)
>>> {
>>> + struct drm_mode_config *config = &dev->mode_config;
>>> + struct drm_mode_object *mode_obj = &crtc->base;
>>> +
>>> + /*
>>> +* Register:
>>> +* =
>>> +* Gamma correction as palette_after_ctm property
>>> +* Degamma correction as palette_before_ctm property
>>> +*
>>> +* Load:
>>> +* =
>>> +* no. of coefficients supported on this platform for gamma
>>> +* and degamma with the query properties. A user
>>> +* space agent should read these query property, and prepare
>>> +* the color correction values accordingly. Its expected from the
>>> +* driver to load the right number of coefficients during the
>>> init
>>> +* phase.
>>> +*/
>>> + if (config->cm_coeff_after_ctm_property) {
>>> + drm_object_attach_property(mode_obj,
>>> + config->cm_coeff_after_ctm_property,
>>> + INTEL_INFO(dev)->num_samples_after_ctm);
>>> + DRM_DEBUG_DRIVER("Gamma query property initialized\n");
>>> + }
>>> +
>>> + if (config->cm_coeff_before_ctm_property) {
>>> + drm_object_attach_property(mode_obj,
>>> + config->cm_coeff_before_ctm_property,
>>> + INTEL_INFO(dev)->num_samples_before_ctm);
>>> + DRM_DEBUG_DRIVER("Degamma query property initialized\n");
>>> + }
>>
>> Shouldn't this commit be squashed with the previous ? You're also
>> missing the function declaration.
>>
> Please see the history of th
[PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
On 10 October 2015 at 06:09, Sharma, Shashank
wrote:
> On 10/10/2015 4:37 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
>> wrote:
>>>
>>> CHV/BSW platform supports two different pipe level gamma
>>> correction modes, which are:
>>> 1. Legacy 8-bit mode
>>> 2. 10-bit CGM (Color Gamut Mapping) mode
>>>
>>> This patch does the following:
>>> 1. Attaches Gamma property to CRTC
>>> 3. Adds the core Gamma correction function for CHV/BSW
>>> 4. Adds Gamma correction macros
>>>
>>> Signed-off-by: Shashank Sharma
>>> Signed-off-by: Kausal Malladi
>>> ---
[snip]
>>> + length = num_samples * sizeof(struct drm_r32g32b32);
>>
>> Calculation can overflow.
>
> good catch, will take care of this.
Actually we do not at all here as the variable is unused. Same applies
for patch 21/22.
[snip]
>>> + while (count < num_samples) {
>>
>> Using for(i = 0;) loop seems the more common approach ?
>
> Nah, we are good with while. The whole color management series prefers while
> (and me too :))
Hmm... so you'd prefer your approach/coding style over the one already
in i915? Feels a bit strange but as long as others are happy fine go
with it.
Regards,
Emil
[PATCH 16/22] drm/i915: Commit color correction to CRTC
On 10 October 2015 at 06:20, Sharma, Shashank
wrote:
> On 10/10/2015 4:54 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
>> wrote:
>>>
>>> The color correction blob values are loaded during set_property
>>> calls. This patch adds a function to find the blob and apply the
>>> correction values to the display registers, during the atomic
>>> commit call.
>>>
>>> Signed-off-by: Shashank Sharma
>>> Signed-off-by: Kausal Malladi
>>> ---
>>> drivers/gpu/drm/i915/intel_color_manager.c | 44
>>> ++
>>> drivers/gpu/drm/i915/intel_display.c | 2 ++
>>> drivers/gpu/drm/i915/intel_drv.h | 3 ++
>>> 3 files changed, 49 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index 433e50a..d5315b2 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev,
>>> struct drm_property_blob *blob,
>>> return ret;
>>> }
>>>
>>> +void intel_color_manager_crtc_commit(struct drm_device *dev,
>>> + struct drm_crtc_state *crtc_state)
>>> +{
>>> + struct drm_property_blob *blob;
>>> + struct drm_crtc *crtc = crtc_state->crtc;
>>> + int ret = -EINVAL;
>>
>> Most places/people advise against pre-emptively initializing ret.
>>
> Just in this case, if makes sense to keep one, coz there might be multiple
> blobs which we are applying in the commit action, and every blob can return
> error, from the core function.
> Assume that there is a situation where both palette_after_ctm(gamma) and CTM
> is in place, then we will be going through multiple if() cases and have to
> check the return values.
When you have an exception of any rule, this implies that you are
using a suboptimal way of doing things.
>>>
>>> +
>>> + blob = crtc_state->palette_after_ctm_blob;
>>> + if (blob) {
>>> + /* Gamma correction is platform specific */
>>> + if (IS_CHERRYVIEW(dev))
>>> + ret = chv_set_gamma(dev, blob, crtc);
>>> +
>>> + if (ret)
>>> + DRM_ERROR("set Gamma correction failed\n");
>>
>> Do we really want to spam dmesg on for each non Cherryview device ?
>
> If you see the complete implementation, as IS_GEN8()/IS_SKL is coming up
> here after IS_CHV(patch 19,20,21) which will cover BDW/SKL/BXT. Anything
> else which comes here, deserves a DRM_ERROR() as this platform will not be
> supported.
>
Your patches should be independent changes. You cannot say "I'm adding
something iffy here, but it will be fixed with another patch".
Otherwise you'll get developer/user X bisecting the kernel, which will
end up with broken system (flooded dmesg in this case) half way
through the bisect.
Regards,
Emil
[PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
On 10 October 2015 at 06:21, Sharma, Shashank
wrote:
> On 10/10/2015 5:09 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
[snip]
>>> + switch (num_samples) {
>>> + case GAMMA_DISABLE_VALS:
>>> +
>>> + /* Disable Gamma functionality on Pipe */
>>
>> Drop the extra newline between the case and the comment ? Here and below.
>>
> I was trying to make it look good :(
Beauty is in the eye of the beholder. The most important part here is
consistency.
Afaict there isn't (m)any i915 code the uses this approach, is there ?
Some of your other patches use this approach while others don't.
Regards,
Emil
[PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.
On Fri, Oct 9, 2015 at 4:27 PM, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
> other Broadcom SoCs.
>
> This binding follows the model of msm, imx, sti, and others, where
> there is a subsystem node for the whole GPU, with nodes for the
The subsystem node is gone now, right?
> individual HW components within it.
>
> Signed-off-by: Eric Anholt
> ---
>
> v2: Extend the commit message, fix several nits from Stephen Warren.
> v3: Rename the compatibility strings, clean up node names, drop the
> unnecessary lists of components. Use compatibility strings for
> choosing CRTC HVS channel numbers. Document the HDMI clock usage.
>
> .../devicetree/bindings/gpu/brcm,bcm-vc4.txt | 64
> ++
Can you put this in bindings/display/ instead? Things are moving there in 4.4.
> 1 file changed, 64 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
> b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
> new file mode 100644
> index 000..175bcde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
> @@ -0,0 +1,64 @@
> +Broadcom VC4 GPU
> +
> +The VC4 device present on the Raspberry Pi includes a display system
> +with HDMI output and the HVS scaler for compositing display planes.
> +
> +Required properties for VC4:
> +- compatible: Should be "brcm,bcm2835-vc4"
reg property? interrupts? clocks?
> +
> +Required properties for Pixel Valve:
> +- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
> + "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
> +- reg: Physical base address and length of the PV's registers
> +- interrupts: The interrupt number
> + See
> bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +
> +Required properties for HVS:
> +- compatible: Should be "brcm,bcm2835-hvs"
> +- reg: Physical base address and length of the HVS's registers
> +- interrupts: The interrupt number
> + See
> bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +
> +Required properties for HDMI
Is HDMI the only output possibility? If not, then you should have OF
graph nodes describing the connection between HDMI block and HVS (or
PV?).
> +- compatible: Should be "brcm,bcm2835-hdmi"
> +- reg: Physical base address and length of the two register ranges
> + ("HDMI" and "HD", in that order)
> +- interrupts: The interrupt numbers
> + See
> bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +- ddc: phandle of the I2C controller used for DDC EDID probing
> +- clocks: a) hdmi: The HDMI state machine clock
> + b) pixel: The pixel clock.
> +
> +Optional properties for HDMI:
> +- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
*-gpio is deprecated, so "hpd-gpios".
Really, I think this and ddc should be in hdmi-connector binding node.
What has been done for bindings so far is all over the map though.
> + as an interrupt/status bit in the HDMI controller
> + itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
> +
> +Example:
> +pixelvalve at 7e807000 {
> + compatible = "brcm,bcm2835-pixelvalve2";
> + reg = <0x7e807000 0x100>;
> + interrupts = <2 10>; /* pixelvalve */
> +};
> +
> +hvs at 7e40 {
> + compatible = "brcm,bcm2835-hvs";
> + reg = <0x7e40 0x6000>;
> + interrupts = <2 1>;
> +};
> +
> +hdmi: hdmi at 7e902000 {
> + compatible = "brcm,bcm2835-hdmi";
> + reg = <0x7e902000 0x600>,
> + <0x7e808000 0x100>;
> + interrupts = <2 8>, <2 9>;
> + ddc = <&i2c2>;
> + hpd-gpio = <&gpio 46 GPIO_ACTIVE_HIGH>;
> + clocks = <&clocks BCM2835_PLLH_PIX>,
> +<&clocks BCM2835_CLOCK_HSM>;
> + clock-names = "pixel", "hdmi";
> +};
> +
> +vc4: gpu at 7e4c {
> + compatible = "brcm,bcm2835-vc4";
> +};
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] of: add URT UMSH-8596MD-xT panel DT bindings
On Thu, Oct 8, 2015 at 3:27 AM, Thierry Reding wrote: > On Wed, Oct 07, 2015 at 11:00:51PM +0200, Maciej S. Szmigiero wrote: >> This patch adds DT bindings for United Radiant Technology >> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels. >> >> Signed-off-by: Maciej Szmigiero >> --- >> Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt | 12 >> >> 1 file changed, 12 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >> >> diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >> b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >> new file mode 100644 >> index 000..57c5fa4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >> @@ -0,0 +1,12 @@ >> +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel >> + >> +Supported are LVDS versions (-11T, -19T) and parallel ones >> +(-T, -1T, -7T, -20T). >> + >> +Required properties: >> +- compatible: should be one of: >> + "urt,umsh-8596md-t", "urt,umsh-8596md-1t", "urt,umsh-8596md-7t", >> + "urt,umsh-8596md-11t", "urt,umsh-8596md-19t" or "urt,umsh-8596md-20t". > > I'd probably list each of these on a single line for slightly more > clarity, but no need to respin because of that. > > Rob, I remember there was some discussion a while back on whether or not > there should be a standard way of describing lists of compatible values, > do you know if anything was ever concluded on that topic? We're working to move the documentation to YAML and describe constraints like this with logic expressions, but we haven't settled on anything yet. This case will probably be just one string per line. Rob
[PATCH 15/22] drm/i915: CHV: Pipe level CSC correction
On 10 October 2015 at 06:26, Sharma, Shashank
wrote:
> On 10/10/2015 5:13 AM, Emil Velikov wrote:
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
>> wrote:
>>>
>>> CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
>>> that needs to be programmed into CGM (Color Gamut Mapping) registers.
>>>
>>> This patch does the following:
>>> 1. Attaches CSC property to CRTC
>>> 2. Adds the core function to program CSC correction values
>>> 3. Adds CSC correction macros
>>>
>>> Signed-off-by: Shashank Sharma
>>> Signed-off-by: Kausal Malladi
>>> Signed-off-by: Kumar, Kiran S
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h| 8 +++
>>> drivers/gpu/drm/i915/intel_color_manager.c | 94
>>> ++
>>> drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
>>> 3 files changed, 121 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index c32e35d..5825ab2 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
>>> #define _PIPE_DEGAMMA_BASE(pipe) \
>>> (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
>>> PIPEC_CGM_DEGAMMA))
>>>
>>> +#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE +
>>> 0x67900)
>>> +#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE +
>>> 0x69900)
>>> +#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE +
>>> 0x6B900)
>>> +#define _PIPE_CSC_BASE(pipe) \
>>> + (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
>>> +
>>> +
>>> +
>>> #endif /* _I915_REG_H_ */
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index bbfe185..433e50a 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -27,6 +27,93 @@
>>>
>>> #include "intel_color_manager.h"
>>>
>>> +static s16 chv_prepare_csc_coeff(s64 csc_value)
>>> +{
>>> + s32 csc_int_value;
>>> + u32 csc_fract_value;
>>> + s16 csc_s3_12_format;
>>
>> The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
>> correct. Seem like the fix got merged into another patch :\
>>
> Can you please elaborate this comment, I dont get it.
>
You have two typos above s16 > s32 which you've fixed in the next
patch. That fix should belong here imho.
[snip]
>>> + while (count < CSC_MAX_VALS) {
>>> + temp = chv_prepare_csc_coeff(
>>> + csc_data->ctm_coeff[count]);
>>> + SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
>>> +
>>> + /*
>>> +* Last value to be written in 1 register.
>>> +* Otherwise, each pair of CSC values go
>>> +* into 1 register
>>> +*/
>>> + if (count != (CSC_MAX_VALS - 1)) {
>>> + count++;
>>> + temp = chv_prepare_csc_coeff(
>>> + csc_data->ctm_coeff[count]);
>>> + SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
>>> + }
>>
>> This looks a bit odd. Use the same approach as in
>> bdw_write_12bit_gamma_precision() ?
>
> Again, can you please give little more details here ?
Take a look at the loop construct in bdw_write_12bit_gamma_precision()
- both of them are essentially doing the same thing.
Here you have
while(i < odd_number) {
foo()
if (if != odd_number-1) {
I++
foo()
}
}
while in the mentioned function
while (i < odd_number -1) {
foo()
foo()
i++
}
foo()
Normally you'd use one or the other. Esp. since this is a single
patchset :-) I'm leaning towards the latter as it's more obvious but
others may prefer the former approach.
Regards,
Emil
[PATCH 09/22] drm/i915: Create color management files
Thanks for the review Emil.
Please find my comments inline
Regards
Shashank
On 10/13/2015 6:29 PM, Emil Velikov wrote:
> On 10 October 2015 at 05:55, Sharma, Shashank
> wrote:
>> On 10/10/2015 4:17 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:28, Shashank Sharma
>>> wrote:
>>> [snip]
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+ ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+ x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define SET_BITS(target, bit_pattern, start_bit, no_bits) \
+ do { \
+ CLEAR_BITS(target, start_bit, no_bits); \
+ target |= (bit_pattern << start_bit); \
+ } while (0)
>>>
>>> It feels suspicious that the kernel does not have macros for either
>>> one of these.
>>>
>>> I would invite you to take a look at include/linux/bitops.h and other
>>> kernel headers.
>>>
>> Thanks for pointing this out, but if you closely observe, these macros are
>> well tested, and created for color management operations, which have
>> specific requirements, like:
>> - pick 8 bits from 16th bit onwards, make them LSB, and give result:
>> GET_BITS
>> - take these 8 bits and move to bit 17th of the word, clearing the existing
>> ones: SET_BITS
>> For core register programming, this was required, so we created it. I would
>> still have a look
>> at the existing ones which you pointed out to avoid any duplication, if they
>> fall directly in the implementation, else I would like to continue with
>> these.
> Unless I'm missing something, these are generic bit manipulation
> macros, are they not ? As such I'd imagine we have some of these
> already available, but I cannot say which ones off-hand.
>
If you closely observe, what set_bit does is picks up the bit pattern
from nth to n+reqd bit, moves it to LSB and returns it. similarly set
bits clears the bits, then copy the bit pattern in the respective bits
and manipulates the shifts. I could not find any such examples which I
can directly use from suggested macros.
> Regards,
> Emil
>
[PATCH 10/22] drm/i915: Register color correction capabilities
Regards
Shashank
On 10/13/2015 6:33 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:01, Sharma, Shashank
> wrote:
>> On 10/10/2015 3:51 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
>>> wrote:
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get applied
beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
after color transformation matrix correction.
These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)
Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.
So finally, This patch does the following:
1. Add a function which loads the platform's color correction
capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
"num_samples_before_ctm" in intel_device_info as gamma and
degamma coefficients vary per platform basis.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/intel_color_manager.c | 33
+-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ad37b25..8bf1d6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -798,6 +798,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+ u16 num_samples_after_ctm;
+ u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and
transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
#include "intel_color_manager.h"
void intel_attach_color_properties_to_crtc(struct drm_device *dev,
- struct drm_mode_object *mode_obj)
+ struct drm_crtc *crtc)
{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_mode_object *mode_obj = &crtc->base;
+
+ /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the
init
+* phase.
+*/
+ if (config->cm_coeff_after_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_after_ctm_property,
+ INTEL_INFO(dev)->num_samples_after_ctm);
+ DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+ }
+
+ if (config->cm_coeff_before_ctm_property) {
+ drm_object_attach_property(mode_obj,
+ config->cm_coeff_before_ctm_property,
+ INTEL_INFO(dev)->num_samples_before_ctm);
+ DRM_DEBUG_DRIVER("
[PATCH 21/22] drm/i915: BDW: Pipe level degamma correction
On 10 October 2015 at 06:31, Sharma, Shashank wrote: > On 10/10/2015 5:19 AM, Emil Velikov wrote: >> >> Hi Shashank, >> >> On 9 October 2015 at 20:29, Shashank Sharma >> wrote: >>> >>> BDW/SKL/BXT supports Degamma color correction feature, which >>> linearizes the non-linearity due to gamma encoded color values. >>> This will be applied before Color Transformation. >>> >>> This patch does the following: >>> 1. Adds the core function to program DeGamma correction values for >>> BDW/SKL/BXT platform >>> 2. Adds DeGamma correction macros/defines >>> >>> Signed-off-by: Shashank Sharma >>> Signed-off-by: Kausal Malladi >>> --- [snip] >> Why don't you use switch statement here ? >> > Same as CHV degamma. Degamma has only 3 conditions (enable/disable and > invalid), and we generally try to accommodate upto 3 condition within if ... > else. That rule sounds a bit funny bth. I'm not sure where it comes from, but as is the codeflow isn't that obvious and the patches look inconsistent with one another. Regards, Emil
[PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
Regards
Shashank
On 10/13/2015 6:38 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:09, Sharma, Shashank
> wrote:
>> On 10/10/2015 4:37 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
>>> wrote:
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
> [snip]
+ length = num_samples * sizeof(struct drm_r32g32b32);
>>>
>>> Calculation can overflow.
>>
>> good catch, will take care of this.
> Actually we do not at all here as the variable is unused. Same applies
> for patch 21/22.
>
Yep, Rob mentioned that in his comment, I have removed this in the
latest patch set I have sent.
> [snip]
+ while (count < num_samples) {
>>>
>>> Using for(i = 0;) loop seems the more common approach ?
>>
>> Nah, we are good with while. The whole color management series prefers while
>> (and me too :))
> Hmm... so you'd prefer your approach/coding style over the one already
> in i915? Feels a bit strange but as long as others are happy fine go
> with it.
>
I am not sure if I915 follows a general rule of using for(...) over
while(), coz I see many instances of using a while in i915_gem,
i915_drv, i915_irq etc, so it should be good. I would see if someone
else can suggest another good reason.
> Regards,
> Emil
>
[PATCH 22/22] drm/i915: BDW: Pipe level CSC correction
On 10 October 2015 at 06:34, Sharma, Shashank
wrote:
> On 10/10/2015 5:24 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma
>> wrote:
>>>
>>> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
>>> that needs to be programmed into respective CSC registers.
>>>
>>> This patch does the following:
>>> 1. Adds the core function to program CSC correction values for
>>> BDW/SKL/BXT platform
>>> 2. Adds CSC correction macros/defines
>>>
>>> Signed-off-by: Shashank Sharma
>>> Signed-off-by: Kausal Malladi
>>> Signed-off-by: Kumar, Kiran S
>>> ---
>>> drivers/gpu/drm/i915/i915_reg.h| 7 ++
>>> drivers/gpu/drm/i915/intel_color_manager.c | 114
>>> -
>>> drivers/gpu/drm/i915/intel_color_manager.h | 12 ++-
>>> 3 files changed, 129 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index ed50f75..0e9d252 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
>>> (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
>>> PAL_PREC_GCMAX_C))
>>>
>>>
>>> +/* BDW CSC correction */
>>> +#define CSC_COEFF_A0x49010
>>> +#define CSC_COEFF_B0x49110
>>> +#define CSC_COEFF_C0x49210
>>> +#define _PIPE_CSC_COEFF(pipe) \
>>> + (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
>>> +
>>> #endif /* _I915_REG_H_ */
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index e659382..0a6c00c 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
>>> return 0;
>>> }
>>>
>>> -static s16 chv_prepare_csc_coeff(s64 csc_value)
>>
>> As mentioned previously, this should be part of the respective patch.
>>
> Agree. Looks like diff is messing up a bit. Will take care of this.
>
>>> +static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
>>> +{
>>> + uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
>>> + int32_t mantissa;
>>> + uint64_t abs_coeff;
>>> +
>>> + coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
>>> + coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
>>> +
>>> + abs_coeff = abs(coeff);
>>> + if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
>>> + /* abs_coeff < 0.125 */
>>> + exponent_bits = 3;
>>> + ls_bit_pos = 19;
>>> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
>>> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
>>> + /* abs_coeff >= 0.125 && val < 0.25 */
>>> + exponent_bits = 2;
>>> + ls_bit_pos = 20;
>>> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
>>> + && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
>>> + /* abs_coeff >= 0.25 && val < 0.5 */
>>> + exponent_bits = 1;
>>> + ls_bit_pos = 21;
>>> + } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
>>> + && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
>>> + /* abs_coeff >= 0.5 && val < 1.0 */
>>> + exponent_bits = 0;
>>> + ls_bit_pos = 22;
>>> + } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
>>> + abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
>>> + /* abs_coeff >= 1.0 && val < 2.0 */
>>> + exponent_bits = 7;
>>> + ls_bit_pos = 23;
>>> + } else {
>>> + /* abs_coeff >= 2.0 && val < 4.0 */
>>> + exponent_bits = 6;
>>> + ls_bit_pos = 24;
>>> + }
>>> +
>>> + mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos,
>>> CSC_MAX_VALS);
>>> + if (coeff < 0) {
>>> + sign_bit = 1;
>>> + mantissa = -mantissa;
>>> + mantissa &= ((1 << CSC_MAX_VALS) - 1);
>>
>> I think there is a macro for this already ?
>>
> Thats for GAMMA_MAX, not for CSC_MAX. Or you mean the whole (1 <<
> CSC_MAX_VALS -1) to be replaced with GET/SET bits ?
What I mean is - the above looks exactly like the GET_BIT_MASK (which
you introduced). Perhaps you can use it ?
Regards,
Emil
[PATCH 16/22] drm/i915: Commit color correction to CRTC
Regards
Shashank
On 10/13/2015 6:47 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:20, Sharma, Shashank
> wrote:
>> On 10/10/2015 4:54 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
>>> wrote:
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_color_manager.c | 44
++
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 3 ++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 433e50a..d5315b2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev,
struct drm_property_blob *blob,
return ret;
}
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+ struct drm_crtc_state *crtc_state)
+{
+ struct drm_property_blob *blob;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ int ret = -EINVAL;
>>>
>>> Most places/people advise against pre-emptively initializing ret.
>>>
>> Just in this case, if makes sense to keep one, coz there might be multiple
>> blobs which we are applying in the commit action, and every blob can return
>> error, from the core function.
>> Assume that there is a situation where both palette_after_ctm(gamma) and CTM
>> is in place, then we will be going through multiple if() cases and have to
>> check the return values.
> When you have an exception of any rule, this implies that you are
> using a suboptimal way of doing things.
>
Not sure, but if you think its that serious, I will gladly change it to
as you suggested :)
+
+ blob = crtc_state->palette_after_ctm_blob;
+ if (blob) {
+ /* Gamma correction is platform specific */
+ if (IS_CHERRYVIEW(dev))
+ ret = chv_set_gamma(dev, blob, crtc);
+
+ if (ret)
+ DRM_ERROR("set Gamma correction failed\n");
>>>
>>> Do we really want to spam dmesg on for each non Cherryview device ?
>>
>> If you see the complete implementation, as IS_GEN8()/IS_SKL is coming up
>> here after IS_CHV(patch 19,20,21) which will cover BDW/SKL/BXT. Anything
>> else which comes here, deserves a DRM_ERROR() as this platform will not be
>> supported.
>>
> Your patches should be independent changes. You cannot say "I'm adding
> something iffy here, but it will be fixed with another patch".
> Otherwise you'll get developer/user X bisecting the kernel, which will
> end up with broken system (flooded dmesg in this case) half way
> through the bisect.
>
There is no confusion here, and its an independent change.
Till this patch, we have color management implemented for CHV only and
any other platforms, should not even register this property, so
naturally it must not hit this part of code. If its hitting, yes I would
like to show this DRM_ERROR. So there is nothing wrong even if we bisect.
> Regards,
> Emil
>
[PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction
Regards
Shashank
On 10/13/2015 6:53 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:21, Sharma, Shashank
> wrote:
>> On 10/10/2015 5:09 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
> [snip]
+ switch (num_samples) {
+ case GAMMA_DISABLE_VALS:
+
+ /* Disable Gamma functionality on Pipe */
>>>
>>> Drop the extra newline between the case and the comment ? Here and below.
>>>
>> I was trying to make it look good :(
> Beauty is in the eye of the beholder. The most important part here is
> consistency.
> Afaict there isn't (m)any i915 code the uses this approach, is there ?
> Some of your other patches use this approach while others don't.
>
I prefer to leave one extra line when I have a comment, so that comment
is more visible, instead of being sandwiched between lines of C code.
May be I missed some places, so I can make it consistent.
> Regards,
> Emil
>
[PATCH 15/22] drm/i915: CHV: Pipe level CSC correction
Regards
Shashank
On 10/13/2015 7:03 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:26, Sharma, Shashank
> wrote:
>> On 10/10/2015 5:13 AM, Emil Velikov wrote:
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
>>> wrote:
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 8 +++
drivers/gpu/drm/i915/intel_color_manager.c | 94
++
drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
3 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c32e35d..5825ab2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
#define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
PIPEC_CGM_DEGAMMA))
+#define PIPEA_CGM_CSC (VLV_DISPLAY_BASE +
0x67900)
+#define PIPEB_CGM_CSC (VLV_DISPLAY_BASE +
0x69900)
+#define PIPEC_CGM_CSC (VLV_DISPLAY_BASE +
0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+ (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index bbfe185..433e50a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@
#include "intel_color_manager.h"
+static s16 chv_prepare_csc_coeff(s64 csc_value)
+{
+ s32 csc_int_value;
+ u32 csc_fract_value;
+ s16 csc_s3_12_format;
>>>
>>> The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
>>> correct. Seem like the fix got merged into another patch :\
>>>
>> Can you please elaborate this comment, I dont get it.
>>
> You have two typos above s16 > s32 which you've fixed in the next
> patch. That fix should belong here imho.
>
Yes, I got that later, current patch set contains this fix.
> [snip]
+ while (count < CSC_MAX_VALS) {
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+
+ /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+ if (count != (CSC_MAX_VALS - 1)) {
+ count++;
+ temp = chv_prepare_csc_coeff(
+ csc_data->ctm_coeff[count]);
+ SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+ }
>>>
>>> This looks a bit odd. Use the same approach as in
>>> bdw_write_12bit_gamma_precision() ?
>>
>> Again, can you please give little more details here ?
> Take a look at the loop construct in bdw_write_12bit_gamma_precision()
> - both of them are essentially doing the same thing.
>
> Here you have
> while(i < odd_number) {
>foo()
>if (if != odd_number-1) {
> I++
> foo()
>}
> }
>
> while in the mentioned function
>
> while (i < odd_number -1) {
>foo()
>foo()
>i++
> }
> foo()
>
> Normally you'd use one or the other. Esp. since this is a single
> patchset :-) I'm leaning towards the latter as it's more obvious but
> others may prefer the former approach.
>
Yes, I got this one also, later :). New patch set has an implementation
similar to this, please have a look.
> Regards,
> Emil
>
[Bug 92240] [SKL] igt/kms_fbcon_fbt/fbc fail
https://bugs.freedesktop.org/show_bug.cgi?id=92240 --- Comment #1 from cprigent --- Reproduced with last setup: Setup -- Hardware: Platform: SKY LAKE Y A0 CPU : Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz (family: 6, model: 78 stepping: 3) MCP : SKL-Y D1 2+2 (ou ULX-D1) QDF : QJK9 CPU : SKL D0 Chipset PCH: Sunrise Point LP C1 CRB : SKY LAKE Y LPDDR3 RVP3 CRB FAB2 Reworks : All Mandatories + FBS02,FBS03, F23, O-02 & O-06 Software Linux : Ubuntu 14.04 LTS 64 bits BIOS : SKLSE2R1.R00.X097.B02.1509020030 ME FW : 11.0.0.1173 Ksc (EC FW): 1.19 kernel 4.3.0-rc3-drm-intel-nightly+ (eb69e51) from git://anongit.freedesktop.org/drm-intel Mesa - 11.0.2 from http://cgit.freedesktop.org/mesa/mesa/ xf86-video-intel - 2.99.917 from http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/ Libdrm - 2.4.64 from http://cgit.freedesktop.org/mesa/drm/ Libva - 1.6.1 from http://cgit.freedesktop.org/libva/ vaapi intel-driver - 1.6.1 from http://cgit.freedesktop.org/vaapi/intel-driver Cairo - 1.14.2 from http://cgit.freedesktop.org/cairo Xorg Xserver - 1.17.2 from http://cgit.freedesktop.org/xorg/xserver -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151013/e31bd054/attachment.html>
[PATCH 22/22] drm/i915: BDW: Pipe level CSC correction
Regards
Shashank
On 10/13/2015 7:15 PM, Emil Velikov wrote:
> On 10 October 2015 at 06:34, Sharma, Shashank
> wrote:
>> On 10/10/2015 5:24 AM, Emil Velikov wrote:
>>>
>>> Hi Shashank,
>>>
>>> On 9 October 2015 at 20:29, Shashank Sharma
>>> wrote:
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
Signed-off-by: Kumar, Kiran S
---
drivers/gpu/drm/i915/i915_reg.h| 7 ++
drivers/gpu/drm/i915/intel_color_manager.c | 114
-
drivers/gpu/drm/i915/intel_color_manager.h | 12 ++-
3 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index ed50f75..0e9d252 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
PAL_PREC_GCMAX_C))
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+ (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e659382..0a6c00c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
}
-static s16 chv_prepare_csc_coeff(s64 csc_value)
>>>
>>> As mentioned previously, this should be part of the respective patch.
>>>
>> Agree. Looks like diff is messing up a bit. Will take care of this.
>>
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+ uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+ int32_t mantissa;
+ uint64_t abs_coeff;
+
+ coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+ coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+ abs_coeff = abs(coeff);
+ if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+ /* abs_coeff < 0.125 */
+ exponent_bits = 3;
+ ls_bit_pos = 19;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+ /* abs_coeff >= 0.125 && val < 0.25 */
+ exponent_bits = 2;
+ ls_bit_pos = 20;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+ && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+ /* abs_coeff >= 0.25 && val < 0.5 */
+ exponent_bits = 1;
+ ls_bit_pos = 21;
+ } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+ && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+ /* abs_coeff >= 0.5 && val < 1.0 */
+ exponent_bits = 0;
+ ls_bit_pos = 22;
+ } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+ abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+ /* abs_coeff >= 1.0 && val < 2.0 */
+ exponent_bits = 7;
+ ls_bit_pos = 23;
+ } else {
+ /* abs_coeff >= 2.0 && val < 4.0 */
+ exponent_bits = 6;
+ ls_bit_pos = 24;
+ }
+
+ mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos,
CSC_MAX_VALS);
+ if (coeff < 0) {
+ sign_bit = 1;
+ mantissa = -mantissa;
+ mantissa &= ((1 << CSC_MAX_VALS) - 1);
>>>
>>> I think there is a macro for this already ?
>>>
>> Thats for GAMMA_MAX, not for CSC_MAX. Or you mean the whole (1 <<
>> CSC_MAX_VALS -1) to be replaced with GET/SET bits ?
> What I mean is - the above looks exactly like the GET_BIT_MASK (which
> you introduced). Perhaps you can use it ?
>
Yes, Agree. but in later code review phase we realized that we dont even
need this masking for mantissa. New patch set doesnt have this &ing, so
we dont need this.
> Regards,
> Emil
>
[PATCH 10/22] drm/i915: Register color correction capabilities
On 13 October 2015 at 14:36, Sharma, Shashank
wrote:
> On 10/13/2015 6:33 PM, Emil Velikov wrote:
>>
>> On 10 October 2015 at 06:01, Sharma, Shashank
>> wrote:
>>>
>>> On 10/10/2015 3:51 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma
wrote:
>
>
> From DRM color management:
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
> color transformation matrix of 9 correction values gets
> applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
> beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
> after color transformation matrix correction.
>
> These color correction capabilities may differ per platform, supporting
> various different no. of correction coefficients. So DRM color manager
> support few properties using which a user space can query the
> platform's
> capability, and prepare color correction accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Now, Intel color manager registers:
> ==
> 1. Gamma correction property as "palette_after_ctm" property
> 2. Degamma correction capability as "palette_bafore_ctm" property
> capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
>
> So finally, This patch does the following:
> 1. Add a function which loads the platform's color correction
> capabilities in the cm_crtc_palette_capabilities_property
> structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
> getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
> "num_samples_before_ctm" in intel_device_info as gamma and
> degamma coefficients vary per platform basis.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
>drivers/gpu/drm/i915/i915_drv.h| 2 ++
>drivers/gpu/drm/i915/intel_color_manager.c | 33
> +-
>2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index ad37b25..8bf1d6f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
> u8 num_sprites[I915_MAX_PIPES];
> u8 gen;
> u8 ring_mask; /* Rings supported by the HW */
> + u16 num_samples_after_ctm;
> + u16 num_samples_before_ctm;
> DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> /* Register offsets for the various display pipes and
> transcoders */
> int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..e466748 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -28,6 +28,37 @@
>#include "intel_color_manager.h"
>
>void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> - struct drm_mode_object *mode_obj)
> + struct drm_crtc *crtc)
>{
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_mode_object *mode_obj = &crtc->base;
> +
> + /*
> +* Register:
> +* =
> +* Gamma correction as palette_after_ctm property
> +* Degamma correction as palette_before_ctm property
> +*
> +* Load:
> +* =
> +* no. of coefficients supported on this platform for gamma
> +* and degamma with the query properties. A user
> +* space agent should read these query property, and prepare
> +* the color correction values accordingly. Its expected from
> the
> +* driver to load the right number of coefficients during the
> init
> +* phase.
> +*/
> + if (config->cm_coeff_after_ctm_property) {
> + drm_object_attach_property(mode_obj,
> + config->cm_coeff_after_ctm_property,
> +
> INTEL_INFO(dev)->num_samples_after_ctm);
> + DRM_DEBUG_DRIVER("Gamma query property initialized\n");
> + }
> +
> + if (config->cm_coeff_before_ctm_property) {
> + drm_object_attach_property(mode_obj,
> +
[PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
On 13 October 2015 at 14:40, Sharma, Shashank wrote: > I am not sure if I915 follows a general rule of using for(...) over while(), > coz I see many instances of using a while in i915_gem, i915_drv, i915_irq > etc, so it should be good. I would see if someone else can suggest another > good reason. I'm not saying "you should never use while loops", but more of "people use for loops when accessing arrays of information". I cannot see any cases of the latter in i915. Perhaps I'm looking at some old code ? The point I'm trying to make here is that people are unlikely to make comments about such trivial nitpicks (bikeshedding), but new contributions should stick with the existing approach, rather than going for "I like XXX" :) Take any and all of my with a grain of salt, just in case. Regards, Emil
[PATCH 10/22] drm/i915: Register color correction capabilities
> Do you have a link handy ? I suspect that something else was mentioned in
> that comment as splitting function declaration and definition is extremely
> uncommon
Yep, maybe I misunderstood. I will add the definition here.
Regards
Shashank
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Tuesday, October 13, 2015 7:24 PM
To: Sharma, Shashank
Cc: Matheson, Annie J; Bradford, Robert; Palleti, Avinash Reddy; intel-gfx at
lists.freedesktop.org; ML dri-devel; Mukherjee, Indranil; Bish, Jim; Barnes,
Jesse; Smith, Gary K; Kausal Malladi; Vetter, Daniel; Kumar, Kiran S
Subject: Re: [PATCH 10/22] drm/i915: Register color correction capabilities
On 13 October 2015 at 14:36, Sharma, Shashank
wrote:
> On 10/13/2015 6:33 PM, Emil Velikov wrote:
>>
>> On 10 October 2015 at 06:01, Sharma, Shashank
>>
>> wrote:
>>>
>>> On 10/10/2015 3:51 AM, Emil Velikov wrote:
Hi Shashank,
On 9 October 2015 at 20:29, Shashank Sharma
wrote:
>
>
> From DRM color management:
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
> color transformation matrix of 9 correction values gets
> applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
> beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
> after color transformation matrix correction.
>
> These color correction capabilities may differ per platform,
> supporting various different no. of correction coefficients. So
> DRM color manager support few properties using which a user space
> can query the platform's capability, and prepare color correction
> accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Now, Intel color manager registers:
> ==
> 1. Gamma correction property as "palette_after_ctm" property 2.
> Degamma correction capability as "palette_bafore_ctm" property
> capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
>
> So finally, This patch does the following:
> 1. Add a function which loads the platform's color correction
> capabilities in the cm_crtc_palette_capabilities_property
> structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
> getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
> "num_samples_before_ctm" in intel_device_info as gamma and
> degamma coefficients vary per platform basis.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
>drivers/gpu/drm/i915/i915_drv.h| 2 ++
>drivers/gpu/drm/i915/intel_color_manager.c | 33
> +-
>2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index ad37b25..8bf1d6f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
> u8 num_sprites[I915_MAX_PIPES];
> u8 gen;
> u8 ring_mask; /* Rings supported by the HW */
> + u16 num_samples_after_ctm;
> + u16 num_samples_before_ctm;
> DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> /* Register offsets for the various display pipes and
> transcoders */
> int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..e466748 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -28,6 +28,37 @@
>#include "intel_color_manager.h"
>
>void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> - struct drm_mode_object *mode_obj)
> + struct drm_crtc *crtc)
>{
> + struct drm_mode_config *config = &dev->mode_config;
> + struct drm_mode_object *mode_obj = &crtc->base;
> +
> + /*
> +* Register:
> +* =
> +* Gamma correction as palette_after_ctm property
> +* Degamma correction as palette_before_ctm property
> +*
> +* Load:
> +* =
> +* no. of coefficients supported on this platform for gamma
> +* and degamma with the query properties. A user
> +* space agent should read these query property, and prepar
[PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction
Regards Shashank On 10/13/2015 7:29 PM, Emil Velikov wrote: > On 13 October 2015 at 14:40, Sharma, Shashank > wrote: > >> I am not sure if I915 follows a general rule of using for(...) over while(), >> coz I see many instances of using a while in i915_gem, i915_drv, i915_irq >> etc, so it should be good. I would see if someone else can suggest another >> good reason. > I'm not saying "you should never use while loops", but more of "people > use for loops when accessing arrays of information". I cannot see any > cases of the latter in i915. Perhaps I'm looking at some old code ? > > The point I'm trying to make here is that people are unlikely to make > comments about such trivial nitpicks (bikeshedding), but new > contributions should stick with the existing approach, rather than > going for "I like XXX" :) > > Take any and all of my with a grain of salt, just in case. > Its a very well written and logical comment, but I like this last line the most :) :) > Regards, > Emil >
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
On 13 October 2015 at 13:16, Michel Thierry wrote: > On 10/6/2015 2:12 PM, Michel Thierry wrote: >> >> On 10/5/2015 7:06 PM, Kristian Høgsberg wrote: >>> >>> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry >>> wrote: On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote: > > > On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote: >> >> >> Gen8+ supports 48-bit virtual addresses, but some objects must >> always be >> allocated inside the 32-bit address range. >> >> In specific, any resource used with flat/heapless >> (0x-0xf000) >> General State Heap (GSH) or Instruction State Heap (ISH) must be in a >> 32-bit range, because the General State Offset and Instruction State >> Offset >> are limited to 32-bits. >> >> The i915 driver has been modified to provide a flag to set when the >> 4GB >> limit is not necessary in a given bo >> (EXEC_OBJECT_SUPPORTS_48B_ADDRESS). >> 48-bit range will only be used when explicitly requested. >> >> Callers to the existing drm_intel_bo_emit_reloc function should set >> the >> use_48b_address_range flag beforehand, in order to use full ppgtt >> range. >> >> v2: Make set/clear functions nops on pre-gen8 platforms, and use them >> internally in emit_reloc functions (Ben) >> s/48BADDRESS/48B_ADDRESS/ (Dave) >> v3: Keep set/clear functions internal, no-one needs to use them >> directly. >> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type >> before enabling set/clear function, print full offsets in debug >> statements, using port of lower_32_bits and upper_32_bits >> from linux >> kernel (MichaÅ) >> >> References: >> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html >> Cc: Ben Widawsky >> Cc: MichaÅ Winiarski > > > > +Kristian > > LGTM. > Acked-by: MichaÅ Winiarski > >> Signed-off-by: Michel Thierry Hi Kristian, More comments on this? I've resent the mesa patch with the last changes (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html). MichaÅ has agreed with the interface and will use it for his work. If mesa doesn't plan to use this for now, it's ok. The kernel changes have been done to prevent any regressions when the support 48-bit flag is not set. >>> >>> >>> I didn't get any replies to my last comments on this: >>> >>> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html >>> >>> Basically, I tried explicitly placing buffers above 8G and didn't see >>> the HW problem described (ie it all worked fine). I still think >>> there's some confusion as to what the W/A is about. >>> >>> Here's my take: the W/A is a SW-only workaround to handle the cases >>> where a driver uses heapless and 48-bit ppgtt. The problem is that the >>> heaps are limited to 4G but with 48bit ppgtt a buffer can be placed >>> anywhere it the 48 bit address space. If that happens it's consideredd >>> out-of-bounds for the heap and access fails. To prevent this we need >>> to make sure the bos we address in a heapless fashion are placed below >>> 4g. >>> >>> For mesa, we only configure general state base as heap-less, which >>> affects scratch bos. What this boils down to is that we need the 4G >>> restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS >>> and 3DSTATE_PS (and tesselation stage eventually). Look for the >>> OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c >>> and gen8_ps_state.c >> >> >> I think it also affects _3DSTATE_VIEWPORT_STATE_POINTERS_CC, maybe it >> isn't exclusive to the scratch bos (the error state points to that >> instruction). >> >> > > Hi, > > Anymore inputs about this patch? > AFAIK, if changes are required based on further comments from Kristian, > these will be in the mesa patch[1], not libdrm. Also, MichaÅ will use this > flag in another project. > The comment seems quite brief and I'm not sure it fully addresses Kristian's concern. I'd suspect that providing reference to the HW documentation (confirming your assumption) might be beneficial. Regards, Emil
[PATCH] drm: misc cleanup
Drop unused drm_atomic and fix comment for drm_debug.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 53d09a1..3a8d598 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -37,11 +37,9 @@
#include "drm_legacy.h"
#include "drm_internal.h"
-unsigned int drm_debug = 0;/* 1 to enable debug output */
+unsigned int drm_debug = 0;/* bitmask of DRM_UT_x */
EXPORT_SYMBOL(drm_debug);
-bool drm_atomic = 0;
-
MODULE_AUTHOR(CORE_AUTHOR);
MODULE_DESCRIPTION(CORE_DESC);
MODULE_LICENSE("GPL and additional rights");
--
2.1.0
[PATCH] drm/dp: add DPCD logging
Add a new drm_debug bit for turning on DPCD logging, to aid debugging
with troublesome monitors.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_dp_helper.c | 66 -
include/drm/drmP.h | 6
2 files changed, 58 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 291734e..8e17f55 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -159,6 +159,46 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
}
EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
+static ssize_t aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
+{
+ size_t ret;
+
+ mutex_lock(&aux->hw_mutex);
+
+ DRM_DEBUG_DPCD("%s: req=0x%02x, address=0x%05x, size=%zu\n", aux->name,
+ msg->request, msg->address, msg->size);
+ if (unlikely(drm_debug & DRM_UT_DPCD)) {
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
+ 16, 1, msg->buffer, msg->size, false);
+ break;
+ default:
+ break;
+ }
+ }
+
+ ret = aux->transfer(aux, msg);
+
+ DRM_DEBUG_DPCD("%s: reply=0x%02x, size=%zu\n", aux->name, msg->reply,
ret);
+ if (unlikely(drm_debug & DRM_UT_DPCD)) {
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
+ 16, 1, msg->buffer, ret, false);
+ break;
+ default:
+ break;
+ }
+ }
+
+ mutex_unlock(&aux->hw_mutex);
+
+ return ret;
+}
+
#define AUX_RETRY_INTERVAL 500 /* us */
/**
@@ -194,9 +234,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
*/
for (retry = 0; retry < 32; retry++) {
- mutex_lock(&aux->hw_mutex);
- err = aux->transfer(aux, &msg);
- mutex_unlock(&aux->hw_mutex);
+ err = aux_transfer(aux, &msg);
if (err < 0) {
if (err == -EBUSY)
continue;
@@ -212,15 +250,17 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
return err;
case DP_AUX_NATIVE_REPLY_NACK:
+ DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
err, msg.size);
return -EIO;
case DP_AUX_NATIVE_REPLY_DEFER:
+ DRM_DEBUG_DPCD("native defer\n");
usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
100);
break;
}
}
- DRM_DEBUG_KMS("too many retries, giving up\n");
+ DRM_DEBUG_DPCD("too many retries, giving up\n");
return -EIO;
}
@@ -530,14 +570,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
int max_retries = max(7, drm_dp_i2c_retry_count(msg,
dp_aux_i2c_speed_khz));
for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c);
retry++) {
- mutex_lock(&aux->hw_mutex);
- ret = aux->transfer(aux, msg);
- mutex_unlock(&aux->hw_mutex);
+ ret = aux_transfer(aux, msg);
if (ret < 0) {
if (ret == -EBUSY)
continue;
- DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+ DRM_DEBUG_DPCD("transaction failed: %d\n", ret);
return ret;
}
@@ -551,11 +589,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
break;
case DP_AUX_NATIVE_REPLY_NACK:
- DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n",
ret, msg->size);
+ DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
ret, msg->size);
return -EREMOTEIO;
case DP_AUX_NATIVE_REPLY_DEFER:
- DRM_DEBUG_KMS("native defer\n");
+ DRM_DEBUG_DPCD("native defer\n");
/*
* We could check for I2C bit rate capabilities and if
* available adjust this interval. We could also be
@@ -582,12 +620,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
return ret;
case DP_AUX_I2C_REPLY_NACK:
- DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu\n", ret,
m
[PATCH] drm/dp: add DPCD logging
On Tue, 13 Oct 2015, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
I wish you could find some balance between having the error cases logged
with normal kms debugging vs. having to have full blown aux traffic
debugging to notice everything failed...
At the very least the "too many retries, giving up" should be included
in KMS debugging, maybe more.
BR,
Jani.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_dp_helper.c | 66
> -
> include/drm/drmP.h | 6
> 2 files changed, 58 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 291734e..8e17f55 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -159,6 +159,46 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
> }
> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>
> +static ssize_t aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
> *msg)
> +{
> + size_t ret;
> +
> + mutex_lock(&aux->hw_mutex);
> +
> + DRM_DEBUG_DPCD("%s: req=0x%02x, address=0x%05x, size=%zu\n", aux->name,
> + msg->request, msg->address, msg->size);
> + if (unlikely(drm_debug & DRM_UT_DPCD)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_WRITE:
> + case DP_AUX_I2C_WRITE:
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, msg->size, false);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + ret = aux->transfer(aux, msg);
> +
> + DRM_DEBUG_DPCD("%s: reply=0x%02x, size=%zu\n", aux->name, msg->reply,
> ret);
> + if (unlikely(drm_debug & DRM_UT_DPCD)) {
> + switch (msg->request & ~DP_AUX_I2C_MOT) {
> + case DP_AUX_NATIVE_READ:
> + case DP_AUX_I2C_READ:
> + print_hex_dump(KERN_DEBUG, "DPCD: ", DUMP_PREFIX_OFFSET,
> + 16, 1, msg->buffer, ret, false);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + mutex_unlock(&aux->hw_mutex);
> +
> + return ret;
> +}
> +
> #define AUX_RETRY_INTERVAL 500 /* us */
>
> /**
> @@ -194,9 +234,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
>*/
> for (retry = 0; retry < 32; retry++) {
>
> - mutex_lock(&aux->hw_mutex);
> - err = aux->transfer(aux, &msg);
> - mutex_unlock(&aux->hw_mutex);
> + err = aux_transfer(aux, &msg);
> if (err < 0) {
> if (err == -EBUSY)
> continue;
> @@ -212,15 +250,17 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux,
> u8 request,
> return err;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> + DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
> err, msg.size);
> return -EIO;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> + DRM_DEBUG_DPCD("native defer\n");
> usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
> 100);
> break;
> }
> }
>
> - DRM_DEBUG_KMS("too many retries, giving up\n");
> + DRM_DEBUG_DPCD("too many retries, giving up\n");
> return -EIO;
> }
>
> @@ -530,14 +570,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
> int max_retries = max(7, drm_dp_i2c_retry_count(msg,
> dp_aux_i2c_speed_khz));
>
> for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c);
> retry++) {
> - mutex_lock(&aux->hw_mutex);
> - ret = aux->transfer(aux, msg);
> - mutex_unlock(&aux->hw_mutex);
> + ret = aux_transfer(aux, msg);
> if (ret < 0) {
> if (ret == -EBUSY)
> continue;
>
> - DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> + DRM_DEBUG_DPCD("transaction failed: %d\n", ret);
> return ret;
> }
>
> @@ -551,11 +589,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg)
> break;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> - DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n",
> ret, msg->size);
> + DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
> ret, msg->size);
> return -EREMOTEIO;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> - DRM_DEBUG_KMS("native defer\n");
> + DRM_DEBUG_DPCD("
[PATCH] drm/dp: add DPCD logging
On Tue, Oct 13, 2015 at 10:30 AM, Jani Nikula
wrote:
> On Tue, 13 Oct 2015, Rob Clark wrote:
>> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
>> with troublesome monitors.
>
> I wish you could find some balance between having the error cases logged
> with normal kms debugging vs. having to have full blown aux traffic
> debugging to notice everything failed...
>
> At the very least the "too many retries, giving up" should be included
> in KMS debugging, maybe more.
maybe that should be DRM_ERROR()? Not sure..
For what I was debugging I actually wanted to be able to turn on just
the DPCD logging without having to turn on all the KMS debugging.. but
I can understand the inverse..
BR,
-R
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 66
>> -
>> include/drm/drmP.h | 6
>> 2 files changed, 58 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 291734e..8e17f55 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -159,6 +159,46 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
>> }
>> EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
>>
>> +static ssize_t aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg
>> *msg)
>> +{
>> + size_t ret;
>> +
>> + mutex_lock(&aux->hw_mutex);
>> +
>> + DRM_DEBUG_DPCD("%s: req=0x%02x, address=0x%05x, size=%zu\n", aux->name,
>> + msg->request, msg->address, msg->size);
>> + if (unlikely(drm_debug & DRM_UT_DPCD)) {
>> + switch (msg->request & ~DP_AUX_I2C_MOT) {
>> + case DP_AUX_NATIVE_WRITE:
>> + case DP_AUX_I2C_WRITE:
>> + print_hex_dump(KERN_DEBUG, "DPCD: ",
>> DUMP_PREFIX_OFFSET,
>> + 16, 1, msg->buffer, msg->size, false);
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> + ret = aux->transfer(aux, msg);
>> +
>> + DRM_DEBUG_DPCD("%s: reply=0x%02x, size=%zu\n", aux->name, msg->reply,
>> ret);
>> + if (unlikely(drm_debug & DRM_UT_DPCD)) {
>> + switch (msg->request & ~DP_AUX_I2C_MOT) {
>> + case DP_AUX_NATIVE_READ:
>> + case DP_AUX_I2C_READ:
>> + print_hex_dump(KERN_DEBUG, "DPCD: ",
>> DUMP_PREFIX_OFFSET,
>> + 16, 1, msg->buffer, ret, false);
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> + mutex_unlock(&aux->hw_mutex);
>> +
>> + return ret;
>> +}
>> +
>> #define AUX_RETRY_INTERVAL 500 /* us */
>>
>> /**
>> @@ -194,9 +234,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
>> request,
>>*/
>> for (retry = 0; retry < 32; retry++) {
>>
>> - mutex_lock(&aux->hw_mutex);
>> - err = aux->transfer(aux, &msg);
>> - mutex_unlock(&aux->hw_mutex);
>> + err = aux_transfer(aux, &msg);
>> if (err < 0) {
>> if (err == -EBUSY)
>> continue;
>> @@ -212,15 +250,17 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux,
>> u8 request,
>> return err;
>>
>> case DP_AUX_NATIVE_REPLY_NACK:
>> + DRM_DEBUG_DPCD("native nack (result=%d, size=%zu)\n",
>> err, msg.size);
>> return -EIO;
>>
>> case DP_AUX_NATIVE_REPLY_DEFER:
>> + DRM_DEBUG_DPCD("native defer\n");
>> usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL +
>> 100);
>> break;
>> }
>> }
>>
>> - DRM_DEBUG_KMS("too many retries, giving up\n");
>> + DRM_DEBUG_DPCD("too many retries, giving up\n");
>> return -EIO;
>> }
>>
>> @@ -530,14 +570,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
>> struct drm_dp_aux_msg *msg)
>> int max_retries = max(7, drm_dp_i2c_retry_count(msg,
>> dp_aux_i2c_speed_khz));
>>
>> for (retry = 0, defer_i2c = 0; retry < (max_retries + defer_i2c);
>> retry++) {
>> - mutex_lock(&aux->hw_mutex);
>> - ret = aux->transfer(aux, msg);
>> - mutex_unlock(&aux->hw_mutex);
>> + ret = aux_transfer(aux, msg);
>> if (ret < 0) {
>> if (ret == -EBUSY)
>> continue;
>>
>> - DRM_DEBUG_KMS("transaction failed: %d\n", ret);
>> + DRM_DEBUG_DPCD("transaction failed: %d\n", ret);
>> return ret;
>> }
>>
>> @@ -551,11 +589,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
>> struct drm_dp_aux_msg *msg)
>> break;
>>
>> case
[PATCH] Fixed several comment coding style blasphemies.
Signed-off-by: Michal Hrbek
---
drivers/gpu/vga/vgaarb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index a0b4334..41f3e13 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -96,7 +96,8 @@ static const char *vga_iostate_to_str(unsigned int iostate)
static int vga_str_to_iostate(char *buf, int str_size, int *io_state)
{
/* we could in theory hand out locks on IO and mem
-* separately to userspace but it can cause deadlocks */
+* separately to userspace but it can cause deadlocks
+*/
if (strncmp(buf, "none", 4) == 0) {
*io_state = VGA_RSRC_NONE;
return 1;
@@ -155,13 +156,15 @@ static inline void vga_irq_set_state(struct vga_device
*vgadev, bool state)
/* If we don't ever use VGA arb we should avoid
- turning off anything anywhere due to old X servers getting
- confused about the boot device not being VGA */
+ * turning off anything anywhere due to old X servers getting
+ * confused about the boot device not being VGA
+ */
static void vga_check_first_use(void)
{
/* we should inform all GPUs in the system that
* VGA arb has occurred and to try and disable resources
-* if they can */
+* if they can
+*/
if (!vga_arbiter_used) {
vga_arbiter_used = true;
vga_arbiter_notify_clients();
@@ -985,11 +988,11 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* TODO: Add this?
- if (io_state == VGA_RSRC_NONE) {
- ret_val = -EPROTO;
- goto done;
- }
- */
+* if (io_state == VGA_RSRC_NONE) {
+* ret_val = -EPROTO;
+* goto done;
+* }
+*/
}
pdev = priv->target;
@@ -1037,10 +1040,10 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* TODO: Add this?
- if (io_state == VGA_RSRC_NONE) {
- ret_val = -EPROTO;
- goto done;
- }
+* if (io_state == VGA_RSRC_NONE) {
+* ret_val = -EPROTO;
+* goto done;
+* }
*/
pdev = priv->target;
@@ -1276,7 +1279,8 @@ static int pci_notify(struct notifier_block *nb, unsigned
long action,
/* For now we're only intereted in devices added and removed. I didn't
* test this thing here, so someone needs to double check for the
-* cases of hotplugable vga cards. */
+* cases of hotplugable vga cards.
+*/
if (action == BUS_NOTIFY_ADD_DEVICE)
notify = vga_arbiter_add_pci_device(pdev);
else if (action == BUS_NOTIFY_DEL_DEVICE)
@@ -1317,7 +1321,8 @@ static int __init vga_arb_device_init(void)
bus_register_notifier(&pci_bus_type, &pci_notifier);
/* We add all pci devices satisfying vga class in the arbiter by
-* default */
+* default
+*/
pdev = NULL;
while ((pdev =
pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
--
2.5.2
