xcompmgr -a doesn't
work better, there are many other compositing managers you can try.
--
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-dev
org/archives/dri-devel/attachments/20140610/45b2f733/attachment.html>
From: Michel D?nzer
Fixes WARN()s from the DRM core since the page flip rework.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77521
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
|Drivers/Gallium/radeonsi
--
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/20140610/81c834e3/attachment-0001.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/a5a892e2/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/7a3a764b/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/9062c309/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #14 from swoorupj at gmail.com ---
(In reply to Alex Deucher from comment #13)
> (In reply to swoorupj from comment #12)
> > Hi Alex,
> >
> > I have reported the same issue in bugs.freedesktop. I tried out the 3.15
> > linux kernel in
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #15 from swoorupj at gmail.com ---
Is there a way or patch, I could get all the state of the card and test how
they differ before and after suspending?
--
You are receiving this mail because:
You are watching the assignee of the bug.
vel/attachments/20140610/3d84bb87/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/bd7ffb89/attachment-0001.html>
On Sun, Jun 08, 2014 at 10:30:15PM +0100, Sitsofe Wheeler wrote:
> With a tree that is close to 3.15 final I'm regularly seeing the
> following on my EeePC 900 when starting ioquake3:
>
> [drm:intel_pipe_config_compare] *ERROR* mismatch in
> gmch_pfit.lvds_border_bits (expected 32768, found 0)
H
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #33 from Teofilis Martisius ---
Created attachment 138791
--> https://bugzilla.kernel.org/attachment.cgi?id=138791&action=edit
dmesg output for 3.15-rc8, delay of 200, patched with testing patch 2
--
You are receiving this mail bec
https://bugzilla.kernel.org/show_bug.cgi?id=51381
--- Comment #34 from Teofilis Martisius ---
Hello,
I have applied patch2 to 3.15-rc8 along with patch1 and delay of 200, ran with
"radeon.runpm=0", tried to turn off and on the dGPU, and the problem is still
there. Dmesg attached.
Sincerely,
Teo
r_bbo =
88000d714800
in dmesg?
--
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/20140610/f88e639a/attachment.html>
On Mon, Jun 09, 2014 at 02:39:51PM +0100, Damien Lespiau wrote:
> It was reported that this comment was confusing, and indeed it is.
>
> Signed-off-by: Damien Lespiau
> ---
> include/uapi/drm/i915_drm.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/include/uap
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #16 from Vitaliy Filippov ---
Since you know everything was ok in 3.8, maybe you'll just also try to bisect?
:)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #17 from swoorupj at gmail.com ---
Sorry I have mislead you. I meant I started using linux since 3.8. And I have
had this problem since. I don't recall it working with KMS.
--
You are receiving this mail because:
You are watching the
On Jun-05-2014 2:58 PM, Thierry Reding wrote:
> On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
> [...]
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> [...]
>> /**
>> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
>> + * @dev: DR
From: Thierry Reding
Tegra124 supports a block-linear mode in addition to the regular pitch
linear and tiled modes. Add support for these by moving the internal
representation into a structure rather than a simple flag.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 102 ++
From: Thierry Reding
Currently the tiling parameters of buffer objects can only be set at
allocation time, and only a single tiled mode is supported. This new
DRM_TEGRA_GEM_SET_TILING IOCTL allows more modes to be set and also
allows the tiling mode to be changed after the allocation. This will
e
From: Thierry Reding
The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the flags of a
buffer object after it has been allocated or imported. Flags associated
with a buffer object can be queried using the DRM_TEGRA_GEM_GET_FLAGS
IOCTL.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/
From: Thierry Reding
This matches what other drivers do for equivalent IOCTLs.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index f292c29ef62f..56ef81a
From: Thierry Reding
Job submission currently relies on the fact that struct drm_tegra_reloc
and struct host1x_reloc are the same size and uses a simple call to the
copy_from_user() function to copy them to kernel space. This causes the
handle to be stored in the buffer object field, which then n
roperty (which would be NULL if create
> fails) and have a NULL check at the calling end or
> 2. have a NULL check for the property at the calling end keeping the
> existing implementation or
> 3. return a non-zero value in case of failure.
I prefer 3. -ENOMEM sounds like a good candidate here.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/995ddec5/attachment.sig>
On Sun, 08 Jun 2014, Matt Turner wrote:
> On Sat, Jun 7, 2014 at 3:45 PM, G?bor Bereczki
> wrote:
>> did some more research. Is the following correct?
>> -OpenCL is not yet supported for Intel GPU on Linux
>
> The Beignet project [1] supports OpenCL IvyBridge (and Haswell, I think).
>
> I believ
On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
wrote:
> Right, so the problem isn't at the HDMI level, but at the DI level... so
> that's where we need to debug what's being setup. I left some debugging
> in ipu-di.c - could you try enabling that please?
Booting the kernel with the HD
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/9356ac4a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/9f3c1e76/attachment-0001.html>
celaration through gstreamer, but I don't have the corresponding packages
installed).
--
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/at
-- next part --
A non-text attachment was scrubbed...
Name: 0001-hummingboardlvds.patch
Type: text/x-patch
Size: 1229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/3be844f8/attachment.bin>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/f257c1bd/attachment.html>
On Thu, Jun 05, 2014 at 11:24:27AM -0700, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there. So check for it and keep it enabled if we see it
> already on. Based on an earlier fix from Kristian.
>
> v2: honor modparam if set too (Dan
https://bugzilla.kernel.org/show_bug.cgi?id=76761
--- Comment #18 from Alex Deucher ---
swoorupj you have some other issue then. It's not related to this bug.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> Some machines (like MBAs) might use a tiled framebuffer but not enable
> display swizzling at boot time. We want to preserve that configuration
> if possible to prevent a boot time mode set. On IVB+ it shouldn't
> affect performance
On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> From: Kristian H?gsberg
>
> The BIOS may set a native mode that doesn't quite match the preferred
> mode timings. It should be ok to use however if it uses the same size,
> so try to avoid a mode set in that case.
>
> Signed-off-by
On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> Let them eat mincemeat pie.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_params.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu
On Fri, Jun 06, 2014 at 02:12:44PM +0300, Jani Nikula wrote:
> On Thu, 05 Jun 2014, Jesse Barnes wrote:
> > Let them eat mincemeat pie.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --
From: Fredrik H?glund
This disambiguates depth 16 formats, such as ARGB1555 and ARGB,
and depth 32 formats such as ARGB2101010 and ARGB.
This patch also adds support for depth 30 (XRGB2101010) framebuffers.
Signed-off-by: Fredrik H?glund
Reviewed-by: Mario Kleiner
Tested-by: Mario Kle
From: Mario Kleiner
The hardware lut's only have 256 slots for indexing by a
8 bpc framebuffer. In 10 bpc scanout modes, framebuffer
color values would get truncated to their 8 msb's,
thereby losing the extra precision afforded by a 10 bpc
framebuffer.
To retain full precision, bypass the hw lut
https://bugzilla.kernel.org/show_bug.cgi?id=77471
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
.
--
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/20140610/83fb5565/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/92888a12/attachment.html>
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v12->v13:
- This patch doesn't need the DRM_MODE_FLAG_POL_*_PRESERVE flags anymore.
- code cleanup to improve readability:
- ENABLE_POL_PRESERVE is now gone
- Less modifications in ip
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v10->v13:
- No changes
ChangeLog v9->v10:
- Rebas
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v9->v13:
- Rebased
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
ChangeLog v7->v8:
- Shrinked e
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v10->v13:
- Rebased
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zabel's Ack.
- Included Lothar Wa
Signed-off-by: Denis Carikli
---
ChangeLog 12->v13:
- No changes
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"staging: imx-drm: Use de-active an
The imx-drm driver can't use the de-active and
pixelclk-active display-timings properties yet.
Instead the data-enable and the pixel data clock
polarity are hardcoded in the imx-drm driver.
So theses properties are now set to keep
the same behaviour when imx-drm will start
using them.
Signed-off
Signed-off-by: Denis Carikli
---
ChangeLog v12->v13:
- Added a note explaining why the size is zero in
the eukrea_mbimxsd51_dvi(s)vga structs.
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
---
.../bindings/panel/euk
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v10->v13:
- Rebased
- Removed enable-active-high in reg_lcd_3v3: its GPIO
already has the GPIO_ACTIVE_HIGH flag.
Without this removal, the display was off at boot
and powering it off and on was necessar
Signed-off-by: Denis Carikli
---
ChangeLog v11->v13:
- No changes
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog v6->v7:
- Shrinked even more
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v12->v13:
- Added Docbook documentation for pol_flags the struct field.
- Removed the _PRESERV
On Tue, Jun 10, 2014 at 09:58:54AM -0300, Fabio Estevam wrote:
> Booting the kernel with the HDMI cable connected (no image is seen on
> HDMI, only on LVDS):
Reformatting a bit:
> disp 0: panel size = 1920 x 1080
> Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
> IPU clock can give 13
On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> where 'M' is the IPU DI clock muxer. However, we're currently setting
> this up as:
>
> LM --+ LDB serial
> `- /7 -+ LDB DI clock
> IPM --- /N IM --- IPU DI clock
>
> and hoping that th
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote:
> Introduce generic functions to register and unregister connectors. This
> provides a common place to add and remove associated user space
> interfaces.
>
> Signed-off-by: Thomas Wood
> ---
> Documentation/DocBook/drm.tmpl|
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote:
> Add a file to debugfs for each connector to enable modification of the
> "force" connector attribute. This allows connectors to be enabled or
> disabled for testing and debugging purposes.
>
> Signed-off-by: Thomas Wood
> ---
> drivers/gp
Hi
On Thu, May 29, 2014 at 5:57 PM, Thomas Wood wrote:
> Add a file to debugfs for each connector that allows the edid data to be
> overridden.
>
> Signed-off-by: Thomas Wood
> ---
> drivers/gpu/drm/drm_crtc.c | 4 +++
> drivers/gpu/drm/drm_debugfs.c | 56
> ++
On Tue, Jun 10, 2014 at 05:14:21PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> > where 'M' is the IPU DI clock muxer. However, we're currently setting
> > this up as:
> >
> > LM --+ LDB serial
> > `- /7
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/f78a083c/attachment-0001.html>
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/20140610/c49be8dc/attachment.html>
On Tue, 10 Jun 2014 16:02:51 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:28AM -0700, Jesse Barnes wrote:
> > Some machines (like MBAs) might use a tiled framebuffer but not enable
> > display swizzling at boot time. We want to preserve that configuration
> > if possible to prevent
On Tue, 10 Jun 2014 16:05:36 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:30AM -0700, Jesse Barnes wrote:
> > From: Kristian H?gsberg
> >
> > The BIOS may set a native mode that doesn't quite match the preferred
> > mode timings. It should be ok to use however if it uses the same
On Tue, 10 Jun 2014 16:07:44 +0200
Daniel Vetter wrote:
> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> > Let them eat mincemeat pie.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i915_params.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(
On Tue, Jun 10, 2014 at 2:04 PM, Russell King - ARM Linux
wrote:
> This diagram is drawn from the code in clk-imx6.c, and it does not
> agree with what is in the SoC manuals - this is the representation
> redrawn from the manuals:
> The difference is, there is no clock gate between the LDB
On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes
wrote:
> On Tue, 10 Jun 2014 16:07:44 +0200
> Daniel Vetter wrote:
>
>> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
>> > Let them eat mincemeat pie.
>> >
>> > Signed-off-by: Jesse Barnes
>> > ---
>> > drivers/gpu/drm/i915/i915_pa
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/8fff1e13/attachment-0001.html>
On Tue, 10 Jun 2014 11:01:06 -0700
St?phane Marchesin wrote:
> On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes
> wrote:
> > On Tue, 10 Jun 2014 16:07:44 +0200
> > Daniel Vetter wrote:
> >
> >> On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
> >> > Let them eat mincemeat pie.
> >>
On Mon, Jun 9, 2014 at 7:29 AM, Fabio Estevam wrote:
> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux
> wrote:
>
>> Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This
>> should report the current state of the hotplug detection.
>
> /sys/class/drm/card0-HDMI-A-1/stat
Hi Tim,
On Tue, Jun 10, 2014 at 3:54 PM, Tim Harvey wrote:
> Fabio,
>
> I'm following along with this thread as I see the same thing you do on
> our Ventana boards that support both LVDS and HDMI: without
> hot-plugging the HDMI connector I get not HDMI out simply by having
> the LVDS node popul
On Sat, May 31, 2014 at 12:00:45PM +0900, Tetsuo Handa wrote:
> >From 4e8d1a83629c5966bfd401c5f2187355624194f2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 31 May 2014 09:59:44 +0900
> Subject: [PATCH 3/5] gpu/drm/ttm: Use mutex_trylock() to avoid deadlock
> inside shrinker function
On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes
wrote:
> Yes, that's what I do below... I even added it to the changelog:
> http://patchwork.freedesktop.org/patch/27223/
>
> Did you miss the later hunk in intel_display.c?
>
> What we try to do here is enable swizzling if possible, which we can do
>
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #3 from joshua.r.marshall.1991 at gmail.com ---
This is the R7 GPU on the A10-7850K
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #4 from joshua.r.marshall.1991 at gmail.com ---
Created attachment 138971
--> https://bugzilla.kernel.org/attachment.cgi?id=138971&action=edit
New kernel config that does boot
I used localmodconfig for then, then added debug info --
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #5 from joshua.r.marshall.1991 at gmail.com ---
Created attachment 138981
--> https://bugzilla.kernel.org/attachment.cgi?id=138981&action=edit
dmesg output
I found where my kernel is leaking memory (USB audio related) but this hand o
On Tue, 10 Jun 2014 21:33:27 +0200
Daniel Vetter wrote:
> On Tue, Jun 10, 2014 at 7:27 PM, Jesse Barnes
> wrote:
> > Yes, that's what I do below... I even added it to the changelog:
> > http://patchwork.freedesktop.org/patch/27223/
> >
> > Did you miss the later hunk in intel_display.c?
> >
> >
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #6 from Alex Deucher ---
Did you build the necessary firmware into your kernel image when you built the
driver into the kernel? I don't think this has anything to do with the
handoff.
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #7 from joshua.r.marshall.1991 at gmail.com ---
I'm not aware of anything involving firmware for building the modules
separately or part of the main kernel. I follow the same build procedure for
both.
--
You are receiving this mail b
https://bugzilla.kernel.org/show_bug.cgi?id=77471
--- Comment #8 from Alex Deucher ---
You need to build the firmware into the kernel image if you build the driver
into the kernel otherwise, the driver will not be able to fetch the firmware.
What you may be seeing is the kernel firmware loading
https://bugzilla.kernel.org/show_bug.cgi?id=77471
joshua.r.marshall.1991 at gmail.com changed:
What|Removed |Added
Resolution|--- |INVALID
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/a83f5744/attachment.html>
dri-devel/attachments/20140610/4ff29e73/attachment.html>
archives/dri-devel/attachments/20140610/04b2900f/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140610/08c8a861/attachment.html>
archives/dri-devel/attachments/20140610/714ebed7/attachment.html>
If there is no panel node in DT and instead display timings are provided
directly in FIMD node, there is no panel object created and ctx->panel
becomes NULL. However during Exynos DRM initialization
drm_helper_hpd_irq_event() is called, which in turns calls
exynos_dpi_detect(), which dereferences c
On Mon, Jun 9, 2014 at 5:41 PM, Jani Nikula
wrote:
>
> Patrik, Alan -
>
> Should you add a MAINTAINERS entry for gma500 with one or both of you as
> maintainers? What's the status?
>
> BR,
> Jani.
Hi Jani
Adding an entry would make people think that I have time to spend on gma500
development or
> Adding an entry would make people think that I have time to spend on gma500
> development or is in some way responsible for it. At the moment, that is sadly
> not the case. I have a few things on my todo-list which I intend to fix but
> after that I would much rather work on something more produc
88 matches
Mail list logo