Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on ]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-panel-Add-Ilitek-ILI9881c-controller-driver/20180505-104031
base:
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gn
https://bugs.freedesktop.org/show_bug.cgi?id=98324
--- Comment #12 from Edward Kigwana ---
I remember this having this issue and found that switching to the console
(CTRL-ALT-F1) and then back to X once or twice woke the monitor.
--
You are receiving this mail because:
You are the assignee for
Hi,
This seems eerily quiet, so I expect it will explode next week or something.
One i915 moduel firmware, two vmwgfx fixes, one vc4 fix and one bridge leak fix.
Dave.
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
ar
This allows dumb buffer allocation for YUV422 and YUV444 with correct
subsampling values.
Signed-off-by: Hyun Kwon
---
tests/modetest/buffers.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
i
Hi,
This set adds more format support for modetest, including fixes for
10bit RGB formats and addition of 422/444 YUV formats.
Thanks,
-hyun
Hyun Kwon (3):
tests: util: pattern: Use 64bit RGB samples
modetest: Add support for YUV422 and YUV444
tests: util: Add support for YUV422 and YUV444
Use of 32bit RGB samples, where each component is 8bit, cannot
support formats with components greater than 8bit (ex, XRGB2101010).
Introduce MAKE_RGBA_64() which creates pixels from a 64bit sample.
Each component in a 64bit sample is 16bit long, thus a pixel with 10bit
components can be generated
Enable YUV422 and YUV444 formats by adding to the format table
and pattern generation calls.
Signed-off-by: Hyun Kwon
---
tests/util/format.c | 4
tests/util/pattern.c | 8
2 files changed, 12 insertions(+)
diff --git a/tests/util/format.c b/tests/util/format.c
index 15ac5e1..b48
From: Matt Atwood
As more differentation occurs between DP spec. Its useful to have these
as macros in a drm_dp_helper.
v2: DPCD_REV_XX to DP_DPCD_REV_XX
Signed-off-by: Matt Atwood
---
include/drm/drm_dp_helper.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_dp_help
From: Matt Atwood
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavio
Hi Sergey,
Il 04/05/2018 23:59, Sergey Suloev ha scritto:
Hi, Giulio,
On 05/05/2018 12:52 AM, Giulio Benetti wrote:
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
You don't have to handcode the fragments anymore
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlay
https://bugs.freedesktop.org/show_bug.cgi?id=106404
--- Comment #3 from Todd ---
Created attachment 139359
--> https://bugs.freedesktop.org/attachment.cgi?id=139359&action=edit
example program
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106404
--- Comment #2 from Todd ---
Created attachment 139358
--> https://bugs.freedesktop.org/attachment.cgi?id=139358&action=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106404
--- Comment #1 from Todd ---
Created attachment 139357
--> https://bugs.freedesktop.org/attachment.cgi?id=139357&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106404
Bug ID: 106404
Summary: Hang in draw function caused by interaction of
glutInitWindowPosition, glutFullScreen ,
glDrawBuffer(GL_FRONT)
Product: DRI
Version: unsp
Just checking for ifdefs cause build issues as reported by
kernel test:
config: openrisc-allmodconfig (attached as .config)
compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
All errors (new ones prefixed by >>):
drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function
'omapfb_i
On Thu, May 03, 2018 at 08:26:26AM +0200, Daniel Vetter wrote:
> On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote:
> > From: Ankit Nautiyal
> >
> > We parse the EDID and add all the modes in the connector's modelist.
> > This adds CEA modes with aspect ratio information too, rega
On Fri, May 4, 2018 at 9:20 AM, Daniel Vetter wrote:
> On Fri, May 04, 2018 at 02:17:49PM +0200, Boris Brezillon wrote:
>> On Fri, 4 May 2018 11:47:48 +0200
>> Thierry Reding wrote:
>>
>> > On Fri, May 04, 2018 at 10:06:53AM +0200, Boris Brezillon wrote:
>> > > Hi Rob,
>> > >
>> > > On Thu, 3 May
https://bugs.freedesktop.org/show_bug.cgi?id=54675
--- Comment #6 from Chris Rankin ---
Booting with "irqpoll=1" doesn't fix the problem; it simply no longer happens
at boot time:
irq 17: nobody cared (try booting with the "irqpoll" option)
Pid: 3347, comm: wineserver Not tainted 3.5.3 #2
Call T
Hi Lin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on rockchip/for-next]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Fri, May 04, 2018 at 05:19:50PM +, Mauro Rossi wrote:
> Hi all,
>
> I just wanted to share that I'm conducting "newbie" tests on oreo-x86 with
> drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle.h
>
> and the results are good on nouveau, provided that some changes in
> drmr
On Fri, May 04, 2018 at 11:48:10AM +0100, Daniel Stone wrote:
> Hey all,
>
> On 4 May 2018 at 09:43, Robert Foss wrote:
> > On 2018-05-03 17:04, Sean Paul wrote:
> >> Apologies for the direct ping. I've harvested your emails from drm_hwc git
> >> logs,
> >> and didn't want to leave anyone out. Th
On Fri, May 04, 2018 at 10:43:22AM +0200, Robert Foss wrote:
> Hey Sean,
>
> On 2018-05-03 17:04, Sean Paul wrote:
> > Hey all,
> > Apologies for the direct ping. I've harvested your emails from drm_hwc git
> > logs,
> > and didn't want to leave anyone out. The good news is that your email
> > a
https://bugs.freedesktop.org/show_bug.cgi?id=106177
--- Comment #4 from tempel.jul...@gmail.com ---
I'm on a RX 560.
I can confirm that with 4.17, behavior has quite changed a lot. I don't think
it's buggy for Polaris, but not documented correctly.
To make values "stick" in pp_sclk_od, you have t
On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
If you really want someone to review your patch, please add more detailed
explanations.
1. Please add 0th patch.
2. Please add what the difference is between V1 and V2 patches.
If you cannot understand what I am saying, just ask another person
On Fri, May 04, 2018 at 06:17:45PM +0300, Dmitry Osipenko wrote:
> On 04.05.2018 18:10, Thierry Reding wrote:
> > On Fri, May 04, 2018 at 05:23:42PM +0300, Dmitry Osipenko wrote:
> >> On 04.05.2018 16:37, Thierry Reding wrote:
> >>> From: Thierry Reding
> >>>
> >>> Attaching to and detaching from
The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
ILI9881c from Ilitek.
Acked-by: Rob Herring
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt | 20
1 file changed, 20 insertions(+)
create mode 100
The BananaPi M2M has an optional 1280x720 DSI panel. Since that panel is
optional, we can only show a DT patch that would show how to enable it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 39 +-
1 file changed, 39 insertions(+)
diff --git
The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
after the other Ilitek controller drivers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/Kconfig | 9 +-
drivers/gpu/drm/p
Hi,
Here is the next version of the patches to add the support for the Ilitek
ILI9881c panel controller.
This used to be a part of the larger DSI support series for the Allwinner
SoCs whose patches have been since merged and are obviously not part of
this series anymore.
Let me know what you thi
On Fri, May 04, 2018 at 02:47:23AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/boot/dts/tegra114.dtsi | 5 +
> 1 file changed, 5 insertions(+)
Applied, thanks.
Thierry
signature.asc
Description: PGP
On Fri, May 04, 2018 at 02:47:22AM +0300, Dmitry Osipenko wrote:
> Enable IOMMU support for Host1x and its clients.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/boot/dts/tegra30.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
Applied, thanks.
Thierry
signature.asc
Descrip
On Fri, May 04, 2018 at 05:39:58PM +0300, Dmitry Osipenko wrote:
[...]
> +static bool tegra_dc_window_can_use_horizontal_filtering(
> + struct tegra_plane *plane,
> + const struct tegra_dc_window *window)
[...]
> +static bool t
On Fri, May 04, 2018 at 05:39:57PM +0300, Dmitry Osipenko wrote:
> Hi,
>
> This series improves DRM plane support by supporting zPos on older Tegra's
> and enabling plane scaling filters (up to Tegra210).
>
> Changelog:
>
> v2:
> - Addressed v1 review comments.
>
> Dmitry Osipenko (3):
>
On Fri, May 04, 2018 at 03:37:04PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> If an error happens during display controller initialization, the host1x
> syncpoint previously requested would be leaked. Properly clean up the
> syncpoint along with the other resources.
>
> Signed-off-b
On Fri, May 04, 2018 at 05:23:42PM +0300, Dmitry Osipenko wrote:
> On 04.05.2018 16:37, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Attaching to and detaching from an IOMMU uses the same code sequence in
> > every driver, so factor it out into separate helpers.
> >
> > Signed-off-by:
https://bugzilla.kernel.org/show_bug.cgi?id=199585
Christian König (christian.koe...@amd.com) changed:
What|Removed |Added
CC||christian.koe
On Fri, 4 May 2018 16:24:04 +0200
Boris Brezillon wrote:
> On Fri, 4 May 2018 16:20:17 +0200
> Daniel Vetter wrote:
>
> > On Fri, May 04, 2018 at 02:17:49PM +0200, Boris Brezillon wrote:
> > > On Fri, 4 May 2018 11:47:48 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Fri, May 04, 20
Am 03.05.2018 um 14:46 schrieb Sean Paul:
On Wed, May 02, 2018 at 11:25:35PM +0200, Dirk Hohndel wrote:
On Wed, May 02, 2018 at 04:33:30PM -0400, Sean Paul wrote:
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 7c2485fe88d8..ea4d59eb8966 100644
On Fri, 4 May 2018 16:20:17 +0200
Daniel Vetter wrote:
> On Fri, May 04, 2018 at 02:17:49PM +0200, Boris Brezillon wrote:
> > On Fri, 4 May 2018 11:47:48 +0200
> > Thierry Reding wrote:
> >
> > > On Fri, May 04, 2018 at 10:06:53AM +0200, Boris Brezillon wrote:
> > > > Hi Rob,
> > > >
> > >
On Fri, May 04, 2018 at 02:17:49PM +0200, Boris Brezillon wrote:
> On Fri, 4 May 2018 11:47:48 +0200
> Thierry Reding wrote:
>
> > On Fri, May 04, 2018 at 10:06:53AM +0200, Boris Brezillon wrote:
> > > Hi Rob,
> > >
> > > On Thu, 3 May 2018 12:12:39 -0500
> > > Rob Herring wrote:
> > >
> > >
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
v2: Don't do the trick to set the ENABLE_SIGNAL_BIT
unconditionally, it results in an expensive spinlock take for
everyone. In
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ia
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
v2: Also remove the relase hook, dma_fence_free is the default.
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_fence.c | 8
1 file chang
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
v2: Add misplaced hunk of kerneldoc from a different patch.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: lina
On Fri, May 04, 2018 at 03:49:06PM +0200, Boris Brezillon wrote:
> On Fri, 4 May 2018 15:29:15 +0200
> Thierry Reding wrote:
>
> > On Fri, May 04, 2018 at 02:05:25PM +0200, Boris Brezillon wrote:
> > > On Fri, 4 May 2018 12:28:33 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Thu, May 03,
Em Wed, 25 Apr 2018 12:47:34 +0200
Bartlomiej Zolnierkiewicz escreveu:
> On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote:
> > Em Mon, 23 Apr 2018 14:47:28 +0200
> > Bartlomiej Zolnierkiewicz escreveu:
> >
> > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrot
On Fri, 4 May 2018 15:29:15 +0200
Thierry Reding wrote:
> On Fri, May 04, 2018 at 02:05:25PM +0200, Boris Brezillon wrote:
> > On Fri, 4 May 2018 12:28:33 +0200
> > Thierry Reding wrote:
> >
> > > On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> > > > Having a device with
On Fri, May 04, 2018 at 03:17:08PM +0200, Christian König wrote:
> Am 04.05.2018 um 11:25 schrieb Daniel Vetter:
> > On Fri, May 4, 2018 at 11:16 AM, Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2018-05-04 09:57:59)
> > > > On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
> >
From: Thierry Reding
Attaching to and detaching from an IOMMU uses the same code sequence in
every driver, so factor it out into separate helpers.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 42 ++--
drivers/gpu/drm/tegra/drm.c | 42 +++
From: Thierry Reding
If an error happens during display controller initialization, the host1x
syncpoint previously requested would be leaked. Properly clean up the
syncpoint along with the other resources.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 2 ++
1 file changed, 2 i
From: Thierry Reding
Failure to register the Tegra DRM client would leak the resources. Move
cleanup code to error unwinding gotos to fix that and share the cleanup
code with the other error paths.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gr3d.c | 27 +--
From: Thierry Reding
Failure to register the Tegra DRM client would leak the resources. Move
cleanup code to error unwinding gotos to fix that and share the cleanup
code with the other error paths.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gr2d.c | 28 ++--
On Fri, May 04, 2018 at 02:05:25PM +0200, Boris Brezillon wrote:
> On Fri, 4 May 2018 12:28:33 +0200
> Thierry Reding wrote:
>
> > On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> > > Having a device with a status property != "okay" in the DT is a valid
> > > use case, and we sh
Am 04.05.2018 um 11:25 schrieb Daniel Vetter:
On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote:
Quoting Daniel Vetter (2018-05-04 09:57:59)
On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
Quoting Daniel Vetter (2018-05-04 09:23:01)
On Fri, May 04, 2018 at 10:17:22AM +0200, D
https://bugs.freedesktop.org/show_bug.cgi?id=106402
Bug ID: 106402
Summary: amdgpu causes kernel Oops: 0002 [#1] SMP PTI
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Friday, May 04, 2018 09:45:26 AM Mauro Carvalho Chehab wrote:
> Em Fri, 04 May 2018 13:05:17 +0200
> Bartlomiej Zolnierkiewicz escreveu:
>
> > On Friday, May 04, 2018 07:59:06 AM Mauro Carvalho Chehab wrote:
> > > Em Fri, 04 May 2018 12:48:46 +0200
> > > Bartlomiej Zolnierkiewicz escreveu:
>
Heya,
On 2018-05-04 12:51, Daniel Stone wrote:
Hi,
On 3 May 2018 at 20:12, Sean Paul wrote:
On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
If you're still reading, I'll point out a couple other things:
- There is a bug tracke
Am Mittwoch, den 25.04.2018, 13:44 -0400 schrieb Alex Deucher:
> On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig > wrote:
> > On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
> > > > It has a non-coherent transaction mode (which the chipset can opt to
> > > > not implement and stil
Em Fri, 04 May 2018 13:05:17 +0200
Bartlomiej Zolnierkiewicz escreveu:
> On Friday, May 04, 2018 07:59:06 AM Mauro Carvalho Chehab wrote:
> > Em Fri, 04 May 2018 12:48:46 +0200
> > Bartlomiej Zolnierkiewicz escreveu:
> >
> > > On Thursday, May 03, 2018 08:48:56 AM Randy Dunlap wrote:
> > >
On Fri, May 04, 2018 at 02:47:21AM +0300, Dmitry Osipenko wrote:
> Attach GR3D to the displays IOMMU group in order to provide GR3D access
> to BO's IOVA.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gr3d.c | 27 +++
> 1 file changed, 27 insertions(+)
On Fri, May 04, 2018 at 02:47:20AM +0300, Dmitry Osipenko wrote:
> Attach GR2D to the display IOMMU group in order to provide GR2D access
> to BO's IOVA.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gr2d.c | 31 +--
> 1 file changed, 29 insertions(
On Fri, May 04, 2018 at 02:47:19AM +0300, Dmitry Osipenko wrote:
> Remove unneeded iommu_group_get() and add missing iommu_group_put(),
> correcting IOMMU group refcount. This is a minor correction / cleanup that
> doesn't really fix anything because Tegra's IOMMU driver are built-in and
> hence gr
On Fri, 4 May 2018 11:47:48 +0200
Thierry Reding wrote:
> On Fri, May 04, 2018 at 10:06:53AM +0200, Boris Brezillon wrote:
> > Hi Rob,
> >
> > On Thu, 3 May 2018 12:12:39 -0500
> > Rob Herring wrote:
> >
> > > On Thu, May 3, 2018 at 11:40 AM, Boris Brezillon
> > > wrote:
> > > > The devic
On Fri, May 04, 2018 at 03:08:44AM +0300, Dmitry Osipenko wrote:
> Older Tegra's support blending. Rename SoC info entry supports_blending
> to has_legacy_blending to eliminate confusion.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/dc.c | 20 ++--
> drivers/g
On Fri, May 04, 2018 at 03:08:43AM +0300, Dmitry Osipenko wrote:
> Older Tegra's do not support planes z position handling in hardware,
> but HW provides knobs for zPos implementation in software.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/dc.c| 134
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #11 from Norbert Klar ---
Same problem here with RX 480 and newest MESA driver.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
On Fri, May 04, 2018 at 01:58:20PM +0200, Boris Brezillon wrote:
> On Fri, 4 May 2018 12:18:52 +0200 Thierry Reding
> wrote:
> > On Thu, May 03, 2018 at 06:40:05PM +0200, Boris Brezillon wrote:
[...]
> > > return mdp4_lvds_connector->panel ?
> > > connector_status_connected :
On Fri, May 04, 2018 at 02:55:01PM +0300, Dmitry Osipenko wrote:
> On 04.05.2018 14:10, Thierry Reding wrote:
> > On Fri, May 04, 2018 at 03:08:42AM +0300, Dmitry Osipenko wrote:
> >> Currently resized plane produces a "pixelated" image which doesn't look
> >> nice, especially in a case of a video
On Fri, 4 May 2018 12:28:33 +0200
Thierry Reding wrote:
> On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> > Having a device with a status property != "okay" in the DT is a valid
> > use case, and we should not prevent the registration of the DRM device
> > when the DSI device c
On Fri, 4 May 2018 12:30:25 +0200
Thierry Reding wrote:
> On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> > Having a device with a status property != "okay" in the DT is a valid
> > use case, and we should not prevent the registration of the DRM device
> > when the DSI device c
Hi Thierry,
On Fri, 4 May 2018 12:18:52 +0200
Thierry Reding wrote:
> On Thu, May 03, 2018 at 06:40:05PM +0200, Boris Brezillon wrote:
> > Right now, the DRM panel logic returns NULL when a panel pointing to
> > the passed OF node is not present in the list of registered panels.
> >
> > Most dr
Op 03-05-18 om 15:36 schreef Ville Syrjälä:
> On Thu, May 03, 2018 at 01:22:17PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/Kconfig | 1 +
>> drivers/gpu/drm/selftests/Makefile| 2 +-
>> .../gpu/drm/selftests
On 04/05/18 09:15, Satendra Singh Thakur wrote:
To avoid duplicate logic for the same
Reviewed-by: Robin Murphy
Please read section 13 of Documentation/process/submitting-patches.rst
for what this tag means; specifically, it is definitely not "this guy
read my patch".
FWIW, in my case the
https://bugzilla.kernel.org/show_bug.cgi?id=199621
--- Comment #3 from Florian Echtler (f...@butterbrot.org) ---
One more update, sorry for the noise: I've been digging through the old Ubuntu
kernel release schedules, and I'm pretty sure that the display worked with 4.8,
but started turning blank
https://bugzilla.kernel.org/show_bug.cgi?id=199621
--- Comment #2 from Florian Echtler (f...@butterbrot.org) ---
Side note two: this is the 27" 2009 iMac model, the exact video card is:
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV730/M96-XT [Mobility Radeon HD 4670
On Fri, May 04, 2018 at 03:08:42AM +0300, Dmitry Osipenko wrote:
> Currently resized plane produces a "pixelated" image which doesn't look
> nice, especially in a case of a video overlay. Enable scaling filters that
> significantly improve image quality of a scaled overlay.
>
> Signed-off-by: Dmit
https://bugzilla.kernel.org/show_bug.cgi?id=199621
--- Comment #1 from Florian Echtler (f...@butterbrot.org) ---
Side note: this bug has been persisting since at least 4.11, I think the last
time it worked was somewhere around kernel 4.8.
--
You are receiving this mail because:
You are watching
On Friday, May 04, 2018 07:59:06 AM Mauro Carvalho Chehab wrote:
> Em Fri, 04 May 2018 12:48:46 +0200
> Bartlomiej Zolnierkiewicz escreveu:
>
> > On Thursday, May 03, 2018 08:48:56 AM Randy Dunlap wrote:
> > > On 04/20/2018 04:25 AM, Anders Roxell wrote:
> > > > Commit 7378f1149884 ("media: oma
Em Fri, 04 May 2018 12:48:46 +0200
Bartlomiej Zolnierkiewicz escreveu:
> On Thursday, May 03, 2018 08:48:56 AM Randy Dunlap wrote:
> > On 04/20/2018 04:25 AM, Anders Roxell wrote:
> > > Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
> > > COMPILE_TEST") broke compilation wit
On Fri, May 04, 2018 at 02:47:18AM +0300, Dmitry Osipenko wrote:
> Hi,
>
> This series enables IOMMU support for 2d/3d HW on Tegra30/114, as a result
> userspace that uses 2d/3d could work with the active IOMMU.
>
> Dmitry Osipenko (5):
> drm/tegra: dc: Balance IOMMU group refcounting
> drm/t
On Fri, May 04, 2018 at 02:47:20AM +0300, Dmitry Osipenko wrote:
> Attach GR2D to the display IOMMU group in order to provide GR2D access
> to BO's IOVA.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gr2d.c | 31 +--
> 1 file changed, 29 insertions(
Hi,
On 3 May 2018 at 20:12, Sean Paul wrote:
> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
>> On Thu, May 3, 2018 at 5:04 PM, Sean Paul wrote:
>> > If you're still reading, I'll point out a couple other things:
>> > - There is a bug tracker on the gitlab instance, feel free to
On Thursday, May 03, 2018 08:48:56 AM Randy Dunlap wrote:
> On 04/20/2018 04:25 AM, Anders Roxell wrote:
> > Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
> > COMPILE_TEST") broke compilation without CONFIG_OF selected.
> > CC drivers/video/fbdev/core/fbmem.o
> > drivers
Hey all,
On 4 May 2018 at 09:43, Robert Foss wrote:
> On 2018-05-03 17:04, Sean Paul wrote:
>> Apologies for the direct ping. I've harvested your emails from drm_hwc git
>> logs,
>> and didn't want to leave anyone out. The good news is that your email
>> address
>> will forever be remembered in t
On Fri, May 04, 2018 at 02:47:19AM +0300, Dmitry Osipenko wrote:
> Remove unneeded iommu_group_get() and add missing iommu_group_put(),
> correcting IOMMU group refcount. This is a minor correction / cleanup that
> doesn't really fix anything because Tegra's IOMMU driver are built-in and
> hence gr
On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> Having a device with a status property != "okay" in the DT is a valid
> use case, and we should not prevent the registration of the DRM device
> when the DSI device connected to the DSI controller is disabled.
>
> Consider the ENOD
On Thu, May 03, 2018 at 06:40:08PM +0200, Boris Brezillon wrote:
> Having a device with a status property != "okay" in the DT is a valid
> use case, and we should not prevent the registration of the DRM device
> when the DSI device connected to the DSI controller is disabled.
>
> Consider the ENOD
On Thu, May 03, 2018 at 06:40:07PM +0200, Boris Brezillon wrote:
> There's no point searching for a drm_bridge or drm_panel if the OF node
> we're pointing has a status property that is not "okay" or "ok". Just
> return -ENODEV in this case.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu
On Thu, May 03, 2018 at 06:40:06PM +0200, Boris Brezillon wrote:
> DT nodes might be present in the DT but with a status property set to
> "disabled" or "fail". In this case, we should not return -EPROBE_DEFER
> when the caller ask for a drm_panel instance. Return -ENODEV instead.
>
> Signed-off-b
On Thu, May 03, 2018 at 06:40:05PM +0200, Boris Brezillon wrote:
> Right now, the DRM panel logic returns NULL when a panel pointing to
> the passed OF node is not present in the list of registered panels.
>
> Most drivers interpret this NULL value as -EPROBE_DEFER, but we are
> about to modify th
On Fri, 4 May 2018 11:50:16 +0200
Thierry Reding wrote:
> On Thu, May 03, 2018 at 06:40:04PM +0200, Boris Brezillon wrote:
> > of_node_put(panel) is not called when of_drm_find_panel(panel) returns
> > NULL, thus leaking the reference we hold on panel.
> >
> > Fixes: 9be7d864cf07 ("drm/tegra: Im
On Fri, May 04, 2018 at 11:50:16AM +0200, Thierry Reding wrote:
> On Thu, May 03, 2018 at 06:40:04PM +0200, Boris Brezillon wrote:
> > of_node_put(panel) is not called when of_drm_find_panel(panel) returns
> > NULL, thus leaking the reference we hold on panel.
> >
> > Fixes: 9be7d864cf07 ("drm/teg
On Thu, May 03, 2018 at 06:40:04PM +0200, Boris Brezillon wrote:
> of_node_put(panel) is not called when of_drm_find_panel(panel) returns
> NULL, thus leaking the reference we hold on panel.
>
> Fixes: 9be7d864cf07 ("drm/tegra: Implement panel support")
> Cc:
> Signed-off-by: Boris Brezillon
> -
On Fri, May 04, 2018 at 10:06:53AM +0200, Boris Brezillon wrote:
> Hi Rob,
>
> On Thu, 3 May 2018 12:12:39 -0500
> Rob Herring wrote:
>
> > On Thu, May 3, 2018 at 11:40 AM, Boris Brezillon
> > wrote:
> > > The device might be described in the device tree but not connected to
> > > the I2C bus.
On Wed, Apr 18, 2018 at 03:40:19AM -0700, Stefan Schake wrote:
> Using drm_atomic_get_private_obj_state after state has been swapped
> will return old state.
>
> Fixes: 0281c4149021 ("drm/tegra: hub: Use private object for global state")
> Signed-off-by: Stefan Schake
> ---
> drivers/gpu/drm/teg
On Fri, 04 May 2018, Satendra Singh Thakur wrote:
> Reviewed-by: Jani Nikula
No. I commented on the patch, but I never said Reviewed-by. Never assume
Reviewed-by based on random comments on patches.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
On Fri, May 04, 2018 at 02:32:03PM +0530, Satendra Singh Thakur wrote:
> On Thu, May 03, 2018 at 11:36:39 +0100, Liviu Dudau wrote:
> > On Thu, May 03, 2018 at 11:28:37AM +0530, Satendra Singh Thakur wrote:
> > > 1.
> > > -Added a new helper drm_display_mode_crtc_to_videomode
> > > -This helper cal
On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-05-04 09:57:59)
>> On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote:
>> > Quoting Daniel Vetter (2018-05-04 09:23:01)
>> > > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote:
>> > > > On Fri
1 - 100 of 120 matches
Mail list logo
