bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/78240480/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/94125b75/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/ea33bf0d/attachment.html>
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
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
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
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
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
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,
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
> -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-
>
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>
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
---
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
+++
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
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
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.
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:
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment
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
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
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
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/4df2df41/attachment.html>
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
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
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
---
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:
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
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
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
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
>
tx->win_data[win].enabled = false;
> > }
> >
> > -static int mixer_check_timing(void *ctx, struct fb_videomode *timing)
> > +static int mixer_check_timing(void *ctx, struct drm_display_mode *mode)
> > {
> > u32 w, h;
> >
> > - w = timing->xres;
> > - h = timing->yre
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
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
> ---
>
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
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 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:
:
<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>
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 index, referencing
an iguana bug.
Is it still buggy from southern
Am 2013-04-25 18:19, schrieb Christian K?nig:
> From: Christian K?nig
>
> This avoid moving the BO directly after allocating it.
>
> Signed-off-by: Christian K?nig
Tested-by: Dieter N?tzel
Regards,
Dieter
> ---
> drivers/gpu/drm/radeon/radeon_sa.c |2 +-
> 1 file changed, 1
Am 2013-04-24 14:12, schrieb Christian K?nig:
> From: Christian K?nig
>
> Also init the scratch reg to zero on the UVD ring.
> This fixes UVD on AGP based cards.
>
> Signed-off-by: Christian K?nig
Tested-by: Dieter N?tzel
RV730 AGP (UVD 2.2) works with radeon.agpmode=8, now.
[ 10.394741]
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]
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:
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
https://bugs.freedesktop.org/show_bug.cgi?id=62889
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Attachment #78533|text/plain |image/png
Hi,
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Uwe Kleine-Konig
Sent: Monday, April 29, 2013 4:35 PM
To: Inki Dae
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; dri-
From: Christian König christian.koe...@amd.com
Stupid copy paste error over all generations.
Signed-off-by: Christian König christian.koe...@amd.com
---
drivers/gpu/drm/radeon/evergreend.h |2 +-
drivers/gpu/drm/radeon/rv770d.h |2 +-
drivers/gpu/drm/radeon/sid.h|2 +-
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
Sent: Monday, April 29, 2013 6:52 PM
To: Inki Dae
Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; dri-
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
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,
https://bugzilla.kernel.org/show_bug.cgi?id=47351
--- Comment #5 from Nick ka.n...@mail.ru 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
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:
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #1 from Nick ka.n...@mail.ru 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/show_bug.cgi?id=57281
Nick ka.n...@mail.ru changed:
What|Removed |Added
Attachment #100261|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick ka.n...@mail.ru changed:
What|Removed |Added
Attachment #100271|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=63702
Christian König deathsim...@vodafone.de changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You
exynos_drm_framebuffer_init() does not return NULL. Use IS_ERR instead.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
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
---
None of these functions actually return a NULL pointer. Hence use
IS_ERR() instead.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
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
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.
https://bugzilla.kernel.org/show_bug.cgi?id=47351
--- Comment #6 from Alex Deucher alexdeuc...@gmail.com 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
On Mon, Apr 29, 2013 at 4:20 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
Stupid copy paste error over all generations.
Applied to my tree.
Alex
Signed-off-by: Christian König christian.koe...@amd.com
---
On Mon, Apr 29, 2013 at 5:55 AM, Christian König
deathsim...@vodafone.de wrote:
From: Christian König christian.koe...@amd.com
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:
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Alex Deucher alexdeuc...@gmail.com changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
--- Comment #3 from Michel Dänzer mic...@daenzer.net 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
On Sun, Apr 28, 2013 at 9:26 PM, Sylvain BERTRAND sylw...@legeek.net 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
https://bugs.freedesktop.org/show_bug.cgi?id=63865
--- Comment #8 from Alex Deucher ag...@yahoo.com ---
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
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
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
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
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
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
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
On Mon, Apr 29, 2013 at 7:14 AM, Rahul Sharma rahul.sha...@samsung.com 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,
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com 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
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com 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
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com 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
Hi,
On 04/29/2013 07:04 PM, Sean Paul wrote:
On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com
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
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
Signed-off-by: Christopher Harvey char...@matrox.com
---
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
Signed-off-by: Christopher Harvey char...@matrox.com
---
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
---
These two variables are set again immediately in 'mgag200_modeset_init'
Signed-off-by: Christopher Harvey char...@matrox.com
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
https://bugs.freedesktop.org/show_bug.cgi?id=63935
--- Comment #6 from Dave Witbrodt dawit...@sbcglobal.net ---
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]
Christopher Harvey char...@matrox.com 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
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
johannesoberm...@gmx.de 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
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #4 from PJBrs pj...@floorenpj.xs4all.nl ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #5 from PJBrs pj...@floorenpj.xs4all.nl ---
Created attachment 78616
-- https://bugs.freedesktop.org/attachment.cgi?id=78616action=edit
First bad penumbra output with RADEON_DEBUG=fp,vp
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=63520
--- Comment #6 from PJBrs pj...@floorenpj.xs4all.nl ---
Created attachment 78617
-- https://bugs.freedesktop.org/attachment.cgi?id=78617action=edit
Last good penumbra output with RADEON_DEBUG=fp,vp
--
You are receiving this mail because:
You
Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
johannesoberm...@gmx.de 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
On Tue, Apr 30, 2013 at 7:27 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie:
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
Hi James,
Linus recently released Kernel 3.9, merge window for
1 - 100 of 104 matches
Mail list logo
