ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141009/93e6c969/attachment.html>
09.10.2014, 22:32, "Christian K?nig" :
> Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
>> ?09.10.2014, 21:42, "Christian K?nig" :
>>> ?For VRAM it is true that we have a couple of different caches between
>>> ?the CPU and the actually memory, which need to be flushed explicitly if
>>> ?you wan
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/2081c337/attachment.html>
09.10.2014, 21:42, "Christian K?nig" :
> Hi Alexander,
>
> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
> registers, not VRAM.
>
> And the register bar shouldn't be accessed write combined, cause that
> could lead to a couple of ordering problems. Why do you think the access
>
Thanks for the input.
I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
i.e, our driver now supports 2 h/w generations with the exact same set
of IOCTLs and I don't see how that would change in the future..
What I'm more worried about is supporting different sets of UMD, which
ld say the
stutter is not completely gone (even though my BL2 experience is good).
--
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/20141009/ee0e6382/attachment.html>
Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov:
> 09.10.2014, 21:42, "Christian K?nig" :
>> Hi Alexander,
>>
>> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
>> registers, not VRAM.
>>
>> And the register bar shouldn't be accessed write combined, cause that
>> could lead to
r just became smaller?
--
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/20141009/f01c169a/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4ff10197/attachment.html>
Hi Alexander,
in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into
registers, not VRAM.
And the register bar shouldn't be accessed write combined, cause that
could lead to a couple of ordering problems. Why do you think the access
is done write combined?
For VRAM it is true that
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4be51a04/attachment.html>
On Thu, Oct 9, 2014 at 7:08 PM, Thierry Reding wrote:
> On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
>> On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
>> >Hi,
>> >
>> >+CC possible victims
>> >
>> >On 10/02/2014 12:52 PM, Inki Dae wrote:
>> >>On 2014? 10? 02? 17:58, Joonyoung S
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_ttm.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 8624979..cbe7b32 100644
--- a/d
From: Michel D?nzer
This avoids them getting in the way of BOs which might be accessed by
the CPU. They can still go to the CPU accessible part of VRAM though if
there's no space outside of it.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_object.c | 42 +++
drm_vblank_get() can return an error, which we should propagate.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/tegra/dc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 6553fd238685..b08df07cad47 100644
On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay wrote:
> Well, I don't expect to reach 100 ioctls anytime soon, but I can tell
> you that for the features we have in the pipeline, I can see the IOCTL
> number go up to 20-30, just for the current H/W generation.
So our Android folks seem to routinely
We have test with and without gpio and we haven't seen any difference.
To be honest I prefer simplify the bindings which is already complex
and so remove gpio.
But I will in mind your advice if one day I have debounce issues.
Regards,
Benjamin
2014-10-09 14:10 GMT+02:00 Rob Clark :
> On Thu, Oc
https://bugzilla.kernel.org/show_bug.cgi?id=82711
--- Comment #12 from Mike Cloaked ---
The only way I can get the laptop to behave sensibly on shutdown is to
blacklist the nouveau module at boot using modprobe.blacklist=nouveau on the
kernel line, or to add to the file /etc/modprobe.d/blacklist.
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4f57558f/attachment.html>
On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam
wrote:
> Ajay,
>
>
> On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar wrote:
>> Hi,
>>
>> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam
>> wrote:
>>> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>>>
>>> Refactoring the exyno
Ajay,
On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar wrote:
> Hi,
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam
> wrote:
>> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>>
>> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
>> and access th
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/9958d0f0/attachment.html>
Hi,
On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam
wrote:
> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>
> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
> and access the register using mfd-syscon and regmap.
> Simultaneously, removing the
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/993f137e/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/b791cb35/attachment.html>
Hi David,
I'm using 3.10.53-rt56 kernel and encounter a problem in
r600_dma_ring_test() when vram memory is mapped as write-combining:
no matter how long the polling is done, old value (0xCAFEDEAD) is read.
Looking with hardware analyzer at what actually happens in the PCI-E bus,
the memory is ac
As long as only IPUv3 is supported in imx-drm, hide the separate
DRM_IMX_IPUV3 option and make DRM_IMX depend on IMX_IPUV3_CORE.
Reported-by: Michael Olbrich
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/Kconfig | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/ttm/ttm_bo.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 407fa2d..d395b0b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/driver
From: Michel D?nzer
The radeon driver uses placement range restrictions for several reasons,
in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
during a page fault.
Without this change, TTM could evict other BOs while trying to satisfy
the requested placement, even if the ev
On 10/02/2014 08:52 PM, Andrzej Hajda wrote:
> Hi,
>
> +CC possible victims
>
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
The patch disables vblanks during dpms off only if pagef
Am 09.10.2014 um 11:55 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> This avoids them getting in the way of BOs which might be accessed by
> the CPU. They can still go to the CPU accessible part of VRAM though if
> there's no space outside of it.
That sounds to me like you want to increase the
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/3f4d867c/attachment.html>
ttachments/20141009/fe45b6da/attachment-0001.html>
On 09/10/14 11:02, Jerome Glisse wrote:
> On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote:
>> Hi Jerome,
>>
>> Do you think your proposed change should also be applied to amdkfd's
>> IOCTLs ?
>
> It might make sense it really depends on the lifespan you expect for
> amdkfd, do you ex
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/a17383b5/attachment.html>
eceiving 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/20141009/484c9001/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=53971
Zhuravlev Uriy changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Alex,
your kernel commit 186b1b2ba2a0684e3d2d3703427a993a3b35b16d
('drm/radeon/dpm: drop clk/voltage dependency filters for SI') causes my
factory-over-clocked Cape Verde card to lock up pretty quickly when
running e.g. Unigine Valley or the PTS Xonotic benchmark. Everything's
fine again
vers supposed to react to this situation?
It shouldn't happen. If drm_vblank_off() and drm_vblank_on() are called
around a modeset they should never conflict with drm_vblank_get(), at
least on Tegra, because the modeset and page-flip IOCTLs will be
serialized.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/ebf4cbdc/attachment.sig>
Am 08.10.2014 um 18:45 schrieb Thierry Reding:
> From: Thierry Reding
>
> OpenBSD wants to reuse this file but needs the license to be more
> permissive.
>
> Acked-by: Alban Bedel
> Acked-by: Daniel Vetter
> Signed-off-by: Thierry Reding
Not sure if it's necessary, but it might be that some of
art --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/630135f4/attachment.sig>
Am 09.10.2014 um 08:03 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/
Am 09.10.2014 um 08:02 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> The radeon driver uses placement range restrictions for several reasons,
> in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
> during a page fault.
>
> Without this change, TTM could evict other BOs while
Am 09.10.2014 um 09:54 schrieb Jerome Glisse:
> On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
>> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote:
>>> So idea is simple, each ioctl would use some struct like :
>>>
>>> struct radeon_ioctl {
>>> u32 version;
>>>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/58234f0f/attachment-0001.html>
On 2014-10-09 07:02, Michel D?nzer wrote:
> From: Michel D?nzer
>
> The radeon driver uses placement range restrictions for several
> reasons,
> in particular to make sure BOs in VRAM can be accessed by the CPU, e.g.
> during a page fault.
>
> Without this change, TTM could evict other BOs whil
On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse wrote:
>
> struct radeon_ioctl {
> u32 version;
> u32 size;
> };
How is this any different from just another ioctl multiplexer and why
can't we just add a new version if an ioctl needs to be revised? E.g.
in i915 we've just add
Depending of the board configuration i2c for ddc could change,
this patch allow to use a phandle to specify which i2c controller to use.
Signed-off-by: Benjamin Gaignard
---
.../devicetree/bindings/gpu/st,stih4xx.txt | 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 40 +++
gpio used for HDMI hot plug detection is useless,
HDMI_STI register contains an hot plug detection status bit.
Fix binding documentation.
Signed-off-by: Benjamin Gaignard
---
Documentation/devicetree/bindings/gpu/st,stih4xx.txt | 2 --
drivers/gpu/drm/sti/sti_hdmi.c | 11 +
Make sure that vblank is enabled when crtc commit is call.
Replace drm_vblank_off() by drm_crtc_vblank_off()
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drm_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c
b/driver
Hi Jerome,
Do you think your proposed change should also be applied to amdkfd's
IOCTLs ?
Oded
On 08/10/14 19:00, Jerome Glisse wrote:
> Hi,
>
> So if i do not start the discussion now it might be already too late. Given
> plan to converge open source driver and closed source driver to u
On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote:
> But there might be another issue, which is that calls to
> drm_vblank_get() will return -EINVAL if invoked between drm_blank_off
> and drm_blank_on. Is this really the desired behavior? Can it at least
> happen? If so, how a
On Wed, Oct 08, 2014 at 06:45:01PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> OpenBSD wants to reuse this file but needs the license to be more
> permissive.
>
> Acked-by: Alban Bedel
> Acked-by: Daniel Vetter
Also Acked-by: Daniel Vetter for the entire
Intel team.
-Daniel
> Signe
These counters are used for Displayort complinace testing to detect error
conditions
when executing certain compliance tests. Currently these are used in the EDID
tests
to determine if the video mode needs to be set to the preferred mode or the
failsafe
mode.
Cc: dri-devel at lists.freedesktop.
Sorry for the spam - Ignore the duplicates. There will be one more coming
when I post this series to intel-gfx.
-T
-Original Message-
From: Todd Previte [mailto:tprev...@gmail.com]
Sent: Thursday, October 09, 2014 8:33 AM
To: tprevite at gmail.com
Cc: dri-devel at lists.freedesktop.org
S
ed if having
a .drirc under $HOME without the workaround overrides one in /etc with it.
--
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
These counters are used for Displayort complinace testing to detect error
conditions
when executing certain compliance tests. Currently these are used in the EDID
tests
to determine if the video mode needs to be set to the preferred mode or the
failsafe
mode.
Cc: dri-devel at lists.freedesktop.
These counters are used for Displayort complinace testing to detect error
conditions
when executing certain compliance tests. Currently these are used in the EDID
tests
to determine if the video mode needs to be set to the preferred mode or the
failsafe
mode.
Cc: dri-devel at lists.freedesktop.
)
#9 0x0040cd98 in main ()
--
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/20141009/3adf3ebf/attachment.html>
On Thu, Oct 9, 2014 at 3:54 AM, Jerome Glisse wrote:
> On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
>> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote:
>> >
>> > So idea is simple, each ioctl would use some struct like :
>> >
>> > struct radeon_ioctl {
>> > u32 vers
On Thu, Oct 9, 2014 at 4:42 AM, Benjamin Gaignard
wrote:
> gpio used for HDMI hot plug detection is useless,
> HDMI_STI register contains an hot plug detection status bit.
> Fix binding documentation.
Random thought, but depending on how much you trust your hw designers
you may want to at least l
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/f1bd400c/attachment.html>
shading is causing GPU lockup on VERDE.
Should I open a separate bug for this issue?
--
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/attachm
On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote:
> Hi Jerome,
>
> Do you think your proposed change should also be applied to amdkfd's
> IOCTLs ?
It might make sense it really depends on the lifespan you expect for
amdkfd, do you expect that you will need substential API evolution
dur
On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote:
> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote:
> >
> > So idea is simple, each ioctl would use some struct like :
> >
> > struct radeon_ioctl {
> > u32 version;
> > u32 size;
> > };
>
>
> fwiw, drm_ioctl(
On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote:
>
> So idea is simple, each ioctl would use some struct like :
>
> struct radeon_ioctl {
> u32 version;
> u32 size;
> };
fwiw, drm_ioctl() will do the right thing (zero-pad) for growing
ioctls these days..
BR,
-R
'll do some debug runs.
--
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/20141009/88e25212/attachment.html>
> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Wednesday, October 08, 2014 12:45 PM
> To: David Airlie
> Cc: Daniel Vetter; Deucher, Alexander; Alban Bedel; dri-
> devel at lists.freedesktop.org
> Subject: [PATCH] video/hdmi: Relicense header under
68 matches
Mail list logo
