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 ac
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 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
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
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
[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
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
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
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 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
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
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
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
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
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
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
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
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/fabf66d2/attachment.html>
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
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
able to differentiate between the two because it
knows what timeout it did pass to the ioctl.
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/20130611/fad4326c/attachment.pgp>
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
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
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(
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
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
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 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
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
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
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
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
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
[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
t available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/0870508c/attachment-0001.pgp>
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.
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
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 modin
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
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/83aacaeb/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/72cfdb75/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=64913
Krzysztof A. Sobiecki changed:
What|Removed |Added
Attachment #80588|0 |1
is obsolete|
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/f0ca953a/attachment.html>
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
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 io
is 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/20130611/acd79b18/attachment-0001.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/20130611/e1d0a1f3/attachment.html>
commits from comment 42.
The diff is really short ...
--
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/20130611/641c2
||
--
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/20130611/ec9c1077/attachment.html>
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
-
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>
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
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
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
'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
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(-)
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
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
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
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
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
2ae49f9
mesa is at
commit ff256ec0686bad0ccf3c9df99ba442773efbc181
--
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/2013061
org/archives/dri-devel/attachments/20130611/40ee7013/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>
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>
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
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
[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
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 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 d
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
>
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 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 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
>>
>> 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 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 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
>
> 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
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]
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 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
vel/attachments/20130611/14a382ed/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/cefd0abd/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130611/3765cbe1/attachment.html>
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>
>
> 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.
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 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
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
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
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 #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
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
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 #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
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
1 - 100 of 143 matches
Mail list logo
