On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote:
> (On a side note I believe treating the pitch and size arguments as inputs
> could be a worthwhile extension to the API, but given that we haven't
> rejected incorrect values in the past we're pretty much stuck).
The bigger
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/17a37f8b/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141106/0bc077c0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=87791
--- Comment #4 from Michel Dänzer ---
(In reply to aCaB from comment #3)
> I understand mesa may be sending crap to the kernel space but that doesn't
> sound like a good reason to deref a NULL.
AFAICT that should be fixed by the changes to
Hi,
On 2014ë
11ì 05ì¼ 02:18, Matwey V. Kornilov wrote:
> Hi,
>
> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
> set to 'y'.
> The issue here is that the platform probe/init goes to infinite
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/20141106/bbda3936/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9b380d7c/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141106/6fdebcaf/attachment-0001.html>
On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
>> Hi,
>>
>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
>> of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
>> set to 'y'.
>>
On 11/06/2014 04:32 AM, Alexandre Courbot wrote:
> On Thu, Oct 23, 2014 at 6:45 PM, Andrzej Hajda wrote:
>> On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
>>> Add the new flags argument to calls of (devm_)gpiod_get*() and
>>> remove any direction setting code afterwards.
>>>
>>> Currently both
On 11/06/2014 07:23 AM, Inki Dae wrote:
> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
>>> Hi,
>>>
>>> I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
>>> of course, but I run multi-platform kernel
On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
> On 11/06/2014 07:23 AM, Inki Dae wrote:
>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
>>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
Hi,
I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have
d, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/8bb179e5/attachment-0001.sig>
d, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3d0d3d1b/attachment.sig>
deletions(-)
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9d0662d2/attachment.sig>
pplication/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/91983c87/attachment.sig>
> create mode 100644
> Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<
On 2014ë
11ì 06ì¼ 17:49, Matwey V. Kornilov wrote:
> 2014-11-06 11:45 GMT+03:00 Inki Dae :
>> On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
>>> On 11/06/2014 07:23 AM, Inki Dae wrote:
On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 09:18:46PM +0400,
Hi,
On last next (next-20141104, next-20141105) booting locks after
initializing Exynos DRM (Trats2 board):
[2.028283] [drm] Initialized drm 1.1.0 20060810
[ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
[ 240.510825] Not tainted 3.18.0-rc3-next-20141105 #794
p://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b68612f2/attachment.sig>
From: Thierry Reding
Various panels were missing the .bpc field which encodes the number of
bits per color. Not every display driver relies on this value, but since
the panels can be used with any display engine it must be specified so
that if a driver knows how to
because this currently causes all sorts of weirdness when
booting a multi-platform kernel on non-Exynos boards. Probably the
easiest for now would be to add some soc_is_exynos*() check at the very
beginning of exynos_drm_init().
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/98dcd330/attachment.sig>
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
> via a Docking Station (MST).
>
> During Bootup all three displays work, even when X is started.
> However, if the laptop display is turned off once (either because of
>
Hi all,
After a few atomic irc chats I've shockingly realized that I've completely
ignored dpms handling in my helper series. Oops.
But there's a few things which are seriously wrong with DPMS, so I've
figured I'll start a discussion about them first - converting to atomic
looks like a good time
nt as
well. But instead of passing around void * and type IDs as in the
interface tracker it could deal with real objects for proper type-
safety.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/44968ab0/attachment-0001.sig>
On 2014ë
11ì 06ì¼ 18:29, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 03:23:27PM +0900, Inki Dae wrote:
>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
>>> On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
Hi,
I run 3.18-rc3 kernel on BeagleBone
On Thu, Nov 06, 2014 at 05:35:40PM +0800, Kuankuan.Yang wrote:
> I'm working on Designware hdmi-audio, also add it as a standard ALSA device.
> Before I saw this email, I also planed to submit my patchs to upsteam.
> I'm very grateful if you can email those patchs to us.
I've attached the set of
ifferently if at all possible.
try_module_get() is the only way I know of that ensures that the code of
a module stays around. Everytime we give out a new reference to a record
we also need to increment the module reference count accordingly to make
sure the underlying code doesn't go away all of a sudden.
I guess that's not entirely accurate. The module reference count doesn't
have to be increment for every record reference, it only needs to track
each record. So the try_module_get() and module_put() could move into
registry_add() and registry_get(), respectively. But the ->owner field
would still be in the record structure.
Would that alleviate your concerns?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/1b589fb1/attachment.sig>
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: Inki Dae
---
Exynos DSI driver uses DSI bus attach/detach callbacks to implement
panel hotplug mechanism. The patch moves panel attachment code
from .detect callback to DSI bus callbacks. It makes the code
simpler and more straightforward.
The patch removes also redundant and lock unprotected dpms_off call
On 06.11.2014 11:32, Inki Dae wrote:
> This patch resolves temporarily infinite loop issue incurred
> when Exynos drm driver is enabled and multi-platform kernel
> is used by registering Exynos drm device object only in case
> of Exynos SoC. So this patch will be replaced with more generic
> way
On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
> On 06.11.2014 11:32, Inki Dae wrote:
>> This patch resolves temporarily infinite loop issue incurred
>> when Exynos drm driver is enabled and multi-platform kernel
>> is used by registering Exynos drm device object only in case
>> of
Hi Inki,
Could you please give a review to this series?
Thanks.
Gustavo
2014-10-31 Gustavo Padovan :
> From: Gustavo Padovan
>
> It is not even used in this header anymore.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 1 -
> 1 file
Hi Gustavo,
On 2014ë
11ì 06ì¼ 21:38, Gustavo Padovan wrote:
>
> Hi Inki,
>
> Could you please give a review to this series?
It looks good to me. This patch series is just cleanup but not test so I
will merge them next week after testing if there is no any comment.
Thanks,
Inki Dae
>
>
On Thu, 06 Nov 2014, Arnd Hannemann wrote:
> Hi,
>
> thanks for your quick response.
>
> Am 06.11.2014 um 10:39 schrieb Jani Nikula:
>> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>>> Hi,
>>>
>>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>>> via a Docking Station
On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote:
> On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
> > On 06.11.2014 11:32, Inki Dae wrote:
> >> This patch resolves temporarily infinite loop issue incurred
> >> when Exynos drm driver is enabled and multi-platform kernel
> >> is used by
a DSI bus.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/09098297/attachment.sig>
On 11/06/2014 02:18 PM, Thierry Reding wrote:
> On Thu, Nov 06, 2014 at 12:35:48PM +0100, Andrzej Hajda wrote:
>> Exynos DSI driver uses DSI bus attach/detach callbacks to implement
>> panel hotplug mechanism. The patch moves panel attachment code
>> from .detect callback to DSI bus callbacks. It
On 2014ë
11ì 06ì¼ 22:00, Krzysztof Kozlowski wrote:
> On czw, 2014-11-06 at 21:32 +0900, Inki Dae wrote:
>> On 2014ë
11ì 06ì¼ 21:11, Krzysztof KozÅowski wrote:
>>> On 06.11.2014 11:32, Inki Dae wrote:
This patch resolves temporarily infinite loop issue incurred
when Exynos drm
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/b1634317/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/5dcde002/attachment.html>
Hi Inki,
With all respect,
On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite
loop issue incurred
> when Exyno drm driver is enabled but all kms drivers
> are disabled on Exynos board by returning -EPROBE_DEFER
> only in case that there is kms device registered.
>
I believe
On 06/11/14 15:44, Emil Velikov wrote:
> Hi Inki,
>
> With all respect,
>
> On 06/11/14 14:10, Inki Dae wrote:> This patch resovles the infinite
> loop issue incurred
>> when Exyno drm driver is enabled but all kms drivers
>> are disabled on Exynos board by returning -EPROBE_DEFER
>> only in
From: Thierry Reding
This second version addresses review comments from before. A new patch
is added that removes a redundant call to drm_gem_free_mmap_offset() in
the CMA GEM helpers.
Below is the cover letter from the first version for more background in
case anybody
From: Thierry Reding
While at it, adjust the drm_gem_handle_create() function declaration to
be more consistent with other functions in the file.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_gem.c | 11 +--
1 file changed, 5
From: Thierry Reding
Use spaces consistently for indentation in the memory-management
section.
Acked-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 268 -
1 file changed, 134 insertions(+), 134
From: Thierry Reding
Most of the functions already have the beginnings of kerneldoc comments
but are using the wrong opening marker. Use the correct opening marker
and flesh out the comments so that they can be integrated with the DRM
DocBook document.
Signed-off-by: Thierry
From: Thierry Reding
This function is similar to drm_gem_cma_dumb_create() but targetted at
kernel internal users so that they can override the pitch and size
requirements of the dumb buffer.
It is important to make this difference because the IOCTL says that the
pitch and
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible
From: Thierry Reding
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags fields are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size.
Drivers must not treat these values as possible
From: Thierry Reding
Some drivers treat the pitch and size fields as inputs and will use them
as minima provided by userspace so that they are only overwritten if the
minimal requirements of the driver exceed them.
This can cause strange behaviour when applications don't
From: Thierry Reding
drm_gem_object_release() called later in the drm_gem_cma_free_object()
function already calls this, so there's no need to do this explicitly.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_gem_cma_helper.c | 2 --
1 file changed, 2 deletions(-)
On Thu, Nov 06, 2014 at 07:26:16PM +0800, Andy Yan wrote:
> From: ykk
We need a "real" name here, sorry.
>
> dw-hdmi is under drm/bridge, so it should be the bridge mode.
> hange off the encoder to dw_hdmi-imx.c, keep the connector &
> birdge in dw_hdmi.c
>
> Signed-off-by: ykk
Same here.
From: Thierry Reding
The DRM driver's ->load() implementation didn't do a good job (no job at
all really) cleaning up on failure. Fix that by undoing any prior setup
when an error occurs. This requires a bit of rework to make it possible
to clean up fbdev midway.
This was
From: Thierry Reding
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display controllers to it. The display controllers
can then scan out non-contiguous buffers by mapping them through the
IOMMU.
Signed-off-by: Thierry Reding
From: Thierry Reding
dma_free_writecombine() must not be called on a buffer that couldn't be
allocated. Check for a valid virtual address before attempting to free
the memory to avoid a crash.
Reported-by: Sean Paul
Signed-off-by: Thierry Reding
---
on-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fcf157e9/attachment.sig>
le
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/f280695e/attachment-0001.sig>
On Thu, 06 Nov 2014 16:08:56 +0900
Michel Dänzer wrote:
> On 06.11.2014 03:06, Frederic Plourde wrote:
> > Many features, like animations, hardly depend on page flip timestamps
> > to work properly, but some DRM drivers do not correctly support page flip
> > timestamps (or not at all) and in
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 723999d73744..fed0c8d60748 100644
---
This patch adds support for the Innolux G121I1-L01 12.1" TFT LCD panel
to the simple-panel driver.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete horizontal
This patch adds support for the Hitachi TX23D38VM0CAA 9" WVGA TFT LCD panel
to the simple-panel driver.
This panel is connected via LVDS and uses the data enable signal for
timing. Since HSYNC/VSYNC are ignored, the split between sync length and
porches is arbitrary, as long as the complete
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/3930670e/attachment.html>
On Sun, Nov 02, 2014 at 02:19:26PM +0100, Daniel Vetter wrote:
> No helper function to do it all yet provided since no driver has
> support for driver core fences yet. Which we'd need to make the
> implementation really generic.
>
> v2: Clarify async howto a bit per the discussion With Rob Clark.
On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> Currently there is no way to implement async flips using atomic, that
> essentially requires us to be able to cancel pending requests
> mid-flight.
>
> To be able to do that (and I guess we want this since vblank synced
> updates
On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> The atomic users and helpers assume that there is always a obj->state
> structure around. Which means drivers need to somehow create that at
> driver load time. Also it should obviously reset hardware state, so
> needs to be reset
On Sun, Nov 02, 2014 at 02:19:29PM +0100, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 20
On Sun, Nov 02, 2014 at 02:19:30PM +0100, Daniel Vetter wrote:
> So my original plan was that the drm core refcounts framebuffers like
> with the legacy ioctls. But that doesn't work for a bunch of reasons:
>
> - State objects might live longer than until the next fb change
> happens for a
On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +retry:
> > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > + if (IS_ERR(crtc_state)) {
> > +
Hi Russell,
On Thursday 06 November 2014 00:54:51 Russell King - ARM Linux wrote:
> On Wed, Nov 05, 2014 at 08:47:07PM +0200, Laurent Pinchart wrote:
> > (On a side note I believe treating the pitch and size arguments as inputs
> > could be a worthwhile extension to the API, but given that we
On Wed, Nov 5, 2014 at 4:44 PM, Daniel Vetter wrote:
> I've applied all the other nits, replies to the more interesting bits
> below.
>
> On Wed, Nov 05, 2014 at 01:53:48PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:23PM +0100, Daniel Vetter wrote:
>> > + if (new_encoder !=
On Wed, Nov 5, 2014 at 5:01 PM, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 02:48:48PM -0500, Sean Paul wrote:
>> > + if (!crtc && crtc != set->crtc)
>>
>> I think this should be an ||
>
> Hm. My idea idea was actually something along the lines of
> diff --git
On Thu, Nov 6, 2014 at 1:13 PM, Daniel Vetter wrote:
>
> On Thu, Nov 06, 2014 at 12:43:34PM -0500, Sean Paul wrote:
> > On Sun, Nov 02, 2014 at 02:19:27PM +0100, Daniel Vetter wrote:
> > > + state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > > +retry:
> > > + crtc_state =
On Thu, Nov 06, 2014 at 04:57:14PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The DRM driver's ->load() implementation didn't do a good job (no job at
> all really) cleaning up on failure. Fix that by undoing any prior setup
> when an error occurs. This requires a bit of rework to
On Thu, Nov 6, 2014 at 10:57 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> dma_free_writecombine() must not be called on a buffer that couldn't be
> allocated. Check for a valid virtual address before attempting to free
> the memory to avoid a crash.
>
> Reported-by: Sean Paul
nit: I'd
The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.
Finally the destroy/duplicate_state functions are an awful
On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
> > The atomic users and helpers assume that there is always a obj->state
> > structure around. Which means drivers need to somehow create that at
> > driver load time. Also
In all cases the text requires that new drivers are converted to the
atomic interfaces.
v2: Add overview for state handling.
v3: Review from Sean: Some spelling fixes and drop the misguided
hunk to remove rgba from the plane helpers compat list.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
On Thu, Nov 6, 2014 at 2:57 PM, Daniel Vetter wrote:
> On Thu, Nov 06, 2014 at 12:43:43PM -0500, Sean Paul wrote:
>> On Sun, Nov 02, 2014 at 02:19:28PM +0100, Daniel Vetter wrote:
>> > The atomic users and helpers assume that there is always a obj->state
>> > structure around. Which means drivers
On Thu, Nov 6, 2014 at 3:00 PM, Daniel Vetter wrote:
> In all cases the text requires that new drivers are converted to the
> atomic interfaces.
>
> v2: Add overview for state handling.
>
> v3: Review from Sean: Some spelling fixes and drop the misguided
> hunk to remove rgba from the plane
On Thu, Nov 06, 2014 at 04:49:16PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Most of the functions already have the beginnings of kerneldoc comments
> but are using the wrong opening marker. Use the correct opening marker
> and flesh out the comments so that they can be integrated
On Thu, Nov 06, 2014 at 04:49:21PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> drm_gem_object_release() called later in the drm_gem_cma_free_object()
> function already calls this, so there's no need to do this explicitly.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Daniel
On Fri, Oct 31, 2014 at 11:07 AM, Ganesan, Aravind
wrote:
> Resend the patch-set with the same thread-id
> A set of three patches to support adreno 4xx GPUs in msm-drm:
> (1) Updated the a3xx and a4xx header files.
> (2) Handle register offset differences between a3xx and a4xx GPUs.
> (3) Added
On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind
wrote:
> Register offsets have changed between a3xx and a4xx GPUs.
> To be able access these registers in common code, we create
> a lookup table, and set of read-write APIs to access the
> register through the lookup table.
>
> Signed-off-by:
On Fri, Oct 31, 2014 at 11:08 AM, Ganesan, Aravind
wrote:
> Added a4xx GPU support.
>
> Signed-off-by: Aravind Ganesan
> ---
> Resend the patch-set with the same thread-id
> Resend in patch-set format and with dri-devel at lists.freedesktop.org on
> the CC.
> drivers/gpu/drm/msm/Makefile
https://bugzilla.kernel.org/show_bug.cgi?id=87791
--- Comment #5 from aCaB ---
Michel,
Thanks for your pointer and sorry for the late answer.
I'll try harder to find a reproducible case (firefox with some large animation
seems to trigger it some times).
In the meantime, if the lockup is a mesa
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/9ff4143d/attachment.html>
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/20141106/3d1aa9a1/attachment.html>
On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/8d69d5a4/attachment.html>
On Thu, Nov 6, 2014 at 10:49 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
> IOCTL, only the width, height, bpp and flags fields are inputs. The
> caller is not guaranteed to zero out or set handle, pitch and size.
>
On Thu, Nov 6, 2014 at 5:06 PM, Rob Clark wrote:
> On Thu, Nov 6, 2014 at 4:43 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> After a few atomic irc chats I've shockingly realized that I've completely
>> ignored dpms handling in my helper series. Oops.
>>
>> But there's a few things which are
Hi Dave,
A few more radeon fixes for 3.18:
- fix missing crtc unlock in MC setup
- set optimal CE ram config
- use gart rather than vram for DMA IB tests to avoid coherency issues with HDP
- fix a crasher with laptop mode and TDP scripts
The following changes since commit
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141106/fc607b22/attachment.html>
On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter wrote:
>
> Hi all,
>
> After a few atomic irc chats I've shockingly realized that I've completely
> ignored dpms handling in my helper series. Oops.
>
> But there's a few things which are seriously wrong with DPMS, so I've
> figured I'll start a
On Thu, Nov 6, 2014 at 6:29 PM, Daniel Vetter wrote:
>>> Proposal. Add a new boolean ->active to the crtc state, which will track
>>> the dpms state of the crtc. Add a helper to the atomic core functions
>>> which will compute ->active from the state update according to the
>>> proposals for
On Thu, Oct 23, 2014 at 6:46 PM, Andrzej Hajda wrote:
> On 10/23/2014 10:16 AM, Alexandre Courbot wrote:
>> Add the new flags argument to calls of (devm_)gpiod_get*() and
>> remove any direction setting code afterwards.
>>
>> Currently both forms (with or without the flags argument)
>> are valid
2014-11-06 11:45 GMT+03:00 Inki Dae :
> On 2014ë
11ì 06ì¼ 17:03, Andrzej Hajda wrote:
>> On 11/06/2014 07:23 AM, Inki Dae wrote:
>>> On 2014ë
11ì 05ì¼ 23:38, Thierry Reding wrote:
On Tue, Nov 04, 2014 at 09:18:46PM +0400, Matwey V. Kornilov wrote:
> Hi,
>
> I run
Hi,
thanks for your quick response.
Am 06.11.2014 um 10:39 schrieb Jani Nikula:
> On Thu, 06 Nov 2014, Arnd Hannemann wrote:
>> Hi,
>>
>> I have a Thinkpad T440s (Haswell) connected to two additional Monitors
>> via a Docking Station (MST).
>>
>> During Bootup all three displays work, even when
1 - 100 of 115 matches
Mail list logo