Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
> >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
> On
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks.
One more thing, you would need to check if other driver can be probed in
probe context. With your patch, exynos_hdmiphy_driver_register() is called
in hdmi_probe() via hdmi_get_phy_device(), and then
platform_driver_reigster() is called via the
exynos_hdmiphy_driver_register(). I remember that was
From: Christian König
The same as on evergreen.
Signed-off-by: Christian König
Reported-by: FrankR Huang
---
drivers/gpu/drm/radeon/cik.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e336a31..463c670 100644
--- a/
> -Original Message-
> From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
> Sent: Friday, August 30, 2013 6:11 PM
> To: dri-devel@lists.freedesktop.org
> Cc: inki@samsung.com; sachin.ka...@linaro.org; patc...@linaro.org;
> Andrzej Hajda
> Subject: [PATCH 1/1] drm/exynos: Fix build err
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae wrote:
> Hi Rahul.
>
> Thanks for your patch set.
>
> I had just quick review to all patch series. And I think we could fully hide
> hdmiphy interfaces,
> exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_a
The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page. In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to
On Fri, Aug 30, 2013 at 5:10 AM, Christian König
wrote:
> From: Christian König
>
> The same as on evergreen.
>
> Signed-off-by: Christian König
> Reported-by: FrankR Huang
Added to my queue and cc'ed for stable.
Alex
> ---
> drivers/gpu/drm/radeon/cik.c |4
> 1 file changed, 4 ins
On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä
> wrote:
>>
>> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
>> > wrote:
>>
>> > > 1. The API is geared toward updating one ob
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just looks l
https://bugs.freedesktop.org/show_bug.cgi?id=68391
--- Comment #9 from Vladimir Ysikov ---
I have GPU lockup with this patch.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesk
Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge. This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile|
https://bugs.freedesktop.org/show_bug.cgi?id=68224
--- Comment #11 from Michel Dänzer ---
(In reply to comment #9)
> .addImm(Lane);
This results in the lane number being encoded verbatim in the VSRC1 instruction
field, which I don't think is correct?
I tried adding 0x80 to make it an inline lit
https://bugs.freedesktop.org/show_bug.cgi?id=64810
Johannes Obermayr changed:
What|Removed |Added
CC||johannesoberm...@gmx.de
--- Comment
Hi,
This patch series adds support for panels to DRM. The current implementation
is very basic and only provides hooks for a panel to handle DPMS changes and
return a list of supported modes. That should be enough to support a rather
large number of panels. It should also be easy to extend the fra
On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>>
>> I guess if you have multiple encoders + multiple connectors for the
>> "ganging" case, then it probably just looks like 2x displays, and
>> nothing more really needed?
>>
>> I'm a bit f
On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
> > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> > wrote:
> >
> > > 1.
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov wrote:
> Handles automake complains about lack of forward-compatibility, due to the
> source files in the kgsl and msm backends/folders.
>
> Cc: Rob Clark
> Signed-off-by: Emil Velikov
I've tested these two (this and 4/6).. they seem to work fine fo
https://bugs.freedesktop.org/show_bug.cgi?id=68708
Alex Deucher changed:
What|Removed |Added
Attachment #84931|0 |1
is obsolete|
On Wed, Aug 14, 2013 at 4:47 PM, Sean Paul wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov wrote:
> Prodives memset() and strlen(), used in tests/setversion
> tests/getversion respectively.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
> tests/getversion.c | 1 +
> tests/setversion.c | 1 +
> 2 files changed, 2 insertions
https://bugs.freedesktop.org/show_bug.cgi?id=68708
--- Comment #3 from Alex Deucher ---
Created attachment 84931
--> https://bugs.freedesktop.org/attachment.cgi?id=84931&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee for t
Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.
Support is add
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov wrote:
> The compiler is unaware of that we have at least one crts/connector/plane
> thus it complains that some of our variables will be used uninitialised.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
>
> This patch looks like a r
Use the DRM panel framework to attach a panel to an output.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/drm/Kconfig | 1 +
drivers/gpu/host1x/drm/drm.h| 1 +
drivers/gpu/host1x/drm/output.c | 28 ++--
3 files changed, 28 insertions(+), 2 deletions(-)
diff
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient t
Hi Dave,
This is the radeon drm-next request. Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes
The following chang
On Thu, Aug 29, 2013 at 09:31:54PM +0100, Emil Velikov wrote:
> Currently the package name and description duplicate that of the
> core libdrm. Update those to reflect reality.
>
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Looks good to me:
Reviewed-by: Damien Lespiau
--
Damien
> ---
https://bugs.freedesktop.org/show_bug.cgi?id=55420
Ian Romanick changed:
What|Removed |Added
Assignee|i...@freedesktop.org |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=55420
--- Comment #2 from Marek Olšák ---
Please test latest Mesa master. TGSI recently got support for array
declarations of temporaries, making register allocation possible with indirect
addressing. That said, I'm not sure if the r600g shader backend
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #14 from Marek Olšák ---
That commit does break something, but it was fixed in:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0d7f087483d014305ec96a84ce5a28355f843c86
In other words, can you checkout 7948ed1250cae78ae1b22dbce4ab2
On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie wrote:
>
> ssh://people.freedesktop.org/~airlied/linux drm-fixes
Please people! When you post ssh addresses, always remember to also
post your user name and password or private key with the pull request.
Ok?
Linus
_
On Sat, Aug 31, 2013 at 9:18 AM, Linus Torvalds
wrote:
> On Thu, Aug 29, 2013 at 4:08 PM, Dave Airlie wrote:
>>
>> ssh://people.freedesktop.org/~airlied/linux drm-fixes
>
> Please people! When you post ssh addresses, always remember to also
> post your user name and password or private key with
https://bugs.freedesktop.org/show_bug.cgi?id=68775
Priority: medium
Bug ID: 68775
Assignee: dri-devel@lists.freedesktop.org
Summary: RV635 (r600) 600_DEBUG=sb causes GPU reset playing
Second Life
Severity: major
Classific
Hi Dave,
Just a one-line patch to fix a black screen issue on rare ivb machines,:w
cc: stable. Normally I'd just shovel this into the -next pull request this
late in the -rc cycle, but Linus was making noises about not getting real
fixes which are cc: stable. So here we go ;-)
Cheers, Daniel
The
Since we are getting to the pointy end, one i915 black screen on some
machines, and one vmwgfx stop userspace ability to nuke the VM,
there might be one or two ati or nouveau fixes trickle in before final,
but I think this should pretty much be it.
Dave.
The following changes since commit d8
Hi Dave,
Need to get my stuff out the door ;-) Highlights:
- pc8+ support from Paulo
- more vma patches from Ben.
- Kconfig option to enable preliminary support by default (Josh
Triplett)
- Optimized cpu cache flush handling and support for write-through caching
of display planes on Iris (Chri
Hi Philipp,
On Tuesday 27 August 2013 11:30:51 Philipp Zabel wrote:
> Hi Laurent,
>
> I have another small issue with the graph helpers below:
>
> Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> [...]
>
> > +/*
> >
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
wrote:
> On Wed,
On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>>> wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
> On Thu, A
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
>> wrote:
>>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
wrote:
> On T
Am 29.08.2013 23:24, schrieb Alex Deucher:
> For powergating, we just need to re-init the registers, there
> is no need to resture the uvd BOs. This just adds needless
> work when powergating uvd for playback while the system is
> on. We only need to restore the uvd BOs on an actual resume
> from
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
> >> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
> >> wrote:
> >>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
> >>
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks.
One more thing, you would need to check if other driver can be probed in
probe context. With your patch, exynos_hdmiphy_driver_register() is called
in hdmi_probe() via hdmi_get_phy_device(), and then
platform_driver_reigster() is called via the
exynos_hdmiphy_driver_register(). I remember that was
From: Christian K?nig
The same as on evergreen.
Signed-off-by: Christian K?nig
Reported-by: FrankR Huang
---
drivers/gpu/drm/radeon/cik.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e336a31..463c670 100644
--- a/
> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Friday, August 30, 2013 6:11 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; sachin.kamat at linaro.org; patches at
> linaro.org;
> Andrzej Hajda
> Subject: [PATCH 1/1] drm/exy
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae wrote:
> Hi Rahul.
>
> Thanks for your patch set.
>
> I had just quick review to all patch series. And I think we could fully hide
> hdmiphy interfaces,
> exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_a
The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page. In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to
On Fri, Aug 30, 2013 at 5:10 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> The same as on evergreen.
>
> Signed-off-by: Christian K?nig
> Reported-by: FrankR Huang
Added to my queue and cc'ed for stable.
Alex
> ---
> drivers/gpu/drm/radeon/cik.c |4
> 1 file changed, 4 ins
On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l?
> wrote:
>>
>> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
>> > wrote:
>>
>> > > 1. The API is geared toward updating one ob
On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>>
>> I guess if you have multiple encoders + multiple connectors for the
>> "ganging" case, then it probably just looks like 2x displays, and
>> nothing more really needed?
>>
>> I'm a bit f
On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l? <
> ville.syrjala at linux.intel.com> wrote:
>
> > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> > wrote:
> >
> > >
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann
> wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just look
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130830/1bc3f302/attachment.html>
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov
wrote:
> Handles automake complains about lack of forward-compatibility, due to the
> source files in the kgsl and msm backends/folders.
>
> Cc: Rob Clark
> Signed-off-by: Emil Velikov
I've tested these two (this and 4/6).. they seem to work fine f
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov
wrote:
> The compiler is unaware of that we have at least one crts/connector/plane
> thus it complains that some of our variables will be used uninitialised.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
>
> This patch looks like a
On Thu, Aug 29, 2013 at 4:31 PM, Emil Velikov
wrote:
> Prodives memset() and strlen(), used in tests/setversion
> tests/getversion respectively.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Rob Clark
> ---
> tests/getversion.c | 1 +
> tests/setversion.c | 1 +
> 2 files changed, 2 insertion
Hi,
This patch series adds support for panels to DRM. The current implementation
is very basic and only provides hooks for a panel to handle DPMS changes and
return a list of supported modes. That should be enough to support a rather
large number of panels. It should also be easy to extend the fra
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient t
Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.
Support is add
Use the DRM panel framework to attach a panel to an output.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/drm/Kconfig | 1 +
drivers/gpu/host1x/drm/drm.h| 1 +
drivers/gpu/host1x/drm/output.c | 28 ++--
3 files changed, 28 insertions(+), 2 deletions(-)
diff
On Thu, Aug 29, 2013 at 09:31:54PM +0100, Emil Velikov wrote:
> Currently the package name and description duplicate that of the
> core libdrm. Update those to reflect reality.
>
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Looks good to me:
Reviewed-by: Damien Lespiau
--
Damien
> ---
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130830/bbc5d9fd/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130830/dc665783/attachment.html>
On Wed, Aug 14, 2013 at 4:47 PM, Sean Paul wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it
Drop the msm_connector base class, and special calls to base class
methods from the encoder, and use instead drm_bridge. This allows for a
cleaner division between the hdmi (and in future dsi) blocks, from the
mdp block.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile|
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130830/7772f8ee/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130830/ae13670c/attachment.html>
Hi Dave,
This is the radeon drm-next request. Big changes include:
- support for dpm on CIK parts
- support for ASPM on CIK parts
- support for berlin GPUs
- major ring handling cleanup
- remove the old 3D blit code for bo moves in favor of CP DMA or sDMA
- lots of bug fixes
The following chang
component is
the common front-end code. Perhaps Marek can comment...
--
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/20130830/3a5ef
On 08/29/13 03:00, Stephen Rothwell wrote:
> Hi all,
>
on x86_64:
ERROR: "nouveau_switcheroo_optimus_dsm" [drivers/gpu/drm/nouveau/nouveau.ko]
undefined!
Full randconfig file is attached.
--
~Randy
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Li
72 matches
Mail list logo
