On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WR
On Mon, Feb 18, 2013 at 07:28:04PM +0200, Imre Deak wrote:
> The existing gtt setup code is correct - and so doesn't need to be fixed to
> handle compact dma scatter lists similarly to the previous patches. Still,
> take the for_each_sg_page macro into use, to get somewhat simpler code.
>
> Signed
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > > void
> > > intel_i2c_reset(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
On Tue, Jan 29, 2013 at 09:10:40AM -0800, Aaron Plattner wrote:
> On 01/28/2013 05:38 AM, Rahul Sharma wrote:
> >It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
> >sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
> >creating SG table for the buf
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #15 from Michel Dänzer ---
Can you please fix this somehow for now? This is preventing radeonsi from
working at all.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #8 from Jan Papež (honyczek) ---
The issue still remains.
openSUSE 12.3
kernel-desktop 3.7.10-1.1.1
xorg-x11-server 7.6_1.13.2-1.2.1
xf86-video-ati 7.0.0-2.1.1
libdrm2 2.4.42-1.1.1
libdrm_radeon1 2.4.42-1.1.1
Mesa
Hey,
Op 19-03-13 11:27, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:02:14AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 19-03-13 10:21, Chris Wilson schreef:
>>> On Mon, Mar 18, 2013 at 01:51:44PM -0700, Bryce Harrington wrote:
Update: Squashes a couple commits to avoid potential
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #16 from Andreas Boll ---
(In reply to comment #15)
> Can you please fix this somehow for now? This is preventing radeonsi from
> working at all.
I've sent the proposed patch from comment #5 to the list:
http://lists.freedesktop.org
>
> Because of the delayed fput in recent kernels, it is possible for plymouth to
> exit and not drop master right away.
> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
> the meantime, opens a fd, but because the fd
> hasn't been closed by plymouth yet, it didn't get
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #8 from Jürg Billeter ---
I don't have a usable backtrace at hand, but I'm seeing very similar crashes in
gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I haven't
noticed any crashes so far. It crashes much more f
https://bugs.freedesktop.org/show_bug.cgi?id=62434
--- Comment #17 from Michel Dänzer ---
(In reply to comment #12)
> Reverting the gallium fix would reopen bug #59238
FWIW, that seems less of an issue to me than this bug or the side effects of
the attached patch.
--
You are receiving this mai
Op 19-03-13 12:10, Dave Airlie schreef:
>> Because of the delayed fput in recent kernels, it is possible for plymouth
>> to exit and not drop master right away.
>> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
>> the meantime, opens a fd, but because the fd
>> hasn't
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
Signed-of
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
On 2013-03-18 22:46, Rob Clark wrote:
> On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen wrote:
>> Hi Dave,
>>
>> I'm writing this mail to get some ideas how we should manage OMAP's
>> display drivers in the future.
>>
>> As a short intro, we have the following players around:
>>
>> omapdss - omapd
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #9 from Alex Deucher ---
Does booting with radeon.disp_priority=2 on the kernel command line in grub
help? For systems where this is a regression, can you bisect?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #9 from Alex Deucher ---
(In reply to comment #8)
> I don't have a usable backtrace at hand, but I'm seeing very similar crashes
> in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I
> haven't noticed any crashes
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #10 from Jürg Billeter ---
(In reply to comment #9)
> (In reply to comment #8)
> > I don't have a usable backtrace at hand, but I'm seeing very similar crashes
> > in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3,
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #10 from Jan Papež (honyczek) ---
> Does booting with radeon.disp_priority=2 on the kernel command line in grub
> help?
No.
> For systems where this is a regression, can you bisect?
I don't understand. Could you explain this quest
https://bugs.freedesktop.org/show_bug.cgi?id=7034
--- Comment #2 from Alexander Skwar ---
A "bit" hard to say, after 7 years…
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesk
https://bugs.freedesktop.org/show_bug.cgi?id=7034
--- Comment #3 from chemtech ---
Can close the bug?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.fre
https://bugs.freedesktop.org/show_bug.cgi?id=7034
Alexander Skwar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=7034
Alexander Skwar changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #11 from Alex Deucher ---
(In reply to comment #10)
> > For systems where this is a regression, can you bisect?
>
> I don't understand. Could you explain this question please (if it was to me)?
If it worked with an older kernel, you
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #12 from Jan Papež (honyczek) ---
Additional specific info:
I'm using extended desktop on two DVI connected monitors (the card has one
connector and you have to use Y cable to connect something). Even if I switch
to cloned desktop, it
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #13 from Alex Deucher ---
(In reply to comment #12)
> Interesting: If I connect only one monitor (either on cable 1 or 2), it
> works well.
The blinking is caused by data underflow to the display controllers. All
clients on the GPU
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #14 from Jan Papež (honyczek) ---
(In reply to comment #13)
> 2. Disable acceleration (Option "NoAccel" "True" in the device section of
> your xorg.conf)
> 3. Disable Tiling (Option "ColorTiling" "False" in the device section of you
Hello,
Here's the fourth version of my modetest enhancements patch set.
The third version only contained patches 01/21 to 04/21. I then felt the need
for a test tool that allows testing more driver features and ended up extending
modetest accordingly.
Beside various cleanups, these patches allow
Enable all standard automake warnings except for -Wpointer-arith (as the
test pattern generation code uses void pointer arithmetics) and fix
them.
Signed-off-by: Laurent Pinchart
---
tests/modetest/Makefile.am | 4 +++-
tests/modetest/buffers.c | 13 +++--
tests/modetest/buffers.h |
Those variables are declared in unistd.h, there's no need to redeclare
them here.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1081c78..92c7
The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 49 ++-
1 file chang
If the -M parameter is specified, modetest will use the requested device
name instead of trying its builtin list of device names.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jani Nikula
---
tests/modetest/modetest.c | 41 -
1 file changed, 28 insertions(
If the -d parameter is specified, modetest will drop master permissions
after setting the mode.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 91
Configuring mode on more than two connectors or two planes is perfectly
valid. Support it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
Instead of retrieving resources as they are needed, retrieve them all
(except property blobs) in one go at startup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 406 +-
1 file changed, 259 insertions(+), 147 deletions(-)
diff --git
The -w parameter can be used to set a property value from the command
line, using the target object ID and the property name.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 108 +-
1 file changed, 106 insertions(+), 2 deletions(-)
dif
As modetest automatically selects an unused plan, providing the plane ID
allows modifying plane properties for the selected planes.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c
The argument isn't used, remove it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ffdb0aa..d6eed4a 100644
--- a/tests/modetest/modetest.c
+++
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 164e7e1..70fa262 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetes
Extend the -P option to allow specifying the plane x and y offsets. The
position is optional, if not specified the plane will be positioned at
the center of the screen as before.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 72 +--
1
Instead of passing the device fd and resources as global variables group
them in a device structure and pass it explictly to all functions that
need it.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 199 --
1 file changed, 102 inserti
The field is no needed, make it a local variable where used.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 70fa262..ba025d6 100644
--- a/test
This prepares the code for the split in separate functions of CRTC and
planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 58 ++-
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/tests/modetest/modetest.c b/tes
This prepares the code for the split in separate functions of CRTC and
planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 74e82ef..0
Planes are associated with CRTCs, not connectors. Don't try to be too
clever, use the CRTC ID in the -P option. This prepares for splitting
CRTC and planes setup.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 32 +---
1 file changed, 17 insertions(+)
There's not reason to require setting a mode to test planes. Split the
two operations.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 105 +++---
1 file changed, 72 insertions(+), 33 deletions(-)
diff --git a/tests/modetest/modetest.c b/t
This prepares the code for handling multiple connectors in a single
pipeline in a cloned configuration.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 164 --
1 file changed, 86 insertions(+), 78 deletions(-)
diff --git a/tests/modete
When building the pipeline, instead of using only the encoders attached
to a connector, take all possible encoders into account to locate a
CRTC.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions
The -s argument can now take a list of connectors. Configure all of them
in cloned mode using a single CRTC.
Signed-off-by: Laurent Pinchart
---
tests/modetest/modetest.c | 211 ++
1 file changed, 157 insertions(+), 54 deletions(-)
diff --git a/tests/
On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson wrote:
>> > How about just using:
>> > if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
>> > and the existing wait loop?
>>
>> I explicitly wanted to avoid touching GMBUS4 register, as the real cause
>> of the failure is not clear.
>>
>> But, a
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> For reference below the updated commit message.
>
> Cheers, Daniel
>
> Author: Jiri Kosina
> Date: Tue Mar 19 09:56:57 2013 +0100
>
> drm/i915: stop using GMBUS IRQs on Gen4 chips
>
> Commit 28c70f162 ("drm/i915: use the gmbus irq for wai
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #11 from Michael Mair-Keimberger ---
I don't know if its the same but i can confirm similar crashes.
First of all, i have a triple head setup, 2 screens with 1920x1200 (left and
right) and one with 2560x1600 (middle). Those crashes h
https://bugs.freedesktop.org/show_bug.cgi?id=45641
--- Comment #15 from Alex Deucher ---
(In reply to comment #14)
> Is possible to add these options when using KMS? Modifying
> /etc/X11/xorg.conf.d/*.conf is enough?
yes.
--
You are receiving this mail because:
You are the assignee for the bug
On 15.03.2013 14:13, Thierry Reding wrote:
> Also you now create a lookup table (or bitfield actually) as we
> discussed but you still pass around a function to check the lookup table
> against. What I originally intended was to not pass a function around at
> all but directly use the lookup table/
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
>> drm/i915: stop using GMBUS IRQs on Gen4 chips
>>
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #12 from Alex Deucher ---
I think these are actually several bugs at play here.
1. CPU only has a 256 MB window into vram. If the window is full due to
fragmentation or other mapped buffers, we fail. Does disabling hyperz help?
se
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #13 from Michel Dänzer ---
Eugene and Knut, in the future please always include information about which
signal was generated, at least if it's not SIGSEGV (which is the most common).
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=61182
--- Comment #14 from Michael Mair-Keimberger ---
(In reply to comment #12)
> I think these are actually several bugs at play here.
>
> 1. CPU only has a 256 MB window into vram. If the window is full due to
> fragmentation or other mapped buffe
On Tue, 19 Mar 2013, Daniel Vetter wrote:
> > That might be misleading. It's possible that the erroneous IRQs _are_
> > being issued but you're simply not aware of them. If the kernel thinks
> > that no device is using IRQ 16 then it will leave that IRQ disabled.
>
> I guess I should have phras
On Tue, Mar 19, 2013 at 10:55 AM, Laurent Pinchart
wrote:
> Planes are associated with CRTCs, not connectors. Don't try to be too
> clever, use the CRTC ID in the -P option. This prepares for splitting
> CRTC and planes setup.
hmm, I was thinking that it would be nice to someday make modetest
cle
Does the Linux kernel have functions to convert images to palleted
images? I want to display a 4bit palleted cursor, not too sure how to
handle that in DRM. Some ideas I have:
* change DRM to handle palleted cursors
* convert 32bit images in drivers
* write library functions do convert
* requi
On Tue, Mar 19, 2013 at 03:15:14PM -0400, Christopher Harvey wrote:
> Does the Linux kernel have functions to convert images to palleted
> images? I want to display a 4bit palleted cursor, not too sure how to
> handle that in DRM. Some ideas I have:
>
> * change DRM to handle palleted cursors
>
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter wrote:
> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's
Added in detection/support for DMM devices when booting with device
tree.
Signed-off-by: Andy Gross
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/
On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote:
> The drmSetMaster call is needed, but the spinning is really just waiting for
> the workqueue to run.
>
> bryce's patch never worked, it just caused it to try drmsetinterfaceversion
> for a few seconds before timing out. That ca
https://bugs.freedesktop.org/show_bug.cgi?id=60503
Tom Stellard changed:
What|Removed |Added
Attachment #74520|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=60963
--- Comment #1 from Tom Stellard ---
Could you post a dump with RADEON_DEBUG=noopt,vp,fp
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
This function was moved to the pci subsystem where it fits better, as
this is much more of a generic pci task, than a drm specific one. All
references to the function (all in the radeon driver) are updated.
This is the second step in moving function drm_pcie_get_speed_cap_mask
from the drm subsyst
This patch series first implements a function called pcie_get_speed_cap_mask
in the PCI subsystem based off from drm_pcie_get_speed_cap_mask in drm. Then
it removes the latter and fixes all references to it. And ultimately, it
implements an architecture-specific version of the same function for p
Implementation of a architecture-specific pcibios_get_speed_cap_mask.
This implementation detects bus capabilities based on OF
ibm,pcie-link-speed-stats property.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/platforms/pseries/pci.c | 35 ++
1 files ch
Added function to gather the speed cap for a device and return a mask to
supported speeds. The function is divided into an interface and a weak
implementation so that architecture-specific functions can be called.
This is the first step in moving function drm_pcie_get_speed_cap_mask
from the drm s
On Wed, 2013-03-20 at 02:24 -0300, Lucas Kannebley Tavares wrote:
> Implementation of a architecture-specific pcibios_get_speed_cap_mask.
> This implementation detects bus capabilities based on OF
> ibm,pcie-link-speed-stats property.
The problem with your approach is that it's not a runtime detec
On 2013-03-19 08:45, Archit Taneja wrote:
> I was trying to come up with a macro which could add default ops to the
> omap_dss_driver. It isn't straight forward as I thought, because you
> need to choose either the default op, or the panel driver's op if it
> exists. For example, I can't create a
On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
the user X session is coming up:
BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [<0001>] 0x0
PGD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables ebtable_
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
>
> Another pesky BIOS which changes the display state behind our back on lid
> closing! Should be duct-tapped over with
>
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter
> Date: Fri Nov 23 18:16:34 2012 +
[ adding Ben Skeggs and Dave Airlie ]
On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > Dropping Tegra ML, it's not the place where Nouveau mails should go.
> > Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouv
_
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130319/53b14d6c/attachment-0001.html>
_
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> 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/20130319/44176a3a/attachment.html>
> Just a bit of cleanup from me (resubmitted). The important patch comes
> from Julia. Julia's patch conflicts with the following:
> 1363594270-22137-1-git-send-email-airlied at gmail.com
>
Yeah I was going to leave the cleanups until -next opens, I'll push
the fix though and get it to stable.
Da
Hi Rob,
2013/3/19 Rob Clark :
> On Mon, Mar 18, 2013 at 9:32 PM, YoungJun Cho wrote:
>>
>> On Mar 19, 2013 9:55 AM, "Rob Clark" wrote:
>>>
>>> On Mon, Mar 18, 2013 at 8:00 PM, YoungJun Cho
>>> wrote:
>>> >
>>> > On Mar 19, 2013 3:01 AM, "Rob Clark" wrote:
>>> >>
>>> >> Btw, what is the hw res
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote:
> On 2013-03-12 16:38, Archit Taneja wrote:
>
>>> memcmp on two structs is often not a good idea. There could be padding
>>> bytes there, with uninitialized data. I'm not sure if that's the case
>>> here, though, but it could well change any
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WR
On Mon, Feb 18, 2013 at 07:28:04PM +0200, Imre Deak wrote:
> The existing gtt setup code is correct - and so doesn't need to be fixed to
> handle compact dma scatter lists similarly to the previous patches. Still,
> take the for_each_sg_page macro into use, to get somewhat simpler code.
>
> Signed
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
> On Mon, 18 Mar 2013, Chris Wilson wrote:
>
> > > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > > void
> > > intel_i2c_reset(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
On Tue, Jan 29, 2013 at 09:10:40AM -0800, Aaron Plattner wrote:
> On 01/28/2013 05:38 AM, Rahul Sharma wrote:
> >It fixes the issue arises due to passing 'nr_pages' in place of 'nents' to
> >sg_alloc_table. When ARM_HAS_SG_CHAIN is disabled, it is causing failure in
> >creating SG table for the buf
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/b6631296/attachment-0001.html>
9.0.2-34.3.1
I have ATI Radeon HD 2400 XT (RV610).
--
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/20130319/2bbc4
Hey,
Op 19-03-13 11:27, Chris Wilson schreef:
> On Tue, Mar 19, 2013 at 11:02:14AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 19-03-13 10:21, Chris Wilson schreef:
>>> On Mon, Mar 18, 2013 at 01:51:44PM -0700, Bryce Harrington wrote:
Update: Squashes a couple commits to avoid potential
list:
http://lists.freedesktop.org/archives/mesa-dev/2013-March/036423.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/20130319/6f762dca/attachment.html>
>
> Because of the delayed fput in recent kernels, it is possible for plymouth to
> exit and not drop master right away.
> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
> the meantime, opens a fd, but because the fd
> hasn't been closed by plymouth yet, it didn't get
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/6b4d6d85/attachment.html>
his 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/20130319/d0af2d69/attachment.html>
Op 19-03-13 12:10, Dave Airlie schreef:
>> Because of the delayed fput in recent kernels, it is possible for plymouth
>> to exit and not drop master right away.
>> It's put onto a workqueue to be freed slightly later. Xorg-server starts in
>> the meantime, opens a fd, but because the fd
>> hasn't
While migrating to common clock framework (CCF), found that the FIMD clocks
were pulled down by the CCF.
If CCF finds any clock(s) which has NOT been claimed by any of the
drivers, then such clock(s) are PULLed low by CCF.
By calling clk_prepare_enable() for FIMD clocks fixes the issue.
Signed-of
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
7;m hoping that CDF in some form would realize soon, and then copying
omapdss would be at least somewhwat easier, as there's no need to drag
the panel drivers along.
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/20130319/589289af/attachment.pgp>
On 19 March 2013 15:29, Vikas Sajjan wrote:
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prep
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130319/92125db4/attachment.html>
1 - 100 of 154 matches
Mail list logo
