Re: [PATCH v2] drm/exynos/dsi: make te-gpios optional
On 03/15/2017 08:20 PM, Andrzej Hajda wrote: DSI forwards te-gpios interrupts to display controller, but if display controller works in HW-TRIGGER mode this interrupt is not necessary. Making te-gpios property optional allows to avoid generating spare interrupts. With this patch we can get rid of 60 interrupt callbacks per second. Signed-off-by: Andrzej Hajda Reviewed-by: Hoegeun Kwon Best regards, Hoegeun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
On 17.04.2017 08:02, Hoegeun Kwon wrote:
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon
Maybe it would be good to remove te-gpios property - tm2/tm2e uses
hardware trigger, so it is not necessary and generates useless interrupts.
Thanks for your review.
I agree, but I thinks remove the te-gpio property after your patch [1]
has been merged.
[1] https://patchwork.kernel.org/patch/9625383/
Best regards,
Hoegeun
Beside this:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..98ad094 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <27800>, <4>;
};
+&dsi {
+ panel@0 {
+ compatible = "samsung,s6e3hf2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
On 18.04.2017 09:44, Hoegeun Kwon wrote:
> On 04/18/2017 03:00 PM, Andrzej Hajda wrote:
>> On 17.04.2017 08:02, Hoegeun Kwon wrote:
>>> This patch add the panel device tree node for s6e3hf2 display
>>> controller to TM2e dts.
>>>
>>> Signed-off-by: Hoegeun Kwon
>> Maybe it would be good to remove te-gpios property - tm2/tm2e uses
>> hardware trigger, so it is not necessary and generates useless interrupts.
> Thanks for your review.
>
> I agree, but I thinks remove the te-gpio property after your patch [1]
> has been merged.
Patch [1] has been merged about month ago :)
Regards
Andrzej
>
>
> [1] https://patchwork.kernel.org/patch/9625383/
>
> Best regards,
> Hoegeun
>
>> Beside this:
>> Reviewed-by: Andrzej Hajda
>> --
>> Regards
>> Andrzej
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> index 694717a..98ad094 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
>>> @@ -52,6 +52,18 @@
>>> assigned-clock-rates = <27800>, <4>;
>>> };
>>>
>>> +&dsi {
>>> + panel@0 {
>>> + compatible = "samsung,s6e3hf2";
>>> + reg = <0>;
>>> + vdd3-supply = <&ldo27_reg>;
>>> + vci-supply = <&ldo28_reg>;
>>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +};
>>> +
>>> &ldo31_reg {
>>> regulator-name = "TSP_VDD_1.8V_AP";
>>> regulator-min-microvolt = <180>;
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #150 from Alfredo Mendez --- I have an ASUS Strix R9 390 and attempted to get it to work, in a nutshell for those looking for redemption... it didn't work. I tried to switch drivers from radeon to amdgpu, and both equally fail randomly. Setting the DPM to zero reduces the chances of black screening, but expect to encounter them either way. Simply put, the drivers are still bad for the 390's. This bug is about to become three years old, and while 17.04 already came out with the same issue, this should be set to its highest level, its been long overdue with no real progress. I would love to collaborate in fixing this issue, but I am simply below the average linux user standard. I hope more people can volunteer in finding the culprit, but for now it points out to be more power related. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: atmel-hlcdc: Uninitialized return in atmel_hlcdc_create_outputs()
On Sat, 15 Apr 2017 22:21:42 +0300
Dan Carpenter wrote:
> It's not possible for endpoint to be zero so the test doesn't work. If
> we break on the first iteration through the loop then endpoint is 1 and
> "ret" is uninitialized.
>
> Fixes: ebc944613567 ("drm: convert drivers to use
> drm_of_find_panel_or_bridge")
> Signed-off-by: Dan Carpenter
Acked-by: Boris Brezillon
Daniel, should I directly apply this patch to drm-misc-next-fixes or
should I wait for someone else to take it?
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index f987b4572d4a..65a3bd7a0c00 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -221,7 +221,8 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
> *dev,
> int atmel_hlcdc_create_outputs(struct drm_device *dev)
> {
> struct device_node *remote;
> - int ret, endpoint = 0;
> + int ret = -ENODEV;
> + int endpoint = 0;
>
> while (true) {
> /* Loop thru possible multiple connections to the output */
> @@ -236,7 +237,5 @@ int atmel_hlcdc_create_outputs(struct drm_device *dev)
> return ret;
> }
>
> - if (!endpoint)
> - return -ENODEV;
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
2017년 04월 18일 14:55에 Andrzej Hajda 이(가) 쓴 글: > On 17.04.2017 08:02, Hoegeun Kwon wrote: >> This patch supports TM2e panel and the panel has 1600x2560 resolution >> in 5.65" physical. >> >> This identify panel type with compatibility string, also invoke >> display mode that matches the type. So add the check code for s6e3ha2 >> compatibility and s6e3hf2 type and select the drm_display_mode of >> default and edge type. >> >> Signed-off-by: Hoegeun Kwon > Reviewed-by: Andrzej Hajda Reviewed-by: Inki Dae Thanks, Inki Dae > > -- > Regards > Andrzej > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
On 04/18/2017 04:56 PM, Andrzej Hajda wrote: On 18.04.2017 09:44, Hoegeun Kwon wrote: On 04/18/2017 03:00 PM, Andrzej Hajda wrote: On 17.04.2017 08:02, Hoegeun Kwon wrote: This patch add the panel device tree node for s6e3hf2 display controller to TM2e dts. Signed-off-by: Hoegeun Kwon Maybe it would be good to remove te-gpios property - tm2/tm2e uses hardware trigger, so it is not necessary and generates useless interrupts. Thanks for your review. I agree, but I thinks remove the te-gpio property after your patch [1] has been merged. Patch [1] has been merged about month ago :) Ah..., My mistake :) I will send ver3 patchset without te-gpio property. Best regards, Hoegeun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1973-ga4b2d83360ec)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1973-ga4b2d83360ec) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d83360ec/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1973-ga4b2d83360ec Git Commit: a4b2d83360ec1673de58ff43d7b6fd5deaba1ce6 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
[PATCH v3 3/3] arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
This patch add the panel device tree node for s6e3hf2 display
controller to TM2e dts.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 694717a..b73e123 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -52,6 +52,17 @@
assigned-clock-rates = <27800>, <4>;
};
+&dsi {
+ panel@0 {
+ compatible = "samsung,s6e3hf2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <180>;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board
Hi all, The purpose of this patch is add support for s6e3hf2 AMOLED panel on the TM2e board. The panel has 1600x2560 resolution in 5.65" physical panel in the TM2e device. The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"), but resolution and some command message are different. So it can be distinguished as a compatiblitiy string. Best regards, Hoegeun Changes for V3: - Remove te-gpios property in dts. - Added Reviewed-by: Andrzej Hajda on all patches. - Added Reviewed-by: Inki Dae on patch (2/3). Changes for V2: - Add new compatible string to "samsung,s6e3ha2.txt binding with comments. - Fix the panel name from s6e3ha2-e to s6e3hf2 Hoegeun Kwon (3): dt-bindings: Add support for samsung s6e3hf2 panel drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board .../bindings/display/panel/samsung,s6e3ha2.txt | 5 +- arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 64 +++--- 3 files changed, 72 insertions(+), 8 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board
This patch supports TM2e panel and the panel has 1600x2560 resolution
in 5.65" physical.
This identify panel type with compatibility string, also invoke
display mode that matches the type. So add the check code for s6e3ha2
compatibility and s6e3hf2 type and select the drm_display_mode of
default and edge type.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Reviewed-by: Inki Dae
---
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 64 ---
1 file changed, 57 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 4cc08d7..c7b418b 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#define S6E3HA2_MIN_BRIGHTNESS 0
@@ -218,6 +219,16 @@
0x1d, 0x1e, 0x1f, 0x20, 0x21
};
+enum s6e3ha2_type {
+ HA2_TYPE,
+ HF2_TYPE,
+};
+
+struct s6e3ha2_panel_desc {
+ const struct drm_display_mode *mode;
+ enum s6e3ha2_type type;
+};
+
struct s6e3ha2 {
struct device *dev;
struct drm_panel panel;
@@ -226,6 +237,8 @@ struct s6e3ha2 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+
+ const struct s6e3ha2_panel_desc *desc;
};
static int s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
@@ -283,11 +296,19 @@ static int s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
static int s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
{
s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+ if (ctx->desc->type == HF2_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67, 0x40, 0xc5);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
- s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62, 0x40,
- 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
+ if (ctx->desc->type == HA2_TYPE)
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+ else
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x14, 0x6d,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+
return 0;
}
@@ -583,7 +604,7 @@ static int s6e3ha2_enable(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode default_mode = {
+static const struct drm_display_mode s6e3ha2_mode = {
.clock = 222372,
.hdisplay = 1440,
.hsync_start = 1440 + 1,
@@ -597,16 +618,41 @@ static int s6e3ha2_enable(struct drm_panel *panel)
.flags = 0,
};
+static const struct s6e3ha2_panel_desc samsung_s6e3ha2 = {
+ .mode = &s6e3ha2_mode,
+ .type = HA2_TYPE,
+};
+
+static const struct drm_display_mode s6e3hf2_mode = {
+ .clock = 247856,
+ .hdisplay = 1600,
+ .hsync_start = 1600 + 1,
+ .hsync_end = 1600 + 1 + 1,
+ .htotal = 1600 + 1 + 1 + 1,
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 1,
+ .vsync_end = 2560 + 1 + 1,
+ .vtotal = 2560 + 1 + 1 + 15,
+ .vrefresh = 60,
+ .flags = 0,
+};
+
+static const struct s6e3ha2_panel_desc samsung_s6e3hf2 = {
+ .mode = &s6e3hf2_mode,
+ .type = HF2_TYPE,
+};
+
static int s6e3ha2_get_modes(struct drm_panel *panel)
{
struct drm_connector *connector = panel->connector;
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(panel->drm, &default_mode);
+ mode = drm_mode_duplicate(panel->drm, ctx->desc->mode);
if (!mode) {
DRM_ERROR("failed to add mode %ux%ux@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- default_mode.vrefresh);
+ ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
+ ctx->desc->mode->vrefresh);
return -ENOMEM;
}
@@ -642,6 +688,7 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
+ ctx->desc = of_device_get_match_data(dev);
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
@@ -717,7 +764,10 @@ static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
}
static const struct of_device_id s6e3ha2_of_match[] = {
- { .compatible = "samsung,s6e3ha2" },
+ { .compatible = "samsung,s6e3ha2",
+ .data = &samsung_s6e3ha2 },
+ { .compatible = "samsung,s6e3hf2",
+ .data = &samsung_s6e3hf2 },
{ }
};
MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
--
1.9.1
__
[PATCH v3 1/3] dt-bindings: Add support for samsung s6e3hf2 panel
The samsung s6e3hf2 panel is a 5.65" 1600x2560 AMOLED panel connected using MIPI-DSI interfaces. The s6e3hf2 is add to samsung,s6e3ha2.txt binding because it is a panel similar to the s6e3ha2. So add the compatible string and comments. Signed-off-by: Hoegeun Kwon Reviewed-by: Andrzej Hajda --- Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt index 18854f4..4acea25 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt @@ -1,7 +1,10 @@ Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel +Samsung S6E3HF2 5.65" 1600x2560 AMOLED panel Required properties: - - compatible: "samsung,s6e3ha2" + - compatible: should be one of: +"samsung,s6e3ha2", +"samsung,s6e3hf2". - reg: the virtual channel number of a DSI peripheral - vdd3-supply: I/O voltage supply - vci-supply: voltage supply for analog circuits -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 invert backlight brightness
On Mon, 17 Apr 2017, Georgios Dakidis wrote: > lspci -n > 00:02.0 0300: 8086:0f31 (rev 0e) > lspci -nn > 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor > Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e) > > dmesg ( with drm.debug=14) Hi there, did you not get my reply to your earlier mail? 87bmsh39aj.fsf@intel.com">http://mid.mail-archive.com/87bmsh39aj.fsf@intel.com BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/11] drm/sun4i: abstract a engine type
Hi,
Thanks for that rework.
On Sun, Apr 16, 2017 at 08:08:43PM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.
>
> Abstract the engine type to void * and a ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> A dedicated Kconfig option is also added to control whether
> sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
> be built. As we removed the codes in CRTC code that directly call the
> layer code, we can now extract the layer part and combine it with the
> backend part into a new module, sun4i-backend.ko.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v4:
> - Comments to tag the color correction functions as optional.
> - Check before calling the optional functions.
> - Change layers_init to satisfy new PATCH v4 04/11.
>
> drivers/gpu/drm/sun4i/Kconfig | 10 ++
> drivers/gpu/drm/sun4i/Makefile| 6 --
> drivers/gpu/drm/sun4i/sun4i_backend.c | 26 +++---
> drivers/gpu/drm/sun4i/sun4i_backend.h | 5 -
> drivers/gpu/drm/sun4i/sun4i_crtc.c| 14 +++---
> drivers/gpu/drm/sun4i/sun4i_crtc.h| 7 ---
> drivers/gpu/drm/sun4i/sun4i_drv.h | 3 ++-
> drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_layer.h | 3 ++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c| 2 +-
> drivers/gpu/drm/sun4i/sun4i_tv.c | 11 ++-
> drivers/gpu/drm/sun4i/sunxi_engine.h | 35
> +++
> 12 files changed, 91 insertions(+), 33 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sunxi_engine.h
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index a4b357db8856..5a8227f37cc4 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -12,3 +12,13 @@ config DRM_SUN4I
> Choose this option if you have an Allwinner SoC with a
> Display Engine. If M is selected the module will be called
> sun4i-drm.
> +
> +config DRM_SUN4I_BACKEND
> + tristate "Support for Allwinner A10 Display Engine Backend"
> + depends on DRM_SUN4I
> + default DRM_SUN4I
> + help
> + Choose this option if you have an Allwinner SoC with the
> + original Allwinner Display Engine, which has a backend to
> + do some alpha blending and feed graphics to TCON. If M is
> + selected the module will be called sun4i-backend.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 59b757350a1f..1db1068b9be1 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -5,9 +5,11 @@ sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
> sun4i-tcon-y += sun4i_dotclock.o
> sun4i-tcon-y += sun4i_crtc.o
> -sun4i-tcon-y += sun4i_layer.o
> +
> +sun4i-backend-y += sun4i_layer.o
> +sun4i-backend-y += sun4i_backend.o
>
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o sun4i-tcon.o
> -obj-$(CONFIG_DRM_SUN4I) += sun4i_backend.o
> +obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index d660741ba475..a16c96a002a4 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -23,6 +23,8 @@
>
> #include "sun4i_backend.h"
> #include "sun4i_drv.h"
> +#include "sun4i_layer.h"
> +#include "sunxi_engine.h"
>
> static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x0107, 0x0204, 0x0064, 0x0108,
> @@ -30,9 +32,10 @@ static const u32 sunxi_rgb2yuv_coef[12] = {
> 0x01c1, 0x3e88, 0x3fb8, 0x0808
> };
>
> -void sun4i_backend_apply_color_correction(struct sun4i_backend *backend)
> +static void sun4i_backend_apply_color_correction(void *engine)
> {
> int i;
> + struct sun4i_backend *backend = engine;
I'm not really fond of passing an opaque pointer here, and hope that
things will work out.
I think having a common structure, holding the common thingsand a more
specific structure for that one would work better.
Something like
struct sunxi_engine {
struct regmap*regs;
};
struct sun4i_backend {
struct sunxi_engine engine;
struct clk *sat_clk;
struct reset_control*sat_reset;
};
static void sun4i_backend_apply_color_correction(struct sunxi_engine *engine)
struct sun4i_backend *backend = container_of(engine, struct
sun4i_backend, engine);
...
> +static const struct sunxi_engine_ops sun4i_back
Re: [PATCH v2 3/5] drm: omapdrm: Remove legacy buffer synchronization support
Hi Daniel, On Tuesday 18 Apr 2017 08:20:29 Daniel Vetter wrote: > On Sat, Apr 15, 2017 at 11:16 AM, Laurent Pinchart wrote: > > - DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_PREP, ioctl_gem_cpu_prep, > > + DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_PREP, ioctl_gem_cpu_prep_fini, > > DRM_AUTH | DRM_RENDER_ALLOW), > > - DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_FINI, ioctl_gem_cpu_fini, > > + DRM_IOCTL_DEF_DRV(OMAP_GEM_CPU_FINI, ioctl_gem_cpu_prep_fini, > > DRM_AUTH | DRM_RENDER_ALLOW), > > drm_noop and drm_invalid_op give you 2 default options for this, for > even less code. Thank you for the tip, I didn't know about that. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
On Sun, Apr 16, 2017 at 08:08:44PM +0800, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in their new SoCs, which comes
> with mixers to do graphic processing and feed data to TCON, like the old
> backends and frontends.
>
> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>
> Currently a lot of functions are still missing -- more investigations
> are needed to gain enough information for them.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v4:
> - Killed some dead code according to Jernej.
>
> drivers/gpu/drm/sun4i/Kconfig | 10 +
> drivers/gpu/drm/sun4i/Makefile | 4 +
> drivers/gpu/drm/sun4i/sun8i_layer.c | 142 ++
> drivers/gpu/drm/sun4i/sun8i_layer.h | 36
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 381
>
> drivers/gpu/drm/sun4i/sun8i_mixer.h | 131 +
> 6 files changed, 704 insertions(+)
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_layer.h
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_mixer.h
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index 5a8227f37cc4..15557484520d 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -22,3 +22,13 @@ config DRM_SUN4I_BACKEND
> original Allwinner Display Engine, which has a backend to
> do some alpha blending and feed graphics to TCON. If M is
> selected the module will be called sun4i-backend.
> +
> +config DRM_SUN4I_SUN8I_MIXER
> + tristate "Support for Allwinner Display Engine 2.0 Mixer"
> + depends on DRM_SUN4I
> + default MACH_SUN8I
> + help
> + Choose this option if you have an Allwinner SoC with the
> + Allwinner Display Engine 2.0, which has a mixer to do some
> + graphics mixture and feed graphics to TCON, If M is
> + selected the module will be called sun8i-mixer.
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 1db1068b9be1..7625c2dad1bb 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -9,7 +9,11 @@ sun4i-tcon-y += sun4i_crtc.o
> sun4i-backend-y += sun4i_layer.o
> sun4i-backend-y += sun4i_backend.o
>
> +sun8i-mixer-y += sun8i_layer.o
> +sun8i-mixer-y += sun8i_mixer.o
> +
> obj-$(CONFIG_DRM_SUN4I) += sun4i-drm.o sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
> +obj-$(CONFIG_DRM_SUN4I_SUN8I_MIXER) += sun8i-mixer.o
Please align the value using tabs.
> obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
> obj-$(CONFIG_DRM_SUN4I) += sun4i_tv.o
> diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_layer.c
> new file mode 100644
> index ..d70a90d963b0
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (C) Icenowy Zheng
> + *
> + * Based on sun4i_layer.h, which is:
> + * Copyright (C) 2015 Free Electrons
> + * Copyright (C) 2015 NextThing Co
> + *
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sun4i_crtc.h"
> +#include "sun8i_layer.h"
> +#include "sun8i_mixer.h"
> +
> +struct sun8i_plane_desc {
> +enum drm_plane_type type;
> +const uint32_t *formats;
> +uint32_tnformats;
> +};
> +
> +static int sun8i_mixer_layer_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + return 0;
> +}
> +
> +static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
> +struct drm_plane_state
> *old_state)
> +{
> + struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> + struct sun8i_mixer *mixer = layer->mixer;
> +
> + sun8i_mixer_layer_enable(mixer, layer->id, false);
> +}
> +
> +static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> + struct sun8i_mixer *mixer = layer->mixer;
> +
> + sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
> + sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
> + sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
> + sun8i_mixer_layer_enable(mixer, layer->id, true);
> +}
> +
> +static struct drm_plane_helper_funcs sun8i_mixer_layer_helper_funcs = {
> + .atomic_check = sun8i_mixer_layer_atomic_check,
> +
Re: [PATCH 09/11] drm/sun4i: Support two display pipelines
Hi Chen-Yu,
On Sat, Apr 08, 2017 at 01:30:55AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Mar 9, 2017 at 10:40 PM, Maxime Ripard
> wrote:
> > On Thu, Mar 09, 2017 at 07:20:30PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
> >> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
> >> >> Some Allwinner SoCs have two display pipelines (frontend -> backend ->
> >> >> tcon).
> >> >>
> >> >> Previously we only supported one pipeline. This patch extends the
> >> >> current driver to support two. It extends the tcon and backend pointers
> >> >> in sun4i_drv into arrays, and makes the related bind functions store
> >> >> the pointer into said arrays based on the id fetched from the device
> >> >> tree. In the case of the tcons, it falls back to a first come order
> >> >> if no encoders that can be used for differentiating the tcons are
> >> >> defined. The driver's depth-first traversal of the of graph, coupled
> >> >> with the increasing address ordering of the of graph endpoints, and
> >> >> the fact that tcon0 should always be enabled for the tcon/encoder
> >> >> mux to be accessible, means that tcon1 would always come after tcon0.
> >> >>
> >> >> Assignment of the device structure into sun4i_drv is moved to the end
> >> >> of the bind function, when all possible error checks have passed.
> >> >>
> >> >> This patch also drops a trailing 0 in one of the backend probe messages.
> >> >>
> >> >> Signed-off-by: Chen-Yu Tsai
> >> >> ---
> >> >> drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
> >> >> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> >> >> drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
> >> >> drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
> >> >> 4 files changed, 29 insertions(+), 13 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> index f3c92d54c8e4..8d22efd5a9cc 100644
> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> >> @@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev,
> >> >> struct device *master,
> >> >> if (!backend)
> >> >> return -ENOMEM;
> >> >> dev_set_drvdata(dev, backend);
> >> >> - drv->backend = backend;
> >> >>
> >> >> backend->id = sun4i_backend_of_get_id(dev->of_node);
> >> >> if (backend->id < 0)
> >> >> return backend->id;
> >> >>
> >> >> + /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
> >> >> + if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
> >> >> + return -EINVAL;
> >> >> +
> >> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> >> regs = devm_ioremap_resource(dev, res);
> >> >> if (IS_ERR(regs))
> >> >> @@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev,
> >> >> struct device *master,
> >> >> backend->regs = devm_regmap_init_mmio(dev, regs,
> >> >>
> >> >> &sun4i_backend_regmap_config);
> >> >> if (IS_ERR(backend->regs)) {
> >> >> - dev_err(dev, "Couldn't create the backend0 regmap\n");
> >> >> + dev_err(dev, "Couldn't create the backend regmap\n");
> >> >> return PTR_ERR(backend->regs);
> >> >> }
> >> >>
> >> >> @@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev,
> >> >> struct device *master,
> >> >> }
> >> >> }
> >> >>
> >> >> + drv->backend[backend->id] = backend;
> >> >> +
> >> >> /* Reset the registers */
> >> >> for (i = 0x800; i < 0x1000; i += 4)
> >> >> regmap_write(backend->regs, i, 0);
> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> >> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> >> index 767bbadcc85d..c15ecb8343d7 100644
> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> >> @@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device
> >> >> *pdev)
> >> >> struct device_node *np = pdev->dev.of_node;
> >> >> int i, count = 0;
> >> >>
> >> >> - for (i = 0;; i++) {
> >> >> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
> >> >> struct device_node *pipeline = of_parse_phandle(np,
> >> >>
> >> >> "allwinner,pipelines",
> >> >> i);
> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> >> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> >> index 5df50126ff52..ec1c08af47e1 100644
> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> >> @@ -16,9 +16,11 @@
> >> >> #include
> >> >> #include
> >> >>
> >> >> +#define SUN4I_DRM_MAX_PIPELINES 2
> >> >> +
> >> >> struct sun4i_drv {
> >> >> - struct sun4i_ba
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > only format supported by bochs-drm), and we have to interpret that in > > bigendian byte order on the host side to get a correct display. > > I wonder if that is just an oversight from trying to match OpenGL > formats to DRM formats. It's full of gotcha's. > > Did you try with GLAMOR? Do you see a difference with and without > GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a > Mesa software renderer? I think I heard someone say something about > Mesa software on BE... So, did some more testing to see where we stand. Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest here, it drives the qemu stdvga with offb, not bochs-drm. More interesting: RHEL-7.3 (gnome 3.14) works fine too. kernel 3.10, but drm drivers updated to roughly 4.6 level. Runs bochs-drm. mesa 11.2.2. glamour not used. Most recent: Fedora 25 (gnome 3.22) looks mostly ok, but there are rendering glitches, for example in the gnome activities screen (the one you get when you press the windows key). kernel 4.10, mesa 13.0.4. glamor not used, but I think gnome-shell uses opengl (via llvmpipe) for compositing. btw: is there some way to start a wayland session from a shell (i.e. what startx does for xorg)? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Document code of conduct
freedesktop.org has adopted a formal&enforced code of conduct: https://www.fooishbar.org/blog/fdo-contributor-covenant/ https://www.freedesktop.org/wiki/CodeOfConduct/ Besides formalizing things a bit more I don't think this changes anything for us, we've already peer-enforced respectful and constructive interactions since a long time. But it's good to document things properly. v2: Drop confusing note from commit message and clarify the grammer (Chris, Alex and others). Cc: Daniel Stone Cc: Keith Packard Cc: tfh...@err.no Signed-off-by: Daniel Vetter Reviewed-by: Daniel Stone Reviewed-by: Sumit Semwal Acked-by: Archit Taneja Reviewed-by: Martin Peres Acked-by: Thierry Reding Acked-by: Jani Nikula Acked-by: Vincent Abriou Acked-by: Neil Armstrong Reviewed-by: Maarten Lankhorst Acked-by: Brian Starkey Acked-by: Rob Clark Reviewed-by: David Herrmann Acked-by: Sean Paul Reviewed-by: Harry Wentland Reviewed-by: Eric Anholt Acked-by: Alex Deucher Acked-by: Gustavo Padovan Acked-by: Michel Dänzer Acked-by: Laurent Pinchart Acked-by: Sumit Semwal Acked-by: Keith Packard Acked-by: Gabriel Krisman Bertazi --- Documentation/gpu/introduction.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 05a82bdfbca4..fccbe375244d 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one month where feature work can't be merged. The recommended way to deal with that is having a -next tree that's always open, but making sure to not feed it into linux-next during the blackout period. As an example, drm-misc works like that. + +Code of Conduct +--- + +As a freedesktop.org project, dri-devel, and the DRM community, follows the +Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct + +Please conduct yourself in a respectful and civilised manner when +interacting with community members on mailing lists, IRC, or bug +trackers. The community represents the project as a whole, and abusive +or bullying behaviour is not tolerated by the project. -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > Quite true that this proves nothing. However one should note that > > fbcon -> fbdev works, > > BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses > e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses > native endian packed colour values. Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get DRM_FORMAT_XRGB (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify fourcc formats directly). cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2] Header: Add rotation property fields
On 17 April 2017 at 21:13, Robert Foss wrote: > From: Sean Paul > > From drm_crtc.h, for use with the plane "rotation" property. > Please see the include/drm/README. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1975-g4d374295ace9)
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1975-g4d374295ace9) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d374295ace9/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1975-g4d374295ace9 Git Commit: 4d374295ace9e57d83483341e2ad07cad5baf912 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failure Detected: x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig+CONFIG_OF=n: FAIL Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) defconfig+CONFIG_KASAN=y: 4 warnings arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 warnings x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) defconfig+CONFIG_KASAN=y: 5 warnings Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig+CONFIG_OF=n (x86) — FAIL, 0 errors, 0 warnings, 0 section mismatches allnoconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches am200epdkit_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches aspeed_g4_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Tue, 18 Apr 2017 12:00:17 +0200 Gerd Hoffmann wrote: > Hi, > > > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm > > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and > > > only format supported by bochs-drm), and we have to interpret that in > > > bigendian byte order on the host side to get a correct display. > > > > I wonder if that is just an oversight from trying to match OpenGL > > formats to DRM formats. It's full of gotcha's. > > > > Did you try with GLAMOR? Do you see a difference with and without > > GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a > > Mesa software renderer? I think I heard someone say something about > > Mesa software on BE... > > So, did some more testing to see where we stand. > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > here, it drives the qemu stdvga with offb, not bochs-drm. I suppose this proves the virtual machine itself is correct about framebuffer endianess? Except you are running it on a little-endian host machine I presume... > More interesting: RHEL-7.3 (gnome 3.14) works fine too. kernel 3.10, > but drm drivers updated to roughly 4.6 level. Runs bochs-drm. mesa > 11.2.2. glamour not used. > > Most recent: Fedora 25 (gnome 3.22) looks mostly ok, but there are > rendering glitches, for example in the gnome activities screen (the one > you get when you press the windows key). kernel 4.10, mesa 13.0.4. > glamor not used, but I think gnome-shell uses opengl (via llvmpipe) for > compositing. I believe glitches are irrelevant for this topic, what we are interested in is if the colors are right or byte-swapped (also mind alpha/blue etc. swaps). > btw: is there some way to start a wayland session from a shell (i.e. > what startx does for xorg)? Depends on which display server you want to start I believe. I don't know about anything else than Weston, which is 'weston' for a logind-enabled system. Thanks, pq pgpCeh_SSyg2W.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500/psb: Actually use VBT mode when it is found
With LVDS we were incorrectly picking the pre-programmed mode instead of
the prefered mode provided by VBT. Make sure we pick the VBT mode if
one is provided. It is likely that the mode read-out code is still wrong
but this patch fixes the immediate problem on most machines.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78562
Cc:
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_lvds.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 483fdce74e39..97c444856d09 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -760,20 +760,23 @@ void psb_intel_lvds_init(struct drm_device *dev,
if (scan->type & DRM_MODE_TYPE_PREFERRED) {
mode_dev->panel_fixed_mode =
drm_mode_duplicate(dev, scan);
+ DRM_DEBUG_KMS("Using mode from DDC\n");
goto out; /* FIXME: check for quirks */
}
}
/* Failed to get EDID, what about VBT? do we need this? */
- if (mode_dev->vbt_mode)
+ if (dev_priv->lfp_lvds_vbt_mode) {
mode_dev->panel_fixed_mode =
- drm_mode_duplicate(dev, mode_dev->vbt_mode);
+ drm_mode_duplicate(dev, dev_priv->lfp_lvds_vbt_mode);
- if (!mode_dev->panel_fixed_mode)
- if (dev_priv->lfp_lvds_vbt_mode)
- mode_dev->panel_fixed_mode =
- drm_mode_duplicate(dev,
- dev_priv->lfp_lvds_vbt_mode);
+ if (mode_dev->panel_fixed_mode) {
+ mode_dev->panel_fixed_mode->type |=
+ DRM_MODE_TYPE_PREFERRED;
+ DRM_DEBUG_KMS("Using mode from VBT\n");
+ goto out;
+ }
+ }
/*
* If we didn't get EDID, try checking if the panel is already turned
@@ -790,6 +793,7 @@ void psb_intel_lvds_init(struct drm_device *dev,
if (mode_dev->panel_fixed_mode) {
mode_dev->panel_fixed_mode->type |=
DRM_MODE_TYPE_PREFERRED;
+ DRM_DEBUG_KMS("Using pre-programmed mode\n");
goto out; /* FIXME: check for quirks */
}
}
--
2.12.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1973-ga4b2d83360ec)
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1973-ga4b2d83360ec) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d83360ec/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1973-ga4b2d83360ec/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1973-ga4b2d83360ec Git Commit: a4b2d83360ec1673de58ff43d7b6fd5deaba1ce6 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 10 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"
All the error codes we (ab)use are strictly not the right ones (since
they're all for the vfs, and the only thing we're allowed to do from
an ioctl is EINVAL). But ENOENT is the common error code for failed to
look up an object throughout drm, so let's use it in the cma helpers,
too.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index d2b77b02830d..53f9bdf470d7 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -189,7 +189,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
if (!obj) {
dev_err(dev->dev, "Failed to lookup GEM object\n");
- ret = -ENXIO;
+ ret = -ENOENT;
goto err_gem_object_put;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"
Hi Daniel,
Thank you for the patch.
On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> All the error codes we (ab)use are strictly not the right ones (since
> they're all for the vfs, and the only thing we're allowed to do from
> an ioctl is EINVAL). But ENOENT is the common error code for failed to
> look up an object throughout drm, so let's use it in the cma helpers,
> too.
Regardless of which is best, it's true that ENOENT is used through the DRM
code, so
Reviewed-by: Laurent Pinchart
Someone should however mention that this changes the userspace API. I'll let
you decide whether to ignore that comment :-)
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index d2b77b02830d..53f9bdf470d7
> 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -189,7 +189,7 @@ struct drm_framebuffer
> *drm_fb_cma_create_with_funcs(struct drm_device *dev, obj =
> drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> if (!obj) {
> dev_err(dev->dev, "Failed to lookup GEM object\n");
> - ret = -ENXIO;
> + ret = -ENOENT;
> goto err_gem_object_put;
> }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100708] Trine 2 doesn't start on radeonsi on mesa 17
https://bugs.freedesktop.org/show_bug.cgi?id=100708 Bug ID: 100708 Summary: Trine 2 doesn't start on radeonsi on mesa 17 Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: krne...@gmail.com QA Contact: dri-devel@lists.freedesktop.org I have a laptop with AMD A8-5557M APU (Radeon HD 8550G, r600) and discrete videocard Radeon HD 8750M (radeonsi). I also have a monitor connected via a hdmi and use it as main screen. I use PRIME to play a game: $ xrandr --setprovideroffloadsink 0x41 0x78 $ DRI_PRIME=1 steam With DRI drivers version 12 it works fine, but if I update it to the recent one (17), the game doesn't start: when I click on start button in the launcher, the screen became black for a moment and the game exits. There is no unusual messages in the console. I found, that if I replace /usr/lib/dri/radeonsi_dri.so with the old one, the game works. With the integrated video (r600) it works fine on all versions. I reported also this to the distribution bug tracker [1], but seems this is an upstream bug in the radeonsi driver. [1] https://bugs.mageia.org/show_bug.cgi?id=20632 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100708] Trine 2 doesn't start on radeonsi on mesa 17
https://bugs.freedesktop.org/show_bug.cgi?id=100708 Nikita Krupenko changed: What|Removed |Added URL||https://bugs.mageia.org/sho ||w_bug.cgi?id=20632 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/exynos/decon5433: use readl_poll_timeout helpers
Linux core provide helpers for polling with timeout, lets use them.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88..237b4c9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc
*crtc)
static void decon_swreset(struct decon_context *ctx)
{
- unsigned int tries;
unsigned long flags;
+ u32 val;
+ int ret;
writel(0, ctx->addr + DECON_VIDCON0);
- for (tries = 2000; tries; --tries) {
- if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
- break;
- udelay(10);
- }
+ readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
+ ~val & VIDCON0_STOP_STATUS, 12, 2);
writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
- for (tries = 2000; tries; --tries) {
- if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
- break;
- udelay(10);
- }
+ ret = readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
+~val & VIDCON0_SWRESET, 12, 2);
- WARN(tries == 0, "failed to software reset DECON\n");
+ WARN(ret < 0, "failed to software reset DECON\n");
spin_lock_irqsave(&ctx->vblank_lock, flags);
ctx->frame_id = 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/exynos/mic: use mode info stored in CRTC to detect i80 mode
MIC driver should use info from CRTC to check mode of work instead of
illegally peeking into nodes of other devices.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 44 +++--
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index e457205..9f2fa8a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -21,9 +21,12 @@
#include
#include
#include
+#include
#include
#include
+#include
+
/* Sysreg registers for MIC */
#define DSD_CFG_MUX0x1004
#define MIC0_RGB_MUX (1 << 0)
@@ -85,12 +88,6 @@
#define MIC_BS_SIZE_2D(x) ((x) & 0x3fff)
-enum {
- ENDPOINT_DECON_NODE,
- ENDPOINT_DSI_NODE,
- NUM_ENDPOINTS
-};
-
static char *clk_names[] = { "pclk_mic0", "sclk_rgb_vclk_to_mic0" };
#define NUM_CLKS ARRAY_SIZE(clk_names)
static DEFINE_MUTEX(mic_mutex);
@@ -229,36 +226,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool
enable)
writel(reg, mic->reg + MIC_OP);
}
-static int parse_dt(struct exynos_mic *mic)
-{
- int ret = 0, i, j;
- struct device_node *remote_node;
- struct device_node *nodes[3];
-
- /*
-* The order of endpoints does matter.
-* The first node must be for decon and the second one must be for dsi.
-*/
- for (i = 0, j = 0; i < NUM_ENDPOINTS; i++) {
- remote_node = of_graph_get_remote_node(mic->dev->of_node, i, 0);
- if (!remote_node) {
- ret = -EPIPE;
- goto exit;
- }
- nodes[j++] = remote_node;
-
- if (i == ENDPOINT_DECON_NODE &&
- of_get_child_by_name(remote_node, "i80-if-timings"))
- mic->i80_mode = 1;
- }
-
-exit:
- while (--j > -1)
- of_node_put(nodes[j]);
-
- return ret;
-}
-
static void mic_disable(struct drm_bridge *bridge) { }
static void mic_post_disable(struct drm_bridge *bridge)
@@ -286,6 +253,7 @@ static void mic_mode_set(struct drm_bridge *bridge,
mutex_lock(&mic_mutex);
drm_display_mode_to_videomode(mode, &mic->vm);
+ mic->i80_mode = to_exynos_crtc(bridge->encoder->crtc)->i80_mode;
mutex_unlock(&mic_mutex);
}
@@ -425,10 +393,6 @@ static int exynos_mic_probe(struct platform_device *pdev)
mic->dev = dev;
- ret = parse_dt(mic);
- if (ret)
- goto err;
-
ret = of_address_to_resource(dev->of_node, 0, &res);
if (ret) {
DRM_ERROR("mic: Failed to get mem region for MIC\n");
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm/exynos: panel mode info propagation
Hi Inki, This patchset beside cleanup/refactoring patches (01-03) adds code to propagate info provided by MIPI-DSI panels about its mode of work (video/command mode). The propagation is performed for whole pipeline as every its elements uses it. Regards Andrzej Andrzej Hajda (7): drm/exynos/decon5433: use readl_poll_timeout helpers drm/exynos: use helper to set possible crtcs drm/exynos/dsi: refactor panel detection logic drm/exynos: propagate info about command mode from panel drm/exynos/mic: use mode info stored in CRTC to detect i80 mode drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode dt-bindings: exynos5433-decon: remove i80-if-timings property .../bindings/display/exynos/exynos5433-decon.txt | 6 - drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 118 ++- drivers/gpu/drm/exynos/exynos_dp.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_core.c | 1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 21 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 10 +- drivers/gpu/drm/exynos/exynos_drm_dpi.c| 12 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 219 ++--- drivers/gpu/drm/exynos/exynos_drm_mic.c| 44 + drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 25 +-- 12 files changed, 228 insertions(+), 259 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/exynos: propagate info about command mode from panel
mipi_dsi framework provides information about panel's mode of work.
This info should be propagated upstream to configure all elements of
the pipeline. As CRTC is the common nominator of the pipeline we can put
such info into its structures.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 527bf1d..96b9d49 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -165,6 +165,7 @@ struct exynos_drm_crtc {
const struct exynos_drm_crtc_ops*ops;
void*ctx;
struct exynos_drm_clk *pipe_clk;
+ booli80_mode : 1;
};
static inline void exynos_drm_pipe_clk_enable(struct exynos_drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 515090f..79df1c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1545,6 +1545,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
*host,
drm_panel_attach(dsi->panel, &dsi->connector);
dsi->connector.status = connector_status_connected;
}
+ exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
+ !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
mutex_unlock(&drm->mode_config.mutex);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/exynos/dsi: refactor panel detection logic
Description of drm_helper_hpd_irq_event clearly states that drivers
supporting hotplug events per connector should use different helper -
drm_kms_helper_hotplug_event. To achieve it following changes have
been performed:
- moved down all DSI ops - they require exynos_dsi_disable function
to be defined earlier,
- simplified exynos_dsi_detect - there is no real detection, it just
returns if panel is attached,
- DSI attach/detach callbacks attaches/detaches DRM panel and sets
connector status and other context fields accordingly, all this is
performed under mutex, as these callbacks are asynchronous.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 204
1 file changed, 103 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 3ae459f..515090f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -254,7 +254,6 @@ struct exynos_dsi {
struct drm_encoder encoder;
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
- struct device_node *panel_node;
struct drm_panel *panel;
struct device *dev;
@@ -1329,12 +1328,13 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
return 0;
}
-static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
+static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
+ struct device *panel)
{
int ret;
int te_gpio_irq;
- dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
+ dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
if (dsi->te_gpio == -ENOENT)
return 0;
@@ -1374,85 +1374,6 @@ static void exynos_dsi_unregister_te_irq(struct
exynos_dsi *dsi)
}
}
-static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *device)
-{
- struct exynos_dsi *dsi = host_to_dsi(host);
-
- dsi->lanes = device->lanes;
- dsi->format = device->format;
- dsi->mode_flags = device->mode_flags;
- dsi->panel_node = device->dev.of_node;
-
- /*
-* This is a temporary solution and should be made by more generic way.
-*
-* If attached panel device is for command mode one, dsi should register
-* TE interrupt handler.
-*/
- if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO)) {
- int ret = exynos_dsi_register_te_irq(dsi);
-
- if (ret)
- return ret;
- }
-
- if (dsi->connector.dev)
- drm_helper_hpd_irq_event(dsi->connector.dev);
-
- return 0;
-}
-
-static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
- struct mipi_dsi_device *device)
-{
- struct exynos_dsi *dsi = host_to_dsi(host);
-
- exynos_dsi_unregister_te_irq(dsi);
-
- dsi->panel_node = NULL;
-
- if (dsi->connector.dev)
- drm_helper_hpd_irq_event(dsi->connector.dev);
-
- return 0;
-}
-
-static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
- const struct mipi_dsi_msg *msg)
-{
- struct exynos_dsi *dsi = host_to_dsi(host);
- struct exynos_dsi_transfer xfer;
- int ret;
-
- if (!(dsi->state & DSIM_STATE_ENABLED))
- return -EINVAL;
-
- if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
- ret = exynos_dsi_init(dsi);
- if (ret)
- return ret;
- dsi->state |= DSIM_STATE_INITIALIZED;
- }
-
- ret = mipi_dsi_create_packet(&xfer.packet, msg);
- if (ret < 0)
- return ret;
-
- xfer.rx_len = msg->rx_len;
- xfer.rx_payload = msg->rx_buf;
- xfer.flags = msg->flags;
-
- ret = exynos_dsi_transfer(dsi, &xfer);
- return (ret < 0) ? ret : xfer.rx_done;
-}
-
-static const struct mipi_dsi_host_ops exynos_dsi_ops = {
- .attach = exynos_dsi_host_attach,
- .detach = exynos_dsi_host_detach,
- .transfer = exynos_dsi_host_transfer,
-};
-
static void exynos_dsi_enable(struct drm_encoder *encoder)
{
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
@@ -1508,25 +1429,7 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
static enum drm_connector_status
exynos_dsi_detect(struct drm_connector *connector, bool force)
{
- struct exynos_dsi *dsi = connector_to_dsi(connector);
-
- if (!dsi->panel) {
- dsi->panel = of_drm_find_panel(dsi->panel_node);
- if (dsi->panel)
- drm_panel_attach(dsi->panel, &dsi->connector);
- } else if (!dsi->panel_node) {
- struct drm_encoder *encoder;
-
- encoder = platform_get_drvdata(to_platform_device(dsi->dev));
- exynos_d
[PATCH 2/7] drm/exynos: use helper to set possible crtcs
All encoders share the same code to set encoders possible_crtcs field.
The patch creates helper to abstract out this code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_dp.c | 15 +--
drivers/gpu/drm/exynos/exynos_drm_core.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 21 ++---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 10 +++---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 12
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 -
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +--
drivers/gpu/drm/exynos/exynos_hdmi.c | 25 +
8 files changed, 53 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 385537b..39629e7 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -155,7 +155,7 @@ static int exynos_dp_bind(struct device *dev, struct device
*master, void *data)
struct exynos_dp_device *dp = dev_get_drvdata(dev);
struct drm_encoder *encoder = &dp->encoder;
struct drm_device *drm_dev = data;
- int pipe, ret;
+ int ret;
/*
* Just like the probe function said, we don't need the
@@ -179,20 +179,15 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
return ret;
}
- pipe = exynos_drm_crtc_get_pipe_from_type(drm_dev,
- EXYNOS_DISPLAY_TYPE_LCD);
- if (pipe < 0)
- return pipe;
-
- encoder->possible_crtcs = 1 << pipe;
-
- DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
-
drm_encoder_init(drm_dev, encoder, &exynos_dp_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(encoder, &exynos_dp_encoder_helper_funcs);
+ ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
+ if (ret < 0)
+ return ret;
+
dp->plat_data.encoder = encoder;
return analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index edbd98f..b0c0621 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -13,6 +13,7 @@
*/
#include
+
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index d72777f..5dc1aab 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
@@ -189,16 +190,30 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
return ERR_PTR(ret);
}
-int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
+struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device *drm_dev,
enum exynos_drm_output_type out_type)
{
struct drm_crtc *crtc;
drm_for_each_crtc(crtc, drm_dev)
if (to_exynos_crtc(crtc)->type == out_type)
- return drm_crtc_index(crtc);
+ return to_exynos_crtc(crtc);
- return -EPERM;
+ return ERR_PTR(-EPERM);
+}
+
+int exynos_drm_set_possible_crtcs(struct drm_encoder *encoder,
+ enum exynos_drm_output_type out_type)
+{
+ struct exynos_drm_crtc *crtc = exynos_drm_crtc_get_by_type(encoder->dev,
+ out_type);
+
+ if (IS_ERR(crtc))
+ return PTR_ERR(crtc);
+
+ encoder->possible_crtcs = drm_crtc_mask(&crtc->base);
+
+ return 0;
}
void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index ef58b64..dec4461 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -15,21 +15,25 @@
#ifndef _EXYNOS_DRM_CRTC_H_
#define _EXYNOS_DRM_CRTC_H_
+
#include "exynos_drm_drv.h"
struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
struct drm_plane *plane,
- enum exynos_drm_output_type type,
+ enum exynos_drm_output_type out_type,
const struct exynos_drm_crtc_ops *ops,
void *context);
void exynos_drm_crtc_wait_pending_update(struct exynos_drm_crtc *exynos_crtc);
void exynos_drm_crtc_finish_update(struct exynos_drm_crtc *exynos_crtc,
struct exynos_drm_plane *exynos_plane);
-/* This function ge
[PATCH 6/7] drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode
Since panel's mode of work is propagated properly from panel to DECON,
there is no need to use redundant private property. The only issue with
such approach is that check for required interrupts should be postponed
until panel communicate its requirements - ie to atomic_check.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 98 ---
1 file changed, 57 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 237b4c9..7a09e03 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -34,9 +34,8 @@
#define WINDOWS_NR 3
#define MIN_FB_WIDTH_FOR_16WORD_BURST 128
-#define IFTYPE_I80 (1 << 0)
-#define I80_HW_TRG (1 << 1)
-#define IFTYPE_HDMI(1 << 2)
+#define I80_HW_TRG (1 << 0)
+#define IFTYPE_HDMI(1 << 1)
static const char * const decon_clks_name[] = {
"pclk",
@@ -58,7 +57,9 @@ struct decon_context {
struct regmap *sysreg;
struct clk *clks[ARRAY_SIZE(decon_clks_name)];
unsigned intirq;
- unsigned intte_irq;
+ unsigned intirq_vsync;
+ unsigned intirq_lcd_sys;
+ unsigned intirq_te;
unsigned long out_type;
int first_win;
spinlock_t vblank_lock;
@@ -91,7 +92,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
u32 val;
val = VIDINTCON0_INTEN;
- if (ctx->out_type & IFTYPE_I80)
+ if (crtc->i80_mode)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
@@ -100,7 +101,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
enable_irq(ctx->irq);
if (!(ctx->out_type & I80_HW_TRG))
- enable_irq(ctx->te_irq);
+ enable_irq(ctx->irq_te);
return 0;
}
@@ -110,7 +111,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
struct decon_context *ctx = crtc->ctx;
if (!(ctx->out_type & I80_HW_TRG))
- disable_irq_nosync(ctx->te_irq);
+ disable_irq_nosync(ctx->irq_te);
disable_irq_nosync(ctx->irq);
writel(0, ctx->addr + DECON_VIDINTCON0);
@@ -140,7 +141,7 @@ static u32 decon_get_frame_count(struct decon_context *ctx,
bool end)
switch (status & (VIDCON1_VSTATUS_MASK | VIDCON1_I80_ACTIVE)) {
case VIDCON1_VSTATUS_VS:
- if (!(ctx->out_type & IFTYPE_I80))
+ if (!(ctx->crtc->i80_mode))
--frm;
break;
case VIDCON1_VSTATUS_BP:
@@ -167,7 +168,7 @@ static u32 decon_get_vblank_counter(struct exynos_drm_crtc
*crtc)
static void decon_setup_trigger(struct decon_context *ctx)
{
- if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
+ if (!ctx->crtc->i80_mode && !(ctx->out_type & I80_HW_TRG))
return;
if (!(ctx->out_type & I80_HW_TRG)) {
@@ -207,7 +208,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
val = VIDOUT_LCD_ON;
if (interlaced)
val |= VIDOUT_INTERLACE_EN_F;
- if (ctx->out_type & IFTYPE_I80) {
+ if (crtc->i80_mode) {
val |= VIDOUT_COMMAND_IF;
} else {
val |= VIDOUT_RGB_IF;
@@ -223,7 +224,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);
- if (!(ctx->out_type & IFTYPE_I80)) {
+ if (!crtc->i80_mode) {
int vbp = m->crtc_vtotal - m->crtc_vsync_end;
int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
@@ -456,7 +457,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
int i;
if (!(ctx->out_type & I80_HW_TRG))
- synchronize_irq(ctx->te_irq);
+ synchronize_irq(ctx->irq_te);
synchronize_irq(ctx->irq);
/*
@@ -511,6 +512,22 @@ static void decon_clear_channels(struct exynos_drm_crtc
*crtc)
clk_disable_unprepare(ctx->clks[i]);
}
+static int decon_atomic_check(struct exynos_drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct decon_context *ctx = crtc->ctx;
+
+ ctx->irq = crtc->i80_mode ? ctx->irq_lcd_sys : ctx->irq_vsync;
+
+ if (ctx->irq)
+ return 0;
+
+ dev_err(ctx->dev, "Panel requires %s mode, but appropriate interrupt is
not provided.\n",
+ crtc->i80_mode ? "command" : "video");
+
+ return -EINVAL;
+}
+
static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disa
[PATCH 7/7] dt-bindings: exynos5433-decon: remove i80-if-timings property
Since i80/command mode is determined in runtime by propagating info from panel this property can be removed. Signed-off-by: Andrzej Hajda --- .../devicetree/bindings/display/exynos/exynos5433-decon.txt | 6 -- 1 file changed, 6 deletions(-) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt index 549c538..26a9269 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt @@ -25,12 +25,6 @@ Required properties: size-cells must 1 and 0, respectively. - port: contains an endpoint node which is connected to the endpoint in the mic node. The reg value muset be 0. -- i80-if-timings: specify whether the panel which is connected to decon uses - i80 lcd interface or mipi video interface. This node contains - no timing information as that of fimd does. Because there is - no register in decon to specify i80 interface timing value, - it is not needed, but make it remain to use same kind of node - in fimd and exynos7 decon. Example: SoC specific DT entry: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] modetest: fix printing of fourcc on BE machines
fourcc is not a string, it's a packed integer. This happens to work out
on LE, but gets reversed on BE.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c390d87..b8891ff 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -174,6 +174,15 @@ static const char *mode_flag_names[] = {
static bit_name_fn(mode_flag)
+static void dump_fourcc(uint32_t fourcc)
+{
+ printf(" %c%c%c%c",
+ fourcc,
+ fourcc >> 8,
+ fourcc >> 16,
+ fourcc >> 24);
+}
+
static void dump_encoders(struct device *dev)
{
drmModeEncoder *encoder;
@@ -443,7 +452,7 @@ static void dump_planes(struct device *dev)
printf(" formats:");
for (j = 0; j < ovr->count_formats; j++)
- printf(" %4.4s", (char *)&ovr->formats[j]);
+ dump_fourcc(ovr->formats[j]);
printf("\n");
if (plane->props) {
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1976-gb15e4217c2dc)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1976-gb15e4217c2dc) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e4217c2dc/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1976-gb15e4217c2dc Git Commit: b15e4217c2dc477367d7239fc94d1c1e80698395 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Hi, > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > here, it drives the qemu stdvga with offb, not bochs-drm. > > I suppose this proves the virtual machine itself is correct about > framebuffer endianess? Except you are running it on a little-endian > host machine I presume... Yes, little endian host, qemu interprets the framebuffer as PIXMAN_b8g8r8x8. Which should be correct for a xrgb bigendian framebuffer as pixman formats are native endian. > > More interesting: RHEL-7.3 (gnome 3.14) works fine too. kernel 3.10, > > but drm drivers updated to roughly 4.6 level. Runs bochs-drm. mesa > > 11.2.2. glamour not used. > > > > Most recent: Fedora 25 (gnome 3.22) looks mostly ok, but there are > > rendering glitches, for example in the gnome activities screen (the one > > you get when you press the windows key). kernel 4.10, mesa 13.0.4. > > glamor not used, but I think gnome-shell uses opengl (via llvmpipe) for > > compositing. > > I believe glitches are irrelevant for this topic, what we are > interested in is if the colors are right or byte-swapped (also mind > alpha/blue etc. swaps). Well, I mean color glitches. But it isn't consistent. As if some operations operate with the correct byteorder and some don't. alpha/blue being swapped is a problem in some areas. https://www.kraxel.org/tmp/ cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Tue, 18 Apr 2017 15:39:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest > > > here, it drives the qemu stdvga with offb, not bochs-drm. > > > > I suppose this proves the virtual machine itself is correct about > > framebuffer endianess? Except you are running it on a little-endian > > host machine I presume... > > Yes, little endian host, qemu interprets the framebuffer as > PIXMAN_b8g8r8x8. Which should be correct for a xrgb bigendian > framebuffer as pixman formats are native endian. Right. Very nice if we can trust the virtual machine at least getting things right, gives some chance for people to test anything. Except... that's a question of what kind of hardware the virtual machine emulates. The display device defines what endianess it uses on framebuffers, not the CPU, right? > > > More interesting: RHEL-7.3 (gnome 3.14) works fine too. kernel 3.10, > > > but drm drivers updated to roughly 4.6 level. Runs bochs-drm. mesa > > > 11.2.2. glamour not used. > > > > > > Most recent: Fedora 25 (gnome 3.22) looks mostly ok, but there are > > > rendering glitches, for example in the gnome activities screen (the one > > > you get when you press the windows key). kernel 4.10, mesa 13.0.4. > > > glamor not used, but I think gnome-shell uses opengl (via llvmpipe) for > > > compositing. > > > > I believe glitches are irrelevant for this topic, what we are > > interested in is if the colors are right or byte-swapped (also mind > > alpha/blue etc. swaps). > > Well, I mean color glitches. But it isn't consistent. As if some > operations operate with the correct byteorder and some don't. > alpha/blue being swapped is a problem in some areas. > > https://www.kraxel.org/tmp/ Ooh, yeah, that's definitely bonkers. Maybe the 100% blue things are supposed to be a transparent blended overlays, like highlights. The icons look somehow... not completely right to me. Somehow washed out? Opaque gray shades are hard to tell right from wrong. gnome-terminal and the wallpaper look right, but those might be the only things. Having a compositing manager complicates things. Thanks, pq pgp_5bXjinR1h.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly
On Mon, Apr 03, 2017 at 11:57:55AM -0700, Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also mitigates some of
> the caching problems (e.g. dma_alloc_coherent only returning uncached
> memory).
>
> Signed-off-by: Laura Abbott
> ---
> drivers/staging/android/ion/Kconfig| 7 +++
> drivers/staging/android/ion/Makefile | 3 +-
> drivers/staging/android/ion/ion_cma_heap.c | 97
> --
> 3 files changed, 35 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig
> b/drivers/staging/android/ion/Kconfig
> index 206c4de..15108c4 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,3 +10,10 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> + Choose this option to enable CMA heaps with Ion. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile
> b/drivers/staging/android/ion/Makefile
> index 26672a0..66d0c4a 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> + ion_carveout_heap.o ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> ifdef CONFIG_COMPAT
> obj-$(CONFIG_ION) += compat_ion.o
> endif
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c
> index d562fd7..f3e0f59 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
> #include
> #include
> #include
> -#include
> +#include
> +#include
>
> #include "ion.h"
> #include "ion_priv.h"
>
> struct ion_cma_heap {
> struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
> };
>
> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
>
> /* ION CMA heap operations functions */
> static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
> @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
> ion_buffer *buffer,
> unsigned long flags)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
>
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
> + if (!pages)
> return -ENOMEM;
>
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
> goto err;
> - }
>
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
> goto free_mem;
>
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
> return 0;
>
> -free_table:
> - kfree(info->table);
> free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
> err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
> return -ENOMEM;
> }
>
> static void ion_cma_free(struct ion_buffer *buffer)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1976-gba8ae8c72f16)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1976-gba8ae8c72f16) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8c72f16/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1976-gba8ae8c72f16 Git Commit: ba8ae8c72f16c6c8177091d07e0825d54b214d4d Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 Julien Isorce changed: What|Removed |Added Attachment #130788|0 |1 is obsolete|| --- Comment #20 from Julien Isorce --- Comment on attachment 130788 --> https://bugs.freedesktop.org/attachment.cgi?id=130788 ddebug_dumps_HD7770_kernel_amd-staging-4.9_ring_stalled Marking as obsolete because this is a different problem than the one reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 Julien Isorce changed: What|Removed |Added Attachment #130787|0 |1 is obsolete|| --- Comment #19 from Julien Isorce --- Comment on attachment 130787 --> https://bugs.freedesktop.org/attachment.cgi?id=130787 dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled Marking as obsolete because this is a different problem than the one reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 Julien Isorce changed: What|Removed |Added Attachment #130789|0 |1 is obsolete|| --- Comment #21 from Julien Isorce --- Comment on attachment 130789 --> https://bugs.freedesktop.org/attachment.cgi?id=130789 dmesg_HD7770_kernel_agd5f-drm-next-4.12_ring_stalled Marking as obsolete because this is a different problem than the one reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 Julien Isorce changed: What|Removed |Added Attachment #130790|0 |1 is obsolete|| --- Comment #22 from Julien Isorce --- Comment on attachment 130790 --> https://bugs.freedesktop.org/attachment.cgi?id=130790 ddebug_dumps_HD7770_kernel_agd5f-drm-next-4.12_ring_stalled Marking as obsolete because this is a different problem than the one reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.
Interesting that you didn't CC any of the maintainers. Could you
do that in the future please?
> >
> > Signed-off-by: Logan Gunthorpe
> > ---
> > drivers/block/xen-blkfront.c | 33 +++--
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 5067a0a..7dcf41d 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
> > struct blkfront_ring_info *ri
> > BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >
> > if (setup.need_copy) {
> > - setup.bvec_off = sg->offset;
> > - setup.bvec_data = kmap_atomic(sg_page(sg));
> > + setup.bvec_off = 0;
> > + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> > + if (IS_ERR(setup.bvec_data)) {
> > + /*
> > +* This should really never happen unless
> > +* the code is changed to use memory that is
> > +* not mappable in the sg. Seeing there is a
> > +* questionable error path out of here,
> > +* we WARN.
> > +*/
> > + WARN(1, "Non-mappable memory used in sg!");
> > + return 1;
> > + }
> ...
>
> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> inside sg_map().
>
> David
>
>
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 114 boots: 2 failed, 112 passed (v4.11-rc6-1975-g4d374295ace9)
drm-tip/drm-tip boot: 114 boots: 2 failed, 112 passed (v4.11-rc6-1975-g4d374295ace9) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d374295ace9/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1975-g4d374295ace9/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1975-g4d374295ace9 Git Commit: 4d374295ace9e57d83483341e2ad07cad5baf912 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 15 unique boards, 8 SoC families, 19 builds out of 207 Boot Failures Detected: arm64: allmodconfig meson-gxbb-p200: 1 failed lab arm: multi_v7_defconfig+CONFIG_SMP=n exynos5250-snow: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] sync_file: get rid of internal reference count.
2017-04-17 Sumit Semwal : > On 17 April 2017 at 18:43, Gustavo Padovan wrote: > > 2017-04-13 Dave Airlie : > > > >> From: Dave Airlie > >> > >> sync_file uses the reference count of the file, the internal > >> kref was never getting moved past 1. > >> > >> We can reintroduce this if we decide we need it later. > >> > >> [airlied: fix buildbot warnings] > >> > >> Reviewed-by: Chris Wilson > >> Signed-off-by: Dave Airlie > >> --- > >> drivers/dma-buf/sync_file.c | 13 ++--- > >> include/linux/sync_file.h | 3 --- > >> 2 files changed, 2 insertions(+), 14 deletions(-) > > > > Reviewed-by: Gustavo Padovan > Acked-by: Sumit Semwal > > > > Or should I just push this one? > Of course, go right ahead, Gustavo :) pushed to drm-misc-next. Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"
On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> > All the error codes we (ab)use are strictly not the right ones (since
> > they're all for the vfs, and the only thing we're allowed to do from
> > an ioctl is EINVAL). But ENOENT is the common error code for failed to
> > look up an object throughout drm, so let's use it in the cma helpers,
> > too.
>
> Regardless of which is best, it's true that ENOENT is used through the DRM
> code, so
>
> Reviewed-by: Laurent Pinchart
>
> Someone should however mention that this changes the userspace API. I'll let
> you decide whether to ignore that comment :-)
Yeah, let's make sure we don't break any existing userspaces (a la pulseaudio).
Sean
>
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c index d2b77b02830d..53f9bdf470d7
> > 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -189,7 +189,7 @@ struct drm_framebuffer
> > *drm_fb_cma_create_with_funcs(struct drm_device *dev, obj =
> > drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> > if (!obj) {
> > dev_err(dev->dev, "Failed to lookup GEM object\n");
> > - ret = -ENXIO;
> > + ret = -ENOENT;
> > goto err_gem_object_put;
> > }
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1977-gbd206d943e83)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1977-gbd206d943e83) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d943e83/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1977-gbd206d943e83 Git Commit: bd206d943e8308fcb814d0595620c140a191cfea Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
https://bugs.freedesktop.org/show_bug.cgi?id=100712 Bug ID: 100712 Summary: ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770 Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: julien.iso...@gmail.com Kernel 4.9 from https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9 and latest mesa. (same result with drm-next-4.12 branch) Same result with kernel 4.8 and mesa 12.0.6. In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved > bytes_moved_threshold" is reached (this is the case for 850 bo in the same list_for_each_entry loop), I can see that radeon_ib_schedule emits a fence that it takes more than the radeon.lockup_timeout to be signaled. In radeon_fence_activity, I checked that the "last_emitted" is the seq number for this last emited fence. And last_seq is equal to last_emitted-1. Then the next call to ttm_wait_bo blocks (15 * HZ > radeon.lockup_timeout) until gpu lockup which leads to a gpu reset. Also it seems the fence is signaled by swapper after more than 10 seconds but it is too late. I requires to reduce the "15" param above to 4 to see that. Is it normal that radeon_bo_list_validate still tries to move the bo if bytes_moved_threshold is reached ? Indeed ttm_bo_validate is always called (it blits from vram to vram). Is it also normal that ttm_bo_validate is called with evict flag as true once bytes_moved_threshold is reached ? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
https://bugs.freedesktop.org/show_bug.cgi?id=100712 --- Comment #1 from Julien Isorce --- Created attachment 130902 --> https://bugs.freedesktop.org/attachment.cgi?id=130902&action=edit dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
https://bugs.freedesktop.org/show_bug.cgi?id=100712 --- Comment #2 from Julien Isorce --- Created attachment 130903 --> https://bugs.freedesktop.org/attachment.cgi?id=130903&action=edit dmesg_HD7770_kernel_amd-staging-4.9_ring_stalled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
https://bugs.freedesktop.org/show_bug.cgi?id=100712 Julien Isorce changed: What|Removed |Added Attachment #130903|0 |1 is obsolete|| --- Comment #3 from Julien Isorce --- Created attachment 130904 --> https://bugs.freedesktop.org/attachment.cgi?id=130904&action=edit ddebug_dumps_HD7770_kernel_amd-staging-4.9_ring_stalled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
https://bugs.freedesktop.org/show_bug.cgi?id=100465 --- Comment #23 from Julien Isorce --- I confirm that comment #9 and #12 are about a different issue (or at least different symptoms). I reported it here: https://bugs.freedesktop.org/show_bug.cgi?id=100712 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: X.org EVoC Ideas
On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia wrote: > Hi there > > I am Raghav Jajodia, an Engineering student from India. While going through > the X.org foundation, I felt that X.org is a great community for new Open > Source developers. I am deeply interested in being a part of the community. > Although, while going through the GSoC and EVoC Ideas, I found that all the > ideas revolve around C, C++, QT or Compilers. > > Working extensively on Web, Moile and Desktop applications, I have gained > good experience with Python, JS, PHP, Ruby etc. But I do not have any > experience with C/C++. > > So, is not possible for a student to participate in EVoC if he doesn't have > any experience with Open source softwares built on C/C++. Are there any > project ideas using languages apart from C/C++ that a student can work on > for EVoC 17/18? Hi, the only requirement regarding programming languages is that "Applicants know their target programming language.".. there isn't any requirement otherwise, but I think the fast majority are largely C/C++. There are bits of python here and there (piglit, for example.. possibly others that I don't know of). From a quick look all of the suggested projects involve C and/or C++. But that doesn't mean a candidate couldn't suggest a different project that is not on the list. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover letter. The distribution list for the patchset
> would have been way too large to cc every maintainer (even as limited as
> it was, I had mailing lists yelling at me). My plan was to get buy in
I am not sure if you know, but you can add on each patch the respective
maintainer via 'CC'. That way you can have certain maintainers CCed only
on the subsystems they cover. You put it after (or before) your SoB and
git send-email happilly picks it up.
It does mean that for every patch you have to run something like this:
$ more add_cc
#!/bin/bash
git diff HEAD^.. > /tmp/a
echo "---"
scripts/get_maintainer.pl --no-l /tmp/a | while read file
do
echo "Cc: $file"
done
Or such.
> for the first patch, get it merged and resend the rest independently to
> their respective maintainers. Of course, though, I'd be open to other
> suggestions.
>
> >>>
> >>> Signed-off-by: Logan Gunthorpe
> >>> ---
> >>> drivers/block/xen-blkfront.c | 33 +++--
> >>> 1 file changed, 27 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >>> index 5067a0a..7dcf41d 100644
> >>> --- a/drivers/block/xen-blkfront.c
> >>> +++ b/drivers/block/xen-blkfront.c
> >>> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
> >>> struct blkfront_ring_info *ri
> >>> BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >>>
> >>> if (setup.need_copy) {
> >>> - setup.bvec_off = sg->offset;
> >>> - setup.bvec_data = kmap_atomic(sg_page(sg));
> >>> + setup.bvec_off = 0;
> >>> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> >>> + if (IS_ERR(setup.bvec_data)) {
> >>> + /*
> >>> + * This should really never happen unless
> >>> + * the code is changed to use memory that is
> >>> + * not mappable in the sg. Seeing there is a
> >>> + * questionable error path out of here,
> >>> + * we WARN.
> >>> + */
> >>> + WARN(1, "Non-mappable memory used in sg!");
> >>> + return 1;
> >>> + }
> >> ...
> >>
> >> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> >> inside sg_map().
>
> Thanks, that's a good suggestion. I'll make the change for v2.
>
> Logan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"
On Tue, Apr 18, 2017 at 10:40:21AM -0400, Sean Paul wrote:
> On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote:
> > > All the error codes we (ab)use are strictly not the right ones (since
> > > they're all for the vfs, and the only thing we're allowed to do from
> > > an ioctl is EINVAL). But ENOENT is the common error code for failed to
> > > look up an object throughout drm, so let's use it in the cma helpers,
> > > too.
> >
> > Regardless of which is best, it's true that ENOENT is used through the DRM
> > code, so
> >
> > Reviewed-by: Laurent Pinchart
> >
> > Someone should however mention that this changes the userspace API. I'll
> > let
> > you decide whether to ignore that comment :-)
>
> Yeah, let's make sure we don't break any existing userspaces (a la
> pulseaudio).
Good point, but I think this is safe. I augmented the commit message and
merged the patch with Sean's irc r-b (plus Laurent's r-b from here).
-Daniel
>
> Sean
>
> >
> > > Cc: Laurent Pinchart
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > b/drivers/gpu/drm/drm_fb_cma_helper.c index d2b77b02830d..53f9bdf470d7
> > > 100644
> > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > @@ -189,7 +189,7 @@ struct drm_framebuffer
> > > *drm_fb_cma_create_with_funcs(struct drm_device *dev, obj =
> > > drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
> > > if (!obj) {
> > > dev_err(dev->dev, "Failed to lookup GEM object\n");
> > > - ret = -ENXIO;
> > > + ret = -ENOENT;
> > > goto err_gem_object_put;
> > > }
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1976-gb15e4217c2dc)
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1976-gb15e4217c2dc) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e4217c2dc/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gb15e4217c2dc/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1976-gb15e4217c2dc Git Commit: b15e4217c2dc477367d7239fc94d1c1e80698395 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 10 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1978-g7204beb80dcd)
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1978-g7204beb80dcd) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1978-g7204beb80dcd/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1978-g7204beb80dcd Git Commit: 7204beb80dcdfd1f8b1cff6a448301407f91a99c Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failure Detected: x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig+CONFIG_OF=n: FAIL Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) defconfig+CONFIG_KASAN=y: 4 warnings arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 warnings x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) defconfig+CONFIG_KASAN=y: 5 warnings Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig+CONFIG_OF=n (x86) — FAIL, 0 errors, 0 warnings, 0 section mismatches allnoconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches am200epdkit_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches aspeed_g4_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches
Re: [PATCH libdrm v2] Header: Add rotation property fields
On 18 April 2017 at 11:32, Emil Velikov wrote: > On 17 April 2017 at 21:13, Robert Foss wrote: >> From: Sean Paul >> >> From drm_crtc.h, for use with the plane "rotation" property. >> > Please see the include/drm/README. > To elaborate a bit: The headers in include/drm should be synced via make headers_install + copy, as seen in git log and described in the README file. Although for the properties here we seems to be in a pickle. These are defined in drm_blend.h which is not exported as part of the ABI. Yet the defines _are_ part of the ABI - see the lovely warning, which was added when someone broke and ABI and hence userspace. My suggestion - fix this in the kernel first. - Move the DRM_ROTATE* and DRM_REFLECT_* to an ABI header. Having a slight preference about drm_mode.h but drm.h should also be fine. - Optional: skim through for other properties that should be moved to the ABI headers. - Update libdrm as described in the README (please send patches if the documentation is not clear) Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: X.org EVoC Ideas
On 18 April 2017 at 16:48, Rob Clark wrote: > On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia > wrote: >> Hi there >> >> I am Raghav Jajodia, an Engineering student from India. While going through >> the X.org foundation, I felt that X.org is a great community for new Open >> Source developers. I am deeply interested in being a part of the community. >> Although, while going through the GSoC and EVoC Ideas, I found that all the >> ideas revolve around C, C++, QT or Compilers. >> >> Working extensively on Web, Moile and Desktop applications, I have gained >> good experience with Python, JS, PHP, Ruby etc. But I do not have any >> experience with C/C++. >> >> So, is not possible for a student to participate in EVoC if he doesn't have >> any experience with Open source softwares built on C/C++. Are there any >> project ideas using languages apart from C/C++ that a student can work on >> for EVoC 17/18? > > Hi, the only requirement regarding programming languages is that > "Applicants know their target programming language.".. there isn't > any requirement otherwise, but I think the fast majority are largely > C/C++. There are bits of python here and there (piglit, for example.. > possibly others that I don't know of). > > From a quick look all of the suggested projects involve C and/or C++. > But that doesn't mean a candidate couldn't suggest a different project > that is not on the list. > FWIW the python in piglit is fine, while the one in Mesa is in a dire shape. That said, I believe Rob summarised it perfectly: Take a look around and feel free to propose something if the ones listed do not interest you. Regards, Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 0/6] Introduce writeback connectors
Hi Boris, On Fri, Apr 14, 2017 at 11:35:17AM +0200, Boris Brezillon wrote: Hi Brian, On Fri, 25 Nov 2016 16:48:58 + Brian Starkey wrote: Hi, This is v3 of my series introducing a new connector type: DRM_MODE_CONNECTOR_WRITEBACK See v1 and v2 here: [1] [2] Writeback connectors are used to expose the memory writeback engines found in some display controllers, which can write a CRTC's composition result to a memory buffer. This is useful e.g. for testing, screen-recording, screenshots, wireless display, display cloning, memory-to-memory composition. Writeback connectors are given a WRITEBACK_FB_ID property (which acts slightly differently to FB_ID, so gets a new name), as well as a PIXEL_FORMATS blob to list the supported writeback formats, and OUT_FENCE_PTR to be used for out-fences. The changes since v2 are in the commit messages of each commit. The main differences are: - Subclass drm_connector as drm_writeback_connector - Slight relaxation of core checks, to allow (connector->crtc && !connector->fb) - Dropped PIXEL_FORMATS_SIZE, which was redundant - Reworked the event interface, drivers don't need to deal with the fence directly - Re-ordered the commits to introduce writeback out-fences up-front. I've kept RFC on this series because the event reporting (introduction of drm_writeback_job) is probably up for debate. v4 will be accompanied by igt tests. I plan to add writeback support to the VC4 driver and wanted to know if anything has changed since this v3 (IOW, do you have a v4 + igt tests ready)? Oh that's good to hear. I've got a v4 (just rebased for the most part), but was holding off sending it until having some "proper" userspace to support it. Unfortunately in the meantime we've had some team changes which mean I'm not really able to work on it to move things forward - Liviu might be able to pick this up. I'll collect together what I have and send it out anyway. It includes some functional tests in igt, but I'm not sure if that meets the "new uapi needs userspace" bar. As always, I look forward to any comments. I'll try to review these patches. Keep in mind that I didn't follow the initial discussions and might suggest things or ask questions that have already been answered in previous versions of this series or on IRC. Thanks, -Brian Regards, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm: writeback: Add out-fences for writeback connectors
On Fri, Apr 14, 2017 at 12:11:14PM +0200, Boris Brezillon wrote: On Fri, 25 Nov 2016 16:49:00 + Brian Starkey wrote: Add the OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. It is not allowed to request an out-fence without a framebuffer attached to the connector. A timeline is added to drm_writeback_connector for use by the writeback out-fences. In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence is set to -1. Changes from v2: - Rebase onto Gustavo Padovan's v9 explicit sync series - Change out_fence_ptr type to s32 __user * Don't know what happened, but I still see s32 __user * types in this patch (I had to patch it to make in work on top of 4.11-rc1). Yeah this really confused me too when rebasing. Given that this patch predates Gustavo's change to s32 I can only assume I typo'd and meant s64 in this commit message. -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm: Add writeback connector type
Hi Boris,
On Fri, Apr 14, 2017 at 12:08:23PM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey wrote:
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8e..6bbd93f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -86,6 +86,7 @@ struct drm_conn_prop_enum_list {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+ { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
Is there a reason we have a Writeback connector, but keep using a
Virtual encoder to connect it to the CRTC? Wouldn't it make more sense
to also add a Writeback encoder?
Only that a writeback connector is functionally and conceptually quite
different from the existing connector types, whereas the "encoder"
(which realistically only exists because the framework forces it to)
acts pretty much like any other.
};
void drm_connector_ida_init(void)
@@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
list_add_tail(&connector->head, &config->connector_list);
config->num_connector++;
- if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+ if ((connector_type != DRM_MODE_CONNECTOR_VIRTUAL) &&
+ (connector_type != DRM_MODE_CONNECTOR_WRITEBACK))
Nitpick: you don't need the extra parenthesis:
if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
Yeah fair enough, I can drop them.
drm_object_attach_property(&connector->base,
config->edid_property,
0);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 34f9741..dc4910d6 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -214,6 +214,19 @@ struct drm_connector_state {
struct drm_encoder *best_encoder;
struct drm_atomic_state *state;
+
+ /**
+* @writeback_job: Writeback job for writeback connectors
+*
+* Holds the framebuffer for a writeback connector. As the writeback
+* completion may be asynchronous to the normal commit cycle, the
+* writeback job lifetime is managed separately from the normal atomic
+* state by this object.
+*
+* See also: drm_writeback_queue_job() and
+* drm_writeback_signal_completion()
+*/
+ struct drm_writeback_job *writeback_job;
Maybe I'm wrong, but is feels weird to have the writeback_job field
directly embedded in drm_connector_state, while drm_writeback_connector
inherits from drm_connector.
IMO, either you decide to directly put the drm_writeback_connector's
job_xxx fields in drm_connector and keep the drm_connector_state as is,
or you create a drm_writeback_connector_state which inherits from
drm_connector_state and embeds the writeback_job field.
I did spend a decent amount of time looking at tracking the writeback
state along with the normal connector state. I couldn't come up with
anything I liked.
As the comment mentions, one of the problems is that you have to make
sure the relevant parts of the connector_state stay around until the
writeback is finished. That means you've got to block before
"swap_state()" until the previous writeback is done, and that
effectively limits your frame rate to refresh/2.
The Mali-DP HW doesn't have that limitation - we can queue up a new
commit while the current writeback is ongoing. For that reason I
didn't want to impose such a limitation in the framework.
In v1 I allowed that by making the Mali-DP driver hold its own
references to the relevant bits of the state for as long as it needed
them. In v3 I moved most of that code back to the core (in part
because Gustavo didn't like me signalling the DRM-"owned" fence from
my driver code directly). I think the new approach of "queue_job()"
and "signal_job()" reduces the amount of tricky code in drivers, and
is generally more clear (also familiar, when compared to vsync
events).
I'm certain there's other ways to do it (refcount atomic states?), but
it seemed like a biggish overhaul to achieve what would basically be
the same thing.
I was expecting each driver supporting writeback to have its own
different requirements around writeback lifetime/duration. For example
I think VC4 specifically came up, in that its writeback could take
several frames, whereas on Mali-DP we either finish within the frame
or we fail.
Letting the driver manage its writeback_job lifetime seemed like a
reasonable way to handle all that, with the documentation stating the
only behaviour which is guaranteed to work on all drivers:
* Userspace should wait for this fence to signal before making another
* commit affecting any of the same CRTCs, Planes or Connectors.
* **Failure to do so will result in und
Re: [PATCH 6/6] drm: mali-dp: Add writeback connector
On Fri, Apr 14, 2017 at 11:47:00AM +0200, Boris Brezillon wrote:
On Fri, 25 Nov 2016 16:49:04 +
Brian Starkey wrote:
+static int
+malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct malidp_mw_connector_state *mw_state = to_mw_state(conn_state);
+ struct malidp_drm *malidp = encoder->dev->dev_private;
+ struct drm_framebuffer *fb;
+ int i, n_planes;
+
+ if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
+ return 0;
+
+ fb = conn_state->writeback_job->fb;
+ if ((fb->width != crtc_state->mode.hdisplay) ||
+ (fb->height != crtc_state->mode.vdisplay)) {
+ DRM_DEBUG_KMS("Invalid framebuffer size %ux%u\n",
+ fb->width, fb->height);
+ return -EINVAL;
+ }
These checks look pretty generic to me. Shouldn't we have a default
helper doing that?
Yeah makes sense. These should be common to everyone until
cropping/scaling support is added.
+
+ mw_state->format =
+ malidp_hw_get_format_id(&malidp->dev->map, SE_MEMWRITE,
+ fb->pixel_format);
+ if (mw_state->format == MALIDP_INVALID_FORMAT_ID) {
Same goes here. By adding a format_types table similar to what is
exposed in drm_plane [1], we could do this check in the core. The only
thing left to the driver is the 4CC -> driver-specific-id conversion.
Yeah could do, but given our driver requires us to run through the
whole table to get the HW ID anyway it seemed like totally wasted
effort to do the same thing in the core.
It's probably a negligible overhead, but it's also unnecessary for
100% of the current writeback implementations ;-)
If a different driver is implemented such that the HW ID lookup isn't
an exhaustive list search then we could add a helper for them to use
which checks the blob.
Cheers,
-Brian
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format,
&format_name));
+ return -EINVAL;
+ }
+
+ n_planes = drm_format_num_planes(fb->pixel_format);
+ for (i = 0; i < n_planes; i++) {
+ struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, i);
+ if (!malidp_hw_pitch_valid(malidp->dev, fb->pitches[i])) {
+ DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
+ fb->pitches[i], i);
+ return -EINVAL;
+ }
+ mw_state->pitches[i] = fb->pitches[i];
+ mw_state->addrs[i] = obj->paddr + fb->offsets[i];
+ }
+ mw_state->n_planes = n_planes;
+
+ return 0;
+}
[1]http://lxr.free-electrons.com/source/include/drm/drm_plane.h#L482
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
Hi Laurent,
On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
wrote:
> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>> > The property is used by the driver but is missing from the DT bindings.
>> > Document it.
>> >
>> > Reported-by: Geert Uytterhoeven
>> > Signed-off-by: Laurent Pinchart
>> >
>> > ---
>> >
>> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>> > 1a02f099a0ff..cf34893a1b53 100644
>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>> >
>> > @@ -36,6 +36,11 @@ Required Properties:
>> >When supplied they must be named "dclkin.x" with "x" being the
>> >input
>> >clock numerical index.
>> >
>> > +Optional Properties:
>> > +
>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
>> > +interfaces for the DU channels (Gen3 only).
>>
>> ", one per channel"?
>>
>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>
> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
> the driver doesn't use them, it makes sense to describe the connection. Of
> course the driver will treat the property as optional for backward
> compatibility.
Now it's mandatory, the vsps property should be present in the example, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2] Header: Add rotation property fields
On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss wrote:
> From: Sean Paul
>
> From drm_crtc.h, for use with the plane "rotation" property.
>
> Signed-off-by: Sean Paul
> Signed-off-by: Robert Foss
> Reviewed-by: Sumit Semwal
> ---
> Changes since v1:
> - Added r-b
>
> include/drm/drm.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 1e7a4bc7a505..656c90045161 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -74,6 +74,14 @@ extern "C" {
> #define _DRM_LOCK_IS_CONT(lock) ((lock) & _DRM_LOCK_CONT)
> #define _DRM_LOCKING_CONTEXT(lock) ((lock) &
> ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
>
> +/* Rotation property bits */
> +#define DRM_ROTATE_0 0
> +#define DRM_ROTATE_90 1
> +#define DRM_ROTATE_180 2
> +#define DRM_ROTATE_270 3
> +#define DRM_REFLECT_X 4
> +#define DRM_REFLECT_Y 5
As far as I understand the property mechanism, the numeric values
aren't actually ABI. The string names of the enum values are the ABI
and you're supposed to parse the enum info and discover the numerical
values. For example:
https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570
Kristian
> +
> typedef unsigned int drm_context_t;
> typedef unsigned int drm_drawable_t;
> typedef unsigned int drm_magic_t;
> --
> 2.11.0.453.g787f75f05
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1976-gba8ae8c72f16)
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1976-gba8ae8c72f16) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8c72f16/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1976-gba8ae8c72f16/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1976-gba8ae8c72f16 Git Commit: ba8ae8c72f16c6c8177091d07e0825d54b214d4d Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 10 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dma-fence: Do not call kref utility functions from static inline code
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref implementation to use refcount_t. Commit 29dee3c03abc
("locking/refcounts: Out-of-line everything") changed the refcount_t
utility functions from static inline to EXPORT_SYMBOL_GPL functions.
Through a chain of dma-fence -> kref -> refcount static inline utility
functions, drm drivers can inadvertently pick up a reference to the
EXPORT_SYMBOL_GPL refcount_t functions.
refcount_t is an internal implementation detail and not intended as
an interface. Thus, EXPORT_SYMBOL_GPL seems reasonable for it.
Higher-level dma-fence functions, on the other hand, are intended as an
interface exposed to drm drivers. So, it arguably seems reasonable that
dma-fence functions do not require EXPORT_SYMBOL_GPL.
Move dma_fence_{put,get,get_rcu} from static inline in dma-fence.h to
EXPORT_SYMBOL functions in dma-fence, to make the interface boundary clear.
Signed-off-by: Andy Ritger
---
drivers/dma-buf/dma-fence.c | 41 +
include/linux/dma-fence.h | 40 +++-
2 files changed, 44 insertions(+), 37 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index d195d617076d..863bf55955ef 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -573,3 +573,44 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
trace_dma_fence_init(fence);
}
EXPORT_SYMBOL(dma_fence_init);
+
+/**
+ * dma_fence_put - decreases refcount of the fence
+ * @fence: [in]fence to reduce refcount of
+ */
+void dma_fence_put(struct dma_fence *fence)
+{
+ if (fence)
+ kref_put(&fence->refcount, dma_fence_release);
+}
+EXPORT_SYMBOL(dma_fence_put);
+
+/**
+ * dma_fence_get - increases refcount of the fence
+ * @fence: [in]fence to increase refcount of
+ *
+ * Returns the same fence, with refcount increased by 1.
+ */
+struct dma_fence *dma_fence_get(struct dma_fence *fence)
+{
+ if (fence)
+ kref_get(&fence->refcount);
+ return fence;
+}
+EXPORT_SYMBOL(dma_fence_get);
+
+/**
+ * dma_fence_get_rcu - get a fence from a reservation_object_list with
+ * rcu read lock
+ * @fence: [in]fence to increase refcount of
+ *
+ * Function returns NULL if no refcount could be obtained, or the fence.
+ */
+struct dma_fence *dma_fence_get_rcu(struct dma_fence *fence)
+{
+ if (kref_get_unless_zero(&fence->refcount))
+ return fence;
+ else
+ return NULL;
+}
+EXPORT_SYMBOL(dma_fence_get_rcu);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 6048fa404e57..0e8d714a5bc7 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -185,43 +185,9 @@ void dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
void dma_fence_release(struct kref *kref);
void dma_fence_free(struct dma_fence *fence);
-/**
- * dma_fence_put - decreases refcount of the fence
- * @fence: [in]fence to reduce refcount of
- */
-static inline void dma_fence_put(struct dma_fence *fence)
-{
- if (fence)
- kref_put(&fence->refcount, dma_fence_release);
-}
-
-/**
- * dma_fence_get - increases refcount of the fence
- * @fence: [in]fence to increase refcount of
- *
- * Returns the same fence, with refcount increased by 1.
- */
-static inline struct dma_fence *dma_fence_get(struct dma_fence *fence)
-{
- if (fence)
- kref_get(&fence->refcount);
- return fence;
-}
-
-/**
- * dma_fence_get_rcu - get a fence from a reservation_object_list with
- * rcu read lock
- * @fence: [in]fence to increase refcount of
- *
- * Function returns NULL if no refcount could be obtained, or the fence.
- */
-static inline struct dma_fence *dma_fence_get_rcu(struct dma_fence *fence)
-{
- if (kref_get_unless_zero(&fence->refcount))
- return fence;
- else
- return NULL;
-}
+void dma_fence_put(struct dma_fence *fence);
+struct dma_fence *dma_fence_get(struct dma_fence *fence);
+struct dma_fence *dma_fence_get_rcu(struct dma_fence *fence);
/**
* dma_fence_get_rcu_safe - acquire a reference to an RCU tracked fence
--
2.1.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Do not call kref utility functions from static inline code
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref implementation to use refcount_t. Commit 29dee3c03abc
("locking/refcounts: Out-of-line everything") changed the refcount_t
utility functions from static inline to EXPORT_SYMBOL_GPL functions.
Through a chain of drm -> kref -> refcount static inline utility
functions, drm drivers can inadvertently pick up a reference to the
EXPORT_SYMBOL_GPL refcount_t functions.
refcount_t is an internal implementation detail and not intended as
an interface. Thus, EXPORT_SYMBOL_GPL seems reasonable for it.
Higher-level drm functions, on the other hand, are intended as an
interface exposed to drm drivers. So, it arguably seems reasonable that
drm functions do not require EXPORT_SYMBOL_GPL.
Move drm functions from static inline to EXPORT_SYMBOL functions, to
make the interface boundary clear.
Specifically:
Move:
drm_crtc_commit_get
drm_crtc_commit_put
drm_atomic_state_get
drm_atomic_state_put
from drm_atomic.h to drm_atomic.c.
Move
drm_framebuffer_read_refcount
from drm_framebuffer.h to drm_framebuffer.c.
Move
drm_gem_object_reference
__drm_gem_object_unreference
from drm_gem.h to drm_gem.c.
Signed-off-by: Andy Ritger
---
drivers/gpu/drm/drm_atomic.c | 51 +++
drivers/gpu/drm/drm_framebuffer.c | 12 +
drivers/gpu/drm/drm_gem.c | 35 +++
include/drm/drm_atomic.h | 50 +++---
include/drm/drm_framebuffer.h | 12 +
include/drm/drm_gem.h | 36 ++-
6 files changed, 105 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a5673107db26..84cc92035a97 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -45,6 +45,31 @@ void __drm_crtc_commit_free(struct kref *kref)
EXPORT_SYMBOL(__drm_crtc_commit_free);
/**
+ * drm_crtc_commit_get - acquire a reference to the CRTC commit
+ * @commit: CRTC commit
+ *
+ * Increases the reference of @commit.
+ */
+void drm_crtc_commit_get(struct drm_crtc_commit *commit)
+{
+ kref_get(&commit->ref);
+}
+EXPORT_SYMBOL(drm_crtc_commit_get);
+
+/**
+ * drm_crtc_commit_put - release a reference to the CRTC commmit
+ * @commit: CRTC commit
+ *
+ * This releases a reference to @commit which is freed after removing the
+ * final reference. No locking required and callable from any context.
+ */
+void drm_crtc_commit_put(struct drm_crtc_commit *commit)
+{
+ kref_put(&commit->ref, __drm_crtc_commit_free);
+}
+EXPORT_SYMBOL(drm_crtc_commit_put);
+
+/**
* drm_atomic_state_default_release -
* release memory initialized by drm_atomic_state_init
* @state: atomic state
@@ -239,6 +264,32 @@ void __drm_atomic_state_free(struct kref *ref)
EXPORT_SYMBOL(__drm_atomic_state_free);
/**
+ * drm_atomic_state_get - acquire a reference to the atomic state
+ * @state: The atomic state
+ *
+ * Returns a new reference to the @state
+ */
+struct drm_atomic_state *drm_atomic_state_get(struct drm_atomic_state *state)
+{
+ kref_get(&state->ref);
+ return state;
+}
+EXPORT_SYMBOL(drm_atomic_state_get);
+
+/**
+ * drm_atomic_state_put - release a reference to the atomic state
+ * @state: The atomic state
+ *
+ * This releases a reference to @state which is freed after removing the
+ * final reference. No locking required and callable from any context.
+ */
+void drm_atomic_state_put(struct drm_atomic_state *state)
+{
+ kref_put(&state->ref, __drm_atomic_state_free);
+}
+EXPORT_SYMBOL(drm_atomic_state_put);
+
+/**
* drm_atomic_get_crtc_state - get crtc state
* @state: global atomic state object
* @crtc: crtc to get state object for
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 28a0108a1ab8..6f24ba5e3866 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -837,3 +837,15 @@ int drm_framebuffer_plane_height(int height,
return height / fb->format->vsub;
}
EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+/**
+ * drm_framebuffer_read_refcount - read the framebuffer reference count.
+ * @fb: framebuffer
+ *
+ * This functions returns the framebuffer's reference count.
+ */
+uint32_t drm_framebuffer_read_refcount(struct drm_framebuffer *fb)
+{
+ return kref_read(&fb->base.refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_read_refcount);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bc93de308673..d189b5720bcb 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1004,3 +1004,38 @@ int drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return ret;
}
EXPORT_SYMBOL(drm_gem_mmap);
+
+/**
+ * drm_gem_object_reference - acquire a GEM BO reference
+ * @obj: GEM buffer object
+ *
+ * This acquires additional reference to @obj. It is illegal to call this
+ * without already holding a ref
[PATCH 0/2] Do not call kref utility functions from static inline code
I don't expect these two patches to be terribly popular, but let's see.
Nikhil Mahale described the problem here:
https://lists.freedesktop.org/archives/dri-devel/2017-April/138731.html
In short:
Commit 10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
updated the kref implementation to use refcount_t. Commit 29dee3c03abc
("locking/refcounts: Out-of-line everything") changed the refcount_t
utility functions from static inline to EXPORT_SYMBOL_GPL functions.
Through a chain of drm -> kref -> refcount static inline utility
functions, drm drivers can inadvertently pick up a reference to the
EXPORT_SYMBOL_GPL refcount_t functions.
To be clear: in the case of NVIDIA's dGPU driver, all the code that
interfaces with drm is in the MIT-licensed nvidia-drm.ko kernel module
(i.e., what Daniel Vetter suggested in response to Nikhil). Churn in
the drm interfaces exposed to drm drivers is fine from NVIDIA's point
of view, and the burden is NVIDIA's to maintain an out-of-tree drm driver.
Elsewhere in that thread, Lukas Wunner asked why nvidia-drm.ko is licensed
MIT rather than MIT+GPL:
https://lists.freedesktop.org/archives/dri-devel/2017-April/139033.html
I explained:
We intentionally chose MODULE_LICENSE("MIT") for nvidia-drm.ko, rather
than MODULE_LICENSE("Dual MIT/GPL"), to avoid any ambiguity:
* nvidia-drm.ko depends on nvidia.ko, which is MODULE_LICENSE("NVIDIA").
* nvidia-drm.ko is the portion of the NVIDIA dGPU driver that interfaces
with DRM in the kernel. We wouldn't want nvidia-drm.ko to
inadvertently function as, or even be perceived as, a path for
nvidia.ko to indirectly get access to EXPORT_SYMBOL_GPL symbols.
If it is reasonable for there to be MIT drm drivers, then hopefully it
is reasonable for the interface exported by drm to drm drivers to not
require EXPORT_SYMBOL_GPL.
I admit that losing static inline on the functions in these patches is
unfortunate. Sorry. At least, I don't expect any of these functions
would be used in particularly perf-critical paths.
I should also note that I attempted to remove all kref helper function
calls from static inline drm functions. This is more than strictly
necessary for NVIDIA's needs. But, it seemed good to be consistent.
Andy Ritger (2):
drm: Do not call kref utility functions from static inline code
dma-fence: Do not call kref utility functions from static inline code
drivers/dma-buf/dma-fence.c | 41 +++
drivers/gpu/drm/drm_atomic.c | 51 +++
drivers/gpu/drm/drm_framebuffer.c | 12 +
drivers/gpu/drm/drm_gem.c | 35 +++
include/drm/drm_atomic.h | 50 +++---
include/drm/drm_framebuffer.h | 12 +
include/drm/drm_gem.h | 36 ++-
include/linux/dma-fence.h | 40 +++---
8 files changed, 149 insertions(+), 128 deletions(-)
--
2.1.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2] Header: Add rotation property fields
On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
> wrote:
>> From: Sean Paul
>>
>> From drm_crtc.h, for use with the plane "rotation" property.
>>
>> Signed-off-by: Sean Paul
>> Signed-off-by: Robert Foss
>> Reviewed-by: Sumit Semwal
>> ---
>> Changes since v1:
>> - Added r-b
>>
>> include/drm/drm.h | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/include/drm/drm.h b/include/drm/drm.h
>> index 1e7a4bc7a505..656c90045161 100644
>> --- a/include/drm/drm.h
>> +++ b/include/drm/drm.h
>> @@ -74,6 +74,14 @@ extern "C" {
>> #define _DRM_LOCK_IS_CONT(lock) ((lock) & _DRM_LOCK_CONT)
>> #define _DRM_LOCKING_CONTEXT(lock) ((lock) &
>> ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
>>
>> +/* Rotation property bits */
>> +#define DRM_ROTATE_0 0
>> +#define DRM_ROTATE_90 1
>> +#define DRM_ROTATE_180 2
>> +#define DRM_ROTATE_270 3
>> +#define DRM_REFLECT_X 4
>> +#define DRM_REFLECT_Y 5
>
> As far as I understand the property mechanism, the numeric values
> aren't actually ABI. The string names of the enum values are the ABI
> and you're supposed to parse the enum info and discover the numerical
> values. For example:
> https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570
>
Note sure I agree, yet then again my kernel experience is less than yours.
Do check the following commit and feel free to search the ML thread
that inspired it.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/drm/drm_blend.h?id=226714dc7c6af6d0acee449eb2afce08d128edad
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 00/12] Ion cleanup in preparation for moving out of staging
Hi, This is v4 of the series to cleanup to Ion. Greg took some of the patches that weren't CMA related already. There was a minor bisectability problem with the CMA APIs so this is a new version to address that. I also addressed some minor comments on the patch to collapse header files. Thanks, Laura Laura Abbott (12): cma: Store a name in the cma structure cma: Introduce cma_for_each_area staging: android: ion: Use CMA APIs directly staging: android: ion: Stop butchering the DMA address staging: android: ion: Break the ABI in the name of forward progress staging: android: ion: Get rid of ion_phys_addr_t staging: android: ion: Collapse internal header files staging: android: ion: Rework heap registration/enumeration staging: android: ion: Drop ion_map_kernel interface staging: android: ion: Remove ion_handle and ion_client staging: android: ion: Set query return value staging/android: Update Ion TODO list arch/powerpc/kvm/book3s_hv_builtin.c| 3 +- drivers/base/dma-contiguous.c | 5 +- drivers/staging/android/TODO| 21 +- drivers/staging/android/ion/Kconfig | 32 + drivers/staging/android/ion/Makefile| 11 +- drivers/staging/android/ion/compat_ion.c| 152 - drivers/staging/android/ion/compat_ion.h| 29 - drivers/staging/android/ion/ion-ioctl.c | 55 +- drivers/staging/android/ion/ion.c | 812 ++-- drivers/staging/android/ion/ion.h | 386 --- drivers/staging/android/ion/ion_carveout_heap.c | 21 +- drivers/staging/android/ion/ion_chunk_heap.c| 16 +- drivers/staging/android/ion/ion_cma_heap.c | 120 ++-- drivers/staging/android/ion/ion_heap.c | 68 -- drivers/staging/android/ion/ion_page_pool.c | 3 +- drivers/staging/android/ion/ion_priv.h | 453 - drivers/staging/android/ion/ion_system_heap.c | 39 +- drivers/staging/android/uapi/ion.h | 36 +- include/linux/cma.h | 6 +- mm/cma.c| 31 +- mm/cma.h| 1 + mm/cma_debug.c | 2 +- 22 files changed, 524 insertions(+), 1778 deletions(-) delete mode 100644 drivers/staging/android/ion/compat_ion.c delete mode 100644 drivers/staging/android/ion/compat_ion.h delete mode 100644 drivers/staging/android/ion/ion_priv.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: X.org EVoC Ideas
On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov wrote: > On 18 April 2017 at 16:48, Rob Clark wrote: >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia >> wrote: >>> Hi there >>> >>> I am Raghav Jajodia, an Engineering student from India. While going through >>> the X.org foundation, I felt that X.org is a great community for new Open >>> Source developers. I am deeply interested in being a part of the community. >>> Although, while going through the GSoC and EVoC Ideas, I found that all the >>> ideas revolve around C, C++, QT or Compilers. >>> >>> Working extensively on Web, Moile and Desktop applications, I have gained >>> good experience with Python, JS, PHP, Ruby etc. But I do not have any >>> experience with C/C++. >>> >>> So, is not possible for a student to participate in EVoC if he doesn't have >>> any experience with Open source softwares built on C/C++. Are there any >>> project ideas using languages apart from C/C++ that a student can work on >>> for EVoC 17/18? >> >> Hi, the only requirement regarding programming languages is that >> "Applicants know their target programming language.".. there isn't >> any requirement otherwise, but I think the fast majority are largely >> C/C++. There are bits of python here and there (piglit, for example.. >> possibly others that I don't know of). >> >> From a quick look all of the suggested projects involve C and/or C++. >> But that doesn't mean a candidate couldn't suggest a different project >> that is not on the list. >> > FWIW the python in piglit is fine, while the one in Mesa is in a dire shape. I didn't realize there where TODO's for py involved in mesa build.. maybe we should add some to the SummerOfCodeIdeas wiki page[1] /me would add convert nir_intrinsic.h + multiple #includes to .py generating .c and .h if there was such a topic.. maybe not enough for a EVoC/GSoC project on it's own but perhaps if combined w/ some other work needed on mesa's python.. BR, -R [1] https://www.x.org/wiki/SummerOfCodeIdeas/ > That said, I believe Rob summarised it perfectly: > Take a look around and feel free to propose something if the ones > listed do not interest you. > > Regards, > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 02/12] cma: Introduce cma_for_each_area
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align,
gfp_t gfp_mask);
extern bool cma_release(struct cma *cma, const struct page *pages, unsigned
int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void
*data);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 43c1b2c..978b4a1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -504,3 +504,17 @@ bool cma_release(struct cma *cma, const struct page
*pages, unsigned int count)
return true;
}
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+ int i;
+
+ for (i = 0; i < cma_area_count; i++) {
+ int ret = it(&cma_areas[i], data);
+
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 01/12] cma: Store a name in the cma structure
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
arch/powerpc/kvm/book3s_hv_builtin.c | 3 ++-
drivers/base/dma-contiguous.c| 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c | 17 +++--
mm/cma.h | 1 +
mm/cma_debug.c | 2 +-
6 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 4d6c64b..b739ff8 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -100,7 +100,8 @@ void __init kvm_cma_reserve(void)
(unsigned long)selected_size / SZ_1M);
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
cma_declare_contiguous(0, selected_size, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, &kvm_cma);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
+ &kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b55804c..ea9726e 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -165,7 +165,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed, res_cma);
+ ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed,
+ "reserved", res_cma);
if (ret)
return ret;
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
- err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
+ err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name,
&cma);
if (err) {
pr_err("Reserved memory: unable to setup CMA region\n");
return err;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 03f32d0..d41d1f8 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -21,13 +21,15 @@ struct cma;
extern unsigned long totalcma_pages;
extern phys_addr_t cma_get_base(const struct cma *cma);
extern unsigned long cma_get_size(const struct cma *cma);
+extern const char *cma_get_name(const struct cma *cma);
extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
- bool fixed, struct cma **res_cma);
+ bool fixed, const char *name, struct cma **res_cma);
extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+ const char *name,
struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align,
gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..43c1b2c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -53,6 +53,11 @@ unsigned long cma_get_size(const struct cma *cma)
return cma->count << PAGE_SHIFT;
}
+const char *cma_get_name(const struct cma *cma)
+{
+ return cma->name ? cma->name : "(undefined)";
+}
+
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
int align_order)
{
@@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
*/
int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+const char *name,
struct cma **res_cma)
{
struct cma *cma;
@@ -198,6 +204,13 @@ int __init cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
* subsystems (like slab allocator) are available.
*/
cma = &cma_areas[cma_area_count];
+ if (name) {
+ cma->name = name;
+ } else {
+ cma->name = kasprintf(GFP_KERNEL, "cma%d\n", cma_area_count);
+ if (!cma->name)
+ return -ENOMEM;
+ }
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
@@ -229,7 +242,7 @@ int __init cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
- bool fixed, struct cma **res_cma)
+ bool fixed, const char *name, struct
[PATCHv4 03/12] staging: android: ion: Use CMA APIs directly
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).
Signed-off-by: Laura Abbott
---
v4: Put some #ifdef around CMA heap functions. This is ugly but gets removed
a few patches later.
---
drivers/staging/android/ion/Kconfig| 7 +++
drivers/staging/android/ion/Makefile | 3 +-
drivers/staging/android/ion/ion_cma_heap.c | 97 --
drivers/staging/android/ion/ion_heap.c | 4 ++
4 files changed, 39 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
If you're not using Android its probably safe to
say N here.
+config ION_CMA_HEAP
+ bool "Ion CMA heap support"
+ depends on ION && CMA
+ help
+ Choose this option to enable CMA heaps with Ion. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
- ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+ ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
ifdef CONFIG_COMPAT
obj-$(CONFIG_ION) += compat_ion.o
endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
#include
#include
#include
-#include
+#include
+#include
#include "ion.h"
#include "ion_priv.h"
struct ion_cma_heap {
struct ion_heap heap;
- struct device *dev;
+ struct cma *cma;
};
#define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
-struct ion_cma_buffer_info {
- void *cpu_addr;
- dma_addr_t handle;
- struct sg_table *table;
-};
-
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
unsigned long flags)
{
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
- struct device *dev = cma_heap->dev;
- struct ion_cma_buffer_info *info;
-
- dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
- if (buffer->flags & ION_FLAG_CACHED)
- return -EINVAL;
+ struct sg_table *table;
+ struct page *pages;
+ int ret;
- info = kzalloc(sizeof(*info), GFP_KERNEL);
- if (!info)
+ pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+ if (!pages)
return -ENOMEM;
- info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
- GFP_HIGHUSER | __GFP_ZERO);
-
- if (!info->cpu_addr) {
- dev_err(dev, "Fail to allocate buffer\n");
+ table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+ if (!table)
goto err;
- }
- info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
- if (!info->table)
+ ret = sg_alloc_table(table, 1, GFP_KERNEL);
+ if (ret)
goto free_mem;
- if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
- len))
- goto free_table;
- /* keep this for memory release */
- buffer->priv_virt = info;
- buffer->sg_table = info->table;
- dev_dbg(dev, "Allocate buffer %p\n", buffer);
+ sg_set_page(table->sgl, pages, len, 0);
+
+ buffer->priv_virt = pages;
+ buffer->sg_table = table;
return 0;
-free_table:
- kfree(info->table);
free_mem:
- dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+ kfree(table);
err:
- kfree(info);
+ cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
}
static void ion_cma_free(struct ion_buffer *buffer)
{
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
[PATCHv4 04/12] staging: android: ion: Stop butchering the DMA address
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
{
struct ion_buffer *buffer;
struct sg_table *table;
- struct scatterlist *sg;
- int i, ret;
+ int ret;
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
INIT_LIST_HEAD(&buffer->vmas);
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
- /*
-* this will set up dma addresses for the sglist -- it is not
-* technically correct as per the dma api -- a specific
-* device isn't really taking ownership here. However, in practice on
-* our systems the only dma_address space is physical addresses.
-* Additionally, we can't afford the overhead of invalidating every
-* allocation via dma_map_sg. The implicit contract here is that
-* memory coming from the heaps is ready for dma, ie if it has a
-* cached mapping that mapping has been invalidated
-*/
- for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
- sg_dma_address(sg) = sg_phys(sg);
- sg_dma_len(sg) = sg->length;
- }
mutex_lock(&dev->buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(&dev->buffer_lock);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress
Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile | 3 -
drivers/staging/android/ion/compat_ion.c | 152 ---
drivers/staging/android/ion/compat_ion.h | 29 --
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/ion/ion.c| 5 +-
drivers/staging/android/uapi/ion.h | 19 ++--
6 files changed, 11 insertions(+), 198 deletions(-)
delete mode 100644 drivers/staging/android/ion/compat_ion.c
delete mode 100644 drivers/staging/android/ion/compat_ion.h
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ obj-$(CONFIG_ION) +=ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
ion_carveout_heap.o ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include
-#include
-#include
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs
*/
-struct compat_ion_allocation_data {
- compat_size_t len;
- compat_size_t align;
- compat_uint_t heap_id_mask;
- compat_uint_t flags;
- compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
- compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
- struct compat_ion_allocation_data __user *data32,
- struct ion_allocation_data __user *data)
-{
- compat_size_t s;
- compat_uint_t u;
- compat_int_t i;
- int err;
-
- err = get_user(s, &data32->len);
- err |= put_user(s, &data->len);
- err |= get_user(s, &data32->align);
- err |= put_user(s, &data->align);
- err |= get_user(u, &data32->heap_id_mask);
- err |= put_user(u, &data->heap_id_mask);
- err |= get_user(u, &data32->flags);
- err |= put_user(u, &data->flags);
- err |= get_user(i, &data32->handle);
- err |= put_user(i, &data->handle);
-
- return err;
-}
-
-static int compat_get_ion_handle_data(
- struct compat_ion_handle_data __user *data32,
- struct ion_handle_data __user *data)
-{
- compat_int_t i;
- int err;
-
- err = get_user(i, &data32->handle);
- err |= put_user(i, &data->handle);
-
- return err;
-}
-
-static int compat_put_ion_allocation_data(
- struct compat_ion_allocation_data __user *data32,
- struct ion_allocation_data __user *data)
-{
- compat_size_t s;
- compat_uint_t u;
- compat_int_t i;
- int err;
-
- err = get_user(s, &data->len);
- err |= put_user(s, &data32->len);
- err |= get_user(s, &data->align);
- err |= put_user(s, &data32->align);
- err |= get_user(u, &data->heap_id_mask);
- err |= put_user(u, &data32->heap_id_mask);
- err |= get_user(u, &data->flags);
- err |= put_user(u, &data32->flags);
- err |= get_user(i, &data->handle);
- err |= put_user(i, &data32->handle);
-
- return err;
-}
-
-long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
- long ret;
-
- if (!filp->f_op->unlocked_ioctl)
- return -ENOTTY;
-
- switch (cmd) {
- case COMPAT_ION_IOC_ALLOC:
- {
- struct compat_ion_allocat
[PATCHv4 06/12] staging: android: ion: Get rid of ion_phys_addr_t
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h | 12 ++--
drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
drivers/staging/android/ion/ion_chunk_heap.c| 6 +++---
drivers/staging/android/ion/ion_heap.c | 4 ++--
4 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
struct ion_client;
struct ion_buffer;
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t. For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
/**
* struct ion_platform_heap - defines a heap in the given platform
* @type: type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
- ion_phys_addr_t base;
+ phys_addr_t base;
size_t size;
- ion_phys_addr_t align;
+ phys_addr_t align;
void *priv;
};
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
- ion_phys_addr_t base;
+ phys_addr_t base;
};
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap
*heap,
return offset;
}
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
unsigned long flags)
{
struct sg_table *table;
- ion_phys_addr_t paddr;
+ phys_addr_t paddr;
int ret;
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
- ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+ phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
ion_heap_buffer_zero(buffer);
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
- ion_phys_addr_t base;
+ phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct
ion_platform_heap *heap_data)
chunk_heap->heap.ops = &chunk_heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
- pr_debug("%s: base %lu size %zu \n", __func__,
-chunk_heap->base, heap_data->size);
+ pr_debug("%s: base %pa size %zu \n", __func__,
+&chunk_heap->base, heap_data->size);
return &chunk_heap->heap;
diff --git a/drivers/staging/android/ion/ion_heap.c
b/drivers/staging/android/ion/ion_heap.c
index 66f8fc5..c974623 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -345,9 +345,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap
*heap_data)
}
if (IS_ERR_OR_NULL(heap)) {
- pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+ pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
__func__, heap_data->name, heap_data->type,
- heap_data->base, heap_data->size);
+ &heap_data->base, heap_data->size);
[PATCHv4 08/12] staging: android: ion: Rework heap registration/enumeration
The current model of Ion heap registration is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig | 25 +
drivers/staging/android/ion/Makefile| 7 +--
drivers/staging/android/ion/ion.c | 28 +-
drivers/staging/android/ion/ion.h | 40 +-
drivers/staging/android/ion/ion_carveout_heap.c | 10
drivers/staging/android/ion/ion_chunk_heap.c| 9
drivers/staging/android/ion/ion_cma_heap.c | 24 +++--
drivers/staging/android/ion/ion_heap.c | 71 -
drivers/staging/android/ion/ion_system_heap.c | 38 -
9 files changed, 85 insertions(+), 167 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
If you're not using Android its probably safe to
say N here.
+config ION_SYSTEM_HEAP
+ bool "Ion system heap"
+ depends on ION
+ help
+ Choose this option to enable the Ion system heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+ bool "Ion carveout heap support"
+ depends on ION
+ help
+ Choose this option to enable carveout heaps with Ion. Carveout heaps
+ are backed by memory reserved from the system. Allocation times are
+ typically faster at the cost of memory not being used. Unless you
+ know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+ bool "Ion chunk heap support"
+ depends on ION
+ help
+ Choose this option to enable chunk heaps with Ion. This heap is
+ similar in function the carveout heap but memory is broken down
+ into smaller chunk sizes, typically corresponding to a TLB size.
+ Unless you know your system has these regions, you should say N here.
+
config ION_CMA_HEAP
bool "Ion CMA heap support"
depends on ION && CMA
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
- ion_page_pool.o ion_system_heap.o \
- ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
#include "ion.h"
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
bool ion_buffer_cached(struct ion_buffer *buffer)
{
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
{
struct dentry *debug_file;
+ struct ion_device *dev = internal_dev;
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct
ion_heap *heap)
heap->dev = dev;
down_write(&dev->lock);
+ heap->id = heap_id++;
/*
* use negative heap->id to reverse the priority -- when traversing
* the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct
ion_heap *heap)
}
EXPORT_SYMBOL(ion_device_add_heap);
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
{
struct ion_device *idev;
int ret;
idev = kzalloc(sizeof(*idev), GFP_KERNEL);
if (!idev)
- return
[PATCHv4 09/12] staging: android: ion: Drop ion_map_kernel interface
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
}
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
- struct ion_buffer *buffer = handle->buffer;
- void *vaddr;
-
- if (handle->kmap_cnt) {
- handle->kmap_cnt++;
- return buffer->vaddr;
- }
- vaddr = ion_buffer_kmap_get(buffer);
- if (IS_ERR(vaddr))
- return vaddr;
- handle->kmap_cnt++;
- return vaddr;
-}
-
static void ion_buffer_kmap_put(struct ion_buffer *buffer)
{
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
}
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
- struct ion_buffer *buffer;
- void *vaddr;
-
- mutex_lock(&client->lock);
- if (!ion_handle_validate(client, handle)) {
- pr_err("%s: invalid handle passed to map_kernel.\n",
- __func__);
- mutex_unlock(&client->lock);
- return ERR_PTR(-EINVAL);
- }
-
- buffer = handle->buffer;
-
- if (!handle->buffer->heap->ops->map_kernel) {
- pr_err("%s: map_kernel is not implemented by this heap.\n",
- __func__);
- mutex_unlock(&client->lock);
- return ERR_PTR(-ENODEV);
- }
-
- mutex_lock(&buffer->lock);
- vaddr = ion_handle_kmap_get(handle);
- mutex_unlock(&buffer->lock);
- mutex_unlock(&client->lock);
- return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
- struct ion_buffer *buffer;
-
- mutex_lock(&client->lock);
- buffer = handle->buffer;
- mutex_lock(&buffer->lock);
- ion_handle_kmap_put(handle);
- mutex_unlock(&buffer->lock);
- mutex_unlock(&client->lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
static struct mutex debugfs_mutex;
static struct rb_root *ion_root_client;
static int is_client_alive(struct ion_client *client)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 12/12] staging/android: Update Ion TODO list
Most of the items have been taken care of by a clean up series. Remove the completed items and add a few new ones. Signed-off-by: Laura Abbott --- drivers/staging/android/TODO | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO index 8f3ac37..5f14247 100644 --- a/drivers/staging/android/TODO +++ b/drivers/staging/android/TODO @@ -7,23 +7,10 @@ TODO: ion/ - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal - interface on top of dma-buf. flush_for_device needs to be added to dma-buf - first. - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some - vendor trees. Should be replaced with an ioctl on the dma-buf to expose the - begin/end_cpu_access hooks to userspace. - - Clarify the tricks ion plays with explicitly managing coherency behind the - dma api's back (this is absolutely needed for high-perf gpu drivers): Add an - explicit coherency management mode to flush_for_device to be used by drivers - which want to manage caches themselves and which indicates whether cpu caches - need flushing. - - With those removed there's probably no use for ION_IOC_IMPORT anymore either - since ion would just be the central allocator for shared buffers. - - Add dt-binding to expose cma regions as ion heaps, with the rule that any - such cma regions must already be used by some device for dma. I.e. ion only - exposes existing cma regions and doesn't reserve unecessarily memory when - booting a system which doesn't use ion. + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would + involve putting appropriate bindings in a memory node for Ion to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0) + - Better test framework (integration with VGEM was suggested) Please send patches to Greg Kroah-Hartman and Cc: Arve Hjønnevåg and Riley Andrews -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 11/12] staging: android: ion: Set query return value
This never got set in the ioctl. Properly set a return value of 0 on success. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 9eeb06f..d6fd350 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query) } query->cnt = cnt; + ret = 0; out: up_read(&dev->lock); return ret; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 53 +--
drivers/staging/android/ion/ion.c | 701 ++--
drivers/staging/android/ion/ion.h | 77 +---
drivers/staging/android/uapi/ion.h | 25 +-
4 files changed, 51 insertions(+), 805 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
#include "ion.h"
union ion_ioctl_arg {
- struct ion_fd_data fd;
struct ion_allocation_data allocation;
- struct ion_handle_data handle;
struct ion_heap_query query;
};
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union
ion_ioctl_arg *arg)
static unsigned int ion_ioctl_dir(unsigned int cmd)
{
switch (cmd) {
- case ION_IOC_FREE:
- return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
- struct ion_client *client = filp->private_data;
- struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
- struct ion_handle *handle;
+ int fd;
- handle = ion_alloc(client, data.allocation.len,
+ fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
- if (IS_ERR(handle))
- return PTR_ERR(handle);
+ if (fd < 0)
+ return fd;
- data.allocation.handle = handle->id;
+ data.allocation.fd = fd;
- cleanup_handle = handle;
- break;
- }
- case ION_IOC_FREE:
- {
- struct ion_handle *handle;
-
- mutex_lock(&client->lock);
- handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
- if (IS_ERR(handle)) {
- mutex_unlock(&client->lock);
- return PTR_ERR(handle);
- }
- ion_free_nolock(client, handle);
- ion_handle_put_nolock(handle);
- mutex_unlock(&client->lock);
- break;
- }
- case ION_IOC_SHARE:
- {
- struct ion_handle *handle;
-
- handle = ion_handle_get_by_id(client, data.handle.handle);
- if (IS_ERR(handle))
- return PTR_ERR(handle);
- data.fd.fd = ion_share_dma_buf_fd(client, handle);
- ion_handle_put(handle);
- if (data.fd.fd < 0)
- ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
- ret = ion_query_heaps(client, &data.query);
+ ret = ion_query_heaps(&data.query);
break;
default:
return -ENOTTY;
}
if (dir & _IOC_READ) {
- if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd))) {
- if (cleanup_handle)
- ion_free(client, cleanup_handle);
+ if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd)))
return -EFAULT;
- }
}
return ret;
}
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 5a82bea..9eeb06f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
buffer->heap = heap;
buffer->flags = flags;
- kref_init(&buffer->ref);
ret = heap->ops->allocate(heap,
[PATCHv4 07/12] staging: android: ion: Collapse internal header files
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
v4: minor cleanup suggested by Emil Velikov
---
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion.h | 479
drivers/staging/android/ion/ion_carveout_heap.c | 1 -
drivers/staging/android/ion/ion_chunk_heap.c| 1 -
drivers/staging/android/ion/ion_cma_heap.c | 1 -
drivers/staging/android/ion/ion_heap.c | 1 -
drivers/staging/android/ion/ion_page_pool.c | 3 +-
drivers/staging/android/ion/ion_priv.h | 453 --
drivers/staging/android/ion/ion_system_heap.c | 1 -
10 files changed, 402 insertions(+), 540 deletions(-)
delete mode 100644 drivers/staging/android/ion/ion_priv.h
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
#include
#include "ion.h"
-#include "ion_priv.h"
union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
#include
#include "ion.h"
-#include "ion_priv.h"
bool ion_buffer_cached(struct ion_buffer *buffer)
{
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index e8a6ffe..fd49403 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -14,24 +14,26 @@
*
*/
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_H
+#define _ION_H
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
#include "../uapi/ion.h"
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
/**
* struct ion_platform_heap - defines a heap in the given platform
* @type: type of the heap from ion_heap_type enum
- * @id:unique identifier for heap. When allocating higher
numbers
+ * @id:unique identifier for heap. When allocating higher
numb ers
* will be allocated from first. At allocation these are passed
* as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
* @name: used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
};
/**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref: reference count
+ * @node: node in the ion_device buffers tree
+ * @dev: back pointer to the ion_device
+ * @heap: back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size: size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @lock: protects the buffers cnt fields
+ * @kmap_cnt: number of times the buffer is mapped to the kernel
+ * @vaddr: the kernel mapping if kmap_cnt is not zero
+ * @sg_table: the sg table for the buffer if dmap_cnt is not zero
+ * @pages: flat array of pages in the buffer -- used by fault
+ * handler and only valid for buffers that are faulted in
+ * @vmas: list of vma's mapping this buffer
+ * @handle_count: count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid: pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+ struct kref ref;
+ union {
+ struct rb_node node;
+ struct list_head list;
+ };
+ struct ion_device *dev;
+ struct ion_heap *heap;
+ unsigned long flags;
+ unsigned long private_flags;
+ size_t size;
+ void *priv_virt;
+ struct mutex lock;
+ int kmap_cnt;
+ void *vaddr;
+ struct sg_table *sg_table;
+ struct page **pages;
+ struct list_head vmas;
+ struct list_head attachments;
+ /* used to track orphaned buffers */
+ int handle_count;
+ char task_comm[TASK_COMM_LEN];
+ pid_t pid;
+};
+v
Re: [PATCH libdrm v2] Header: Add rotation property fields
On Tue, Apr 18, 2017 at 11:03 AM, Emil Velikov wrote:
> On 18 April 2017 at 18:38, Kristian Høgsberg wrote:
>> On Mon, Apr 17, 2017 at 1:13 PM, Robert Foss
>> wrote:
>>> From: Sean Paul
>>>
>>> From drm_crtc.h, for use with the plane "rotation" property.
>>>
>>> Signed-off-by: Sean Paul
>>> Signed-off-by: Robert Foss
>>> Reviewed-by: Sumit Semwal
>>> ---
>>> Changes since v1:
>>> - Added r-b
>>>
>>> include/drm/drm.h | 8
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/include/drm/drm.h b/include/drm/drm.h
>>> index 1e7a4bc7a505..656c90045161 100644
>>> --- a/include/drm/drm.h
>>> +++ b/include/drm/drm.h
>>> @@ -74,6 +74,14 @@ extern "C" {
>>> #define _DRM_LOCK_IS_CONT(lock) ((lock) & _DRM_LOCK_CONT)
>>> #define _DRM_LOCKING_CONTEXT(lock) ((lock) &
>>> ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
>>>
>>> +/* Rotation property bits */
>>> +#define DRM_ROTATE_0 0
>>> +#define DRM_ROTATE_90 1
>>> +#define DRM_ROTATE_180 2
>>> +#define DRM_ROTATE_270 3
>>> +#define DRM_REFLECT_X 4
>>> +#define DRM_REFLECT_Y 5
>>
>> As far as I understand the property mechanism, the numeric values
>> aren't actually ABI. The string names of the enum values are the ABI
>> and you're supposed to parse the enum info and discover the numerical
>> values. For example:
>> https://git.collabora.com/cgit/user/daniels/weston.git/tree/libweston/compositor-drm.c?h=wip/2017-03/atomic-v10-WIP#n570
>>
> Note sure I agree, yet then again my kernel experience is less than yours.
> Do check the following commit and feel free to search the ML thread
> that inspired it.
I haven't worked much with the property mechanism tbh, but I know
Daniel (Stone) jumped through all those hoops to avoid hard-coding the
enum values.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/drm/drm_blend.h?id=226714dc7c6af6d0acee449eb2afce08d128edad
>
> Thanks
> Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1977-gbd206d943e83)
drm-tip/drm-tip boot: 17 boots: 2 failed, 15 passed (v4.11-rc6-1977-gbd206d943e83) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d943e83/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1977-gbd206d943e83/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1977-gbd206d943e83 Git Commit: bd206d943e8308fcb814d0595620c140a191cfea Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 10 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100681] F1 2015 glitches (letters mainly)
https://bugs.freedesktop.org/show_bug.cgi?id=100681 --- Comment #5 from Andy Furniss --- OK, I sent a mail - awaiting moderation for the cc as I am not on any llvm lists. I did try to add the author as cc on the tracker when I filed the bug, but no luck, it would be handy if committers could join the bug tracker of the projects they commit to, (with the email they use to commit). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.
For the Raspberry Pi's bindings, the power domain also implicitly
turns on the clock and deasserts reset, but for the new Cygnus port we
start representing the clock in the devicetree.
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 ++
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 33 ++
3 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index ca02d3e4db91..bc1756f4f791 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -59,6 +59,9 @@ Required properties for V3D:
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+Optional properties for V3D:
+- clocks: The clock the unit runs on
+
Required properties for DSI:
- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1"
- reg: Physical base address and length of the DSI block's registers
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 81d2bc08e766..08d5c2213c80 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -189,6 +189,7 @@ struct vc4_v3d {
struct vc4_dev *vc4;
struct platform_device *pdev;
void __iomem *regs;
+ struct clk *clk;
};
struct vc4_hvs {
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 7cc346ad9b0b..2442622e6bff 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -16,6 +16,7 @@
* this program. If not, see
[PATCH 3/3] drm/vc4: Add specific compatible strings for Cygnus.
Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display
modules. The V3D can be uniquely identified by the IDENT[01]
registers, and there's nothing to key off of for the display change
other than the lack of DT nodes for the display components, but it's
convention to have new compatible strings anyway.
Signed-off-by: Eric Anholt
---
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 4 ++--
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index bc1756f4f791..284e2b14cfbe 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -5,7 +5,7 @@ with HDMI output and the HVS (Hardware Video Scaler) for
compositing
display planes.
Required properties for VC4:
-- compatible: Should be "brcm,bcm2835-vc4"
+- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
Required properties for Pixel Valve:
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
@@ -54,7 +54,7 @@ Required properties for VEC:
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for V3D:
-- compatible: Should be "brcm,bcm2835-v3d"
+- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d"
- reg: Physical base address and length of the V3D's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 92fb9a41fe7c..754ce76d4b98 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -335,6 +335,7 @@ static int vc4_platform_drm_remove(struct platform_device
*pdev)
static const struct of_device_id vc4_of_match[] = {
{ .compatible = "brcm,bcm2835-vc4", },
+ { .compatible = "brcm,cygnus-vc4", },
{},
};
MODULE_DEVICE_TABLE(of, vc4_of_match);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 2442622e6bff..3abcd27aa46f 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -304,6 +304,7 @@ static int vc4_v3d_dev_remove(struct platform_device *pdev)
static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,bcm2835-v3d" },
+ { .compatible = "brcm,cygnus-v3d" },
{ .compatible = "brcm,vc4-v3d" },
{}
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
The FBDEV initialization would throw an error in dmesg, when we just
want to silently not initialize fbdev on a V3D-only VC4 instance.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ad7925a9e0ea..237a504f11f0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -230,10 +230,12 @@ int vc4_kms_load(struct drm_device *dev)
drm_mode_config_reset(dev);
- vc4->fbdev = drm_fbdev_cma_init(dev, 32,
- dev->mode_config.num_connector);
- if (IS_ERR(vc4->fbdev))
- vc4->fbdev = NULL;
+ if (dev->mode_config.num_connector) {
+ vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+ dev->mode_config.num_connector);
+ if (IS_ERR(vc4->fbdev))
+ vc4->fbdev = NULL;
+ }
drm_kms_helper_poll_init(dev);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vc4: Turn the V3D clock on at runtime.
Eric Anholt writes:
> For the Raspberry Pi's bindings, the power domain also implicitly
> turns on the clock and deasserts reset, but for the new Cygnus port we
> start representing the clock in the devicetree.
> + v3d->clk = devm_clk_get(dev, "v3d_clk");
> + if (IS_ERR(v3d->clk)) {
> + int ret = PTR_ERR(v3d->clk);
> +
> + if (ret == -ENODEV) {
Apparently I hadn't booted this on RPi yet. This is supposed to be
-ENOENT.
> + /* bcm2835 didn't have a clock reference in the DT. */
> + ret = 0;
> + v3d->clk = NULL;
> + } else {
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get V3D clock: %d\n",
> + ret);
> + return ret;
> + }
> + }
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Document code of conduct
On Tue, 2017-04-18 at 12:10 +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > v2: Drop confusing note from commit message and clarify the grammer > (Chris, Alex and others). Acked-by: Adam Jackson - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [repost] drm sync objects cleaned up
On 14 April 2017 at 19:45, Chris Wilson wrote: > On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote: >> This set of sync object patches should address most of the issues >> raised in review. >> >> The major changes: >> Race on destroy should be gone, >> Documentation fixups >> amdgpu internal use p instead of adev fixups >> >> My plans are to write some igt tests this week, and try >> to get some more review on what the API should allow (should >> I lock it down to drm syncobj is just semaphores for now). > > Having an idr of handles is much, much nicer than fd and I want the same > for fences :) Okay, but what form do you want the API to take for fences? because I've just ported all this to using sem_file as the backend, instead of sync_file which seems to oppose the goal of using it for fences. For fences do you want upfront creation, then passing created fences object into command submission that attach the internal fence? Or do you want command submission to have out fence handles that it creates, so we don't have any explicit syncobj create for fences? Do you want those fences to be shareable across processes using sync_file semantics? I kinda feel like I'm going around in circles here and I'm going to just merge something instead. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: X.org EVoC Ideas
On Tue, Apr 18, 2017 at 02:27:14PM -0400, Rob Clark wrote: > On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov > wrote: > > On 18 April 2017 at 16:48, Rob Clark wrote: > >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia > >> wrote: > >>> Hi there > >>> > >>> I am Raghav Jajodia, an Engineering student from India. While going > >>> through > >>> the X.org foundation, I felt that X.org is a great community for new Open > >>> Source developers. I am deeply interested in being a part of the > >>> community. > >>> Although, while going through the GSoC and EVoC Ideas, I found that all > >>> the > >>> ideas revolve around C, C++, QT or Compilers. > >>> > >>> Working extensively on Web, Moile and Desktop applications, I have gained > >>> good experience with Python, JS, PHP, Ruby etc. But I do not have any > >>> experience with C/C++. > >>> > >>> So, is not possible for a student to participate in EVoC if he doesn't > >>> have > >>> any experience with Open source softwares built on C/C++. Are there any > >>> project ideas using languages apart from C/C++ that a student can work on > >>> for EVoC 17/18? > >> > >> Hi, the only requirement regarding programming languages is that > >> "Applicants know their target programming language.".. there isn't > >> any requirement otherwise, but I think the fast majority are largely > >> C/C++. There are bits of python here and there (piglit, for example.. > >> possibly others that I don't know of). > >> > >> From a quick look all of the suggested projects involve C and/or C++. > >> But that doesn't mean a candidate couldn't suggest a different project > >> that is not on the list. > >> > > FWIW the python in piglit is fine, while the one in Mesa is in a dire shape. > > I didn't realize there where TODO's for py involved in mesa build.. > maybe we should add some to the SummerOfCodeIdeas wiki page[1] > > /me would add convert nir_intrinsic.h + multiple #includes to .py > generating .c and .h if there was such a topic.. maybe not enough for > a EVoC/GSoC project on it's own but perhaps if combined w/ some other > work needed on mesa's python.. > > BR, > -R > > [1] https://www.x.org/wiki/SummerOfCodeIdeas/ Or just add a link to the TODO in the codebase here? That's essentially what we're doing for the kernel, at least for the cleanup/refactor tasks. -Daniel > > > > That said, I believe Rob summarised it perfectly: > > Take a look around and feel free to propose something if the ones > > listed do not interest you. > > > > Regards, > > Emil > ___ > bo...@foundation.x.org: X.Org Foundation Board of Directors > Archives: https://foundation.x.org/cgi-bin/mailman/private/board > Info: https://foundation.x.org/cgi-bin/mailman/listinfo/board -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194843] [amdgpu] oops [drm:gfx_v8_0_priv_reg_irq] *ERROR* Illegal register access in command stream
https://bugzilla.kernel.org/show_bug.cgi?id=194843 --- Comment #6 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- Some more observation: It seems the hangs happen much more often/frequent with kernel 4.11 than with 4.10. Where 4.10 kernels running usually several days, I have a hang with 4.11 within a day. Additionally I've found some of the WARNING: CPU: 1 PID: 872 at ./include/linux/dma-fence.h:349 amdgpu_vm_grab_id entries in the logs without a hang at this time. As far as I've seen this was always with a 4.10 kernel. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
