was looking for the flickering that this bug mentions.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/33e37f1e/attachment.html>
On 7 December 2016 at 11:51, Stefan Agner wrote:
> Hi Dave,
>
> On 2016-11-28 18:55, Stefan Agner wrote:
>> Hi Dave,
>>
>> Some fixes and cleanup, mainly around fbdev emulation. It also adds a
>> new module parameter which allows to specify the color depth/bpp for
>> the fbdev emulation (like the
On 12/07/2016 06:27 AM, zain wang wrote:
> We will ignored PSR setting if panel not support it. So, in this case, we
> should
> return from analogix_dp_enable/disable_psr() without any error code.
> Let's retrun 0 instead of -EINVAL when panel not support PSR in
>
L:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/3e5160f5/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/d10098d8/attachment.html>
On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
> It seems that there should be a better way to do it,
> but this works too.
In some cases there might be:
> --- a/drivers/s390/virtio/Makefile
> +++ b/drivers/s390/virtio/Makefile
> @@ -6,6 +6,8 @@
> Â # it under the terms of the GNU
Hi,
On 06/12/2016 19:49, Gustavo Padovan wrote:
> Hi Tvrtko,
>
> 2016-12-06 Tvrtko Ursulin :
>
>> From: Tvrtko Ursulin
>>
>> Driver prefix is a bit redundant in debug messages. If we choose
>> not to log it we change debug messages which used to look like this:
>>
>> [i915:edp_panel_off
Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.
I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Signed-off-by: Daniel Vetter
---
On Wed, 07 Dec 2016, Daniel Vetter wrote:
> Spotted while auditing our ioctl table. Also nuke the
> not-really-kerneldoc comments, we don't document internals and
> definitely don't want to mislead people with the old dragons.
Not just specific to this patch, but I'm not sure I agree with the
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
> That's right -- nouveau currently requires 4k page sizes to work. This is a
> software limitation, not a hardware one though.
Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>
>
> On Dec 1, 2016 5:13 PM, "Jeremy
Hello,
On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or
ubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/92bb6381/attachment.gz>
Hi Rob,
On Tuesday 06 Dec 2016 15:15:50 Rob Herring wrote:
> On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> > Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> > tree binding by itself but is meant to be referenced by platform device
> > tree bindings,
On 07/12/16 06:39 PM, Alexandre Courbot wrote:
> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>> software limitation, not a hardware one though.
>
> Looking at the trace I wonder - is the limitation in Nouveau
On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin wrote:
>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>> software limitation, not a hardware one though.
>>
>>
version 4:
- add documentation about drm_gem_cma_get_unmapped_area()
- introduce FB_PROVIDE_GET_FB_UNMAPPED_AREA configuration flag for
get_fb_unmapped_area()
- I have also send the first patch (https://lkml.org/lkml/2016/12/1/308) to
make dma_mmap_wc
works on ARM noMMU platform, assuming that
commit ab6494f0c96f ("nommu: Add noMMU support to the DMA API") have
add CONFIG_MMU compilation flag but that prohibit to use dma_mmap_wc()
when the platform doesn't have MMU.
This patch call vm_iomap_memory() in noMMU case to test if addresses
are correct and set wma->vm_flags rather than all
drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU.
Use a new DRM_VM to define when drm_vm.c in needed.
stub drm_legacy_vma_flush() to avoid compilation issues
version 4:
- a "config DRM_VM" in Kconfig
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/Kconfig | 5 +
Allow generic frame-buffer to provide a default
get_fb_unmapped_area function if specific devices need it.
Usually this function is defined in architecture directories but
define it here may limit code duplication especially for all ARM
platforms without MMU.
version 4:
- introdude a
Some SoC without MMU have display driver where a drm/kms driver
could be implemented.
Before doing such kind of thing drm/kms must allow to use mmuless devices.
This patch propose to remove MMU configuration flag and add a cma helper
function to help implementing mmuless display driver
version
On Tue, Dec 06, 2016 at 03:47:17PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Instead of dealing with crtc details inside drm_atomic.c we should
> just export a function that creates a new crtc fence for us and
> use that.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Gustavo
On Wed, Dec 07, 2016 at 11:28:54AM +0200, Jani Nikula wrote:
> On Wed, 07 Dec 2016, Daniel Vetter wrote:
> > Spotted while auditing our ioctl table. Also nuke the
> > not-really-kerneldoc comments, we don't document internals and
> > definitely don't want to mislead people with the old dragons.
>
On Wed, Dec 07, 2016 at 11:06:51AM +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add
On Tue, Dec 06, 2016 at 11:33:11AM +0200, Mikko Perttunen wrote:
>
>
> On 12/06/2016 09:14 AM, Daniel Vetter wrote:
> > On Mon, Dec 05, 2016 at 08:51:31PM +0100, Thierry Reding wrote:
> > > On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote:
> > > > This series adds IOMMU support to
2016-12-07 11:27 GMT+01:00 Daniel Vetter :
> On Wed, Dec 07, 2016 at 11:06:51AM +0100, Benjamin Gaignard wrote:
>> Some SoC without MMU have display driver where a drm/kms driver
>> could be implemented.
>>
>> Before doing such kind of thing drm/kms must allow to use mmuless devices.
>> This patch
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
v2 ->
The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
THS8135 is a configurable video DAC. Add DT bindings for this chip and
use the dumb-vga-dac driver for now as no configuration is required to
make it work.
Signed-off-by: Bartosz Golaszewski
---
.../bindings/display/bridge/ti,ths8135.txt | 52 ++
Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850-lcdk.dts | 67
1 file
At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.
Specify the max-pixelclock property for the display node for
da850-lcdk.
[1]
2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> THS8135 is a configurable video DAC. Add DT bindings for this chip and
> use the dumb-vga-dac driver for now as no configuration is required to
> make it work.
>
> Signed-off-by: Bartosz Golaszewski
> ---
>
Acked-by: Benjamin Gaignard
2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> When a plane is enabled, after having been disabled, do not reload XP70
> firmware again, but only register VTG again
>
> Signed-off-by: Fabien Dessenne
> ---
> drivers/gpu/drm/sti/sti_hqvdp.c | 8 ++--
> 1 file
Acked-by: Benjamin Gaignard
2016-12-05 16:09 GMT+01:00 Fabien Dessenne :
> Do not process update requests with unmodified parameters.
>
> Since the HQVDP command queue is limited to 2, we shall take care of
> not posting unneeded commands, which would abusively fill the command
> queue leading
The check to reject combinations of multiple rotation angles is overly
restrictive and has the side-effect of also failing any rotation value
which consists only of reflections.
Fix this by relaxing the check to ignore values which contain no
rotation flags.
Fixes: 6e0c7c3358d4 ("drm/atomic:
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.
Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
non-KMS driver")
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Exposing rb swapped (or other swizzled) formats for rendering would
involve swizzing in the pixel shader. This is not the case at the
moment, so reject requests for creating such surfaces.
(GPUs that need an extra resolve step anyway due to multiple pixel
pipes, such as gc2000, might also do this
https://bugzilla.kernel.org/show_bug.cgi?id=189451
--- Comment #3 from Raffaele ---
I have a new kernel and a new error message
Kernel 4.8.10-300.fc25.x86_64
New error message. This time UVD seems to be initialized fine, but there is
another error afterwards
[ 20.447459] [drm:uvd_v1_0_start
https://bugzilla.kernel.org/show_bug.cgi?id=189451
--- Comment #4 from Raffaele ---
Created attachment 247081
--> https://bugzilla.kernel.org/attachment.cgi?id=247081=edit
Second error message with 4.8.10
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Brian,
2016-12-07 Brian Starkey :
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
>
> Fix this by relaxing the check to ignore values which contain no
>
On Wed, Dec 07, 2016 at 02:13:23PM +0100, Daniel Vetter wrote:
> vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> fare similarly.
>
> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
> non-KMS driver")
> Cc: Michel Dänzer
> Cc: Alex Deucher
>
On Wed, Dec 07, 2016 at 07:25:51AM +0100, Johannes Berg wrote:
> On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote:
>
> > It seems that there should be a better way to do it,
> > but this works too.
>
> In some cases there might be:
>
> > --- a/drivers/s390/virtio/Makefile
> > +++
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
>
> Fix this by relaxing the check to ignore
On 05.12.2016 20:37, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:38PM +0200, Mikko Perttunen wrote:
>> Add a new IO virtual memory allocation API to allow clients to
>> allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
>> required e.g. for loading client firmware when
On 05.12.2016 20:39, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:39PM +0200, Mikko Perttunen wrote:
>> On 64-bit Tegras, buffer object memory allocation may
>> return memory above 4G that units behind Host1x cannot
>> access. Add the GFP_DMA flag to these allocation when
>> IOMMU is not
On 05.12.2016 21:13, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:40PM +0200, Mikko Perttunen wrote:
>> From: Arto Merilainen
>>
>> Add a set of falcon helper routines for use by the tegradrm client drivers
>> of the various falcon-based engines.
>>
>> The falcon is a microcontroller
We will ignored PSR setting if panel not support it. So, in this case, we should
return from analogix_dp_enable/disable_psr() without any error code.
Let's retrun 0 instead of -EINVAL when panel not support PSR in
analogix_dp_enable/disable_psr().
Signed-off-by: zain wang
---
Changes in v2:
-
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_cmd_transfer_to_host_2d expects x and y
> parameters in LE, but virtio_gpu_primary_plane_update
> passes in the CPU format instead.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++--
On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard
wrote:
> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
>> The panels shipped with Allwinner devices are very "generic", i.e.
>> they do not have model numbers or reliable sources of information
>> for the timings (that we know of)
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> When virtio_gpu_free_vbufs exits due to list empty, it does not
> drop the free_vbufs lock that it took.
> list empty is not expected to happen anyway, but it can't hurt to fix
> this and drop the lock.
>
> Signed-off-by: Michael S. Tsirkin
On 2016å¹´12æ06æ¥ 23:41, Michael S. Tsirkin wrote:
> __CHECK_ENDIAN__ isn't on by default presumably because
> it triggers too many sparse warnings for correct code.
> But virtio is now clean of these warnings, and
> we want to keep it this way - enable this for
> sparse builds.
>
>
å¾æç iPad å³é
> Thierry Reding æ¼ 2016å¹´12æ6æ¥ ä¸å11:46
> 寫éï¼
>
>> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
>> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
>> supported by the simple panel driver.
>>
>> Signed-off-by: Randy Li
>>
On 2016å¹´12æ06æ¥ 23:40, Michael S. Tsirkin wrote:
> virtio_gpu_queue_ctrl_buffer_locked is called with ctrlq.qlock taken, it
> releases and acquires this lock. This causes a sparse warning. Add
> appropriate annotations for sparse context checking.
>
> Signed-off-by: Michael S. Tsirkin
>
2016-12-07 Daniel Vetter :
> On Tue, Dec 06, 2016 at 03:47:17PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Instead of dealing with crtc details inside drm_atomic.c we should
> > just export a function that creates a new crtc fence for us and
> > use that.
> >
> >
On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> The check to reject combinations of multiple rotation angles is overly
> restrictive and has the side-effect of also failing any rotation value
> which consists only of reflections.
>
> Fix this by relaxing the check to ignore
On 12/06/16 15:28, Dan Carpenter wrote:
> Hello Jyri Sarha,
>
> The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> driver" from Oct 31, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/bridge/ti-tfp410.c:141 tfp410_get_connector_ddc()
>
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:45:11 Bartosz Golaszewski wrote:
> 2016-12-07 11:42 GMT+01:00 Bartosz Golaszewski :
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required
Hi Bartosz,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
> Add the vga-bridge node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz
2016-12-07 15:25 GMT+01:00 Laurent Pinchart :
> Hi Bartosz,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:42:44 Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>>
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:50 Benjamin Gaignard wrote:
> drm_vm.c functions are only need for DRM_LEGACY and DRM_NOUVEAU.
> Use a new DRM_VM to define when drm_vm.c in needed.
>
> stub drm_legacy_vma_flush() to avoid compilation issues
>
> version 4:
>
Hi Benjamin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> Allow generic frame-buffer to provide a default
> get_fb_unmapped_area function if specific devices need it.
>
> Usually this function is defined in architecture directories but
> define it here
On Wed, Dec 07, 2016 at 04:20:34PM +0200, Jyri Sarha wrote:
> On 12/06/16 15:28, Dan Carpenter wrote:
> > Hello Jyri Sarha,
> >
> > The patch dc55ac3b52e6: "drm/bridge: Add ti-tfp410 DVI transmitter
> > driver" from Oct 31, 2016, leads to the following static checker
> > warning:
> >
> >
On Wed, Dec 07, 2016 at 04:12:07PM +0200, Ville Syrjälä wrote:
>On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
>> The check to reject combinations of multiple rotation angles is overly
>> restrictive and has the side-effect of also failing any rotation value
>> which consists
On Wed, Dec 07, 2016 at 04:32:44PM +0200, Laurent Pinchart wrote:
> Hi Benjamin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:06:51 Benjamin Gaignard wrote:
> > Some SoC without MMU have display driver where a drm/kms driver
> > could be implemented.
> >
> > Before doing such
vgem (and our igt tests using vgem) need this. I suspect etnaviv will
fare similarly.
v2. Make it build. Oops.
Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
non-KMS driver")
Cc: Michel Dänzer
Cc: Alex Deucher
Cc: Chris Wilson
Reviewed-by: Chris Wilson
On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > The check to reject combinations of multiple rotation angles is overly
> > restrictive and has the side-effect of also failing any rotation value
> > which consists
On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
>
>
> å¾æç iPad å³é
>
> > Thierry Reding æ¼ 2016å¹´12æ6æ¥
> > ä¸å11:46 寫éï¼
> >
> >> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> >> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> >>
2016-12-07 15:35 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch.
>
> On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
>> Allow generic frame-buffer to provide a default
>> get_fb_unmapped_area function if specific devices need it.
>>
>> Usually this function is
On Mon, 5 Dec 2016 17:50:13 -0800
Florian Fainelli wrote:
> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
> >
> > Signed-off-by: Boris Brezillon
> > ---
>
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c
On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > The check to reject combinations of multiple rotation angles is overly
> > > restrictive and has
Hi Benjamin,
On Wednesday 07 Dec 2016 15:57:49 Benjamin Gaignard wrote:
> 2016-12-07 15:35 GMT+01:00 Laurent Pinchart:
> > On Wednesday 07 Dec 2016 11:06:49 Benjamin Gaignard wrote:
> >> Allow generic frame-buffer to provide a default
> >> get_fb_unmapped_area function if specific devices need
Some SoC without MMU have display driver where a drm/kms driver
could be implemented.
Before doing such kind of thing drm/kms must allow to use mmuless devices.
This patch propose to remove MMU configuration flag and add a cma helper
function to help implementing mmuless display driver
version
Hi Thomas,
in commit 59bd00c8 (Blackfin: fix framebuffer mmap bug for nommu) you
have introduce
get_fb_unmapped_area() for blackfin architecture.
I'm proposing a patch to have a default function in fbmem which
slightly does the same.
Do you think is new function could also fit with blackfin
Under a big-endian kernel, colours on the framebuffer all come out a
delightful shade of wrong, since we fail to take the reversed byte
order into account. Fortunately, the HDLCD has a control bit to make it
automatically byteswap big-endian data; let's use it as appropriate.
Signed-off-by: Robin
On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > On Wed, Dec 07, 2016 at 12:18:19PM +, Brian Starkey wrote:
> > > > The check to reject
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong, since we fail to take the reversed byte
> order into account. Fortunately, the HDLCD has a control bit to make it
> automatically
On Wed, Dec 07, 2016 at 04:54:40PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 05:13:24PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 07, 2016 at 03:52:29PM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 07, 2016 at 01:32:57PM +, Chris Wilson wrote:
> > > > On Wed, Dec 07, 2016 at
On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> Under a big-endian kernel, colours on the framebuffer all come out a
> delightful shade of wrong,
So you are saying that wrong is only a 1 bit value?
> since we fail to take the reversed byte
> order into account. Fortunately, the
On Wednesday, 2016-12-07 16:19:52 +0100, Benjamin Gaignard wrote:
> Some SoC without MMU have display driver where a drm/kms driver
> could be implemented.
>
> Before doing such kind of thing drm/kms must allow to use mmuless devices.
> This patch propose to remove MMU configuration flag and add
On 07/12/16 15:57, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>> Under a big-endian kernel, colours on the framebuffer all come out a
>> delightful shade of wrong, since we fail to take the reversed byte
>> order into account. Fortunately, the HDLCD has a
On Wed, Dec 07, 2016 at 04:57:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
> > Under a big-endian kernel, colours on the framebuffer all come out a
> > delightful shade of wrong, since we fail to take the reversed byte
> > order into account.
On 6 December 2016 at 05:12, Jonathan Gray wrote:
> On Mon, Dec 05, 2016 at 05:56:40PM +, Emil Velikov wrote:
>> On 1 December 2016 at 04:18, Jonathan Gray wrote:
>> > DRI devices on OpenBSD are not in their own directory. They reside in
>> > /dev with a large number of statically generated
On 07/12/16 16:42, Robin Murphy wrote:
> On 07/12/16 15:57, Daniel Vetter wrote:
>> On Wed, Dec 07, 2016 at 03:31:40PM +, Robin Murphy wrote:
>>> Under a big-endian kernel, colours on the framebuffer all come out a
>>> delightful shade of wrong, since we fail to take the reversed byte
>>>
Hi Dave,
If it's not too late, one last regression fix for amdgpu.
The following changes since commit ab7cd8d83e5dba13027de66f1b008b08b30b71a4:
Merge tag 'drm-intel-fixes-2016-12-01' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-04 06:31:26
+1000)
are available in
On Fri, Dec 02, 2016 at 04:01:28PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>
> Until commit b1cb1bd29189 ("drm/i915/dsi: update
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/4fb87cc8/attachment-0001.html>
On Thu, Dec 01, 2016 at 09:29:09PM +0100, Hans de Goede wrote:
> Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
>
> Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
> Cc: stable at vger.kernel.org
> Cc: Jani Nikula
> Cc: Ville Syrjälä
>
-
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/3596769f/attachment.html>
This is still missing corresponding documentation changes, and I haven't
moved anything to drm_print.h yet, as suggested.
Sending out with a few functional improvements first to get agreement
before documenting anything (changes summarised in v2: section below)
In particular, affecting the
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_ ## level, \
> > -__func__, "", fmt, ##args); \
> > + _DRM_DEBUG(DRM_UT_ ## category, fmt, ##args); \
> > })
> >
> > /**
> > @@ -268,21 +313,24 @@ struct dma_buf_attachment;
> > * \param arg arguments
> > */
> > #define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, args...) \
> > - DEV__DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
> > #define DRM_DEBUG_RATELIMITED(fmt, args...) \
> > - DRM_DEV_DEBUG_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRIVER, fmt, ##args)
> > #define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...) \
> > - DRM_DEV_DEBUG_DRIVER_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEV_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, KMS, fmt, ##args)
> > #define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
> \
> > - DRM_DEV_DEBUG_KMS_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
> > +
> > #define DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, args...) \
> > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, PRIME, fmt, ##args)
> > #define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...)\
> > - DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##args)
> > + _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
> >
> > /* Format strings and argument splitters to simplify printing
> > * various "complex" objects
>
> Since I brought up some changes for the debug stuff itself, would it make
> sense to split that from the general macro rework for all the non-debug
> output, and merge that first?
>
> Another thing to look into: I think it'd be good to move all the print
> definitions into drm_print.[hc], since drmP.h is a mess, and drm_drv.c not
> really the right place. That would then also allow us to easily document
> all the variants, and put something like the intro message for this commit
> into the overview DOC: section.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ff4a879d/attachment-0001.html>
he panel's
mode actually scans out successfully. Then, since compatible strings
are cheap, you can use a new one if necessary to attach better modes to
the panel for a particular clock driver by adjusting your timings to get
closer to the refresh rates you want.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/d2a9b314/attachment.sig>
hment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/ac9e00a2/attachment.sig>
On Tue, 06 Dec 2016, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote:
>> On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote:
>> > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
>> > > On Mon, Dec 05, 2016 at 09:16:27AM +0100,
On 2016-12-06 04:36, Marek Vasut wrote:
> On 12/06/2016 08:53 AM, Daniel Vetter wrote:
>> On Tue, Dec 06, 2016 at 11:08:06AM +1000, Dave Airlie wrote:
>>> On 2 December 2016 at 04:02, Marek Vasut wrote:
Hi,
as asked by Daniel, I collected the MXSFB DT Acks and the driver and
Hi Eric,
On Wednesday 07 Dec 2016 11:16:32 Eric Anholt wrote:
> Maxime Ripard writes:
> > [ Unknown signature status ]
> >
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model
Hi Dave, first set of fixes for drm-next/v4.10-rc1.
BR,
Jani.
The following changes since commit e9cbc4bd0140e1d4e0172e2fe8fe07ba278e5980:
drm/i915: Update DRIVER_DATE to 20161121 (2016-11-21 09:45:03 +0100)
are available in the git repository at:
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/521adfc8/attachment.html>
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin
>>> wrote:
That's right -- nouveau currently requires 4k page sizes to work.
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161207/e22b1e1e/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161207/b9b4e43a/attachment.html>
1 - 100 of 130 matches
Mail list logo
