Hi Magnus,
On Tuesday 06 Dec 2016 16:07:02 Laurent Pinchart wrote:
> On Wednesday 26 Oct 2016 18:13:23 Magnus Damm wrote:
> > On Wed, Oct 26, 2016 at 4:31 PM, Geert Uytterhoeven wrote:
> >> On Wed, Oct 26, 2016 at 5:31 AM, Magnus Damm wrote:
> >>> From: Magnus Damm
> >>>
> >>> For the DU to oper
On 12/14/2016 11:14 PM, Andrzej Hajda wrote:
> On 14.12.2016 07:04, Hoegeun Kwon wrote:
>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>> panel in the TM2 device.
>>
>> Signed-off-by: Donghwa Lee
>> Signed-off
Even on fast systems a 2 microsecond delay is most likely more efficient
as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
change this to a udelay(2).
Signed-off-by: Nicholas Mc Guire
---
Problem found by coccinelle:
Patch was compile tested with: x86_64_defconfig (implie
usleep_range() is intended for delays in the 10us to 10ms range that need
good precision. a useleep_range(1, will effectively be no more than an
imprecise udelay with some added cache disruption as it will fire more or
less immediately - use udelay() here.
Fixes: commit be4fc046bed3 ("drm/i915: ad
in testing this idea out.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/86bd62fc/attachment-0001.html>
tex, so any code trying to lock that hangs.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/fe378b5e/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/8815c1a4/attachment.html>
er hsync came first, followed by vsync. This old
behavior caused problems at least on one encoder I worked on.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/c0a88d15/attachment.sig>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/eeb14c8d/attachment.html>
part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/e568901a/attachment.sig>
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/9979dc4b/attachment-0001.sig>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node_in_range(), check that we only allocate from
> the specified range.
>
> Signed-off-by: Chris Wilson
With the stylistic changes I proposed to whole series;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joona
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> usleep_range() is intended for delays in the 10us to 10ms range that need
> good precision. a useleep_range(1, will effectively be no more than an
> imprecise udelay with some added cache disruption as it will fire more or
> less immediately - use ud
On Thu, 15 Dec 2016, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> usleep_range() is intended for delays in the 10us to 10ms range that need
>> good precision. a useleep_range(1, will effectively be no more than an
>> imprecise udelay with some added cache disruption as it
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/2a97ad3c/attachment.html>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we can request alignment to any power-of-two or prime using a
> plain drm_mm_node_insert(), and also handle a reasonable selection of
> primes.
>
> Signed-off-by: Chris Wilson
> +static int igt_align(void *ignored)
> +{
> +
overflow on one platform could be defined as something else
> on
> another platform and be mistaken.
>
> Given that we already take the same lock in the IRQ handler to call the wait
> handlers, do you think this is really an issue ?
Yep, I think it's fine for the time being.
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/f0fa6071/attachment.sig>
Hi Bibby,
On Wed, Dec 14, 2016 at 1:14 PM, Bibby Hsieh
wrote:
>
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
>
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> Even on fast systems a 2 microsecond delay is most likely more efficient
> as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> change this to a udelay(2).
Similar concerns as in [1]. We don't need the accuracy of udelay() here
Op 14-12-16 om 14:17 schreef Daniel Vetter:
> On Wed, Nov 16, 2016 at 02:58:04PM +0100, Maarten Lankhorst wrote:
>> Second approach. Instead of trying to convert all drivers straight away,
>> implement all macros that are required to get state working.
>>
>> Current situation:
>> Use obj->state, wh
On Thu, Dec 15, 2016 at 10:59:10AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > Check that we can request alignment to any power-of-two or prime using a
> > plain drm_mm_node_insert(), and also handle a reasonable selection of
> > primes.
> >
> > Signed
On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > Even on fast systems a 2 microsecond delay is most likely more efficient
> > as a busy-wait loop. The overhead of a hrtimer does not seem warranted -
> > change this to a udelay(2).
>
On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> > On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > > Even on fast systems a 2 microsecond delay is most likely more efficient
> > > as a busy-wait loop. The overhead of
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to the eviction scanner in order to
> find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> + if ((int)tmp.start % n || tmp.size != nsize ||
> tmp.hole_foll
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:47:57AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > usleep_range() is intended for delays in the 10us to 10ms range that need
>> > good precision. a useleep_range(1, will effectively be
On 12/14/2016 03:30 PM, Sean Paul wrote:
> On Wed, Dec 14, 2016 at 12:03 AM, Archit Taneja
> wrote:
>> Hi,
>>
>> On 12/12/2016 08:28 PM, Sean Paul wrote:
>>>
>>> On Fri, Dec 9, 2016 at 9:49 PM, Caesar Wang wrote:
Look likes, the BOE panel FW didn't ack the DPCD600 signal from the hos
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that we add arbitrary blocks to a restrited eviction scanner in
> order to find the first minimal hole that matches our request.
>
> Signed-off-by: Chris Wilson
> +static int igt_evict_range(void *ignored)
> +{
> + drm_for_ea
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > Even on fast systems a 2 microsecond delay is most likely more efficient
>> > as a busy-wait loop. The overhead of a hrtimer does not
iar with it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/be632a35/attachment.html>
Hi Tomi,
On Thursday 15 Dec 2016 10:08:47 Tomi Valkeinen wrote:
> On 14/12/16 17:05, Tony Lindgren wrote:
> > * Laurent Pinchart [161213 15:38]:
> >> The series will be annoying to merge given how interleaved the ARM and
> >> driver patches are. The easiest solution would be to merge everything
>
On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> >> > Even on fast systems a 2 microsecond delay is most likely more ef
On Thu, 15 Dec 2016, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> >> > Even on fast s
With checks! This will allow safe access to the current state,
while ensuring that the correct locks are held.
Changes since v1:
- Constify returned states.
- Require plane lock to return plane state, don't allow crtc_lock to
be sufficient.
Changes since v2:
- Include drmP.h for drm_device, chan
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161215/5d6ac1fb/attachment.html>
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that after applying the driver's color adjustment, fitting of the
> node and its alignment are still correct.
>
> Signed-off-by: Chris Wilson
> +static void no_color_touching(struct drm_mm_node *node,
> + Â Â Â Â
signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/29af53df/attachment.sig>
Am Mittwoch, den 14.12.2016, 09:53 +0100 schrieb Wladimir J. van der
Laan:
> - Add PS.INST_ADDR and VS.INST_ADDR: GC3000 loads shader code from these
> addresses if ICACHE
> is enabled.
>
> - Add new NFE vertex stream addresses.
Please resend with a proper Signed-off-by line. I can't take a patc
Am Mittwoch, den 14.12.2016, 09:39 +0100 schrieb Wladimir J. van der
Laan:
> Set up the PULSE_EATER register (0x0010C) in etnaviv_gpu_hw_init. This
> ports three mostly undocumented model/revision-specific register
> overrides from the Vivante kernel driver.
>
> This is relevant as at least the "d
On 15 December 2016 at 07:30, Nath, Arindam wrote:
>>-Original Message-
>>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>>Sent: Wednesday, December 14, 2016 9:26 PM
>>To: Nath, Arindam
>>Cc: David Airlie; Deucher, Alexander; amd-gfx mailing list; ML dri-devel;
>>Koenig, Christian
From: Thierry Reding
drm_event_reserve_init_locked() is the correct function to call when
already holding the dev->event_lock lock.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/driv
On Thu, Dec 15, 2016 at 11:51 AM, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 10:27:59AM +0100, Daniel Vetter wrote:
>> On Thu, Dec 15, 2016 at 10:25:19AM +0100, Daniel Vetter wrote:
>> > On Thu, Dec 15, 2016 at 11:08:49AM +0200, Jani Nikula wrote:
>> > > On Thu, 15 Dec 2016, Nicholas Mc Gu
From: Thierry Reding
Ever since support for vblank handling and event processing was added to
libdrm (v2.4.16), events were read in 1 KiB chunks in drmHandleEvent().
In addition, the implementation of drm_read() will not unqueue events if
they can't be successfully passed to userspace. The result
On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
>> On Thu, 15 Dec 2016, Ville Syrjälä
>> wrote:
>> > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
>> >> On Thu, 15 Dec 2016, Nicholas Mc Guire wrote:
>> >> > On Thu, De
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
crtc_state after commit. Move it to atomic_state->crtcs.
Also stop re-using new_crtc_state->enable, we can now simply set a
bitmask with crtc_crtc_mask.
Changes since v1:
- Keep last_vblank_count in __drm_crtc_state.
---
diff
On Thu, Dec 15, 2016 at 10:34:00AM +, Nicholas Mc Guire wrote:
> On Thu, Dec 15, 2016 at 12:20:01PM +0200, Jani Nikula wrote:
> > On Thu, 15 Dec 2016, Ville Syrjälä
> > wrote:
> > > On Thu, Dec 15, 2016 at 11:52:34AM +0200, Jani Nikula wrote:
> > >> On Thu, 15 Dec 2016, Nicholas Mc Guire w
On Thu, Dec 15, 2016 at 12:48:34PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Ever since support for vblank handling and event processing was added to
> libdrm (v2.4.16), events were read in 1 KiB chunks in drmHandleEvent().
> In addition, the implementation of drm_read() will not un
- Add PS.INST_ADDR (0x01028) and VS.INST_ADDR (0x0086C): GC3000 loads
shader code from these addresses if ICACHE is used.
- Add new NFE vertex stream addresses (0x14600).
- Add PE Multple Render Target pipe addresses (0x14800).
- Add TS Multiple Render Target pipe addresses (0x017C0, 0x17E0).
On Thu, Dec 15, 2016 at 12:36:02PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> drm_event_reserve_init_locked() is the correct function to call when
> already holding the dev->event_lock lock.
>
> Signed-off-by: Thierry Reding
Pushed to drm-misc-next, thanks.
-Daniel
> ---
> driv
Set up the PULSE_EATER register (0x0010C) in etnaviv_gpu_hw_init. This
ports three mostly undocumented model/revision-specific register
overrides from the Vivante kernel driver.
This is relevant as at least the "disable internal DFS" for revisions >
0x5420 has shown to have a huge impact on shader
gnature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/52a6e22e/attachment.sig>
On Thu, Dec 15, 2016 at 1:47 PM, Nath, Arindam wrote:
>>-Original Message-
>>From: Emil Velikov [mailto:emil.l.velikov at gmail.com]
>>Sent: Thursday, December 15, 2016 5:01 PM
>>To: Nath, Arindam
>>Cc: David Airlie; Deucher, Alexander; amd-gfx mailing list; ML dri-devel;
>>Koenig, Christi
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range effic
On Thu, 15 Dec 2016, Thierry Reding wrote:
> From: Thierry Reding
>
> Ever since support for vblank handling and event processing was added to
> libdrm (v2.4.16), events were read in 1 KiB chunks in drmHandleEvent().
> In addition, the implementation of drm_read() will not unqueue events if
> the
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Build the struct drm_mm selftests so that we can trivially run them
> within our CI.
>
> Signed-off-by: Chris Wilson
"Enable debug, become developer."
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technolog
1,6 +433,10 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
>
> DBG("%s: GO", omap_crtc->name);
>
> + dispc_mgr_go(omap_crtc->channel);
> +
> + WARN_ON(drm_crtc_vblank_get(crtc) != 0);
I don't like this style very much. I
nsertions(+), 22 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/54eba3d3/attachment.sig>
bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/24bc7262/attachment-0001.sig>
On Thu, Dec 15, 2016 at 02:28:32PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> > @@ -799,7 +706,7 @@ bool drm_mm_scan_add_block(struct drm_mm_scan *scan,
> > Â if (adj_end <= adj_start || adj_end - adj_start < scan->size)
> > Â return false;
>
igital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/6c1985fc/attachment.sig>
On 11/16/2016, 02:12 PM, Gerd Hoffmann wrote:
> On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote:
>> On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote:
>>> On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote:
On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> Hi,
>
>
ions(+), 8 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/
On Wed, Dec 14, 2016 at 11:37:46PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 18, 2016 at 09:52:36PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Second installment of my effort to remove the duplicated
> > depth/bpp/pixel_format from drm_framebuffer and ju
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30762 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/d337150a/attachment-0001.gz>
Am 15.12.2016 um 13:33 schrieb Nath, Arindam:
>> -Original Message-
>> From: Grazvydas Ignotas [mailto:notasas at gmail.com]
>> Sent: Thursday, December 15, 2016 5:52 PM
>> To: Nath, Arindam
>> Cc: Emil Velikov; David Airlie; Deucher, Alexander; ML dri-devel; amd-gfx
>> mailing list; Koenig
From: Ville Syrjälä
Apparently my arm .config had reverted to CMA=n at some point, so I
failed to notice that I typoed the code. Fix it up so that the
cma helper will compile again.
Reported-by: kbuild test robot
Cc: Laurent Pinchart
Fixes: ca984a998ad3 ("drm/fb_cma_helper: Replace drm_forma
There were some issues in i915 preventing rmfb from working correctly.
A lot of them are related to hw readout, some others due to keeping
crtc active during driver unload:
https://intel-gfx-ci.01.org/CI/Trybot_394/
I fixed the POWER_DOMAIN_AUDIO issue because it was easy to do so,
but ignored th
From: Daniel Vetter
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied f
We may keep the crtc's enabled when userspace unsets all framebuffers but
keeps the crtc active. This exposes a WARN in fbc_global disable, and
a lot of bugs in our hardware readout code. Solve this by disabling
all crtc's for now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_d
If the crtc was brought up with audio before the driver loads,
then crtc_disable will remove a refcount to audio that doesn't exist
before.
Fortunately we already set power domains on readout, so we can just add
the power domain handling to get_crtc_power_domains, which will update
the power domai
drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
different from commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 60697482b94c..d1d25
Hi Ville,
Thank you for the patch.
On Thursday 15 Dec 2016 16:29:27 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently my arm .config had reverted to CMA=n at some point, so I
> failed to notice that I typoed the code. Fix it up so that the
> cma helper will compile
On 2016-12-13 06:08 PM, Daniel Vetter wrote:
> Mostly nothing special (except making sure that really all error paths
> and friends call iter_put).
>
> v2: Don't forget the raw connector_list walking in
> drm_helper_move_panel_connectors_to_head. That one unfortunately can't
> be converted to the i
On Thu, Dec 15, 2016 at 04:31:58PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Thursday 15 Dec 2016 16:29:27 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently my arm .config had reverted to CMA=n at some point, so I
> > faile
On Thu, Dec 15, 2016 at 04:31:58PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Thursday 15 Dec 2016 16:29:27 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently my arm .config had reverted to CMA=n at some point, so I
> > faile
Hi Tomi,
On Thursday 15 Dec 2016 14:52:47 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > Instead of going through a complicated private IRQ registration
> > mechanism, handle the vblank interrupt activation with the standard
> > drm_crtc_vblank_get() and drm_crtc_vblank_put
On Thu, 15 Dec 2016, Laurent Pinchart
wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Thursday 15 Dec 2016 16:29:27 ville.syrjala at linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Apparently my arm .config had reverted to CMA=n at some point, so I
>> failed to notice that I typoed
ect, as I expect
WARN_ON() to be just a check, like assert(). So when reading the code, I
skip the WARN_ONs.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/a142350b/attachment.sig>
On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> different from commit.
>
> Signed-off-by: Maarten Lankhorst
I think it'd be good to update the kerneldoc for the atomic_commit
callback to mention that driver
t
drm_format_name_buf format_name;
488546fc Laurent Pinchart 2016-10-18 81
b3c11ac2 Eric Engestrom 2016-11-12 82DRM_DEBUG_KMS("non-RGB
pixel format %s\n",
:: The code at line 74 was first introduced by commit
:: 1de72faf10c367d80039761dca5f761b42abca01 drm/kms-helpers: Extract
drm_modeset_helper.[hc]
:: TO: Daniel Vetter
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/b8a7dfad/attachment-0001.gz>
-
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38581 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/068967cf/attachment-0001.gz>
Hi,
I have been reading the ongoing discussion about what to do about AMD DC
(Display Core) with great interest since I have started to put more time into
developing OpenChrome DRM for VIA Technologies Chrome IGP.
I particularly enjoyed reading what Tony Cheng wrote about what is going on
insid
On Thu, Dec 15, 2016 at 04:31:58PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Thursday 15 Dec 2016 16:29:27 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently my arm .config had reverted to CMA=n at some point, so I
> > faile
On Thu, Dec 15, 2016 at 12:51:42PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
> crtc_state after commit. Move it to atomic_state->crtcs.
>
> Also stop re-using new_crtc_state->enable, we can now simply set a
> bitmask with crtc_crtc_mas
Mostly nothing special (except making sure that really all error paths
and friends call iter_put).
v2: Don't forget the raw connector_list walking in
drm_helper_move_panel_connectors_to_head. That one unfortunately can't
be converted to the iterator helpers, but since it's just some list
splicing
On 2016-12-13 06:08 PM, Daniel Vetter wrote:
> Only static connectors should be left at this point, and we should be
> able to clean them out by simply dropping that last reference still
> around from drm_connector_init.
>
> If that leaves anything behind then we have a driver bug.
>
> Doing the fi
Op 15-12-16 om 16:55 schreef Daniel Vetter:
> On Thu, Dec 15, 2016 at 12:51:42PM +0100, Maarten Lankhorst wrote:
>> Stop relying on a per crtc_state last_vblank_count, we shouldn't touch
>> crtc_state after commit. Move it to atomic_state->crtcs.
>>
>> Also stop re-using new_crtc_state->enable, we
Reviewed-by: Harry Wentland:
On 2016-12-15 10:58 AM, Daniel Vetter wrote:
> Mostly nothing special (except making sure that really all error paths
> and friends call iter_put).
>
> v2: Don't forget the raw connector_list walking in
> drm_helper_move_panel_connectors_to_head. That one unfortunatel
From: Ville Syrjälä
drm_modeset_helper.c:74: warning: No description found for parameter 'dev'
Cc: Laurent Pinchart
Cc: Alex Deucher
Fixes: a3f913ca9892 ("drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modeset_helper.c | 1 +
1
Fix a bunch of related crashes in amdgpu that occur when shadow page tables
are kicked out of the GART.
One of the issues was that during command submission, we rely on a
device-global evictions counter to skip some of the work of page-table
validation. The driver was never informed of evictions f
From: Nicolai Hähnle
Ensure that the driver can listen to evictions even when they don't take the
path through ttm_bo_driver::move.
This is crucial for amdgpu, which relies on an eviction counter to skip
re-binding page tables when possible.
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
non-shadow page tables using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
From: Nicolai Hähnle
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 4306b2f..15a723a 100644
--- a/drivers/g
From: Nicolai Hähnle
This catches evictions of shadow page tables from the GART. Since shadow
page tables are always stored in system memory, amdgpu_bo_move is never
called for them.
This fixes a crash during command submission that occurs when only a shadow
page table and no other BOs were evi
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm when shadow the page directory is swapped out.
Clean up the check for non-shadow BOs as well using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
> -Original Message-
> From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at
> linux.intel.com]
> Sent: Thursday, December 15, 2016 12:01 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Laurent Pinchart; Deucher, Alexander
> Subject: [PATCH] drm: Fix kernel docs for drm_helper_
Hi Ville,
Thank you for the patch.
On Thursday 15 Dec 2016 19:01:28 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_modeset_helper.c:74: warning: No description found for parameter 'dev'
>
> Cc: Laurent Pinchart
> Cc: Alex Deucher
> Fixes: a3f913ca9892 ("drm: Pass 'de
On Thu, Dec 15, 2016 at 05:12:26PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at
> > linux.intel.com]
> > Sent: Thursday, December 15, 2016 12:01 PM
> > To: dri-devel at lists.freedesktop.org
> > Cc: Laurent Pinc
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the
non-shadow page tables using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
On Thu, Dec 15, 2016 at 07:55:54PM +0100, Jason A. Donenfeld wrote:
> On most platforms, there exists this ifdef:
>
> #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
>
> This makes this patch functionally useless. However, on PPC, there is
> actually an explicit definition of atomic_
On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen
wrote:
> Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan.
>
> ...
>
> I just don't have time to even pretend I maintain fbdev, so mark it as Orphan.
>
> Anyone want to pick fbdev maintainership?
I'll keep an eye on the mail
1 - 100 of 122 matches
Mail list logo
