2015-02-07 19:49 GMT+09:00 Inki Dae :
> This patch sets display clock correctly.
>
> If Display clock isn't set correctly then you would find below messages
> and Display controller doesn't work correctly since a patch[1]
>
>exynos-drm: No connectors reported connected with modes
>[drm] Can
On 05/19/2015 09:53 PM, Arnd Bergmann wrote:
> The recently added iommu code in the nouveau driver fails to build
> when the IOMMU support is disabled:
>
> drivers/gpu/drm/nouveau/nouveau_platform.c: In function
> 'nouveau_platform_probe_iommu':
> drivers/gpu/drm/nouveau/nouveau_platform.c:113:41:
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/23cda902/attachment.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/20150520/e5478e25/attachment.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/20150520/841c6e1c/attachment.html>
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/20150520/b84357e0/attachment.html>
Hi,
with 4.1-rc display-port on my Tahiti XT stopped working. I used the
firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
today.
Note: the display is an Asus PB278, it used to have problems with
display port negotiation, but those disappeared like a year ago.
% grep radeon /t
On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
wrote:
> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>> Re-pinging Marteen on an email address that still exists :P
>>
>> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot
>> wrote:
>>> On Sun, Mar 15, 2015 at 5:41 PM, Alexandre Courbot
>
On 05/19/2015 09:00 PM, Daniel Vetter wrote:
> On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
>> On 05/19/2015 03:04 PM, Daniel Vetter wrote:
>>> On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
+void drm_bridge_post_disable(struct drm_bridge *bridge)
+{
This patchset proposes to introduce a "staging" module option to dynamically
enable features (mostly ioctls) that are merged but may be refined before
they are declared "stable". The second patch illustrates the use of this
staging option with the SET_TILING ioctl, which can be used to specify the
Add a module option allowing to enable staging/unstable APIs. This will
allow us to experiment freely with experimental APIs for a while before
setting them in stone.
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_drm.c | 18 ++
drm/nouveau/uapi/drm/nouveau_drm
From: Ari Hirvonen
Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
mode for imported dma-bufs. This ioctl is staging for now.
Signed-off-by: Ari Hirvonen
[acourbot at nvidia.com: carry upstream, fix style]
Signed-off-by: Alexandre Courbot
---
drm/nouveau/nouveau_drm.c | 1
The lack of IOMMU API support can make nouveau_platform_probe_iommu()
fail to compile because struct iommu_ops is then empty. Fix this by
skipping IOMMU probe in that case - lack of IOMMU on platform devices
is sub-optimal, but is not an error.
Signed-off-by: Alexandre Courbot
---
This is an alte
On Wed, May 20, 2015 at 10:49:38AM +0530, Archit Taneja wrote:
> On 05/19/2015 09:00 PM, Daniel Vetter wrote:
> >On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
> >>On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> >>>On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote:
>
On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
>
>
> On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
>> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
>>> Cc: dri-devel at lists.freedesktop.org
>>> Signed-off-by: Sonika Jindal
>>> ---
>>> Documentation/DocBook/drm.tmpl |7 +--
On 20/05/15 08:11, Alexandre Courbot wrote:
> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst
> wrote:
>> Op 15-05-15 om 09:11 schreef Alexandre Courbot:
>>> Re-pinging Marteen on an email address that still exists :P
>>>
>>> On Wed, Apr 22, 2015 at 6:08 PM, Alexandre Courbot
>>> wrote:
On Wednesday 20 May 2015 15:10:24 Alexandre Courbot wrote:
> The lack of IOMMU API support can make nouveau_platform_probe_iommu()
> fail to compile because struct iommu_ops is then empty. Fix this by
> skipping IOMMU probe in that case - lack of IOMMU on platform devices
> is sub-optimal, but is n
On Tue, 19 May 2015, Sergey Senozhatsky wrote:
> drm_property_unreference_blob_locked() is static and unused,
> drop it.
http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at
mail.gmail.com
>
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/gpu/drm/drm_crtc.c | 19 ---
On Wed, 20 May 2015, Arnd Bergmann wrote:
> This function was added recently but never used, and causes
> a compile warning:
>
> drivers/gpu/drm/drm_crtc.c:4324:13: warning:
> 'drm_property_unreference_blob_locked' defined but not used
> [-Wunused-function]
>
> Removing that function avoids the
On 05/20/2015 12:05 PM, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 10:49:38AM +0530, Archit Taneja wrote:
>> On 05/19/2015 09:00 PM, Daniel Vetter wrote:
>>> On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote:
On 05/19/2015 03:04 PM, Daniel Vetter wrote:
> On Tue, May 19,
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also there is a variant to find optional gpios that returns NULL if
there is no
On Wed, May 20, 2015 at 4:37 AM, Joe Perches wrote:
> Use the generic mechanism to declare a bitmap instead of unsigned long.
>
> It seems that "struct kfd_process.allocated_queue_bitmap" is unused.
> Maybe it could be deleted instead.
>
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/amd/a
On Wed, May 20, 2015 at 12:43:40PM +0530, Archit Taneja wrote:
> Where do you think drm_bridge documentation fits? I was considering putting
> it under 'KMS initialization and setup', while pointing out that it isn't
> exactly a drm_mode_object entity like crtcs or encoders etc.
Since drm_bridge i
On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
>
>
> On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
>> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
>>> Cc: dri-devel at lists.freedesktop.org
>>> Signed-off-by: Sonika Jindal
>>> ---
>>> Documentation/DocBook/drm.tmpl |7 +--
Am 19.05.2015 um 13:41 schrieb Jani Nikula:
>
> +intel-gfx
> For brand new platforms you should be running drm-intel-nightly branch
> from http://cgit.freedesktop.org/drm-intel.
Tested now, drm-intel-nightly solves the problem.
Thanks a lot
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manag
On Wed, 20 May 2015, Rainer Koenig wrote:
> Am 19.05.2015 um 13:41 schrieb Jani Nikula:
>>
>> +intel-gfx
>
>> For brand new platforms you should be running drm-intel-nightly branch
>> from http://cgit.freedesktop.org/drm-intel.
>
> Tested now, drm-intel-nightly solves the problem.
>
> Thanks a lo
In
commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
Author: Daniel Vetter
Date: Thu Jan 22 16:36:23 2015 +0100
drm/atomic-helpers: Recover full cursor plane behaviour
we've added a hack to atomic helpers to never to vblank waits for
cursor updates through the legacy apis since that's what
On Wed, 20 May 2015 10:36:32 +0200
Daniel Vetter wrote:
> In
>
> commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
> Author: Daniel Vetter
> Date: Thu Jan 22 16:36:23 2015 +0100
>
> drm/atomic-helpers: Recover full cursor plane behaviour
>
> we've added a hack to atomic helpers to never t
This patch adds the bus_format field to the HSD100PXN1 panel structure.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 63dea57..28d7360 10
Hi Daniel,
thank you for the comments.
Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
[...]
> > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned
> > int *depth,
> > break;
> > case DRM_FORMAT_RGB565:
> > case DRM_FORMAT_BGR565:
> >
Am Dienstag, den 19.05.2015, 18:58 +0200 schrieb Daniel Vetter:
[...]
> > @@ -86,13 +93,36 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane,
> > struct drm_framebuffer *fb,
> > eba = cma_obj->paddr + fb->offsets[0] +
> > fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
> >
truct iommu_ops as empty if IOMMU_API is deselected so you'll
probably get compiler errors unless you actually preprocess the code
out.
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/20150520/b2177925/attachment.sig>
On (05/20/15 10:09), Jani Nikula wrote:
> > drm_property_unreference_blob_locked() is static and unused,
> > drop it.
>
> http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at
> mail.gmail.com
>
oh, ok. thanks.
-ss
> >
> > Signed-off-by: Sergey Senozhatsky
> > -
On Wednesday 20 May 2015 13:32:33 Thierry Reding wrote:
>
> Since these are all static functions, perhaps an "if (IS_ENABLED(...))"
> would work here? That way you'd get compile coverage of the code in all
> cases.
I had the same thought at first.
> But perhaps that doesn't work for IOMMU. I hav
On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> Hi Daniel,
>
> thank you for the comments.
>
> Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> [...]
> > > @@ -5198,11 +5206,15 @@ void drm_fb_get_bpp_depth(uint32_t format,
> > > unsigned int *depth,
> > >
drm_fb_get_bpp_depth is to be used by legacy drivers only. None of those
support multi-planar formats, so add a WARN_ON if this function is ever
called with a format with more than one plane.
Suggested-by: Daniel Vetter
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/drm_crtc.c | 6 ++
1 f
Dave -
My Haswell oopses when power cycling an MST enabled Dell P2415Q display.
I haven't been able to get a picture on screen when either the sink or
the source has MST enabled, but one thing at a time...
Below is the only snippet of dmesg I've been able to squeeze out at this
time, maybe it g
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/7d4213a4/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/8f7bd80c/attachment.html>
On Wed, May 20, 2015 at 01:19:34PM +0530, Jindal, Sonika wrote:
>
>
> On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
> >
> >
> > On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
> >> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
> >>> Cc: dri-devel at lists.freedesktop.org
> >>> Signed-
y help is appreciated. Thank you!
pstglia
ps: It's working nice with r600g driver/hardware
--
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/20150520/9be9c29e/attachment.html>
On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > Hi Daniel,
> >
> > thank you for the comments.
> >
> > Am Dienstag, den 19.05.2015, 18:52 +0200 schrieb Daniel Vetter:
> > [...]
> > > > @@ -5198,11 +5206,15 @@ void
On Wed, May 20, 2015 at 9:01 PM, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 13:32:33 Thierry Reding wrote:
>>
>> Since these are all static functions, perhaps an "if (IS_ENABLED(...))"
>> would work here? That way you'd get compile coverage of the code in all
>> cases.
>
> I had the same thou
2100 (KANIBI)
- AMD R7 240 (OLAND)
--
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/20150520/92cb0a96/attachment.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/20150520/9076ab82/attachment.html>
From: Gustavo Padovan
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 +--
1 file changed, 1 in
From: Gustavo Padovan
ideal_clk is the divisor in an operation to find the clock divider so
it can't never be zero or we will end up with a division by zero error.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
Unfortunately old userspace didn't clear this properly, but since
we've added fb modifiers that's fixed. Checking properly that unused
fields is important for abi extensions, and just right now there's a
bunch of discussions going on about how exactly the additional aux
planes for render compressio
Am Mittwoch, den 20.05.2015, 17:07 +0300 schrieb Ville Syrjälä:
> On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> > On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > > Hi Daniel,
> > >
> > > thank you for the comments.
> > >
> > > Am Dienstag, den 19.05.2015, 1
The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
This looks like a typo that is now fixed.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_p
On Wed, May 20, 2015 at 04:54:01PM +0200, Philipp Zabel wrote:
> Am Mittwoch, den 20.05.2015, 17:07 +0300 schrieb Ville Syrjälä:
> > On Wed, May 20, 2015 at 02:58:53PM +0200, Daniel Vetter wrote:
> > > On Wed, May 20, 2015 at 12:50:35PM +0200, Philipp Zabel wrote:
> > > > Hi Daniel,
> > > >
> >
Using fb modifier flag, support NV12MT format in MDP4.
v2:
- rework the modifier's description [Daniel Vetter's comment]
- drop .set_mode_config() callback [Rob Clark's comment]
v3:
- change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
Signed-off-by: Rob Clark
---
drivers/gpu/dr
On Wed, May 20, 2015 at 11:15 AM, Rob Clark wrote:
> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage to NV12 [
On Wed, May 20, 2015 at 10:57 AM, Stephane Viau wrote:
> The index of ->planes[] array (3rd parameter) cannot be equal to MAX_PLANE.
> This looks like a typo that is now fixed.
>
> Signed-off-by: Stephane Viau
Acked-by: Rob Clark
Dave, since it looks like you've merged my earlier fixes pull bu
On Wed, May 20, 2015 at 11:15:27AM -0400, Rob Clark wrote:
> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage t
Hi Rob,
> Using fb modifier flag, support NV12MT format in MDP4.
>
> v2:
> - rework the modifier's description [Daniel Vetter's comment]
> - drop .set_mode_config() callback [Rob Clark's comment]
> v3:
> - change VENDOR's name and restrict usage to NV12 [pointed by Daniel]
>
> Signed-off-by: Rob C
On Tue, May 19, 2015 at 6:03 PM, Malte Schröder wrote:
> Hi,
> with 4.1-rc display-port on my Tahiti XT stopped working. I used the
> firmware from http://people.freedesktop.org/~agd5f/radeon_ucode/ as of
> today.
> Note: the display is an Asus PB278, it used to have problems with
> display port
On Thu, May 7, 2015 at 12:49 PM, Shobhit Kumar wrote:
> On Wed, May 6, 2015 at 5:44 PM, Thierry Reding
> wrote:
>> On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
>>> The Crystalcove PMIC controls PWM signals and this driver exports that
>>
>> You say signal_s_ here, but you only
* Robert Bragg wrote:
> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
Hmm,
I wonder if that really 'fixes' anything, because now we get a WARN_ON
which is immediately followed by a div-by-zero. Furthermore we then
still use the result of that operation as input for a hw register (bad
idea?)
I thought of something like this. Change fimd_calc_clkdiv() to return a
Hi,
On 20 May 2015 at 17:04, Tobias Jakobi wrote:
> Hmm,
>
> I wonder if that really 'fixes' anything, because now we get a WARN_ON which
> is immediately followed by a div-by-zero. Furthermore we then still use the
> result of that operation as input for a hw register (bad idea?)
>
> I thought o
On Wed, May 20, 2015 at 11:32 AM, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 11:15:27AM -0400, Rob Clark wrote:
>> Using fb modifier flag, support NV12MT format in MDP4.
>>
>> v2:
>> - rework the modifier's description [Daniel Vetter's comment]
>> - drop .set_mode_config() callback [Rob Clark'
On 2015-05-20 18:14, Daniel Stone wrote:
> Hi,
>
> On 20 May 2015 at 17:04, Tobias Jakobi
> wrote:
>> Hmm,
>>
>> I wonder if that really 'fixes' anything, because now we get a WARN_ON
>> which
>> is immediately followed by a div-by-zero. Furthermore we then still
>> use the
>> result of that
On Tue, May 19, 2015 at 9:37 PM, Joe Perches wrote:
> Use the generic mechanism to declare a bitmap instead of unsigned long.
>
> Signed-off-by: Joe Perches
Applied to my -next tree. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On 2015-05-20 16:33, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When mode's vrefresh is zero we should ask DRM core to calculate
> vrefresh
> for us so we can get the correct value instead of relying on fixed
> value
> defined in a macro.
>
> Signed-off-by: Gustavo Padovan
> ---
> dr
Hi,
On 20 May 2015 at 17:31, Tobias Jakobi wrote:
> On 2015-05-20 18:14, Daniel Stone wrote:
>> On 20 May 2015 at 17:04, Tobias Jakobi
>> wrote:
>>> I wonder if that really 'fixes' anything, because now we get a WARN_ON
>>> which
>>> is immediately followed by a div-by-zero. Furthermore we then
Hi,
On 20 May 2015 at 17:58, Tobias Jakobi wrote:
> On 2015-05-20 16:33, Gustavo Padovan wrote:
>> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
>> for us so we can get the correct value instead of relying on fixed value
>> defined in a macro.
>>
>> Signed-off-by: Gust
From: Gustavo Padovan
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.
Suggested-by: Daniel Stone
Signed-off-by: Gustavo
Hi,
2015-05-20 Daniel Stone :
> Hi,
>
> On 20 May 2015 at 17:58, Tobias Jakobi
> wrote:
> > On 2015-05-20 16:33, Gustavo Padovan wrote:
> >> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> >> for us so we can get the correct value instead of relying on fixed value
>
Kernel driver in use: radeon
---
--
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/20150520/e644af9e/attachment.html>
Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> for us so we can get the correct value instead of relying on fixed value
> defined in a macro. But if vrefresh is still zero we should fail the
> update.
Even with this w
Hello Maarten Lankhorst,
This is a semi-automatic email about new static checker warnings.
The patch 32975e952e85: "drm/atomic: add commit_planes_on_crtc
helper" from May 19, 2015, leads to the following Smatch complaint:
drivers/gpu/drm/drm_atomic_helper.c:1244
drm_atomic_helper_commit_planes
Some newer chips have trouble coming up, and we get bad MMIO reads from
them, like 0xbadf100. This ends up translating into crazy amounts of
VRAM, which destroys all sorts of other logic down the line. Instead,
fail device init.
Signed-off-by: Ilia Mirkin
Cc: stable at kernel.org
---
drm/nouveau
2015-05-20 Tobias Jakobi :
> Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> > for us so we can get the correct value instead of relying on fixed value
> > defined in a macro. But if vrefresh is still zero we sh
From: Gustavo Padovan
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.
Suggested-by: Daniel Stone
Signed-off-by: Gustavo
Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
> for us so we can get the correct value instead of relying on fixed value
> defined in a macro. But if vrefresh is still zero we should fail the
> update.
>
> Suggested-b
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/2bc4535e/attachment.html>
Someone will have to trudge through a mmiotrace and figure out what
magic bit we need to set in order to bring it out of deep sleep. Or
perhaps NVIDIA will graciously tell us, which they eventually did for
GK104/GK106 (but their instructions appear to be insufficient for at
least some GK106's).
Bu
\
> AUX_SW_RX_PARTIAL_BYTE | \
> AUX_SW_NON_AUX_MODE |\
> - AUX_SW_RX_MIN_COUNT_VIOL | \
> AUX_SW_RX_INVALID_STOP | \
> AUX_SW_RX_SYNC_INVALID_L | \
> AUX_SW_RX_SYNC_INVALID_H | \
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-error-flag-checking-in-native-aux-pat.patch
Type: text/x-patch
Size: 1055 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/36501357/attachment.bin>
native-aux-pat.patch
Type: text/x-patch
Size: 1055 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/77b466de/attachment.bin>
Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they
do not have a sink device in them to respond to any AUX traffic. When
probing these dongles over the DDC, sometimes they will NAK the first attempt
even though the transaction is valid and they support the DDC protocol. The
re.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150520/ea53b3b5/attachment-0001.sig>
Any idea on how to solve the problem. other than just reporting it?
But for now this adds a helpful error message... you may add my R-b.
On 20.05.2015 22:01, Ilia Mirkin wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translati
I'm not sure where, exactly, but somewhere in here we must be relying on
an implicit include.
drivers/gpu/drm/msm/dsi/dsi_host.c: In function âdsi_host_init_panel_gpiosâ:
drivers/gpu/drm/msm/dsi/dsi_host.c:1356:2: error: implicit declaration of
function âdevm_gpiod_getâ [-Werror=implicit-
84 matches
Mail list logo
