Hi all,
On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
> 'mdp5_plane_cleanup_fb':
> drivers/gpu/drm/msm/mdp/mdp5/mdp5
Hi Linus,
On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie wrote:
>
> This is the main pull request for the drm for 4.3. Nouveau is probably the
> biggest
> amount of changes in here, since it missed 4.2. Highlights below, along with
> the usual
> bunch of fixes. There are a few minor confli
On 8 September 2015 at 12:03, Stephen Rothwell wrote:
> Hi Linus,
>
> On Fri, 4 Sep 2015 23:40:53 +0100 (IST) Dave Airlie
> wrote:
>>
>> This is the main pull request for the drm for 4.3. Nouveau is probably the
>> biggest
>> amount of changes in here, since it missed 4.2. Highlights below, alo
Hi Dave,
On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie wrote:
>
> Is this to be a regular thing? because I know I'd prefer to merge
> fixes than wait for -rc1 to be an accurate copy of linux-next.
It happens when I can (almost) keep up with Linus' merge rate (often I
can't). It is not an issue
Op 08-09-15 om 01:42 schreef Stephen Rothwell:
> Hi all,
>
> On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
> wrote:
>> After merging the drm-misc tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
>> 'mdp
On 8 September 2015 at 14:04, Stephen Rothwell wrote:
> Hi Dave,
>
> On Tue, 8 Sep 2015 13:01:21 +1000 Dave Airlie wrote:
>>
>> Is this to be a regular thing? because I know I'd prefer to merge
>> fixes than wait for -rc1 to be an accurate copy of linux-next.
>
> It happens when I can (almost) ke
https://bugzilla.kernel.org/show_bug.cgi?id=103271
--- Comment #13 from Michel Dänzer ---
You should only run "git bisect" for commits which exhibit the same symptoms as
described in this report. For commits exhibiting other issues, in particular
such that you can't tell whether the problem desc
Hi all,
The following series add initial support for the Slimport ANX7814 transmitter, a
ultra-low power Full-HD (1080p60) transmitter designed for portable device.
The driver was originally created and based from the work of Junhua Xia from
Analogix. This driver is a refactor of the original dri
Analogix Semiconductor develops analog and mixed-signal devices for digital
media and communications interconnect applications.
Signed-off-by: Enric Balletbo i Serra
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/device
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
You can add support to your board with current binding.
Example:
anx7814: anx7814 at 38 {
compatible = "analogix,anx7814";
reg = <0x38>;
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
This driver adds initial support and supports HDMI to DP pass-through mode.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/i2c/Kconfig |2 +
drivers/gpu/drm/i
Mesa revisions.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/02182ea6/attachment.html>
On Tue, Sep 08, 2015 at 06:48:34AM +0200, Maarten Lankhorst wrote:
> Op 08-09-15 om 01:42 schreef Stephen Rothwell:
> > Hi all,
> >
> > On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell > canb.auug.org.au> wrote:
> >> After merging the drm-misc tree, today's linux-next build (arm
> >> multi_v7_de
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
On 09/07/2015 01:46 PM, Archit Taneja wrote:
> Thierry,
>
> On 08/21/2015 11:39 AM, Archit Taneja wrote:
>>
>>
>> On 08/20/2015 05:18 PM, Thierry Reding wrote:
>>> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
Hi Thierry, Lucas,
On 08/19/2015 08:32 PM, Thierry
d...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/ecb5f32d/attachment.sig>
Hi Daniel,
Thank you for the patch.
On Tuesday 08 September 2015 12:02:07 Daniel Vetter wrote:
> 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 al
On Tue, Sep 08, 2015 at 01:10:58PM +0200, Thierry Reding wrote:
> On Tue, Sep 08, 2015 at 12:02:07PM +0200, Daniel Vetter wrote:
> > 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 th
Requested by Laurent.
Note that this uses the new markdown support which will only land in
kernel 4.4 (for the code snippet).
v2: A few spelling fixes I spotted myself.
Cc: Laurent Pinchart
Reviewed-by: Thierry Reding (v1 on irc)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_he
Hi all,
Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODESET (i.e. modern
drivers) since all of them have their own locking. Besides that a few random
things that kind where in the same area/files.
Of course kerneldoc is updated too.
Feedback highly welcome.
Cheers, Daniel
Daniel
We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.
Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.
v2: Use IS_ENABLED(CONFIG
Makes it really hard to reason about these since there are dependency
loops. Also if you touch them and don't know what you're doing you get
to keep all the pieces.
v2: Move marking debug module options as _unsafe into a separate patch,
as requested by Jani.
Cc: Jani Nikula
Signed-off-by: Daniel
We don't want random people to touch these.
Especially true since we've just screwed up SKL by holding it way too
long under the preliminary flag because of some ABI issues. And now
there's howtos all over the internets about how to set this. Same
pretty much for anything else.
Cc: Jani Nikula
S
This was only used for the ums+gem combo, so ripe for removal now that
we only have kms code left.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED
And use it in radeon to replace all the ioctls no longer valid in kms
mode. I plan to also use this later on when nuking the ums support for
i915.
Note that setting the function pointer in the ioctl table to NULL
would amount to the same, but that results in some debug output from
the drm_ioctl()
As usual pull it into the drm docbook template, too. And again as
usual I've decided to only document stuff exported to drivers, so all
the old leftover markup from the shared drm repo days lost the magic
** signature.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 1 +
drive
With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare th
drm core enforces now for DRIVER_MODESET that all ioctls are unlocked.
And all the old nasty ones from drm core aren't allowed for modern
drivers any more. Hence this is no longer needed.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8
1 file changed, 8 deletio
Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
everywhere.
Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.
v2: admgpu h
They're only used in the drm ioctl table, and there they're excluded
when AGP support is disabled. So this is just dead code ripe for
removal.
Signed-off-by: Daniel Vetter
---
include/drm/drm_agpsupport.h | 48
1 file changed, 48 deletions(-)
diff --
Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König
.
That should be everything touching radeon/amdgpu if I missed something
leave me a note.
Regards,
Christian.
On 08.09.2015 13:56, Daniel Vetter wrote:
> Hi all,
>
> Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODES
Hi Daniel,
Thank you for the patch.
On Tuesday 08 September 2015 13:52:45 Daniel Vetter wrote:
> Requested by Laurent.
>
> Note that this uses the new markdown support which will only land in
> kernel 4.4 (for the code snippet).
>
> v2: A few spelling fixes I spotted myself.
>
> Cc: Laurent Pi
From: Thierry Reding
This function can be used to duplicate an atomic state object. This is
useful for example to implement suspend/resume, where the state before
suspend can be saved and restored upon resume.
v2: move locking to caller, be more explicit about prerequisites
v3: explicitly pass l
From: Thierry Reding
Provide subsystem-level suspend and resume helpers that can be used to
implement suspend/resume on atomic mode-setting enabled drivers.
v2: simplify locking, enhance kerneldoc comments
v3: pass lock acquisition context by parameter, improve kerneldoc
Signed-off-by: Thierry
On Tue, Sep 08, 2015 at 03:00:46PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Provide subsystem-level suspend and resume helpers that can be used to
> implement suspend/resume on atomic mode-setting enabled drivers.
>
> v2: simplify locking, enhance kerneldoc comments
> v3: pass loc
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/d91a2674/attachment.html>
Requested by Laurent.
Note that this uses the new markdown support which will only land in
kernel 4.4 (for the code snippet).
v2: A few spelling fixes I spotted myself.
v3: Big reword for commit_planes() kerneldoc based on a text from
Laurent.
Cc: Laurent Pinchart
Reviewed-by: Thierry Reding
On Tue, Sep 08, 2015 at 03:00:45PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This function can be used to duplicate an atomic state object. This is
> useful for example to implement suspend/resume, where the state before
> suspend can be saved and restored upon resume.
>
> v2: move
From: Thierry Reding
These functions are like drm_modeset_{,un}lock_all(), but they take the
lock acquisition context as a parameter rather than storing it in the
DRM device's drm_mode_config structure.
Implement drm_modeset_{,un}lock_all() in terms of the new function for
better code reuse, and
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/82574927/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/82e45303/attachment.html>
The cost of faulting in all memory to be locked can be very high when
working with large mappings. If only portions of the mapping will be
used this can incur a high penalty for locking.
For the example of a large file, this is the usage pattern for a large
statical language model (probably appli
On 7 September 2015 at 22:50, Rob Herring wrote:
> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso
> wrote:
>> Hello,
>>
>> I have a problem with the panel on my Tegra Chromebook taking longer
>> than expected to be ready during boot (Stéphane Marchesin reported what
>> is basically the same issue
Hello,
during the discussion about the last patchset touching the
fimg2d code, it became apparent that the error handling for
the command submission is currently unsatisfactory.
This series rewrites the handling. All functions that submit
command buffers now first check if enough space is availab
Empty command buffers are no error, we just don't have
anything to do for flushing then.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 24a06d0..4a88e0c 100644
--- a
Use g2d_add_base_addr() for source and destination base
address just like all other calls.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 4a88e0c..85
This is going to be used to check if the command buffers have
enough space left prior to actual submission of the commands.
Use this in g2d_{solid_fill,copy,copy_with_scale}().
For this the parameter validation before buffer space
checking so that we can exit early if it fails.
Also don't reset t
The G2D headers define a number of modes through enums
(like e.g. color, select, repeat, etc.).
This introduces g2d_validate_select_mode() and
g2d_validate_blending_op() which validate a
select mode or blending operation respectively.
Use this together with g2d_check_space() in
g2d_{blend,scale_a
We now validate the blending mode via g2d_validate_mode()
prior to feeding it to g2d_get_blend_op().
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 9d9359
The g2d_point_val union consists of two coordinates of 16
bits. Whenever this union is used though, both coordinates
are explicitly set. Hence prior initialization is unnecessary.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 19 ---
1 file changed, 19 deletions(-)
d
The function currently checks for each added command
if an overflow of the corresponding command buffers
occurs, but none of the callers ever checks the
return value.
Since all callers are now converted to use
g2d_check_space() simplify the function.
(1) The overflow checks become asserts, so the
Add a prefix to the messages printed to the console via
printf() and fprintf() so that one can easily see where
the message comes from.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/exy
All functions from the public API only operation on
struct g2d_context*, so this shouldn't break too much.
Make the context private since we don't want the
user to modify its content directly. Also remove
the defines that were only used for fields of
g2d_context.
Signed-off-by: Tobias Jakobi
---
] fbcon: radeondrmfb (fb0) is primary device
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/d80f73d1/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/0039e8a5/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150908/d3819805/attachment.html>
On Mon, Sep 7, 2015 at 9:56 PM, Dave Airlie wrote:
>
> i.e. 59 commits in a 5000 commit tree is likely not that bad, 59
> commits in a 20 commit tree would be bad.
I think it's about size of the commits. If it's 59 clean oneliner
fixes, I don't think it's a big deal. If it's 59 patches that add n
On Thu, Aug 27, 2015 at 05:23:30PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
> supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
> when we continue to poll for the completio
Hi Daniel,
2015-09-08 Daniel Vetter :
> With the prep patches for i915 all kms drivers either have
> DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
> with an invariant return value when in modeset mode. But that's only
> the case for i915 and radeon. The drm core ioctls ar
Hi Daniel,
2015-09-08 Daniel Vetter :
> Just one special case (since i915 lost its ums code, yay):
> - radeon: Has slots for the old ums ioctls which don't have
> DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
> everywhere.
>
> Every other kms driver just has DRM_UNLOCKED
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150908/8f9ac51f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=103271
--- Comment #14 from Kevin McCormack ---
Michel, thank you for this, I will try to bisect again...it should only take 13
compiles! :/
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Sep 7, 2015 at 6:02 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes build failure due to unresolved log2.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> tests/Makefile.am | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tests/Makefile.am b/te
On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> You can add support to your board with current binding.
>
> Example:
>
> anx7814: anx7814 at 38 {
> compatible
On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
> On 7 September 2015 at 22:50, Rob Herring wrote:
>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso
>> wrote:
>>> Hello,
>>>
>>> I have a problem with the panel on my Tegra Chromebook taking longer
>>> than expected to be ready during boot (Stéphane Ma
On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> Analogix Semiconductor develops analog and mixed-signal devices for digital
> media and communications interconnect applications.
>
> Signed-off-by: Enric Balletbo i Serra
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/v
hda_intel.c:azx_probe() defers initialization of an audio controller
on the discrete GPU if the GPU is powered off. The power state of the
GPU is determined by calling vga_switcheroo_get_client_state().
vga_switcheroo_get_client_state() returns VGA_SWITCHEROO_INIT if
vga_switcheroo is not enabled,
68 matches
Mail list logo
