A recent cleanup removed the only user of the 'kms' variable in
msm_preclose(), causing a harmless compiler warning:
drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms'
[-Werror=unused-variable]
This removes the variable a
Use CMA helper drm_fbdev_cma_restore_mode to restore fbdev mode
in process which uses drm/kms dies.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/f
Disabling output polling before unloading the driver.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 182578d..f9227b7 10
Free fbdev CMA using drm_fbdev_cma_fini on unload. This fixes
a warning when unloading the driver:
WARNING: CPU: 0 PID: 164 at drivers/gpu/drm/drm_crtc.c:5930
drm_mode_config_cleanup+0x204/0x208
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 9 +
1 file chan
The driver uses different variable names for struct drm_device
across functions which is confusing. Stick to the more common
variable name dev. While at it, remove unnecessary if statement
in error handling.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 29 +
If the device tree property fsl,panel is missing, drm_panel_attach
is called with a NULL pointer as first argument. Having a panel is
basically mandatory since RGB is the only supported connector.
Check if a panel node has been found, return -ENODEV and cleanup
otherwise.
Signed-off-by: Stefan Agn
Disable the earlier attached panel on connector destroy.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index f586f1e..a07886f
Hi all,
This patchset fixes several issues around unloading/unbinding
the driver. There is still one WARNING when unloading the driver
while vblank interrupts are enabled. I am not sure what/who
should make sure that vblank interrupts get disabled before
unloading the driver:
root at colibri-vf:~
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/fcea8a3a/attachment-0001.html>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/5cf27a07/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/1b17aa51/attachment.html>
policy
> > to avoid static initializations to 0. (Note that this doesn't hold in
> > regular user applications, just the kernel.)
> >
> > -ilia
> > ___
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/ca9a9d2f/attachment.sig>
On Sat, Apr 16, 2016 at 2:07 AM, Vineet Gupta
wrote:
> On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
>
>> And now the question is how to force DRM subsystem or just that driver
>> to use whatever predefined (say via device tree) location in memory
>> for data buffer allocation.
>
> It se
On Sat, Apr 16, 2016 at 4:41 PM, Arnd Bergmann wrote:
> A recent cleanup removed the only user of the 'kms' variable in
> msm_preclose(), causing a harmless compiler warning:
>
> drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
> drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variab
On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.
It seems this is pretty easy to do with DT reserved-memory binding.
This was just a random thought process I was having last night, and
wondered if it was possible.
We have a scenario with OpenGL where certain APIs hand large amounts
of data from the user to the API and when you return from the API call
the user can then free/overwrite/do whatever they want with t
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/cff512c4/attachment.html>
17 matches
Mail list logo
