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:
>>> > >
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/873835b8/attachment.html>
ttp://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/attachments/20130227/57
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>
-
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
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
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
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
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
>
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
ing 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>
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>
.
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/attachment-0
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
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
---
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
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
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:
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
:
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>
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>
t;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
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
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/7eb9dc8a/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130227/709dc855/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/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
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
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
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
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/5455f5dd/attachment.html>
ding
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>
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/d7579843/attachment.html>
s
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>
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
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
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
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
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.
>
>
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
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/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
https://bugzilla.kernel.org/show_bug.cgi?id=14945
??? ? changed:
What|Removed |Added
CC||rootlexx at mail.ru
--- Comment #8
are 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:
d 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>
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
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
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>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/714a6539/attachment.html>
cified above.
> + }
> +
> return MODE_OK;
> }
>
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/86c1ba0f/attachment.pgp>
n-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/b83934e0/attachment.pgp>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/44dddca6/attachment.pgp>
-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130227/a11a6265/attachment.pgp>
kernel. The kernel w/a is
being backported by Julien Cristau for the debian kernel.
--
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
On Tue, Feb 26, 2013 at 11:48:18AM +0200, Terje Bergström wrote:
On 25.02.2013 17:24, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:43:59PM +0200, Terje Bergstrom wrote:
[...]
+/*
+ * Start timer for a buffer submition that has completed yet.
submission. And I don't understand the
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 wrote:
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie wrote:
Highlights:
i915: all over the map, haswell power well enhancements, valleyview macro
horrors cleaned up, killing lots of legacy GTT
code,
Lowlight:
https://bugs.freedesktop.org/show_bug.cgi?id=61532
Jani Nikula jani.nik...@intel.com changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop
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
https://bugzilla.kernel.org/show_bug.cgi?id=14945
Алексей Шилин rootl...@mail.ru changed:
What|Removed |Added
CC||rootl...@mail.ru
---
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #9 from Алексей Шилин rootl...@mail.ru 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
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #10 from Алексей Шилин rootl...@mail.ru 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://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #31 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #30)
What do you mean by fixed, this bug or the one you linked?
Because I still get the same corruptions in Trine 2 and some textures in
CS:S with the
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #25 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Created attachment 75640
-- https://bugs.freedesktop.org/attachment.cgi?id=75640action=edit
Adding tests for all-1s after every read or write
Ok, so after applying the
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #26 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Btw, the calling path here seems to be
evergreen_init - atom_asic_init - (ASIC_Init) - (SetMemoryClock) -
(MemoryPLLInit)
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #27 from Jerome Glisse gli...@freedesktop.org ---
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.
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #156 from Trey Ramsay tram...@linux.vnet.ibm.com ---
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?
--
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #28 from Alex Deucher ag...@yahoo.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #23 from Simone Scanzoni nonno.cic...@tiscali.it ---
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
On Fri, Feb 22, 2013 at 8:32 AM, Rahul Sharma rahul.sha...@samsung.com 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
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 BIT(2)
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 gre...@linuxfoundation.org
wrote:
Hi Ben,
My Macbook Pro
On 26 February 2013 17:35, Greg KH gre...@linuxfoundation.org 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 gre...@linuxfoundation.org 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
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
Hi Mr.Shim,
On 21 February 2013 12:35, Joonyoung Shim jy0922.s...@samsung.com 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 l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
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/2144861/
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 jy0922.s...@samsung.com
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 l.kris...@samsung.com
Signed-off-by:
Adds support for pinctrl to drm fimd
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |9 +
1 file changed, 9 insertions(+)
diff --git
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
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_DMT_HSYNC_LOW
https://bugs.freedesktop.org/show_bug.cgi?id=58042
--- Comment #24 from Andreas Boll andreas.boll@gmail.com ---
(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:
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #7 from Philippe Leblanc philipp...@live.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #29 from Alex Deucher ag...@yahoo.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=44852
--- Comment #8 from Alex Deucher ag...@yahoo.com ---
(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
https://bugzilla.kernel.org/show_bug.cgi?id=14945
--- Comment #11 from Alex Deucher alexdeuc...@gmail.com 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
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #30 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=59982
--- Comment #31 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=50135
--- Comment #9 from Simone Scanzoni nonno.cic...@tiscali.it ---
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
1 - 100 of 115 matches
Mail list logo
