On 09/22/16 09:18, Daniel Vetter wrote:
> On Wed, Sep 21, 2016 at 06:36:28AM -0700, Sean Paul wrote:
>> Also reorder alphabetically and fix up drm_flip_work header.
>>
>> Signed-off-by: Sean Paul
>
> Reviewed-by: Daniel Vetter
>
Picked this up. Thanks!
Best regards,
Jyri
>> ---
>> drivers/g
Hi Dave,
Please pull these collected fixes and cleanups from various sources. The
request was rebased on top the previous pull tilcdc request tag, so it
contains all the accumulated tilcdc changes for v4.9 so far.
Thanks,
Jyri
The following changes since commit 2e0965b06d90b9dba76198d026c4c2ee044
chment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160923/539572fa/attachment.html>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")
from Linus' tree and commit:
43968d7b806d ("drm: Extract drm_plane.[hc]")
from the drm-misc tree.
I fixed it u
https://bugzilla.kernel.org/show_bug.cgi?id=172421
Roland Scheidegger changed:
What|Removed |Added
CC||rscheidegger at gmx.ch
--- Comment
Turns out assuming that only stuff in uabi is uabi is a bit naive, and
we have a bunch of properties for which the enum values are placed in
random headers. A proper fix would be to split out uapi include
headers, but meanwhile sprinkle at least some warning over them.
Fixes: 532b36712ddf ("drm/do
On Fri, 23 Sep 2016, Daniel Vetter wrote:
> Turns out assuming that only stuff in uabi is uabi is a bit naive, and
> we have a bunch of properties for which the enum values are placed in
> random headers. A proper fix would be to split out uapi include
> headers, but meanwhile sprinkle at least so
On 09/23/2016 12:05 PM, Daniel Vetter wrote:
> Turns out assuming that only stuff in uabi is uabi is a bit naive, and
> we have a bunch of properties for which the enum values are placed in
> random headers. A proper fix would be to split out uapi include
> headers, but meanwhile sprinkle at leas
On Thu, Sep 22, 2016 at 11:44 PM, Jani Nikula
wrote:
> On Fri, 23 Sep 2016, Daniel Vetter wrote:
>> Turns out assuming that only stuff in uabi is uabi is a bit naive, and
>> we have a bunch of properties for which the enum values are placed in
>> random headers. A proper fix would be to split out
On Thu, Sep 22, 2016 at 2:37 PM, Jyri Sarha wrote:
> Hi Dave,
> Please pull these collected fixes and cleanups from various sources. The
> request was rebased on top the previous pull tilcdc request tag, so it
> contains all the accumulated tilcdc changes for v4.9 so far.
>
> Thanks,
> Jyri
>
> Th
On Thu, Sep 22, 2016 at 4:14 PM, Brian Starkey wrote:
> On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
>>
>> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
>> wrote:
>>>
>>> On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
Actually, could you please
On Thu, Sep 22, 2016 at 2:40 PM, Russell King - ARM Linux
wrote:
> Sorry, I thought you were some random person maintaining some random
> tree who'd submitted a pull request to be merged into drm-misc. If
> you are in fact the drm-misc maintainer, please add yourself to the
> MAINTAINERS file so
This reverts commit 6a2925ea12006911c8180a89feda6d040873ed18.
commit 6a2925ea12006911c8180a89feda6d040873ed18
Author: Brian Starkey
Date: Mon Jul 25 11:55:48 2016 +0100
drm/i2c: tda998x: don't register the connector
[seanpaul]
Patch isn't fully baked, and apparently causing issues in hdlc
On Thu, Sep 22, 2016 at 1:24 PM, Dan Carpenter
wrote:
> On Thu, Sep 22, 2016 at 03:11:25PM +0200, SF Markus Elfring wrote:
>> > If you restricted yourself to fixing bugs only then you would maybe fix
>> > more
>> > bugs than you introduce but as it you are making the kernel worse.
>>
>> Would yo
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160923/0d43c18d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=172421
--- Comment #14 from Christian König ---
(In reply to Roland Scheidegger from comment #13)
> Personally I've always thought the risk of damaging hardware with any kind
> of overclocking is just about exactly zero as long as you don't increase
>
> I think the "if (node)" in the of_node_put() is there on purpose,
Yes, of course.
Does such an implementation detail correspond to a general software design
pattern?
> because it potentially saves the caller one extra if()-statement
This can occasionally happen.
> and keeps the caller cod
On 23 September 2016 at 17:25, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 1:24 PM, Dan Carpenter
> wrote:
>> On Thu, Sep 22, 2016 at 03:11:25PM +0200, SF Markus Elfring wrote:
>>> > If you restricted yourself to fixing bugs only then you would maybe fix
>>> > more
>>> > bugs than you introduce
Hi Inki,
These two patches replaces exynos-drm specific mechanism for waiting
for vblanks with the one provided by drm-core.
The patchset has nice diffstat and fixes some issues,
described in datail in patches.
As the patches touches exynos-drm core I have tested them in different
scenarios on di
VIDI driver uses fake vblank handler to generate vblank events.
It was implemented using worker which slept for vblank time, additionally
it did not work if there were no page flips. The patch replaces it with
timer, uses drm_crtc_vblank_(on|off) helpers to manage it and fixes
behavior for non-page
Exynos DRM devices update their registers at vblank time. Exynos-DRM uses
custom mechanism to wait for vblank. This mechanism is error prone -
variables are not updated atomically. As a result in certain circumstances
user space can try to free buffers which are still in use by hardware,
in such ca
>> Would you like to discuss the statistics for my failure (or success) rate
>> a bit more so that involved issues can be clarified in a constructive way?
>
> It should be that you target 20 bug fixes for each new regression
> that you add.
How do you think about to clarify any concrete "regressi
> I will refrain from merging any more style/checkpatch/"code cleanup"
> patches from Markus until we start getting real, tested, bug fixes.
Can such a kind of feedback be also interpreted in the way that you insist
to keep some weaknesses which I tried to point in the Linux source code out
for an
> Markus, please contact the list in advance in future before posting a bunch
> of patches that don't fix any problems.
I am trying to improve various open issues also in Linux source files.
Unfortunately, some of the proposed changes might not fit to your software
development attention at the mo
Maintain a table of regulator names expect by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Cc: dri-devel at lists.freedesktop.org
Cc: Laurent Pinchart
Signed-off-by: Ar
On 09/17/2016 04:47 AM, John Stultz wrote:
> This patch adds support to Audio for both adv7511 and adv7533
> bridge chips.
>
> This patch was originally from [1] by Lars-Peter Clausen
> and was adapted by Archit Taneja and
> Srinivas Kandagatla .
>
> Then I heavily reworked it to use the hdmi-c
On 09/17/2016 04:47 AM, John Stultz wrote:
> From: Srinivas Kandagatla
>
> This patch enables the Audio Data and Clock pads to the adv7533 bridge.
> Without this patch audio can not be played.
>
> Cc: David Airlie
> Cc: Archit Taneja
> Cc: Laurent Pinchart
> Cc: Wolfram Sang
> Cc: Srinivas K
Hi Tobias,
On 06.05.2016 09:48, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> Hi Tobias,
>>
>> On 05/05/2016 07:27 PM, Tobias Jakobi wrote:
>>> Hello,
>>>
>>> here's another issue I experience when enabling FIMD on the ODROID-X2.
>>>
>>> I can trigger a IOMMU pagefault by sta
On Fri, Sep 23, 2016 at 12:18:12AM -0700, Sean Paul wrote:
> This reverts commit 6a2925ea12006911c8180a89feda6d040873ed18.
>
> commit 6a2925ea12006911c8180a89feda6d040873ed18
> Author: Brian Starkey
> Date: Mon Jul 25 11:55:48 2016 +0100
>
> drm/i2c: tda998x: don't register the connector
>
On Fri, Sep 23, 2016 at 09:05:50AM +0200, Daniel Vetter wrote:
> On Thu, Sep 22, 2016 at 4:14 PM, Brian Starkey
> wrote:
> > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> >>
> >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> >> wrote:
> >>>
> >>> On Thu, Sep 22, 2016
First of all please stop sending your patches as a reply to an earlier
and completely unrelated series.
Second please prefix all TTM related patches with "drm/ttm:".
Additional to that I don't really see the point in renaming some of the
jump labels, if you call it "restart" or "lock_restart" d
On 22/09/16 10:22 PM, Christian König wrote:
> Am 22.09.2016 um 15:05 schrieb Daniel Vetter:
>> On Thu, Sep 22, 2016 at 2:44 PM, Christian König
>> wrote:
- explicit fencing: Userspace passes around distinct fence objects for
any work going on on the gpu. The kernel doesn't insert any
> Additional to that I don't really see the point in renaming some of the jump
> labels,
I am suggesting changes for another collateral software evolution.
> if you call it "restart" or "lock_restart" doesn't make much difference.
Do other identifiers fit better to a specification from the doc
On Thu, Sep 22, 2016 at 7:43 AM, Chris Wilson
wrote:
> Currently we use a linear walk to lookup a handle and return a dma-buf,
> and vice versa. A long overdue TODO task is to convert that to a
> hashtable. Since the initial implementation of dma-buf/prime, we now
> have resizeable hashtables we
The udl damage handler is supposed to render 'height' lines, but its
iterator has an obvious typo that makes it miss most lines if the
rectangle does not cover 0/0.
Fix the damage handler to correctly render all lines.
This is a fallout from:
commit e375882406d0cc24030746638592004755ed4ae0
On 09/23/16 10:36, SF Markus Elfring wrote:
>> I think the "if (node)" in the of_node_put() is there on purpose,
>
> Yes, of course.
>
> Does such an implementation detail correspond to a general software design
> pattern?
>
Yes it does. For instance standard malloc()/free() implementation [1]
Am 23.09.2016 um 12:20 schrieb SF Markus Elfring:
>> Additional to that I don't really see the point in renaming some of the jump
>> labels,
> I am suggesting changes for another collateral software evolution.
>
>
>> if you call it "restart" or "lock_restart" doesn't make much difference.
> Do oth
On 09/23/16 09:23, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 2:04 PM, Jyri Sarha wrote:
>> On 09/22/16 09:18, Daniel Vetter wrote:
>>> On Wed, Sep 21, 2016 at 06:36:28AM -0700, Sean Paul wrote:
Also reorder alphabetically and fix up drm_flip_work header.
Signed-off-by: Sean Paul
>
Dave,
Please ignore this pull request. I'll send another soon.
The "drm/tilcdc: Add atomic and crtc headers to crtc.c" is already
coming trough drm-misc.
Best regards,
Jyri
On 09/23/16 00:37, Jyri Sarha wrote:
> Hi Dave,
> Please pull these collected fixes and cleanups from various sources. The
In case of some platforms fimd clocks can be configured to
very low values, as a result refresh rate can be very low and
driver/drm-core will timeout waiting for vblanks, it will result
in premature removal of framebuffers and will cause oopses.
The patch adds atomic_check callback to fimd to preve
>> A special view on software simplicity can also lead to questionable
>> intermediate
>> function implementation, can't it?
>
> I don't really follow. But in any case I do not see anything
> questionable in the current tilcdc_convert_slave_node() implementation.
I identified update candidates t
On Thu, Sep 22, 2016 at 2:38 PM, SF Markus Elfring
wrote:
>>> The of_node_put() function was called in some cases
>>> by the tilcdc_convert_slave_node() function during error handling
>>> even if the passed variable contained a null pointer.
>>>
>>> * Adjust jump targets according to the Linux cod
On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote:
> rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still
> enabled, but we never got the call to turn off the CRTC. Brian is still
> tracking through the fbdev emulation to figure out the cause for that.
fbdev emulation doesn
Noralf accidentally made a small mistake for real subrectangles in his
patch to convert udl to the shared fb dirty handling code.
Fixes: e375882406d0 ("drm/udl: Use drm_fb_helper deferred_io support")
Cc: # v4.7+
Cc: Noralf Trønnes
Cc: Gerd Hoffmann
Signed-off-by: Daniel Vetter
---
drivers/g
ytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160923/268bba3d/attachment.sig>
- 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/20160923/51340f52/attachment.sig>
On Fri, Sep 23, 2016 at 2:32 AM, wrote:
> On Fri, Sep 23, 2016 at 12:18:12AM -0700, Sean Paul wrote:
>> This reverts commit 6a2925ea12006911c8180a89feda6d040873ed18.
>>
>> commit 6a2925ea12006911c8180a89feda6d040873ed18
>> Author: Brian Starkey
>> Date: Mon Jul 25 11:55:48 2016 +0100
>>
>>
> It's just the names like "out" or "restart" perfectly explain why the labels
> exists.
I have got an other impression.
> So they fulfill this requirement from the coding style as far as I can see.
Short identifiers might look more convenient in some cases because
they are quicker to type.
Am 23.09.2016 um 13:07 schrieb SF Markus Elfring:
>> It's just the names like "out" or "restart" perfectly explain why the labels
>> exists.
> I have got an other impression.
>
>
>> So they fulfill this requirement from the coding style as far as I can see.
> Short identifiers might look more conv
> iirc, there are Coccinelle rules that find code with unnecessary null
> checks and removes them.
This kind of software change is not needed here.
I find that a corresponding return value check happens one function call
too late.
> Although you probably made this complex enough that cocinelle
On Fri, Sep 23, 2016 at 7:19 AM, SF Markus Elfring
wrote:
>> iirc, there are Coccinelle rules that find code with unnecessary null
>> checks and removes them.
>
> This kind of software change is not needed here.
>
> I find that a corresponding return value check happens one function call
> too lat
BIT(DRM_REFLECT_X)
> | BIT(DRM_REFLECT_Y));
This fixes the problem... Obviously something gets confused if the
property is created twice. Perhaps the first one gets stored somewhere,
and gets used somehow, even if the latter property is the "real" one,
attached to the plane? Just a guess...
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/20160923/ed1ad629/attachment.sig>
> Calling the label "unlock" instead of "out" is arguable a little better,
Thanks that you can follow a renaming for this direction in principle.
> but nothing I would call a major improvement either.
This was not my intention for such an use case.
I am proposing some small software updates ac
On 09/23/16 14:47, Sean Paul wrote:
> On Fri, Sep 23, 2016 at 3:52 AM, Daniel Schultz
> wrote:
>> When 'component_bind_all' fails it should not try to unbind components
>> in the error handling. This will produce a null pointer kernel panic when
>> no component exist.
>>
>> This patch changes the
On Fri, Sep 23, 2016 at 07:00:25PM +0900, Michel Dänzer wrote:
> On 22/09/16 10:22 PM, Christian König wrote:
> > Am 22.09.2016 um 15:05 schrieb Daniel Vetter:
> >> On Thu, Sep 22, 2016 at 2:44 PM, Christian König
> >> wrote:
> - explicit fencing: Userspace passes around distinct fence obj
>> I see a need to improve not only correctness there but also a bit of
>> software efficiency.
>
> If you can measure any performance difference and present some results
> (esp. considering that this is something that just happens when the
> driver is loaded), then we'll talk.
Are you really int
Am Freitag, den 23.09.2016, 12:58 +0200 schrieb Daniel Vetter:
> On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau
> wrote:
> >
> > rmmod-ing the hdlcd module generates a WARN() splat as the vsync is
> > still
> > enabled, but we never got the call to turn off the CRTC. Brian is
> > still
> > trackin
2016-09-23 Andrzej Hajda :
> VIDI driver uses fake vblank handler to generate vblank events.
> It was implemented using worker which slept for vblank time, additionally
> it did not work if there were no page flips. The patch replaces it with
> timer, uses drm_crtc_vblank_(on|off) helpers to manag
2016-09-23 Andrzej Hajda :
> Exynos DRM devices update their registers at vblank time. Exynos-DRM uses
> custom mechanism to wait for vblank. This mechanism is error prone -
> variables are not updated atomically. As a result in certain circumstances
> user space can try to free buffers which are
Hi Daniel,
On Wednesday 21 Sep 2016 09:31:58 Daniel Vetter wrote:
> On Thu, Sep 08, 2016 at 05:44:26PM +0300, Laurent Pinchart wrote:
> > The driver is the last users of the drm_fb_get_bpp_depth() function. It
> > should ideally be converted to use struct drm_mode_fb_cmd2 instead of
> > the legacy
On Fri, Sep 23, 2016 at 03:40:17PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 21 Sep 2016 09:31:58 Daniel Vetter wrote:
> > On Thu, Sep 08, 2016 at 05:44:26PM +0300, Laurent Pinchart wrote:
> > > The driver is the last users of the drm_fb_get_bpp_depth() function. It
> > > should
On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
>On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote:
>> rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still
>> enabled, but we never got the call to turn off the CRTC. Brian is still
>> tracking through the fbdev
On Mon, Aug 29, 2016 at 08:08:24AM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that
On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that
On Mon, Aug 29, 2016 at 08:08:26AM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that
On Fri, Sep 23, 2016 at 12:20:54PM +0200, SF Markus Elfring wrote:
> > if you call it "restart" or "lock_restart" doesn't make much difference.
>
> Do other identifiers fit better to a specification from the document
> "CodingStyle"
> like the following?
>
> "â¦
> Choose label names which say w
On Mon, Aug 29, 2016 at 08:08:27AM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that
On Mon, Aug 29, 2016 at 08:08:28AM +0100, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that
On Mon, Aug 29, 2016 at 08:08:29AM +0100, Chris Wilson wrote:
> This variant of fence_get_rcu() takes an RCU protected pointer to a
> fence and carefully returns a reference to the fence ensuring that it is
> not reallocated as it does. This is required when mixing fences and
> SLAB_DESTROY_BY_RCU
On Mon, Aug 29, 2016 at 08:08:30AM +0100, Chris Wilson wrote:
> In order to be completely generic, we have to double check the read
> seqlock after acquiring a reference to the fence. If the driver is
> allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
> within an RCU grace pe
On Fri, Sep 23, 2016 at 8:17 AM, SF Markus Elfring
wrote:
>>> I see a need to improve not only correctness there but also a bit of
>>> software efficiency.
>>
>> If you can measure any performance difference and present some results
>> (esp. considering that this is something that just happens whe
Am 23.09.2016 um 13:49 schrieb SF Markus Elfring:
>> Calling the label "unlock" instead of "out" is arguable a little better,
> Thanks that you can follow a renaming for this direction in principle.
>
>
>> but nothing I would call a major improvement either.
> This was not my intention for such an
radeon_cursor_move_unlock() contains a workaround for AVIVO chips that
are older than DCE6 when the cursor ends on 128 pixel boundary. It
decreases the position when the calculated end position is on 128
pixel boundary. However, it hits also the condition where x=-1 and
width=1 are passed, since
On Fri, Sep 23, 2016 at 8:55 AM, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:26AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion
On Fri, Sep 23, 2016 at 12:36:02PM +0200, David Herrmann wrote:
> The udl damage handler is supposed to render 'height' lines, but its
> iterator has an obvious typo that makes it miss most lines if the
> rectangle does not cover 0/0.
>
> Fix the damage handler to correctly render all lines.
>
>
On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote:
> On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau
> > wrote:
> > > rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still
> > > enabled, but we never
Hi Dave,
Please pull these collected fixes and cleanups from various sources. The
request was rebased on top the previous tilcdc pull request tag, so it
contains all the accumulated tilcdc changes for v4.9 so far.
Thanks,
Jyri
The following changes since commit 2e0965b06d90b9dba76198d026c4c2ee044
On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On Thursday, 22 September 2016, Maxime Ripard free-electrons.
> com> wrote:
>
> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> > > The panel should be enabled after the controller so that the panel
On Mon, Aug 29, 2016 at 08:08:31AM +0100, Chris Wilson wrote:
> In order to be completely generic, we have to double check the read
> seqlock after acquiring a reference to the fence. If the driver is
> allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
> within an RCU grace pe
Exynos DRM framework handled page-flip event with custom code.
The patch replaces it with drm-core vblank queue.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
This patch is next step of vblank re-factoring in Exynos-DRM.
I have tested the code on fimd, vidi, decon5433, mixer.
I hope I have not intro
On 23 September 2016 at 09:50, SF Markus Elfring
wrote:
>> Markus, please contact the list in advance in future before posting a bunch
>> of patches that don't fix any problems.
>
> I am trying to improve various open issues also in Linux source files.
>
That the fact that you see issues (in these
Am 23.09.2016 um 14:59 schrieb Daniel Vetter :
>>
>> /**
>> - * fence_put - decreases refcount of the fence
>> - * @fence: [in]fence to reduce refcount of
>> + * fence_get_rcu_safe - acquire a reference to an RCU tracked fence
>> + * @fence: [in]pointer to fence to increase refcount o
On Mon, Aug 29, 2016 at 08:08:32AM +0100, Chris Wilson wrote:
> In order to be completely generic, we have to double check the read
> seqlock after acquiring a reference to the fence. If the driver is
> allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
> within an RCU grace pe
>> Do other identifiers fit better to a specification from the document
>> "CodingStyle"
>> like the following?
>>
>> "â¦
>> Choose label names which say what the goto does or why the goto exists.
>> â¦"
>>
>>
>> Does this wording need any more adjustments?
>
> No.
I have got an other impressi
Am 23.09.2016 um 13:30 schrieb Gustavo Padovan:
> 2016-09-22 Christian König :
>
>> Am 22.09.2016 um 13:16 schrieb Gustavo Padovan:
>>> 2016-09-22 Christian König :
>>>
Dropping the rest of the patch, cause that really doesn't make sense any
more.
Am 22.09.2016 um 12:40 schrie
On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote:
> With the seqlock now extended to cover the lookup of the fence and its
> testing, we can perform that testing solely under the seqlock guard and
> avoid the effective locking and serialisation of acquiring a reference to
> the request.
On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> Currently we install a callback for performing poll on a dma-buf,
> irrespective of the timeout. This involves taking a spinlock, as well as
> unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> multiple threads.
On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote:
> > With the seqlock now extended to cover the lookup of the fence and its
> > testing, we can perform that testing solely under the seqlock guard and
> > avoid the effecti
So users know whether PSR should be enabled or not.
Signed-off-by: Tomeu Vizoso
Cc: Sean Paul
Cc: Yakir Yang
Cc: Archit Taneja
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
include/drm/bridge/analogix_dp.h | 1 +
2 files changed, 9 insertions(+)
diff
There's no point in enabling PSR when the panel doesn't support it.
This also avoids a problem when PSR gets enabled when a CRTC is being
disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
interrupt on which we wait will never arrive. This was observed on
RK3288 with a panel wit
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
> > unnecessary work, and
>> I am trying to improve various open issues also in Linux source files.
>>
> That the fact that you see issues (in these particular cases) while
> others do not
I guess that the discussed "story" affects more challenges in communication
and different opinions about where to invest software devel
On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
>On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote:
>> On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote:
>> > On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau
>> > wrote:
>> > > rmmod-ing the hdlcd module generat
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
> > unnecessary work, and
Hello,
I have already talked to Marek in private about this. The latest runpm patch
(b05984e21a7e000bf5074ace00d7a574944b2c16) cripples G2D operation. I have tried
to come up with a way to fix this and also to improve runpm behaviour while at
it.
Marek pointed out that the current issue, i.e.
The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
operation of the G2D. After this commit the following
happens.
- exynos_g2d_exec_ioctl() prepares a runqueue node and
calls g2d_exec_runqueue()
- g2d_exec_runqueue() calls g2d_dma_start() which gets
runtime PM sync
- runtime PM calls g2d
Tobias Jakobi wrote:
> The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
> operation of the G2D. After this commit the following
> happens.
> - exynos_g2d_exec_ioctl() prepares a runqueue node and
> calls g2d_exec_runqueue()
> - g2d_exec_runqueue() calls g2d_dma_start() which gets
> run
On Thu, Sep 15, 2016 at 12:34:51PM +0300, Jyri Sarha wrote:
> Remove "default" keyword from blue-and-red-wiring devicetree property
> binding document. The code does not support and there is no intention
> to support it.
>
> Reported-by: Rob Herring
> Signed-off-by: Jyri Sarha
> ---
> I sent the
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
> > unnecessary work, and
https://bugzilla.kernel.org/show_bug.cgi?id=172421
--- Comment #15 from Roland Scheidegger ---
(In reply to Christian König from comment #14)
> (In reply to Roland Scheidegger from comment #13)
> > Personally I've always thought the risk of damaging hardware with any kind
> > of overclocking is
1 - 100 of 131 matches
Mail list logo
