Hi,
I am seeing this also on Linux-Next.
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
/var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux
On 26 February 2013 18:11, James Courtier-Dutton
wrote:
> On 26 February 2013 17:35, Greg KH wrote:
>> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
>>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
>>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
>>> > >
https://bugzilla.kernel.org/show_bug.cgi?id=54581
Summary: Radeon: Failed to parse relocation, gem object lookup
failed
Product: Drivers
Version: 2.5
Kernel Version: 3.8
Platform: All
OS/Version: Linux
Tree: M
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #35 from Jakob Nixdorf ---
Yes, it seems the dmesg errors are gone. I will try piglit later to confirm
this.
--
You are receiving this mail because:
You are the assignee for the bug.
___
d
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/20130227/873835b8/attachment.html>
s patch:
http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.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/attachment
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/c7fcce13/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/02dbbbc0/attachment.html>
On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer wrote:
> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote:
>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote:
>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote:
Alex Deucher (29):
drm/radeon: halt engines before disabling MC
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrot
e ATI RV670 [Radeon HD 3870], Git kernel (pre 3.9))
--
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/20130227/9e06d1dc/attachment.html>
On Wed, Feb 27, 2013 at 6:14 PM, John Stultz wrote:
> Also note: I've done this so far without any feedback from the Android devs
> (despite my reaching out to Erik a few times recently), so if they object to
> pushing it to staging, in deference to it being their code I'll back off,
> even though
On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote:
>>> Alex Deucher (29):
>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>> drm/radeon: halt engines before disabl
On Thu, Feb 28, 2013 at 8:21 AM, Joonyoung Shim wrote:
> On 02/28/2013 11:45 AM, Vikas Sajjan wrote:
>>
>> Hi,
>>
>> On 28 February 2013 08:07, Joonyoung Shim wrote:
>>>
>>> On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
>>
e lights behind some big
fans in level 8.
HD3850 (RV670) AGP, kernel 3.8.0
--
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/attach
Hi
2013/2/25 Rodrigo Vivi :
> From: Shobhit Kumar
>
> Signed-off-by: Sateesh Kavuri
>
> v2: Modified and corrected the structures to be more in line for
> kernel coding guidelines and rebased the code on Paulo's DP patchset
>
> Signed-off-by: Shobhit Kumar
>
> v3: removing unecessary identation
On 02/28/2013 11:45 AM, Vikas Sajjan wrote:
Hi,
On 28 February 2013 08:07, Joonyoung Shim wrote:
On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
ex
On 02/27/2013 07:32 PM, Vikas Sajjan wrote:
modified compatible string for exynos4 fimd as "exynos4210-fimd" and
exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discusse
On 02/27/2013 08:49 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Am
On Wed, Feb 27, 2013 at 06:14:24PM -0800, John Stultz wrote:
> I'd like to get a discussion going about submitting the Android sync
> driver to staging.
>
> I know there is currently some very similar work going on with the
> dmabuf-fences, and rather then both approaches being worked out
> indivi
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #34 from Alexandre Demers ---
(In reply to comment #32)
> Created attachment 75658 [details] [review]
> align dma commands to 8 dwords
>
> Does this patch help? You might also try it in combination with this patch:
> http://lists.fr
I'd like to get a discussion going about submitting the Android sync
driver to staging.
I know there is currently some very similar work going on with the
dmabuf-fences, and rather then both approaches being worked out
individually on their own, I suspect there could be better collaboration
ar
g I noticed while using the new videomode, display_timings.h
has a few names that are quite short and generic. Like "TE_MIN", which
is now a global define. And "timing_entry". Either name could be well
used internally in some .c file, and could easily clash.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/4e36f403/attachment-0001.pgp>
Hi,
On 02/21/2013 04:18 PM, Joonyoung Shim wrote:
On 02/21/2013 04:12 PM, Vikas Sajjan wrote:
Hi,
On 21 February 2013 12:25, Joonyoung Shim
wrote:
Hi,
On 02/15/2013 03:43 PM, Vikas Sajjan wrote:
Add support for parsing the display-timing node using video helper
function.
The DT node par
ags" field? What does it give us to
> have those two separately?
>
> Should the above say raising edge/falling edge instead of positive
> edge/negative edge?
>
> Tomi
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type:
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/5a821b4d/attachment.html>
error.
This makes me think the adapters are fine :)
--
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/20130227/2627e552/attachm
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drive
Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
It also adds pinctrl support for drm fimd.
changes since v7:
- addressed comments from Joonyoung Shim
to remove a unnecessar
Ah, sorry. Forgot to answer this.
On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
> Ping.
>
> On 2013-02-18 16:09, Tomi Valkeinen wrote:
> > Hi Steffen,
> >
> > On 2013-01-25 11:01, Steffen Trumtrar wrote:
> >
> >> +/* VESA display monitor timing parameters */
> >> +#define VESA
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #11 from Alex Deucher 2013-02-27
17:04:56 ---
Created an attachment (id=94191)
--> (https://bugzilla.kernel.org/attachment.cgi?id=94191)
add quirk for 9100 board
This should fix your board.
--
Configure bugmail: https://bugzi
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/49b6d004/attachment.html>
Hi
2013/2/25 Rodrigo Vivi :
> While old platforms had 3 transcoders and 3 pipes (1:1), HSW has
> 4 transcoders and 3 pipes.
> These regs were being used only by HDMI code where pipe is always the same
> thing as cpu_transcoder.
> This patch allow us to use them for DP, specially for TRANSCODER_EDP
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/50e937bc/attachment.html>
ected and configured correctly by the driver.
--
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/20130227/f9f37044/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/cb0937db/attachment.html>
modified compatible string for exynos4 fimd as "exynos4210-fimd" and
exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/214486
On Wed, Feb 27, 2013 at 11:27:30PM +, James Courtier-Dutton wrote:
> On 26 February 2013 18:11, James Courtier-Dutton
> wrote:
> > On 26 February 2013 17:35, Greg KH wrote:
> >> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> >>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH w
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/7eb9dc8a/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/709dc855/attachment.html>
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/20130227/63ece496/attachment-0001.html>
Hi Linus,
Here's the 3.9 pull request for dma-buf framework updates: could you
please pull?
Thanks and best regards,
~Sumit.
The following changes since commit d895cb1af15c04c522a25c79cc429076987c089b:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2013-0
On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer wrote:
> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote:
>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote:
>>> Alex Deucher (29):
>>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>>> drm/radeon: halt engines before disabl
On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer wrote:
> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote:
>> Alex Deucher (29):
>> drm/radeon: halt engines before disabling MC (6xx/7xx)
>> drm/radeon: halt engines before disabling MC (evergreen)
>> drm/radeon: halt engines befor
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/697bc5be/attachment.html>
Hi Mr.Shim,
On 21 February 2013 12:35, Joonyoung Shim wrote:
> Hi,
>
>
> On 02/21/2013 02:11 PM, Vikas Sajjan wrote:
>>
>> Adds support for pinctrl to drm fimd.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c |9
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #33 from Jakob Nixdorf ---
No, I still get corruption in Trine 2 and on some CS:S textures with this patch
(also in combination with the one you linked).
Should I try all 5 patches in the set you linked or only 3/5 ?
--
You are rec
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/5455f5dd/attachment.html>
#x27;t be reading
this register shortly after writing to 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/attachments/20130227/3e8065ac/attachment.html>
Hi
2013/2/25 Rodrigo Vivi :
> From: Shobhit Kumar
>
> Signed-off-by: Sateesh Kavuri
>
> v2: Modified and corrected the structures to be more in line for
> kernel coding guidelines and rebased the code on Paulo's DP patchset
>
> Signed-off-by: Shobhit Kumar
>
> v3: removing unecessary identation
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/d7579843/attachment.html>
Imre fail, though I think Daniel is
on holiday this week,
so maybe if you can make it revert, that might be the best option,
If you want to just bump it so Ironlake isn't affected, (patch attached).
Is this external DP monitor or eDP laptop panel btw?
Dave.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch
Type: application/octet-stream
Size: 998 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/c9514608/attachment.obj>
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #32 from Alex Deucher ---
Created attachment 75658
--> https://bugs.freedesktop.org/attachment.cgi?id=75658&action=edit
align dma commands to 8 dwords
Does this patch help? You might also try it in combination with this patch:
htt
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #27 from Bryan Quigley ---
> The only patch that's relevant for r6xx is 2/5. Does that help?
That's just turning that off (same as a revert specific to r600 though). Works
perfectly.
--
You are receiving this mail because:
You ar
On Wed, Feb 27, 2013 at 11:21 AM, Stéphane Marchesin
wrote:
> On Wed, Feb 27, 2013 at 3:49 AM, Vikas Sajjan wrote:
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the NON
On Wed, Feb 27, 2013 at 11:21 AM, St?phane Marchesin
wrote:
> On Wed, Feb 27, 2013 at 3:49 AM, Vikas Sajjan
> wrote:
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #26 from Alex Deucher ---
(In reply to comment #25)
> > Could you test this patch
> > http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.html
>
> Patch 3/5 doesn't help for me. Should I try out the other patches in
Thanks Sean,
On Tue, Feb 26, 2013 at 11:33 PM, Sean Paul wrote:
> On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma
> wrote:
>> Exynos5 is already using drm_display_mode for timings parameters. Exynos4
>> is also modifed to use the same. List of supported resolutions and
>> corresponding timings ar
Hi
2013/2/25 Rodrigo Vivi :
> While old platforms had 3 transcoders and 3 pipes (1:1), HSW has
> 4 transcoders and 3 pipes.
> These regs were being used only by HDMI code where pipe is always the same
> thing as cpu_transcoder.
> This patch allow us to use them for DP, specially for TRANSCODER_EDP
On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie wrote:
> Alex Deucher (29):
> drm/radeon: halt engines before disabling MC (6xx/7xx)
> drm/radeon: halt engines before disabling MC (evergreen)
> drm/radeon: halt engines before disabling MC (cayman/TN)
> drm/radeon: halt engines
Thanks Sean,
On Tue, Feb 26, 2013 at 10:55 PM, Sean Paul wrote:
> On Tue, Feb 26, 2013 at 7:16 AM, Rahul Sharma
> wrote:
>> Exynos hdmi driver is using drm_display_mode for setting timing values
>> for a supported resolution. Conversion to fb_videomode and then comparing
>> with the mixer/hdmi/
On Wed, Feb 27, 2013 at 3:49 AM, Vikas Sajjan wrote:
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-
On Wed, Feb 27, 2013 at 3:49 AM, Vikas Sajjan
wrote:
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #25 from Bryan Quigley ---
> Could you test this patch
> http://lists.freedesktop.org/archives/mesa-dev/2013-February/035347.html
Patch 3/5 doesn't help for me. Should I try out the other patches in that
series? (nee ATI RV670 [Rade
On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma
wrote:
> Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
> related
> code is tightly coupled with hdmi ip driver. Physicaly they are different
> devices and
s/Physicaly/Physically/
> should be instantiated independent
https://bugs.freedesktop.org/show_bug.cgi?id=50135
--- Comment #9 from Simone Scanzoni ---
I still have this problem with Mesa 9.2-devel (git-4deefd9)
( patched with:
r600g: emit a ps partial flush after CP DMA
r600g: enable CP DMA on r6xx (v3) )
The night times scenes work better with force_gl
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #10 from ??? ? 2013-02-27 10:30:02
---
Created an attachment (id=94181)
--> (https://bugzilla.kernel.org/attachment.cgi?id=94181)
ATI Radeon 9100 BIOS dump
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cg
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #9 from ??? ? 2013-02-27 10:27:38 ---
Created an attachment (id=94171)
--> (https://bugzilla.kernel.org/attachment.cgi?id=94171)
ATI Radeon 9100 registers (with and without KMS)
I've tried `radeontool regs' both with and
https://bugzilla.kernel.org/show_bug.cgi?id=14945
??? ? changed:
What|Removed |Added
CC||rootlexx at mail.ru
--- Comment #8 fr
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/bbbcecc5/attachment.html>
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro
> > horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
We number of gathers is limited
by HOST1X_GATHER_QUEUE_SIZE, right? So we could allocate a buffer of the
appropriate size for each job to avoid continuously reallocating and
freeing everytime the job in pinned or unpinned.
Also jobs are allocated for each submit and allocating them is quite
expensive, so eventually we may want to pool them. Which will not be
trivial though, given that it requires the number of command buffers
and relocs to match. Some clever checks can probably make this work,
though.
> >> + /* Null kickoff prevents submit from being sent to hardware */
> >> + bool null_kickoff;
> >
> > I don't think this is used anywhere.
>
> True, we can remove this as we haven't posted the code for null kickoff.
Make sure to explain what this is used for when you post. The one
comment above is a bit vague.
> >> + /* Check if register is marked as an address reg */
> >> + int (*is_addr_reg)(struct platform_device *dev, u32 reg, u32 class);
> >
> > is_addr_reg() sounds a bit unusual. Maybe match this to the name of the
> > main firewall routine, validate()?
>
> The point of this op is to just tell if a register for a class is
> pointing to a buffer. validate then uses this information. But both
> answers (yes/no) and both types of registers are still valid, so
> validate() wouldn't be the proper name.
>
> validation is then done by checking that there's a reloc corresponding
> to each register write to a register that can hold an address.
I just remembered that we discussed this already and I think we agreed
that a table lookup might be a better implementation. That'd get rid of
the naming issue altogether, since you can just name the table something
like address_registers, which is quite unambiguous.
> >> diff --git a/drivers/gpu/host1x/memmgr.h b/drivers/gpu/host1x/memmgr.h
> > [...]
> >> +struct mem_handle;
> >> +struct platform_device;
> >> +
> >> +struct host1x_job_unpin_data {
> >> + struct mem_handle *h;
> >> + struct sg_table *mem;
> >> +};
> >> +
> >> +enum mem_mgr_flag {
> >> + mem_mgr_flag_uncacheable = 0,
> >> + mem_mgr_flag_write_combine = 1,
> >> +};
> >
> > I'd like to see this use a more object-oriented approach and more common
> > terminology. All of these handles are essentially buffer objects, so
> > maybe something like host1x_bo would be a nice and short name.
> >
> > To make this more object-oriented, I propose something like:
> >
> > struct host1x_bo_ops {
> > int (*alloc)(struct host1x_bo *bo, size_t size, unsigned
> > long align,
> > unsigned long flags);
> > int (*free)(struct host1x_bo *bo);
> > ...
> > };
> >
> > struct host1x_bo {
> > const struct host1x_bo_ops *ops;
> > };
> >
> > struct host1x_cma_bo {
> > struct host1x_bo base;
> > struct drm_gem_cma_object *obj;
> > };
> >
> > static inline struct host1x_cma_bo *to_host1x_cma_bo(struct
> > host1x_bo *bo)
> > {
> > return container_of(bo, struct host1x_cma_bo, base);
> > }
> >
> > static inline int host1x_bo_alloc(struct host1x_bo *bo, size_t size,
> > unsigned long align, unsigned
> > long flags)
> > {
> > return bo->ops->alloc(bo, size, align, flags);
> > }
> >
> > ...
> >
> > That should be easy to extend with a new type of BO once the IOMMU-based
> > allocator is ready. And as I said it is much closer in terminology to
> > what other drivers do.
>
> One complexity is that we're using the same type for communicating with
> user space. Each buffer carries with it a flag indicating its allocator.
> We might be able to model the internal structure to be more like what
> you propose, but for the API we still need the flag.
I disagree. I don't see any need for passing around the type at all.
We've discussed this a few times already, and correct me if I'm wrong,
but I think we agreed that we don't want to mix handle/buffer types.
We only support CMA for now, so all buffers will be allocated from CMA.
Once the IOMMU-based allocator is ready we'll want to switch to that for
Tegra30 and later, but stick to CMA for Tegra20 since the GART isn't
very usable.
So the way I see it, the decision about which allocator to use is done
once at driver probe time. So all that's really needed is a function
that allocates a buffer object and returns the proper one for the given
Tegra SoC. Once a host1x_bo object is returned it can be used throughout
and we get rid of the additional memmgr abstraction. I think it'll make
things much simpler.
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/20130227/36dcdc05/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #31 from Lucas Kannebley Tavares ---
I just altered the patch, removing the reads that were forced after writes to
make it less intrusive and the results are the same.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #30 from Lucas Kannebley Tavares ---
Well, I don't have an x86 system to test that on. I could get one, in time.
What I do have are two different adapters, bought separately, on two different
ppc64 systems with the exact same error.
On Wed, Feb 27, 2013 at 07:25:35PM +1000, Ben Skeggs wrote:
> On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> > On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #11 from Alex Deucher 2013-02-27 17:04:56
---
Created an attachment (id=94191)
--> (https://bugzilla.kernel.org/attachment.cgi?id=94191)
add quirk for 9100 board
This should fix your board.
--
Configure bugmail: https://bugzi
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #8 from Alex Deucher ---
(In reply to comment #7)
> I have an E2-1800 but it doesn't appear to be detected as a Wrestler.
>
> glxinfo yields:
>
> OpenGL vendor string: X.Org
> OpenGL renderer string: Gallium 0.4 on AMD PALM
> OpenGL
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #29 from Alex Deucher ---
Does the card work on an x86 system (even just checking to see if the bios post
screen is fine)? I just want to confirm that it's not an issue with the card
itself.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #7 from Philippe Leblanc ---
I have an E2-1800 but it doesn't appear to be detected as a Wrestler.
glxinfo yields:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PALM
OpenGL version string: 2.1 Mesa 9.1
OpenG
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related
code is tightly coupled with hdmi ip driver. Physicaly they are different
devices and
should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent of
each
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #24 from Andreas Boll ---
(In reply to comment #23)
> Mesa 9.2-devel (git-4deefd9) showed the problem here with TF2, I don't have
> CSS.
> Added patches:
> r600g: emit a ps partial flush after CP DMA
> r600g: enable CP DMA on r6xx (
Ah, sorry. Forgot to answer this.
On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote:
> Ping.
>
> On 2013-02-18 16:09, Tomi Valkeinen wrote:
> > Hi Steffen,
> >
> > On 2013-01-25 11:01, Steffen Trumtrar wrote:
> >
> >> +/* VESA display monitor timing parameters */
> >> +#define VESA
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related
code is tightly coupled with hdmi ip driver. Physicaly they are different
devices and
should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent of
each
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
Add support for parsing the display-timing node using video helper
function.
The DT node parsing and pinctrl selection is done only if 'dev.of_node'
exists and the NON-DT logic is still maintained under the 'else' part.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drive
Add display-timing node parsing to drm fimd and depends on
the display helper patchset at
http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html
It also adds pinctrl support for drm fimd.
changes since v7:
- addressed comments from Joonyoung Shim to
remove a unnecessar
modified compatible string for exynos4 fimd as "exynos4210-fimd" and
exynos5 fimd as "exynos5250-fimd" to stick to the rule that compatible
value should be named after first specific SoC model in which this
particular IP version was included as discussed at
https://patchwork.kernel.org/patch/214486
Hi Mr.Shim,
On 21 February 2013 12:35, Joonyoung Shim wrote:
> Hi,
>
>
> On 02/21/2013 02:11 PM, Vikas Sajjan wrote:
>>
>> Adds support for pinctrl to drm fimd.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c |9
On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH
> >
On Tue, Feb 26, 2013 at 06:11:31PM +, James Courtier-Dutton wrote:
> On 26 February 2013 17:35, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> >> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> >> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie
On 26 February 2013 17:35, Greg KH wrote:
> On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
>> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
>> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
>> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH
>> > > wrote:
>> > >
On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrote:
> > > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH
> > > wrote:
> > > > Hi Ben,
> > > >
> > > > My Macbook Pro Retina fa
Ping.
On 2013-02-18 16:09, Tomi Valkeinen wrote:
> Hi Steffen,
>
> On 2013-01-25 11:01, Steffen Trumtrar wrote:
>
>> +/* VESA display monitor timing parameters */
>> +#define VESA_DMT_HSYNC_LOW BIT(0)
>> +#define VESA_DMT_HSYNC_HIGH BIT(1)
>> +#define VESA_DMT_VSYNC_LOW
On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma wrote:
> Exynos5 is already using drm_display_mode for timings parameters. Exynos4
> is also modifed to use the same. List of supported resolutions and
> corresponding timings are removed which helps is enabling some extra
> resolutions. It also cleans
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #23 from Simone Scanzoni ---
Mesa 9.2-devel (git-4deefd9) showed the problem here with TF2, I don't have
CSS.
Added patches:
r600g: emit a ps partial flush after CP DMA
r600g: enable CP DMA on r6xx (v3)
and the problem persisted.
Th
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #28 from Alex Deucher ---
I'm trying to find out more internally.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freed
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #156 from Trey Ramsay ---
Thanks... We are using 2.6.32 kernel. We had problems with the 845G hanging
but I don't think we were using SNA acceleration at the time. What patches do
you think we need?
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #27 from Jerome Glisse ---
I don't know what this register does maybe Alex can shed some light
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel maili
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/431be177/attachment.html>
1 - 100 of 117 matches
Mail list logo
