Dear Christopher,
Am Montag, den 29.04.2013, 14:37 -0400 schrieb Christopher Harvey:
> I submitted these a while ago, but I think they got lost in the
> mailing list. Just wanted to make sure they get a shot at the merge
> window.
as you resend the patches you could have easily amended the commi
Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
> On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
> wrote:
> > Hi James,
> >
> > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
> > opened, and the question is whether drm-openchrome will be part of the new
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #160 from Jani Nikula ---
(In reply to comment #159)
> Something is broken in the 3.8 kernel. When I'm using it, the colour depth
> is low, and my system freezes when I try to suspend the computer. I don't
> know if it caused by the a
On Mon, Apr 29, 2013 at 11:07 PM, Sylwester Nawrocki
wrote:
> Hi,
>
> On 04/29/2013 07:04 PM, Sean Paul wrote:
>> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
>> wrote:
>>> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
>>> accessed among hdmi and hdmiphy driver. Duri
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/78240480/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/94125b75/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/ea33bf0d/attachment.html>
> The reason we (currently) use the dumb buffer interface is because it
> does pretty much exactly what we need it to, as we only want linear
> RGB buffers:
Except in the cases where it doesn't do what you want, and possibly in
the future where it does less of what you want. You've started on a
sl
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access t
Hdmiphy callbacks are tighly coupled with hdmi IP callbacks inside
the hdmi driver. With increase in the support of different versions of
hdmiphys, hdmi ip driver expanding with lots of phy related information.
Above movement ensures that phy related code is present and maintained
within the hdmiph
hdmiphy hardware block is a physically separate device. Hdmiphy driver
is glued inside hdmi driver and acessed through hdmi callbacks. With
increasing diversities in the hdmiphy mapping and configurations, hdmi
driver is expanding with un-related changes.
This patch registers hdmiphy as a independ
Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
components. Currently, drivers for these components are getting registered
in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
In this patch, registration of drm hdmi sub-driver and device, drivers for
hd
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related code is tightly coupled with hdmi ip driver. Physicaly they are
different devices and should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent
of each oth
Hello Rahul,
I looks good to me.
On 2013? 04? 29? 20:14, Rahul Sharma wrote:
> Exynos hdmi driver is using drm_display_mode for setting timing values
> for a supported resolution. Conversion to fb_videomode and then comparing
> with the mixer/hdmi/phy limits is not required. Instead, drm_display_
Hi,
On 04/29/2013 07:04 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
>> accessed among hdmi and hdmiphy driver. During power cycle, each of these
>> driver decrements the ref-count and e
> -Original Message-
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, April 29, 2013 6:52 PM
> To: Inki Dae
> Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri-
> dev
u 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/20130429/918d2ce3/attachment.html>
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 78d8e91..f988965 100644
--- a/drivers/gpu/drm/mgag200/mgag
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #159 from György Balló ---
Something is broken in the 3.8 kernel. When I'm using it, the colour depth is
low, and my system freezes when I try to suspend the computer. I don't know if
it caused by the applied workaround or not, but th
Hi James,
Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
opened, and the question is whether drm-openchrome will be part of the new
Kernel version.
Regards,
Johannes
>>
>> Christopher Harvey (3):
>> drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
>> drm/mgag200: Pass driver specific mga_device in driver functions
>> drm/mgag200: Remove extra variable assigns
>>
>> drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
>> drivers/gpu/drm/mgag200/mgag2
Dear Christian,
Am Montag, den 29.04.2013, 10:20 +0200 schrieb Christian K?nig:
> From: Christian K?nig
>
> Stupid copy & paste error over all generations.
does this fix an error or was this found just by reading the code? Could
please you add such information to commit message in the future?
Hi,
> -Original Message-
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Uwe Kleine-Konig
> Sent: Monday, April 29, 2013 4:35 PM
> To: Inki Dae
> Cc: gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; dri-
> devel a
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode and then comparing
with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
fields cane be directly compared.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
Hi Dave,
This is final pull request for Exynos next and includes device tree
support for fimc device, one revert, some code cleanups and fixup.
The revert replaces wrong one[1] with correct one[2].
This was my mistake and sorry for this.
[1] http://www.mail-archive.com/linux-media
u 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/20130429/53b7b082/attachment.html>
Christopher Harvey writes:
> I submitted these a while ago, but I think they got lost in the
> mailing list. Just wanted to make sure they get a shot at the merge
> window.
>
> thanks,
>
> Christopher Harvey (3):
> drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
> drm/mgag200: Pas
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #3 from Michel D?nzer 2013-04-29 14:41:09
---
(In reply to comment #0)
> After upgrading my AMD E-450-based notebook to a newer one (HP 4545s
> A4-3300-based) i noticed that in spite of noticeable higher clock rate the
> video pe
I submitted these a while ago, but I think they got lost in the
mailing list. Just wanted to make sure they get a shot at the merge
window.
thanks,
Christopher Harvey (3):
drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
drm/mgag200: Pass driver specific mga_device in driver functio
On Tue, Apr 30, 2013 at 7:27 AM, Johannes Obermayr
wrote:
> Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
>> On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
>> wrote:
>> > Hi James,
>> >
>> > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
>> > opened, a
This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
The issue could be induced when some framework which includes two
more sub drivers, is built as one moudle because those sub drivers
could have their own MODULE_DEVICE_TABLE.
And 'struct of_device_id' isn't needed to be determined by t
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
> On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
> wrote:
> > Hi James,
> >
> > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
> > opened, and the question is whether drm-openchrome will be part of the new
https://bugzilla.kernel.org/show_bug.cgi?id=47351
--- Comment #6 from Alex Deucher 2013-04-29
14:20:38 ---
(In reply to comment #5)
> I have the same behaviour on my HP 4545s laptop if I try to use discrete video
> card (HD7500/7600). I managed to get it work (more or less) on integrated
>
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #6 from PJBrs ---
Created attachment 78617
--> https://bugs.freedesktop.org/attachment.cgi?id=78617&action=edit
Last good penumbra output with RADEON_DEBUG=fp,vp
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #5 from PJBrs ---
Created attachment 78616
--> https://bugs.freedesktop.org/attachment.cgi?id=78616&action=edit
First bad penumbra output with RADEON_DEBUG=fp,vp
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #4 from PJBrs ---
I've run the Penumbra Requiem game with RADEON_DEBUG=fp,vp and captured the
output. I made two attachments. The file named "Goodlog" is the log with mesa
version snb_magic_9030_g342cac7 (commit
342cac71669662abad3435
Hi Rahul,
2013/4/26 Rahul Sharma
> Right now hdmiphy operations and configs are kept inside hdmi driver.
> hdmiphy
> related code is tightly coupled with hdmi ip driver. Physicaly they are
> different devices and should be instantiated independently.
>
> In terms of versions/mapping/configurati
Hello Rahul,
I agree with basic idea of this patch.
However, to avoid confusion, how do you think about fixing all
check_timing as check_mode and its second parameter as mode including
struct exynos_drm_display_ops?
Regards,
- Seung-Woo Kim
On 2013? 04? 26? 23:03, Rahul Sharma wrote:
> Exynos h
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/20130429/4df2df41/attachment.html>
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
wrote:
> Hi James,
>
> Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
> opened, and the question is whether drm-openchrome will be part of the new
> Kernel version.
Johannes,
you misunderstand merge window. The merge
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
wrote:
> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
> accessed among hdmi and hdmiphy driver. During power cycle, each of these
> driver decrements the ref-count and ensures that last user disables the
> clock. Setting p
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
wrote:
> hdmiphy hardware block is a physically separate device. Hdmiphy driver
> is glued inside hdmi driver and acessed through hdmi callbacks. With
> increasing diversities in the hdmiphy mapping and configurations, hdmi
> driver is expanding with
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick changed:
What|Removed |Added
Attachment #100271|application/octet-stream|text/plain
mime type|
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
wrote:
> Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
> components. Currently, drivers for these components are getting registered
> in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
>
> In this patc
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick changed:
What|Removed |Added
Attachment #100261|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #1 from Nick 2013-04-29 12:34:50 ---
Created an attachment (id=100271)
--> (https://bugzilla.kernel.org/attachment.cgi?id=100271)
Kernel config
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Y
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Summary: Radeon: Bad performance and power consumption
Product: Drivers
Version: 2.5
Kernel Version: 3.8.2-pf
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NE
None of these functions actually return a NULL pointer. Hence use
IS_ERR() instead.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/
exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
Signed-off-by: Sachin Kamat
---
This series is based on exynos-drm-next branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |2 +-
On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma
wrote:
> Exynos hdmi driver is using drm_display_mode for setting timing values
> for a supported resolution. Conversion to fb_videomode and then comparing
> with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
> fields cane be di
https://bugzilla.kernel.org/show_bug.cgi?id=47351
--- Comment #5 from Nick 2013-04-29 12:01:07 ---
Created an attachment (id=100251)
--> (https://bugzilla.kernel.org/attachment.cgi?id=100251)
lspci -vv output
I have the same behaviour on my HP 4545s laptop if I try to use discrete video
ca
Christopher Harvey writes:
> I submitted these a while ago, but I think they got lost in the
> mailing list. Just wanted to make sure they get a shot at the merge
> window.
>
> thanks,
>
> Christopher Harvey (3):
> drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
> drm/mgag200: Pas
From: Christian K?nig
Instead of duplicating the code over and over again, just use a single
function to handle the clock calculations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c | 103 +++---
drivers/gpu/drm/radeon/r600d.h |4 +
driver
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #6 from Dave Witbrodt ---
FWIW, I'm seeing this same firmware issue on a SUMO2 system:
[1.305718] [drm] Initialized drm 1.1.0 20060810
[1.305767] [drm] radeon kernel modesetting enabled.
[1.305964] [drm] initializing kern
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 64297c7
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 78d8e91..f988965 100644
--- a/drivers/gpu/drm/mgag200/mgag
Signed-off-by: Christopher Harvey
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index d2253f6..a5a1f34 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/
I submitted these a while ago, but I think they got lost in the
mailing list. Just wanted to make sure they get a shot at the merge
window.
thanks,
Christopher Harvey (3):
drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth
drm/mgag200: Pass driver specific mga_device in driver functio
On Mon, Apr 29, 2013 at 10:22 AM, Inki Dae wrote:
>
> Hi Rahul,
>
>
> 2013/4/26 Rahul Sharma
>>
>> Right now hdmiphy operations and configs are kept inside hdmi driver.
hdmiphy
>> related code is tightly coupled with hdmi ip driver. Physicaly they are
>> different devices and should be instantiat
Hello Rahul,
Thanks for notifying.
As your comment, it is same patch with yours, so just ignore my patch.
Besg Regards,
- Seung-Woo Kim
On 2013? 04? 26? 18:14, Rahul Sharma wrote:
> Hi Seung Woo,
>
> I had posted the same solution at
> http://lists.freedesktop.org/archives/dri-devel/2013-Janua
- h = timing->yres;
> > + w = mode->hdisplay;
> > + h = mode->vdisplay;
> >
> > DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
> > - __func__, timing->xres, timing->yres,
> > - timing->refresh, (timing->vmode &
> > - FB_VMODE_INTERLACED) ? true : false);
> > + __func__, mode->hdisplay, mode->vdisplay,
> > + mode->vrefresh, (mode->flags &
> > + DRM_MODE_FLAG_INTERLACE) ? true : false);
> >
> > if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> > (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> > @@ -837,6 +837,7 @@ static int mixer_check_timing(void *ctx, struct
> fb_videomode *timing)
> >
> > return -EINVAL;
> > }
> > +
> > static void mixer_wait_for_vblank(void *ctx)
> > {
> > struct mixer_context *mixer_ctx = ctx;
> >
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
>
> ___
> 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/20130429/3ab62fba/attachment-0001.html>
On Sun, Apr 28, 2013 at 9:26 PM, Sylvain BERTRAND wrote:
> Hi,
>
> I have a few questions about radeon pm code:
>
>
> In radeon_atombios.c, radeon_atombios_parse_power_table_6
> function, power_state->v2.nonClockInfoIndex for non_clock_info of
> one state is ignored and replaced by the state
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
>
> The issue could be induced when some framework which includes two
> more sub drivers, is built as one moudle because those sub drivers
> could have their own MODULE_DEVICE_
Hi,
On 04/29/2013 07:04 PM, Sean Paul wrote:
> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
> wrote:
>> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
>> accessed among hdmi and hdmiphy driver. During power cycle, each of these
>> driver decrements the ref-count and e
On Mon, Apr 29, 2013 at 5:55 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Instead of duplicating the code over and over again, just use a single
> function to handle the clock calculations.
Applied to by tree.
Alex
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/e
On Mon, Apr 29, 2013 at 4:20 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Stupid copy & paste error over all generations.
Applied to my tree.
Alex
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/evergreend.h |2 +-
> drivers/gpu/drm/radeon/rv770d.h |2
From: Christian K?nig
Stupid copy & paste error over all generations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreend.h |2 +-
drivers/gpu/drm/radeon/rv770d.h |2 +-
drivers/gpu/drm/radeon/sid.h|2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma wrote:
> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
> accessed among hdmi and hdmiphy driver. During power cycle, each of these
> driver decrements the ref-count and ensures that last user disables the
> clock. Setting pa
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma wrote:
> hdmiphy hardware block is a physically separate device. Hdmiphy driver
> is glued inside hdmi driver and acessed through hdmi callbacks. With
> increasing diversities in the hdmiphy mapping and configurations, hdmi
> driver is expanding with
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma wrote:
> Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
> components. Currently, drivers for these components are getting registered
> in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
>
> In this patch
On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma wrote:
> Exynos hdmi driver is using drm_display_mode for setting timing values
> for a supported resolution. Conversion to fb_videomode and then comparing
> with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
> fields cane be dir
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
s/mutiple/multiple/, still this sentence doesn't sound right. What is
the error message you see?
> The issue could be induced when some framework which includes two
> more sub
Hi James,
Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been
opened, and the question is whether drm-openchrome will be part of the new
Kernel version.
Regards,
Johannes
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
Hi Dave,
Just a few important fixes for 3.10. 3 regression fixes, plus rectified
Haswell overclock support (the old code was correct, only docs confusing)
and improved DP data m/n selection.
Cheers, Daniel
The following changes since commit bd080ee57c2173cefdcadc39c7863a76c249d049:
drm/i915:
Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
accessed among hdmi and hdmiphy driver. During power cycle, each of these
driver decrements the ref-count and ensures that last user disables the
clock. Setting parrent device to none ensure that both the drivers gets
access t
Hdmiphy callbacks are tighly coupled with hdmi IP callbacks inside
the hdmi driver. With increase in the support of different versions of
hdmiphys, hdmi ip driver expanding with lots of phy related information.
Above movement ensures that phy related code is present and maintained
within the hdmiph
hdmiphy hardware block is a physically separate device. Hdmiphy driver
is glued inside hdmi driver and acessed through hdmi callbacks. With
increasing diversities in the hdmiphy mapping and configurations, hdmi
driver is expanding with un-related changes.
This patch registers hdmiphy as a independ
Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
components. Currently, drivers for these components are getting registered
in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.
In this patch, registration of drm hdmi sub-driver and device, drivers for
hd
Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy
related code is tightly coupled with hdmi ip driver. Physicaly they are
different devices and should be instantiated independently.
In terms of versions/mapping/configurations Hdmi and hdmiphy are independent
of each oth
https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #8 from Alex Deucher ---
It looks like you are using a bogus unposted vbios image. I think you'll need
to bisect. If I had to guess, I'd say it's related to some change in how the
pci rom images are fetched.
--
You are receiving t
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/65dbe621/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/20130429/e566204f/attachment.html>
On Sun, Apr 28, 2013 at 9:26 PM, Sylvain BERTRAND wrote:
> Hi,
>
> I have a few questions about radeon pm code:
>
>
> In radeon_atombios.c, radeon_atombios_parse_power_table_6
> function, power_state->v2.nonClockInfoIndex for non_clock_info of
> one state is ignored and replaced by the state
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #3 from Michel Dänzer 2013-04-29 14:41:09 ---
(In reply to comment #0)
> After upgrading my AMD E-450-based notebook to a newer one (HP 4545s
> A4-3300-based) i noticed that in spite of noticeable higher clock rate the
> video per
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
On Mon, Apr 29, 2013 at 5:55 AM, Christian König
wrote:
> From: Christian König
>
> Instead of duplicating the code over and over again, just use a single
> function to handle the clock calculations.
Applied to by tree.
Alex
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/e
On Mon, Apr 29, 2013 at 4:20 AM, Christian König
wrote:
> From: Christian König
>
> Stupid copy & paste error over all generations.
Applied to my tree.
Alex
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/evergreend.h |2 +-
> drivers/gpu/drm/radeon/rv770d.h |2
https://bugzilla.kernel.org/show_bug.cgi?id=47351
--- Comment #6 from Alex Deucher 2013-04-29 14:20:38
---
(In reply to comment #5)
> I have the same behaviour on my HP 4545s laptop if I try to use discrete video
> card (HD7500/7600). I managed to get it work (more or less) on integrated
>
Exynos hdmi driver is using drm_display_mode for setting timing values
for a supported resolution. Conversion to fb_videomode and then comparing
with the mixer/hdmi/phy limits is not required. Instead, drm_display_mode
fields cane be directly compared.
v4:
1) Removed __func__ from DRM_DEBUG_KMS.
On Mon, Apr 29, 2013 at 02:32:01PM +0900, Inki Dae wrote:
> This patch fixes mutiple defined issue to MODULE_DEVICE_TABLE
>
> The issue could be induced when some framework which includes two
> more sub drivers, is built as one moudle because those sub drivers
> could have their own MODULE_DEVICE_
None of these functions actually return a NULL pointer. Hence use
IS_ERR() instead.
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/
exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
Signed-off-by: Sachin Kamat
---
This series is based on exynos-drm-next branch of Inki Dae's tree:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |2 +-
https://bugs.freedesktop.org/show_bug.cgi?id=63702
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick changed:
What|Removed |Added
Attachment #100271|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick changed:
What|Removed |Added
Attachment #100261|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #1 from Nick 2013-04-29 12:34:50 ---
Created an attachment (id=100271)
--> (https://bugzilla.kernel.org/attachment.cgi?id=100271)
Kernel config
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Y
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Summary: Radeon: Bad performance and power consumption
Product: Drivers
Version: 2.5
Kernel Version: 3.8.2-pf
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NE
1 - 100 of 113 matches
Mail list logo
