Some devices don't have a panel connected to LVDS and thus will never power up.
This patch checks the power sequence progress bits in PP_STATUS to prevent an
endless loop on such devices.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_lid.c | 12 +---
1 file changed, 9
On Sun, May 13, 2012 at 2:17 PM, Patrik Jakobsson
wrote:
> Some devices don't have a panel connected to LVDS and thus will never power
> up.
> This patch checks the power sequence progress bits in PP_STATUS to prevent an
> endless loop on such devices.
"gma500: address the lid code" triggers the
Poulsbo needs a physical address in the cursor base register. We allocate a
stolen memory buffer and copy the cursor image provided by userspace into it.
When/If we get our own userspace driver we can map this stolen memory directly.
The patch also adds a mark in chip ops so we can identify devices
https://bugzilla.kernel.org/show_bug.cgi?id=43236
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #5 f
https://bugzilla.kernel.org/show_bug.cgi?id=30642
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
Dear Patrik,
Am Sonntag, den 13.05.2012, 15:07 +0200 schrieb Patrik Jakobsson:
> Poulsbo needs a physical address in the cursor base register. We allocate a
> stolen memory buffer and copy the cursor image provided by userspace into it.
> When/If we get our own userspace driver we can map this st
On Sun, 13 May 2012 14:17:52 +0200
Patrik Jakobsson wrote:
> Some devices don't have a panel connected to LVDS and thus will never power
> up.
> This patch checks the power sequence progress bits in PP_STATUS to prevent an
> endless loop on such devices.
We should never get there. In fact we do
> How can it be verified, that the hardware cursor is working?
Use the mode setting X server with cursor support.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=41762
Tadej Janež changed:
What|Removed |Added
CC||tadej.janez@tadej.hicsalta.
On Sun, May 13, 2012 at 3:59 PM, Alan Cox wrote:
> We should never get there. In fact we don't want to because if there is
> np panel the backlight is not initialised either.
>
> I'll take a look. I've just fixed a related problem where we wrongly
> invoked the lid code on non Pouslbo devices.
Ok
https://bugs.freedesktop.org/show_bug.cgi?id=43167
--- Comment #40 from Alan 2012-05-13 07:51:54 PDT ---
Thanks
(For reference the reason I want to take a look to see where the problem is
likely to be is that when we switch
to the fbcon the shell should be getting SIGWINCH and the tty bits upda
On Sun, May 13, 2012 at 3:53 PM, Paul Menzel
wrote:
>> The patch also adds a mark in chip ops so we can identify devices that has
>> this
>
> s,has,have,
Noted...
> How can it be verified, that the hardware cursor is working?
As Alan says, use the modesetting driver from:
git://anongit.freedes
On Sun, 13 May 2012 16:43:31 +0200
Patrik Jakobsson wrote:
> On Sun, May 13, 2012 at 3:59 PM, Alan Cox wrote:
> > We should never get there. In fact we don't want to because if there is
> > np panel the backlight is not initialised either.
> >
> > I'll take a look. I've just fixed a related prob
https://bugs.freedesktop.org/show_bug.cgi?id=41762
--- Comment #8 from Pasi Kärkkäinen 2012-05-13 08:44:47 PDT ---
Yeah, many people have the overheating problem with radeon driver and laptops..
In my opinion the default radeon power profile is *broken*, and it should be
switched to "low", or
https://bugzilla.kernel.org/show_bug.cgi?id=42984
--- Comment #12 from Peter Hedlund 2012-05-13
22:51:16 ---
(In reply to comment #11)
> Dithering?
eDP-1 connected 1440x900+1920+0 (normal left inverted right x axis y axis)
286mm x 179mm
EDID:
00000610df9c
2012/5/10 Emil Goode :
> Include the linux/types.h file where used types are declared.
>
> Sparse gives the following warning:
> /usr/include/drm/exynos_drm.h:92:
> found __[us]{8,16,32,64} type without
> #include
>
> Signed-off-by: Emil Goode
> ---
> include/drm/exynos_drm.h |
On 05/12/2012 01:48 PM, InKi Dae wrote:
> 2012/5/12 KOSAKI Motohiro :
>> On Fri, May 11, 2012 at 7:29 PM, Jerome Glisse wrote:
>>> On Fri, May 11, 2012 at 6:59 PM, KOSAKI Motohiro
>>> wrote:
> My point is this ioctl will be restricted to one user (Xserver if i
> understand) and only this
this feature could be used to memory region allocated by malloc() in user mode
and mmaped memory region allocated by other memory allocators.
userptr interface can identify memory type through vm_flags value and would get
pages or page frame numbers to user space appropriately.
Changelog v4:
we ha
this ioctl is used to limit user-desired userptr size as pre-defined
and also could be accessed by only root user.
with userptr feature, unprivileged user can allocate all the pages on system,
so the amount of free physical pages will be very limited. if the VMAs
within user address space was pinn
this feature is used to import user space region allocated by malloc() or
mmaped into a gem. for this, we uses get_user_pages() to get all the pages
to VMAs within user address space. However we should pay attention to use
this userptr feature like below.
The migration issue.
- Pages reserved by C
Hi,
There was some warning when ran "make randconfig ".
warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct
dependencies (EXPERIMENTAL).
so i was thinking of the possible fix may be
drivers/gpu/drm/Kconfig
+ select DMA_SHARED_BUFFER if EXPERIMENTAL
Thanks
Hello Alex Deucher,
This is a semi-automatic email about new static checker warnings.
The patch eccea7920cfb: "drm/radeon/kms: improve bpc handling (v2)"
from Mar 26, 2012, leads to the following Smatch complaint:
drivers/gpu/drm/radeon/atombios_crtc.c:599 atombios_adjust_pll()
warn: v
> + npages = buf->size >> PAGE_SHIFT;
Why round down? usually we use round up.
> + down_read(¤t->mm->mmap_sem);
> +
> + /*
> + * Basically, all the pages from get_user_pages() can not be not only
> + * migrated by CMA but also swapped out.
> + *
> +
> -Original Message-
> From: KOSAKI Motohiro [mailto:kosaki.motoh...@gmail.com]
> Sent: Monday, May 14, 2012 3:33 PM
> To: Inki Dae
> Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org; j.gli...@gmail.com;
> minc...@kernel.org; kyungmin.p...@samsung.com; sw0312@samsung.com;
> jy092
2012. 5. 13. ?? 12:05 Rob Clark ??:
> Ok, I've pushed this with a couple minor cleanups:
>
> 1) remove .pc file (which is generated from .pc.in file)
> 2) below patch to fix a compile error (maybe not seen w/ older gcc?)
> 3) remove DRM_IOCTL_EXYNOS_GEM_USERPTR because I think that part is
>
The CEA has a bunch of very peculiar modes. For backwards
compatibility is specifies a bunch of resulting that are suitable to
display old SD TV content. But these modes have such low pixel clocks
that pixels need to be double to reach the minimal clock of the HDMI
interface.
Paulo Zanoni already
Paulo Zanoni already fixed up the avi infoframes as mandated by CEA,
this patch here now ensures that we correctly scan out these
double-clocked modes.
Intel hw automatically doubles the pixels and clocks, hence we want
half wire pixel clock from the drm mode, but otherwise can take the
framebuffe
The CEA spec has a bunch of very peculiar modes. For backwards
compatibility it specifies a bunch of modes that are suitable to
display old SD TV content. But these modes have such low pixel clocks
that pixels need to be doubled to reach the minimal clock of the HDMI
interface.
Paulo Zanoni alread
Paulo Zanoni already fixed up the avi infoframes as mandated by CEA,
this patch here now ensures that we correctly scan out these
double-clocked modes.
Intel hw automatically doubles the pixels and clocks, hence we want
half the wire pixel clock from the drm mode, but otherwise can take
the frameb
Some devices don't have a panel connected to LVDS and thus will never power up.
This patch checks the power sequence progress bits in PP_STATUS to prevent an
endless loop on such devices.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_lid.c | 12 +---
1 file changed, 9
On Sun, May 13, 2012 at 2:17 PM, Patrik Jakobsson
wrote:
> Some devices don't have a panel connected to LVDS and thus will never power
> up.
> This patch checks the power sequence progress bits in PP_STATUS to prevent an
> endless loop on such devices.
"gma500: address the lid code" triggers the
Poulsbo needs a physical address in the cursor base register. We allocate a
stolen memory buffer and copy the cursor image provided by userspace into it.
When/If we get our own userspace driver we can map this stolen memory directly.
The patch also adds a mark in chip ops so we can identify devices
https://bugzilla.kernel.org/show_bug.cgi?id=43236
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
https://bugzilla.kernel.org/show_bug.cgi?id=30642
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
/* Sub functions */
> struct drm_crtc_helper_funcs const *crtc_helper;
[?]
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL
On Sun, 13 May 2012 14:17:52 +0200
Patrik Jakobsson wrote:
> Some devices don't have a panel connected to LVDS and thus will never power
> up.
> This patch checks the power sequence progress bits in PP_STATUS to prevent an
> endless loop on such devices.
We should never get there. In fact we do
> How can it be verified, that the hardware cursor is working?
Use the mode setting X server with cursor support.
Alan
https://bugs.freedesktop.org/show_bug.cgi?id=41762
Tadej Jane? changed:
What|Removed |Added
CC||tadej.janez at tadej.hicsalta.
On Sun, May 13, 2012 at 3:59 PM, Alan Cox wrote:
> We should never get there. In fact we don't want to because if there is
> np panel the backlight is not initialised either.
>
> I'll take a look. I've just fixed a related problem where we wrongly
> invoked the lid code on non Pouslbo devices.
Ok
https://bugs.freedesktop.org/show_bug.cgi?id=43167
--- Comment #40 from Alan 2012-05-13 07:51:54 PDT ---
Thanks
(For reference the reason I want to take a look to see where the problem is
likely to be is that when we switch
to the fbcon the shell should be getting SIGWINCH and the tty bits upda
On Sun, May 13, 2012 at 3:53 PM, Paul Menzel
wrote:
>> The patch also adds a mark in chip ops so we can identify devices that has
>> this
>
> s,has,have,
Noted...
> How can it be verified, that the hardware cursor is working?
As Alan says, use the modesetting driver from:
git://anongit.freedes
On Sun, 13 May 2012 16:43:31 +0200
Patrik Jakobsson wrote:
> On Sun, May 13, 2012 at 3:59 PM, Alan Cox wrote:
> > We should never get there. In fact we don't want to because if there is
> > np panel the backlight is not initialised either.
> >
> > I'll take a look. I've just fixed a related prob
https://bugs.freedesktop.org/show_bug.cgi?id=41762
--- Comment #8 from Pasi K?rkk?inen 2012-05-13 08:44:47 PDT
---
Yeah, many people have the overheating problem with radeon driver and laptops..
In my opinion the default radeon power profile is *broken*, and it should be
switched to "low", or
https://bugzilla.kernel.org/show_bug.cgi?id=42984
--- Comment #12 from Peter Hedlund 2012-05-13
22:51:16 ---
(In reply to comment #11)
> Dithering?
eDP-1 connected 1440x900+1920+0 (normal left inverted right x axis y axis)
286mm x 179mm
EDID:
00000610df9c
Hi,
There was some warning when ran "make randconfig ".
warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct
dependencies (EXPERIMENTAL).
so i was thinking of the possible fix may be
drivers/gpu/drm/Kconfig
+ select DMA_SHARED_BUFFER if EXPERIMENTAL
Thanks
Hello Alex Deucher,
This is a semi-automatic email about new static checker warnings.
The patch eccea7920cfb: "drm/radeon/kms: improve bpc handling (v2)"
from Mar 26, 2012, leads to the following Smatch complaint:
drivers/gpu/drm/radeon/atombios_crtc.c:599 atombios_adjust_pll()
warn: v
46 matches
Mail list logo
