Hi Tony, Thierry, Laurent,
Any thoughts on the below points?
I think yet another option is to write some omap boot time quirks code, which looks at the DT data,
and changes the panel compatible string (for 1), and removes the timings node (for 2).
Tomi
On 14/11/2019 11:39, Tomi Valkeinen wr
On Tue, Nov 19, 2019 at 04:18:15PM +0100, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> interme
On Tue, 19 Nov 2019, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where the
On Fri, Nov 15, 2019 at 10:27:04PM +0800, zhengbin wrote:
> zhengbin (3):
> drm/gma500: remove set but not used variable 'htotal'
> drm/gma500: remove set but not used variable 'error'
> drm/gma500: remove set but not used variable 'is_hdmi','is_crt'
All three applied, thanks for the patches
On 2019-11-08 03:34, Daniel Vetter wrote:
On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
Fuzzers used in Android compliance testing repeatedly call the
create blob IOCTL which eventually exhausts the system memory.
This series adds a hook which allows drivers to impose their own
li
On Sat, Nov 9, 2019 at 1:01 AM wrote:
>
> On 2019-11-08 03:34, Daniel Vetter wrote:
> > On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
> >> Fuzzers used in Android compliance testing repeatedly call the
> >> create blob IOCTL which eventually exhausts the system memory.
> >> This ser
On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
> Fuzzers used in Android compliance testing repeatedly call the
> create blob IOCTL which eventually exhausts the system memory.
> This series adds a hook which allows drivers to impose their own
> limitations on the size and/or number o
On Mon, Nov 04, 2019 at 06:23:19PM -0800, Jamal Shareef wrote:
> This patchset removes spaces after left open parenthesis.
> Issue found by checkpatch.
I'd say that those spaces make code easier to look at, so it would
be better to teach checkpatch to ignore cases like these.
Best Regards,
Michał
On Tue, 2019-11-05 at 05:53 +0100, Michał Mirosław wrote:
> On Mon, Nov 04, 2019 at 06:23:19PM -0800, Jamal Shareef wrote:
> > This patchset removes spaces after left open parenthesis.
> > Issue found by checkpatch.
>
> I'd say that those spaces make code easier to look at, so it would
> be better
ping
On 2019/10/9 14:25, zhengbin wrote:
> zhengbin (3):
> drm/amd/display: Remove set but not used variables
> 'bl_pwm_cntl','pwm_period_cntl'
> drm/amd/display: Remove set but not used variable 'value0'
> drm/amd/display: Remove set but not used variables 'regval','speakers'
>
> drive
Hi Zheng,
Harry's previous comment about the superfluous REG_READ()s is still unaddressed.
Once that's fixed, I can give my r-b.
Thanks,
Leo
On 2019-10-28 5:32 a.m., zhengbin (A) wrote:
> ping
>
> On 2019/10/9 14:25, zhengbin wrote:
>> zhengbin (3):
>> drm/amd/display: Remove set but not use
Hi
Am 28.10.19 um 13:06 schrieb Hans de Goede:
> Hi,
>
> On 28-10-2019 12:34, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.10.19 um 12:26 schrieb Hans de Goede:
>>> Hi Thomas,
>>>
>>> On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev
>
Hi,
On 28-10-2019 12:34, Thomas Zimmermann wrote:
Hi
Am 28.10.19 um 12:26 schrieb Hans de Goede:
Hi Thomas,
On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.
Al
Hi
Am 28.10.19 um 12:26 schrieb Hans de Goede:
> Hi Thomas,
>
> On 11-10-2019 15:48, Thomas Zimmermann wrote:
>> The vboxvideo driver provides its own implementation for fbdev emulation
>> and framebuffers. Both can be replaced by DRM's generic code.
>>
>> All patches have been tested on VirtualB
Hi Thomas,
On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.
All patches have been tested on VirtualBox 6.0.12.
Thomas Zimmermann (3):
drm/vboxvideo: Switch to
(cc: Gerd)
Am 28.10.19 um 09:45 schrieb Thomas Zimmermann:
> Udl's GEM implementation is mostly SHMEM and we should attempt to
> replace it with the latter.
>
> Patches #1 and #2 update udl to simplify the conversion. In patch #3
> the udl code is being replaced by SHMEM. The GEM object's mmap()
Hi
Am 12.10.19 um 14:36 schrieb Sam Ravnborg:
Hi Thomas.
On Fri, Oct 11, 2019 at 03:48:05PM +0200, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.
All patches have been tested on Vi
Hi Thomas.
On Fri, Oct 11, 2019 at 03:48:05PM +0200, Thomas Zimmermann wrote:
> The vboxvideo driver provides its own implementation for fbdev emulation
> and framebuffers. Both can be replaced by DRM's generic code.
>
> All patches have been tested on VirtualBox 6.0.12.
>
> Thomas Zimmermann (3
Thanks for the patches.
I think for all of them we should just drop the REG_READ calls
completely. They look like leftovers from when we had a different
register update scheme that would read the register, then update or get
the field value. Now we just use the REG_ macros that will combine the
re
在 2019-10-02三的 12:36 +0200，Maxime Ripard写道：
> Hi,
>
> On Tue, Oct 01, 2019 at 04:02:50PM +0800, Icenowy Zheng wrote:
> > This patchset fixes some portion of timing calculation in
> > sun6i_mipi_dsi
> > driver according to the BSP driver.
> >
> > Two of the patches are reverting, one is fixing som
Hi,
On Tue, Oct 01, 2019 at 04:02:50PM +0800, Icenowy Zheng wrote:
> This patchset fixes some portion of timing calculation in sun6i_mipi_dsi
> driver according to the BSP driver.
>
> Two of the patches are reverting, one is fixing some misread of the BSP
> source code, another is fixing a wrong r
On Fri, Sep 13, 2019 at 06:27:00PM -0400, Lyude Paul wrote:
> Some random issues with documentation that I noticed while working on
> nouveau the other day. There are no functional changes in this series.
Nice! On all three:
Reviewed-by: Daniel Vetter
>
> Lyude Paul (3):
> drm/encoder: Fix
On Wed, Sep 11, 2019 at 02:03:49PM +0200, Thomas Zimmermann wrote:
> The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
> reimplementing vmap(). We can share some code by using the respective
> functionality from GEM VRAM buffer objects.
>
> Thomas Zimmermann (3):
> drm/vra
ping for a review
Am 11.09.19 um 14:03 schrieb Thomas Zimmermann:
> The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
> reimplementing vmap(). We can share some code by using the respective
> functionality from GEM VRAM buffer objects.
>
> Thomas Zimmermann (3):
> drm/vra
Hi Jitao,
On Thu, Sep 12, 2019 at 5:04 PM Jitao Shi wrote:
>
> Add driver to support panel innolux,p097pfg with bridge ssd2858.
> SSD2858 can spilt dsi 4 lanes to 8 lanes.
>
> Jitao Shi (3):
> drm/panel: panel-innolux: Allow 2 reset pins for panel
> dt-bindings: display: Add documentation for
FYI this is actually version 3 of the patch set posted at
[1] and [2]
[1] https://lists.freedesktop.org/archives/dri-devel/2019-July/227823.html
[2] https://lists.freedesktop.org/archives/dri-devel/2019-July/228074.html
Am 11.09.19 um 14:03 schrieb Thomas Zimmermann:
> The ast and mgag200 drivers
On Wed, Aug 21, 2019 at 12:24 PM Heiko Stuebner wrote:
>
> Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> > This series converts the various Arm Mali GPU bindings to use the DT
> > schema format.
> >
> > The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
>
Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> This series converts the various Arm Mali GPU bindings to use the DT
> schema format.
>
> The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
> because there's all different ordering. The Utgard binding generate
Hi Rob,
On Tue, Aug 20, 2019 at 02:59:56PM -0500, Rob Herring wrote:
> This series converts the various Arm Mali GPU bindings to use the DT
> schema format.
>
> The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
> because there's all different ordering. The Utgard binding gene
Hi,
On 20/08/2019 21:59, Rob Herring wrote:
> This series converts the various Arm Mali GPU bindings to use the DT
> schema format.
>
> The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
> because there's all different ordering. The Utgard binding generates
> warnings on Roc
On Mon, Aug 19, 2019 at 6:48 PM John Stultz wrote:
>
> Peter sent a patchset out back in April to enable Lima support
> on HiKey, but there's not been much action on it since since.
>
> I've been carrying the patchset in my tree, and figured I'd send
> out just these three dt-bindings changes just
Den 25.07.2019 12.51, skrev Noralf Trønnes:
> This is the final polish on tinydrm turning it into _the_ place for tiny
> DRM drivers.
>
> Noralf.
>
> Noralf Trønnes (3):
> drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM
> drm/tinydrm: Rename folder to tiny
> drm/gm12u320: Move driver t
Hi Sam,
On Fri, Jul 26, 2019 at 12:25:29PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Jul 26, 2019 at 11:21:40AM +0200, Guido Günther wrote:
> > If the panel is wrapped in a panel_bridge it gets prepar()ed before the
> > upstream DSI bridge which can cause hangs (e.g. with imx-nwl since cl
Hi Guido.
On Fri, Jul 26, 2019 at 11:21:40AM +0200, Guido Günther wrote:
> If the panel is wrapped in a panel_bridge it gets prepar()ed before the
> upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
> are not enabled yet). To avoid this move the panel's first DSI access to
Hi Noralf.
On Thu, Jul 25, 2019 at 02:46:08PM +0200, Noralf Trønnes wrote:
>
>
> Den 25.07.2019 14.06, skrev Daniel Vetter:
> > On Thu, Jul 25, 2019 at 12:51:29PM +0200, Noralf Trønnes wrote:
> >> This is the final polish on tinydrm turning it into _the_ place for tiny
> >> DRM drivers.
> >>
> >
Den 25.07.2019 14.06, skrev Daniel Vetter:
> On Thu, Jul 25, 2019 at 12:51:29PM +0200, Noralf Trønnes wrote:
>> This is the final polish on tinydrm turning it into _the_ place for tiny
>> DRM drivers.
>>
>> Noralf.
>>
>> Noralf Trønnes (3):
>> drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM
On Thu, Jul 25, 2019 at 12:51:29PM +0200, Noralf Trønnes wrote:
> This is the final polish on tinydrm turning it into _the_ place for tiny
> DRM drivers.
>
> Noralf.
>
> Noralf Trønnes (3):
> drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM
> drm/tinydrm: Rename folder to tiny
> drm/gm12u
On Wed, 2019-07-24 at 13:28 +0100, Linus Walleij wrote:
> On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg wrote:
> > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > Do we need to support arm,pl11x,tft-r0g0b0-pads before
> > we can obsolete fbdev stuff?
>
> No I don't think so, the
On Wed, Jul 24, 2019 at 2:47 PM Pawel Moll wrote:
> On Wed, 2019-07-24 at 13:28 +0100, Linus Walleij wrote:
> > On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg wrote:
> > > On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > > Do we need to support arm,pl11x,tft-r0g0b0-pads before
> >
On Tue, Jul 23, 2019 at 8:10 PM Sam Ravnborg wrote:
> On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> > So this is a cold-coded attempt to move the TI nspire over to
> > using DRM. It is more or less the last user of the old fbdev
> > driver so it is a noble cause and interesting
Am 23.07.19 um 10:40 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, Jul 23, 2019 at 09:54:22AM +0200, Thomas Zimmermann wrote:
>> This patch set fixes a number of bugs that where introduced by the
>> recent changes to mgag200's handling of cursor BOs.
>>
>> Thomas Zimmermann (3):
>> drm/mgag200:
Hi Linus.
On Tue, Jul 23, 2019 at 03:37:52PM +0200, Linus Walleij wrote:
> So this is a cold-coded attempt to move the TI nspire over to
> using DRM. It is more or less the last user of the old fbdev
> driver so it is a noble cause and interesting usecase.
Do we need to support arm,pl11x,tft-r0g0
Hi Thomas.
On Tue, Jul 23, 2019 at 09:54:22AM +0200, Thomas Zimmermann wrote:
> This patch set fixes a number of bugs that where introduced by the
> recent changes to mgag200's handling of cursor BOs.
>
> Thomas Zimmermann (3):
> drm/mgag200: Pin displayed cursor BO to video memory
> drm/mgag
Dne sobota, 20. julij 2019 ob 07:42:55 CEST je Maxime Ripard napisal(a):
> On Sat, Jul 13, 2019 at 02:03:43PM +0200, Jernej Skrabec wrote:
> > In order to correctly convert image between YUV and RGB, you have to
> > know color encoding and color range. This patch set adds appropriate
> > properties
On Sat, Jul 13, 2019 at 02:03:43PM +0200, Jernej Skrabec wrote:
> In order to correctly convert image between YUV and RGB, you have to
> know color encoding and color range. This patch set adds appropriate
> properties and considers them when choosing CSC conversion matrix for
> DE2 and DE3.
>
> No
On 02.07.2019 17:44, Rob Clark wrote:
> From: Rob Clark
>
> In process of debugging panel on my lenovo yoga c630, I noticed some
> errors in the dsi->mode_flags, which I guess were just cargo-cult'd?
>
> Since dumping the status regs was useful to notice this problem, I
> cleaned it up and turned
On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> to the memory manager. Now, unused BOs are only evicted when the space
> is required.
>
> The lock/unlock-renaming patch aligns the interface with other nam
On Tue, May 21, 2019 at 02:40:22PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> > Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> > to the memory manager. Now, unused BOs are only evicted when the space
> > is required.
On Tue, May 21, 2019 at 4:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> > On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> >> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> >> to the memory manager. Now, unused
Hi
Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
>> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
>> to the memory manager. Now, unused BOs are only evicted when the space
>> is required.
>>
>> The lock/unl
On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> to the memory manager. Now, unused BOs are only evicted when the space
> is required.
>
> The lock/unlock-renaming patch aligns the interface with other nam
On 13/05/2019 14:39, Boris Brezillon wrote:
> On Mon, 13 May 2019 13:48:08 +0100
> Steven Price wrote:
>
>> On 12/05/2019 14:38, Boris Brezillon wrote:
>>> On Sat, 11 May 2019 15:32:20 -0700
>>> Alyssa Rosenzweig wrote:
>>>
Hi all,
As Steven Price explained, the "GPU top" kbase
> This being said, I think I'll go for a simple debugfs-based iface to
> unblock Alyssa. debugfs is not part of the stable-ABI and I guess we
> can agree on explicitly marking it as "unstable" so that when we settle
> on a generic interface to expose such counters we can get rid of the
> old one.
On 12/05/2019 14:38, Boris Brezillon wrote:
> On Sat, 11 May 2019 15:32:20 -0700
> Alyssa Rosenzweig wrote:
>
>> Hi all,
>>
>> As Steven Price explained, the "GPU top" kbase approach is often more
>> useful and accurate than per-draw timing.
>>
>> For a 3D game inside a GPU-accelerated desktop,
On Sun, May 12, 2019 at 03:40:26PM +0200, Boris Brezillon wrote:
> On Tue, 30 Apr 2019 09:49:51 -0600
> Jordan Crouse wrote:
>
> > On Tue, Apr 30, 2019 at 06:10:53AM -0700, Rob Clark wrote:
> > > On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
> > > wrote:
> > > >
> > > > +Rob, Eric, Mark and
On Mon, 13 May 2019 13:48:08 +0100
Steven Price wrote:
> On 12/05/2019 14:38, Boris Brezillon wrote:
> > On Sat, 11 May 2019 15:32:20 -0700
> > Alyssa Rosenzweig wrote:
> >
> >> Hi all,
> >>
> >> As Steven Price explained, the "GPU top" kbase approach is often more
> >> useful and accurate th
Hi all,
As Steven Price explained, the "GPU top" kbase approach is often more
useful and accurate than per-draw timing.
For a 3D game inside a GPU-accelerated desktop, the games' counters
*should* include desktop overhead. This external overhead does affect
the game's performance, especially if
On Tue, 30 Apr 2019 09:49:51 -0600
Jordan Crouse wrote:
> On Tue, Apr 30, 2019 at 06:10:53AM -0700, Rob Clark wrote:
> > On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
> > wrote:
> > >
> > > +Rob, Eric, Mark and more
> > >
> > > Hi,
> > >
> > > On Fri, 5 Apr 2019 16:20:45 +0100
> > > Steven P
On Sat, 11 May 2019 15:32:20 -0700
Alyssa Rosenzweig wrote:
> Hi all,
>
> As Steven Price explained, the "GPU top" kbase approach is often more
> useful and accurate than per-draw timing.
>
> For a 3D game inside a GPU-accelerated desktop, the games' counters
> *should* include desktop overhea
On Wed, 01 May 2019 10:12:42 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > +Rob, Eric, Mark and more
> >
> > Hi,
> >
> > On Fri, 5 Apr 2019 16:20:45 +0100
> > Steven Price wrote:
> >
> >> On 04/04/2019 16:20, Boris Brezillon wrote:
> >> > Hello,
> >> >
> >> > This patch adds ne
Boris Brezillon writes:
> +Rob, Eric, Mark and more
>
> Hi,
>
> On Fri, 5 Apr 2019 16:20:45 +0100
> Steven Price wrote:
>
>> On 04/04/2019 16:20, Boris Brezillon wrote:
>> > Hello,
>> >
>> > This patch adds new ioctls to expose GPU counters to userspace.
>> > These will be used by the mesa driv
On Tue, Apr 30, 2019 at 06:10:53AM -0700, Rob Clark wrote:
> On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
> wrote:
> >
> > +Rob, Eric, Mark and more
> >
> > Hi,
> >
> > On Fri, 5 Apr 2019 16:20:45 +0100
> > Steven Price wrote:
> >
> > > On 04/04/2019 16:20, Boris Brezillon wrote:
> > > > Hello
On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
wrote:
>
> +Rob, Eric, Mark and more
>
> Hi,
>
> On Fri, 5 Apr 2019 16:20:45 +0100
> Steven Price wrote:
>
> > On 04/04/2019 16:20, Boris Brezillon wrote:
> > > Hello,
> > >
> > > This patch adds new ioctls to expose GPU counters to userspace.
> > >
+Rob, Eric, Mark and more
Hi,
On Fri, 5 Apr 2019 16:20:45 +0100
Steven Price wrote:
> On 04/04/2019 16:20, Boris Brezillon wrote:
> > Hello,
> >
> > This patch adds new ioctls to expose GPU counters to userspace.
> > These will be used by the mesa driver (should be posted soon).
> >
> > A few
On Thu, Apr 18, 2019 at 03:27:24PM +0200, Paul Kocialkowski wrote:
> This series brings-in some fixes that are necessary to be able to
> remove the driver at run-time (when built as a module) and properly
> re-probe it afterwards.
Applied all three, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedde
Neil Armstrong writes:
> On 13/03/2019 15:10, Neil Armstrong wrote:
>> This patchset adds the G12A specific bindings for the Display VPU
>> and VPU Power Control.
>>
>> The Amlogic Meson G12A Display module is based on the Meson GXM SoC
>> with an updated Plane Blender, thus VPU architecture and
On 13/03/2019 15:10, Neil Armstrong wrote:
> This patchset adds the G12A specific bindings for the Display VPU
> and VPU Power Control.
>
> The Amlogic Meson G12A Display module is based on the Meson GXM SoC
> with an updated Plane Blender, thus VPU architecture and interconnect
> is the same.
>
On 04/04/2019 16:20, Boris Brezillon wrote:
> Hello,
>
> This patch adds new ioctls to expose GPU counters to userspace.
> These will be used by the mesa driver (should be posted soon).
>
> A few words about the implementation: I followed the VC4/Etnaviv model
> where perf counters are retrieved
+1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Since one of the primary use cases is to draw pretty graphs of the
> system load [1], this "per-job" information isn't all that relevant (and
> minimal performance overhead is important). And if you want to monitor
> just one application it is usually easiest to ensure that it is the only
> thing
On Fri, 5 Apr 2019 09:33:55 -0700
Alyssa Rosenzweig wrote:
> > Since one of the primary use cases is to draw pretty graphs of the
> > system load [1], this "per-job" information isn't all that relevant (and
> > minimal performance overhead is important). And if you want to monitor
> > just one ap
Hello,
On 2/1/19 22:05, Stefan Agner wrote:
> On 02.01.2019 18:02, Ahmad Fatoum wrote:
>> Hello,
>>
>> I got a board with the RED[0:7]/BLUE[0:7] lanes originating from the
>> LCDIF swapped and would like to describe this in the device tree:
>>
>> This first patch extends the mxsfb driver to suppor
Hello Sam,
On 7/1/19 19:04, Sam Ravnborg wrote:
> Hi Ahmad.
>
>> On 2/1/19 22:37, Sam Ravnborg wrote:
>>> The problem with the RED/BLUE lines swapped is something I
>>> have encountered while working with DRM support for Atmel at91sam9263 too.
>>>
>>> The solution selected is to extend the endpoi
Hi Kieran,
Thank you for the patches.
On Thu, Mar 14, 2019 at 10:04:17PM +, Kieran Bingham wrote:
> Three fairly trivial cleanup patches from while I've been working on the CRTC
> code on rcar-du.
>
> The first is a small spelling error in the drm_crtc_state documentation, and
> the followin
Hi,
On 11-03-19 14:09, Daniel Vetter wrote:
On Tue, Mar 05, 2019 at 08:03:23AM +0100, Greg Kroah-Hartman wrote:
On Mon, Mar 04, 2019 at 05:47:21PM +0100, Hans de Goede wrote:
Hi All,
This patch-series addresses the 2 TODO / FIXME items recently reported
by Daniel and after that moves the vbox
On Tue, Mar 05, 2019 at 08:03:23AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Mar 04, 2019 at 05:47:21PM +0100, Hans de Goede wrote:
> > Hi All,
> >
> > This patch-series addresses the 2 TODO / FIXME items recently reported
> > by Daniel and after that moves the vboxvideo driver out of staging.
>
Hi Hans,
On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
> Hi Heikki,
>
> On 28-02-19 15:47, Heikki Krogerus wrote:
> > Hi Hans,
> >
> > On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 28-02-19 10:15, Heikki Krogerus wrote:
>
>
>
> > > >
Hi,
On 04-03-19 16:17, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
Hi Heikki,
On 28-02-19 15:47, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
On Mon, Mar 04, 2019 at 05:47:21PM +0100, Hans de Goede wrote:
> Hi All,
>
> This patch-series addresses the 2 TODO / FIXME items recently reported
> by Daniel and after that moves the vboxvideo driver out of staging.
>
> Note this applies on top of drm-misc-next + this patch:
> https://patchwork
On Thu, Feb 28, 2019 at 09:03:26PM +0100, Jernej Skrabec wrote:
> DE2 and DE3 VI channels support coarse scaling to overcome VI scaler
> limitations. That is especially useful for downscaling big planes, for
> example 4K to 1080p.
>
> Following patches were tested on H3 and A64 with 4K video playb
On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-02-19 12:16, Jani Nikula wrote:
> > On Wed, 27 Feb 2019, Heikki Krogerus
> > wrote:
> > > One thing that this series does not consider is the DP lane count
> > > problem. The GPU drivers (i915 in this case) does not k
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> Hi,
>
> On 28-02-19 10:15, Heikki Krogerus wrote:
> > On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 27-02-19 12:16, Jani Nikula wrote:
> > > > On Wed, 27 Feb 2019, Heikki Krogerus
Hi Heikki,
On 28-02-19 15:47, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
I've been thinking about this... Do we actually need to link the
correct drm_connector to the Type-C connector? Perha
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915
Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.
Also, orientation.
The orientation should
On Wed, Feb 27, 2019 at 01:16:27PM +0200, Jani Nikula wrote:
> On Wed, 27 Feb 2019, Heikki Krogerus wrote:
> > One thing that this series does not consider is the DP lane count
> > problem. The GPU drivers (i915 in this case) does not know is four,
> > two or one DP lanes in use.
>
> Also, orient
Hi Hans,
On Mon, Feb 25, 2019 at 02:20:34PM +0100, Hans de Goede wrote:
> Hi All,
>
> On some Cherry Trail devices, DisplayPort over Type-C is supported through
> a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
> datalines between USB-3 and DP (e.g. a pi3usb30532). The
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
> One thing that this series does not consider is the DP lane count
> problem. The GPU drivers (i915 in this case) does not know is four,
> two or one DP lanes in use.
Also, orientation.
> I guess that is not a critical issue since there is a workaroun
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of
On 23.01.2019 14:03, Kees Cook wrote:
> This adds a new plugin "stackinit" that attempts to perform unconditional
> initialization of all stack variables
Hello Kees! Hello everyone!
I was curious about the performance impact of the initialization of all stack
variables. So I did a very brief test
Am Mittwoch, 9. Januar 2019, 19:56:36 CET schrieb Ezequiel Garcia:
> Here's a small series supporting plane reflection (aka. mirroring)
> properties on RK3328, RK3368, and RK3399 SoCs.
>
> Note that RK3288 specification doesn't seem to document registers
> for plane mirroring, but instead it only
On 2019-01-07 7:56 p.m., Lyude Paul wrote:
> Fix the suspend/issues that Jerry Zuo found in amdgpu, and add some
> compiler warnings for drivers ignoring the return code of
> drm_dp_mst_topology_mgr_resume() to help ensure we don't need to fix
> this again in the future for someone else's driver.
>
Hello Sam,
On 2/1/19 22:37, Sam Ravnborg wrote:
> The problem with the RED/BLUE lines swapped is something I
> have encountered while working with DRM support for Atmel at91sam9263 too.
>
> The solution selected is to extend the endpoint with
> a new optional property:
>
> - wiring: Wiring of da
Hi Ahmad.
> On 2/1/19 22:37, Sam Ravnborg wrote:
> > The problem with the RED/BLUE lines swapped is something I
> > have encountered while working with DRM support for Atmel at91sam9263 too.
> >
> > The solution selected is to extend the endpoint with
> > a new optional property:
> >
> > - wirin
On 1/2/19 10:05 PM, Stefan Agner wrote:
> On a quick glance patch 1 looks good.
>
> However, patch 2/3 are probably unnecessary when using of graph/panel
> support. E.g. panel-simple.c supports bus formats.
>
> Is the display you are using regular RGB and only the board/connectors
> happen to sw
Hi Ahmad.
On Wed, Jan 02, 2019 at 10:05:31PM +0100, Stefan Agner wrote:
> On 02.01.2019 18:02, Ahmad Fatoum wrote:
> > Hello,
> >
> > I got a board with the RED[0:7]/BLUE[0:7] lanes originating from the
> > LCDIF swapped and would like to describe this in the device tree:
> >
> > This first patc
On 02.01.2019 18:02, Ahmad Fatoum wrote:
> Hello,
>
> I got a board with the RED[0:7]/BLUE[0:7] lanes originating from the
> LCDIF swapped and would like to describe this in the device tree:
>
> This first patch extends the mxsfb driver to support
> following bus formats:
> MEDIA_BUS_FMT_BG
On Thu, Dec 20, 2018 at 12:56:46PM +, Emil Velikov wrote:
> On Wed, 19 Dec 2018 at 20:37, Daniel Vetter wrote:
> >
> > On Wed, Dec 19, 2018 at 09:30:46PM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 19, 2018 at 07:22:44PM +, Emil Velikov wrote:
> > > > Hi all,
> > > >
> > > > This series
On Wed, 19 Dec 2018 at 20:37, Daniel Vetter wrote:
>
> On Wed, Dec 19, 2018 at 09:30:46PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 19, 2018 at 07:22:44PM +, Emil Velikov wrote:
> > > Hi all,
> > >
> > > This series relaxes some permission handling we have in core.
> > >
> > > The first patc
On Wed, Dec 19, 2018 at 09:30:46PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 07:22:44PM +, Emil Velikov wrote:
> > Hi all,
> >
> > This series relaxes some permission handling we have in core.
> >
> > The first patch, swaps the DRM_ROOT_ONLY to DRM_MASTER on DROP_MASTER
> > ioctls
401 - 500 of 727 matches
Mail list logo
