On Tue, Oct 22, 2013 at 10:28 PM, Inki Dae wrote:
> 2013/10/22 Sean Paul :
>> On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae wrote:
>>>
>>>
-Original Message-
From: Sean Paul [mailto:seanpaul at chromium.org]
Sent: Tuesday, October 22, 2013 6:18 AM
To: Inki Dae
Cc: dri
t? :) It seems that you are outside real point.
> >> >>
> >> >> > Take a look at exynos_drm_encoder.c in my tree
> >> >> >
> >> >> >
> >> >> > (
> https://github.com/crseanpaul/exynos-drm-next/blob/linux-next-exynos-staging/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> ),
> >> >> > what does it do that's useful to abstract? All that it does is just
> >> >> > call display ops, it's completely useless. The same is true for
> >> >> > exynos_drm_connector, it's just dead weight. There is some useful
> >> >> > stuff in exynos_drm_crtc for page flipping, that would be better
> >> >> > served as a helper library, though.
> >> >> >
> >> >> >> The abstraction layer you mentioned also means a common spot.
> >> >> >> Another one, you patch also makes each sub driver have strongly
> >> >> >> dependency
> >> >> >> of drm framework. So how we can support existing backlight and lcd
> >> >> >> class
> >> >> >> based lcd panel drivers if the connector is implemented in each
> >> >> >> device
> >> >> >> driver later? the drm header files should be included in
> >> >> >> drivers/video/backlight/xxx_lcd.c?
> >> >> >>
> >> >> >
> >> >> > drm_bridge or drm_panel seem like good candidates for this.
> >> >> >
> >> >>
> >> >> Yes, exynos_drm_display could be replaced with drm_panel later if the
> >> >> drm_panel can be merged to mainline.
> >> >>
> >> >> >
> >> >> >> And, I will introduce a new framework to support existing lcd
> panel
> >> >> >> drivers
> >> >> >> and display bus drivers soon; as of now for Exynos drm, and the
> >> >> >> framework is
> >> >> >> being tested internally. With this framework, encoder and
> connector
> >> >> >> will be
> >> >> >> created when lcd panel or display bus driver such as eDP is
> probed:
> >> >> >> it
> >> >> >> doesn?t really need to create encoder and connector in advance if
> >> >> >> lcd
> >> >> >> panel
> >> >> >> or display bus driver isn't probed yet. Regardless of crtc, and
> >> >> >> encoder
> >> >> >> and
> >> >> >> connector creation order, when last one is created, crtc and
> >> >> >> connector
> >> >> >> will
> >> >> >> be connected each other. And exynos_drm_display could be
> implemented
> >> >> >> in
> >> >> >> other frameworks if we have common structure for display device
> >> >> >> driver.
> >> >> >> And
> >> >> >> also the framework will support lvds driver according to Linux
> >> >> >> device
> >> >> >> driver
> >> >> >> model.
> >> >> >>
> >> >> >
> >> >> > I don't really follow what you're trying to do here, but I think we
> >> >> > should be moving in the direction of fewer abstractions in the
> exynos
> >> >> > driver, not more :)
> >> >> >
> >> >>
> >> >> Not abstraction layer, just a bridge for connecting crtc and its
> >> >> corresponding encoder/connector, and lvds regardless of creation
> >> >> order, and for connecting drm connector and other framework based
> >> >> display ops such as drm_panel later.
> >> >>
> >> >> > Sean
> >> >> >
> >> >> >
> >> >> >
> >> >> >> Thanks,
> >> >> >> Inki Dae
> >> >> >>
> >> >> >>> Sean
> >> >> >>>
> >> >> >>> >>>
> >> >> >>> >>> > And another one, the patch 6 passes manager object to
> >> >> >>> >>> > manager_ops,
> >> >> >>> and
> >> >> >>> >>> for
> >> >> >>> >>> > this, you made the manager object to be set to driver data;
> >> >> >>> >>> > platform_set_drvdata(pdev, &manager). That isn't
> reasonable.
> >> >> >>> Generally,
> >> >> >>> >>> > driver_data would point to device driver's context object.
> >> >> >>> >>> >
> >> >> >>> >>>
> >> >> >>> >>> I'm not sure why this isn't reasonable, but it's a moot
> point.
> >> >> >>> >>> The
> >> >> >>> >>> driver data is only used up until we get rid of the pm ops,
> it
> >> >> >>> >>> needn't
> >> >> >>> >>> be set at all once things go through dpms.
> >> >> >>> >>>
> >> >> >>> >>
> >> >> >>> >> Generally, device drivers can call its own internal functions,
> >> >> >>> >> and
> >> >> >>> >> they
> >> >> >>> will
> >> >> >>> >> call that functions with ctx. However, if you set manager to
> >> >> >>> driver_data
> >> >> >>> >> then that functions should be called with manager object and
> >> >> >>> >> also
> >> >> >>> internally
> >> >> >>> >> that functions should get ctx from the manager object. What is
> >> >> >>> >> the
> >> >> >>> purpose
> >> >> >>> >> of manager? Do you think it's reasonable?
> >> >> >>> >>
> >> >> >>> >
> >> >> >>> > So, to avoid setting the manager as the drvdata, we could
> >> >> >>> > implement
> >> >> >>> > something like fimd_dpms_ctx(ctx, mode) that takes ctx and the
> >> >> >>> > manager
> >> >> >>> > callback calls it fimd_dpms(mgr, mode) { ctx = mgr->ctx;
> >> >> >>> > fimd_dpms_ctx(ctx, mode); }. Alternatively, you can save a
> >> >> >>> > pointer
> >> >> >>> > to
> >> >> >>> > mgr in ctx, but that creates a circular link between the two.
> >> >> >>> > IMO,
> >> >> >>> > both of those solutions suck :)
> >> >> >>> >
> >> >> >>> > I'd much rather just set drvdata to the manager and call the
> hook
> >> >> >>> > directly. Like I said earlier, this is just a temporary step
> >> >> >>> > since
> >> >> >>> > we
> >> >> >>> > remove these pm ops later in the patch series.
> >> >> >>> >
> >> >> >>> > Sean
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >> Anyway, I'd like to say really sorry about inconvenient again.
> >> >> >>> >> So I
> >> >> >>> will fix
> >> >> >>> >> it.
> >> >> >>> >>
> >> >> >>> >> Thanks,
> >> >> >>> >> Inki Dae
> >> >> >>> >>
> >> >> >>> >>> Sean
> >> >> >>> >>>
> >> >> >>> >>>
> >> >> >>> >>> > Thanks,
> >> >> >>> >>> > Inki Dae
> >> >> >>> >>> >
> >> >> >>> >>
> >> >> >>
> >> >> > ___
> >> >> > 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
> >> >
> >
> >
> >
> > ___
> > 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/20131022/4c924e8e/attachment-0001.html>
On Tue, Oct 22, 2013 at 6:27 PM, Matt Roper
wrote:
> On Mon, Oct 14, 2013 at 01:26:46PM -0400, Rob Clark wrote:
>> Break the mutable state of a crtc out into a separate structure
>> and use atomic properties mechanism to set crtc attributes. This
>> makes it easier to have some helpers for crtc-
From: Marek Ol??k
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/cikd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 203d2a0..cad6e8a 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/dr
; driver later? the drm header files should be included in
> >> >> drivers/video/backlight/xxx_lcd.c?
> >> >>
> >> >
> >> > drm_bridge or drm_panel seem like good candidates for this.
> >> >
> >>
> >> Yes, exynos_drm_display could be replaced with drm_panel later if the
> >> drm_panel can be merged to mainline.
> >>
> >> >
> >> >> And, I will introduce a new framework to support existing lcd panel
> >> >> drivers
> >> >> and display bus drivers soon; as of now for Exynos drm, and the
> >> >> framework is
> >> >> being tested internally. With this framework, encoder and connector
> >> >> will be
> >> >> created when lcd panel or display bus driver such as eDP is probed:
> it
> >> >> doesn?t really need to create encoder and connector in advance if lcd
> >> >> panel
> >> >> or display bus driver isn't probed yet. Regardless of crtc, and
> encoder
> >> >> and
> >> >> connector creation order, when last one is created, crtc and
> connector
> >> >> will
> >> >> be connected each other. And exynos_drm_display could be implemented
> in
> >> >> other frameworks if we have common structure for display device
> driver.
> >> >> And
> >> >> also the framework will support lvds driver according to Linux device
> >> >> driver
> >> >> model.
> >> >>
> >> >
> >> > I don't really follow what you're trying to do here, but I think we
> >> > should be moving in the direction of fewer abstractions in the exynos
> >> > driver, not more :)
> >> >
> >>
> >> Not abstraction layer, just a bridge for connecting crtc and its
> >> corresponding encoder/connector, and lvds regardless of creation
> >> order, and for connecting drm connector and other framework based
> >> display ops such as drm_panel later.
> >>
> >> > Sean
> >> >
> >> >
> >> >
> >> >> Thanks,
> >> >> Inki Dae
> >> >>
> >> >>> Sean
> >> >>>
> >> >>> >>>
> >> >>> >>> > And another one, the patch 6 passes manager object to
> >> >>> >>> > manager_ops,
> >> >>> and
> >> >>> >>> for
> >> >>> >>> > this, you made the manager object to be set to driver data;
> >> >>> >>> > platform_set_drvdata(pdev, &manager). That isn't reasonable.
> >> >>> Generally,
> >> >>> >>> > driver_data would point to device driver's context object.
> >> >>> >>> >
> >> >>> >>>
> >> >>> >>> I'm not sure why this isn't reasonable, but it's a moot point.
> The
> >> >>> >>> driver data is only used up until we get rid of the pm ops, it
> >> >>> >>> needn't
> >> >>> >>> be set at all once things go through dpms.
> >> >>> >>>
> >> >>> >>
> >> >>> >> Generally, device drivers can call its own internal functions,
> and
> >> >>> >> they
> >> >>> will
> >> >>> >> call that functions with ctx. However, if you set manager to
> >> >>> driver_data
> >> >>> >> then that functions should be called with manager object and also
> >> >>> internally
> >> >>> >> that functions should get ctx from the manager object. What is
> the
> >> >>> purpose
> >> >>> >> of manager? Do you think it's reasonable?
> >> >>> >>
> >> >>> >
> >> >>> > So, to avoid setting the manager as the drvdata, we could
> implement
> >> >>> > something like fimd_dpms_ctx(ctx, mode) that takes ctx and the
> >> >>> > manager
> >> >>> > callback calls it fimd_dpms(mgr, mode) { ctx = mgr->ctx;
> >> >>> > fimd_dpms_ctx(ctx, mode); }. Alternatively, you can save a pointer
> >> >>> > to
> >> >>> > mgr in ctx, but that creates a circular link between the two. IMO,
> >> >>> > both of those solutions suck :)
> >> >>> >
> >> >>> > I'd much rather just set drvdata to the manager and call the hook
> >> >>> > directly. Like I said earlier, this is just a temporary step since
> >> >>> > we
> >> >>> > remove these pm ops later in the patch series.
> >> >>> >
> >> >>> > Sean
> >> >>> >
> >> >>> >
> >> >>> >> Anyway, I'd like to say really sorry about inconvenient again.
> So I
> >> >>> will fix
> >> >>> >> it.
> >> >>> >>
> >> >>> >> Thanks,
> >> >>> >> Inki Dae
> >> >>> >>
> >> >>> >>> Sean
> >> >>> >>>
> >> >>> >>>
> >> >>> >>> > Thanks,
> >> >>> >>> > Inki Dae
> >> >>> >>> >
> >> >>> >>
> >> >>
> >> > ___
> >> > 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/20131022/722b4c30/attachment-0001.html>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/46e9f425/attachment.html>
also the framework will support lvds driver according to Linux device
> driver
> >> model.
> >>
> >
> > I don't really follow what you're trying to do here, but I think we
> > should be moving in the direction of fewer abstractions in the exynos
> > driver, not more :)
> >
>
> Not abstraction layer, just a bridge for connecting crtc and its
> corresponding encoder/connector, and lvds regardless of creation
> order, and for connecting drm connector and other framework based
> display ops such as drm_panel later.
>
> > Sean
> >
> >
> >
> >> Thanks,
> >> Inki Dae
> >>
> >>> Sean
> >>>
> >>> >>>
> >>> >>> > And another one, the patch 6 passes manager object to
> manager_ops,
> >>> and
> >>> >>> for
> >>> >>> > this, you made the manager object to be set to driver data;
> >>> >>> > platform_set_drvdata(pdev, &manager). That isn't reasonable.
> >>> Generally,
> >>> >>> > driver_data would point to device driver's context object.
> >>> >>> >
> >>> >>>
> >>> >>> I'm not sure why this isn't reasonable, but it's a moot point. The
> >>> >>> driver data is only used up until we get rid of the pm ops, it
> needn't
> >>> >>> be set at all once things go through dpms.
> >>> >>>
> >>> >>
> >>> >> Generally, device drivers can call its own internal functions, and
> they
> >>> will
> >>> >> call that functions with ctx. However, if you set manager to
> >>> driver_data
> >>> >> then that functions should be called with manager object and also
> >>> internally
> >>> >> that functions should get ctx from the manager object. What is the
> >>> purpose
> >>> >> of manager? Do you think it's reasonable?
> >>> >>
> >>> >
> >>> > So, to avoid setting the manager as the drvdata, we could implement
> >>> > something like fimd_dpms_ctx(ctx, mode) that takes ctx and the
> manager
> >>> > callback calls it fimd_dpms(mgr, mode) { ctx = mgr->ctx;
> >>> > fimd_dpms_ctx(ctx, mode); }. Alternatively, you can save a pointer to
> >>> > mgr in ctx, but that creates a circular link between the two. IMO,
> >>> > both of those solutions suck :)
> >>> >
> >>> > I'd much rather just set drvdata to the manager and call the hook
> >>> > directly. Like I said earlier, this is just a temporary step since we
> >>> > remove these pm ops later in the patch series.
> >>> >
> >>> > Sean
> >>> >
> >>> >
> >>> >> Anyway, I'd like to say really sorry about inconvenient again. So I
> >>> will fix
> >>> >> it.
> >>> >>
> >>> >> Thanks,
> >>> >> Inki Dae
> >>> >>
> >>> >>> Sean
> >>> >>>
> >>> >>>
> >>> >>> > Thanks,
> >>> >>> > Inki Dae
> >>> >>> >
> >>> >>
> >>
> > ___
> > 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/20131022/b05486e4/attachment-0001.html>
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/20131022/f1e1e066/attachment.html>
org/archives/dri-devel/attachments/20131022/3d54cf9a/attachment.html>
2013/10/17 Sean Paul :
> This patch splits display and manager from subdrv. The result is that
> crtc functions can directly call into manager callbacks and encoder
> functions can directly call into display callbacks. This will allow
> us to remove the exynos_drm_hdmi shim and support mixer/hdmi &
On Tue, Oct 22, 2013 at 7:43 AM, Sylvain BERTRAND wrote:
>>> commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12)
>>>
>>> evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped?
>>> Should cpu_to_le32 be used?
>>>
>>> Basically, is the endianness enforcement right for the r
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/14588c31/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/86711073/attachment.html>
els)
- OpenCL: small kernels (< 51 words)
--
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/20131022/4fdcfad4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=63391
--- Comment #7 from Tasev Nikola ---
Hi,
The 3.12-rc1 kernel is running fine with dpm enabled for more than 7 hours now
with 10-15 suspend resume cycles.
--
You are receiving this mail because:
You are watching the assignee of the bug.
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/20131022/b6af2e34/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/f050b0ea/attachment-0001.html>
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #8 from Ilya Tumaykin ---
I've just noticed that after such lockup if I only restart X server without
full reboot of the machine then video playback (mplayer) is unavailable. xvinfo
shows this:
X-Video Extension version 2.2
screen #0
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #7 from Ilya Tumaykin ---
mclk_ss doesn't help either. Last option is gfx_clock_gating. Will try it next.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/35968015/attachment.html>
vel/attachments/20131022/86570312/attachment.html>
/Radeon |DRM/Radeon
--
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/20131022/ea175b1e/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/8d5fbd69/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/619e732e/attachment-0001.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/5cc23c97/attachment.html>
hdmiphy dt node needs a child node called 'phy-power-control'
which represents the PMU register for power controlling the
hdmiphy.
hdmi driver dt node provides phy property which points to
the hdmiphy dt node.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420.dtsi | 14
hdmiphy dt node needs a child node called 'phy-power-control'
which represents the PMU register for power controlling the
hdmiphy.
hdmi driver dt node provides phy property which points to
the hdmiphy dt node.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250-smdk5250.dts |9
Exynos hdmi ddc is a I2C device and if we register hdmi ddc
driver with id_table as NULL, cause failure in probing.
id_table field should not be NULL for i2c_driver registeration.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_ddc.c |5 +
1 file changed, 5 insertions(+)
Before hdmiphy operation like config, start etc, hdmiphy
bit in PMU block should be enabled. Earlier this happens
in hdmi driver through a dummy "hdmiphy" clock.
Pmu bit control is added in both i2c and platform driver
for exynos hdmiphy.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/
Exynos5420 hdmiphy device is a platform device, unlike
predecessor SoCs where it used to be a I2C device. This
support is added to the hdmiphy platform driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/Makefile |1 +
drivers/gpu/drm/exynos/exynos_hdmi.c
hdmiphy is a dummy clock which actually controls the PMU bit
to enable/disable hdmiphy (before CCF). This clock is cleaned
from the hdmi driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c |8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/exyn
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is very tightly
coupled with hdmi IP driver.
This patch moves hdmiphy related code to hdmiphy I2C driver
which supports hdmiphys which are accessible through i2c
control bus for example in exynos4210, exyn
Currently, exynos hdmiphy operations and configs are kept
inside the hdmi driver. Hdmiphy related code is very tightly
coupled with hdmi IP driver. With these patches, hdmiphy
related stuff is moved to hdmiphy i2c driver for exynos4 and
exynos5250 socs. hdmi driver, being the phy controller, calls
On Mon, Oct 14, 2013 at 01:26:46PM -0400, Rob Clark wrote:
> Break the mutable state of a crtc out into a separate structure
> and use atomic properties mechanism to set crtc attributes. This
> makes it easier to have some helpers for crtc->set_property()
> and for checking for invalid params. Th
There exists a tight race between the call to nouveau_fence_done from
nouveau_fence_wait and the call to nouveau_fence_wait_uevent.
nouveau_fence_done checks to see if fence->channel is NULL before calling
nouveau_fence_wait_uevent, but it's not good enough since the dereference
in nouveau_fence_w
Use the driver calculated CTS and N values rather than
having hardware generate them. This allows us to use
the modeline pixel clock rather than the actual pll clock
when setting up the dto for audio. Fixes problems with
audio playback rate on certain asics if the pll clock
does not match the pix
On Fri, Oct 18, 2013 at 04:15:57PM +0100, Russell King - ARM Linux wrote:
> David,
>
> Rob Clark has now reviewed this and has given his blessing for it to be
> pulled for the coming merge window.
>
> This adds support for the Armada 510 display subsystem found on the
> Marvell Dove devices. Thi
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Tuesday, October 22, 2013 6:18 AM
> To: Inki Dae
> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>
> On Mon, Oct 21, 201
post your Xorg.log.
--
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/20131022/d1cb2a2c/attachment.html>
s/dri-devel/attachments/20131022/da0e1374/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/ec3db20b/attachment.html>
> -Original Message-
> From: Sean Paul [mailto:seanpaul at chromium.org]
> Sent: Monday, October 21, 2013 11:47 PM
> To: Inki Dae
> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
> Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
>
> On Thu, Oct 17, 201
>> commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12)
>>
>> evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped?
>> Should cpu_to_le32 be used?
>>
>> Basically, is the endianness enforcement right for the rlc BOs?
>> Or is there a bit somewhere to switch the RLC to host
On Tue, Oct 22, 2013 at 10:38:03AM +0100, Chris Wilson wrote:
> Prevent the user from passing in an ioctl command with up to 16,383
> bytes specified for the struct to be allocated and copied, and
> instead only allocate enough space to satisfy the kernel.
>
> Suggested-by: Pavel Roskin
> Signed-
https://bugzilla.kernel.org/show_bug.cgi?id=63101
--- Comment #14 from Kertesz Laszlo ---
I did some more testing. Turns out that i can get into the game if i set the
texture quality to "low". But it still crashes afterwards at some point -
usually after ~20 or so minutes.
Sometimes io have tons
On Tue, 22 Oct 2013 10:38:03 +0100
Chris Wilson wrote:
> Prevent the user from passing in an ioctl command with up to 16,383
> bytes specified for the struct to be allocated and copied, and
> instead only allocate enough space to satisfy the kernel.
>
> Suggested-by: Pavel Roskin
> Signed-off-b
https://bugzilla.kernel.org/show_bug.cgi?id=63391
--- Comment #6 from Tasev Nikola ---
(In reply to Alex Deucher from comment #3)
> (In reply to Tasev Nikola from comment #0)
> > It works also fine with kernel 3.11 with dpm enabled.
>
> Can you bisect?
Hi,
I remember now that i was using 3-4 d
https://bugzilla.kernel.org/show_bug.cgi?id=63391
--- Comment #5 from Tasev Nikola ---
Created attachment 111921
--> https://bugzilla.kernel.org/attachment.cgi?id=111921&action=edit
Xorg.0.log 3.11.6 dpm enabled and working ok
Xorg.0.log 3.11.6 dpm enabled and working ok
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=63391
--- Comment #4 from Tasev Nikola ---
Created attachment 111911
--> https://bugzilla.kernel.org/attachment.cgi?id=111911&action=edit
Dmesg 3.11.6 dpm enabled and working ok
Dmesg 3.11.6 dpm enabled and working ok
--
You are receiving this mail
Prevent the user from passing in an ioctl command with up to 16,383
bytes specified for the struct to be allocated and copied, and
instead only allocate enough space to satisfy the kernel.
Suggested-by: Pavel Roskin
Signed-off-by: Chris Wilson
Cc: Pavel Roskin
Cc: dri-devel at lists.freedesktop
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131022/50f43646/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131022/8d68de84/attachment.html>
es/dri-devel/attachments/20131022/548e9073/attachment.html>
guess it's usually
not even visible and possibly not worth bothering about.
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/20131022/cee8a722/attachment.pgp>
On Tue, Oct 22, 2013 at 1:30 AM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Sean Paul [mailto:seanpaul at chromium.org]
>> Sent: Tuesday, October 22, 2013 6:18 AM
>> To: Inki Dae
>> Cc: dri-devel; Dave Airlie; Tomasz Figa; St?phane Marchesin
>> Subject: Re: [PATCH v2 12/26] drm/exy
Hi Linus,
travelling slowed down getting these out,
2 vmwgfx fixes, radeon revert to avoid a regression, i915 fixes, and some
ioctl sizing issues fixed with 32 on 64.
Dave.
The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2:
Linux 3.12-rc5 (2013-10-13 15:41:28 -0700
g 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/20131022/f7bda638/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=63391
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #3 fr
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131022/dfa087cf/attachment.html>
On Sun, Oct 20, 2013 at 12:10:53PM -0400, Rob Clark wrote:
>Fyi, here are the queued up patches I have so far for 3.13.
I'm happy with these changes. You can add a
Acked-by: David Brown
if you want.
David
>Rob Clark (6):
> drm/msm: prime support
> drm/msm: support render nodes
> drm/m
Hi,
commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12)
evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped?
Should cpu_to_le32 be used?
Basically, is the endianness enforcement right for the rlc BOs?
Or is there a bit somewhere to switch the RLC to host
endianness? O
On Mon, Oct 21, 2013 at 8:26 PM, Sylvain BERTRAND wrote:
> Hi,
>
> commit 555b1b651acf44bf27ebbb04235d38a8fd2d58dc (drm-fixes-3.12)
>
> evergreen.c, SI code path, line 4045 and 4046 shouldn't be swapped?
> Should cpu_to_le32 be used?
>
> Basically, is the endianness enforcement right for the rlc B
Once a DRM device is unregistered, user-space must not access any existing
mmaps, anymore. As we cannot rely on this, we now zap all of them in
drm_dev_unregister().
Any driver which wants to support that needs to protect their fault()
and mmap() handlers via drm_dev_get_active(), otherwise users
Drivers which support unplugging currently use drm_unplug_dev() which
waits for all open files to be closed before unregistering a device. All
other drivers just immediately unregister the device if unplugged or
unloaded, which results in panics if there're pending open files.
This patch implement
If we unplug a DRM device, we currently set dev->unplugged and then wait
for all open-files to close. Beside rather subtle race-conditions, the
main disadvantage is that most DRM device resources will stay allocated
and registered. This means the device cannot be re-used by another driver
until all
This splits off real file-destruction into drm_close(). drm_release() now
calls drm_close() and then takes care of any device-cleanup which isn't
strictly related to file-destruction.
Besides making the code more readable, this is needed if we want to close
open-files during GPU unplug. We could s
This is basically a copy of percpu_down_read() but does not sleep if a
writer is already active. Same semantics as classic down_read_trylock().
Signed-off-by: David Herrmann
---
include/linux/percpu-rwsem.h | 1 +
lib/percpu-rwsem.c | 20
2 files changed, 21 inser
DRM could make great use of percpu-rwsems to track active users and wait
for them during hw hotplugging. Export symbols and allow using them in
runtime loadable modules.
Signed-off-by: David Herrmann
---
lib/Makefile | 2 +-
lib/percpu-rwsem.c | 7 +++
2 files changed, 8 insertions(+),
Hi
This is the 2nd revision of reliable unplug support for DRM. As revoke support
for the generic VFS layer is still not even close to being merged, this fixes
the generic DRM layer to handle unplugged devices gracefully.
This series fixes the DRM core to track any running f_ops. During device
un
70 matches
Mail list logo
