On Tue, Mar 28, 2017 at 12:10:37PM -0400, Alex Deucher wrote:
> On Tue, Mar 28, 2017 at 11:53 AM, Daniel Vetter
> wrote:
> > Mostly because I want the links from the newly-added @state functions
> > to work. But I think explaining when they're useful and that the
> > implicit one is deprecated is
On Tue, Mar 28, 2017 at 01:13:43PM -0700, Eric Anholt wrote:
> Without this, the first modeset would dereference past the allocation
> when trying to free the mm node.
>
> Signed-off-by: Eric Anholt
> Tested-by: Stefan Wahren
Fixes: d8dbf44f13b9 ("drm/vc4: Make the CRTCs cooperate on allocating
On 29/03/17 01:02 PM, r...@ubuntu.com wrote:
> From: Christopher James Halse Rogers
>
> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
> an imported dma-buf.
>
> v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
>
> Signed-off-by: Christopher
From: Christopher James Halse Rogers
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
From: Christopher James Halse Rogers
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
On Wed, 29 Mar 2017 at 13:04 Michel Dänzer wrote:
> On 29/03/17 09:27 AM, r...@ubuntu.com wrote:
> > From: Christopher James Halse Rogers <
> christopher.halse.rog...@canonical.com>
> >
> > Any use of the framebuffer will migrate it to VRAM, which is not
> sensible for
> > an imported dma-buf.
>
Hi Monk,
It's probably a bug fix that unveils the link errors.
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
head: 98093dcaed5fe9f954a4362f8d72981c10d2609e
commit: d418c1e086f1601c588cc51084e27251f75780b0 [287/305] uapi/drm:add new
flag for Preemption
config: i386-all
On 29/03/17 09:27 AM, r...@ubuntu.com wrote:
> From: Christopher James Halse Rogers
>
> Any use of the framebuffer will migrate it to VRAM, which is not sensible for
> an imported dma-buf.
>
> Signed-off-by: Christopher James Halse Rogers
>
> CC: amd-...@lists.freedesktop.org
> ---
> drivers/
On 29/03/17 09:27 AM, r...@ubuntu.com wrote:
> From: Christopher James Halse Rogers
>
> Attempting to migrate the bo will break the sharing of the buffer.
>
> Signed-off-by: Christopher James Halse Rogers
>
> CC: amd-...@lists.freedesktop.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
https://bugs.freedesktop.org/show_bug.cgi?id=100437
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Product|xorg
On Mon, 16 Jan 2017 23:53:53 +0200
Laurent Pinchart wrote:
> Hi Gustavo,
>
> (CC'ing Steven)
Sorry for the very late reply. I somehow missed this email. But I
figured I would reply to it anyway. At least for knowledge for future
changes.
>
> On Monday 16 Jan 2017 19:12:58 Gustavo Padovan wrot
On 29/03/17 03:59, Emil Velikov wrote:
Hi Chad,
On 24 March 2017 at 20:44, Chad Versace wrote:
On Tue 21 Mar 2017, Matt Turner wrote:
On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov wrote:
On 20 March 2017 at 18:30, Matt Turner wrote:
On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov wrote:
On Tue, Mar 28, 2017 at 3:16 AM, Arnd Bergmann wrote:
> A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
> the rockchip drm driver will fail to link:
>
> drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
> cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x
https://bugs.freedesktop.org/show_bug.cgi?id=100400
Michel Dänzer changed:
What|Removed |Added
Attachment #130515|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100189
Emil Velikov changed:
What|Removed |Added
Component|Drivers/DRI/i915|Drivers/Gallium/i915g
--- Comment #13 fr
https://bugs.freedesktop.org/show_bug.cgi?id=100395
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #4 f
From: Christopher James Halse Rogers
Attempting to migrate the bo will break the sharing of the buffer.
Signed-off-by: Christopher James Halse Rogers
CC: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu
From: Christopher James Halse Rogers
Attempting to migrate the bo will break the sharing of the buffer.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 11 +++
1 file changed, 11 insertions(+)
diff --git
From: Christopher James Halse Rogers
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
Signed-off-by: Christopher James Halse Rogers
CC: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_display.c | 4
1 file changed, 4 ins
From: Christopher James Halse Rogers
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_display.c | 6 ++
1 file changed, 6 ins
From: Christopher James Halse Rogers
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
1 file changed, 6
For nouveau, radeon, and amdgpu attempting to scanout of a bo will cause
the driver to migrate it to VRAM.
When the bo in question is an imported dma-buf, this results in a buffer
that appears to be shared but is actually device-private.
Consensus on #dri-devel seemed to be that it would be appro
From: Christopher James Halse Rogers
Attempting to migrate the bo will break the sharing of the buffer.
Signed-off-by: Christopher James Halse Rogers
CC: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_prime.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/dri
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #8 from beham.christop...@gmx.at ---
Created attachment 130515
--> https://bugs.freedesktop.org/attachment.cgi?id=130515&action=edit
valgrind output of the game execution logged with script
Thanks for your replies, I ran valgrind w
Without this, the first modeset would dereference past the allocation
when trying to free the mm node.
Signed-off-by: Eric Anholt
Tested-by: Stefan Wahren
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #12 from Marek Olšák ---
The i915 gallium driver is unmaintained and not even supported by its
manufacturer. This bug report starts its deprecation period. If the driver
remains in a broken state for a while, it will be removed from
On Tue, Mar 28, 2017 at 06:44:50PM +0200, Philipp Zabel wrote:
> Hi Martyn,
>
> On Tue, 2017-03-28 at 11:49 +0100, Martyn Welch wrote:
> > On Mon, Mar 27, 2017 at 12:11:12PM +0100, Martyn Welch wrote:
> > > On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> > > > On Fri, 2017-03-24 a
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #11 from Javi Ballester Tomás ---
(In reply to Marek Olšák from comment #8)
> Is this the gallium driver?
Yes.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #10 from Javi Ballester Tomás ---
The "Gallium 0.4 on i915 (chipset: Pineview M)" is the one giving the segfault.
The "Mesa DRI Intel(R) Pineview M" works.
Additional info, not related to this bug, I think:
The two works with some
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #9 from Javi Ballester Tomás ---
Created attachment 130508
--> https://bugs.freedesktop.org/attachment.cgi?id=130508&action=edit
output of glxinfo
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #8 from Marek Olšák ---
Is this the gallium driver?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
Hi Chad,
On 24 March 2017 at 20:44, Chad Versace wrote:
> On Tue 21 Mar 2017, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
>> wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> >> wrote:
>
>> >>> These proj
Hi Martyn,
On Tue, 2017-03-28 at 11:49 +0100, Martyn Welch wrote:
> On Mon, Mar 27, 2017 at 12:11:12PM +0100, Martyn Welch wrote:
> > On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> > > On Fri, 2017-03-24 at 10:24 +, Martyn Welch wrote:
> > > [...]
> > > > > Could you move to
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #7 from Javi Ballester Tomás ---
The result of 'git bisect':
e027935a795ecf546f3e4abcc25655766f9615ac is the first bad commit
commit e027935a795ecf546f3e4abcc25655766f9615ac
Author: Marek Olšák
Date: Wed Feb 22 19:59:27 2017 +010
Patches 1-3 are Reviewed-by: Harry Wentland
Harry
On 2017-03-28 11:53 AM, Daniel Vetter wrote:
Mostly because I want the links from the newly-added @state functions
to work. But I think explaining when they're useful and that the
implicit one is deprecated is good either way. Slightly repetiti
On Tue, Mar 28, 2017 at 11:53 AM, Daniel Vetter wrote:
> Mostly because I want the links from the newly-added @state functions
> to work. But I think explaining when they're useful and that the
> implicit one is deprecated is good either way. Slightly repetitive
> unfortunately.
>
> Cc: Harry Went
They're properly documented in drm_connector.c now, and this
csv file is a horrible mess. Better to remove it.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/kms-properties.csv | 5 -
1 file changed, 5 deletions(-)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/k
Mostly because I want the links from the newly-added @state functions
to work. But I think explaining when they're useful and that the
implicit one is deprecated is good either way. Slightly repetitive
unfortunately.
Cc: Harry Wentland
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
inc
The rules are getting real hard, better to dump my brain into text a
bit. This is by far not complete, but I think I reasonable start at
least.
Some of the older kms structures would need a full doc review anyway
...
Cc: Harry Wentland
Reviewed-by: Harry Wentland
Cc: Maarten Lankhorst
Signed-o
On 27.03.2017 04:09, Seung-Woo Kim wrote:
In error path of drmGetBusid() and drmGetReservedContextList(),
there are memory leaks for error path. So this removes them.
Signed-off-by: Seung-Woo Kim
Reviewed-by: Nicolai Hähnle
---
xf86drm.c | 18 --
1 files changed, 12 ins
Hello Doug,
On 03/22/2017 12:59 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 22, 2017 at 3:57 AM, Andrzej Hajda wrote:
>> On 10.03.2017 05:32, Sean Paul wrote:
>>> From: Douglas Anderson
>>>
>>> The comments in analogix_dp_init_aux() claim that we're disabling aux
>>> channel retries, but the
On 2017-03-28 03:02 AM, Daniel Vetter wrote:
On Tue, Mar 28, 2017 at 08:23:53AM +0200, Daniel Vetter wrote:
On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
This is just prep work to get an acquire ctx into ever
Reviewed-by: Harry Wentland
Harry
On 2017-03-28 03:01 AM, Daniel Vetter wrote:
No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.
This removes another user of drm_modeset_lock_crtc. There's
On Tue, Mar 28, 2017 at 04:07:58PM +0200, Arnd Bergmann wrote:
> The newly introduced function causes a harmless build warning:
>
> drivers/gpu/drm/arm/malidp_planes.c: In function
> 'malidp_plane_atomic_print_state':
> drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp'
> [-W
On Tue, Mar 28, 2017 at 03:18:36PM +0300, Tomi Valkeinen wrote:
> On 27/03/17 10:43, Daniel Vetter wrote:
>
> > With atomic we've stopped killing the entire CRTC when you the last
> > userspace reference for the framebuffer on the primary plane disappears,
> > but just shut down the primary plane.
https://bugs.freedesktop.org/show_bug.cgi?id=92248
Maarten Lankhorst changed:
What|Removed |Added
Status|NEEDINFO|REOPENED
--- Comment #32 from Maarte
The newly introduced function causes a harmless build warning:
drivers/gpu/drm/arm/malidp_planes.c: In function
'malidp_plane_atomic_print_state':
drivers/gpu/drm/arm/malidp_planes.c:98:23: error: unused variable 'mp'
[-Werror=unused-variable]
The variable serves no purpose here and can be remo
On 03/27/17 08:58, Archit Taneja wrote:
> Hi,
>
> On 03/07/2017 03:21 AM, Christopher Spinrath wrote:
>> Hi Fabio,
>>
>> On 03/06/2017 10:46 PM, Fabio Estevam wrote:
>>> Hi Christopher,
>>>
>>> On Mon, Mar 6, 2017 at 6:40 PM,
>>> wrote:
From: Christopher Spinrath
On some boards t
On 03/22/2017 02:53 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 21-03-2017 15:12, Neil Armstrong wrote:
>> From: Laurent Pinchart
>>
>> In preparation for adding PHY operations to handle RX SENSE and HPD,
>> group all the PHY interrupt setup code in a single location and extract
>> it to a separat
When unloading omapdrm we get a NULL pointer deref in
omap_drm_irq_uninstall(). This is caused by:
967dd48417874dd25491a4e933648f394a64f70f ("drm: remove
drm_vblank_no_hw_counter assignment from driver code")
We shut down all the crtcs at unload time before calling
omap_drm_irq_uninstall, so the
Hi Thomas,
2017-03-28 Thomas Hellstrom :
> The mesa winsys sometimes uses unimplemented parameter requests to
> check for features. Remove the error message to avoid bloating the
> kernel log.
>
> Cc:
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Brian Paul
> Reviewed-by: Sinclair Yeh
> -
From: Peter Ujfalusi
When the connector associated detect callback is not provided, we can not
detect if the display is connected or disconnected. These displays does not
support hot plug, they are always connected. Let DRM know that connectors
w/o detect callback should not be polled.
Signed-of
Use drm_atomic_helper_shutdown() to ensure that all crtcs are disabled
when unloading the driver.
Signed-off-by: Tomi Valkeinen
Cc: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/o
From: Peter Ujfalusi
The associated backlight device can be configured via DT by providing the
phandle to the device.
If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn
From: Peter Ujfalusi
The functions can be used to check a component (by it's of_node) if it is
part of the omapdss display or output list. If the component is found, it
means that the driver is loaded.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss
Instead of printing 0/1 for display flags like vsync high/low, use a
tri-state print (-1/0/1) to indicate the "undefined" state.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers
If omap_plane_atomic_update() is called when the crtc is disabled, and
the timings are zero, we'll see the following warning:
omapdss DISPC error: cannot calculate scaling settings: pclk is zero
omapdrm omapdrm.0: Failed to setup plane vid2
It shouldn't cause any issues, as the crtc is disabled s
From: Peter Ujfalusi
Instead of 'guessing' based on aliases of the status of the DSS drivers,
use the new interface to check that all needed drivers are loaded.
In this way we can be sure that all needed drivers are loaded so it is
safe to continue the probing of omapdrm.
This method will allow t
From: Peter Ujfalusi
When omapdss is loaded (all core components are in place) create a list of
devices used in the display graph. This list later can be used by omapdrm
via the omapdss_stack_is_ready() function to check that these components
are loaded. Based on this information, omapdrm can def
omapdss_is_initialized() is used to find out if omapdss has been probed
successfully. This patch moves the related code to the common
omapdss-base module, so that the same support will be there for both
omapdss and omapdss6.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c
From: Peter Ujfalusi
Keep the panel_list ordered according to aliases. The DRM connectors will
be created following the panel_list. By keeping the list ordered the DRM
connectors will be created in the same order regardless of the driver
probe order.
Signed-off-by: Peter Ujfalusi
Signed-off-by:
At the moment VSYNC/HSYNC/DE high/low flags set by the panel/encoder
drivers get lost when the videotimings are translated to DRM's
videomode, as DRM's mode does not have corresponding flags.
DRM has bus-flags for this purpose, and while it lacks a few flags at
the moment, it should be used here.
omapdrm now uses dispc_ops instead of direct function calls so we can
remove all EXPORT_SYMBOLs from dispc. Most of the functions can also be
made static, but a few are used outside dispc.c.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 84 +---
display.c uses dsi_get_pixel_size() which is implemented in the DSI
driver, and we won't have that in the omapdss-base module, to which we
want to move display.c
This patch changes display.c not to use dsi_get_pixel_size(). The call
can be replaced with a simple check for OMAP_DSS_DSI_FMT_RGB565.
Change omapdrm to get dispc_ops and use that to call the dispc functions
instead or direct function calls.
The change is very straightforward.
The only problem was in omap_crtc_init() which calls pipe2vbl(crtc), and
at that point of time the crtc->dev link, which is used to get the
dispc_ops, has
DSS uses "replication logic" to convert color components from smaller
bit widths to bigger bit widths. Without replication logic, the color
component would be shifted and the least significant bits would be left
at 0, whereas with replication logic, the least significat bits will be
filled with the
We want to change the dispc API from plain functions to a struct with
functions pointers, so that omapdrm can call either omapdss or omapdss6
depending on the platform.
This patch adds 'struct dispc_ops' and adds functions to omapdss-base
to set and get the ops.
Signed-off-by: Tomi Valkeinen
---
Remove two unused WB functions.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 10 --
drivers/gpu/drm/omapdrm/dss/dss.h | 2 --
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 7104
This patch changes the current omapdss driver to fill a dispc_ops struct
and set it to omapdss-base.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 40 +
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.
This patch moves the common parts of omapdss to omapdss-base so that
both the current omapdss driver and the new omapdss6 driver can use
them.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Makefile | 6 +++---
drivers/gpu/drm/omapdrm/dss/display.c | 2 --
drivers/gpu/drm/omapdrm
This is the third revision of this series. Note that this series depends on
"drm/atomic: Introduce drm_atomic_helper_shutdown" which has not yet been
merged to drm-next.
The main changes in v3:
- improve variable names in 'work-around for errata i886'
- drop 'Init fbdev emulation only when we hav
We are working towards enabling omapdss6, which will consists of a new
dss, dispc and dpi drivers. omapdss6 will be a new module. The panel,
encoder and omapdrm will need to use either the current omapdss driver
or the new omapdss6 driver, depending on the platform.
This will be implemented with a
omapdrm still uses a few non-dispc functions: dss_feat_get_num_mgrs(),
dss_feat_get_num_ovls() and dss_feat_get_supported_color_modes(). We
want to provide omapdrm a single dispc_ops function pointer struct so
that omapdrm will use either the current omapdss or the new omapdss6
driver depending on
From: Hemant Hariyani
Add support for render nodes in omap driver and allow required
ioctls to be accessible via render nodes.
This enables unprivileged clients to allocate resources like GEM buffers
for rendering their content into. Mode setting (KMS ioctls) is not
allowed using render nodes. T
We don't have omapdss's custom error printing functions in the common
omapdss-base module, to which we want to move output.c.
This patch changes output.c to use dev_err instead of DSSERR so that it
doesn't depend on DSSERR.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/output.c
The driver only uses even dividers for hsdiv when pclk >= 100MHz, as odd
dividers can create uneven duty cycle. However, while this holds true
for some dividers like DISPC's LCK and PCK dividers, it is not actually
true for hsdiv.
hsdiv always produces even duty cycle, so the constraint can be rem
mode_config's min_width and min_height are both set to 32, which is
overly restrictive.
The real limits depend on whether we're configuring a crtc or a plane,
but a limit of 8x2 is safe for both cases.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
1 file changed
DRA7 errata i886 (FPDLink PLL Unlocks With Certain SoC PLL M/N Values)
says that FPDLink is sensitive to jitter on the vout clock, and that low
PLL M and N values result in more jitter than high M and N values.
This patch implements a workaround for the problem by changing the PLL
setup to search
While implementing writeback support, odd behavior of WBDELAYCOUNT was
observed with the combination of WB capture and HDMI. The result of the
debugging was that the HDMI sync polarities are not set correctly.
The current code sets the sync polarities going from HDMI WP to DISPC
according to the v
The clock source selection for the LCD outputs is too hardcoded at the
moment. For example, LCD3 is set to use PLL2_1, and PLL2 doesn't exist
on DRA72x SoCs.
There are quite many ways to configure the clocks, even using HDMI PLL
for LCD outputs, but enabling full configuration of the clocks is rat
The current driver doesn't expose any of the CRTC HW properties like
background color or transparency key, and sets them at CRTC enable time.
Refactor this into a separate function and call that function from
omap_crtc_atomic_flush(). This is the behavior we want when the
properties can be configu
Hi Shuah,
On Monday 27 Mar 2017 15:27:36 Shuah Khan wrote:
> On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart wrote:
> > From: Sakari Ailus
> >
> > The cache synchronisation may be a time consuming operation and thus not
> > best performed in an interrupt which is a typical context for
> > vb2_
On 27/03/17 10:43, Daniel Vetter wrote:
> With atomic we've stopped killing the entire CRTC when you the last
> userspace reference for the framebuffer on the primary plane disappears,
> but just shut down the primary plane. Assuming the driver can do that, we
> fall back to full CRTC shutdown if
On Tue, Mar 28, 2017 at 11:26 AM, Inki Dae wrote:
> Merged.
Hi,
I do not see the tag (with DT patches) merged by you which I provided
to you before. These are essential for bisectability. Without them,
kernel bisectability is broken. Did you merged the tag somewhere?
Best regards,
Krzysztof
>
從我的 iPad 傳送
> Clint Taylor 於 2017年3月28日 上午6:49 寫道：
>
>> On 03/26/2017 09:05 PM, Ayaka wrote:
>>
>>
>> 從我的 iPad 傳送
>>
Ander Conselvan De Oliveira 於 2017年3月14日 下午9:53 寫道：
On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
從我的 iPad 傳送
>> Ville Syrjälä 於 2017
Andrey Ryabinin wrote:
> It's safe to call vfree() from rcu callback as in any other interrupt context.
> Commits you listed bellow didn't change anything in that respect.
> They made impossible to call vfree() under stuff like
> preempt_disable()/spin_lock()
I still cannot catch. According to te
2017年3月27日 上午5:11于 Maxime Ripard 写道：
>
> On Fri, Mar 17, 2017 at 11:34:45AM +0800, Chen-Yu Tsai wrote:
> > On Thu, Mar 16, 2017 at 1:37 AM, Rob Herring wrote:
> > > On Tue, Mar 07, 2017 at 09:56:26AM +0100, Maxime Ripard wrote:
> > >> The Allwinner Timings Controller has two, mutually exclusiv
[+CC drm folks, see the following threads:
http://lkml.kernel.org/r/201703232349.bgb95898.qhlvffomtfo...@i-love.sakura.ne.jp
http://lkml.kernel.org/r/1490352808-7187-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
]
On 03/24/2017 07:17 PM, Matthew Wilcox wrote:
> On Fri, Mar
In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the
'req->mip_levels' array. This array can be assigned any value from
the user space. As both the 'num_sizes' and the array is uint32_t,
it is easy to make 'num_sizes' overflow. The later 'mip_levels' is
used as the loop count. This can
https://bugs.freedesktop.org/show_bug.cgi?id=100395
--- Comment #3 from Andy Furniss ---
Created attachment 130499
--> https://bugs.freedesktop.org/attachment.cgi?id=130499&action=edit
dmesg
dmesg attached, plus a link to an external video of what it looks like.
As seen it's also visible when
https://bugs.freedesktop.org/show_bug.cgi?id=98629
--- Comment #8 from Emil Velikov ---
Hi Brian,
The define is coming from the kernel's drmP.h. Perhaps we should have
explicitly made it part of the public API/ABI, but that won't help here.
In upstream the major is set in drm_core_init()'s
regi
On 28 March 2017 at 10:36, Michel Dänzer wrote:
> On 28/03/17 05:24 PM, Julien Isorce wrote:
> > Hi Michel,
> >
> > About the hard lockup, I noticed that I cannot have it with the
> > following conditions:
> >
> > 1. soft lockup fix (the 0->i change which avoids infinite loop)
> > 2. Your suggest
On Mon, Mar 27, 2017 at 12:11:12PM +0100, Martyn Welch wrote:
> On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> > On Fri, 2017-03-24 at 10:24 +, Martyn Welch wrote:
> > [...]
> > > > Could you move to v4.9 or v4.10 and check if the four patches in
> > > > https://git.pengutroni
A bug that I had fixed earlier just came back, with CONFIG_EXTCON=m,
the rockchip drm driver will fail to link:
drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
cdn-dp-core.c:(.text.cdn_dp_get_port_lanes+0x30): undefined reference to
`extcon_get_state'
cdn-dp-core.c:(.
On 28/03/17 08:45, Jyri Sarha wrote:
> On 03/24/17 11:40, Tomi Valkeinen wrote:
>> DRA7 errata i886 (FPDLink PLL Unlocks With Certain SoC PLL M/N Values)
>> says that FPDLink is sensitive to jitter on the vout clock, and that low
>> PLL M and N values result in more jitter than high M and N values.
https://bugs.freedesktop.org/show_bug.cgi?id=100395
--- Comment #2 from Andy Furniss ---
(In reply to Michel Dänzer from comment #1)
> So this doesn't happen with amdgpu.dc=0?
It's OK with amdgpu.dc=0
--
You are receiving this mail because:
You are the assignee for the bug.
This patch adds simple panel support in stm32_defconfig file
Signed-off-by: Yannick Fertre
---
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 562d351..ae68d9f 100644
--- a/arch/arm/c
Add function drm_fb_cma_get_gem_addr() which return the physical address
of framebuffer (1st pixel). This function will usually be called by plane
callback (atomic_update).
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/drm_fb_cma_helper.c | 27 +++
include/drm/drm_fb_
This patch adds DRM (Direct Rendering Manager) support
in stm32_defconfig file
Signed-off-by: Yannick Fertre
---
arch/arm/configs/stm32_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ac372e3..562d351 100644
Missing field get_unmapped_area which is necessary with device without MMU
Signed-off-by: Yannick Fertre
---
include/drm/drm_gem_cma_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index f962d33..7320b14 100644
---
1 - 100 of 135 matches
Mail list logo
