Hi Rahul,
On Thursday 20 of June 2013 07:41:53 Rahul Sharma wrote:
> Hi Tomasz, Lucas,
>
> How does this patch look to you ? Please share your views.
Looks fine now. Have my
Reviewed-by: Tomasz Figa
for the whole series.
Best regards,
Tomasz
> regards,
> Rahul Sharma.
>
> On Wed, Jun 19, 2
https://bugzilla.kernel.org/show_bug.cgi?id=58021
wipp...@gmx.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
>
> > -Original Message-
> > From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> > [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> > Behalf Of Russell King - ARM Linux
> > Sent: Thursda
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Thursday, June 20, 2013 4:47 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> ker...@lists.inf
Am Donnerstag, den 20.06.2013, 09:17 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> > Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> > >
> > > > -Original Message-
> > > > From: dri-devel-bounces+inki.dae=samsung
https://bugs.freedesktop.org/show_bug.cgi?id=65958
Priority: medium
Bug ID: 65958
Assignee: dri-devel@lists.freedesktop.org
Summary: GPU Lockup on Trinity 7500G
Severity: normal
Classification: Unclassified
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=65958
--- Comment #1 from Mike Lothian ---
Created attachment 81099
--> https://bugs.freedesktop.org/attachment.cgi?id=81099&action=edit
Lspci
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Wed, Jun 19, 2013 at 02:00:45PM +0200, Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/DocBook/drm.tmpl | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> ind
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
> > > In addition, please see the below more detail examples.
> > >
> > > The conventional way (without dmabuf-sync) is:
> > > Task A
> > >
> > > 1. CPU accesses buf
> > > 2. Send the buf to Task B
> >
Hi Thierry,
On Thursday 20 June 2013 12:10:47 Thierry Reding wrote:
> On Wed, Jun 19, 2013 at 02:00:45PM +0200, Laurent Pinchart wrote:
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > Documentation/DocBook/drm.tmpl | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
Hi Dave,
Could you please pull the following four shmob-drm patches for v3.11 ?
The following changes since commit dc28aa072f502433b6adc5c9ae8f56955c07580a:
gpu:drm:tilcdc: get preferred_bpp value from DT (2013-06-20 14:08:01 +1000)
are available in the git repository at:
git://linuxtv.org
Hi Dave,
The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:
Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux.git drm/fixes
for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804
On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Thursday 20 June 2013 12:10:47 Thierry Reding wrote:
> > On Wed, Jun 19, 2013 at 02:00:45PM +0200, Laurent Pinchart wrote:
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > >
> > > Documentation/DocBo
Hi Thierry,
On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > On Thursday 20 June 2013 12:10:47 Thierry Reding wrote:
> > > On Wed, Jun 19, 2013 at 02:00:45PM +0200, Laurent Pinchart wrote:
> > > > Signed-off-by: Laurent
On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> > On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > > On Thursday 20 June 2013 12:10:47 Thierry Reding wrote:
> > > > On Wed, Jun 19, 20
> -Original Message-
> From: Lucas Stach [mailto:l.st...@pengutronix.de]
> Sent: Thursday, June 20, 2013 7:11 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> ker...@lists.inf
This will allow me to call functions that have multiple arguments if fastpath
fails.
This is required to support ticket mutexes, because they need to be able to
pass an
extra argument to the fail function.
Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg.
This e
Changes since v4:
- Some documentation cleanups.
- Added a lot more tests to cover all the DEBUG_LOCKS_WARN_ON cases.
- Added EDEADLK tests.
- Split off the normal mutex tests to a separate patch.
- Added a patch to not allow tests to fail that succeed with PROVE_LOCKING
enabled.
---
Daniel Vett
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex
This stresses the lockdep code in some ways specifically useful to
ww_mutexes. It adds checks for most of the common locking errors.
Changes since v1:
- Add tests to verify reservation_id is untouched.
- Use L() and U() macros where possible.
Changes since v2:
- Use the ww_mutex api directly.
From: Daniel Vetter
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and th
None of the ww_mutex codepaths should be taken in the 'normal'
mutex calls. The easiest way to verify this is by using the
normal mutex calls, and making sure o.ctx is unmodified.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 62
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 264 +++-
1 file changed, 261 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 37faefd..d554f3f 100644
--- a/lib/locking-selftest.c
+++ b/lib
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to
pass unexpectedly, but there no tests that should start to fail that
pass with CONFIG_PROVE_LOCKING enabled.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c |8 +---
1 file changed, 5 insertions(+), 3 deleti
Op 20-06-13 13:55, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>> - removed mutex_locked_set_res
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Priority: medium
Bug ID: 65968
Assignee: dri-devel@lists.freedesktop.org
Summary: Massive memory corruption in Planetary Annihilation
Alpha
Severity: normal
Classificatio
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #1 from Andreas Ringlstetter ---
Created attachment 81106
--> https://bugs.freedesktop.org/attachment.cgi?id=81106&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #2 from Andreas Ringlstetter ---
Created attachment 81107
--> https://bugs.freedesktop.org/attachment.cgi?id=81107&action=edit
glxinfo log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Andreas Ringlstetter changed:
What|Removed |Added
Attachment #81105|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=65968
--- Comment #4 from Andreas Ringlstetter ---
PS:
I will not be able to test with 9.0 or 9.1 since one of the shaders causes a
segfault while compiling in these version. This has only recently (last 1-2
months) been fixed in git.
This was caused
https://bugs.freedesktop.org/show_bug.cgi?id=65958
--- Comment #2 from Alex Deucher ---
Does setting the env var RADEON_VA=0 in your /etc/environment fix the issue?
This looks like a mesa issue.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=65963
Alex Deucher changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=65968
Alex Deucher changed:
What|Removed |Added
Attachment #81105|text/plain |image/jpeg
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=65963
--- Comment #2 from Damian Nowak ---
Thanks for taking a look at it. Package versions as follows. Pasting a
PKGBUILDs so you can see the flags for compilation.
extra/mesa 9.1.3-1
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/
On Wed, Jun 19, 2013 at 01:45:45AM +0200, Laurent Pinchart wrote:
> Hello Adam,
>
> Ping ?
>
> Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
> get_modes operation that just returns 0 ?
Yeah, I guess that works, too.
-Daniel
>
> On Friday 14 June 2013 16:03:19 D
On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote:
> On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> > > On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > > > On Thu
Hi,
I am implementing HDMI hotplug feature for i.MX6 platform,
the basic function has already been done and works
But there is is an "issue",
When bootup system without HDMI cable attached, fbdev is initialised
with fbsize: 1024x768, after plug-in HDMI cable, I can see in debug log,
display's v
From: Alex Deucher
Hi Dave,
Just one more fix for radeon. Patch from Jerome to avoid GPU
resets due to false positives when the ring is empty.
The following changes since commit c139b1ee4e36374af705660af6172d7477352792:
drm/radeon: fix UVD on big endian (2013-06-14 17:05:57 -0400)
are
> git://anongit.freedesktop.org/tegra/linux.git drm/fixes
>
> for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
>
> gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
>
> I know this comes awfully late and is much bigger than I'd like. It's
> all my f
On Fri, Jun 21, 2013 at 06:37:30AM +1000, Dave Airlie wrote:
> > git://anongit.freedesktop.org/tegra/linux.git drm/fixes
> >
> > for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
> >
> > gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
> >
> > I kno
Hi Linus,
one core fix, but mostly radeon fixes for s/r and big endian UVD support,
and a fix to stop the GPU being reset for no good reason, and crashing
people's machines.
Dave.
The following changes since commit df63d3ecbca514bad99513b2401448d19a9bb92e:
Merge tag 'drm-intel-fixes-2013-06
On Fri, Jun 21, 2013 at 10:02 AM, Mike Turquette wrote:
> Quoting Kukjin Kim (2013-06-19 07:01:17)
>> On 06/19/13 13:04, Rahul Sharma wrote:
>> > + mike
>> >
>> Mike, I'm waiting for your reply on this. If you're OK, let me take this
>> series on top of exynos5420 stuff in samsung tree.
>>
>> Of c
+Mike
On Mon, Jun 10, 2013 at 4:17 PM, Rahul Sharma wrote:
> This patch is already posted at
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg18331.html
> and
>
> Reviewed-by: Doug Anderson
>
> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma
> wrote:
>> From: Arun Kumar K
>>
>
+Mike
On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma wrote:
> hdmi driver needs to change the parent of hdmi clock
> frequently between pixel clock and hdmiphy clock. hdmiphy is
> not stable after power on and for a short interval while changing
> the phy configuration. For this duration pixel clo
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> hdmi driver needs hdmiphy clock which is one of the parent
> for hdmi mux clock. This is required while changing the parent
> of mux clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5250-clo
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> Adding sysmmu clock for tv for exynos5250 SoC. It also
> adds aclk200_disp1 mux which is the actual parent of the
> disp1 block (contains hdmi, mixer, sysmmu_tv).
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindin
+Mike
On Mon, Jun 10, 2013 at 4:31 PM, Rahul Sharma wrote:
> parent of hdmi and mixer block is mentioned as aclk200 which is
> not correct. It is clocked by the ouput of aclk200_disp1. Hence
> parent for mixer and hdmi clocks is changed to aclk200_disp1.
>
> Signed-off-by: Rahul Sharma
> ---
>
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Add sclk_hdmiphy to the list of exposed clocks. This is required
> by hdmi driver to change the parent of hdmi clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> dri
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Adding sysmmu clock for tv for exynos5420.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
> drivers/clk/samsung/clk-exynos5420.c |3 ++-
> 2 f
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Listing sclk_hdmiphy at 0th position in the list of parents is
> causing wrong configuration in reg SRC_DISP10.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/clk/samsung/clk-exynos5420.c |2 +-
> 1 file changed, 1 insertion(+),
+Mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> hdmi driver needs to change the parent of hdmi clock
> to pixel clock or hdmiphy clock, based on the stability
> of hdmiphy. This patch is exposing the mux for changing
> the parent.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentati
+Mike
On Tue, Jun 18, 2013 at 7:54 PM, Rahul Sharma wrote:
> With this patch, it is at par with Exynos5250 and Exynos4 clocks
> where sclk_pixel ID is assigned to a divider clock but in real,
> sclk_pixel is listed under gate clocks (enum value).
>
> Alternate to this, I can allocate a new ID, di
2013/6/20 Rahul Sharma
> Thanks Mr. Kim,
>
> I will post v4 with aforesaid change.
>
>
You don't need to re-post it. I gonna change it to "ARM/dts: change
compatible strings for Exynos5250 hdmi subsystem", and merge it. Is there
another you want?
Thanks,
Inki Dae
regards,
> Rahul Sharma.
>
> O
Thanks Mr. Dae, nothing else for this series.
On Fri, Jun 21, 2013 at 10:47 AM, Inki Dae wrote:
>
>
>
> 2013/6/20 Rahul Sharma
>>
>> Thanks Mr. Kim,
>>
>> I will post v4 with aforesaid change.
>>
>
> You don't need to re-post it. I gonna change it to "ARM/dts: change
> compatible strings for Ex
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
ore dma access
as long as possible. Of course, user process need to call dma-buf
interfaces or simliar things for buffer synchronization with DMA side.
However, as of now, there is no good idea: I had implemented the user
interfaces in dma-buf framework but that was just to show you so ugly. The
eventual purpose of my approach is to integrate sync interfaces with dmabuf
sync, and this approach can be used commonly for v4l2, drm drivers, user
processes, and so on: as I already mentioned in document file, this
approach is for DMA devices using system memory as DMA buffer, especially
most ARM SoCs.
Thanks,
Inki Dae
> Regards,
> Lucas
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/7eb4db6c/attachment-0001.html>
From: Dave Airlie
So it looks like for virtual hw cursors on QXL we need to inform
the "hw" device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing
From: Dave Airlie
This uses the cursor hotspot info from userspace and passes
it to the qxl hw layer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drive
Hello Rahul,
This patch is exactly same with v2 2/4 and only rebased on v3 1/3, so my
ack is valid for this patch.
On 2013? 06? 19? 21:51, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
Anyway, this p
Hi Tomasz, Lucas,
How does this patch look to you ? Please share your views.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 6:21 PM, Rahul Sharma
wrote:
> This patch adds new combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which rep
>>
>> Signed-off-by: Benoit Parrot
>
> Acked-by: Rob Clark
Applied to -next,
thanks,
Dave.
On Thu, Jun 20, 2013 at 12:45 AM, Laurent Pinchart
wrote:
> The enabled field has been removed from struct drm_plane. Don't use it
> in the driver.
Applied to -next,
Dave.
From: Wei Yongjun
The dereference should be moved below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Russell King - ARM Linux
> Sent: Thursday, June 20, 2013 3:29 AM
> To: Inki Dae
> Cc: linux-fbdev; DRI mai
Hi Rahul,
On Thursday 20 of June 2013 07:41:53 Rahul Sharma wrote:
> Hi Tomasz, Lucas,
>
> How does this patch look to you ? Please share your views.
Looks fine now. Have my
Reviewed-by: Tomasz Figa
for the whole series.
Best regards,
Tomasz
> regards,
> Rahul Sharma.
>
> On Wed, Jun 19, 2
https://bugzilla.kernel.org/show_bug.cgi?id=58021
wippbox at gmx.net changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
>
> > -Original Message-
> > From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> > [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> > Behalf Of Russell King - ARM Linux
> > Sent: T
> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Thursday, June 20, 2013 4:47 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> kernel at lis
Am Donnerstag, den 20.06.2013, 09:17 +0100 schrieb Russell King - ARM
Linux:
> On Thu, Jun 20, 2013 at 09:47:07AM +0200, Lucas Stach wrote:
> > Am Donnerstag, den 20.06.2013, 15:43 +0900 schrieb Inki Dae:
> > >
> > > > -Original Message-
> > > > From: dri-devel-bounces+inki.dae=samsung.com
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/c4274402/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/5d354bf6/attachment-0001.html>
_VBLANK won't work properly.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/47a949f9/attachment.pgp>
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
> > > In addition, please see the below more detail examples.
> > >
> > > The conventional way (without dmabuf-sync) is:
> > > Task A
> > >
> > > 1. CPU accesses buf
> > > 2. Send the buf to Task B
> >
ion manually
> you also need to manually set drm->irq_enabled = 1, as otherwise things
> like DRM_IOCTL_WAIT_VBLANK won't work properly.
That's only needed if DRIVER_HAVE_IRQ is set, otherwise the drm_wait_vblank()
function skips the irq_enabled check.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/04e70f6b/attachment.pgp>
Hi Dave,
Could you please pull the following four shmob-drm patches for v3.11 ?
The following changes since commit dc28aa072f502433b6adc5c9ae8f56955c07580a:
gpu:drm:tilcdc: get preferred_bpp value from DT (2013-06-20 14:08:01 +1000)
are available in the git repository at:
git://linuxtv.org
;http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/3fe39495/attachment.pgp>
)
> function skips the irq_enabled check.
Not quite. There's another check for dev->irq_enabled in the
DRM_WAIT_ON() so it'll never actually block. Arguably this could be
solved by making the DRM_WAIT_ON() condition drop the !dev->irq_enabled
in case DRIVER_HAVE_IRQ isn't set.
I'll see if I can find the time to come up with a patch.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/dac54ffe/attachment-0001.pgp>
et drm->irq_enabled = 1, as otherwise things
> > > like DRM_IOCTL_WAIT_VBLANK won't work properly.
> >
> > That's only needed if DRIVER_HAVE_IRQ is set, otherwise the
> > drm_wait_vblank() function skips the irq_enabled check.
>
> Not quite. There's another check for dev->irq_enabled in the
> DRM_WAIT_ON() so it'll never actually block.
Indeed.
> Arguably this could be solved by making the DRM_WAIT_ON() condition drop the
> !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set.
Or we could force drivers to set drm->irq_enabled, I'm fine with that as well.
I can fix the documentation if that would be the preferred solution.
> I'll see if I can find the time to come up with a patch.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/ccec4b09/attachment.pgp>
T_ON() condition drop the
> > !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set.
>
> Or we could force drivers to set drm->irq_enabled, I'm fine with that as
> well.
> I can fix the documentation if that would be the preferred solution.
Thinking about it some more, the latter seems more appropriate. Consider
some driver that doesn't set DRIVER_HAVE_IRQ but also doesn't initialize
interrupts manually. If so it'll cause DRM_IOCTL_WAIT_VBLANK to block
indefinitely.
On the other hand perhaps the check at the beginning of drm_wait_vblank
should be improved. Maybe make it something like this:
if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
if (!drm_dev_to_irq(dev))
return -EINVAL;
if (!dev->irq_enabled)
return -EINVAL;
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/2d9f4896/attachment.pgp>
> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Thursday, June 20, 2013 7:11 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
> 'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
> kernel at lis
This will allow me to call functions that have multiple arguments if fastpath
fails.
This is required to support ticket mutexes, because they need to be able to
pass an
extra argument to the fail function.
Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg.
This e
Changes since v4:
- Some documentation cleanups.
- Added a lot more tests to cover all the DEBUG_LOCKS_WARN_ON cases.
- Added EDEADLK tests.
- Split off the normal mutex tests to a separate patch.
- Added a patch to not allow tests to fail that succeed with PROVE_LOCKING
enabled.
---
Daniel Vett
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex
This stresses the lockdep code in some ways specifically useful to
ww_mutexes. It adds checks for most of the common locking errors.
Changes since v1:
- Add tests to verify reservation_id is untouched.
- Use L() and U() macros where possible.
Changes since v2:
- Use the ww_mutex api directly.
From: Daniel Vetter
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and th
None of the ww_mutex codepaths should be taken in the 'normal'
mutex calls. The easiest way to verify this is by using the
normal mutex calls, and making sure o.ctx is unmodified.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 62
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c | 264 +++-
1 file changed, 261 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 37faefd..d554f3f 100644
--- a/lib/locking-selftest.c
+++ b/lib
When CONFIG_PROVE_LOCKING is not enabled, more tests are expected to
pass unexpectedly, but there no tests that should start to fail that
pass with CONFIG_PROVE_LOCKING enabled.
Signed-off-by: Maarten Lankhorst
---
lib/locking-selftest.c |8 +---
1 file changed, 5 insertions(+), 3 deleti
Op 20-06-13 13:55, Ingo Molnar schreef:
> * Maarten Lankhorst wrote:
>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
>> - removed mutex_locked_set_res
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/5bce7ee3/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/1b611fdd/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/82f8b661/attachment.html>
tion in other
textures is already starting.
--
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/20130620/21da2ace/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/ef7d0ab4/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/1823eb33/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/6fee18aa/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/20130620/2ec56af5/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130620/fdadba66/attachment.html>
On Wed, Jun 19, 2013 at 01:45:45AM +0200, Laurent Pinchart wrote:
> Hello Adam,
>
> Ping ?
>
> Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
> get_modes operation that just returns 0 ?
Yeah, I guess that works, too.
-Daniel
>
> On Friday 14 June 2013 16:03:19 D
On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote:
> On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
> > > On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
> > > > On Thu
1 - 100 of 121 matches
Mail list logo
