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 changed:
What|Removed |Added
Attachment #78533|text/plain |image/png
mime type|
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-
> de...@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=62889
--- Comment #20 from Michel Dänzer ---
Are the 32-bit drivers used by Steam up to date?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@l
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(-)
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
> -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-
> de...@lists.fre
> 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
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_
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
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
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
Nick changed:
What|Removed |Added
Attachment #100261|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick 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 changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
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 +-
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/
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_
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 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
>
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 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
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
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
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://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
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
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
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
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 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
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
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 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 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:
> 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
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
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
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/
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
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
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
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
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
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
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 #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
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
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
>>
>> 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
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
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
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
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]
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 insertion(+),
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 islan
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
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
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
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
- 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 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
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
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:
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
||
--
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,
> -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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130429/65dbe621/attachment-0001.html>
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(-)
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
> -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
> 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
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_
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
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
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
Nick changed:
What|Removed |Added
Attachment #100261|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=57281
Nick changed:
What|Removed |Added
Attachment #100271|application/octet-stream|text/plain
mime type|
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>
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.
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 +-
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/
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_
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
>
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 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
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=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
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
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>
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
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
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
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 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
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
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
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
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:
> 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
1 - 100 of 113 matches
Mail list logo
