On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote:
> I honestly have no idea what the subtle differences between
> con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
> it looks like both vc->vc_display_fg and con_driver_map are protected
> by the console_lock, so pro
On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote:
> Simply because olpc never unregisters the damn thing. It also
> registers the framebuffer directly by poking around in fbdev
> core internals, so it's all around rather broken.
>
> Signed-off-by: Daniel Vetter
> Cc: Jens Frederich
On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote:
> this driver is pretty horrible from a design pov, and needs a complete
> overhaul. Concrete thing that annoys me is that it looks at
> registered_fb, which is an internal thing to fbmem.c and fbcon.c. And
> ofc it gets the lifetime ru
Dear All,
I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
platform running.
The board is connected to one LCD screen and one HDMI monitor.
It have DRM + Wayland setup for display.
Also, I noticed that it have two dri interface:
/dev/dri/card0
/dev/dri/card1
I am not very familiar
On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> Good work, nice cleanup all over.
>
> A few comments to a few patches - not something that warrant a
> new series to be posted as long as it is fixed before the patches are
> applied.
Hm yeah good idea, I'll add that
On Mon, May 27, 2019 at 09:08:58AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote:
> > I honestly have no idea what the subtle differences between
> > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
> > it looks like both vc->vc_di
On Mon, May 27, 2019 at 09:10:10AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote:
> > Simply because olpc never unregisters the damn thing. It also
> > registers the framebuffer directly by poking around in fbdev
> > core internals, so it's all around r
On Mon, May 27, 2019 at 09:11:26AM +0200, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote:
> > this driver is pretty horrible from a design pov, and needs a complete
> > overhaul. Concrete thing that annoys me is that it looks at
> > registered_fb, which is an i
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- legacy DRI1 ioctl, which is already neutered
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV htere is no distinction between primary and render
nodes, thus we can drop the token.
Note: authentication is required on a single ioctl, due to a bug in
userspace. The issue has
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Qiang Yu
Cc: l...@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: David Airlie
Cc: Daniel
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already neuter
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Tobias Jakobi
Si
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark
Cc: Sean Paul
Cc: freedr...@lists.freedesktop.org
Cc: David Airlie
Cc: Danie
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instances are:
- legacy DRI1 ioctls, which are already neuter
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Note: the outstanding DRM_AUTH instance is:
- (badly coped) legacy DRI1 ioctl, which is a no
From: Emil Velikov
Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
render node. A seemingly deliberate design decision.
Hence we can drop the DRM_AUTH all together (details in follow-up patch)
yet not all userspace checks if it's authenticated, but instead uses
uncommon
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/vgem/v
From: Emil Velikov
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
Cc: David Airlie
C
On Mon, 27 May 2019, Emil Velikov wrote:
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Note: the outstanding DRM_AUTH insta
Hi,
On 25/05/2019 17:56, Matteo Croce wrote:
On Sat, May 25, 2019 at 9:30 AM Hariprasad Kelam
wrote:
fix below warnings reported by coccicheck
Hi,
a similar patch was nacked because it makes backports more difficult:
https://lore.kernel.org/lkml/3dec4093-824e-b13d-d712-2dedd445a...@ti.co
On 2019/05/25, Thomas Hellstrom wrote:
> On Sat, 2019-05-25 at 00:39 +0200, Thomas Hellström wrote:
> > Hi, Emil
> >
> > On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> > > On 2019/05/24, Thomas Hellstrom wrote:
> > > > On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote:
> > > > > On 2
On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote:
> Drop use of the deprecated drmP.h header file.
>
> While touching the list of include files:
> - Divide include files in blocks of linux/* video/* drm/* etc.
> Be consistent in the order of the blocks
> - Sort individual blocks of include fi
Hi Emil,
19. 5. 27. 오후 5:17에 Emil Velikov 이(가) 쓴 글:
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
>>From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Inki Dae
> Cc: Jo
On Mon, May 27, 2019 at 12:41 PM Pintu Agarwal wrote:
>
> Dear All,
>
> I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
> platform running.
> The board is connected to one LCD screen and one HDMI monitor.
> It have DRM + Wayland setup for display.
> Also, I noticed that it have two
Print display controller hardware version in debug mode only.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/ltdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d24ffc2..16b1103 100644
--- a/drivers/gpu/d
Add power on & off optional physical operation functions, helpful to
program specific registers of the DSI physical part.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8
include/drm/bridge/dw_mipi_dsi.h | 2 ++
2 files changed, 10 insert
These patches fix a bug concerning an access issue to display controler (ltdc)
registers.
If the physical layer of the DSI is started too early then the fifo DSI are full
very quickly which implies ltdc register's access hang up. To avoid this
problem, it is necessary to start the DSI physical laye
These new physical operations are helpful to power_on/off the dsi
wrapper. If the dsi wrapper is powered in video mode, the display
controller (ltdc) register access will hang when DSI fifos are full.
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 21 ++
MTP SDM845 panel seems to need additional delay to bring panel
to a workable state. Running modetest without this change displays
blurry artifacts.
Signed-off-by: Vivek Gautam
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/pane
Am 27.05.19 um 10:17 schrieb Emil Velikov:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> yet not all userspace c
Hi,
On 23/05/2019 23:07, Sebastian Reichel wrote:
Hi,
Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv5. The patches are based
on v5.2-rc1 tag. It does not contain the patches required for
OMAP3 support (it needs a workaround for a hardware bug)
Am 24.05.19 um 23:34 schrieb Kuehling, Felix:
> On 2019-05-23 5:06 a.m., Christian König wrote:
>> [CAUTION: External Email]
>>
>> Leaving BOs on the LRU is harmless. We always did this for VM page table
>> and per VM BOs.
>>
>> The key point is that BOs which couldn't be reserved can't be evicted.
On Mon, May 27, 2019 at 11:11:18AM +0200, Linus Walleij wrote:
> On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote:
>
> > Drop use of the deprecated drmP.h header file.
> >
> > While touching the list of include files:
> > - Divide include files in blocks of linux/* video/* drm/* etc.
> > Be c
Thanks for the comments, but you are looking at a completely outdated
patchset.
If you are interested in the newest one please ping me and I'm going to
CC you when I send out the next version.
Christian.
Am 25.05.19 um 03:04 schrieb Hillf Danton:
On Tue, 16 Apr 2019 20:38:31 +0200 Christian
On 5/24/19 5:28 PM, Daniel Vetter wrote:
> Hi Daniel,
>
> On Fri, May 24, 2019 at 3:14 PM Daniel Thompson
> wrote:
>>
>> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote:
>>> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
>>>
>>> The justification is that if hw blanki
https://bugs.freedesktop.org/show_bug.cgi?id=107209
--- Comment #3 from vono ---
Same here on Fedora 30 with kernel 5.0.17-300.fc30.x86_64
[drm] DM_PPLIB: values for Invalid clock
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB: 0 in kHz
[drm] DM_PPLIB:
https://bugs.freedesktop.org/show_bug.cgi?id=107209
vono changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107296
vono changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #14 from vono -
Use drm_atomic_helper_check_plane_state()
to sanity check the plane state.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virti
Vikash,
As it's been quite a while, I want to know if the problem is solved
successfully If so, could you please shed some light on the problem
solving path?
Working on a custom hardware based on TI AM5728, and having the same
problem at hand, I just was curious if some one has been able to
* Tomi Valkeinen [190527 10:51]:
> Hi,
>
> On 23/05/2019 23:07, Sebastian Reichel wrote:
> > Hi,
> >
> > Here is another round of the DSI command mode panel patchset
> > integrating the feedback from PATCHv5. The patches are based
> > on v5.2-rc1 tag. It does not contain the patches required for
Hi, Emil,
On Mon, 2019-05-27 at 10:08 +0100, Emil Velikov wrote:
> On 2019/05/25, Thomas Hellstrom wrote:
> > On Sat, 2019-05-25 at 00:39 +0200, Thomas Hellström wrote:
> > > Hi, Emil
> > >
> > > On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> > > > On 2019/05/24, Thomas Hellstrom wrote:
Hi,
On Mon, May 27, 2019 at 10:24:02AM +0800, Shawn Guo wrote:
> On Wed, May 08, 2019 at 07:18:27PM +0200, Guido Günther wrote:
> > If somebody is working on DCSS support it'd be cool to know since this
>
> I have some time slots here and will start looking at it, if no one else
> is already worki
https://bugs.freedesktop.org/show_bug.cgi?id=110712
Haxk20 changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Product|DR
https://bugs.freedesktop.org/show_bug.cgi?id=110712
--- Comment #2 from Haxk20 ---
Moved the bug over to mesa as this is mesa bug. Sorry for reporting it
incorrectly the first time.
--
You are receiving this mail because:
You are the assignee for the bug.
On Mon, May 27, 2019 at 9:17 AM Daniel Vetter wrote:
>
> On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > Good work, nice cleanup all over.
> >
> > A few comments to a few patches - not something that warrant a
> > new series to be posted as long as it is fixed
Am 27.05.19 um 10:17 schrieb Emil Velikov:
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
On 2019/05/27, Jani Nikula wrote:
> On Mon, 27 May 2019, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary and render
> > nodes, thus we can drop t
On Tue, 16 Apr 2019 20:38:34 +0200 Christian König wrote:
> + /**
> + * @unpin_dma_buf:
> + *
> + * This is called by dma_buf_unpin and lets the exporter know that an
> + * importer doesn't need to the DMA-buf to stay were it is any more.
> + *
s/need to/need/ s/were/
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.c: In function
dpp_get_optimal_number_of_taps:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_dpp.c:137:11: warning:
variable pixel_width set but not used [-Wunused-but-set-variable]
It
fix below warning reported by coccicheck
./drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c:1364:3-5: WARNING:
possible condition with no effect (if == else)
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 8 +---
1 file changed, 1 insertion(+), 7 dele
From tho...@m3y3r.de Sun May 26 13:49:04 2019
Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated
To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch,
dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Mime-Version
VirtIO DRM driver crashes when setting specific 16.16 fixed-point
property values
When running a virtual machine with a VirtIO GPU, it's possible to
crash the entire VM by setting the value of a 16.16 fixed-point
property to any value below 65536 (1.0 in 16.16 format or 0x0001).
As a specific
On Tue, 16 Apr 2019 20:38:32 +0200 Christian König wrote:
> @@ -688,9 +689,9 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (attach->sgt)
> return attach->sgt;
>
> - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> -
Hi all,
I've a workstation which has internal VGA that is detected as AST 2400 and
with it EDID has been always quite flaky (except for some time it worked
with 4.14 long enough that I thought the problems would be past until the
problems reappeared also with 4.14). Thus, I've provided manually
fix below warnings reported by coccicheck
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c:1057:1-3:
WARNING: PTR_ERR_OR_ZERO can be used
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletion
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:1846:6:
warning: symbol 'deallocate_hiq_sdma_mqd' was not declared. Should it be
static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 ++-
1
From: Benjamin Gaignard
Restore calls to clk_{enable/disable} deleted after applying the wrong
version of the patch
Fixes: fd6905fca4f0 ("drm/stm: ltdc: remove clk_round_rate comment")
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/ltdc.c | 2 ++
1 file changed, 2 insertions(+)
dif
Hi all,
left over from my previous Teres-I device tree series, here comes
the revised anx6345 node for the Teres-I, along with the driver.
The innolux panel attached to it is already known; pinebooks can be
enabled on top of this series, once their panels are introduced.
Changes from the respecti
On Tue, 16 Apr 2019 20:38:35 +0200 Christian König wrote:
> @ -331,14 +282,19 @@ EXPORT_SYMBOL(drm_gem_map_dma_buf);
> * @sgt: scatterlist info of the buffer to unmap
> * @dir: direction of DMA transfer
> *
> - * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
> - *
asic_reg/nbio/nbio_6_1_offset.h is included twice.
Issue identified by includecheck
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_inc.h
b/drivers/gpu/drm/amd/pow
Hi Rob,
On Wed, 22 May 2019 at 21:27, Rob Herring wrote:
>
> On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote:
> >
> > Hi,
> >
> > The Allwinner H6 has a Mali-T720 MP2 which should be supported by
> > the new panfrost driver. This series fix two issues and introduce the
> > dt-bindings but a
Hi Nasser,
No, problem was not solved and I left it as priorities of my work changed.
Best Regards,
Vikash
On Mon, May 27, 2019 at 3:08 AM nasser afshin
wrote:
> Hi Vikash,
>
> As it's been quite a while, I want to know if the problem is solved
> successfully
> If so, could you please shed som
Quoting Sean Paul (2019-05-24 10:32:18)
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating the debug directory under /sys/kernel/debug/ and
> instead creates the directory under the correct node in
> /s
remove duplicate entry of soc15.h. Issue identified by includecheck
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index c763733..d723332 1
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can drop the DRM_AUTH all together
The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
Linux, with a matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree
bindings for that controller over to a YAML schemas.
Signed-off-by: Maxime Ripard
---
.../display/all
On 2019/05/27, Christian König wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if the authenticatio
Am 27.05.19 um 14:05 schrieb Emil Velikov:
> On 2019/05/27, Koenig, Christian wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
>>> render node. A seemingly deliberate design decision.
>>>
>>
Am 27.05.19 um 14:10 schrieb Emil Velikov:
> On 2019/05/27, Christian König wrote:
>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
>>> From: Emil Velikov
>>>
>>> There are cases (in mesa and applications) where one would open the
>>> primary node without properly authenticating the client.
>>>
>>> S
Hi Benjamin,
Many thanks for this fix (and more generally for pushing STM patches on
misc :-)
Acked-by: Philippe Cornu
Philippe :-)
On 5/27/19 1:58 PM, Benjamin Gaignard wrote:
> From: Benjamin Gaignard
>
> Restore calls to clk_{enable/disable} deleted after applying the wrong
> version of
Hi Yannick,
Thank you for your patch
Acked-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:14 PM, Yannick Fertré wrote:
> Print display controller hardware version in debug mode only.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/ltdc.c | 2 +-
> 1 file changed, 1 insertion(
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
> > I think we might be talking past each other, let's take a step back:
> >
> > - as of previous patch, all of vmwgfx ioctls size is consistently
> > handled by the core
>
> I don't think I follow you here, AFAICT patch 3/5 only affects and
>
On 5/27/19 10:17 AM, Emil Velikov wrote:
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
T
Hi Yannick,
and thank you for your patch.
Tested successfully on stm32f too.
Reviewed-by: Philippe Cornu
Tested-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:21 PM, Yannick Fertré wrote:
> Add power on & off optional physical operation functions, helpful to
> program specific registers of the
On 2019/05/27, Koenig, Christian wrote:
> Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > On 2019/05/27, Koenig, Christian wrote:
> >> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> >>> From: Emil Velikov
> >>>
> >>> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> >>> rende
Hi Yannick,
and thank you for your patch.
Tested successfully on stm32f too.
Acked-by: Philippe Cornu
Tested-by: Philippe Cornu
Philippe :-)
On 5/27/19 12:21 PM, Yannick Fertré wrote:
> These new physical operations are helpful to power_on/off the dsi
> wrapper. If the dsi wrapper is powered
On 2019/05/27, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't check if the authentication
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #8 from Nicholas Kazlauskas ---
Do you happen to know if this was a regression?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> ye
On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote:
> On 5/27/19 10:17 AM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > There are cases (in mesa and applications) where one would open the
> > primary node without properly authenticating the client.
> >
> > Sometimes we don't
On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can drop
On Mon, May 27, 2019 at 06:51:18AM +, james qian wang (Arm Technology
China) wrote:
> On Fri, May 24, 2019 at 03:12:26PM +0300, Ville Syrjälä wrote:
> > On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> > > Hi,
> > >
> > > On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wa
On Mon, May 27, 2019 at 01:52:05PM +0100, Emil Velikov wrote:
> On 2019/05/27, Koenig, Christian wrote:
> > Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > > On 2019/05/27, Koenig, Christian wrote:
> > >> Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > >>> From: Emil Velikov
> > >>>
> > >>> Currentl
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> > Am 27.05.19 um 10:17 schrieb Emil Velikov:
> > > From: Emil Velikov
> > >
> > > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > > render node. A seemingly delib
On Mon, May 27, 2019 at 3:26 PM Daniel Vetter wrote:
>
> On Mon, May 27, 2019 at 01:52:05PM +0100, Emil Velikov wrote:
> > On 2019/05/27, Koenig, Christian wrote:
> > > Am 27.05.19 um 14:05 schrieb Emil Velikov:
> > > > On 2019/05/27, Koenig, Christian wrote:
> > > >> Am 27.05.19 um 10:17 schrieb
Am Mittwoch, den 08.05.2019, 19:18 +0200 schrieb Guido Günther:
> Hi,
> On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found on
> > i.MX8
> > SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP core can a
Am 27.05.19 um 15:26 schrieb Emil Velikov:
> On 2019/05/27, Daniel Vetter wrote:
>> On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
>>> Am 27.05.19 um 10:17 schrieb Emil Velikov:
From: Emil Velikov
Currently one can circumvent DRM_AUTH, when the ioctl is exposed v
On 5/27/19 2:35 PM, Emil Velikov wrote:
Hi Thomas,
On 2019/05/27, Thomas Hellstrom wrote:
I think we might be talking past each other, let's take a step back:
- as of previous patch, all of vmwgfx ioctls size is consistently
handled by the core
I don't think I follow you here, AFAICT patch
The sii902x chip family supports also HDMI audio. Add binding for
describing the necessary i2s and mclk wiring for it.
Signed-off-by: Jyri Sarha
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/sii902x.txt | 40 +++
1 file changed, 40 insertions(+)
diff --git a/Do
Remove trailing white space from sii902x display bridge binding.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/d
I think these should be ready for applying to drm-misc.
Changes since v7:
- Debased on top of the lasts drm-misc-next and tested
- "dt-bindings: display: sii902x: Add HDMI audio bindings"
- Dropped off "or higher to avoid conflict with video ports"
and added "Reviewed-by: Rob Herring "
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
--
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/d
The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 5 +++--
1 file
Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sii902x.c |
On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at 09:17:29AM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> > render node. A seemingly deliberate design decision.
> >
> > Hence we can drop the DRM_A
1 - 100 of 167 matches
Mail list logo
