On Thu, Apr 19, 2018 at 10:11:05AM +0300, Tomi Valkeinen wrote:
> On 19/04/18 09:34, Daniel Vetter wrote:
>
> >> But the kernel cannot know what the user wants to do, so it cannot
> >> configure the planes. If we have an HDMI output which supports 2k+ and a
> >> -2k LCD, and 4 hw planes, we can se
Hi Sebastian,
On 30/03/18 20:18, Sebastian Reichel wrote:
> This adds the required infrastructure for manually
> updated displays, such as DSI command mode panels.
>
> While those panels often support partial updates
> we currently always do a full refresh. Display
> will be refreshed when someth
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> >
> > Of course we'll never feed such a strange sg table to
On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:
> On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
> > On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
> > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> > > > On 04/17/2018 11:57 P
Gerd Hoffmann (4):
qxl: remove qxl_io_log()
qxl: move qxl_send_monitors_config()
qxl: hook monitors_config updates into crtc, not encoder.
qxl: drop dummy functions
drivers/gpu/drm/qxl/qxl_drv.h | 3 -
drivers/gpu/drm/qxl/qxl_cmd.c | 36 +
drivers/gpu/drm/qxl/qxl_display.
qxl_io_log() sends messages over to the host (qemu) for logging.
Remove the function and all callers, we can just use standard
DRM_DEBUG calls (and if needed a serial console).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_cmd.c | 34 ++-
Needed to avoid a forward declaration in a followup patch.
Pure code move, no functional change.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 47 +++
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qx
The encoder callbacks are only called in case the video mode changes.
So any layout changes without mode changes will go unnoticed.
Add qxl_crtc_update_monitors_config(), based on the old
qxl_write_monitors_config_for_encoder() function. Hook it into the
enable, disable and flush atomic crtc call
These days drm core checks function pointers everywhere before calling
them. So we can drop a bunch of dummy functions now.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 50 ---
1 file changed, 50 deletions(-)
diff --git a/drivers/gpu/
On 20/04/18 10:00, Daniel Vetter wrote:
(Adding Benoit back, he was dropped at some point in the thread)
> Stuff randomly not working is officially how atomic works. That's what the
> TEST_ONLY mode is for. There's a lot more than virtualized planes that
> might or might not push any given plane
On Wed, Apr 18, 2018 at 11:55:26AM +0100, Roger Pau Monné wrote:
> On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
> > On 04/18/2018 01:18 PM, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On
On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote:
> Wait until we have enough space in the virt queue to actually queue up
> our request. Avoids the guest spinning in case we have a non-zero
> amount of free entries but not enough for the request.
Ping airlied, can you please either
> Gerd Hoffmann (2):
> qxl: fix qxl_release_{map,unmap}
> qxl: keep separate release_bo pointer
Ping airlied, can you please either pick it up or review so I can commit
myself?
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
On Thu, Apr 19, 2018 at 03:43:19PM +0200, Hans de Goede wrote:
> Hi,
>
> On 05-04-18 15:26, Daniel Vetter wrote:
> > On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote:
> > > Hi,
> > >
> > >
> > > On 05-04-18 09:14, Daniel Vetter wrote:
> > > >
> > > > On Fri, Mar 30, 2018 at 02:27:15PM +0200
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/vc4/vc4_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-
On Tue, Apr 17, 2018 at 08:08:27PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:00, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote:
> >> Colorkey'ing allows to draw on top of overlapping planes, like for example
> >> on top of a video plane. Older Tegra
Hello Giulio,
this patch breaks LVDS output on A83T. Without it, modesetting works,
with it there's no output.
Some more info below...
On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
> mode_valid function is missing for lvds.
>
> Add it making it pointed by encoder helper functi
Some LVDS controller can output swapped versions of LVDS RGB formats.
Define and document them in the list of supported media bus formats
Signed-off-by: Jacopo Mondi
---
Documentation/media/uapi/v4l/subdev-formats.rst | 174
include/uapi/linux/media-bus-format.h
Add LVDS map mode description property to THC63LVD1024 LVDS decoder in
R-Car V3M-Eagle board device tree.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm6
With the introduction of static input image format enumeration in DRM
bridges, add support to retrieve the format in rcar-lvds LVDS encoder
from both panel or bridge, to set the desired LVDS mode.
Do not rely on 'DRM_BUS_FLAG_DATA_LSB_TO_MSB' flag to mirror the LVDS
format, as it is only defined f
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file changed, 2 insertions(
Changelog:
v4:
- Current patchset separates out eDP panel specific resources from sn65dsi86
bridge driver and creates a separate driver for the innloux edp panel.
- Removed the unnecessary header files and variables used in driver.
- Replaced irq_gpio as "interrupts" property in dt-binding
On 28 March 2018 at 18:04, Christian König wrote:
> Am 28.03.2018 um 17:53 schrieb Arnd Bergmann:
>>
>> Building amdkfd without MMU notifiers is broken:
>>
>> In file included from drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c:28:
>> drivers/gpu/drm/amd/amdkfd/kfd_priv.h:584:22: error: field 'mm
This prepares for being a drm_bridge which will not register the
encoder. That makes the connector the better choice.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/
Add a central function to parse a node according to the video
interface binding and get a media bus format.
Start with only supporting a very limited set of a few basic media
bus formats.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_of.c | 38 ++
includ
The THC63LVD1024 LVDS to RGB bridge supports two different input mapping
modes, selectable by means of an external pin.
Describe the LVDS mode map through a newly defined mandatory property in
device tree bindings.
Signed-off-by: Jacopo Mondi
---
.../devicetree/bindings/display/bridge/thine,thc
Start list of actual chips compatible with "lvds-encoder".
Reviewed-by: Laurent Pinchart
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
a/Documen
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++
1 file chan
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ s
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
.../video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 18 ++
1 fi
On 18 April 2018 at 00:14, Joonas Lahtinen
wrote:
> Quoting Jani Nikula (2018-04-17 12:02:52)
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W M
With bus-type/bus-width properties in the endpoint nodes, the video-
interface of the connection can be specified for cases where the
heuristic fails to select the correct output mode. This can happen
e.g. if not all RGB pins are routed on the PCB; the driver has no
way of knowing this, and needs t
On 2018-04-19 20:44, Jordan Crouse wrote:
On Wed, Apr 18, 2018 at 05:49:59PM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 ++
1 file changed, 2 insertions(+)
On 2018-04-19 18:22, Rob Herring wrote:
> On Tue, Apr 17, 2018 at 8:10 AM, Peter Rosin wrote:
>> Add a central function to parse a node according to the video
>> interface binding and get a media bus format.
>>
>> Start with only supporting a very limited set of a few basic media
>> bus formats.
>
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
Add support for Innolux TV123WAM 12.3" panel which
is an eDP panel.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 293 +
1 file changed, 293 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c
diff --git a/
On 14 April 2018 at 04:49, Randy Dunlap wrote:
> From: Randy Dunlap
>
> When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an
> incomplete type definition, which causes build errors.
>
> ../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier'
> has incomplete t
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if some of the RGB pins between the lcd controller and the
encoder are not routed on the PCB.
The THC63LVD1024 LVDS to RGB bridge supports two different LVDS mapping
modes, selectable by means of an external pin.
Add support for configurable LVDS input mapping modes, using the newly
introduced support for bridge input image formats.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge
This enables reuse of the machinery for the case where a drm_bridge
needs to do the same work via different interfaces.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/i2c/tda998x_drv.c | 46 ++-
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/d
This makes this driver work with all(?) drivers that are not
componentized and instead expect to connect to a panel/bridge. That
said, the only one tested is atmel_hlcdc.
This hooks the relevant work function previously called by the encoder
and the component also to the bridge, since the encoder
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/video/fbdev/auo_k190x.c| 12
drivers/video/fbdev/sh_mob
Hi!
I naively thought that since there was support for both nxp,tda19988 (in
the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
But it wasn't, so I started looking around and realized I had to fix
things.
In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
c
DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are
used to swap ordering of LVDS RGB format to accommodate DRM objects
that need to handle LVDS components ordering.
Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported
to use the newly introduced MEDIA_BUS_FMT_
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/msm_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Removed edp p
Add support for storing image format information in DRM bridges with
associated helper function.
This patch replicates for bridges what 'drm_display_info_set_bus_formats()'
is for connectors.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/drm_bridge.c | 30 ++
inclu
Hi,
On Thu, 2018-04-19 at 17:07 +0200, Maxime Ripard wrote:
> On Thu, Apr 19, 2018 at 02:56:38PM +0200, Paul Kocialkowski wrote:
> > Although frontend nodes are defined in the device-trees of the
> > aforementioned platforms, there are no matching compatibles defined
> > in
> > the driver. This ma
Hello DRM list,
cc media-list for the mbus format extension
cc renesas-soc and devicetree for Eagle DTS patch
This series adds support for static image formats to DRM bridges, mimicking
what display_info.bus_formats represents for DRM connectors.
The main use case of this series is the R-Car
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++
1 file changed, 2 insertions(+), 4 de
As now both bridges and panels report supported image formats,
use the newly introduced _LE version of LVDS media bus formats in place
of the DRM_BUS_FLAG_DATA_ flags defined in drm_connector.h
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/panel/panel-lvds.c | 21 -
1 file
The Innolux TV123WAM is a 12.3" eDP display panel
with 2160x1440 resolution.
Signed-off-by: Sandeep Panda
---
.../bindings/display/panel/innolux,edp-2k-panel.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/inno
On Tue, Apr 17, 2018 at 08:31:11PM +0300, Dmitry Osipenko wrote:
> On 17.04.2018 12:01, Daniel Vetter wrote:
> > On Mon, Apr 16, 2018 at 03:16:28PM +0300, Dmitry Osipenko wrote:
> >> This new property allows userspace to apply custom color conversion
> >> coefficients per plane, making possible to
On Fri, 20 Apr 2018, Ian W MORRISON wrote:
> I've performed backport testing and some additional analysis as follows:
What testing did you do beyond booting? Did you run igt?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
dri-deve
On Wed, Apr 18, 2018 at 07:42:56AM +0200, Gerd Hoffmann wrote:
> s/PAGE_SIZE/PAGE_MASK/
>
> Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
> bad side effects and managed to stay unnoticed for years that way ...
>
> Signed-off-by: Gerd Hoffmann
Sweeet. Since the buggy c
On Thu, Apr 19, 2018 at 03:38:53PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
>
> v2:
> * Moved helper function which attaches content type property
>to the drm
On Fri, Apr 20, 2018 at 10:21:35AM +0300, Tomi Valkeinen wrote:
> On 20/04/18 10:00, Daniel Vetter wrote:
>
> (Adding Benoit back, he was dropped at some point in the thread)
>
> > Stuff randomly not working is officially how atomic works. That's what the
> > TEST_ONLY mode is for. There's a lot
On Fri, Apr 20, 2018 at 10:09:38AM +0300, Tomi Valkeinen wrote:
> Hi Sebastian,
>
> On 30/03/18 20:18, Sebastian Reichel wrote:
> > This adds the required infrastructure for manually
> > updated displays, such as DSI command mode panels.
> >
> > While those panels often support partial updates
>
On Fri, Apr 20, 2018 at 09:19:04AM +0200, Gerd Hoffmann wrote:
> These days drm core checks function pointers everywhere before calling
> them. So we can drop a bunch of dummy functions now.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 50
> -
From: Daniel Vetter [daniel.vet...@ffwll.ch] on behalf of Daniel Vetter
[dan...@ffwll.ch]
> The property documentation to tie all the bits together (property, helper,
> internals) is missing. It should be in
> https://dri.freedesktop.org/docs/drm/gpu/drm
Hi Peter,
I've been a bit a pain in the arse for you recently, but please
bear with me a bit more, and sorry for jumping late on the band wagon.
On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> Hi!
>
> I naively thought that since there was support for both nxp,tda19988 (in
> the
On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
> This driver will be used to support Mesa on the Broadcom 7268 and 7278
> platforms.
>
> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
> complicated CL/shader validation scheme. This massively changes the
> GEM
Am 20.04.2018 um 09:13 schrieb Daniel Vetter:
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.
Of course we'll never
On 18.04.2018 16:40, Jacopo Mondi wrote:
> As I have another series which is based on this one + Eagle board display
> support, I'm re-sending this one to fix the small issue I pointed out in my
> reply to v8.
>
> Simon: no changes to Eagle DTS series, so the last one sent is still the good
> one.
Hi Peter,
Thank you for the patch.
On Thursday, 19 April 2018 19:27:49 EEST Peter Rosin wrote:
> This prepares for being a drm_bridge which will not register the
> encoder. That makes the connector the better choice.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
> drive
Hi Peter,
Thank you for the patch.
On Thursday, 19 April 2018 19:27:50 EEST Peter Rosin wrote:
> This enables reuse of the machinery for the case where a drm_bridge
> needs to do the same work via different interfaces.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c |
Hi Matthias,
On Fri, 2018-04-20 at 11:41 +0200, Matthias Brugger wrote:
> Hi Philipp,
>
> On 11/23/2017 09:54 AM, Philipp Zabel wrote:
> > Hi Matthias,
> >
> > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> > > The mmsys memory space is shared between the drm and the
> > > clk driv
Hi Peter,
Thank you for the patch.
On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
> This makes this driver work with all(?) drivers that are not
> componentized and instead expect to connect to a panel/bridge. That
> said, the only one tested is atmel_hlcdc.
>
> This hooks the relev
Reviewed-by: Dave Airlie
On Fri., 20 Apr. 2018, 17:23 Gerd Hoffmann, wrote:
> On Tue, Apr 03, 2018 at 11:59:04AM +0200, Gerd Hoffmann wrote:
> > Wait until we have enough space in the virt queue to actually queue up
> > our request. Avoids the guest spinning in case we have a non-zero
> > amou
Hello,
On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> Hi Peter,
> I've been a bit a pain in the arse for you recently, but please
> bear with me a bit more, and sorry for jumping late on the band wagon.
>
> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> > Hi!
> >
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
> > Yes there's a bit a layering violation insofar that drivers really
> > shouldn't each have their own copy of "how do I convert a piece of dma
> > memory into dma-buf", but that doesn't render the interface a bad idea.
>
> Comple
Hi Tomi,
On 20 April 2018 at 08:09, Tomi Valkeinen wrote:
> It's actually not quite clear to me how manual update displays work with
> DRM...
>
> As far as I see, we have essentially two cases: 1) single buffering,
> where the userspace must set an area in the fb dirty, which then
> triggers the
Hi,
On 20-04-18 09:27, Daniel Vetter wrote:
On Thu, Apr 19, 2018 at 03:43:19PM +0200, Hans de Goede wrote:
Hi,
On 05-04-18 15:26, Daniel Vetter wrote:
On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote:
Hi,
On 05-04-18 09:14, Daniel Vetter wrote:
On Fri, Mar 30, 2018 at 02:27:15PM +020
Hi Peter,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc1 next-20180420]
[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-ci/linux/commits
Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into dma-buf", but that doesn't ren
Hi Laurent,
On Fri, Apr 20, 2018 at 01:18:13PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> > Hi Peter,
> > I've been a bit a pain in the arse for you recently, but please
> > bear with me a bit more, and sorry for jumping late on the
On 04/20/2018 10:19 AM, Daniel Vetter wrote:
On Wed, Apr 18, 2018 at 11:10:58AM +0100, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 10:35 AM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenk
https://bugs.freedesktop.org/show_bug.cgi?id=103924
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=104723
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
Hi Peter,
On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
> On 2018-04-20 12:18, Laurent Pinchart wrote:
> > Hello,
> >
> > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> >> Hi Peter,
> >> I've been a bit a pain in the arse for you recently, but please
> >> bear with
https://bugs.freedesktop.org/show_bug.cgi?id=104439
--- Comment #10 from Francesco Turco ---
I can't reproduce this bug anymore with the Falkon 3.0.0 web browser and the
Linux 4.16.2 kernel.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #86 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Hi, any updates (In reply to Andrey Grodzovsky from comment #85)
> (In reply to Ricardo Ribalda from comment #84)
> > Hi Andrey
> >
> > I have removed the GALLIUM_DDEBUG=flush
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #87 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey
I have been running some manual tests (~30 boots) and it has been always ok. I
did not have time to setup an automatic test machine.
You are more than welcome to clos
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #88 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Great, thanks.(In reply to Ricardo Ribalda from comment #87)
> Hi Andrey
>
> I have been running some manual tests (~30 boots) and it has been always ok.
> I did not have time
The hardware has a single block for applying a CTM prior to gamma lut.
It can be fed with pixels from one of our CRTC at a time and uses a
matrix with S0.9 scalars. Use private atomic state to reject attempts
from userland to apply CTM for more than one CRTC at a time and reject
matrices with scala
Now that we set the OLED* registers to do CTM, it's helpful to have them
in the register dump.
Signed-off-by: Stefan Schake
---
v4: new in the series.
drivers/gpu/drm/vc4/vc4_hvs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hv
On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> >
> > {page,offset,len} + {dma_addr+dma_len}
> >
> > is not a
To allow bridge drivers to access state data such as the active mode in
their enable and disable handlers, pass a pointer to the connector state
to those handlers. From there the CRTC state can be accessed through
conn_state->crtc->state.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sean Paul
--
https://bugs.freedesktop.org/show_bug.cgi?id=104439
--- Comment #11 from magiblot ---
It has been working fine for me for quite a time with the 4.15 kernel as well.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=106073
Gabriel Rauter changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
From: Ankit Nautiyal
This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_modes.c | 47 +
i
On 12.03.2018 08:12, Andrzej Hajda wrote:
> On 20.02.2018 07:45, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> On 02.02.2018 16:11, Andrzej Hajda wrote:
>>> Hi Inki, Tobias,
>>>
>>> This is reviewed/updated/tested Tobias's patch addressing page-faults
>>> in Video Processor in interlaced mode. Plus prelim
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #19 from Kevin McCormack (wittyma...@yahoo.com) ---
Thanks for testing, Martin. This doesn't appear to be included in 4.16.3
looking at https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.16.3 and
Arch just bumped the kernel from
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch add
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is n
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/d
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once
1 - 100 of 163 matches
Mail list logo
