From: Ville Syrjälä
To help with debugging i2c-over-aux issues, add a module parameter than
can be used to tweak the assumed i2c bus speed, and thus the maximum
number of retries we will do for each aux message.
Cc: Simon Farnsworth
Cc: moosotc at gmail.com
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Calculate the number of retries we should do for each i2c-over-aux
message based on the time it takes to perform the i2c transfer vs. the
aux transfer. We assume the shortest possible length for the aux
transfer, and the longest possible (exluding clock stretching) for the
i
From: Ville Syrjälä
Currently we react to native and i2c defers by waiting either 400-500 us
or 500-600 us, depending on which code path we take. Consolidate them
all to one define AUX_RETRY_INTERVAL which defines the minimum interval.
Since we've been using two different intervals pick the lon
All three patches are:
Reviewed-by: Simon Farnsworth
I'd consider making the upper limit of AUX_RETRY_INTERVAL a define as well, but
that's just nit-picking and not worth respinning the patches.
Simon
On Wednesday 26 Aug 2015 22:55:07 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj
https://bugzilla.kernel.org/show_bug.cgi?id=103561
Bug ID: 103561
Summary: unable to handle kernel paging request with csgo in
wine+nine, ttm_bo_del_from_lru
Product: Drivers
Version: 2.5
Kernel Version: 4.2-rc8
Hardwar
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #17 from Alex Deucher ---
Maybe something with the audio driver? This doesn't seem to be a GPU driver
issue.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.
I've put this into the core since right now no helper or driver copes
with it, no user
On Wed, Aug 26, 2015 at 12:50:44PM -0300, Gustavo Padovan wrote:
> Hi,
>
> What about this patch? We need it to avoid the WARN_ON added by patch
> 2/2 that was already picked up by Daniel.
That patch is only for 4.4, so not too time critical to get the exynos one
in. But might be good to get it i
On Wed, Aug 26, 2015 at 01:38:36PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
> wrote:
> > On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
> >> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> >> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter >>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/067af358/attachment-0001.html>
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WA
This function is meant to be used with dma-buf mmap, when finishing the CPU
access of the mapped pointer.
The error case should be rare to happen though, requiring the buffer become
active during the sync period and for the end_cpu_access to be interrupted. So
we use a uninterruptible mutex_lock t
This is my (failed) attempt to make the SYNC_* mandatory. I've tried to revoke
write access to the mapped region until begin_cpu_access is called.
The tasklet schedule order seems alright but the whole logic is not working and
I guess it's something related to the fs trick I'm trying to do with th
From: Daniel Vetter
The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc
This patch removes range-based information used for optimizations in
begin_cpu_access and end_cpu_access.
We don't have any user nor implementation using range-based flush. It seems a
consensus that if we ever want something like that again (or even more robust
using 2D, 3D sub-range regions) we c
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write a
Lot's of discussion since v4, thanks for your feedback:
http://lists.freedesktop.org/archives/dri-devel/2015-August/088259.html
The two main concerns was about range-based flush (which we decided to
postpone) and about making the SYNC ioctl mandatory. I need you guys guiding
and educating me on t
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/cb5c74d7/attachment.html>
On Wed, Aug 26, 2015 at 3:59 PM, Dave Airlie wrote:
> On 27 August 2015 at 00:30, Rob Herring wrote:
>> On Wed, Aug 26, 2015 at 7:09 AM, Thierry Reding
>> wrote:
>>> On Wed, Aug 26, 2015 at 01:52:29PM +0200, Daniel Vetter wrote:
On Tue, Aug 25, 2015 at 04:42:18PM -0400, Rob Clark wrote:
>>>
On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
> > wrote:
> >> Very strictly speaking this is possible if you have special hw and
> >> genlocked CRTCs. In general switching a plan
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #16 from Lorenzo Bona ---
Any hint on this?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, Aug 26, 2015 at 05:41:23PM +0200, Daniel Vetter wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put th
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/0285473d/attachment-0001.html>
Hi,
overall it looks to me like this binding is modeled after the Linux DRM
abstractions. Instead, the device nodes should be modeled after the
hardware.
Describing each function block as a separate device node is probably not
the best choice, as would be combining all devices in the mmsys range
Hi Dave,
radeon and amdgpu fixes for 4.3:
- DP fixes for radeon and amdgpu
- IH ring fix for tonga and fiji
- Lots of GPU scheduler fixes
- Misc additional fixes
The following changes since commit aaba64487a96df6584a05d8898634307f3c86790:
Merge branch 'drm-next-fsl-dcu' of
https://github.com/
On 08/26/2015 05:07 PM, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
>> On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
>>>
>>>
>>> On 08/26/2015 10:42 AM, Archit Taneja wrote:
On 08/25/2015 07:15 PM, Daniel Vetter wrote:
On Wed, Aug 26, 2015 at 3:49 PM, Daniel Vetter
wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
>
> I've put this into
On 08/26/2015 05:04 PM, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
>>
>>
>> On 08/26/2015 10:42 AM, Archit Taneja wrote:
>>>
>>>
>>> On 08/25/2015 07:15 PM, Daniel Vetter wrote:
Faster than recompiling.
Note that restore_fbdev_mode_unlocke
Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.
I've put this into the core since I really couldn't come up with a
case where we don't
On 08/26/2015 09:20 AM, Michal Hocko wrote:
> On Tue 25-08-15 15:03:00, Eric B Munson wrote:
> [...]
>> Would you drop your objections to the VMA flag if I drop the portions of
>> the patch that expose it to userspace?
>>
>> The rework to not use the VMA flag is pretty sizeable and is much more
>>
On Wed, 2015-08-26 at 18:53 +0300, Ville Syrjälä wrote:
> On Wed, Aug 26, 2015 at 05:41:23PM +0200, Daniel Vetter wrote:
> > Very strictly speaking this is possible if you have special hw and
> > genlocked CRTCs. In general switching a plane between two active
> > CRTC
> > just won't work so well
On Wed, Aug 26, 2015 at 04:38:14PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 26, 2015 at 04:31:50PM -0400, Jerome Glisse wrote:
> > On Wed, Aug 26, 2015 at 03:44:52PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> > > > On Wed, Aug
On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
> On 08/26/2015 09:58 AM, Daniel Vetter wrote:
> >The other is that right now there's no user nor implementation in sight
> >which actually does range-based flush optimizations, so I'm pretty much
> >expecting we'll get it wrong. Maybe
On 08/26/2015 04:32 PM, Tiago Vignatti wrote:
> On 08/26/2015 09:58 AM, Daniel Vetter wrote:
>> The other is that right now there's no user nor implementation in sight
>> which actually does range-based flush optimizations, so I'm pretty much
>> expecting we'll get it wrong. Maybe instead we should
On Wed, Aug 26, 2015 at 04:31:50PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:44:52PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> > > On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Aug
On Wed, Aug 26, 2015 at 03:44:52PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> > On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> > > > Fro
With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.
Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set
Hi Daniel,
On Tue, Aug 25, 2015 at 10:21:20AM +0200, Daniel Vetter wrote:
> On Tue, Aug 25, 2015 at 09:36:47AM +0200, Lukas Wunner wrote:
> > I've overhauled locking once more because previously all EDID reads
> > were serialized even on machines which don't use vga_switcheroo at all.
> > Seems it
On Wed, Aug 26, 2015 at 03:26:42PM -0400, Jerome Glisse wrote:
> On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> > > From: Jérôme Glisse
> > >
> > > Some device like GPU do things differently if
> 26 aug 2015 kl. 16:58 skrev Tiago Vignatti :
>
>> On 08/26/2015 11:51 AM, Daniel Vetter wrote:
>>> On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
On 08/26/2015 09:58 AM, Daniel Vetter wrote:
The other is that right now there's no user nor implementation in sight
>>
On Wed, Aug 26, 2015 at 03:02:31PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> > From: Jérôme Glisse
> >
> > Some device like GPU do things differently if swiotlb is in use. We
> > use to rely on swiotlb_nr_tbl() to know if swio
This patch adds support for atomic page flip. User can specify -V option
with the plane id for testing atomic page flipping.
---
tests/modetest/modetest.c | 153 --
1 file changed, 149 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c
This patch adds support for atomic modeset. Using -a option, user can
make modeset to use DRM_IOCTL_MODE_ATOMIC instead of legacy IOCTLs.
Also, by using -w option, user can set the property as before.
Signed-off-by: Hyungwon Hwang
---
tests/modetest/modetest.c | 221 +
Modetest gets the property name from user to set it. So the name must be
converted to its id. Until now, this is done in the set_property(). But to
support atomic modeset in modetest, this logic should be separated from the
fuction, because atomic modeset and legacy modeset use different IOCTLs.
S
> 2015-08-26 9:55 GMT-04:00 :
>> Hi Archit,
>>
>>> mdp5_hw_init and mdp5_set_irqmask configure registers but may not have
>>> clocks enabled.
>>>
>>> Add mdp5_enable/disable calls in these funcs to ensure clocks are
>>> enabled. We need this until we get proper runtime pm support.
>>>
>>> Signed-o
On Wed, Aug 26, 2015 at 02:52:02PM -0400, jglisse at redhat.com wrote:
> From: Jérôme Glisse
>
> Some device like GPU do things differently if swiotlb is in use. We
> use to rely on swiotlb_nr_tbl() to know if swiotlb was enabled or not
> but this is unreliable. Patch add a simple helpers to ch
On Wed, Aug 26, 2015 at 02:28:30PM +0200, Thomas Hellstrom wrote:
> On 08/26/2015 02:10 PM, Daniel Vetter wrote:
> > On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
> >> Hi, Tiago.
> >>
> >> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
> >>> From: Daniel Vetter
> >>>
> >>> The u
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
We can not rely on swiotlb_nr_tbl() to know if swiotlb is in use or
not for our device. Use the new helper to determine that.
Signed-off-by: Jérôme Glisse
Cc: Konrad Rzeszutek Wilk
Cc: Alex Deucher
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: lkml at vger.kernel.org
Cc: Daniel
From: Jérôme Glisse
Some device like GPU do things differently if swiotlb is in use. We
use to rely on swiotlb_nr_tbl() to know if swiotlb was enabled or not
but this is unreliable. Patch add a simple helpers to check if any of
the dma_ops associated with a device points to the swiotlb function
So this is only build tested as i am away from hardware right now.
Idea is to provide reliable way to check if swiotlb is in use for
a device or not. It seems swiotlb_nr_tbl() is no longer reliable
for that.
Please test.
Cheers,
Jérôme Glisse
On Wed, Aug 26, 2015 at 05:59:14PM +0530, Archit Taneja wrote:
>
>
> On 08/26/2015 05:07 PM, Daniel Vetter wrote:
> >On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
> >>On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
> >>>
> >>>
> >>>On 08/26/2015 10:42 AM, Archit Ta
From: Gustavo Padovan
Now that atomic modesetting is implemented for exynos enable the
DRIVER_ATOMIC flag on the driver's features.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/e
From: Gustavo Padovan
Exynos atomic commit procedures already does this job of waiting for
pending updates to finish, that means using pending_flip_queue is
pointless now because the disable CRTC procedure will never happen
during a page_flip.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm
From: Gustavo Padovan
Add infrastructure to wait for all planes updates to finish by using
an atomic_t variable to track how many pending updates we are waiting
plus a wait_queue for the wait part.
It also changes vblank behaviour and keeps it enabled for all types
of updates
Signed-off-by: Gus
On Wed, Aug 26, 2015 at 12:11:56PM +0100, simon.farnsworth at onelan.com wrote:
> On Tuesday 25 August 2015 18:10:14 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Calculate the number of retries we should do for each i2c-over-aux
> > message based on the time it takes
From: Gustavo Padovan
The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will now schedule a work task to run the update later.
It also serializes commits that needs to run on the same cr
From: Gustavo Padovan
fimd_update_plane() programs BUF_START[win] and during the update
BUF_START[win] is copied to BUF_START_S[win] (its shadow register)
and starts scanning out, then it raises a irq.
The fimd_irq_handler, in the case we have a pending_fb, will check
the fb value was copied to
From: Gustavo Padovan
This macro is need to get the value of the START shadow register, that
will tell if an framebuffer is currently displayed on the screen or not.
Signed-off-by: Gustavo Padovan
---
include/video/samsung_fimd.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/vide
From: Gustavo Padovan
The current code was ignoring the end of update for all overlay planes,
caring only for the primary plane update in case of pageflip.
This change adds a change to start to check for pending updates for all
planes through exynos_plane->pending_fb. At the start of plane updat
From: Gustavo Padovan
Only set/clear the update bit in the CRTC's .atomic_begin()/flush()
so all planes are really committed at the same time.
Signed-off-by: Gustavo Padovan
---
v2: rename prepare_plane/cleanup_plane to atomic_begin/atomic_flush
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |
From: Gustavo Padovan
.atomic_begin() and .atomic_flush() allows to perform extra operations
before and after the update of planes. For FIMD for example this will
be used to enable disable the shadow protection bit.
Signed-off-by: Gustavo Padovan
---
v2: rename prepare_plane/cleanup_plane to a
From: Gustavo Padovan
Unify handling of finished plane update to prepare for a following patch
that will check for the START and START_S regs to really make sure that
the plane was updated.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 +-
1 file chan
From: Gustavo Padovan
Only set/clear the update bit in the CRTC's .atomic_begin()/flush()
so all planes are really committed at the same time.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 57 +++-
1 file changed, 34 insertions(+), 23
From: Gustavo Padovan
struct drm_crtc already stores the enabled state of the crtc
thus we don't need to replicate enabled in exynos_drm_crtc.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
2 f
From: Gustavo Padovan
Hi,
This patchset adds a couple of changes to improve atomic modesetting:
* add check for the START shadow register for FIMD to only finish the update
when the screen was actually updated.
* add asynchronous atomic commit, so now page flips can be run asynchronously.
I
Hi Dave
Here are some fixes and some new features for rockchip drm,
tested on popmetal rk3288 board, can you land them?
The following changes since commit db56176025cee5e242dfeed5f4e304d095d29fa3:
Revert "drm/atomic: Call ww_acquire_done after check phase is
complete" (2015-08-25 17
There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 31 +--
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 fi
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f10a4724b841..60dca34d2f0f 100644
--- a/drivers/gpu/drm/i915/intel_d
Cc: Thierry Reding
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 499e9f625aef..8c52d0ef1fc9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_he
On Wed, Aug 26, 2015 at 2:22 PM, Werner Johansson
wrote:
>
> On Aug 26, 2015 10:46, "Rob Clark" wrote:
>>
>> btw, w/ some of these clk rounding issues, I suspect we need 'struct
>> drm_display_mode' to be able to represent mode clock with greater
>> accuracy than Khz..
>
> Interesting point! Howe
On 08/26/2015 02:10 PM, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
>> Hi, Tiago.
>>
>> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
>>> From: Daniel Vetter
>>>
>>> The userspace might need some sort of cache coherency management e.g. when
>>> CPU
>>>
On 08/26/2015 10:42 AM, Archit Taneja wrote:
>
>
> On 08/25/2015 07:15 PM, Daniel Vetter wrote:
>> Faster than recompiling.
>>
>> Note that restore_fbdev_mode_unlocked is a bit special and the only
>> one which returns an error code when fbdev isn't there - i915 needs
>> that one to not fall over
On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote:
> Hi, Tiago.
>
> On 08/26/2015 02:02 AM, Tiago Vignatti wrote:
> > From: Daniel Vetter
> >
> > The userspace might need some sort of cache coherency management e.g. when
> > CPU
> > and GPU domains are being accessed through dma-b
me
principles that the host1x infrastructure uses could be implemented in a
similar way for other DRM drivers. You can easily collect information
about subdevices by walking the device tree and matching on known
compatible strings. And you can also instantiate the top-level device
from driver code rather than have it in DT. It should still be possible
to make this work without an artificial device node in DT. The component
and master infrastructure is largely orthogonal to that, and as far as I
remember the only blocker is the need for a top-level device. I wonder
if perhaps this could be made to work by binding the master to the top-
level SoC device.
Obviously adding the node in DT is easier, but to my knowledge easy has
never been a good excuse for mangling DT. Perhaps that's different these
days...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/23936e24/attachment-0001.sig>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/846a7a0d/attachment-0001.html>
On Tue, Aug 25, 2015 at 9:11 PM, Rob Clark wrote:
> On Tue, Aug 25, 2015 at 3:05 AM, Daniel Vetter wrote:
>> On Wed, Aug 19, 2015 at 03:00:04PM -0400, Rob Clark wrote:
>>> On Tue, Apr 7, 2015 at 2:09 PM, Jilai Wang wrote:
>>> So one thing that I wanted sorting out before we let userspace see
>>>
On 26 August 2015 at 09:16, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit c86dabfc9f04 ("omap: zero is a valid fd number, treat it as
> such") corrected checks for valid file descriptors, but the OMAP buffer
> object code initializes the DMA-BUF file descriptor to 0 (as a result of
> ca
On Wed, Aug 26, 2015 at 1:53 PM, Ville Syrjälä
wrote:
> On Wed, Aug 26, 2015 at 01:38:36PM -0400, Rob Clark wrote:
>> On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
>> wrote:
>> > On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
>> >> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark
>
Hi Archit,
> mdp5_hw_init and mdp5_set_irqmask configure registers but may not have
> clocks enabled.
>
> Add mdp5_enable/disable calls in these funcs to ensure clocks are
> enabled. We need this until we get proper runtime pm support.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm
On Tue, Aug 25, 2015 at 04:42:18PM -0400, Rob Clark wrote:
> On Mon, Aug 24, 2015 at 9:47 AM, Rob Herring wrote:
> > On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt wrote:
> >> Stephen Warren writes:
> >>
> >>> On 08/12/2015 06:56 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt
> >>>
> >>
next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/6ac61672/attachment.sig>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/91186538/attachment.html>
On Tue, Aug 25, 2015 at 03:35:58PM -0400, Rob Clark wrote:
> Add support for using atomic code-paths for restore_fbdev_mode().
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 131
> +---
> drivers/gpu/drm/drm_fb_helper.c | 74 +
On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson
wrote:
>
> On Aug 26, 2015 08:34, "Hai Li" wrote:
>>
>> Hi Werner,
>>
>> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly
>> the same as the excel calculation, but slightly different from the output of
>> drm code as you po
On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
wrote:
> On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
>> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
>> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter > > ffwll.ch> wrote:
>> >> Very strictly speaking this is possible if yo
On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
> >
> >
> > On 08/26/2015 10:42 AM, Archit Taneja wrote:
> > >
> > >
> > >On 08/25/2015 07:15 PM, Daniel Vetter wrote:
> > >>Faster than recompiling.
> > >>
> > >>Note t
On Tue, Aug 25, 2015 at 03:20:02PM -0400, Rob Clark wrote:
> On Tue, Aug 25, 2015 at 11:20 AM, Daniel Vetter
> wrote:
> > Using bool and returning true upon error is very uncommon. Also an int
> > return value is actually what all the callers which did check it seem
> > to have expected.
> >
> >
On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:
>
>
> On 08/26/2015 10:42 AM, Archit Taneja wrote:
> >
> >
> >On 08/25/2015 07:15 PM, Daniel Vetter wrote:
> >>Faster than recompiling.
> >>
> >>Note that restore_fbdev_mode_unlocked is a bit special and the only
> >>one which returns
On Wed, 12 Aug 2015, Thierry Reding wrote:
> From: Thierry Reding
>
> The enhanced framing capability was added in DisplayPort 1.1, so any
> code dealing with it needs to be protected accordingly.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 5 +++--
> 1 file chan
h the drm_driver functions over.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150826/b4ba366e/attachment.sig>
Hi,
What about this patch? We need it to avoid the WARN_ON added by patch
2/2 that was already picked up by Daniel.
Gustavo
2015-08-13 Gustavo Padovan :
> From: Gustavo Padovan
>
> These legacy helpers should only be used by shadow-attaching drivers.
> KMS drivers has its own way to h
Hi Inki,
2015-08-24 Inki Dae :
> On 2015ë
08ì 16ì¼ 01:26, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > .prepare_plane() and .cleanup_plane() allows to perform extra operations
> > before and after the update of planes. For FIMD for example this will
> > be used to enable disable
On Tuesday 25 August 2015 18:10:14 ville.syrjala at linux.intel.com wrote:
Simon Farnsworth |Senior Software Engineer
Tel: +44(0)1491 411400|Fax: +44(0)1491 579254
Email: simon.farnsworth at onelan.com |Company Website: www.onelan.com
ONELAN Limited
Andersen House, Newtown Road, Henley-on-Thames
On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
> wrote:
>> Very strictly speaking this is possible if you have special hw and
>> genlocked CRTCs. In general switching a plane between two active CRTC
>> just won't work so well and is probably
On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter
wrote:
> Very strictly speaking this is possible if you have special hw and
> genlocked CRTCs. In general switching a plane between two active CRTC
> just won't work so well and is probably not tested at all. Just forbid
> it.
So, I expect msm shou
On 08/26/2015 11:51 AM, Daniel Vetter wrote:
> On Wed, Aug 26, 2015 at 11:32:30AM -0300, Tiago Vignatti wrote:
>> On 08/26/2015 09:58 AM, Daniel Vetter wrote:
>>> The other is that right now there's no user nor implementation in sight
>>> which actually does range-based flush optimizations, so I'm
1 - 100 of 119 matches
Mail list logo
