Re: 答复: [PATCH 4/4] drm/amdgpu: Add audio component support
On Wed, 25 Jul 2018 07:38:37 +0200,
Qu, Jim wrote:
>
> Jim: Just like Alex said, we want driver can get eld info when hotplug in new
> device. amdgpu driver is a bit difference from radeon driver, it is not a
> suitable place to call notify() function in *_audio_enable() , since they are
> not in the hotplug process context like them in radeon driver, but the mode
> setting.
>
> IMO, the right place to call notify() function is also in the
> amdgpu_connector__detect() in amdgpu_connector.c.
Hm, but by the modesetting, it actually enables / disables the audio
as well, no? If so, the notifier is exactly for that purpose. The
audio driver needs to know not only about the physical connection but
whether the audio can be actually driven.
That is, even if the monitor is connected, the audio won't come out if
the mode is off. That is equivalent with the unplugged state for the
audio driver.
The i915 driver deals with the notifier just like the above, so the
behavior is intentional.
thanks,
Takashi
> With None-DC driver, the detect() of connectors will to be preformed in
> drm_helper_hpd_irq_event() when there is device hotplug. However,
> amdgpu_connector__detect() maybe need to be modified to fit your change.
>
> Thanks
> JimQu
>
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c | 97 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 +
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 ++
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 6 ++
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++
> 9 files changed, 130 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2c7112ddfed4..fbe7216c5c56 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -193,6 +193,7 @@ config DRM_AMDGPU
> select BACKLIGHT_LCD_SUPPORT
> select INTERVAL_TREE
> select CHASH
> + select SND_HDA_COMPONENT if SND_HDA_CORE
> help
> Choose this option if you have a recent AMD Radeon graphics card.
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index bfd332c95b61..9c26facddb17 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -52,7 +52,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> amdgpu_atomfirmware.o \
> amdgpu_queue_mgr.o amdgpu_vf_error.o amdgpu_sched.o amdgpu_debugfs.o \
> - amdgpu_ids.o
> + amdgpu_ids.o amdgpu_audio.o
>
> # add asic specific block
> amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index a59c07590cee..203d2584c989 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1957,5 +1957,9 @@ int amdgpu_dm_display_resume(struct amdgpu_device *adev
> );
> static inline int amdgpu_dm_display_resume(struct amdgpu_device *adev) {
> return 0; }
> #endif
>
> +int amdgpu_audio_component_init(struct amdgpu_device *adev);
> +void amdgpu_audio_component_fini(struct amdgpu_device *adev);
> +void amdgpu_audio_eld_notify(struct amdgpu_device *adev, int pin);
> +
> #include "amdgpu_object.h"
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
> new file mode 100644
> index ..39256e2f84b3
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: MIT
> +
> +#include
> +#include "amdgpu.h"
> +
> +static int amdgpu_audio_component_get_eld(struct device *kdev, int port,
> + int pipe, bool *enabled,
> + unsigned char *buf, int max_bytes)
> +{
> + struct drm_device *dev = dev_get_drvdata(kdev);
> + struct drm_encoder *encoder;
> + struct amdgpu_encoder *amdgpu_encoder;
> + struct amdgpu_encoder_atom_dig *dig;
> + struct drm_connector *connector;
> + int ret = 0;
> +
> + *enabled = 0;
> + list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> + amdgpu_encoder = to_amdgpu_encoder(encoder);
> + dig = amdgpu_encoder->enc_priv;
> + if (!dig || !dig->afmt || !dig->afmt->enabled)
> + continue;
> + if (!dig->afmt->pin || dig->afmt->pin->id != port)
> +
Re: [PATCH v1 11/15] drm/mediatek: add dummy buffer for RDMA memory mode
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add dummy buffer for RDMA memory mode
>
> When display power on, the drm frame work would modeset and
> set up the display HW.
>
> In this time, the RDMA would start wroking and read the data from memory.
> But, user space not send the data to drm yet.
>
> For this case, if user space not send data to display hw(RDMA) yet,
> RDMA would read the wrong address to show garbage.
>
> Therefore, we create dummy buffer for RDMA reading memory
> when userspace not send the data yet.
>
Is this the only solution? If panel resolution is 1920x1080, the buffer
size is 8294400 bytes. How large it is. If we have another solution,
I'll not accept this one. As far as I know, DSI or DPI could output
single color even though there is no input data. If this is true, when
encoder is enabled, it output the single color. When crtc enable, config
all setting except 'start'. When receive the buffer, 'start' the
pipeline which include encoder. When encoder 'start', it disable the
single color function and output the data from input.
Regards,
CK
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 23 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 8d41f5cd485b..e28f368728cd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -20,6 +20,7 @@
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp_comp.h"
> +#include "mtk_drm_gem.h"
>
> #define DISP_REG_RDMA_INT_ENABLE 0x
> #define DISP_REG_RDMA_INT_STATUS 0x0004
> @@ -59,6 +60,9 @@
> #define MEM_MODE_INPUT_FORMAT_UYVY (0x004 << 4)
> #define MEM_MODE_INPUT_FORMAT_YUYV (0x005 << 4)
>
> +#define RDMA_DUMMY_BUFFER_SIZE(h, v) ((h) * (v) * 4)
> +#define RDMA_DUMMY_BUFFER_PITCH(h) ((h) * 4)
> +
> struct mtk_disp_rdma_data {
> unsigned int fifo_size;
> };
> @@ -74,6 +78,7 @@ struct mtk_disp_rdma {
> const struct mtk_disp_rdma_data *data;
> struct drm_device *drm_dev;
> bool rdma_memory_mode;
> + unsigned int dummy_size;
> };
>
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -126,14 +131,29 @@ static void mtk_rdma_disable_vblank(struct mtk_ddp_comp
> *comp)
>
> static void mtk_rdma_start(struct mtk_ddp_comp *comp)
> {
> + struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + bool *rdma_memory_mode = comp->comp_mode;
> +
> + if (*rdma_memory_mode == true) {
> + comp->mtk_gem = mtk_drm_gem_create(rdma->drm_dev,
> +rdma->dummy_size, false);
> + writel(comp->mtk_gem->dma_addr & 0x,
> +comp->regs + DISP_RDMA_MEM_START_ADDR);
> + }
> +
> rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON, RDMA_ENGINE_EN,
>RDMA_ENGINE_EN);
> }
>
> static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
> {
> + bool *rdma_memory_mode = comp->comp_mode;
> +
> writel(RDMA_SOFT_RESET, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
> writel(0, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
> +
> + if (*rdma_memory_mode == true)
> + mtk_drm_gem_free_object(>mtk_gem->base);
> }
>
> static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> @@ -149,8 +169,11 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>
> if (*rdma_memory_mode == true) {
> + rdma->dummy_size = RDMA_DUMMY_BUFFER_SIZE(width, height);
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
>MATRIX_INT_MTX_SEL_DEFAULT);
> + writel(RDMA_DUMMY_BUFFER_PITCH(width),
> +comp->regs + DISP_RDMA_MEM_SRC_PITCH);
> rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON,
>RDMA_MODE_MEMORY, RDMA_MODE_MEMORY);
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index a1988ce15141..6dbb83144a74 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -92,6 +92,7 @@ struct mtk_ddp_comp {
> int irq;
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> + struct mtk_drm_gem_obj *mtk_gem;
> const struct mtk_ddp_comp_funcs *funcs;
> void *comp_mode;
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 答复: [PATCH 3/4] drm/radeon: Add audio component support
On 2018年07月25日 13:28, Takashi Iwai wrote: On Wed, 25 Jul 2018 05:32:52 +0200, Qu, Jim wrote: @@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device *rdev, if (rdev->audio.funcs->enable) rdev->audio.funcs->enable(rdev, pin, enable_mask); + + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, +pin->id, -1); Jim: radeon_audio_enable() can enable audios and also disable them, so eld noitfy callback should be called when enable_mask is true. It's intentional. The notifier needs to be called at disablement time, too. The audio driver has to follow the HDMI audio disablement, and notifier receives both on and off case. The actual state is inquired via get_eld call by HD-audio followed after the notification. thanks, Takashi OK, I got your point. Thanks JimQu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
答复: [PATCH 4/4] drm/amdgpu: Add audio component support
See comments in line.
Thanks
JimQu
发件人: amd-gfx 代表 Takashi Iwai
发送时间: 2018年7月23日 22:50
收件人: alsa-de...@alsa-project.org
抄送: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
主题: [PATCH 4/4] drm/amdgpu: Add audio component support
This patch introduces the HDMI audio component binding like what i915
does to amdgpu driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at each *_audio_enable() call and giving the eld
query by copying the connector->eld contents.
This patch currently doesn't contain the component support for the new
DC codes yet.
Signed-off-by: Takashi Iwai
**
Jim: Just like Alex said, we want driver can get eld info when hotplug in new
device. amdgpu driver is a bit difference from radeon driver, it is not a
suitable place to call notify() function in *_audio_enable() , since they are
not in the hotplug process context like them in radeon driver, but the mode
setting.
IMO, the right place to call notify() function is also in the
amdgpu_connector__detect() in amdgpu_connector.c.
With None-DC driver, the detect() of connectors will to be preformed in
drm_helper_hpd_irq_event() when there is device hotplug. However,
amdgpu_connector__detect() maybe need to be modified to fit your change.
Thanks
JimQu
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c | 97 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 +
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++
9 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2c7112ddfed4..fbe7216c5c56 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -193,6 +193,7 @@ config DRM_AMDGPU
select BACKLIGHT_LCD_SUPPORT
select INTERVAL_TREE
select CHASH
+ select SND_HDA_COMPONENT if SND_HDA_CORE
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index bfd332c95b61..9c26facddb17 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -52,7 +52,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_atomfirmware.o \
amdgpu_queue_mgr.o amdgpu_vf_error.o amdgpu_sched.o amdgpu_debugfs.o \
- amdgpu_ids.o
+ amdgpu_ids.o amdgpu_audio.o
# add asic specific block
amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a59c07590cee..203d2584c989 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1957,5 +1957,9 @@ int amdgpu_dm_display_resume(struct amdgpu_device *adev );
static inline int amdgpu_dm_display_resume(struct amdgpu_device *adev) {
return 0; }
#endif
+int amdgpu_audio_component_init(struct amdgpu_device *adev);
+void amdgpu_audio_component_fini(struct amdgpu_device *adev);
+void amdgpu_audio_eld_notify(struct amdgpu_device *adev, int pin);
+
#include "amdgpu_object.h"
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
new file mode 100644
index ..39256e2f84b3
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_audio.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: MIT
+
+#include
+#include "amdgpu.h"
+
+static int amdgpu_audio_component_get_eld(struct device *kdev, int port,
+ int pipe, bool *enabled,
+ unsigned char *buf, int max_bytes)
+{
+ struct drm_device *dev = dev_get_drvdata(kdev);
+ struct drm_encoder *encoder;
+ struct amdgpu_encoder *amdgpu_encoder;
+ struct amdgpu_encoder_atom_dig *dig;
+ struct drm_connector *connector;
+ int ret = 0;
+
+ *enabled = 0;
+ list_for_each_entry(encoder, >mode_config.encoder_list, head) {
+ amdgpu_encoder = to_amdgpu_encoder(encoder);
+ dig = amdgpu_encoder->enc_priv;
+ if (!dig || !dig->afmt || !dig->afmt->enabled)
+ continue;
+ if
Re: 答复: [PATCH 3/4] drm/radeon: Add audio component support
On Wed, 25 Jul 2018 05:32:52 +0200, Qu, Jim wrote: > @@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device > *rdev, > > if (rdev->audio.funcs->enable) > rdev->audio.funcs->enable(rdev, pin, enable_mask); > + > + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) > + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, > +pin->id, -1); > > >>> > Jim: radeon_audio_enable() can enable audios and also disable them, so eld > noitfy callback should be called when enable_mask is true. It's intentional. The notifier needs to be called at disablement time, too. The audio driver has to follow the HDMI audio disablement, and notifier receives both on and off case. The actual state is inquired via get_eld call by HD-audio followed after the notification. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] backlight: pwm_bl: Fix uninitialized variable
On Tue, 24 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
> brightness-levels")
> Reported-by: Marcel Ziswiler
> Signed-off-by: Daniel Thompson
> Tested-by: Marcel Ziswiler
> ---
>
> Notes:
> v3:
> - Switch to the simplest fix and zero the uninitialized variable. git
>grep indicates that ~25% of calls to of_property_read_u32() use this
>pattern (pre-initialize optional properties with sane values and
>ignore the return code).
>
> v2:
> - Simplify SoB chain (with Marcel's permission)
> - Separate complex if statement and make other similar calls use same
>return code checking approach
> - Tidy up comment formatting and fix pre-existing grammar error
>
> drivers/video/backlight/pwm_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Once the 'Fixes:' line has been repaired:
Acked-by: Lee Jones
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 14/15] drm/mediatek: fixed the error value for add DSI1 in mutex
Hi, Stu: On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > This patch fixed the error value for add DSI1 in mutex > English is not my mother language, but should it be 'fix' rather than 'fixed'? Regards, CK > Signed-off-by: Stu Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > index 3239f22785fd..ac047fdb1a2b 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c > @@ -437,7 +437,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex, > reg = MUTEX_SOF_DSI0; > break; > case DDP_COMPONENT_DSI1: > - reg = MUTEX_SOF_DSI0; > + reg = MUTEX_SOF_DSI1; > break; > case DDP_COMPONENT_DSI2: > reg = MUTEX_SOF_DSI2; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105532] Broken map generation in Northgard game
https://bugs.freedesktop.org/show_bug.cgi?id=105532 --- Comment #10 from Timothy Arceri --- (In reply to Christian Lanig from comment #7) > (In reply to Alexander Tsoy from comment #5) > > (In reply to Christian Lanig from comment #4) > > There are native linux binaries in the linux subfolder. > > Yes. You are right. I renamed Northgard.exe and the game still starts. I > thought that Haxe would somewhere start the Windows binary after loading the > data file because shipping it to Linux users didn't make that much sense to > me. I'm sorry for the confusion. > > Still, Haxe might be useful to localize the roots of the issue. As per my reply in comment 3. The game runs in the HashLink virtual machine. Which is why I was requesting a trace grabbed via a build of the game compiled with HL/C which produces a native binary instead. -- 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 3/4] drm/radeon: Add audio component support
Hi Takashi lwai,
Sorry, I have to use outlook again, since my mail client had some problems that
did not receive these series patches.
See the commands in line.
Thanks
JimQu
发件人: amd-gfx 代表 Takashi Iwai
发送时间: 2018年7月23日 22:50
收件人: alsa-de...@alsa-project.org
抄送: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
主题: [PATCH 3/4] drm/radeon: Add audio component support
This patch introduces the HDMI audio component binding like what i915
does to radeon driver. Unlike i915, we need only the hotplug
notification and the ELD query, hence the code is relatively simple,
just adding the hook at radeon_audio_enable() and giving the eld query
by copying the connector->eld contents.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/radeon/radeon.h | 3 +
drivers/gpu/drm/radeon/radeon_audio.c | 79 +++
3 files changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2a72d2feb76d..2c7112ddfed4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,6 +170,7 @@ config DRM_RADEON
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
select INTERVAL_TREE
+ select SND_HDA_COMPONENT if SND_HDA_CORE
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 4a2eb409aacc..fad58df0bf19 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -75,6 +75,7 @@
#include
#include
+#include
#include "radeon_family.h"
#include "radeon_mode.h"
@@ -1760,6 +1761,8 @@ struct r600_audio {
struct radeon_audio_funcs *hdmi_funcs;
struct radeon_audio_funcs *dp_funcs;
struct radeon_audio_basic_funcs *funcs;
+ struct drm_audio_component *component;
+ bool component_registered;
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
b/drivers/gpu/drm/radeon/radeon_audio.c
index 770e31f5fd1b..58e149b7a7a4 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include
#include "radeon.h"
@@ -248,6 +249,7 @@ static void radeon_audio_enable(struct radeon_device *rdev,
struct drm_encoder *encoder;
struct radeon_encoder *radeon_encoder;
struct radeon_encoder_atom_dig *dig;
+ struct drm_audio_component *acomp = rdev->audio.component;
int pin_count = 0;
if (!pin)
@@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device *rdev,
if (rdev->audio.funcs->enable)
rdev->audio.funcs->enable(rdev, pin, enable_mask);
+
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
+pin->id, -1);
>>>
Jim: radeon_audio_enable() can enable audios and also disable them, so eld
noitfy callback should be called when enable_mask is true.
JimQu
Thanks
>>>
}
static void radeon_audio_interface_init(struct radeon_device *rdev)
@@ -292,6 +298,71 @@ static void radeon_audio_interface_init(struct
radeon_device *rdev)
}
}
+static int radeon_audio_component_get_eld(struct device *kdev, int port,
+ int pipe, bool *enabled,
+ unsigned char *buf, int max_bytes)
+{
+ struct drm_device *dev = dev_get_drvdata(kdev);
+ struct drm_encoder *encoder;
+ struct radeon_encoder *radeon_encoder;
+ struct radeon_encoder_atom_dig *dig;
+ struct drm_connector *connector;
+ int ret = 0;
+
+ *enabled = 0;
+ list_for_each_entry(encoder, >mode_config.encoder_list, head) {
+ if (!radeon_encoder_is_digital(encoder))
+ continue;
+ radeon_encoder = to_radeon_encoder(encoder);
+ dig = radeon_encoder->enc_priv;
+ if (!dig->pin || dig->pin->id != port)
+ continue;
+ connector = radeon_get_connector_for_encoder(encoder);
+ *enabled = !!connector;
+ if (connector) {
+ ret = drm_eld_size(connector->eld);
+ memcpy(buf, connector->eld, min(max_bytes, ret));
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static const struct drm_audio_component_ops radeon_audio_component_ops = {
+ .get_eld = radeon_audio_component_get_eld,
+};
+
+static int radeon_audio_component_bind(struct device *kdev,
+
Re: [PATCH v1 12/15] drm/mediatek: add layer number condition for RDMA to control plane
Hi, Stu: On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > This patch add layer number condition for RDMA to control plane > > When plane init in crtc create, > it use the number of OVL layer to init plane. > That's OVL can read 4 memory address. > > For mt2712 third ddp, it use RDMA to read memory. > RDMA can read 1 memory address, so it just init one plane. > > For compatibility, this patch use two define OVL_LAYER_NR and > RDMA_LAYER_NR to distingush two difference HW engine. > > Signed-off-by: Stu Hsieh > --- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 ++ > 2 files changed, 19 insertions(+), 8 deletions(-) > [...] > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h > index 9d9410c67ae9..b44fefadf14a 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h > @@ -18,7 +18,9 @@ > #include "mtk_drm_ddp_comp.h" > #include "mtk_drm_plane.h" > > +#define MAX_LAYER_NR 4 > #define OVL_LAYER_NR 4 > +#define RDMA_LAYER_NR1 > #define MTK_LUT_SIZE 512 > #define MTK_MAX_BPC 10 > #define MTK_MIN_BPC 3 If the layer number is not fixed in '4', I would like to get this value from component because in some SoC, OVL may have 6 layer. So add an interface to get the max layer number and OVL, RDMA driver would return the number for this SoC. Regards, CK ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 06/15] drm/mediatek: add memory mode for RDMA
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add memory mode for RDMA
>
> If use RDMA to read data from memory, it should set memory mode to RDMA
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
[...]
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -111,7 +116,8 @@ static void mtk_rdma_start(struct mtk_ddp_comp *comp)
>
> static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
> {
> - rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON, RDMA_ENGINE_EN, 0);
> + writel(RDMA_SOFT_RESET, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
> + writel(0, comp->regs + DISP_REG_RDMA_GLOBAL_CON);
Without reset, what happen to dram mode? Why direct link mode need not
this reset?
> }
>
> static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> @@ -121,10 +127,18 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> unsigned int threshold;
> unsigned int reg;
> struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + bool *rdma_memory_mode = comp->comp_mode;
>
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>
> + if (*rdma_memory_mode == true) {
> + rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xff,
> + MATRIX_INT_MTX_SEL_DEFAULT);
> + rdma_update_bits(comp, DISP_REG_RDMA_GLOBAL_CON,
> + RDMA_MODE_MEMORY, RDMA_MODE_MEMORY);
> + }
> +
I would like this to be a kind of 'layer' config. In some SoC, one layer
of OVL could switch to direct link input or dram input. So I think it's
better to move this setting into some layer interface.
Regards,
CK
> /*
>* Enable FIFO underflow since DSI and DPI can't be blocked.
>* Keep the FIFO pseudo size reset default of 8 KiB. Set the
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 00/15] Add RDMA memory mode support for mediatek SOC MT2712
Hi, Stu: It looks like the series is a bug fix of [1]. In [1], you create third crtc but it does not work unless apply this series. So for all the patches in this series, you should refer to [2] to add 'Fixes:' and 'Cc:' in commit message. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e6ab087a224fd7bcf712db698fbade673cc9addd [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=83ba62bc700bab710b22be3a1bf6cf973f754273 Regards, CK On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote: > This patch series add RDMA memory mode support for mediatek SOC MT2712. > MT2712 has three display data path, including three HW engine, > two OVL and one RDMA. > > The RDMA used in third ddp and it need to be set memory mode, > then RDMA could read data from memory and output to panel. > > Stu Hsieh (15): > drm/mediatek: add connection from RDMA0 to DPI1 > drm/mediatek: add connection from RDMA0 to DSI1 > drm/mediatek: add connection from RDMA1 to DSI0 > drm/mediatek: add connection from RDMA2 to DSI0 > drm/mediatek: add RDMA memory mode for crtc created > drm/mediatek: add memory mode for RDMA > drm/mediatek: add layer config to set RDMA for plane setting > drm/mediatek: add RGB color format support for RDMA > drm/mediatek: add YUYV/UYVY color format support for RDMA > drm/mediatek: add drm_device in RDMA for mamory mode to reaquest > buffer > drm/mediatek: add dummy buffer for RDMA memory mode > drm/mediatek: add layer number condition for RDMA to control plane > drm/mediatek: Update some variable name from ovl to comp > drm/mediatek: fixed the error value for add DSI1 in mutex > drm/mediatek: fixed connection from RDMA2 to DSI1 > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 122 > +++- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 59 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 20 - > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 + > 5 files changed, 181 insertions(+), 26 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] backlight: pwm_bl: Fix uninitialized variable
Hi,
On Tue, Jul 24, 2018 at 12:12 AM, Daniel Thompson
wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation between
> brightness-levels")
I think it may be incorrect to word-wrap the Fixes line. A quick grep
through the source code looks like others agree.
> Reported-by: Marcel Ziswiler
> Signed-off-by: Daniel Thompson
> Tested-by: Marcel Ziswiler
> ---
>
> Notes:
> v3:
> - Switch to the simplest fix and zero the uninitialized variable. git
>grep indicates that ~25% of calls to of_property_read_u32() use this
>pattern (pre-initialize optional properties with sane values and
>ignore the return code).
>
> v2:
> - Simplify SoB chain (with Marcel's permission)
> - Separate complex if statement and make other similar calls use same
>return code checking approach
> - Tidy up comment formatting and fix pre-existing grammar error
>
> drivers/video/backlight/pwm_bl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Other than the nit on the commit message, this simple fix seems sane.
Reviewed-by: Douglas Anderson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 18/19] dt-bindings: msm/disp: Add bindings for Snapdragon 845 DPU
On Fri, Jul 20, 2018 at 04:43:09PM -0400, Sean Paul wrote: > From: Jeykumar Sankaran > > Adds bindings for Snapdragon 845 display processing unit > > Changes in v2: > - Use SoC specific compatibles for mdss and dpu (Rob Herring) > - Use assigned-clocks to set initial clock frequency (Rob Herring) > > Changes in v3 (all suggested by Rob Herring): > - Rename mdss_phys to mdss > - Correct description for clocks/assigned-clocks > - Rename mdp_phys to mdp > - Rename vbif_phys to vbif > - Remove redundant interrupt-parent from mdss_mdp > - Fully specify 'ranges' and use relative reg address in mdss_mdp > > Cc: Rob Herring > Signed-off-by: Jeykumar Sankaran > Signed-off-by: Rajesh Yadav > Signed-off-by: Sean Paul > --- > .../devicetree/bindings/display/msm/dpu.txt | 131 ++ > 1 file changed, 131 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: Fix a use-after-free race accessing the scheduler's fences.
Once we push the job, the scheduler could run it and free it. So, if
we want to reference their fences, we need to grab them before then.
I haven't seen this happen in many days of conformance test runtime,
but let's still close the race.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
---
drivers/gpu/drm/v3d/v3d_drv.h | 5 +
drivers/gpu/drm/v3d/v3d_gem.c | 8 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 5042573e97f4..83c55ab6e1c0 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -204,6 +204,11 @@ struct v3d_exec_info {
*/
struct dma_fence *bin_done_fence;
+ /* Fence for when the scheduler considers the render to be
+* done, for when the BOs reservations should be complete.
+*/
+ struct dma_fence *render_done_fence;
+
struct kref refcount;
/* This is the array of BOs that were looked up at the start of exec. */
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index e1fcbb4cd0ae..c98fbfbdb68e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -209,7 +209,7 @@ v3d_flush_caches(struct v3d_dev *v3d)
static void
v3d_attach_object_fences(struct v3d_exec_info *exec)
{
- struct dma_fence *out_fence = >render.base.s_fence->finished;
+ struct dma_fence *out_fence = exec->render_done_fence;
struct v3d_bo *bo;
int i;
@@ -409,6 +409,7 @@ v3d_exec_cleanup(struct kref *ref)
dma_fence_put(exec->render.done_fence);
dma_fence_put(exec->bin_done_fence);
+ dma_fence_put(exec->render_done_fence);
for (i = 0; i < exec->bo_count; i++)
drm_gem_object_put_unlocked(>bo[i]->base);
@@ -574,6 +575,9 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail_unreserve;
+ exec->render_done_fence =
+ dma_fence_get(>render.base.s_fence->finished);
+
kref_get(>refcount); /* put by scheduler job completion */
drm_sched_entity_push_job(>render.base,
_priv->sched_entity[V3D_RENDER]);
@@ -587,7 +591,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
sync_out = drm_syncobj_find(file_priv, args->out_sync);
if (sync_out) {
drm_syncobj_replace_fence(sync_out,
- >render.base.s_fence->finished);
+ exec->render_done_fence);
drm_syncobj_put(sync_out);
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: Add a little debugfs entry for measuring the core clock.
This adds just enough performance counter support to measure the
clock. We don't have linux kernel drivers for the clock driving the
HW, and this was useful for determining that the V3D HW is running on
a slow clock, not that the driver was slow.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 35 +++
drivers/gpu/drm/v3d/v3d_regs.h| 30 ++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index 4db62c545748..d48008adb085 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -176,9 +176,44 @@ static int v3d_debugfs_bo_stats(struct seq_file *m, void
*unused)
return 0;
}
+static int v3d_measure_clock(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = (struct drm_info_node *)m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct v3d_dev *v3d = to_v3d_dev(dev);
+ uint32_t cycles;
+ int core = 0;
+ int measure_ms = 1000;
+
+ if (v3d->ver >= 40) {
+ V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
+ V3D_SET_FIELD(V3D_PCTR_CYCLE_COUNT,
+V3D_PCTR_S0));
+ V3D_CORE_WRITE(core, V3D_V4_PCTR_0_CLR, 1);
+ V3D_CORE_WRITE(core, V3D_V4_PCTR_0_EN, 1);
+ } else {
+ V3D_CORE_WRITE(core, V3D_V3_PCTR_0_PCTRS0,
+ V3D_PCTR_CYCLE_COUNT);
+ V3D_CORE_WRITE(core, V3D_V3_PCTR_0_CLR, 1);
+ V3D_CORE_WRITE(core, V3D_V3_PCTR_0_EN,
+ V3D_V3_PCTR_0_EN_ENABLE |
+ 1);
+ }
+ msleep(measure_ms);
+ cycles = V3D_CORE_READ(core, V3D_PCTR_0_PCTR0);
+
+ seq_printf(m, "cycles: %d (%d.%d Mhz)\n",
+ cycles,
+ cycles / (measure_ms * 1000),
+ (cycles / (measure_ms * 100)) % 10);
+
+ return 0;
+}
+
static const struct drm_info_list v3d_debugfs_list[] = {
{"v3d_ident", v3d_v3d_debugfs_ident, 0},
{"v3d_regs", v3d_v3d_debugfs_regs, 0},
+ {"measure_clock", v3d_measure_clock, 0},
{"bo_stats", v3d_debugfs_bo_stats, 0},
};
diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
index 854046565989..c3a5e4e44f73 100644
--- a/drivers/gpu/drm/v3d/v3d_regs.h
+++ b/drivers/gpu/drm/v3d/v3d_regs.h
@@ -267,6 +267,36 @@
# define V3D_PTB_BXCF_RWORDERDISA BIT(1)
# define V3D_PTB_BXCF_CLIPDISA BIT(0)
+#define V3D_V3_PCTR_0_EN 0x00674
+#define V3D_V3_PCTR_0_EN_ENABLEBIT(31)
+#define V3D_V4_PCTR_0_EN 0x00650
+/* When a bit is set, resets the counter to 0. */
+#define V3D_V3_PCTR_0_CLR 0x00670
+#define V3D_V4_PCTR_0_CLR 0x00654
+#define V3D_PCTR_0_OVERFLOW0x00658
+
+#define V3D_V3_PCTR_0_PCTRS0 0x00684
+#define V3D_V3_PCTR_0_PCTRS15 0x00660
+#define V3D_V3_PCTR_0_PCTRSX(x)(V3D_V3_PCTR_0_PCTRS0 +
\
+ 4 * (x))
+/* Each src reg muxes four counters each. */
+#define V3D_V4_PCTR_0_SRC_0_3 0x00660
+#define V3D_V4_PCTR_0_SRC_28_310x0067c
+# define V3D_PCTR_S0_MASK V3D_MASK(6, 0)
+# define V3D_PCTR_S0_SHIFT 0
+# define V3D_PCTR_S1_MASK V3D_MASK(14, 8)
+# define V3D_PCTR_S1_SHIFT 8
+# define V3D_PCTR_S2_MASK V3D_MASK(22, 16)
+# define V3D_PCTR_S2_SHIFT 16
+# define V3D_PCTR_S3_MASK V3D_MASK(30, 24)
+# define V3D_PCTR_S3_SHIFT 24
+# define V3D_PCTR_CYCLE_COUNT 32
+
+/* Output values of the counters. */
+#define V3D_PCTR_0_PCTR0 0x00680
+#define V3D_PCTR_0_PCTR31 0x006fc
+#define V3D_PCTR_0_PCTRX(x)(V3D_PCTR_0_PCTR0 + \
+ 4 * (x))
#define V3D_GMP_STATUS 0x00800
# define V3D_GMP_STATUS_GMPRST BIT(31)
# define V3D_GMP_STATUS_WR_COUNT_MASK V3D_MASK(30, 24)
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106658] 2500u HP Envy x360 Hangs randomly
https://bugs.freedesktop.org/show_bug.cgi?id=106658 --- Comment #5 from Tim Carr --- Have you tried booting with the 'idle=nomwait' kernel option? This worked for the submitter of similar bug #106670, and so far seems to have worked for me as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] msm: add msm drm uapi header
Tanmay Shah writes: > On 2018-07-24 12:19, Eric Anholt wrote: >> Tanmay Shah writes: >> >>> file derived from msm-next kernel uapi header. >> >> Unless there's an exception from Dave, I believe uapi headers in libdrm >> and Mesa should be direct copies from "make headers_install" on the >> drm-next branch. How does this compare to that? > > The header file is identical as in drm-next kernel. Great, let's say "drm-next" instead to make that clear. Also, looks like freedreno/msm/msm_drm.h should probably get removed in favor of this? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] msm: add msm drm uapi header
On 2018-07-24 12:19, Eric Anholt wrote: Tanmay Shah writes: file derived from msm-next kernel uapi header. Unless there's an exception from Dave, I believe uapi headers in libdrm and Mesa should be direct copies from "make headers_install" on the drm-next branch. How does this compare to that? The header file is identical as in drm-next kernel. -- Tanmay Shah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
> /* failed to reap part of the address space. Try again later */
> if (!__oom_reap_task_mm(mm)) {
> up_read(>mmap_sem);
> - return true;
> + return false;
> }
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
>
>
> On top of that the proposed cleanup looks as follows:
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 88657e018714..4e185a282b3d 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
> return ret;
> }
>
> +/*
> + * Reaps the address space of the give task.
> + *
> + * Returns true on success and false if none or part of the address space
> + * has been reclaimed and the caller should retry later.
> + */
> static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
> {
> + bool ret = true;
> +
> if (!down_read_trylock(>mmap_sem)) {
> trace_skip_task_reaping(tsk->pid);
> return false;
> @@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
>* down_write();up_write() cycle in exit_mmap().
>*/
> if (test_bit(MMF_OOM_SKIP, >flags)) {
> - up_read(>mmap_sem);
> trace_skip_task_reaping(tsk->pid);
> - return true;
> + goto out_unlock;
> }
>
> trace_start_task_reaping(tsk->pid);
>
> /* failed to reap part of the address space. Try again later */
> - if (!__oom_reap_task_mm(mm)) {
> - up_read(>mmap_sem);
> - return false;
> - }
> + ret = __oom_reap_task_mm(mm);
> + if (!ret)
> + goto out_finish;
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
> task_pid_nr(tsk), tsk->comm,
> K(get_mm_counter(mm, MM_ANONPAGES)),
> K(get_mm_counter(mm, MM_FILEPAGES)),
> K(get_mm_counter(mm, MM_SHMEMPAGES)));
> +out_finish:
> + trace_finish_task_reaping(tsk->pid);
> +out_unlock:
> up_read(>mmap_sem);
>
> - trace_finish_task_reaping(tsk->pid);
> - return true;
> + return ret;
> }
>
> #define MAX_OOM_REAP_RETRIES 10
I think we still want to trace when reaping was skipped to know that the
oom reaper will retry again later.
mm/oom_kill.c: clean up oom_reap_task_mm() fix
indicate reaping has been partially skipped so we can expect future skips
or another start before finish.
Signed-off-by: David Rientjes
---
mm/oom_kill.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -569,10 +569,12 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
trace_start_task_reaping(tsk->pid);
- /* failed to reap part of the address space. Try again later */
ret = __oom_reap_task_mm(mm);
- if (!ret)
+ if (!ret) {
+ /* Failed to reap part of the address space. Try again later */
+ trace_skip_task_reaping(tsk->pid);
goto out_finish;
+ }
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/pm: Fix potential Spectre v1
On Mon, Jul 23, 2018 at 12:32 PM, Gustavo A. R. Silva
wrote:
> idx can be indirectly controlled by user-space, hence leading to a
> potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
> warn: potential spectre issue 'data.states'
>
> Fix this by sanitizing idx before using it to index data.states
Is this actually necessary? We already check that idx is valid a few
lines before:
if (ret || idx >= ARRAY_SIZE(data.states)) {
count = -EINVAL;
goto fail;
}
Alex
>
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
>
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 15a1192..a446c7c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -31,7 +31,7 @@
> #include
> #include
> #include
> -
> +#include
>
> static int amdgpu_debugfs_pm_init(struct amdgpu_device *adev);
>
> @@ -403,6 +403,7 @@ static ssize_t amdgpu_set_pp_force_state(struct device
> *dev,
> count = -EINVAL;
> goto fail;
> }
> + idx = array_index_nospec(idx, ARRAY_SIZE(data.states));
>
> amdgpu_dpm_get_pp_num_states(adev, );
> state = data.states[idx];
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: amdgpu: Replace mdelay with msleep in cik_pcie_gen3_enable()
On Mon, Jul 23, 2018 at 10:29 AM, Jia-Ju Bai wrote: > cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is > never called in atomic context. > cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not > necessary. > mdelay() can be replaced with msleep(). > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai Applied. thanks! Alex > --- > drivers/gpu/drm/amd/amdgpu/cik.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c > b/drivers/gpu/drm/amd/amdgpu/cik.c > index 0df22030e713..5b7fab2c2008 100644 > --- a/drivers/gpu/drm/amd/amdgpu/cik.c > +++ b/drivers/gpu/drm/amd/amdgpu/cik.c > @@ -1476,7 +1476,7 @@ static void cik_pcie_gen3_enable(struct amdgpu_device > *adev) > tmp |= PCIE_LC_CNTL4__LC_REDO_EQ_MASK; > WREG32_PCIE(ixPCIE_LC_CNTL4, tmp); > > - mdelay(100); > + msleep(100); > > /* linkctl */ > pci_read_config_word(root, bridge_pos + > PCI_EXP_LNKCTL, ); > -- > 2.17.0 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set
https://bugs.freedesktop.org/show_bug.cgi?id=106228 --- Comment #5 from Daniel Drake --- Created attachment 140809 --> https://bugs.freedesktop.org/attachment.cgi?id=140809=edit additional patch this patch may also be required -- 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] mm, oom: distinguish blockable mode for mmu notifiers
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to something which happened in the past, is in fact
> > referring to something which might happen in the future.
> >
> > - fails to call trace_finish_task_reaping() in one case
> >
> > - code duplication.
> >
> > - Increases mmap_sem hold time a little by moving
> > trace_finish_task_reaping() inside the locked region. So sue me ;)
> >
> > - Sharing the finish: path means that the trace event won't
> > distinguish between the two sources of finishing.
> >
> > Please take a look?
>
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
> struct mm_struct *mm)
> /* failed to reap part of the address space. Try again later */
> if (!__oom_reap_task_mm(mm)) {
> up_read(>mmap_sem);
> - return true;
> + return false;
> }
>
> pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
> file-rss:%lukB, shmem-rss:%lukB\n",
OK, thanks, I added that.
>
> On top of that the proposed cleanup looks as follows:
>
Looks good to me. Seems a bit strange that we omit the pr_info()
output if the mm was partially reaped - people would still want to know
this? Not very important though.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260
https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #13 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (In reply to Harry Wentland from comment #11) > Should be fixed by https://patchwork.freedesktop.org/patch/230831/ which is > merged into amd-staging-drm-next Just tested with 4.18-rc6 that has this patch applied. Still getting the use-after-free. Looking at this patch, this seems to fix another bug: BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu] whereas this one is: BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x212/0x270 I'll try the patch from Daniel Vetter now. -- 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
[PATCH for v4.19] drm_dp_cec.c: fix formatting typo: %pdH -> %phD
This caused a kernel oops since %pdH interpreted the pointer as a struct file. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/drm_dp_cec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c index 87b67cc1ea58..a6cac47f6248 100644 --- a/drivers/gpu/drm/drm_dp_cec.c +++ b/drivers/gpu/drm/drm_dp_cec.c @@ -157,7 +157,7 @@ static void drm_dp_cec_adap_status(struct cec_adapter *adap, if (drm_dp_read_desc(aux, , true)) return; - seq_printf(file, "OUI: %*pdH\n", + seq_printf(file, "OUI: %*phD\n", (int)sizeof(id->oui), id->oui); seq_printf(file, "ID: %*pE\n", (int)strnlen(id->device_id, sizeof(id->device_id)), -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] msm: add msm drm uapi header
Tanmay Shah writes: > file derived from msm-next kernel uapi header. Unless there's an exception from Dave, I believe uapi headers in libdrm and Mesa should be direct copies from "make headers_install" on the drm-next branch. How does this compare to that? 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/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats
Boris Brezillon writes:
> This is needed to ensure ->is_unity is correct when the plane was
> previously configured to output a multi-planar format with scaling
> enabled, and is then being reconfigured to output a uniplanar format.
>
> Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
> Cc:
> Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel
https://bugs.freedesktop.org/show_bug.cgi?id=107367 Bug ID: 107367 Summary: [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: gr.mue...@gmail.com QA Contact: dri-devel@lists.freedesktop.org This reproducible all the time with Dota2 starting a benchmark with 1920x1080 and Vulkan using Phoronix test suite. Starting the benchmark makes the machine freeze and you just can hit the reset button. I also experienced the freeze with Shadow of Mordor but not all the time. fc9a53946d9c107a36b79de3dd1a4eac43f13f3f is the first bad commit commit fc9a53946d9c107a36b79de3dd1a4eac43f13f3f Author: Junwei Zhang Date: Mon Jul 16 10:53:43 2018 +0800 drm/scheduler: add NULL pointer check for run queue (v2) To check rq pointer before adding entity into it. That avoids NULL pointer access in some case. v2: move the check to caller Suggested-by: Christian König Signed-off-by: Junwei Zhang Reviewed-by: Christian König :04 04 aa8b4eb640e3995a1f77907edd6ec8fc6fccd1b3 4a061e532ddb8a1293e781a4ccd5ece2efe35d8a M drivers Reverting the commit let the freeze go away. -- 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 libdrm] msm: add msm drm uapi header
file derived from msm-next kernel uapi header.
Signed-off-by: Tanmay Shah
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308 ++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
diff --git a/Makefile.sources b/Makefile.sources
index 1f8372b..55290fe 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -25,6 +25,7 @@ LIBDRM_INCLUDE_H_FILES := \
include/drm/i915_drm.h \
include/drm/mach64_drm.h \
include/drm/mga_drm.h \
+ include/drm/msm_drm.h \
include/drm/nouveau_drm.h \
include/drm/qxl_drm.h \
include/drm/r128_drm.h \
diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
new file mode 100644
index 000..c06d0a5
--- /dev/null
+++ b/include/drm/msm_drm.h
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#ifndef __MSM_DRM_H__
+#define __MSM_DRM_H__
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+/* Please note that modifications to all structs defined here are
+ * subject to backwards-compatibility constraints:
+ * 1) Do not use pointers, use __u64 instead for 32 bit / 64 bit
+ * user/kernel compatibility
+ * 2) Keep fields aligned to their size
+ * 3) Because of how drm_ioctl() works, we can add new fields at
+ * the end of an ioctl if some care is taken: drm_ioctl() will
+ * zero out the new fields at the tail of the ioctl, so a zero
+ * value should have a backwards compatible meaning. And for
+ * output params, userspace won't see the newly added output
+ * fields.. so that has to be somehow ok.
+ */
+
+#define MSM_PIPE_NONE0x00
+#define MSM_PIPE_2D0 0x01
+#define MSM_PIPE_2D1 0x02
+#define MSM_PIPE_3D0 0x10
+
+/* The pipe-id just uses the lower bits, so can be OR'd with flags in
+ * the upper 16 bits (which could be extended further, if needed, maybe
+ * we extend/overload the pipe-id some day to deal with multiple rings,
+ * but even then I don't think we need the full lower 16 bits).
+ */
+#define MSM_PIPE_ID_MASK 0x
+#define MSM_PIPE_ID(x) ((x) & MSM_PIPE_ID_MASK)
+#define MSM_PIPE_FLAGS(x)((x) & ~MSM_PIPE_ID_MASK)
+
+/* timeouts are specified in clock-monotonic absolute times (to simplify
+ * restarting interrupted ioctls). The following struct is logically the
+ * same as 'struct timespec' but 32/64b ABI safe.
+ */
+struct drm_msm_timespec {
+ __s64 tv_sec; /* seconds */
+ __s64 tv_nsec; /* nanoseconds */
+};
+
+#define MSM_PARAM_GPU_ID 0x01
+#define MSM_PARAM_GMEM_SIZE 0x02
+#define MSM_PARAM_CHIP_ID0x03
+#define MSM_PARAM_MAX_FREQ 0x04
+#define MSM_PARAM_TIMESTAMP 0x05
+#define MSM_PARAM_GMEM_BASE 0x06
+#define MSM_PARAM_NR_RINGS 0x07
+
+struct drm_msm_param {
+ __u32 pipe; /* in, MSM_PIPE_x */
+ __u32 param; /* in, MSM_PARAM_x */
+ __u64 value; /* out (get_param) or in (set_param) */
+};
+
+/*
+ * GEM buffers:
+ */
+
+#define MSM_BO_SCANOUT 0x0001 /* scanout capable */
+#define MSM_BO_GPU_READONLY 0x0002
+#define MSM_BO_CACHE_MASK0x000f
+/* cache modes */
+#define MSM_BO_CACHED0x0001
+#define MSM_BO_WC0x0002
+#define MSM_BO_UNCACHED 0x0004
+
+#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
+ MSM_BO_GPU_READONLY | \
+ MSM_BO_CACHED | \
+ MSM_BO_WC | \
+ MSM_BO_UNCACHED)
+
+struct drm_msm_gem_new {
+ __u64 size; /* in */
+ __u32 flags; /* in, mask of MSM_BO_x */
+ __u32 handle; /* out */
+};
+
+#define MSM_INFO_IOVA 0x01
+
+#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
+
+struct
Re: [PATCH] msm: add msm drm uapi header
On 2018-07-23 15:14, Tanmay Shah wrote:
file derived from msm-next kernel uapi header.
Change-Id: Idcaa1ad6fc13e0c1d2d0a2e619121d2c5450f7da
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308
++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
diff --git a/Makefile.sources b/Makefile.sources
index 1f8372b..55290fe 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -25,6 +25,7 @@ LIBDRM_INCLUDE_H_FILES := \
include/drm/i915_drm.h \
include/drm/mach64_drm.h \
include/drm/mga_drm.h \
+ include/drm/msm_drm.h \
include/drm/nouveau_drm.h \
include/drm/qxl_drm.h \
include/drm/r128_drm.h \
diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
new file mode 100644
index 000..c06d0a5
--- /dev/null
+++ b/include/drm/msm_drm.h
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a
+ * copy of this software and associated documentation files (the
"Software"),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom
the
+ * Software is furnished to do so, subject to the following
conditions:
+ *
+ * The above copyright notice and this permission notice (including
the next
+ * paragraph) shall be included in all copies or substantial portions
of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef __MSM_DRM_H__
+#define __MSM_DRM_H__
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+/* Please note that modifications to all structs defined here are
+ * subject to backwards-compatibility constraints:
+ * 1) Do not use pointers, use __u64 instead for 32 bit / 64 bit
+ * user/kernel compatibility
+ * 2) Keep fields aligned to their size
+ * 3) Because of how drm_ioctl() works, we can add new fields at
+ * the end of an ioctl if some care is taken: drm_ioctl() will
+ * zero out the new fields at the tail of the ioctl, so a zero
+ * value should have a backwards compatible meaning. And for
+ * output params, userspace won't see the newly added output
+ * fields.. so that has to be somehow ok.
+ */
+
+#define MSM_PIPE_NONE0x00
+#define MSM_PIPE_2D0 0x01
+#define MSM_PIPE_2D1 0x02
+#define MSM_PIPE_3D0 0x10
+
+/* The pipe-id just uses the lower bits, so can be OR'd with flags in
+ * the upper 16 bits (which could be extended further, if needed,
maybe
+ * we extend/overload the pipe-id some day to deal with multiple
rings,
+ * but even then I don't think we need the full lower 16 bits).
+ */
+#define MSM_PIPE_ID_MASK 0x
+#define MSM_PIPE_ID(x) ((x) & MSM_PIPE_ID_MASK)
+#define MSM_PIPE_FLAGS(x)((x) & ~MSM_PIPE_ID_MASK)
+
+/* timeouts are specified in clock-monotonic absolute times (to
simplify
+ * restarting interrupted ioctls). The following struct is logically
the
+ * same as 'struct timespec' but 32/64b ABI safe.
+ */
+struct drm_msm_timespec {
+ __s64 tv_sec; /* seconds */
+ __s64 tv_nsec; /* nanoseconds */
+};
+
+#define MSM_PARAM_GPU_ID 0x01
+#define MSM_PARAM_GMEM_SIZE 0x02
+#define MSM_PARAM_CHIP_ID0x03
+#define MSM_PARAM_MAX_FREQ 0x04
+#define MSM_PARAM_TIMESTAMP 0x05
+#define MSM_PARAM_GMEM_BASE 0x06
+#define MSM_PARAM_NR_RINGS 0x07
+
+struct drm_msm_param {
+ __u32 pipe; /* in, MSM_PIPE_x */
+ __u32 param; /* in, MSM_PARAM_x */
+ __u64 value; /* out (get_param) or in (set_param) */
+};
+
+/*
+ * GEM buffers:
+ */
+
+#define MSM_BO_SCANOUT 0x0001 /* scanout capable */
+#define MSM_BO_GPU_READONLY 0x0002
+#define MSM_BO_CACHE_MASK0x000f
+/* cache modes */
+#define MSM_BO_CACHED0x0001
+#define MSM_BO_WC0x0002
+#define MSM_BO_UNCACHED 0x0004
+
+#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
+ MSM_BO_GPU_READONLY | \
+ MSM_BO_CACHED | \
+ MSM_BO_WC | \
+ MSM_BO_UNCACHED)
+
+struct drm_msm_gem_new {
+ __u64 size; /* in */
+ __u32 flags; /* in, mask of MSM_BO_x */
+ __u32 handle; /* out */
+};
+
+#define
Re: [PATCH 03/13] drm: Add drm_puts() to complement drm_printf()
Hi Jordan,
I might be a bit late for the party, so consider the following jfyi.
On 24 July 2018 at 17:33, Jordan Crouse wrote:
> +void drm_puts(struct drm_printer *p, const char *str)
One could easily use the compiler to detect if drm_printf or drm_puts
should be used. See the trace_printk define in include/linux/kernel.h.
> +{
> + if (p->puts)
> + p->puts(p, str);
> + else
> + drm_printf(p, "%s", str);
From a quick look from the existing three printers (seq_file, info and
debug) only the first one is updated with this series.
I would imagine that updating the other two and dropping the
drm_printf() fallback is a good move.
Otherwise one could easily assume that they have a fast path when they do not.
HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200633] [Regression] VGA not being detected with R9 380 using AMDGPU after 4.17 kernel update.
https://bugzilla.kernel.org/show_bug.cgi?id=200633 --- Comment #2 from sybo...@gmail.com --- dmesg: https://ghostbin.com/paste/7pyty Xorg: https://ghostbin.com/paste/38zyy amdgpu.dc=0 does indeed make the issue go away, so I'm guessing DC was turned on by default for Tonga in this 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
Re: [PATCH v2] drm/msm/display: negative x/y in cursor move
Hi,
On Tuesday 17 July 2018 04:33 AM, Carsten Behling wrote:
modesetting X11 driver may provide negative x/y cordinates in
mdp5_crtc_cursor_move call when rotation is enabled.
Cursor buffer can overlap down to its negative width/height.
ROI has to be recalculated for negative x/y indicating using the
lower/right corner of the cursor buffer and hotspot must be set
in MDP5_LM_CURSOR_XY_SRC_Y MDP5_LM_CURSOR_XY_SRC_X.
Thanks for the patch. Could you tell how to reproduce this issue
on a db410c?
I was playing with xrandr's --rotate and --reflect options to get
a rotated output, but wasn't able to generate negative x/y
co-ordinates. I'm using linaro's debian userspace, running lxqt.
Thanks,
Archit
Signed-off-by: Carsten Behling
---
Changes in v2:
- fixed format specifier in debug message
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 51 ++-
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 10271359789e..a7f4a6688fec 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -65,7 +65,7 @@ struct mdp5_crtc {
struct drm_gem_object *scanout_bo;
uint64_t iova;
uint32_t width, height;
- uint32_t x, y;
+ int x, y;
} cursor;
};
#define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
@@ -760,20 +760,31 @@ static void get_roi(struct drm_crtc *crtc, uint32_t
*roi_w, uint32_t *roi_h)
* Cursor Region Of Interest (ROI) is a plane read from cursor
* buffer to render. The ROI region is determined by the visibility of
* the cursor point. In the default Cursor image the cursor point will
-* be at the top left of the cursor image, unless it is specified
-* otherwise using hotspot feature.
+* be at the top left of the cursor image.
*
+* Without rotation:
* If the cursor point reaches the right (xres - x < cursor.width) or
* bottom (yres - y < cursor.height) boundary of the screen, then ROI
* width and ROI height need to be evaluated to crop the cursor image
* accordingly.
* (xres-x) will be new cursor width when x > (xres - cursor.width)
* (yres-y) will be new cursor height when y > (yres - cursor.height)
+*
+* With rotation:
+* We get negative x and/or y coordinates.
+* (cursor.width - abs(x)) will be new cursor width when x < 0
+* (cursor.height - abs(y)) will be new cursor width when y < 0
*/
- *roi_w = min(mdp5_crtc->cursor.width, xres -
+ if (mdp5_crtc->cursor.x >= 0)
+ *roi_w = min(mdp5_crtc->cursor.width, xres -
mdp5_crtc->cursor.x);
- *roi_h = min(mdp5_crtc->cursor.height, yres -
+ else
+ *roi_w = mdp5_crtc->cursor.width - abs(mdp5_crtc->cursor.x);
+ if (mdp5_crtc->cursor.y >= 0)
+ *roi_h = min(mdp5_crtc->cursor.height, yres -
mdp5_crtc->cursor.y);
+ else
+ *roi_h = mdp5_crtc->cursor.height - abs(mdp5_crtc->cursor.y);
}
static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
@@ -783,7 +794,7 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
struct mdp5_kms *mdp5_kms = get_kms(crtc);
const enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
uint32_t blendcfg, stride;
- uint32_t x, y, width, height;
+ uint32_t x, y, src_x, src_y, width, height;
uint32_t roi_w, roi_h;
int lm;
@@ -800,6 +811,26 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
get_roi(crtc, _w, _h);
+ /* If cusror buffer overlaps due to rotation on the
+* upper or left screen border the pixel offset inside
+* the cursor buffer of the ROI is the positive overlap
+* distance.
+*/
+ if (mdp5_crtc->cursor.x < 0) {
+ src_x = abs(mdp5_crtc->cursor.x);
+ x = 0;
+ } else {
+ src_x = 0;
+ }
+ if (mdp5_crtc->cursor.y < 0) {
+ src_y = abs(mdp5_crtc->cursor.y);
+ y = 0;
+ } else {
+ src_y = 0;
+ }
+ DBG("%s: x=%u, y=%u roi_w=%u roi_h=%u src_x=%u src_y=%u",
+ crtc->name, x, y, roi_w, roi_h, src_x, src_y);
+
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
@@ -812,6 +843,9 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_START_XY(lm),
MDP5_LM_CURSOR_START_XY_Y_START(y) |
MDP5_LM_CURSOR_START_XY_X_START(x));
+ mdp5_write(mdp5_kms,
[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl
https://bugs.freedesktop.org/show_bug.cgi?id=107309 --- Comment #2 from Vasilis LIaskovitis --- Cool, thanks! -- 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] efifb: BGRT: Do not copy the boot graphics for non native resolutions
On Monday, July 16, 2018 03:45:43 PM Hans de Goede wrote: > On x86 some firmwares use a low non native resolution for the display when > they have shown some text messages. While keeping the bgrt filled with info > for the native resolution. If the bgrt image intended for the native > resolution still fits, it will be displayed very close to the right edge of > the display looking quite bad. > > This commits adds a (heuristics based) checks for this and makes efifb > not show the boot graphics when this is the case. > > Signed-off-by: Hans de Goede Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: fix omap2/omapfb/dss/ indentation warning
On Saturday, July 21, 2018 08:16:09 PM Randy Dunlap wrote: > From: Randy Dunlap > > Fix indentation warning (from gcc 8.1.0) in omap2/omapfb: > > ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 'pixinc': > ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else' > clause does not guard... [-Wmisleading-indentation] > else > ^~~~ > ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1861:3: note: ...this > statement, but the latter is misleadingly indented as if it were guarded by > the 'else' >return 0; >^~ > > Signed-off-by: Randy Dunlap > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-o...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: encoder-tpd12s015: remove redundant pointer 'in'
On Friday, July 20, 2018 07:52:13 PM Colin King wrote: > From: Colin Ian King > > Pointer 'in' is being assigned but is never used hence it is > redundant and can be removed. > > Cleans up clang warning: > warning: variable 'in' set but not used [-Wunused-but-set-variable] > > Signed-off-by: Colin Ian King Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: tridentfb: remove deadcode on unreachable case statement
On Monday, July 16, 2018 02:44:58 PM Colin King wrote:
> From: Colin Ian King
>
> The value of tmp being used in the switch statement has the range of
> just 0..3 hence the case 4 statement can never be reached and is
> deadcode and can be removed.
>
> Detected by CoverityScan, CID#744384 ("Logically dead code")
>
> Signed-off-by: Colin Ian King
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: omapfb: off by one in omapfb_register_client()
On Friday, July 13, 2018 05:55:55 PM Dan Carpenter wrote:
> The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> > should be >= or we are one element beyond the end of the array.
>
> Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
> Signed-off-by: Dan Carpenter
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/13] drm: Add puts callback for the coredump printer
Add a puts function for the coredump printer to bypass printf()
for constant strings for a speed boost. Reorganize the
coredump printf callback to share as much code as possible.
v2: Try to reuse code between print and puts as suggested by
Chris Wilson
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 84 +
include/drm/drm_print.h | 2 +
2 files changed, 51 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 8ddeaba4bf9d..7631a40389ba 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,7 +30,7 @@
#include
#include
-void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
struct drm_print_iterator *iterator = p->arg;
ssize_t len;
@@ -38,26 +38,16 @@ void __drm_printfn_coredump(struct drm_printer *p, struct
va_format *vaf)
if (!iterator->remain)
return;
- /* Figure out how big the string will be */
- len = snprintf(NULL, 0, "%pV", vaf);
-
if (iterator->offset < iterator->start) {
- char *buf;
ssize_t copy;
+ len = strlen(str);
+
if (iterator->offset + len <= iterator->start) {
iterator->offset += len;
return;
}
- /* Print the string into a temporary buffer */
- buf = kmalloc(len + 1,
- GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
- if (!buf)
- return;
-
- snprintf(buf, len + 1, "%pV", vaf);
-
copy = len - (iterator->start - iterator->offset);
if (copy > iterator->remain)
@@ -65,42 +55,66 @@ void __drm_printfn_coredump(struct drm_printer *p, struct
va_format *vaf)
/* Copy out the bit of the string that we need */
memcpy(iterator->data,
- buf + (iterator->start - iterator->offset), copy);
+ str + (iterator->start - iterator->offset), copy);
iterator->offset = iterator->start + copy;
iterator->remain -= copy;
-
- kfree(buf);
} else {
- char *buf;
ssize_t pos = iterator->offset - iterator->start;
- if (len < iterator->remain) {
- snprintf(((char *) iterator->data) + pos,
- iterator->remain, "%pV", vaf);
+ len = min_t(ssize_t, strlen(str), iterator->remain);
- iterator->offset += len;
- iterator->remain -= len;
+ memcpy(iterator->data + pos, str, len);
- return;
- }
+ iterator->offset += len;
+ iterator->remain -= len;
+ }
+}
+EXPORT_SYMBOL(__drm_puts_coredump);
- /* Print the string into a temporary buffer */
- buf = kmalloc(len + 1,
- GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
- if (!buf)
- return;
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+ struct drm_print_iterator *iterator = p->arg;
+ size_t len;
+ char *buf;
+
+ if (!iterator->remain)
+ return;
+
+ /* Figure out how big the string will be */
+ len = snprintf(NULL, 0, "%pV", vaf);
+
+ /* This is the easiest path, we've already advanced beyond the offset */
+ if (iterator->offset + len <= iterator->start) {
+ iterator->offset += len;
+ return;
+ }
- snprintf(buf, len + 1, "%pV", vaf);
+ /* Then check if we can directly copy into the target buffer */
+ if ((iterator->offset >= iterator->start) && (len < iterator->remain)) {
+ ssize_t pos = iterator->offset - iterator->start;
- /* Copy out the remaining bits */
- memcpy(iterator->data + pos, buf, iterator->remain);
+ snprintf(((char *) iterator->data) + pos,
+ iterator->remain, "%pV", vaf);
- iterator->offset += iterator->remain;
- iterator->remain = 0;
+ iterator->offset += len;
+ iterator->remain -= len;
- kfree(buf);
+ return;
}
+
+ /*
+* Finally, hit the slow path and make a temporary string to copy over
+* using _drm_puts_coredump
+*/
+ buf = kmalloc(len + 1, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+ if (!buf)
+ return;
+
+ snprintf(buf, len + 1, "%pV", vaf);
+ __drm_puts_coredump(p, (const char *) buf);
+
+ kfree(buf);
}
EXPORT_SYMBOL(__drm_printfn_coredump);
diff --git
[PATCH 11/13] drm/msm/adreno: Add ringbuffer data to the GPU state
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 7 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 39 +
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
3 files changed, 48 insertions(+)
diff --git a/Documentation/gpu/msm-crash-dump.rst
b/Documentation/gpu/msm-crash-dump.rst
index 75ab1d541c03..35e87004e006 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -59,6 +59,13 @@ ringbuffer
wptr
The current write pointer (wptr) for the ringbuffer.
+ size
+ Maximum size of the ringbuffer programmed in the hardware.
+
+ data
+ The contents of the ring encoded as ascii85. Only the used
+ portions of the ring will be printed.
+
registers
Set of registers values. Each entry is on its own line enclosed
by brackets { }.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index c7a998d9dc85..808d4fc9c4a1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,6 +17,7 @@
* this program. If not, see
[PATCH 12/13] drm/msm/adreno: Add a5xx specific registers for the GPU state
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture. Add a5xx specific code
to program the crashdumper and retrieve the wayward registers
and dump them for the crash state.
Also, remove a block of registers the regular CPU accessible
list that aren't useful for debug which helps reduce the size
of the crash state file by a goodly amount.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 4 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 236 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 23 +--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 +-
6 files changed, 252 insertions(+), 31 deletions(-)
diff --git a/Documentation/gpu/msm-crash-dump.rst
b/Documentation/gpu/msm-crash-dump.rst
index 35e87004e006..7943f43f70d6 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -76,3 +76,7 @@ registers
value
Hexadecimal value of the register.
+
+registers-hlsq
+ (5xx only) Register values from the HLSQ aperture.
+ Same format as the register section.
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index fc502e412132..669c2d4b070d 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -421,10 +421,12 @@ static void a3xx_dump(struct msm_gpu *gpu)
static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
{
- struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+ struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (IS_ERR(state))
- return state;
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ adreno_gpu_state_get(gpu, state);
state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 8129cf037db1..7c4e6dc1ed59 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -457,10 +457,12 @@ static const unsigned int a4xx_registers[] = {
static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
{
- struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+ struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (IS_ERR(state))
- return state;
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ adreno_gpu_state_get(gpu, state);
state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 16074fa6bf1e..bd84f71d27d8 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "msm_gem.h"
#include "msm_mmu.h"
#include "a5xx_gpu.h"
@@ -1123,8 +1124,9 @@ static const u32 a5xx_registers[] = {
0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
- 0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
- 0xB9A0, 0xB9BF, ~0
+ 0xEAA5, 0xEAC2, 0xA800, 0xA800, 0xA820, 0xA828, 0xA840, 0xA87D,
+ 0XA880, 0xA88D, 0xA890, 0xA8A3, 0xA8D0, 0xA8D8, 0xA8E0, 0xA8F5,
+ 0xAC60, 0xAC60, ~0,
};
static void a5xx_dump(struct msm_gpu *gpu)
@@ -1195,25 +1197,233 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
return 0;
}
+struct a5xx_crashdumper {
+ void *ptr;
+ struct drm_gem_object *bo;
+ u64 iova;
+};
+
+struct a5xx_gpu_state {
+ struct msm_gpu_state base;
+ u32 *hlsqregs;
+};
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+ readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+ interval, timeout)
+
+static int a5xx_crashdumper_init(struct msm_gpu *gpu,
+ struct a5xx_crashdumper *dumper)
+{
+ dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+ SZ_1M, MSM_BO_UNCACHED, gpu->aspace,
+ >bo, >iova);
+
+ if (IS_ERR(dumper->ptr))
+ return PTR_ERR(dumper->ptr);
+
+ return 0;
+}
+
+static void a5xx_crashdumper_free(struct msm_gpu *gpu,
+ struct a5xx_crashdumper *dumper)
+{
+ msm_gem_put_iova(dumper->bo, gpu->aspace);
+ msm_gem_put_vaddr(dumper->bo);
+
+ drm_gem_object_unreference(dumper->bo);
+}
+
+static int a5xx_crashdumper_run(struct
[PATCH 06/13] drm/msm/gpu: Capture the state of the GPU
Add the infrastructure to capture the current state of the GPU and
store it in memory so that it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this should
be extended to capture a much larger set of GPU information.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 15 +++
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 14 +++
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 55 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 ++
drivers/gpu/drm/msm/msm_gpu.h | 20 +
6 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 3ebbeb3a9b68..b707b5bca9ab 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -427,6 +427,19 @@ static void a3xx_dump(struct msm_gpu *gpu)
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
adreno_dump(gpu);
}
+
+static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
+{
+ struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+ if (IS_ERR(state))
+ return state;
+
+ state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
+
+ return state;
+}
+
/* Register offset defines for A3XX */
static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -453,6 +466,8 @@ static const struct adreno_gpu_funcs funcs = {
#ifdef CONFIG_DEBUG_FS
.show = a3xx_show,
#endif
+ .gpu_state_get = a3xx_gpu_state_get,
+ .gpu_state_put = adreno_gpu_state_put,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 16d3d596638e..17e97ebc1077 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -465,6 +465,18 @@ static void a4xx_show(struct msm_gpu *gpu, struct seq_file
*m)
}
#endif
+static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
+{
+ struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+ if (IS_ERR(state))
+ return state;
+
+ state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
+
+ return state;
+}
+
/* Register offset defines for A4XX, in order of enum adreno_regs */
static const unsigned int a4xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_A4XX_CP_RB_BASE),
@@ -541,6 +553,8 @@ static const struct adreno_gpu_funcs funcs = {
#ifdef CONFIG_DEBUG_FS
.show = a4xx_show,
#endif
+ .gpu_state_get = a4xx_gpu_state_get,
+ .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a4xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d39400e5bc42..9e85e4f7016d 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1195,6 +1195,26 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
return 0;
}
+static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
+{
+ struct msm_gpu_state *state;
+
+ /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+ a5xx_set_hwcg(gpu, false);
+
+ state = adreno_gpu_state_get(gpu);
+
+ if (!IS_ERR(state))
+ state->rbbm_status = gpu_read(gpu, REG_A5XX_RBBM_STATUS);
+
+ a5xx_set_hwcg(gpu, true);
+
+ return state;
+}
+
#ifdef CONFIG_DEBUG_FS
static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
{
@@ -1244,6 +1264,8 @@ static const struct adreno_gpu_funcs funcs = {
.debugfs_init = a5xx_debugfs_init,
#endif
.gpu_busy = a5xx_gpu_busy,
+ .gpu_state_get = a5xx_gpu_state_get,
+ .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a5xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bcbf9f2a29f9..4286a539f40a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -368,6 +368,61 @@ bool adreno_idle(struct msm_gpu *gpu, struct
msm_ringbuffer *ring)
return false;
}
+struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ struct msm_gpu_state *state;
+ int i, count = 0;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ do_gettimeofday(>time);
+
+ for (i = 0; i < gpu->nr_rings; i++)
[PATCH 01/13] include: Move ascii85 functions from i915 to linux/ascii85.h
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
v4: Make the return value const char * as suggested by Chris Wilson
v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be cleaner for the caller as suggested by Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/i915/i915_gpu_error.c | 34 +++-
include/linux/ascii85.h | 38 +++
2 files changed, 42 insertions(+), 30 deletions(-)
create mode 100644 include/linux/ascii85.h
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index df234dc23274..284e899ca8ff 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "i915_gpu_error.h"
#include "i915_drv.h"
@@ -522,35 +523,12 @@ void i915_error_printf(struct drm_i915_error_state_buf
*e, const char *f, ...)
va_end(args);
}
-static int
-ascii85_encode_len(int len)
-{
- return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
- int i;
-
- if (in == 0)
- return false;
-
- out[5] = '\0';
- for (i = 5; i--; ) {
- out[i] = '!' + in % 85;
- in /= 85;
- }
-
- return true;
-}
-
static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
{
- char out[6];
+ char out[ASCII85_BUFSZ];
int page;
if (!obj)
@@ -572,12 +550,8 @@ static void print_error_obj(struct
drm_i915_error_state_buf *m,
len -= obj->unused;
len = ascii85_encode_len(len);
- for (i = 0; i < len; i++) {
- if (ascii85_encode(obj->pages[page][i], out))
- err_puts(m, out);
- else
- err_puts(m, "z");
- }
+ for (i = 0; i < len; i++)
+ err_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
}
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index ..4cc40201273e
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,38 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) 2018 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+ return DIV_ROUND_UP(len, 4);
+}
+
+static inline const char *
+ascii85_encode(u32 in, char *out)
+{
+ int i;
+
+ if (in == 0)
+ return "z";
+
+ out[5] = '\0';
+ for (i = 5; i--; ) {
+ out[i] = '!' + in % 85;
+ in /= 85;
+ }
+
+ return out;
+}
+
+#endif
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/13] drm/msm/adreno: Convert the show/crash file format
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
v2: Use a standard .rst for the msm crashdump documentation
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 71 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 +---
2 files changed, 84 insertions(+), 8 deletions(-)
create mode 100644 Documentation/gpu/msm-crash-dump.rst
diff --git a/Documentation/gpu/msm-crash-dump.rst
b/Documentation/gpu/msm-crash-dump.rst
new file mode 100644
index ..75ab1d541c03
--- /dev/null
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -0,0 +1,71 @@
+=
+MSM Crash Dump Format
+=
+
+Following a GPU hang the MSM driver outputs debugging information via
+/sys/kernel/dri/X/show or via devcoredump (/sys/class/devcoredump/dcdX/data).
+This document describes how the output is formatted.
+
+Each entry is in the form key: value. Sections headers will not have a value
+and all the contents of a section will be indented two spaces from the header.
+Each section might have multiple array entries the start of which is designated
+by a (-).
+
+Mappings
+
+
+kernel
+ The kernel version that generated the dump (UTS_RELEASE).
+
+module
+ The module that generated the crashdump.
+
+time
+ The kernel time at crash formated as seconds.microseconds.
+
+comm
+ Comm string for the binary that generated the fault.
+
+cmdline
+ Command line for the binary that generated the fault.
+
+revision
+ ID of the GPU that generated the crash formatted as
+ core.major.minor.patchlevel separated by dots.
+
+rbbm-status
+ The current value of RBBM_STATUS which shows what top level GPU
+ components are in use at the time of crash.
+
+ringbuffer
+ Section containing the contents of each ringbuffer. Each ringbuffer is
+ identified with an id number.
+
+ id
+ Ringbuffer ID (0 based index). Each ringbuffer in the section
+ will have its own unique id.
+ iova
+ GPU address of the ringbuffer.
+
+ last-fence
+ The last fence that was issued on the ringbuffer
+
+ retired-fence
+ The last fence retired on the ringbuffer.
+
+ rptr
+ The current read pointer (rptr) for the ringbuffer.
+
+ wptr
+ The current write pointer (wptr) for the ringbuffer.
+
+registers
+ Set of registers values. Each entry is on its own line enclosed
+ by brackets { }.
+
+ offset
+ Byte offset of the register from the start of the
+ GPU memory region.
+
+ value
+ Hexadecimal value of the register.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index c72e3afc43a8..c7a998d9dc85 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -445,23 +445,28 @@ void adreno_show(struct msm_gpu *gpu, struct
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
- drm_printf(p, "status: %08x\n", state->rbbm_status);
drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
- for (i = 0; i < gpu->nr_rings; i++) {
- drm_printf(p, "rb %d: fence:%d/%d\n", i,
- state->ring[i].fence, state->ring[i].seqno);
+ drm_printf(p, "rbbm-status: 0x%08x\n", state->rbbm_status);
+
+ drm_puts(p, "ringbuffer:\n");
- drm_printf(p, " rptr: %d\n", state->ring[i].rptr);
- drm_printf(p, "rb wptr: %d\n", state->ring[i].wptr);
+ for (i = 0; i < gpu->nr_rings; i++) {
+ drm_printf(p, " - id: %d\n", i);
+ drm_printf(p, "iova: 0x%016llx\n", state->ring[i].iova);
+ drm_printf(p, "last-fence: %d\n", state->ring[i].seqno);
+ drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
+ drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
+ drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
}
- drm_printf(p, "IO:region %s 0002\n", gpu->name);
+ drm_puts(p, "registers:\n");
+
for (i = 0; i < state->nr_registers; i++) {
- drm_printf(p, "IO:R %08x %08x\n",
+ drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH 08/13] drm/msm/gpu: Rearrange the code that collects the task during a hang
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..03ba8872cc99 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -314,6 +314,7 @@ static void recover_worker(struct work_struct *work)
struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_submit *submit;
struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
+ char *comm = NULL, *cmd = NULL;
int i;
mutex_lock(>struct_mutex);
@@ -327,7 +328,7 @@ static void recover_worker(struct work_struct *work)
rcu_read_lock();
task = pid_task(submit->pid, PIDTYPE_PID);
if (task) {
- char *cmd;
+ comm = kstrdup(task->comm, GFP_ATOMIC);
/*
* So slightly annoying, in other paths like
@@ -340,22 +341,23 @@ static void recover_worker(struct work_struct *work)
* about the submit going away.
*/
mutex_unlock(>struct_mutex);
- cmd = kstrdup_quotable_cmdline(task, GFP_KERNEL);
+ cmd = kstrdup_quotable_cmdline(task, GFP_ATOMIC);
mutex_lock(>struct_mutex);
+ }
+ rcu_read_unlock();
+ if (comm && cmd) {
dev_err(dev->dev, "%s: offending task: %s (%s)\n",
- gpu->name, task->comm, cmd);
+ gpu->name, comm, cmd);
msm_rd_dump_submit(priv->hangrd, submit,
- "offending task: %s (%s)", task->comm, cmd);
-
- kfree(cmd);
- } else {
+ "offending task: %s (%s)", comm, cmd);
+ } else
msm_rd_dump_submit(priv->hangrd, submit, NULL);
- }
- rcu_read_unlock();
}
+ kfree(cmd);
+ kfree(comm);
/*
* Update all the rings with the latest and greatest fence.. this
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/13] drm/msm/gpu: Capture the GPU state on a GPU hang
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be captured on the next hang.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 +-
drivers/gpu/drm/msm/msm_debugfs.c | 5 +-
drivers/gpu/drm/msm/msm_gpu.c | 83 -
drivers/gpu/drm/msm/msm_gpu.h | 38 ++-
9 files changed, 154 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde971b48..843a9d40c05e 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
+ select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4cffec2b6adc..fc502e412132 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -454,7 +454,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a3xx_irq,
.destroy = a3xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
#endif
.gpu_state_get = a3xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 95f08c22e8d7..8129cf037db1 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -540,7 +540,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a4xx_irq,
.destroy = a4xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
#endif
.gpu_state_get = a4xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 5f1aab3c1cb1..16074fa6bf1e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1243,8 +1243,10 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = a5xx_active_ring,
.irq = a5xx_irq,
.destroy = a5xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
+#endif
+#if defined(CONFIG_DEBUG_FS)
.debugfs_init = a5xx_debugfs_init,
#endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 42828253ede5..c72e3afc43a8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -378,6 +378,8 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu
*gpu)
if (!state)
return ERR_PTR(-ENOMEM);
+ kref_init(>ref);
+
do_gettimeofday(>time);
for (i = 0; i < gpu->nr_rings; i++) {
@@ -414,18 +416,28 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu
*gpu)
return state;
}
-void adreno_gpu_state_put(struct msm_gpu_state *state)
+static void adreno_gpu_state_destroy(struct kref *kref)
{
- if (IS_ERR_OR_NULL(state))
- return;
+ struct msm_gpu_state *state = container_of(kref,
+ struct msm_gpu_state, ref);
+ kfree(state->comm);
+ kfree(state->cmd);
kfree(state->registers);
kfree(state);
}
-#ifdef CONFIG_DEBUG_FS
+int adreno_gpu_state_put(struct msm_gpu_state *state)
+{
+ if (IS_ERR_OR_NULL(state))
+ return 1;
+
+ return kref_put(>ref, adreno_gpu_state_destroy);
+}
+
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
- struct seq_file *m)
+ struct drm_printer *p)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
@@ -433,23 +445,23 @@ void adreno_show(struct msm_gpu *gpu, struct
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
- seq_printf(m, "status: %08x\n", state->rbbm_status);
- seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
+ drm_printf(p, "status: %08x\n", state->rbbm_status);
+ drm_printf(p,
[PATCH 13/13] drm/msm/gpu: Add the buffer objects from the submit to the crash dump
For hangs, dump copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 14 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 58 -
drivers/gpu/drm/msm/msm_gpu.c | 48 ++--
drivers/gpu/drm/msm/msm_gpu.h | 9
4 files changed, 116 insertions(+), 13 deletions(-)
diff --git a/Documentation/gpu/msm-crash-dump.rst
b/Documentation/gpu/msm-crash-dump.rst
index 7943f43f70d6..757cd257e0d8 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -66,6 +66,20 @@ ringbuffer
The contents of the ring encoded as ascii85. Only the used
portions of the ring will be printed.
+bo
+ List of buffers from the hanging submission if available.
+ Each buffer object will have a uinque iova.
+
+ iova
+ GPU address of the buffer object.
+
+ size
+ Allocated size of the buffer object.
+
+ data
+ The contents of the buffer object encoded with ascii85. Only
+ Trailing zeros at the end of the buffer will be skipped.
+
registers
Set of registers values. Each entry is on its own line enclosed
by brackets { }.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index cd418dab7a62..08d3c618b7de 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -437,6 +437,10 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
for (i = 0; i < ARRAY_SIZE(state->ring); i++)
kfree(state->ring[i].data);
+ for (i = 0; state->bos && i < state->nr_bos; i++)
+ kvfree(state->bos[i].data);
+
+ kfree(state->bos);
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -460,6 +464,39 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
}
#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
+
+static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
+{
+ char out[ASCII85_BUFSZ];
+ long l, datalen, i;
+
+ if (!ptr || !len)
+ return;
+
+ /*
+* Only dump the non-zero part of the buffer - rarely will any data
+* completely fill the entire allocated size of the buffer
+*/
+ for (datalen = 0, i = 0; i < len >> 2; i++) {
+ if (ptr[i])
+ datalen = (i << 2) + 1;
+ }
+
+ /* Skip printing the object if it is empty */
+ if (datalen == 0)
+ return;
+
+ l = ascii85_encode_len(datalen);
+
+ drm_puts(p, "data: !!ascii85 |\n");
+ drm_puts(p, " ");
+
+ for (i = 0; i < l; i++)
+ drm_puts(p, ascii85_encode(ptr[i], out));
+
+ drm_puts(p, "\n");
+}
+
void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
struct drm_printer *p)
{
@@ -487,19 +524,20 @@ void adreno_show(struct msm_gpu *gpu, struct
msm_gpu_state *state,
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
- if (state->ring[i].data && state->ring[i].data_size) {
- u32 *ptr = (u32 *) state->ring[i].data;
- char out[ASCII85_BUFSZ];
- long len = ascii85_encode_len(state->ring[i].data_size);
- int j;
+ adreno_show_object(p, state->ring[i].data,
+ state->ring[i].data_size);
+ }
- drm_printf(p, "data: !!ascii85 |\n");
- drm_printf(p, " ");
+ if (state->bos) {
+ drm_puts(p, "bos:\n");
- for (j = 0; j < len; j++)
- drm_printf(p, ascii85_encode(ptr[j], out));
+ for (i = 0; i < state->nr_bos; i++) {
+ drm_printf(p, " - iova: 0x%016llx\n",
+ state->bos[i].iova);
+ drm_printf(p, "size: %zd\n", state->bos[i].size);
- drm_printf(p, "\n");
+ adreno_show_object(p, state->bos[i].data,
+ state->bos[i].size);
}
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 5f39549d9a8b..3cf8e8d29812 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -318,8 +318,39 @@ static void msm_gpu_devcoredump_free(void *data)
msm_gpu_crashstate_put(gpu);
}
-static void msm_gpu_crashstate_capture(struct msm_gpu *gpu, char *comm,
- char *cmd)
+static void msm_gpu_crashstate_get_bo(struct msm_gpu_state *state,
+
[PATCH 07/13] drm/msm/gpu: Convert the GPU show function to use the GPU state
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping a previously captured state from a GPU hang.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 11 +--
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 12 +---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 18 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 +-
drivers/gpu/drm/msm/msm_debugfs.c | 92 ++---
drivers/gpu/drm/msm/msm_gpu.h | 3 +-
7 files changed, 104 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b707b5bca9ab..4cffec2b6adc 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -411,15 +411,6 @@ static const unsigned int a3xx_registers[] = {
~0 /* sentinel */
};
-#ifdef CONFIG_DEBUG_FS
-static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
- seq_printf(m, "status: %08x\n",
- gpu_read(gpu, REG_A3XX_RBBM_STATUS));
- adreno_show(gpu, m);
-}
-#endif
-
/* would be nice to not have to duplicate the _show() stuff with printk(): */
static void a3xx_dump(struct msm_gpu *gpu)
{
@@ -464,7 +455,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a3xx_irq,
.destroy = a3xx_destroy,
#ifdef CONFIG_DEBUG_FS
- .show = a3xx_show,
+ .show = adreno_show,
#endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 17e97ebc1077..95f08c22e8d7 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -455,16 +455,6 @@ static const unsigned int a4xx_registers[] = {
~0 /* sentinel */
};
-#ifdef CONFIG_DEBUG_FS
-static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
- seq_printf(m, "status: %08x\n",
- gpu_read(gpu, REG_A4XX_RBBM_STATUS));
- adreno_show(gpu, m);
-
-}
-#endif
-
static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
{
struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
@@ -551,7 +541,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a4xx_irq,
.destroy = a4xx_destroy,
#ifdef CONFIG_DEBUG_FS
- .show = a4xx_show,
+ .show = adreno_show,
#endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 9e85e4f7016d..5f1aab3c1cb1 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct
msm_gpu *gpu)
return state;
}
-#ifdef CONFIG_DEBUG_FS
-static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
- seq_printf(m, "status: %08x\n",
- gpu_read(gpu, REG_A5XX_RBBM_STATUS));
-
- /*
-* Temporarily disable hardware clock gating before going into
-* adreno_show to avoid issues while reading the registers
-*/
- a5xx_set_hwcg(gpu, false);
- adreno_show(gpu, m);
- a5xx_set_hwcg(gpu, true);
-}
-#endif
-
static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1260,7 +1244,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a5xx_irq,
.destroy = a5xx_destroy,
#ifdef CONFIG_DEBUG_FS
- .show = a5xx_show,
+ .show = adreno_show,
.debugfs_init = a5xx_debugfs_init,
#endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 4286a539f40a..42828253ede5 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -424,38 +424,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
}
#ifdef CONFIG_DEBUG_FS
-void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
+void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
+ struct seq_file *m)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
+ if (IS_ERR_OR_NULL(state))
+ return;
+
+ seq_printf(m, "status: %08x\n", state->rbbm_status);
seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn,
[PATCH 04/13] drm: Add a -puts() function for the seq_file printer
Add a puts() function to use seq_puts() to help speed up
up print time for constant strings.
Reviewed-by: Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4bcd960788ba..8ddeaba4bf9d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -104,6 +104,12 @@ void __drm_printfn_coredump(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_coredump);
+void __drm_puts_seq_file(struct drm_printer *p, const char *str)
+{
+ seq_puts(p->arg, str);
+}
+EXPORT_SYMBOL(__drm_puts_seq_file);
+
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
{
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 06167a30f165..1834ec6244bf 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -76,6 +76,7 @@ struct drm_printer {
void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
+void __drm_puts_seq_file(struct drm_printer *p, const char *str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -182,6 +183,7 @@ static inline struct drm_printer
drm_seq_file_printer(struct seq_file *f)
{
struct drm_printer p = {
.printfn = __drm_printfn_seq_file,
+ .puts = __drm_puts_seq_file,
.arg = f,
};
return p;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/13] drm: Add drm_puts() to complement drm_printf()
Add drm_puts() for a much faster path to print constant strings
into a drm_printer object with memcpy and friends. This can
have seconds off of really large outputs such as GPU dumps.
If the drm_printer object supports a custom puts function then
use that otherwise fall back to the slower legacy printf call.
v2: Add documentation for drm_puts() per Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 17 +
include/drm/drm_print.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 03d1f98e5ac7..4bcd960788ba 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -122,6 +122,23 @@ void __drm_printfn_debug(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_debug);
+/**
+ * drm_puts - print a const string to a _printer stream
+ * @p: the printer
+ * @f: const string
+ *
+ * Allow _printer types that have a constant string
+ * option to use it.
+ */
+void drm_puts(struct drm_printer *p, const char *str)
+{
+ if (p->puts)
+ p->puts(p, str);
+ else
+ drm_printf(p, "%s", str);
+}
+EXPORT_SYMBOL(drm_puts);
+
/**
* drm_printf - print to a _printer stream
* @p: the _printer
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 3213d2896e9c..06167a30f165 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -69,6 +69,7 @@
struct drm_printer {
/* private: */
void (*printfn)(struct drm_printer *p, struct va_format *vaf);
+ void (*puts)(struct drm_printer *p, const char *str);
void *arg;
const char *prefix;
};
@@ -80,6 +81,7 @@ void __drm_printfn_debug(struct drm_printer *p, struct
va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
+void drm_puts(struct drm_printer *p, const char *str);
__printf(2, 0)
/**
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/13] drm: drm_printer: Add printer for devcoredump
Add a drm printer suitable for use with the read callback for
devcoredump or other suitable buffer based output format that
isn't otherwise covered by seq_file.
v2: Add improved documentation per Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 74 +
include/drm/drm_print.h | 65
2 files changed, 139 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index b25f98f33f6c..03d1f98e5ac7 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,6 +30,80 @@
#include
#include
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+ struct drm_print_iterator *iterator = p->arg;
+ ssize_t len;
+
+ if (!iterator->remain)
+ return;
+
+ /* Figure out how big the string will be */
+ len = snprintf(NULL, 0, "%pV", vaf);
+
+ if (iterator->offset < iterator->start) {
+ char *buf;
+ ssize_t copy;
+
+ if (iterator->offset + len <= iterator->start) {
+ iterator->offset += len;
+ return;
+ }
+
+ /* Print the string into a temporary buffer */
+ buf = kmalloc(len + 1,
+ GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+ if (!buf)
+ return;
+
+ snprintf(buf, len + 1, "%pV", vaf);
+
+ copy = len - (iterator->start - iterator->offset);
+
+ if (copy > iterator->remain)
+ copy = iterator->remain;
+
+ /* Copy out the bit of the string that we need */
+ memcpy(iterator->data,
+ buf + (iterator->start - iterator->offset), copy);
+
+ iterator->offset = iterator->start + copy;
+ iterator->remain -= copy;
+
+ kfree(buf);
+ } else {
+ char *buf;
+ ssize_t pos = iterator->offset - iterator->start;
+
+ if (len < iterator->remain) {
+ snprintf(((char *) iterator->data) + pos,
+ iterator->remain, "%pV", vaf);
+
+ iterator->offset += len;
+ iterator->remain -= len;
+
+ return;
+ }
+
+ /* Print the string into a temporary buffer */
+ buf = kmalloc(len + 1,
+ GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+ if (!buf)
+ return;
+
+ snprintf(buf, len + 1, "%pV", vaf);
+
+ /* Copy out the remaining bits */
+ memcpy(iterator->data + pos, buf, iterator->remain);
+
+ iterator->offset += iterator->remain;
+ iterator->remain = 0;
+
+ kfree(buf);
+ }
+}
+EXPORT_SYMBOL(__drm_printfn_coredump);
+
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
{
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index e1a46e9991cc..3213d2896e9c 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -73,6 +73,7 @@ struct drm_printer {
const char *prefix;
};
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -104,6 +105,70 @@ drm_vprintf(struct drm_printer *p, const char *fmt,
va_list *va)
#define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX",
##__VA_ARGS__)
+/**
+ * struct drm_print_iterator - local struct used with drm_printer_coredump
+ * @data: Pointer to the devcoredump output buffer
+ * @start: The offset within the buffer to start writing
+ * @remain: The number of bytes to write for this iteration
+ */
+struct drm_print_iterator {
+ void *data;
+ ssize_t start;
+ ssize_t remain;
+ /* private: */
+ ssize_t offset;
+};
+
+/**
+ * drm_coredump_printer - construct a _printer that can output to a buffer
+ * from the read function for devcoredump
+ * @iter: A pointer to a struct drm_print_iterator for the read instance
+ *
+ * This wrapper extends drm_printf() to work with a dev_coredumpm() callback
+ * function. The passed in drm_print_iterator struct contains the buffer
+ * pointer, size and offset as passed in from devcoredump.
+ *
+ * For example::
+ *
+ * void coredump_read(char *buffer, loff_t offset, size_t count,
+ * void *data, size_t datalen)
+ * {
+ * struct drm_print_iterator iter;
+ * struct drm_printer p;
+ *
+ * iter.data = buffer;
+ *
[v8 PATCH 00/13] drm/msm: Capture and dump the GPU crash state
This is revision 8 implementing a GPU crash state for drm/msm (https://patchwork.freedesktop.org/series/36097/). This patchset adds better documentation and reflects comments from the mailing lists. I know we will miss 4.19 at this point, but I think this is ready to soak in msm-next for a while. The object of this code is to store and provide enough information to debug software and hardware issues on the Adreno hardware in a semi human-readable format that can also be parsed by scripts. THe full set of changes here capture basic information about the GPU, the status and contents of the ringbuffers, a snapshot of the current register state and the active buffers from the hanging submit. The data is printed with devcoredump. For example, after a hang you can get the data from /sys/class/devcoredump/devcdX/data where X is a unique number. v8: Add documentation and consolidate puts/printf code from code comments v7: Add EXPORT_SYMBOL for __drm_puts_coredump and use %zd to print a size_t variable for the bo dump thanks to the ever vigilant zero one bot. v6: Add drm_puts() and use it in the appropriate place. Clean up a few minor bugs here and there. v5: Fix symbol error in i915_gpu_error.c thanks to 01 dot org bot. Added open/release functions for the show debugfs file to get the state per Chris Wilson. Slightly modified the register output format to be more YAML friendly also per Chris. v4: Add buffer dump for the active submit. Fix refcount issue with devcoredump. Change header for a5xx registers to registers-hlsq because I'm told YAML requires unique tags. v3: Make recommended changes to ascii85 per Chris Wilson. Use devcoredump to dump crash states as suggested by Bjorn Andersson and add a new drm_print facility to facilitate that. Remove the now obsolete 'crash' debugfs node. Add documentation for the crash dump output. v2: Convert output to yaml, use ascii85 to dump ringbuffer contents. Jordan Crouse (13): include: Move ascii85 functions from i915 to linux/ascii85.h drm: drm_printer: Add printer for devcoredump drm: Add drm_puts() to complement drm_printf() drm: Add a -puts() function for the seq_file printer drm: Add puts callback for the coredump printer drm/msm/gpu: Capture the state of the GPU drm/msm/gpu: Convert the GPU show function to use the GPU state drm/msm/gpu: Rearrange the code that collects the task during a hang drm/msm/gpu: Capture the GPU state on a GPU hang drm/msm/adreno: Convert the show/crash file format drm/msm/adreno: Add ringbuffer data to the GPU state drm/msm/adreno: Add a5xx specific registers for the GPU state drm/msm/gpu: Add the buffer objects from the submit to the crash dump Documentation/gpu/msm-crash-dump.rst| 96 ++ drivers/gpu/drm/drm_print.c | 111 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 34 +--- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 30 +-- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 22 ++- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 242 ++-- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 184 -- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 10 +- drivers/gpu/drm/msm/msm_debugfs.c | 93 - drivers/gpu/drm/msm/msm_gpu.c | 145 +- drivers/gpu/drm/msm/msm_gpu.h | 68 ++- include/drm/drm_print.h | 71 +++ include/linux/ascii85.h | 38 14 files changed, 1044 insertions(+), 101 deletions(-) create mode 100644 Documentation/gpu/msm-crash-dump.rst create mode 100644 include/linux/ascii85.h -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
>
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
>
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
>
> This patch helps with backward compatibility for devices pre DP1.3.
>
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> v5: split into function, removed DPCD rev check
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/intel_dp.c | 54 +
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..ed16b93bfe40 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3731,6 +3731,58 @@ intel_dp_link_down(struct intel_encoder *encoder,
> }
> }
>
> +static void
> +intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
> +{
> + /*
> + * Prior to DP1.3 the bit represented by
> + * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> + * if it is set DP_DPCD_REV at h could be at a value less than
> + * the true capability of the panel. The only way to check is to
> + * then compare h and 2200h.
> + */
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
> + _ext, sizeof(dpcd_ext)) < 0)
> + return;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV])
> + return;
I'm still missing the debug messages here and above...
> +
> + if (memcmp(_dp->dpcd[DP_DPCD_REV], _ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision
> previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_DPCD_REV],
> + dpcd_ext[DP_DPCD_REV]);
> + memcpy(_dp->dpcd[DP_DPCD_REV],
> +_ext[DP_DPCD_REV], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate
> previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_MAX_LINK_RATE],
> + dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port
> Present previous value %2x new value %2x\n",
> + intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> + dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
> +}
> +
> +
> bool
> intel_dp_read_dpcd(struct intel_dp *intel_dp)
> {
> @@ -3738,6 +3790,8 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
> return false; /* aux transfer failed */
>
> + intel_dp_extended_receiver_capabilities(intel_dp);
> +
> DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> intel_dp->dpcd);
>
> return intel_dp->dpcd[DP_DPCD_REV] != 0;
> --
> 2.17.1
>
___
dri-devel mailing list
Re: [PATCH 1/2] drm/dp: add extended receiver capability field present bit
On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > This bit was added to DP Training Aux RD interval with DP 1.3. Via > descriptiion of the spec this field indicates the panels true > capabilities are described in DPCD address space 02200h through 022FFh. > > v2: version comment update > v3: version comment correction, commit message update > v4: white space correction I'm afraid the wrong space that I had mentioned it is still there s/"(1 << 7)/* DP 1.3 */"/"(1 << 7) /* DP 1.3 *"/g > > Signed-off-by: Matt Atwood > --- > include/drm/drm_dp_helper.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c01564991a9f..44aaefdc8448 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -123,8 +123,9 @@ > # define DP_FRAMING_CHANGE_CAP (1 << 1) > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher > */ > > -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */ > +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ > +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */ > +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */ ^ here > > #define DP_ADAPTER_CAP 0x00f /* 1.2 */ > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: Replace #if 1 with a bool to ignore
On Tuesday, July 24, 2018 06:13:19 PM Bartlomiej Zolnierkiewicz wrote: > On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > > > From: Steven Rostedt (VMware) > > > > There's been discussion on the fb list about the addition of > > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > > the fb module is loaded with lockless_register_fb the console lock is > > not taken for debugging reasons. With the addition of > > WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to > > fill up with warnings when trying to debug the fb driver. > > > > There's also a #if 1 that enables the warning which was added before > > git history, and we look down on constant #if's in the kernel nowadays > > anyway. > > > > Remove the #if 1 and add a ignore_console_lock_warning boolean that can > > be set by drivers to ignore the warning in order to do debugging. > > > > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de > > Reviewed-by: Hans de Goede > > Acked-by: Sergey Senozhatsky > > Signed-off-by: Steven Rostedt (VMware) > > Patch queued for 4.19, thanks. Dequeued, I've just noticed a newer patch from Thomas for this issue (I plan to apply it later this week). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] console: Replace #if 1 with a bool to ignore
On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote: > > From: Steven Rostedt (VMware) > > There's been discussion on the fb list about the addition of > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when > the fb module is loaded with lockless_register_fb the console lock is > not taken for debugging reasons. With the addition of > WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to > fill up with warnings when trying to debug the fb driver. > > There's also a #if 1 that enables the warning which was added before > git history, and we look down on constant #if's in the kernel nowadays > anyway. > > Remove the #if 1 and add a ignore_console_lock_warning boolean that can > be set by drivers to ignore the warning in order to do debugging. > > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de > Reviewed-by: Hans de Goede > Acked-by: Sergey Senozhatsky > Signed-off-by: Steven Rostedt (VMware) Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: mark expected switch fall-throughs
On Monday, July 09, 2018 05:41:45 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: Mark expected switch fall-throughs
On Monday, July 09, 2018 05:04:36 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: fbmem: mark expected switch fall-through
On Monday, July 09, 2018 04:36:08 PM Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Signed-off-by: Gustavo A. R. Silva Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev/via: fix defined but not used warning
On Saturday, July 07, 2018 08:29:36 AM Randy Dunlap wrote: > From: Randy Dunlap > > Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled > by marking the unused function as __maybe_unused. > > ../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: > 'viafb_sup_odev_proc_show' defined but not used [-Wunused-function] > > Signed-off-by: Randy Dunlap > Cc: Florian Tobias Schandinat > Cc: linux-fb...@vger.kernel.org > Cc: Bartlomiej Zolnierkiewicz > Cc: dri-devel@lists.freedesktop.org Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: rename omap2 module to omap2fb.ko
On Monday, July 09, 2018 12:02:16 AM Tony Lindgren wrote: > * Arnd Bergmann [180706 12:39]: > > In a kernel configuration with both CONFIG_FB_OMAP=m and CONFIG_FB_OMAP2=m, > > Kbuild fails to point out that we have two modules with the same name > > (omapfb.ko), > > but instead fails with a cryptic error message like: > > > > ERROR: "omapfb_register_panel" [drivers/video/fbdev/omap/lcd_osk.ko] > > undefined! > > > > This can now happen when building a randconfig kernel with > > CONFIG_ARCH_OMAP1, > > as the omap1 fbdev driver depends on that, whiel the omap2 fbdev driver can > > now be built anywhere with CONFIG_COMPILE_TEST. > > > > The solution is to rename one of the two modules, so for consistency with > > the directory naming I decided to rename the omap2 version to omap2fb.ko. > > Sounds good to me: > > Acked-by: Tony Lindgren Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: goldfishfb: fix memory leak on driver remove
On Friday, July 06, 2018 03:04:22 PM Anton Vasilyev wrote: > goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does > not have deallocation of fb, which leads to memory leak on probe/remove. > > The patch adds deallocation into goldfish_fb_remove(). > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Anton Vasilyev Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: fix modedb docs in fb_find_mode
On Thursday, July 05, 2018 03:52:17 PM Daniel Vetter wrote: > Fix up the indenting that confused sphinx. To make sure we > don't have to make the examples unreadable with escaping just > put them in as block quotes, that seems the simplest solution. > > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: mark PM functions as __maybe_unused
The suspend/resume functions are not referenced when power
management is disabled:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1288:12: error: 'dpu_runtime_resume'
defined but not used [-Werror=unused-function]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1261:12: error: 'dpu_runtime_suspend'
defined but not used [-Werror=unused-function]
This marks them as __maybe_unused to let the compiler
drop the functions without complaining.
Fixes: 591225291ca2 ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 8d4678d29cc7..1c0838801e78 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1258,7 +1258,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
return 0;
}
-static int dpu_runtime_suspend(struct device *dev)
+static int __maybe_unused dpu_runtime_suspend(struct device *dev)
{
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
@@ -1285,7 +1285,7 @@ static int dpu_runtime_suspend(struct device *dev)
return rc;
}
-static int dpu_runtime_resume(struct device *dev)
+static int __maybe_unused dpu_runtime_resume(struct device *dev)
{
int rc = -1;
struct platform_device *pdev = to_platform_device(dev);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl
https://bugs.freedesktop.org/show_bug.cgi?id=107309 Emil Velikov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- 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 107309] libGL error: MESA-LOADER: failed to retrieve device information on virgl
https://bugs.freedesktop.org/show_bug.cgi?id=107309 --- Comment #1 from Emil Velikov --- The message is harmless since Mesa falls back to use the DRM driver name. That said, a slightly better (I'm obviously biased) solution has been on the list for ~month [1]. Just double-checked and pushed it to master. [1] https://lists.freedesktop.org/archives/dri-devel/2018-June/181067.html -- 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 00/10] Add helper for plane reset
On 2018-07-20 05:14 PM, Alexandru Gheorghe wrote: > Drivers that subclass drm_plane need to copy the logic for linking the > drm_plane with its state and to initialize core properties to their > default values. E.g (alpha and rotation) > > Having a helper to reset the plane_state makes sense because of multiple > reasons: > 1. Eliminate code duplication. > 2. Add a single place for initializing core properties to their > default values, no need for driver to do it if what the helper sets > makes sense for them. > 3. No need to debug the driver when you enable a core property and > observe it doesn't have a proper default value. > > Tested with mali-dp the other drivers are just built-tested. > For some reason I lost 02/10 hence I'm replying to the cover letter. Patches 1 & 2 are Reviewed-by: Harry Wentland Harry > > Alexandru Gheorghe (10): > drm/atomic: Add __drm_atomic_helper_plane_reset > drm/amd/display: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm: mali-dp: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of > copying the logic > drm/exynos: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/imx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying > the logic > drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the > logic > drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the > logic > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-- > drivers/gpu/drm/arm/malidp_planes.c | 7 ++-- > .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 +-- > drivers/gpu/drm/drm_atomic_helper.c | 32 +-- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 3 +- > drivers/gpu/drm/imx/ipuv3-plane.c | 8 ++--- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +-- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +-- > drivers/gpu/drm/sun4i/sun4i_layer.c | 4 +-- > drivers/gpu/drm/vc4/vc4_plane.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-- > include/drm/drm_atomic_helper.h | 2 ++ > 12 files changed, 39 insertions(+), 45 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 1/3] drm: Add colorspace property
This patch adds a colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_connector.c | 31 +++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 11 +++
5 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e..f065e6f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1397,6 +1397,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1502,6 +1504,8 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5ada064..cfe1d79 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -805,6 +805,25 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { EXTENDED_COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { EXTENDED_COLORIMETRY_XV_YCC_709, "709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { EXTENDED_COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { EXTENDED_COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { EXTENDED_COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { EXTENDED_COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+};
+
/**
* DOC: standard connector properties
*
@@ -951,6 +970,12 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
* can also expose this property to external outputs, in which case they
* must support "None", which should be the default (since external screens
* have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -999,6 +1024,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+ colorspace, ARRAY_SIZE(colorspace));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.colorspace_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index a5179eb..306b536 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -443,6 +443,13 @@ struct drm_connector_state {
unsigned int content_protection;
/**
+* @colorspace: Connector property to request colorspace
+* change. This is most commonly used to switch to wider color
+* gamuts like BT2020.
+*/
+ enum extended_colorimetry colorspace;
+
+ /**
* @writeback_job: Writeback job for writeback connectors
*
* Holds the framebuffer and out-fence for a writeback connector. As
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index
[RFC 2/3] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index b04952b..8e7d540 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, */ if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || + new_state->colorspace != old_state->colorspace || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index d06cf42..7fb96e2 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2110,6 +2110,9 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); drm_connector_attach_content_type_property(connector); + drm_object_attach_property(>base, + connector->dev->mode_config.colorspace_property, + EXTENDED_COLORIMETRY_XV_YCC_601); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 3/3] drm/i915: Set colorspace by enabling Infoframe
Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 7fb96e2..319da1b 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB; + frame.avi.extended_colorimetry = conn_state->colorspace; + drm_hdmi_avi_infoframe_quant_range(, adjusted_mode, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/3] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Kernel will not give the supported colorspaces since this is panel dependant and our curremt property infrastructure is not supporting it. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" Please provide comments on this current approach. This is just an RFC to get some feedback. Will refine the series based on inputs and feedback. Uma Shankar (3): drm: Add colorspace property drm/i915: Attach colorspace property and enable modeset drm/i915: Set colorspace by enabling Infoframe drivers/gpu/drm/drm_atomic.c| 4 drivers/gpu/drm/drm_connector.c | 31 +++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + include/drm/drm_connector.h | 7 +++ include/drm/drm_mode_config.h | 6 ++ include/uapi/drm/drm_mode.h | 11 +++ 7 files changed, 65 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: metronomefb: fix some off by one bugs
On Tuesday, July 03, 2018 03:28:13 PM Dan Carpenter wrote: > The "mem" buffer has "size" bytes. The ">" should be ">=" to prevent > reading one character beyond the end of the array. > > Signed-off-by: Dan Carpenter Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/console/vgacon: Print big fat warning with nomodeset
On Monday, July 02, 2018 05:04:40 PM Lyude Paul wrote: > It's been a pretty good while since kernel modesetting was introduced. > It has almost entirely replaced previous solutions which required > userspace modesetting, and I can't even recall any drivers off the top > of my head for modern day hardware that don't only support one or the > other. Even nvidia's ugly blob does not require the use of nomodeset, > and only requires that nouveau be blacklisted. > > Effectively, the only thing nomodeset does in the year 2018 is disable > your graphics drivers. Since VESA is a thing, this will give many users > the false impression that they've actually fixed an issue they were > having with their machine simply because the laptop will boot up to a > degraded GUI. This of course, is never actually the case. > > Things get even worse when you consider that there's still an enormous > amount of tutorials users find on the internet that still suggest adding > nomodeset, along with various users who have been around long enough to > still suggest it. > > There really isn't any legitimate reason I can see for this to be an > option that's used by anyone else other then developers, or properly > informed users. So, let's end the confusion and start printing warnings > whenever it's enabled. > > Signed-off-by: Lyude Paul Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
On Saturday, June 30, 2018 03:29:49 PM Yisheng Xie wrote:
> Following pattern is often used:
>
> for (i = 0; i < FB_MAX; i++) {
> if (registered_fb[i]) {
> ...
> }
> }
>
> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
> be introduced to make the code easier to read and write by reducing
> indentation level. It also saves few lines of code in each occurrence.
>
> This patch convert all part here at the same time.
>
> Suggested-by: Andy Shevchenko
> Signed-off-by: Yisheng Xie
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 2/2] fbdev: fix typo in comment
On Saturday, June 30, 2018 03:30:48 PM Yisheng Xie wrote: > change beeng to being and occured to occurred. > > Signed-off-by: Yisheng Xie Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: fsl-diu-fb: Remove VLA usage
On Saturday, June 30, 2018 10:59:15 AM Timur Tabi wrote: > On 6/29/18 1:46 PM, Kees Cook wrote: > > In the quest to remove all stack VLA usage from the kernel[1], this moves > > the buffer off the stack (since it could be as much as 1024 bytes), and > > uses a new area in the cursor data structure. Additionally adds missed > > documentation and removes redundant assignments. > > > > [1]https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > > > Signed-off-by: Kees Cook > > Acked-by: Timur Tabi Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/modetest: Add modetest_atomic tool
2018-07-23 18:30 GMT+02:00 Eric Engestrom :
> On Friday, 2018-07-20 13:33:29 +0200, Benjamin Gaignard wrote:
>> This is a modetest like tool but using atomic API.
>>
>> With modetest_atomic it is mandatory to specify a mode ("-s")
>> and a plane ("-P") to display a pattern on screen.
>>
>> "-v" does a loop swapping between two framebuffers for each
>> active planes.
>>
>> modetest_atomic doesn't offer cursor support
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>>
>> The code is based on modetest and keep most of it infrastructure
>> like arguments parsing, finding properties id from their name,
>> resources dumping or the general way of working.
>> It duplicates modetest code but adding compilation flags or
>> conditional tests everywhere in modetest would have made it
>> more complex and unreadable.
>
> I don't have an opinion on whether duplicating the test is the right
> thing, but if you do, please also duplicate the lines in
> tests/modetest/meson.build :)
You are right, I will also make it compile for Android.
>
>>
>> Creating modetest_atomic could allow to test atomic API without
>> need to use "big" frameworks like weston, drm_hwcomposer or igt
>> with all their dependencies.
>> kmscube could also be used to test atomic API but it need EGL.
>>
>> It have been tested (only) on stm driver with one or two planes
>> actived.
>>
>> tests/modetest/Makefile.am | 13 +-
>> tests/modetest/Makefile.sources |7 +
>> tests/modetest/modetest_atomic.c | 1546
>> ++
>> 3 files changed, 1564 insertions(+), 2 deletions(-)
>> create mode 100644 tests/modetest/modetest_atomic.c
>>
>> diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
>> index 4b296c83..8f697bb3 100644
>> --- a/tests/modetest/Makefile.am
>> +++ b/tests/modetest/Makefile.am
>> @@ -10,10 +10,12 @@ AM_CFLAGS += \
>>
>> if HAVE_INSTALL_TESTS
>> bin_PROGRAMS = \
>> - modetest
>> + modetest \
>> + modetest_atomic
>> else
>> noinst_PROGRAMS = \
>> - modetest
>> + modetest \
>> + modetest_atomic
>> endif
>>
>> modetest_SOURCES = $(MODETEST_FILES)
>> @@ -22,3 +24,10 @@ modetest_LDADD = \
>> $(top_builddir)/libdrm.la \
>> $(top_builddir)/tests/util/libutil.la \
>> $(CAIRO_LIBS)
>> +
>> +modetest_atomic_SOURCES = $(MODETEST_ATOMIC_FILES)
>> +
>> +modetest_atomic_LDADD = \
>> + $(top_builddir)/libdrm.la \
>> + $(top_builddir)/tests/util/libutil.la \
>> + $(CAIRO_LIBS)
>> diff --git a/tests/modetest/Makefile.sources
>> b/tests/modetest/Makefile.sources
>> index 399af0df..0a1df4c0 100644
>> --- a/tests/modetest/Makefile.sources
>> +++ b/tests/modetest/Makefile.sources
>> @@ -4,3 +4,10 @@ MODETEST_FILES := \
>> cursor.c \
>> cursor.h \
>> modetest.c
>> +
>> +MODETEST_ATOMIC_FILES := \
>> + buffers.c \
>> + buffers.h \
>> + cursor.c \
>> + cursor.h \
>> + modetest_atomic.c
>> diff --git a/tests/modetest/modetest_atomic.c
>> b/tests/modetest/modetest_atomic.c
>> new file mode 100644
>> index ..8c877860
>> --- /dev/null
>> +++ b/tests/modetest/modetest_atomic.c
>> @@ -0,0 +1,1546 @@
>> +/*
>> + * DRM based mode setting test program
>> + * Copyright 2008 Tungsten Graphics
>> + * Jakob Bornecrantz
>> + * Copyright 2008 Intel Corporation
>> + * Jesse Barnes
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
>> DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +/*
>> + * This fairly simple test program dumps output in a similar format to the
>> + * "xrandr" tool everyone knows & loves. It's necessarily slightly
>> different
>> + * since the kernel separates outputs into encoder and connector structures,
>> + * each with their own unique ID. The program also allows test testing of
>> the
>> + * memory management and mode setting APIs by allowing the user to specify a
>> + * connector and mode to use for mode setting. If all
Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes
On Monday, July 09, 2018 07:12:50 AM Daniel Mack wrote: > Hi Bartlomiej, Hi, > Should I resend with Robert's Reviewed-bys again? I'd like to get this > merged for 4.19 if possible. No need for resend, I added Robert's tags while applying your patches. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] video: fbdev: pxafb: Add support for lcd-supply regulator
On Sunday, June 24, 2018 05:38:17 PM Daniel Mack wrote: > Optionally obtain a lcd-supply regulator during probe and use it in > __pxafb_lcd_power() to switch the power supply of LCD panels. > > This helps boards booted from DT to control such voltages without > callbacks. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] video: fbdev: pxafb: handle errors from pxafb_init_fbinfo() correctly
On Sunday, June 24, 2018 05:38:16 PM Daniel Mack wrote: > pxafb_init_fbinfo() can not only report errors caused by failed > allocations but also when the clock can't be found. > > To fix this, return an error pointer instead of NULL in case of errors, > and up-chain the result. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] video: fbdev: pxafb: clear allocated memory for video modes
On Sunday, June 24, 2018 05:38:14 PM Daniel Mack wrote: > When parsing the video modes from DT properties, make sure to zero out > memory before using it. This is important because not all fields in the mode > struct are explicitly initialized, even though they are used later on. > > Fixes: 420a488278e86 (video: fbdev: pxafb: initial devicetree conversion) > Reviewed-by: Robert Jarzmik > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] video: fbdev: pxafb: switch to devm_* API
On Sunday, June 24, 2018 05:38:15 PM Daniel Mack wrote: > This helps us clean up the probe() and remove() implementations. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] video: fbdev: pxa3xx_gcu: add devicetree bindings
On Wednesday, July 04, 2018 09:35:02 PM Daniel Mack wrote: > Add a device tree match table for this hardware graphics acceleration > driver so it can be used by pxa3xx boards booted with a devicetree. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: add devicetree bindings for pxa300-gcu
On Wednesday, July 04, 2018 09:35:01 PM Daniel Mack wrote: > This patch adds the binding documentation for the pxa300 gcu. > > Signed-off-by: Daniel Mack Patch queued for 4.19, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev: Distinguish between interlaced and progressive modes
On Wednesday, July 04, 2018 09:08:48 PM Fredrik Noring wrote:
> Hi Bartlomiej,
>
> > > With this change fb_find_mode can match interlaced and progressive
> > > modes equally well, and distinguish between for example 1920x1080i
> > > and 1920x1080p.
> > >
> > > Signed-off-by: Fredrik Noring
> >
> > Could you please give some examples of use cases that need this change
> > (i.e. which fbdev drivers need it for which modes etc.)?
>
> I discovered the problem when developing a frame buffer driver for the
> PlayStation 2 (not yet merged), using the following video modes for the
> PlayStation 3 in drivers/video/fbdev/ps3fb.c:
>
> }, {
> /* 1080if */
> "1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
> FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
> }, {
> /* 1080pf */
> "1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
> FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
> },
>
> In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
> but it can only select the interlaced variant of 1920x1080 since the loop
> matching the modes does not take the difference between interlaced and
> progressive modes into account.
>
> In short, without the patch, progressive 1920x1080 cannot be chosen as a
> mode_option parameter since fb_find_mode (falsely) thinks interlace is a
> perfect match.
Patch queued for 4.19 (with the above explanation used as patch description),
thanks!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCHv2 2/9] dt-bindings: display/ti: add k2g-dss bindings
Hi Tomi, Thank you for the patch. On Monday, 18 June 2018 16:22:35 EEST Tomi Valkeinen wrote: > Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS > is quite simple, with a single plane and a single output. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org > Reviewed-by: Rob Herring > --- > .../devicetree/bindings/display/ti/ti,k2g-dss.txt | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt new file mode > 100644 > index ..1af11425eda3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.txt > @@ -0,0 +1,15 @@ > +Texas Instruments K2G Display Subsystem > +=== > + > +Required properties: > +- compatible: "ti,k2g-dss" > +- reg: address and length of the register spaces for DSS submodules > +- reg-names: "cfg", "common", "vid1", "ovr1", "vp1" When seeing multiple register ranges for a DT node I always suspect that we describe multiple IP cores that could be better modeled as independent nodes. What prompted you not to model the DISPC as a separate DT node (possibly a child of the DSS DT node) ? Furthermore, "cfg" corresponds to the DSS registers, so I wonder whether it shouldn't be named "dss". Similarly, "common" really sounds like DSS common registers, while it relates to the DISPC. > +- clocks: phandle to fclk and vp1 clocks > +- clock-names: "fck", "vp1" > +- interrupts: phandle to the DISPC interrupt > + > +The DSS outputs are described using the device graphs as documented in > +Documentation/devicetree/bindings/graph.txt. K2G DSS has a single DPI > output as > +port 0. Both SPRUHY8H and SPRSP07D document a DPI output and a DBI output. Am I looking at the wrong document ? > + Extra blank line ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
>
> - comment "failed to reap part..." is misleading - sounds like it's
> referring to something which happened in the past, is in fact
> referring to something which might happen in the future.
>
> - fails to call trace_finish_task_reaping() in one case
>
> - code duplication.
>
> - Increases mmap_sem hold time a little by moving
> trace_finish_task_reaping() inside the locked region. So sue me ;)
>
> - Sharing the finish: path means that the trace event won't
> distinguish between the two sources of finishing.
>
> Please take a look?
oom_reap_task_mm should return false when __oom_reap_task_mm return
false. This is what my patch did but it seems this changed by
http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
so that one should be fixed.
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 104ef4a01a55..88657e018714 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
/* failed to reap part of the address space. Try again later */
if (!__oom_reap_task_mm(mm)) {
up_read(>mmap_sem);
- return true;
+ return false;
}
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
On top of that the proposed cleanup looks as follows:
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 88657e018714..4e185a282b3d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
return ret;
}
+/*
+ * Reaps the address space of the give task.
+ *
+ * Returns true on success and false if none or part of the address space
+ * has been reclaimed and the caller should retry later.
+ */
static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
{
+ bool ret = true;
+
if (!down_read_trylock(>mmap_sem)) {
trace_skip_task_reaping(tsk->pid);
return false;
@@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk,
struct mm_struct *mm)
* down_write();up_write() cycle in exit_mmap().
*/
if (test_bit(MMF_OOM_SKIP, >flags)) {
- up_read(>mmap_sem);
trace_skip_task_reaping(tsk->pid);
- return true;
+ goto out_unlock;
}
trace_start_task_reaping(tsk->pid);
/* failed to reap part of the address space. Try again later */
- if (!__oom_reap_task_mm(mm)) {
- up_read(>mmap_sem);
- return false;
- }
+ ret = __oom_reap_task_mm(mm);
+ if (!ret)
+ goto out_finish;
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB,
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
K(get_mm_counter(mm, MM_FILEPAGES)),
K(get_mm_counter(mm, MM_SHMEMPAGES)));
+out_finish:
+ trace_finish_task_reaping(tsk->pid);
+out_unlock:
up_read(>mmap_sem);
- trace_finish_task_reaping(tsk->pid);
- return true;
+ return ret;
}
#define MAX_OOM_REAP_RETRIES 10
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCHv2 1/9] drm: Add support for extracting sync signal drive edge from videomode
Hi Tomi,
Thank you for the patch.
On Monday, 18 June 2018 16:22:34 EEST Tomi Valkeinen wrote:
> From: Peter Ujfalusi
>
> The sync in some panels needs to be driven by different edge of the pixel
> clock compared to data. This is reflected by the
> DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode flags.
> Add similar similar definitions for bus_flags and convert the sync drive
> edge via drm_bus_flags_from_videomode().
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jyri Sarha
Given "[PATCH 08/23] drm: Add display info bus flags to specify sync signals
clock edges" (https://patchwork.kernel.org/patch/10454713/),
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_modes.c | 15 +++
> include/drm/drm_connector.h | 4
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index e82b61e08f8c..1661bfc55687 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -659,10 +659,12 @@ EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode);
> * drm_bus_flags_from_videomode - extract information about pixelclk and
> * DE polarity from videomode and store it in a separate variable
> * @vm: videomode structure to use
> - * @bus_flags: information about pixelclk and DE polarity will be stored
> here + * @bus_flags: information about pixelclk, sync and DE polarity will
> be stored + * here
> *
> - * Sets DRM_BUS_FLAG_DE_(LOW|HIGH) and DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE
> - * in @bus_flags according to DISPLAY_FLAGS found in @vm
> + * Sets DRM_BUS_FLAG_DE_(LOW|HIGH), DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and
> + * DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in @bus_flags according to
> DISPLAY_FLAGS + * found in @vm
> */
> void drm_bus_flags_from_videomode(const struct videomode *vm, u32
> *bus_flags) {
> @@ -672,6 +674,11 @@ void drm_bus_flags_from_videomode(const struct
> videomode *vm, u32 *bus_flags) if (vm->flags &
> DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> *bus_flags |= DRM_BUS_FLAG_PIXDATA_NEGEDGE;
>
> + if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE)
> + *bus_flags |= DRM_BUS_FLAG_SYNC_POSEDGE;
> + if (vm->flags & DISPLAY_FLAGS_SYNC_NEGEDGE)
> + *bus_flags |= DRM_BUS_FLAG_SYNC_NEGEDGE;
> +
> if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> *bus_flags |= DRM_BUS_FLAG_DE_LOW;
> if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> @@ -684,7 +691,7 @@ EXPORT_SYMBOL_GPL(drm_bus_flags_from_videomode);
> * of_get_drm_display_mode - get a drm_display_mode from devicetree
> * @np: device_node with the timing specification
> * @dmode: will be set to the return value
> - * @bus_flags: information about pixelclk and DE polarity
> + * @bus_flags: information about pixelclk, sync and DE polarity
> * @index: index into the list of display timings in devicetree
> *
> * This function is expensive and should only be used, if only one mode is
> to be diff --git a/include/drm/drm_connector.h
> b/include/drm/drm_connector.h index 675cc3f8cf85..8fa901637f00 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -290,6 +290,10 @@ struct drm_display_info {
> #define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
> /* data is transmitted LSB to MSB on the bus */
> #define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
> +/* drive sync on pos. edge */
> +#define DRM_BUS_FLAG_SYNC_POSEDGE(1<<6)
> +/* drive sync on neg. edge */
> +#define DRM_BUS_FLAG_SYNC_NEGEDGE(1<<7)
>
> /**
>* @bus_flags: Additional information (like pixel signal polarity) for
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats
This is needed to ensure ->is_unity is correct when the plane was
previously configured to output a multi-planar format with scaling
enabled, and is then being reconfigured to output a uniplanar format.
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 9d7a36f148cf..cfb50fedfa2b 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -320,6 +320,9 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_state->x_scaling[0] = VC4_SCALING_TPZ;
if (vc4_state->y_scaling[0] == VC4_SCALING_NONE)
vc4_state->y_scaling[0] = VC4_SCALING_TPZ;
+ } else {
+ vc4_state->x_scaling[1] = VC4_SCALING_NONE;
+ vc4_state->y_scaling[1] = VC4_SCALING_NONE;
}
vc4_state->is_unity = (vc4_state->x_scaling[0] == VC4_SCALING_NONE &&
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic: Initialize variables in drm_atomic_helper_async_check() to make gcc happy
drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.
Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that plane, new_plane_state and
old_plane_state are initialized.
Explicitly initialize those variables to NULL to make gcc happy.
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update")
Cc:
Signed-off-by: Boris Brezillon
Reviewed-by: Sean Paul
---
Changes in v2:
- Cc stable
- Add Sean's R-b
- Fix a typo in the commit message
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f7ccfebd3ca8..80be74df7ba6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1538,8 +1538,9 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane *plane = NULL;
+ struct drm_plane_state *old_plane_state = NULL;
+ struct drm_plane_state *new_plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
int i, n_planes = 0;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
Async plane update is supposed to work only when updating the FB or FB
position of an already enabled plane. That does not apply to requests
where the plane was previously disabled or assigned to a different
CTRC.
Check old_plane_state->crtc value to make sure async plane update is
allowed.
Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane
update")
Cc:
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
---
Changes in v2:
- Cc stable
- Add Eric's R-b
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 866a2cc72ef6..f7ccfebd3ca8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1555,7 +1555,8 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
if (n_planes != 1)
return -EINVAL;
- if (!new_plane_state->crtc)
+ if (!new_plane_state->crtc ||
+ old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
funcs = plane->helper_private;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 --- Comment #33 from Alex Smith --- We've had several user reports of this through our support, and reproduced it internally as well (on a 270X, which is our officially supported minimum spec). Seems to be specific to SI cards. Given that this has regressed since the original release of the game, is it possible to get a workaround into Mesa, e.g. disabling the load/store vectorizer like suggested for SI cards (perhaps just restricted to Hitman), until the issue is resolved in LLVM? -- 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 107328] radeon_gart_table_vram_pin takes 473 ms during ACPI S3 resume
https://bugs.freedesktop.org/show_bug.cgi?id=107328 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Christian König --- (In reply to Paul Menzel from comment #2) > Just as a follow-up, the long time seems to have been caused by ftrace. > > With the patch below on top of drm-tip from this morning, it only takes 7 > ms. Interesting. I wasn't aware that ftrace could have such negative side effects. Anyway if somebody has a radeon in a box with halve a TB system memory he can probably live with a few ms resume time :) -- 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 09/10] drm/vc4: Use __drm_atomic_helper_plane_reset instead of copying the logic
On Tue, Jul 24, 2018 at 09:11:21AM +0100, Alexandru-Cosmin Gheorghe wrote: > Hi Maxime, > > On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote: > > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote: > > > Signed-off-by: Alexandru Gheorghe > > > --- > > > drivers/gpu/drm/vc4/vc4_plane.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c > > > b/drivers/gpu/drm/vc4/vc4_plane.c > > > index 9d7a36f148cf..688ad9bb0f08 100644 > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c > > > @@ -200,9 +200,7 @@ static void vc4_plane_reset(struct drm_plane *plane) > > > if (!vc4_state) > > > return; > > > > > > - plane->state = _state->base; > > > - plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE; > > > - vc4_state->base.plane = plane; > > > + __drm_atomic_helper_plane_reset(plane, _state->base); > > > > For vc4, rcar-du, atmel-hlcdc and sun4i, you're changing the reset > > value of alpha from DRM_BLEND_ALPHA_OPAQUE to > > plane->alpha_property->values[1]. > > plane->alpha_property->values[1] holds the max value for alpha, and > it's initialized by the core to DRM_BLEND_ALPHA_OPAQUE. > > > > > This might or might not be a good idea, but you should definitely > > explain why. > > Would a commit message suffice? Or do you have other ideas? Yes, that would be enough. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] Allwinner R40 HDMI refactoring
On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote: > Hi Maxime, > > Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard napisal(a): > > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote: > > > This series fixes several issues found in R40 HDMI patch series after > > > it was applied. Conversation can be found here: > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.htm > > > l > > > > > > Patches are based on latest linux-next (next-20180710) and are ordered > > > in such way that they don't break R40 HDMI at any time. Because of that > > > I suggest that whole series goes through drm-misc to preserve that order. > > > > > > I also tested those patches on H3 to make sure it doesn't break other > > > platforms. However, it would be nice to test for regressions also on > > > older SoCs (with DE1). > > > > > > Best regards, > > > Jernej > > > > Applied all patches but the patch 10, thanks! > > Maxime > > It seems that you forgot to merge some patches: > > [PATCH v2 12/18] drm/sun4i: tcon: Add another way for matching mixers with > tcon > [PATCH v2 13/18] drm/sun4i: tcon: Add support for R40 TCON > > Without them, R40 display pipeline can't work. > > Maybe they are in your spam folder? Thanks for telling me, I'm not quite sure what happened. I've applied them. Sorry, Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
Hey On request of Noralf, I picked up the patches and prepared v5. Works fine with Xorg, if configured according to: https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html If anyone knows how to make Xorg pick it up dynamically without such a static configuration, please let me know. Thanks David David Herrmann (7): x86/sysfb: add support for 64bit EFI lfb_base x86/sysfb: fix lfb_size calculation of/platform: expose of_platform_device_destroy() video: add generic framebuffer eviction drm: switch to sysfb_evict_conflicts() drm: add SimpleDRM driver drm/simpledrm: add fbdev fallback support ... Hi! I asked Noralf about this patch set recently, and he mentioned that this never made it any further than this patch series... Are there still any interest in getting this mainlined? Does the code exist in any repo anywhere? For my own part, this would be an awesome driver to have to resurrect some old hardware I have lying around... - Mads ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Use (struct drm_format_info) fields to determine if a format is yuv and multi planar or not.
On Mon, Jul 23, 2018 at 09:57:00AM +0100, Ayan Kumar Halder wrote: > We do not need sun4i_backend_format_is_packed_yuv422() / > sun4i_backend_format_is_planar_yuv() to determine if the format is yuv multi > planar > or not. (struct drm_format_info *)->is_yuv tells if the format is yuv or not. > And (struct drm_format_info *)->num_planes denotes the number of planes. > > This issue was identified during a review on a previous patch:- > https://lists.freedesktop.org/archives/dri-devel/2018-July/183840.html > > Signed-off-by: Ayan Kumar halder Applied, thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106707] [CI] igt@gem_exec_schedule@deep-* - fail - Failed assertion: __vgem_fence_signal(fd, fence) == 0
https://bugs.freedesktop.org/show_bug.cgi?id=106707 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Chris Wilson --- commit 2884f91dd6d7682ea738ef6f0943cc591643dda2 (HEAD, upstream/master) Author: Chris Wilson Date: Fri Jul 20 12:29:30 2018 +0100 igt/gem_exec_schedule: Trim deep runtime Time the runtime for emitting deep dependency tree, while keeping it full of umpteen thousand requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106707 Signed-off-by: Chris Wilson Reviewed-by: Katarzyna Dec -- 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
