or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/3b36a255/attachment.html>
eceiving 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/20131118/f0b7a8f7/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c6077170/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/af56e1c1/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c20ce164/attachment.html>
ly
in order.
--
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/20131118/b3ece3f5/attachment-0001.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/798dd658/attachment.html>
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/cik.c| 3 +++
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 9 +
include/uapi/drm/radeon_drm.h | 2 ++
5 files change
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index bb87105..fa42c81 100644
--- a/drivers/gpu/drm/radeon/rade
On Fre, 2013-11-15 at 18:55 +0100, Marek Ol??k wrote:
> From: Michel D?nzer
>
> Signed-off-by: Marek Ol??k
[...]
> @@ -1657,10 +1659,7 @@ static int si_surface_init_2d(struct
> radeon_surface_manager *surf_man,
> tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
> b
https://bugzilla.kernel.org/show_bug.cgi?id=65141
Bug ID: 65141
Summary: Blank screen after resume with radeon driver
Product: Drivers
Version: 2.5
Kernel Version: 3.7,3.11,3.12
Hardware: All
OS: Linux
Tree: M
https://bugzilla.kernel.org/show_bug.cgi?id=65141
Takashi Iwai changed:
What|Removed |Added
URL||https://bugzilla.novell.com
s scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/41a49856/attachment-0001.pgp>
Hi Simon,
On Monday 18 November 2013 17:23:11 Simon Horman wrote:
> Hi Laurent,
>
> I am wondering if you have any patches to wire up this driver
> for the Koelsch board so that I might test it.
Here you go.
git://linuxtv.org/pinchartl/fbdev.git drm/du/koelsch
Only the LVDS output is c
op.
I agree. While I currently have no use-case where this is required, I
think having a struct dsi_msg makes it easier to extend the featureset
on an as-needed basis.
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/20131118/94e107dd/attachment.pgp>
rates.
--
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/20131118/510216fe/attachment.html>
- Original Message -
> If ttm_bo_move_memcpy was instructed to move a non-populated ttm to
> io memory, it would first populate the ttm, then move the data and then
> destroy the ttm. That's stupid. However, some drivers might have relied on
> this to clear io memory from old stuff. So inst
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c643902b/attachment.html>
On 11/18/2013 11:22, Thierry Reding wrote:
> On Thu, Nov 14, 2013 at 03:04:19PM +, Bert Kenward wrote:
> > #define DSI_WINDOW_VFP (1 << 0)
> > #define DSI_WINDOW_ACT (1 << 1)
> > #define DSI_WINDOW_VBP (1 << 2)
> > #define DSI_WINDOW_VSY (1 << 3)
> >
> > /**
> > * struct dsi_msg - DSI comm
nd even so
dsi_msg doesn't have to be perfect from the start. It's an in-kernel
API, therefore can change easily if needed. The less we require of it
now the easier it will be to extend when the need arises.
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/20131118/ccbecb2d/attachment-0001.pgp>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/d541f6a9/attachment.html>
h driver to properly encode the
channel and data type.
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/20131118/4647e53c/attachment.pgp>
release so that the version number can be used
to track the dependency.
I wonder if perhaps tying the libdrm releases more tightly to Linux
kernel releases would help. Since there already is a requirement for new
kernel APIs to be merged before the libdrm equivalent can be merged,
then having both release cycles in lockstep makes some sense.
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/20131118/d3912c84/attachment.pgp>
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/20131118/e18e0f22/attachment.pgp>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/031f29cc/attachment.html>
l/attachments/20131118/59d34eb2/attachment-0001.html>
On Mon, Nov 18, 2013 at 4:25 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
Both patches applied to my tree.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rad
d of multiple times.
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/20131118/e9a02036/attachment.pgp>
From: Michel D?nzer
Signed-off-by: Marek Ol??k
---
radeon/radeon_surface.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 927a21e..cd5cbd6 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -143
On Thu, Nov 14, 2013 at 7:49 PM, Thomas Hellstrom
wrote:
> Addresses
> "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE".
>
> In the first occurence it was used to try to be nice while releasing the
> mmap_sem and retrying the fault to work around a locking inversion.
> The sec
On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
wrote:
> On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
>> Debug print the capabilities, and flag an error if the panel does not
>> support adjusting backlight through the BL_PWM_DIM pin, requiring
>> backlight control through DPCD.
>>
On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding
wrote:
> On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
>> On 11/09/2013 12:11 AM, Dave Airlie wrote:
>> >>> How does this interact with the rule that kernel interfaces require an
>> >>> open source userspace? Is "here are the mesa/lib
ould be pulled into libdrm and a
release be made. I could even imagine a matching of version numbers.
libdrm releases could be numbered using the same major and minor as
Linux kernels that they support. Micro version numbers could be used
in intermediate releases.
> Maybe limiting who does releases would be sufficient. Unless there is
> someone with enough free time and energy to volunteer to be libdrm
> maintainer.
>
> But tbh I don't think it has been too much of a problem in the past.
> I'm not sure if I actually read somewhere the rule about not updating
> kernel headers until the interface is locked in (ie. drm-next), but it
> seemed like common sense to me. Could be enough just to document this
> a bit more explicitly.
It's not something I feel very strongly about. People seemed unhappy
about the current state of affairs, so I thought I'd dump a few ideas.
=)
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/20131118/436769ea/attachment.pgp>
could probably be made to work. The tricky part would be
> hw specific ordering in the training sequence. At the very minimum,
> you need driver callbacks to set up the source side:
>
> set_training_pattern()
> set_vs_emph()
>
> And probably some flags to indicate whether the the
https://bugzilla.kernel.org/show_bug.cgi?id=53471
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vid
On Mon, Nov 18, 2013 at 04:26:17PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 10:09:56AM -0500, Alex Deucher wrote:
> > On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
> > wrote:
> > > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> > >> Debug print the capabilities, and
On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
wrote:
> On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
>> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding
>> wrote:
>> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote:
>> >> On 11/09/2013 12:11 AM, Dave Airlie wrote:
>>
https://bugzilla.kernel.org/show_bug.cgi?id=53111
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=53111
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail because:
Yo
MIPI DSI bus allows to model DSI hosts
and DSI devices using Linux bus.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
Hi,
This is my implementation of mipi dsi bus.
The first time it was posted as a part of CDF infrastructure [1],
but if it can be merged independently I will be
https://bugzilla.kernel.org/show_bug.cgi?id=53471
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
op 09-11-13 22:26, Ian Romanick schreef:
> On 11/09/2013 12:11 AM, Dave Airlie wrote:
How does this interact with the rule that kernel interfaces require an
open source userspace? Is "here are the mesa/libdrm patches that use
it" sufficient to get the kernel interface merged?
>>> Tha
> fruit first.
That also means we'll have to duplicate the training in every new
driver. I was half expecting to be required to come up with the generic
code again, but if everyone is okay with this I won't bother with it for
now.
> Note that there's already a bit of abstraction for i2c over dp aux, but
> imo that's at the wrong level. At least reading through i915, gma500 and
> radeon code there's a lot more we could share with just a dp aux helper
> library (which then implements useful stuff on top of it).
I have some difficulty envisioning how the helper code can work without
some sort of driver-specific ops implementation. Currently the helpers
only use a snapshot of the DPCD to extract information. Eventually we'll
be bound to modify the DPCD, so some method of writing it back (or a
subset of it) will be needed. Otherwise the scope of the helper library
will be somewhat limited.
Once we have the callbacks, the current helpers could be reworked to not
use a buffer, but rather an "AUX channel object" and access the
registers directly. If there are concerns about performance, it could
possibly be implemented as a sort of cache, too. That would make it fast
to query the status. I don't think it'll be worth the added complexity,
though.
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/20131118/9fc2248c/attachment.pgp>
On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding
wrote:
>> Note that there's already a bit of abstraction for i2c over dp aux, but
>> imo that's at the wrong level. At least reading through i915, gma500 and
>> radeon code there's a lot more we could share with just a dp aux helper
>> library (which
ting code to libdrm before it's in a upstream
> kernel.
> Preferably wait until it appears in torvalds/linux.git, but it seems airlied
> has a
> lower standard. :)
>
> Sometimes software bugs might warrant a release too, so this middle area is
> needed.
Having a different development model doesn't exclude the possibility for
bugfix releases. Neither does explicit control of what patches are
merged.
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/20131118/1db723ca/attachment.pgp>
t for new
> >> > kernel APIs to be merged before the libdrm equivalent can be merged,
> >> > then having both release cycles in lockstep makes some sense.
> >>
> >> Not sure about strictly tying it to kernel releases would be ideal.
> >> Not *everything* in libdrm is about new kernel APIs. It tends to be
> >> the place for things needed both by xorg ddx and mesa driver, which I
> >> suppose is why it ends up a bit of a free-for-all.
> >
> > I didn't mean that every release would need to be tied to the Linux
> > kernel. But whenever a new Linux kernel release was made, relevant
> > changes from the public headers could be pulled into libdrm and a
> > release be made. I could even imagine a matching of version numbers.
> > libdrm releases could be numbered using the same major and minor as
> > Linux kernels that they support. Micro version numbers could be used
> > in intermediate releases.
>
> maybe an update-kernel-headers.sh script to grab the headers from
> drm-next and update libdrm wouldn't be a bad idea?
Perhaps. But I think it could even be a manual step. It's not something
that one person should be doing alone, but rather something that driver
maintainers should be doing, since they know best what will be needed
in a new version of libdrm.
Like I mentioned in another subthread, I think a subtree-oriented model
could work well.
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/20131118/5df0bde5/attachment-0001.pgp>
On 11/18/2013 01:57 PM, Thierry Reding wrote:
> On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote:
>> Hi Thierry,
>>
>> On 11/13/2013 10:38 PM, Thierry Reding wrote:
>>> On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote:
Hi Thierry,
I have already sent patch w
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/5142c525/attachment.html>
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote:
> > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding
> > wrote:
> > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote:
> > >> On Mon, Nov 18, 2013 at 8:29 AM, Thie
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/2316fbb7/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4411faa0/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/8c4a3ca6/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/0239973d/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4987a921/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/dea78b5f/attachment.html>
|--- |FIXED
--
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/20131118/e8cda89d/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2013 06:43 PM, Keith Packard wrote:
> Emil Velikov writes:
>
>> On 18/11/13 01:08, Keith Packard wrote:
>>> libudev doesn't have a stable API/ABI, and if the application
>>> wants to use one version, we'd best not load another into
>>> libGL
https://bugzilla.kernel.org/show_bug.cgi?id=53471
--- Comment #3 from Chris Rankin ---
This particular intermittent problem hasn't occurred again, but I can't claim
to know whether it has been fixed.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On Fri, Nov 15, 2013 at 9:47 PM, Mark Rutland wrote:
> On Tue, Oct 29, 2013 at 08:12:32AM +, Shirish S wrote:
>> This patch adds dt support to hdmiphy config settings
>> as it is board specific and depends on the signal pattern
>> of board.
>>
>> Signed-off-by: Shirish S
>> ---
>> .../d
On 18/11/13 01:08, Keith Packard wrote:
> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard
> ---
>
Hi Keith,
Firstly, I would like to apologise for the rather daft questions.
With t
For various revisions of a chipset if the signal pattern is changed for every
revision, then the phy setting need to be updated correspondingly by measuring
the signal.
For getting correct signals the clock level and data de-emphasis
levels needs to be adjusted.
Since only these 2 values matter,we
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 +
1 file changed, 75 insertions(+)
d
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 75 ++
1 file changed, 75 insertions(+)
d
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 75
1 file changed, 75 insertions(+)
d
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++
1 file changed, 74 insertions(+)
d
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 33 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 77 ++
On 15.11.2013 22:53, Stephen Warren wrote:
> From: Stephen Warren
>
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard DMA DT bindings.
>
> Historica
Hi Laurent,
I am wondering if you have any patches to wire up this driver
for the Koelsch board so that I might test it.
On Wed, Nov 13, 2013 at 02:52:10PM +0100, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds support for the DU found in the R8A7791 SoC. It starts
> by a cleanup pat
On Mon, Nov 18, 2013 at 4:10 AM, Thierry Reding wrote:
> On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote:
>> Hi All,
>>
>> The commit below seems to have made the Tegra DRM driver a bool option
>> instead of tristate:
>>
>> commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9
>> Author: Thie
For various revisions of a chipset if the signal pattern is changed for every
revision, then the phy setting need to be updated correspondingly by measuring
the signal.
For getting correct signals the clock level and data de-emphasis
levels needs to be adjusted.
Since only these 2 values matter,we
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 33 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 77 ++
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +
1 file changed, 74 insertions(+)
d
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 74
1 file changed, 74 insertions(+)
d
ture
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1ba23072/attachment.pgp>
On 18/11/13 01:08, Keith Packard wrote:
> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard
> ---
>
Hi Keith,
Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
I
pplication/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/bed4ee40/attachment-0001.pgp>
76 matches
Mail list logo
