On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> CC [M] drivers/gpu/drm/i915/i915_gem.o
> /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> ‘i915_gem_object_bind_to_gtt’:
> /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c:3000:3: warning:
> format ‘%ld’ expects argu
On Fri, May 31, 2013 at 2:17 PM, wrote:
> From: Ville Syrjälä
>
> Keeping the modes in the same order as we probe them makes it a bit
> easier to track what's happening.
>
> Signed-off-by: Ville Syrjälä
I've just added a regression fixer to my -fixes queue which depends
upon the old behaviour
On Mon, Jun 10, 2013 at 11:23:42PM +0200, Sebastian Hesselbarth wrote:
> Current DRM slave encoder API conflicts with auto-registration of i2c client
> when using DT probed clients. To allow DRM slave encoders passed by DT, this
> patch adds a check to drm_i2c_encoder_init for a non-NULL .of_node o
On Mon, Jun 10, 2013 at 11:32:54PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > > wrote:
> > >> On Mon, Jun 10, 2013
On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrjälä wrote:
> On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> > ‘i915_gem_object_bind_to_gtt’:
> > /ssd/git/drm-next/dri
On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrjälä wrote:
> On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> > ‘i915_gem_object_bind_to_gtt’:
> > /ssd/git/drm-next/dri
On Tue, Jun 11, 2013 at 09:15:29AM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 2:17 PM, wrote:
> > From: Ville Syrjälä
> >
> > Keeping the modes in the same order as we probe them makes it a bit
> > easier to track what's happening.
> >
> > Signed-off-by: Ville Syrjälä
>
> I've just
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #36 from Marc Dietrich ---
I attached the output of firefox
http://www.gooengine.com/demofiles/pearl-boy/index.html with R600_LLVM=0/1
(large!). I'll try with an older llvm/mesa combo later.
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #37 from Marc Dietrich ---
Created attachment 80665
--> https://bugs.freedesktop.org/attachment.cgi?id=80665&action=edit
R600_LLVM=0
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #38 from Marc Dietrich ---
Created attachment 80666
--> https://bugs.freedesktop.org/attachment.cgi?id=80666&action=edit
R600_LLVM=1
--
You are receiving this mail because:
You are the assignee for the bug.
___
Hi Dave,
Just tiny regression fixes here:
- Two fixes to fix sdvo hotplug which broke in the hpd storm detection
work.
- One fix to patch-up the sdvo lvds regression fixer from the last pull -
we need to prefer the vbt mode over edid modes.
IMPORTANT:
The sdvo lvds fix in this -fixes pull
c
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #39 from Marc Dietrich ---
maybe unrelated, but R600_DEBUG=sb crashes firefox
Program received signal SIGSEGV, Segmentation fault.
0x7fffb5586c2e in r600_sb::bc_parser::prepare_alu_group(r600_sb::cf_node*,
r600_sb::alu_group_node
On Tue, Jun 11, 2013 at 08:48:48AM +0100, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 09:15:29AM +0200, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 2:17 PM, wrote:
> > > From: Ville Syrjälä
> > >
> > > Keeping the modes in the same order as we probe them makes it a bit
> > > easier to tra
On Tue, Jun 11, 2013 at 08:39:16AM +0100, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #40 from Andy Furniss ---
Created attachment 80679
--> https://bugs.freedesktop.org/attachment.cgi?id=80679&action=edit
rv770 dump of heaven current heads broken (compressed)
--
You are receiving this mail because:
You are the ass
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #41 from Andy Furniss ---
Created attachment 80680
--> https://bugs.freedesktop.org/attachment.cgi?id=80680&action=edit
rv 790 current heads working with R600_LLVM=0 (compressed)
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=64257
Andy Furniss changed:
What|Removed |Added
Attachment #80679|rv770 dump of heaven|rv790 dump of heaven
description|c
On Tue, May 28, 2013 at 01:12:12PM -0600, Keith Packard wrote:
> Thierry Reding writes:
>
>
> > That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking
> > at the history, drmIoctl() was introduced to automatically loop if a
> > signal was received (commit 8b9ab108ec1f2ba2b503f7
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #42 from Andy Furniss ---
Created attachment 80682
--> https://bugs.freedesktop.org/attachment.cgi?id=80682&action=edit
rv790 dump of heaven working with older llvm/mesa
llvm is at
commit 9a9e936650bb82244f38dbddf6c4e427c2ae49f9
On Tue, Jun 11, 2013 at 12:48 PM, Thierry Reding
wrote:
> On Tue, May 28, 2013 at 01:12:12PM -0600, Keith Packard wrote:
>> Thierry Reding writes:
>>
>>
>> > That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking
>> > at the history, drmIoctl() was introduced to automatically lo
On 11.06.2013 14:00, Daniel Vetter wrote:
> We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
> which blew up the gpu (that one has been submitted already in a
> different ioctl call), but to be able to restart the ioctl after the
> reset has completed: We need to kick every thre
On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström wrote:
> On 11.06.2013 14:00, Daniel Vetter wrote:
>> We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
>> which blew up the gpu (that one has been submitted already in a
>> different ioctl call), but to be able to restart the ioc
Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
internally".
nvidia always seems to do this flush after writing values.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c
b/drivers/gpu/drm/nouveau/core/subdev/vm/nv50.c
index 8
From: Sean Paul
Change the clk_enable/clk_disable calls in mixer and hdmi drivers into
clk_prepare_enable/clk_disable_unprepare, respectively.
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 24
drivers/gpu/drm/exynos
After switching to CCF, driver and device tree nodes are required
to be update with clock information. This set includes those changes.
After these patches, the only missing portion is hdmiphy power control
which is posted independently. Together, basic hdmi is working for
exynos5250.
Rahul Sharm
HDMI driver needs to configure the mout_hdmi mux clock to change
the parent between sclk_hdmiphy and sclk_pixel.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exyno
From: Sean Paul
This patch adds the mixer clocks to the mixer node in the dts file.
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos
Fix wrong clock numbers in hdmi dt node. Removed hdmiphy
clock which was a dummy clock earlier and not required now.
Also added mux clock to change the clock parent.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250.dtsi |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Previously, hdmiphy is added as a dummy clock in clock file for
exynos SoCs. Enable/Disable to this clock, actually toggles the power
control bit in PMU, instead of controlling the clock gate.
This RFC adds the support to parse hdmiphy control node which is a child
node to hdmi, and map the pmu re
Previous to CCF, hdmiphy is added as a dummy clock in clock file for
exynos SoCs. Enable/Disable to this clock, actually toggles the power
control bit in PMU, instead of controlling the clock gate.
Patch adds the support to parse hdmiphy control node which is a child
node to hdmi, and map the pmu
Add hdmiphy power control node as a child to hdmi node. This
node will be parsed by hdmi driver to map phy control pmu reg and
control the phy power.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/e
'break' after goto statement is redundant. Silences the following
message:
drivers/gpu/drm/exynos/exynos_drm_ipp.c:1067 exynos_drm_ipp_check_valid()
info: ignoring unreachable code.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 -
1 file changed, 1 deletion(-)
d
On 06/11/13 09:24, Daniel Vetter wrote:
On Mon, Jun 10, 2013 at 11:23:42PM +0200, Sebastian Hesselbarth wrote:
Current DRM slave encoder API conflicts with auto-registration of i2c client
when using DT probed clients. To allow DRM slave encoders passed by DT, this
patch adds a check to drm_i2c_e
[Petter Reinholdtsen 2013-06-03]
> According to modinfo i915, I should report machines/video cards
> needing the invert_brightness=1 setting here. The laptop in question
> is described on http://www.linlap.com/packard_bell_easynote_lv >.
> The screen go black as soon as the i915 kernel module is l
https://bugs.freedesktop.org/show_bug.cgi?id=64913
Krzysztof A. Sobiecki changed:
What|Removed |Added
Attachment #80588|0 |1
is patch|
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #43 from Marc Dietrich ---
the commit mentioned in comment 42 almost fixes the misrendering, but not
completely. R600_DEBUG=sbdisasm crashes, so I cannot provide the output with
it.
Anyway, attaching output with current mesa/llvm and
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #44 from Marc Dietrich ---
Created attachment 80690
--> https://bugs.freedesktop.org/attachment.cgi?id=80690&action=edit
output with commit from comment 42
this one shows much less misrendered triangles (no not zero)
--
You are r
Hi Petter,
Can you please make this into a real kernel patch with commit message,
sob line and all? See Documentation/SubmittingPatches. Diff itself
looks good.
Thanks, Daniel
On Tue, Jun 11, 2013 at 10:28 AM, Petter Reinholdtsen wrote:
> [Petter Reinholdtsen 2013-06-03]
>> According to modinf
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #45 from Marc Dietrich ---
Created attachment 80691
--> https://bugs.freedesktop.org/attachment.cgi?id=80691&action=edit
output with current mesa
lots of misrendered triangles all across the screen
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #46 from Tom Stellard ---
(In reply to comment #43)
> the commit mentioned in comment 42 almost fixes the misrendering, but not
> completely. R600_DEBUG=sbdisasm crashes, so I cannot provide the output with
> it.
> Anyway, attaching o
On Mon, Jun 10, 2013 at 12:27 AM, Chris Wilson wrote:
> It is these machines that require the per-connector quirk to turn off
> hotplug detection anyway. And there are users that need to turn off all
> hotplug detection (hardware and polling) on certain connectors whilst
> plugged into their kvm.
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #47 from Tom Stellard ---
Created attachment 80701
--> https://bugs.freedesktop.org/attachment.cgi?id=80701&action=edit
Work Around
It looks like the stack size calculations are wrong in some cases, does this
patch help?
--
You a
https://bugs.freedesktop.org/show_bug.cgi?id=64257
--- Comment #48 from Marc Dietrich ---
seems to be fixed in master now, but using the commits in comment 42 it crashes
like this.
Program received signal SIGSEGV, Segmentation fault.
0x7fffb4481f44 in r600_sb::bc_decoder::decode_alu(unsigne
Hi,
Sebastian Hesselbarth writes:
>> - I think we could also drop the call to ->set_config since presumably an
>>of-enabled driver grabbed any required info already from the dt.
>[...]
>> I think this way we could still share encoder slaves across tons of
>> platforms, only the init sequence
On Tue, Jun 11, 2013 at 02:09:31PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström
> wrote:
> > On 11.06.2013 14:00, Daniel Vetter wrote:
> >> We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
> >> which blew up the gpu (that one has been submitte
https://bugs.freedesktop.org/show_bug.cgi?id=64913
Krzysztof A. Sobiecki changed:
What|Removed |Added
Attachment #80588|0 |1
is obsolete|
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
wrote:
> Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
> internally".
> nvidia always seems to do this flush after writing values.
Thanks, patch applied.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drive
Applied.
Thanks,
Inki Dae
2013/6/10 Rahul Sharma
> This patch renames check_timing to check_mode and removes the
> unnecessary conversion of drm_display_mode to/from fb_videomode in
> the hdmi driver.
>
> v4:
> 1) Changed the commit message to add information related to renaming
> the callback
Hi Rahul,
This patch is important to us. Actually, previous hdmi driver had
controlled hdmiphy HDMI_PHY_CONTROL as if that were a clock but now that
doesn't exist anymore. So we need to discuss how hdmiphy should be handled.
I konw that you had already posted hdmiphy relevant patch set, [PATCH 0/4
2013/6/12 Inki Dae
> Hi Rahul,
>
> This patch is important to us. Actually, previous hdmi driver had
> controlled hdmiphy HDMI_PHY_CONTROL as if that were a clock but now that
> doesn't exist anymore. So we need to discuss how hdmiphy should be handled.
> I konw that you had already posted hdmiph
Add support for exynos5420 hdmiphy which is mapped to the platform
bus. hdmi dt node has a property with name "phy" which holds the
phandle for hdmiphy node. hdmi driver uses this phandle to check
the compatible type of the phy. If it is compatible with exynos5420,
it needs to be treated as a platf
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +
drivers/gpu/drm/exynos/regs-mixer.h |7 +
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/driver
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.
Signed-off-by: Rahul Sharma
---
drivers/gpu
On Sun, Jun 09, 2013 at 07:01:36PM -0400, Matthew Garrett wrote:
> Windows 8 introduced new policy for backlight control by pushing it out to
> graphics drivers. This appears to have coincided with a range of vendors
> adding Windows 8 checks to their backlight control code which trigger either
> a
Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 and Changes the drivers as per IP modifications.
This set is based on drm-next branch of Inki Dae's tree at
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git.
Rahul Sharma (9):
drm/exynos: use
Exynos hdmi IP version is named after hdmi specification version i.e.
1.3 and 1.4. This versioning mechanism is not sufficient to handle
the diversity in the hdmi/phy IPs which are present across the exynos
SoC family.
This patch changes the hdmi version to the name of the SoC in which
the IP was
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
Add support for exynos5420 hdmi IP.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a7f7ab3..0c94e54 100644
--- a/drivers/gpu/drm/exy
Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata
which is not used anywhere. Swtiching to of_get_named_gpio instead
of of_get_named_gpio_flags solved this.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(
Add property to hdmi node to get phandle for hdmiphy node. This
is required to check the compatible type of phy in hdmi driver.
If phy is compatible to exynos5420, it needs to be treated as a
platform device rather than a i2c device.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250-s
Update device tree binding documentation for hdmi subsystem with the
clock information, phy property information and compatible strings for
exynos5420.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/video/exynos_hdmi.txt | 19 +++
.../devicetree/bindings/video/ex
[Daniel Vetter]
> Hi Petter,
>
> Can you please make this into a real kernel patch with commit
> message, sob line and all? See Documentation/SubmittingPatches. Diff
> itself looks good.
Sure. This is my first try, so I hope I got it right.
Set i915.invert_brightness=1 on Packard Bell EasyNote
On 06/11/2013 05:10 PM, Francisco Jerez wrote:
Sebastian Hesselbarth writes:
- I think we could also drop the call to ->set_config since presumably an
of-enabled driver grabbed any required info already from the dt.
[...]
I think this way we could still share encoder slaves across tons of
On Tue, 11 Jun 2013 19:41:31 +0530, Rahul Sharma
wrote:
> Update device tree binding documentation for hdmi subsystem with the
> clock information, phy property information and compatible strings for
> exynos5420.
>
> Signed-off-by: Rahul Sharma
Binding looks reasonable to me. I'll leave it to
If the device is idle for over ten seconds, then the next attempt to do
anything can race with the lockup detector and cause a bogus lockup
to be detected.
Oddly, the situation is well-described in the lockup detector's comments
and a fix is even described. This patch implements that fix (and cor
https://bugs.freedesktop.org/show_bug.cgi?id=24066
--- Comment #11 from Agra ---
Hello,
I am experiencing the same "wireframe" issue on the steam version. Happens in
character creation. Clicking anything lets me know that "display driver" is not
responding and craches. Win7x64, ATI 4850x2
Agra
On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
>> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
>>> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
>>> wrote:
>>> > This patch adds support for the pair of LCD contr
>
> Here's a small pull request for v3.11 that contains the GEM CMA DMA-BUF
> support patches. The content is identical to "[PATCH v3 0/5] GEM CMA DMA-BUF
> support" with acks picked up from the list.
Pulled, thanks,
Dave.
CC [M] drivers/gpu/drm/i915/i915_gem.o
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
?i915_gem_object_bind_to_gtt?:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c:3000:3: warning:
format ?%ld? expects argument of type ?long int?, but argument 5 has
type ?size_t? [-Wformat]
>
> Here is the first run at inspection of the VIA openchrome dri
> driver. Now that the Xorg driver has been out over a year with KMS support
> most people should be able to use this feature. The driver is totaly
Just FYI this is a really bad idea, don't go releasing userspace code that u
>>
>> That makes the driver just be a dumb scanout only driver. Sorry,
>> that *really* does not interest me one bit, because the CPU doing
>> framebuffer accesses is pig slow.
>
> Well, yes that is basically what I am saying, unless we can find a
> different way (dmabuf? if there is some way to p
On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
wrote:
> On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
>> I'd like to see all the ARM based drivers based on CMA if it can meet
>> their requirements
>> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/030afad5/attachment.html>
On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
I
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is b
This fixes the wrong sync generation and sync calculation for progressive
and interlaced modes. Sync timings for a bunch of modes have also been verified
with an oscilloscope near-end (TDA998x input) and far-end (DVI receiver output).
Signed-off-by: Sebastian Hesselbarth
---
Note: This patch is b
On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> >> ioctls as a small patch on top
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
> >> their requirements
> >>
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
These chipsets include the VP2 engine which is composed of a bitstream
On 10.06.2013 23:43, Thierry Reding wrote:
> Can you post the corresponding wrappers to make it easier to discuss
> them? If they just wrap runtime PM calls then they don't solve the
> locality problems that Terje brought up.
I don't think the wrappers are applicable here. They're there in
downstr
On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> CC [M] drivers/gpu/drm/i915/i915_gem.o
> /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> ?i915_gem_object_bind_to_gtt?:
> /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c:3000:3: warning:
> format ?%ld? expects argu
On Fri, May 31, 2013 at 2:17 PM, wrote:
> From: Ville Syrj?l?
>
> Keeping the modes in the same order as we probe them makes it a bit
> easier to track what's happening.
>
> Signed-off-by: Ville Syrj?l?
I've just added a regression fixer to my -fixes queue which depends
upon the old behaviour
On Mon, Jun 10, 2013 at 11:23:42PM +0200, Sebastian Hesselbarth wrote:
> Current DRM slave encoder API conflicts with auto-registration of i2c client
> when using DT probed clients. To allow DRM slave encoders passed by DT, this
> patch adds a check to drm_i2c_encoder_init for a non-NULL .of_node o
On Mon, Jun 10, 2013 at 11:32:54PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> > On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > > wrote:
> > >> On Mon, Jun 10, 2013
On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrj?l? wrote:
> On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> > ?i915_gem_object_bind_to_gtt?:
> > /ssd/git/drm-next/dri
On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrj?l? wrote:
> On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In function
> > ?i915_gem_object_bind_to_gtt?:
> > /ssd/git/drm-next/dri
On Tue, Jun 11, 2013 at 09:15:29AM +0200, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 2:17 PM, wrote:
> > From: Ville Syrj?l?
> >
> > Keeping the modes in the same order as we probe them makes it a bit
> > easier to track what's happening.
> >
> > Signed-off-by: Ville Syrj?l?
>
> I've just
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>> On Sun, Jun 9, 2013 at 3:29 PM, Russell
cause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/2ebc841a/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/3765cbe1/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/cefd0abd/attachment.html>
Hi Dave,
Just tiny regression fixes here:
- Two fixes to fix sdvo hotplug which broke in the hpd storm detection
work.
- One fix to patch-up the sdvo lvds regression fixer from the last pull -
we need to prefer the vbt mode over edid modes.
IMPORTANT:
The sdvo lvds fix in this -fixes pull
c
vel/attachments/20130611/14a382ed/attachment.html>
On Tue, Jun 11, 2013 at 08:48:48AM +0100, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 09:15:29AM +0200, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 2:17 PM, wrote:
> > > From: Ville Syrj?l?
> > >
> > > Keeping the modes in the same order as we probe them makes it a bit
> > > easier to tra
On Tue, Jun 11, 2013 at 08:39:16AM +0100, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 10:03:06AM +0300, Ville Syrj?l? wrote:
> > On Tue, Jun 11, 2013 at 08:55:03AM +1000, Dave Airlie wrote:
> > > CC [M] drivers/gpu/drm/i915/i915_gem.o
> > > /ssd/git/drm-next/drivers/gpu/drm/i915/i915_gem.c: In
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/cd09caf7/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/20130611/aa0f24c6/attachment.html>
org/archives/dri-devel/attachments/20130611/40ee7013/attachment.html>
-
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/20130611/095b343d/attachment-0001.pgp>
1 - 100 of 143 matches
Mail list logo
