I
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
> analogix_dp_enable/disable_psr(
..
URL:
<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 [i915]]
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
---
drive
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 "we
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 Linton
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 relia
t.h Daniel Vetter 2016-08-29 68 *
@count: number of valid properties, must be less than or equal to
a2511a55 include/drm/drm_mode_object.h Daniel Vetter 2016-08-29 69 *
DRM_OBJECT_MAX_PROPERTY.
:: The code at line 61 was first introduced by commit
:: 7520a277d97be6e8a8ec038bb5ed01f40d4f9aeb drm: Extract
drm_framebuffer.[hc]
:: TO: Daniel Vetter
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
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, a
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 o
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.
>>
>> L
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 ret
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 configuratio
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 4:
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 P
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 -> v3
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 ++
drivers/gpu/drm/bridg
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 changed
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]
http://processors.wiki.ti.com/index.ph
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
> ---
> .../bindings/display/bridge/ti,ths8135.
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 chan
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 to
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: Reje
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&action=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
> rota
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
> Cc
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
> > +++ b/dr
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 values
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 clien
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 e
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 th
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:
- Re
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) other
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.
>
> Signed-off
å¾æç 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.
> >
> > Suggested-
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 values
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()
> warn
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 t
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 Go
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 remove
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 ma
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:
> >
> > driv
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 only
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 kin
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
Signed-off
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 onl
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
> >> s
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 de
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 b/drivers/gpu/d
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 th
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 it.
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 4:
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 arch
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 combin
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 byteswa
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 12
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 a
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 c
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. Fort
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
>>> order
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 t
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 re
-)
>
> --
> 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ä
> Signed-off
--
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 output
DEFAULT_RATELIMIT_BURST); \
> > if (__ratelimit(&_rs)) \
> > - 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>
ware, it's up to you to make sure that the 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>
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/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, Daniel
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
wr
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 numbers
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:
git://anongit.freedesktop.org/git/drm-int
next 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. T
.
-- 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
