On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
> We can't expect userspace to have full support for all HDMI 2.0+
> features. Instead of expecting/waiting for userspace to support
> the new features add a knob, much like the stereo knob, so that
> DRM core will only expose the features
On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote:
> Perform sanity checks so that HDMI 2.0+ modes are not exported to
> drivers or userspace unless asked to.
Why? They're just normal modes, this doesn't make sense. If you want to
filter the aspect ratio stuff, that makes sense, but expos
On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> On 03/22/2017 10:50 PM, Daniel Vetter wrote:
> > It's been around forever, no one bothered to address the FIXME, so I
> > presume it's all fine.
> >
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> > Signed-off-by: Daniel Vetter
On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> > On 03/22/2017 10:50 PM, Daniel Vetter wrote:
> > > It's been around forever, no one bothered to address the FIXME, so I
> > > presume it's all fine.
> > >
> > > Cc:
We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling the irq will disable it
from with the same interrupt as the last pageflip event. If we move the
decision on w
Better subject might be
drm: Use vblank irq shadow for entire flip sequence
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 23/03/17 03:19 AM, Zachary Michaels wrote:
> We were experiencing an infinite loop due to VRAM bos getting added back
> to the VRAM lru on eviction via ttm_bo_mem_force_space,
Can you share more details about what happened? I can imagine that
moving a BO from CPU visible to CPU invisible VRAM w
On 22.03.2017 18:35, Jose Abreu wrote:
> This patch completes CEA table of video modes so that VIC 1-107
> are now available. Use the HDMI 2.0+ flag to signal these are
> modes for HDMI 2.0 onwards.
edid_cea_modes array is used in different contexts, simple extensions of
the array with modes not p
On Wed, 22 Mar 2017, Dylan Baker wrote:
> Quoting Jani Nikula (2017-03-22 01:24:19)
>> Right. That helps avoid many of the issues e.g. Sphinx has with the
>> configuration files being pure python.
>
> Yes, sphinx's configuration files are awful for just that reason.
Of course, for the exact same
Hi, Daniel,
On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
>> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
>>> On 03/22/2017 10:50 PM, Daniel Vetter wrote:
It's been around forever, no one bothered to address
From: Michel Dänzer
Otherwise this can also prevent modesets e.g. for switching VTs, when
multiple monitors with different native resolutions are connected.
The depths must match though, so keep the != test for that.
Also update the DRM_DEBUG output to be slightly more accurate, this
doesn't on
Op 22-03-17 om 22:05 schreef Pandiyan, Dhinakaran:
> On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote:
>> Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan:
>>> From: "Pandiyan, Dhinakaran"
>>>
>>> It is necessary to track states for objects other than connector, crtc
>>> and plane for at
On 22.03.2017 16:19, Sean Paul wrote:
> On Wed, Mar 22, 2017 at 09:36:34AM +0100, Andrzej Hajda wrote:
>> On 21.03.2017 20:58, Sean Paul wrote:
>>> On Thu, Mar 16, 2017 at 02:40:21PM +0100, Andrzej Hajda wrote:
On 10.03.2017 05:32, Sean Paul wrote:
> From: zain wang
>
> There is a
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #3 from Michel Dänzer ---
(In reply to OmegaPhil from comment #2)
> confirmed 7.9 is loaded, the problem is still present.
Does radeon_scanout_flip still spit out both "Invalid argument" and "Device or
resource busy" errors?
> Hmm
On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
> Hi, Daniel,
>
> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
> >> On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas Hellstrom wrote:
> >>> On 03/22/2017 10:50 PM, D
mdp5_interface struct contains data corresponding to a INTF
instance in MDP5 hardware. This sturct is memcpy'd to the
mdp5_encoder struct, and then later to the mdp5_ctl struct.
Instead of copying around interface data, create mdp5_interface
instances in mdp5_init, like how it's done currently don
Add the stuff needed to allow dynamically assigning a mixer to a CRTC.
Since mixers are a resource that can be shared across multiple CRTCs, we
need to maintain a 'hwmixer_to_crtc' map in the global atomic state,
acquire the mdp5_kms.state_lock modeset lock and so on.
The mixer is assigned in the
Create a struct to represent MDP5 Layer Mixer instances. This will
eventually allow us to detach CRTCs from the Layer Mixers, and
generally clean things up a bit.
This is very similar to how hwpipes were previously abstracted away
from drm planes.
Signed-off-by: Archit Taneja
---
drivers/gpu/dr
This patchset enables dynamic assignment of Layer Mixer blocks to CRTCs
in order to support wide resolution modes and planes.
The approach is similar to what was done for decoupling MDP5 planes from
the hwpipes (SSPPs). We go further by letting a CRTC comprise of 2 Layer
Mixers, one to scanout the
We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring
it back to mdp5_plane. We will need this because an mdp5_plane in the
future could comprise of 2 hw pipes. It makes more sense to have a single
lock to protect the registers for the hw pipes used by a plane, rather
than trying
The INTF and CTL used in a display pipeline are going to be maintained as
a part of the CRTC state (i.e, in mdp5_crtc_state).
These entities, however, are currently statically assigned to drm_encoders
(i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we
assign them to the CRTC
The number of Layer Mixers and the downstream blocks (DSPPs and PPs)
connected to each LM can vary with different MDP5 revisions. These
parameters are also static.
Keep the per instance LM data in mdp5_cfg. This will avoid the need
to have macros which identify PP id or DSPP id the LM is connected
PingPong ID for a Layer Mixer is already contained in
mdp5_hw_mixer.
This avoids the need to retrieve PP ID using macros
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 5 ++---
drivers/gpu/drm/msm/
The mdp5_ctl has an 'op_mode' struct which contains info on
the downstream pipeline.
Grouping these params together in a struct doesn't serve much
purpose in the code. Maybe there was a plan to expand this
further that never happened.
Remove the op_mode struct, and place its members directly in
m
Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of
using the LM index.
Like before, the Layer Mixers are assigned statically to the CRTCs.
The hwmixer(s) will later be dynamically assigned to CRTCs.
For now, ignore the hwmixers that can only do WB.
Signed-off-by: Archit Taneja
Things like vblank/err irq masks, mode of operation (command mode or not)
are derivative of the interface and mixer state. Therefore, they need to
be a part of the CRTC state too.
Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check()
func, so that it can be rolled back to a cle
Subclass drm_crtc_state so that we can maintain additional state for
our CRTCs.
Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state.
mdp5_pipeline is a grouping of the HW entities that forms the downstream
pipeline for a particular CRTC. It currently contains pointers to
mdp5_interface
These are a part of CRTC state, it doesn't feel nice to leave them
hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead
wherever it is needed.
We still have some params in mdp5_ctl like start_mask etc which
are derivative of atomic state, and should be rolled back if
a commit fails, but
Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state.
This mixer will be used to generate the right half of the scanout.
With Source Split, a SSPP can now be connected to 2 Layer Mixers, but
has to be at the same blend level (stage #) on both Layer Mixers.
A drm_plane that has a lesser
In the last few commits, we've been adding params to mdp5_crtc_state, and
assigning them in the atomic_check() funcs. Now it's time to actually
start using them.
Remove the duplicated params from the mdp5_crtc struct, and start using
them in the mdp5_crtc code. The majority of the references to th
In order to enable Source Split in HW, we need to add/modify
a few LM register configurations:
- Configure the LM width to be half the mode width, so that
each LM manages one half of the scanout.
- Tell the 'right' LM that it is configured to be the 'right'
LM in source split mode.
- Since we
If the drm_plane has a source width that's greater than the max width
supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe'
to it in mdp5_plane_atomic_check().
TODO: There are a few scenarios where the hwpipe assignments aren't
recommended by HW. For example, an assignment which r
Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter
func takes in only the hwpipe and the parameters that need to be
programmed into the hwpipe registers. All the code that calculates these
parameters is left as is in mdp5_plane_mode_set.
In the future, when we let drm_plane be c
Some of the newer MDP5 versions support Source Split of SSPPs. It is a
feature that allows us to route the output of a hwpipe to 2 Layer
Mixers. This is required to achieve the following use cases:
- Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single
DSI interface doesn't have t
If a CRTC comprises of 2 LMs, it is mandatory to enable border out
and assign it to the base stage.
We had to enable border out also when the base plane wasn't fullscreen.
Club these checks and put them in a separate function called
get_start_stage() that returns the starting stage for assigning p
Now that we have a right hwpipe in mdp5_plane_state, configure it
mdp5_plane_mode_set(). The only parameters that vary between the
left and right hwpipes are the src_w, src_img_w, src_x and crtc_x
as we just even chop the fb into left and right halves.
Add a mdp5_plane_right_pipe() which will be u
Now that our mdp5_planes can consist of 2 hwpipes, update the
blend_setup() code to stage the right hwpipe to the left and
right LMs
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 12
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 12
2 files ch
3D mux is a small block placed after the DSPPs in MDP5. It can merge
2 LM/DSPP outputs and feed it to a single interface.
Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check
will need to be made more specific later when we add Dual DSI
support with source split enabled. In that use cas
Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's
atomic_check path. Assigning the right mixer has some constraints,
i.e, only a few LMs can be paired together. Update mdp5_mixer_assign
to handle these constraints.
Firstly, we need to identify whether we need a right mixer or not.
Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs
and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that
isn't used by our CTL instance anymore.
Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM
instances. The ones that need to be configured are conf
On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
>> Hi, Daniel,
>>
>> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
>>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote:
On Thu, Mar 23, 2017 at 07:22:31AM +0100, Thomas
I realized it was too early to search that in dri-devel last night, I
guess it takes some time to sync.
Now I can see them all :)
On 3/23/2017 12:37 PM, Jose Abreu wrote:
Hi Shashank,
On 22-03-2017 18:57, Sharma, Shashank wrote:
Hi Jose,
I can't find the other patches of this series in dri
On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote:
> Hi Daniel,
>
>
> On 23-03-2017 07:22, Daniel Vetter wrote:
> > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote:
> >> We can't expect userspace to have full support for all HDMI 2.0+
> >> features. Instead of expecting/waitin
Regards
Shashank
On 3/23/2017 10:11 AM, Andrzej Hajda wrote:
On 22.03.2017 18:35, Jose Abreu wrote:
This patch completes CEA table of video modes so that VIC 1-107
are now available. Use the HDMI 2.0+ flag to signal these are
modes for HDMI 2.0 onwards.
edid_cea_modes array is used in differ
On 23.03.2017 12:04, Jose Abreu wrote:
> Hi Andrzej,
>
>
> Thanks for the feedback!
>
> On 23-03-2017 08:11, Andrzej Hajda wrote:
>> On 22.03.2017 18:35, Jose Abreu wrote:
>>> This patch completes CEA table of video modes so that VIC 1-107
>>> are now available. Use the HDMI 2.0+ flag to signal the
On 22 March 2017 at 20:10, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson. It doesn't
>> seem so bad with a quick look and I think I
Hi Michel,
On 23 March 2017 at 08:53, Michel Dänzer wrote:
> Otherwise this can also prevent modesets e.g. for switching VTs, when
> multiple monitors with different native resolutions are connected.
>
> The depths must match though, so keep the != test for that.
>
> Also update the DRM_DEBUG out
From: Colin Ian King
info is being checked to see if it is a null pointer, however, vpgu is
dereferencing info before this check, leading to a potential null
pointer dereference. If info is null, then the error message being
printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
u
On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> >
> >
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
> > > >
On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote:
> From: Colin Ian King
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference. If info is null, then the error message being
>
On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote:
> On 03/23/2017 11:10 AM, Daniel Vetter wrote:
> > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote:
> >> Hi, Daniel,
> >>
> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote:
> >>> On Thu, Mar 23, 2017 at 08:28:32AM +01
On Wed, 22 Mar 2017, "Sharma, Shashank" wrote:
> Thanks for this patch, Jani.
>
> Reviewed-by: Shashank Sharma
And pushed to drm-misc-next, thanks for the review.
BR,
Jani.
>
>
> Regards
> Shashank
> On 3/22/2017 4:33 PM, Jani Nikula wrote:
>> Fix sparse warning:
>>
>> drivers/gpu/drm/drm_scd
On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the s
On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote:
> Hi Michel,
>
> On 23 March 2017 at 08:53, Michel Dänzer wrote:
> > Otherwise this can also prevent modesets e.g. for switching VTs, when
> > multiple monitors with different native resolutions are connected.
> >
> > The depths must m
Hi Ville,
On 21 March 2017 at 18:12, wrote:
> Another iteration of the i915 CCS support. Main change is lifting the
> fb dimensions hsub/vsub alignment restrictions from the core. Without that
> userspace would have to align the fb size be a multiple of 8x16 pixels
> which isn't something they a
The fence allocation needs to be protected by the GPU mutex, otherwise
the fence seqnos of concurrent submits might not match the insertion order
of the jobs in the kernel ring. This breaks the assumption that jobs
complete with monotonically increasing fence seqnos.
Fixes: d9853490176c (drm/etnav
Make sure the GPU lock is taken, so that fence completion order matches
seqno order.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index
On stih407-410 chip family the GDP layers are able to support up to UHD
resolution (3840 x 2160).
Signed-off-by: Vincent Abriou
---
drivers/gpu/drm/sti/sti_gdp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/s
On 23.03.2017 12:35, Jose Abreu wrote:
> Hi Andrzej,
>
>
> On 23-03-2017 11:17, Andrzej Hajda wrote:
>> On 23.03.2017 12:04, Jose Abreu wrote:
>>> Hi Andrzej,
>>>
>>>
>>> Thanks for the feedback!
>>>
>>> On 23-03-2017 08:11, Andrzej Hajda wrote:
On 22.03.2017 18:35, Jose Abreu wrote:
> Thi
https://bugs.freedesktop.org/show_bug.cgi?id=100304
--- Comment #5 from Alex Deucher ---
Created attachment 130399
--> https://bugs.freedesktop.org/attachment.cgi?id=130399&action=edit
possible fix
This should fix the issue.
--
You are receiving this mail because:
You are the assignee for th
Hi Laurent,
On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart
wrote:
> Signed-off-by: Laurent Pinchart
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
> +{
> + struct rcar_du_device *rcdu = vsp->dev;
> + struct platfor
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onw
On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> flag which will signal userspace that this is a HDMI 2.0+ mode. It
> is expected that these new flags will not be exported to userspace
> unless client asks to.
W.r.t.
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1
Regards
Shashank
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes
You guys might wanna use this series, to solve this problem.
https://patchwork.freedesktop.org/series/21773/
Patch 1: completes the CEA modes 1-107
Patch 2: Protects HDMI 1.4 monitors from HDMI 2.0 VICs
Regards
Shashank
On 3/23/2017 1:07 PM, Sharma, Shashank wrote:
Regards
Shashank
On 3/2
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>> wrote:
>>>
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
>>> 1-64).
>>> For any other mode, the VIC filed in A
https://bugs.freedesktop.org/show_bug.cgi?id=100304
--- Comment #6 from Mike Lothian ---
Thanks, that's working great for me
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedeskto
>
> Was userspace maybe performing concurrent CPU access to the BOs in
> question?
As far as I know Julien has demonstrated that this is not the case.
> I hope we can find a better solution.
Understood -- I thought you might not want to take this patch, but I went
ahead and sent it out becaus
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 15:14, Shashank Sharma wrote:
> > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> > For any other mode, the VIC filed in AVI infoframes should be 0.
> > HDMI 2.0 sinks, sup
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #4 from omegap...@startmail.com ---
Just 'Invalid argument' currently.
I just did 10 tests turning the monitor off for just over 30 seconds, and on
turning it back on, the display layout did not break (but I got the usual flip
queue
Hi Dave,
drm-misc-fixes-2017-03-23:
One fbdev regression fix from Michel
Cheers, Daniel
The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:
Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-mi
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #12 from pablow.1...@gmail.com ---
(In reply to Vedran Miletić from comment #11)
> Is this still an issue?
Hi! I no longer have that video card, so no idea if it's still an issue.
--
You are receiving this mail because:
You are the
- Are we going to support resizing BAR when kernel
modesetting is not enabled and we are running in console
under VBIOS control (VESA/VGA)?
No, initial I've tried to resize the PCI BAR during probing without the
help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able
to handle a
Christian,
- Are we going to support resizing BAR when kernel
modesetting is not enabled and we are running in console
under VBIOS control (VESA/VGA)?
- Should we restore PCI configuration if amdgpu
will be unloaded?
- In function amdgpu_resize_bar0():
If resizing for "max" size failed sho
Understood -- I thought you might not want to take this patch, but I
went ahead and sent it out because Christian requested it, and it
seems like he doesn't think VRAM bos should ever evict back to VRAM at
all?
No, I've requested reverting the patch for now because it causes an
obviously and ra
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 15:14, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861
Regards
Shashank
On 3/23/2017 5:52 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:36, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI
Regards
Shashank
On 3/23/2017 5:28 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
1-64).
Regards
Shashank
On 3/23/2017 6:33 PM, Jose Abreu wrote:
Hi Shashank,
On 23-03-2017 16:08, Sharma, Shashank wrote:
Regards
Shashank
On 3/23/2017 5:57 PM, Jose Abreu wrote:
Hi Ville,
On 23-03-2017 15:45, Ville Syrjälä wrote:
On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:
>
> No, I've requested reverting the patch for now because it causes an
> obviously and rather severe problem. If you guys can quickly find how to
> fix it feel free to use that instead.
>
> My mistake! That makes sense. Thanks again.
___
dri-devel mailin
On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/23/2017 5:52 PM, Jose Abreu wrote:
> > Hi Ville,
> >
> >
> > On 23-03-2017 15:36, Ville Syrjälä wrote:
> >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote:
> >>> HDMI 1.4b support
On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 23-03-2017 16:43, Sharma, Shashank wrote:
> > Regards
> >
> > Shashank
> >
> >
> > On 3/23/2017 6:33 PM, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:08, Sharma, Shashank wrote:
> >>> Regard
Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker wrote:
>
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
Sure, but if it's easier to get right (which I'm asserting it is),
https://bugs.freedesktop.org/show_bug.cgi?id=100067
--- Comment #6 from Vedran Miletić ---
(In reply to Mig from comment #5)
> minimal.cpp compiled with
>
> gcc -c minimal.cpp -g -o minimal.o
>
> [miguel@antergos-mig extra]$ gdb
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Founda
On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 23-03-2017 17:42, Ville Syrjälä wrote:
> > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote:
> >> Hi Shashank,
> >>
> >>
> >> On 23-03-2017 16:43, Sharma, Shashank wrote:
> >>> Regards
> >>>
> >>> Shashank
On 21 March 2017 at 05:00, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>> > > wrote:
>> > > > Seems
https://bugs.freedesktop.org/show_bug.cgi?id=100304
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 23-03-2017 15:16, Ville Syrjälä wrote:
> > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote:
> >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new
> >> flag which will signal userspace that
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #5 from omegap...@startmail.com ---
Ah, happened again after leaving it off for ~2 hours...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=100289
--- Comment #6 from omegap...@startmail.com ---
Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow
I'm sure ;)
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on|79431 |
Referenced Bugs:
https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=79431
Jan Vesely changed:
What|Removed |Added
Resolution|NOTABUG |---
Status|RESOLVED
can you add bps here too?
On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
>
> Signed-off-by: Chris Zhong
> Reviewed-by: Sean Paul
> Tested-by: Brian Norris
> ---
>
> Changes in v3:
> - printk err after regula
On Sat, Mar 18, 2017 at 12:09 AM, Russell King - ARM Linux
wrote:
> On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote:
>> This is a modesetting driver for the pl111 CLCD display controller
>> found on various ARM platforms such as the Versatile Express. The
>> driver has only been tested
On 03/22/2017 02:48 PM, Rob Clark wrote:
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote:
Quoting Rob Clark (2017-03-22 10:07:54)
I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, whi
https://bugs.freedesktop.org/show_bug.cgi?id=100364
Bug ID: 100364
Summary: DisplayPort hotplug warning and monitor sometimes
stays blank
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All
https://bugs.freedesktop.org/show_bug.cgi?id=100364
--- Comment #1 from John Brooks ---
Created attachment 130407
--> https://bugs.freedesktop.org/attachment.cgi?id=130407&action=edit
Fix for display not waking
--
You are receiving this mail because:
You are the assignee for the bug._
1 - 100 of 136 matches
Mail list logo
