On Thu, Jan 21, 2016 at 10:16:01AM +0100, Mario Kleiner wrote:
> On 01/21/2016 09:25 AM, Michel Dänzer wrote:
> > On 21.01.2016 17:16, Mario Kleiner wrote:
> >>
> >> This patch replaces calls to drm_vblank_pre/post_modeset in the
> >> drivers dpms code with calls to drm_vblank_off/on, as recommend
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/ffb880fc/attachment.html>
[c0514bc4] .drm_pci_init+0x68/0x10c
[c001750ffb90] [c00001667b84] .radeon_init+0xac/0xd0
[c001750ffc10] [c0009484] .do_one_initcall+0x14c/0x1e8
[c001750ffd00] [c162fb5c] .kernel_init_freeable+0x180/0x23c
[c001750ffdb0] [c0009b10] .kernel_init+0x20/0x120
[c001750ffe30] [c0007eb0] .ret_from_kernel_thread+0x58/0xa8
Instruction dump:
4b9fc315 6000 e93b23b0 387c0100 389e014c e8a9 38a5feb4 4b9fd84d
6000 815a0024 7d3cea14 3860 <7d5ce92e> 815a0028 91490004 815a002c
---[ end trace 70c04666cc8ef3da ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
Rebooting in 180 seconds..
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/6405c522/attachment-0001.html>
Hi Yakir,
Am Dienstag, 19. Januar 2016, 18:04:53 schrieb Yakir Yang:
> Rockchip have three clocks for dp controller, we leave pclk_edp
> to analogix_dp driver control, and keep the sclk_edp_24m and
> sclk_edp in platform driver.
>
> Signed-off-by: Yakir Yang
> Tested-by: Javier Martinez Canillas
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/8cb060cc/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/0d79e03a/attachment-0001.html>
hi...
i just found that its blocking waiting for console_lock...
@vineet, alexey: i think that console_lock is architecture dependent right? Do
you know any issue with console_lock for ARC?
On 21-01-2016 18:09, Carlos Palminha wrote:
> i made some progress in identifying the issue...
> When my d
If DRM_FBDEV_EMULATION is not selected in the config then we can save a
bit of space by not including the framebuffer code.
Signed-off-by: John Keeping
---
On Thu, 21 Jan 2016 17:52:51 +0100, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 01:53:46PM +, John Keeping wrote:
> > If DRM_FBDEV_EM
From: Michel Dänzer
Not doing so makes it impossible for radeon_bo_open callers to set any
RADEON_GEM_* flags for the newly created BO.
Signed-off-by: Michel Dänzer
---
radeon/radeon_bo_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/radeon/radeon_bo_gem.c b/radeon/
i made some progress in identifying the issue...
When my driver calls drm_fb_helper_initial_config it seems DRM blocks waiting
for register_framebuffer to return.
The sequence is
drm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer.
Its strange because register_frame
On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
wrote:
> On 21 January 2016 at 12:08, Marek Olšák wrote:
>> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov
>> wrote:
>>> On 18 January 2016 at 22:53, Marek Olšák wrote:
Try explaining that to people who have a compulsion to fix them or
>>
On Thu, Jan 21, 2016 at 01:53:46PM +, John Keeping wrote:
> If DRM_FBDEV_EMULATION is not selected in the config then we should not
> setup a framebuffer console.
It should just magically work, and this patch here just removes a bit more
dead code in the rockchip driver itself that's not neede
+Alex
On Thu, Jan 21, 2016 at 5:24 PM, Oded Gabbay wrote:
> On Fri, Oct 2, 2015 at 7:56 AM, Benjamin Herrenschmidt
> wrote:
>> On Fri, 2015-10-02 at 14:53 +1000, Dave Airlie wrote:
>>> On 2 October 2015 at 14:45, Benjamin Herrenschmidt
>>> wrote:
>>> > On Fri, 2015-10-02 at 14:42 +1000, Dave Ai
On 21.01.2016 16:58, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 15:38, Michel Dänzer wrote:
>>> On 21.01.2016 14:31, Mario Kleiner wrote:
On 01/21/2016 04:43 AM, Michel Dänzer wrote:
> On 21.01.2016 05:32, Mario Kleiner wrote:
On Thu, Jan 21, 2016 at 12:39:41PM +0530, Archit Taneja wrote:
> Add hdmi phy bindings. Update the example to use hdmi phy.
>
> Add a missing power-domains property in the hdmi core bindings.
>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring
>
> Signed-off-by: Archit Taneja
> ---
> .../
On 21.01.2016 17:16, Mario Kleiner wrote:
>
> This patch replaces calls to drm_vblank_pre/post_modeset in the
> drivers dpms code with calls to drm_vblank_off/on, as recommended
> for drivers with hw counters that reset to zero during modeset.
Sounds like you fell for the drm_vblank_on/off propag
On Fri, Oct 2, 2015 at 7:56 AM, Benjamin Herrenschmidt
wrote:
> On Fri, 2015-10-02 at 14:53 +1000, Dave Airlie wrote:
>> On 2 October 2015 at 14:45, Benjamin Herrenschmidt
>> wrote:
>> > On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote:
>> > > I don't think we resolved this the last time we t
lt;http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/ba11d7ba/attachment.sig>
call this new function so that both OF and !OF share the same
code for this.
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/20160121/17e805f1/attachment.sig>
c: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/51f7586f/attachment.sig>
t; + * @type: dsi peripheral chip type
> * @reg: DSI virtual channel assigned to peripheral
> * @node: pointer to OF device node
> *
> @@ -148,6 +151,7 @@ enum mipi_dsi_pixel_format {
> * DSI device
> */
> struct mipi_dsi_device_info {
> + char type[DSI_DEV_NAME_SIZE];
Why limit ourselves to 20 characters? And why even so complicated? Isn't
the type always static when someone specifies this? Couldn't we simply
use a const char *name here instead?
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/20160121/9cbd627c/attachment.sig>
return dsi;
}
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/20160121/b21d69a4/attachment.sig>
On 1/21/2016 8:59 AM, Nick Bowler wrote:
> On 1/20/16, Nick Bowler wrote:
>> Hi,
>>
>> On 2016-01-20, Jindal, Sonika wrote:
>>> Can you please check if you have following patch:
>>> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
>>> Author: Gary Wang
>>> Date: Wed Dec 23 16:11:35 2015 +080
important because we never check the return value in the one
call-site that we have, which I guess could be an argument for removing
the return value altogether...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signatu
On 21.01.2016 15:38, Michel Dänzer wrote:
> On 21.01.2016 14:31, Mario Kleiner wrote:
>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>> On 21.01.2016 05:32, Mario Kleiner wrote:
So the problem is that AMDs hardware frame counters reset to
zero during a modeset. The old DRM code d
On 21.01.2016 14:31, Mario Kleiner wrote:
> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>> On 21.01.2016 05:32, Mario Kleiner wrote:
>>>
>>> So the problem is that AMDs hardware frame counters reset to
>>> zero during a modeset. The old DRM code dealt with drivers doing that by
>>> keeping vblank
Adds hdmi 8996 phy registers. The registers are divided into 3 domains:
- Core HDMI PHY registers
- HDMI PLL registers (part of QSERDES block)
- HDMI TX lane registers (part of QSERDES block)
Signed-off-by: Archit Taneja
---
rnndb/hdmi/hdmi.xml | 258
- Create separate domains for 8960 PHY and PLL
- Create separate domains for 8x60 PHY
Signed-off-by: Archit Taneja
---
rnndb/hdmi/hdmi.xml | 147 +++-
1 file changed, 75 insertions(+), 72 deletions(-)
diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/
Modify existing offsests for HDMI PHYs, and add support for MSM8996
Archit Taneja (2):
rnndb: hdmi: Create separate domains for 8x60 and 8960 PHY
rnndb: hdmi: Add hdmi phy registers for 8996
rnndb/hdmi/hdmi.xml | 405 ++--
1 file changed, 333 i
you are
reporting.
--
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/20160121/3f9012b3/attachment.html>
Hi Lukas,
Sorry for the late answer, I went on vacation and then was busy with
something else. Anyway, I tried to address all comments (yours and
Daniel's) on a new version. See some comments below.
On Sun, Dec 06, 2015 at 05:08:49PM +0100, Lukas Wunner wrote:
> Hi Rafael,
>
> On Thu, Dec 03, 20
From: Lukas Wunner
Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON
if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister()
is called after drm_connector_unregister(). radeon is the only driver
affected by this besides i915. (amdgpu calls drm_dp_aux_unregister()
b
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the dr
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector
The module_init and module_exit functions will start here, and call the
subsequent init's and exit's.
v10:
- Keep __init on drm_fb_helper init function.
- Move MODULE_* macros to the common file.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/Makefile| 4 ++-
drivers/gp
This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.
Lukas Wunner (1):
drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled
Rafael Antognolli (3
The retire worker is kicked for each fence, either the normal way
by signaling the fence from the event completion interrupt or by
the recover worker if the GPU got stuck. Moving the RPM put into
the retire worker allows us to have it in a single place for
both cases.
This also shaves off quite a
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/df2e527c/attachment.html>
play is enabled
--
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/20160121/5f07be7f/attachment.html>
On Thu, Jan 21, 2016 at 4:13 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Not doing so makes it impossible for radeon_bo_open callers to set any
> RADEON_GEM_* flags for the newly created BO.
Reviewed-by: Alex Deucher
>
> Signed-off-by: Michel Dänzer
> ---
> radeon/radeon_bo_gem.c |
veral graphical glitches.
--
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/20160121/b0163a17/attachment-0001.html>
On 2016-01-21, Jindal, Sonika wrote:
> On 1/21/2016 8:59 AM, Nick Bowler wrote:
>> On 1/20/16, Nick Bowler wrote:
>>> On 2016-01-20, Jindal, Sonika wrote:
[...]
Does the same system works with any other monitor?
>>> I'll see if I can find another to try.
>> I tried another monitor, and the
If DRM_FBDEV_EMULATION is not selected in the config then we should not
setup a framebuffer console.
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 11 +++
2 files changed, 13 insertions(+), 1 deleti
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/4af2462f/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/aaadc99d/attachment.html>
On 21 January 2016 at 12:08, Marek Olšák wrote:
> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov
> wrote:
>> On 18 January 2016 at 22:53, Marek Olšák wrote:
>>> Try explaining that to people who have a compulsion to fix them or
>>> argue about them. :) Ignore? REALLY? IGNORE???
>>>
>> Now t
On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov
wrote:
> On 18 January 2016 at 22:53, Marek Olšák wrote:
>> Try explaining that to people who have a compulsion to fix them or
>> argue about them. :) Ignore? REALLY? IGNORE???
>>
> Now that we have a few people off your back can you please point
Please submit patches for review with git send-email.
Please send xf86-video-amdgpu patches to the xorg-driver-ati at lists.x.org
list with a [PATCH xf86-video-amdgpu] subject prefix.
On 21.01.2016 02:08, StDenis, Tom wrote:
> Subject: [PATCH] amdgpu: Move memset() after variable declarations
On 21.01.2016 05:32, Mario Kleiner wrote:
>
> So the problem is that AMDs hardware frame counters reset to
> zero during a modeset. The old DRM code dealt with drivers doing that by
> keeping vblank irqs enabled during modesets and incrementing vblank
> count by one during each vblank irq, i think
Add hdmi phy bindings. Update the example to use hdmi phy.
Add a missing power-domains property in the hdmi core bindings.
Cc: devicetree at vger.kernel.org
Cc: Rob Herring
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/display/msm/hdmi.txt | 39 +-
1 file
Add support for the HDMI PHY/PLL found in msm8996/apq8096.
Unlike the previous phys supported in the driver, this doesn't need
the powerup/powerdown ops. The PLL prepare/unprepare clock ops
enable/disable the phy itself.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/Makefile
Adds hdmi 8996 phy offsets. The offsets are divided into 3 parts:
- Core HDMI PHY registers
- HDMI PLL registers (part of QSERDES block)
- HDMI TX lane registers (part of QSERDES block)
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 500 +++
Remove the old phy ops managed by hdmi_platform_config and use them as ops
provided by the hdmi phy driver.
Remove the old hdmi 8960 PLL code that used the top level hdmi tx mmio
base.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 25 +-
drivers/gpu/drm/msm/hdmi/h
Add a helper to initialize PLL in the phy driver.
HDMI PLLs are going to have their own mmio base different from that of
PHY.
For the clock code in hdmi_phy_8960.c, some changes were needed for it to
work with the updated register offsets. Create a copy of the updated clock
code in hdmi_pll_8960.
Make hdmi core get its phy by parsing the qcom,hdmi-phy phandle. The core
will use this phy reference to enable/disable phy. The driver defers probe
until phy isn't available.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 40
drivers/
Create a phy device that represents the TX PHY and PLL parts of the hdmi
block.
This makes management of PHY specific resources (regulators and clocks)
much easier, and makes the PHY and PLL usable independently. It also
simplifies the core hdmi driver, which currently assigns phy ops among
with m
- Create separate domains for 8960 PHY and PLL
- Create separate domains for 8x60 PHY
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 157 +---
1 file changed, 74 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.xml
Some platforms may not have a hpd gpio line to detect hpd. They need to
rely only on reading REG_HDMI_HPD_INT_STATUS for hpd.
Modify hdmi_connector_detect logic such that it checks for hpd only using
the status register if there is no hpd gpio.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/m
Make gpio allocation and usage iterative by parsing the gpios on a given
platform from a list. This gives us flexibility over what all gpios exist
for a platform, whether they are input or output, and what value they
should be set to.
In particular, this will make hdmi on 8x96 platforms easier to
The msm Makefile and Kconfig are getting conjusted. Move edp related
stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile | 7 +--
drivers/gpu/drm/msm/edp/Kconfig | 7 +++
drivers/gpu/drm/m
The msm Makefile and Kconfig are getting conjusted. HDMI is going to
have more configs and files in the future to manage, which will make
managing these harder.
Move hdmi related stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 1 +
The msm Makefile and Kconfig are getting conjusted. Move out
the DSI related stuff into separate Kconfig and Makefile.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/Kconfig | 40 +---
drivers/gpu/drm/msm/Makefile | 22 --
dr
HDMI on MSM8996 has a tx block that is compatible with the older
versions apart from some minor changes. The HDMI PHY and PLL on msm8996
are new.
The series refactors the code such that there is a separate hdmi phy
driver, similar to what we already have for dsi. This makes it easier
to integrate
Hi Lucas,
2016-01-21 10:16 GMT+01:00 Lucas Stach :
> Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King:
>> Export further minor feature bitmasks and the varyings count from
>> the GPU specifications registers to userspace.
>>
>> Signed-off-by: Russell King
>
> I guess you have MESA ch
rubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/5d7c3288/attachment.html>
n't actually matter, as the difference was about -5FPS.
--
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/20160121/b3f1785a/attachment.html>
On Thu, Jan 21, 2016 at 10:39 AM, Oded Gabbay wrote:
> +Alex
No objections from me. Care to respin with amdgpu support and signed
off? Would probably also be nice to split the core drm change from
the driver specific ones.
Alex
>
> On Thu, Jan 21, 2016 at 5:24 PM, Oded Gabbay wrote:
>> On Fr
On Thu, Jan 21, 2016 at 12:34:16PM +0100, Christian Gmeiner wrote:
> Hi Lucas,
>
> 2016-01-21 10:16 GMT+01:00 Lucas Stach :
> > Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King:
> >> Export further minor feature bitmasks and the varyings count from
> >> the GPU specifications register
Is there a PATCH 2/2 which I can't find, or is the subject wrong?
On 01/21/2016 09:16 AM, Mario Kleiner wrote:
> The hardware vblank counter of AMD gpu's resets to zero during a
> modeset. The new implementation of drm_update_vblank_count() from
> commit 4dfd6486 "drm: Use vblank timestamps to gue
On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
> On 21.01.2016 16:58, Daniel Vetter wrote:
> > On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
> >> On 21.01.2016 15:38, Michel Dänzer wrote:
> >>> On 21.01.2016 14:31, Mario Kleiner wrote:
> On 01/21/2016 04:43
Equivalent change to the radeon driver.
Note that with radeon this caught a bug in the dri3 DDX
implementation, which asked for vblank interrupts when the pipe is
off. That bug needs to be fixed before we can merge this patch (if
amdgpu is affected too). Michel discovered this one.
Cc: Michel Dä
These should be functionally equivalent to the older per/post modeset
functions, except that they block out drm_vblank_get right away.
There's only the clock adjusting code (outside of pageflips) in
readone which uses drm_vblank_get. But that code doesn't synchronize
against concurrent modesets and
In
commit 9cba5efab5a8145ae6c52ea273553f069c294482
Author: Mario Kleiner
Date: Tue Jul 29 02:36:44 2014 +0200
drm/nouveau: Dis/Enable vblank irqs during suspend/resume
drm_vblank_on/off calls where added around suspend/resume to make sure
vblank stay doesn't go boom over that transition.
On 18 January 2016 at 22:53, Marek Olšák wrote:
> Try explaining that to people who have a compulsion to fix them or
> argue about them. :) Ignore? REALLY? IGNORE???
>
Now that we have a few people off your back can you please point out
where this triggers warnings ?
I've tried multiple times to
From: Gustavo Padovan
With the removal of struct sync_pt sync_fence_create_dma() now takes
the same arguments as sync_fence_create() so let's keep only
sync_fence_create().
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 8 +---
drivers/staging/android/sync.h | 10
From: Gustavo Padovan
All changes to timeline value come through the user via
sync_timeline_signal() calls. When sync_timeline_destroy() is called no
changes on timeline->value happens hence call sync_timeline_signal() with
no increment is pointless.
Signed-off-by: Gustavo Padovan
---
drivers/
From: Gustavo Padovan
signaled_pts is not used in this function.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3c2c8d0..9ec55ef 100644
--- a/drivers/stag
From: Gustavo Padovan
struct sync_pt was just wrapping around struct fence and creating an
extra abstraction layer. The only two members of struct sync_pt, child_list
and active_list, were moved to struct fence in an earlier commit. After
removing those two members struct sync_pt is nothing more
From: Gustavo Padovan
'sync_pt' is actually declared as struct fence so to make the name means
its type we rename it to 'fence'.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 20 ++--
drivers/staging/android/sync.h | 2 +-
drivers/staging/andr
From: Gustavo Padovan
sync_file has a more close meaning to what a sync_fence really, a struct
that represent a file that can be used by userspace to get information on
a fence, or wait for it to be signaled.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 254 +++
From: Gustavo Padovan
This remove CONFIG_SW_SYNC_USER and instead compile the sw_sync file into
debugpfs under /sync/sw_sync.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/Kconfig | 9 ---
drivers/staging/android/sw_sync.c| 129 ---
drive
From: Gustavo Padovan
Creates the 'sync' dir on debugfs root dir and move the 'sync' file
to sync/info. This is the preparation to add more debug info and control.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync_debug.c | 21 +
1 file changed, 17 insertions(
From: Gustavo Padovan
.dup and .compare are not used by the sync framework, so remove them
from sw_sync.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 29 +
drivers/staging/android/sync.c| 6 --
drivers/staging/android/sync.h| 1
From: Gustavo Padovan
These interfaces are not used nor have plans to be used in the near
future so remove them for a cleaner solution before de-staging the sync
framework.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.c | 56
driver
From: Gustavo Padovan
Updates comments about functions and structures.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sync.h | 45 --
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/android/sync.h b/drivers/sta
From: Gustavo Padovan
Hi,
The following patches are some clean ups on the sync framework before
we start the actual de-staging. The main changes here are the move of
SW_SYNC_USER to debugfs. Removal of struct sync_pt in favor of direct
use of struct fence. And the rename of sync_fence to sync_fi
Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King:
> Export further minor feature bitmasks and the varyings count from
> the GPU specifications registers to userspace.
>
> Signed-off-by: Russell King
I guess you have MESA changes that depend on this patch, right? In that
case I'll fa
On 01/21/2016 09:25 AM, Michel Dänzer wrote:
> On 21.01.2016 17:16, Mario Kleiner wrote:
>>
>> This patch replaces calls to drm_vblank_pre/post_modeset in the
>> drivers dpms code with calls to drm_vblank_off/on, as recommended
>> for drivers with hw counters that reset to zero during modeset.
>
>
On 01/21/2016 09:28 AM, Mario Kleiner wrote:
>> ... just like drm_vblank_pre/post_modeset. That those were broken is a
>> regression which needs to be fixed anyway. I don't think switching to
>> drm_vblank_on/off is suitable for stable trees.
>>
>> Looking at Vlastimil's original post again, I'd sa
Am Mittwoch, den 20.01.2016, 19:01 +0100 schrieb Christian Gmeiner:
> Hi Russell
>
> 2016-01-19 11:21 GMT+01:00 Russell King - ARM Linux arm.linux.org.uk>:
> > On Tue, Jan 19, 2016 at 11:09:57AM +0100, Christian Gmeiner wrote:
> >> Hi Russell,
> >>
> >> 2016-01-19 10:18 GMT+01:00 Russell King :
>
http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/a0610dcb/attachment.html>
On 01/21/2016 07:38 AM, Michel Dänzer wrote:
> On 21.01.2016 14:31, Mario Kleiner wrote:
>> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
>>> On 21.01.2016 05:32, Mario Kleiner wrote:
So the problem is that AMDs hardware frame counters reset to
zero during a modeset. The old DRM cod
args->pitch and args->size may not be set by userspace, sometimes
userspace only malloc args and not memset args to zero, then
args->pitch and args->size is random, it is very danger to use
pitch/size on gem.
pitch's type is u32, and min_pitch's type is int, example,
pitch is 0x, then pitc
The hardware vblank counter of AMD gpu's resets to zero during a
modeset. The new implementation of drm_update_vblank_count() from
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how
many vblanks were missed", introduced in Linux 4.4, treats that
as a counter wraparound and causes the so
On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote:
> On 21.01.2016 15:38, Michel Dänzer wrote:
> > On 21.01.2016 14:31, Mario Kleiner wrote:
> >> On 01/21/2016 04:43 AM, Michel Dänzer wrote:
> >>> On 21.01.2016 05:32, Mario Kleiner wrote:
>
> So the problem is that AMDs har
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/6b021f73/attachment.html>
On 2016å¹´01æ19æ¥ 18:46, John Keeping wrote:
> The first two patches are unchanged since v1 but the comment in the
> third has been expanded following Thierry's comments.
>
> John Keeping (3):
>drm/atomic-helper: Export framebuffer_changed()
>drm/rockchip: don't wait for vblank if fb has
|major |critical
--
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/20160121/2fe1b843/attachment.html>
On 01/21/2016 04:43 AM, Michel Dänzer wrote:
> On 21.01.2016 05:32, Mario Kleiner wrote:
>>
>> So the problem is that AMDs hardware frame counters reset to
>> zero during a modeset. The old DRM code dealt with drivers doing that by
>> keeping vblank irqs enabled during modesets and incrementing vb
On 1/20/16, Nick Bowler wrote:
> Hi,
>
> On 2016-01-20, Jindal, Sonika wrote:
>> Can you please check if you have following patch:
>> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
>> Author: Gary Wang
>> Date: Wed Dec 23 16:11:35 2015 +0800
>>
>> drm/i915: increase the tries for HDMI hotplu
1 - 100 of 103 matches
Mail list logo
