On 2018년 10월 05일 15:26, Daniel Vetter wrote:
> On Fri, Oct 5, 2018 at 8:22 AM Daniel Vetter wrote:
>>
>> On Fri, Oct 5, 2018 at 4:59 AM Inki Dae wrote:
>>>
>>> This reverts commit 0586feba322e1de05075700eb4b835c8b683e62b
>>>
>>> This patch makes it to need get_vblank_counter callback in crtc
>>
On Thu, Oct 04, 2018 at 08:29:50PM -0400, Lyude Paul wrote:
> With the exception of modesets which would switch the DPMS state of a
> connector from on to off, we want to make sure that we disallow all
> modesets which would result in enabling a new monitor or a new mode
> configuration on a monito
On Thu, Oct 04, 2018 at 08:29:51PM -0400, Lyude Paul wrote:
> As mentioned in the previous commit, we currently prevent new modesets
> on recently-removed MST connectors by returning no encoder from our
> ->best_encoder() callback once the MST port has disappeared. This is
> wrong however, because
On Thu, Oct 04, 2018 at 08:29:52PM -0400, Lyude Paul wrote:
> Currently we set intel_connector->mst_port to NULL to signify that the
> MST port has been removed from the system so that we can prevent further
> action on the port such as connector probes, mode probing, etc.
> However, we're going to
On Thu, Oct 04, 2018 at 08:29:53PM -0400, Lyude Paul wrote:
> Since we need to be able to allow DPMS on->off prop changes after an MST
> port has disappeared from the system, we need to be able to make sure we
> can compute a config for the resulting atomic commit. Currently this is
> impossible wh
On Thu, Oct 04, 2018 at 08:29:54PM -0400, Lyude Paul wrote:
> Currently, i915 appears to rely on blocking modesets on
> no-longer-present MSTB ports by simply returning NULL for
> ->best_encoder(), which in turn causes any new atomic commits that don't
> disable the CRTC to fail. This is wrong howe
On Fri, Oct 05, 2018 at 04:03:25PM +0900, Inki Dae wrote:
>
>
> On 2018년 10월 05일 15:26, Daniel Vetter wrote:
> > On Fri, Oct 5, 2018 at 8:22 AM Daniel Vetter wrote:
> >>
> >> On Fri, Oct 5, 2018 at 4:59 AM Inki Dae wrote:
> >>>
> >>> This reverts commit 0586feba322e1de05075700eb4b835c8b683e62b
Somehow I forgot a few when typing all the shiny new kerneldoc. Drop
them.
Signed-off-by: Daniel Vetter
---
include/drm/drm_vblank.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index d25a9603ab57..6ad9630d4f48 10
On 04/10/2018 20:10, Daniel Vetter wrote:
> On Thu, Oct 4, 2018 at 5:05 PM Neil Armstrong wrote:
>>
>> On 04/10/2018 12:09, Daniel Vetter wrote:
>>> On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
The mode_config max_width/max_height determines the maximum framebuffer
siz
On Fri, Oct 05, 2018 at 08:43:51AM +0200, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 10:40:16PM +, Thomas Hellstrom wrote:
> > Hi!
> >
> > I've sent out patches that replace 05/21 and 07/21. Since I'm on travel,
> > I'm not sure I'll be able to incorporate them in a pull before the merge
On Fri, Oct 05, 2018 at 04:45:54PM +1000, Ben Skeggs wrote:
> The following changes since commit 3483f08106fcd0e8edad2b9f2fc4726d25177799:
>
> drm/nouveau/devinit: fix warning when PMU/PRE_OS is missing
> (2018-09-13 10:56:58 +1000)
>
> are available in the Git repository at:
>
> git://githu
On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong wrote:
>
> On 04/10/2018 20:10, Daniel Vetter wrote:
> > On Thu, Oct 4, 2018 at 5:05 PM Neil Armstrong
> > wrote:
> >>
> >> On 04/10/2018 12:09, Daniel Vetter wrote:
> >>> On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> The mod
On Fri, Sep 28, 2018 at 10:02 AM Chen-Yu Tsai wrote:
>
> On Thu, Sep 27, 2018 at 7:50 PM Jagan Teki wrote:
> >
> > Bananapi S070WV20-CT16 is 800x480, 4-lane MIPI-DSI panel which
> > can be used to connect via BPI-M64 board, so add a driver for it.
> >
> > The same panel PCB comes with parallel RB
On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
wrote:
>
> On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > > These are the approaches which could have been taken to handle
> > > this scenario -
> > >
On Thu, Oct 4, 2018 at 6:04 PM Russell King - ARM Linux
wrote:
>
> On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> > On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> > wrote:
> > >
> > > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > > On Thu, O
Hi Matthew,
On Thu, Oct 4, 2018 at 1:30 AM Matthew Wilcox wrote:
>
> On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > These are the approaches which could have been taken to handle
> > this scenario -
> >
> > * Replace vm_insert_page with vmf_insert_page and then write few
>
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.
Instead, base field swap on the field order of the input to the CSI,
and th
Hi Souptick,
On Thu, Oct 4, 2018 at 8:49 PM Souptick Joarder wrote:
>
> On Thu, Oct 4, 2018 at 11:47 PM Matthew Wilcox wrote:
> >
> > I think this is a bad plan. What we should rather do is examine the current
> > users of vm_insert_page() and ask "What interface would better replace
> > vm_ins
Hi Sakari, Hans,
On Tue, May 9, 2017 at 12:05 AM Sakari Ailus
wrote:
>
> The cache synchronisation may be a time consuming operation and thus not
> best performed in an interrupt which is a typical context for
> vb2_buffer_done() calls. This may consume up to tens of ms on some
> machines, depend
On Thu, Oct 04, 2018 at 11:42:18PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 6:04 PM Russell King - ARM Linux
> wrote:
> > I'm confused, what are you trying to do?
> >
> > It seems that we already have:
> >
> > vm_insert_page() - returns an errno
> > vmf_insert_page() - returns a VM_
On Thu, Sep 27, 2018 at 10:47 PM Maxime Ripard
wrote:
>
> On Thu, Sep 27, 2018 at 05:18:50PM +0530, Jagan Teki wrote:
> > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > BPI-M64 board.
> >
> > DSI panel connected via board DSI port with,
> > - DC1SW as AVDD supply
> > - DCDC1 as
On Thu, Oct 4, 2018 at 1:28 AM Miguel Ojeda
wrote:
>
> Hi Souptick,
>
> On Wed, Oct 3, 2018 at 8:55 PM Souptick Joarder wrote:
> >
> > vm_insert_kmem_page is similar to vm_insert_page and will
> > be used by drivers to map kernel (kmalloc/vmalloc/pages)
> > allocated memory to user vma.
> >
> > G
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be double
On Fri, Oct 5, 2018 at 1:16 AM Miguel Ojeda
wrote:
>
> Hi Souptick,
>
> On Thu, Oct 4, 2018 at 8:49 PM Souptick Joarder wrote:
> >
> > On Thu, Oct 4, 2018 at 11:47 PM Matthew Wilcox wrote:
> > >
> > > I think this is a bad plan. What we should rather do is examine the
> > > current
> > > users
Hi,
On Fri, Sep 14, 2018 at 06:05:52PM +0800, Peng Hao wrote:
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:
> In function ‘gmc_v8_0_process_interrupt’:
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1447:10:
> warning: missing braces around initializer [-Wmissing-braces]
>
> Signed-off-by: Peng Hao
On Thu, Oct 4, 2018 at 11:47 PM Matthew Wilcox wrote:
>
> On Thu, Oct 04, 2018 at 11:42:18PM +0530, Souptick Joarder wrote:
> > On Thu, Oct 4, 2018 at 6:04 PM Russell King - ARM Linux
> > wrote:
> > > I'm confused, what are you trying to do?
> > >
> > > It seems that we already have:
> > >
> > >
Hi,
I have a somewhat of my own view on what would be involved with VRR,
and I'd like to hear what you think of it. Comments inline.
On Tue, 25 Sep 2018 09:51:37 -0400
"Kazlauskas, Nicholas" wrote:
> On 09/24/2018 04:26 PM, Ville Syrjälä wrote:
> > On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kaz
Am 04.10.2018 um 20:52 schrieb Guenter Roeck:
> Hi,
>
> On Fri, Sep 14, 2018 at 06:05:52PM +0800, Peng Hao wrote:
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:
>> In function ‘gmc_v8_0_process_interrupt’:
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1447:10:
>> warning: missing braces around init
On 05/10/2018 09:58, Daniel Vetter wrote:
> On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong wrote:
>>
[...]
>> OK, won't this be enough ?
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -333,6 +333,8 @@ struct drm_mode_config_funcs {
>> * @min_height: minimum
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #16 from quirin.blae...@freenet.de ---
Created attachment 278933
--> https://bugzilla.kernel.org/attachment.cgi?id=278933&action=edit
amdgpu_pm_info
content of /sys/kernel/debug/dri/1/amdgpu_pm_info
for 4.18.12 +/- 93b100ddda3be284b
https://bugs.freedesktop.org/show_bug.cgi?id=106671
Michel Dänzer changed:
What|Removed |Added
Attachment #141904|application/x-trash |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #25 from Michel Dänzer ---
(In reply to Alan W. Irwin from comment #24)
> Just now the direct X server failed with a segfault (see the attached log
> file for the details).
Looks like a Mesa bug. Please install the libgl1-mesa-dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #22 from Mike Lothian ---
Created attachment 141907
--> https://bugs.freedesktop.org/attachment.cgi?id=141907&action=edit
report with amdgpu DDX
this is still happening with the amdgpu DDX
--
You are receiving this mail because:
There has been some discussion about extending drm core to handle
linear tile formats, in the series sent by me here [1] and how to
handle formats that are intended to be used just with
modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC
here [3] and [4].
Hence, this big-merged s
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu
From: Brian Starkey
As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).
AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes",
From: Brian Starkey
AFBC is a flexible, proprietary, lossless compression protocol and
format, with a number of defined DRM format modifiers. To facilitate
consistency and compatibility between different AFBC producers and
consumers, document the expectations for usage of the AFBC DRM format
modi
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 23 +--
2 files changed, 32 ins
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #26 from Alan W. Irwin ---
(In reply to Michel Dänzer from comment #25)
> (In reply to Alan W. Irwin from comment #24)
> > Just now the direct X server failed with a segfault (see the attached log
> > file for the details).
>
> Look
Hi Steve,
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:
[...]
> int ipu_csi_init_interface(struct ipu_csi *csi,
> struct v4l2_mbus_config *mbus_cfg,
> -struct v4l2_mbus_framefmt *mbus_fmt)
> +struct v4l2_mbus_fr
Well except the destroy helper, which isn't really a primary helper
but generally useful, if mislabelled.
v2: Keep some of the nice comments about the limitations of the
primarmy plane helpers, and put them into the kerneldoc for
drm_crtc_init() (Sam).
Reviewed-by: Ville Syrjälä (v1)
Cc: Sam Rav
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:
> To support interlaced scan with planar formats, cpmem SLUV must
> be programmed with the correct chroma line stride. For full and
> partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
> be doubled. For full and partial planar 4:
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
Attachment #141907|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #27 from Michel Dänzer ---
(In reply to Alan W. Irwin from comment #26)
> Debian Jessie = oldstable had debug packages for libgl1-mesa-dri, but I
> can find nothing equivalent for Debian Stretch
Debugging symbol packages are in a se
On Thu, Oct 04, 2018 at 10:38:17PM +, Thomas Hellstrom wrote:
> Make the connector is_implicit property immutable.
> As far as we know, no user-space application is writing to it.
>
> Also move the verification that all implicit display units scan out
> from the same framebuffer to atomic_chec
On Fri, Oct 05, 2018 at 09:36:36AM +0200, Daniel Vetter wrote:
> Somehow I forgot a few when typing all the shiny new kerneldoc. Drop
> them.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> include/drm/drm_vblank.h | 8
> 1 file changed, 4 insertions(+), 4 deletio
From: Daniel Vetter
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremel
https://bugs.freedesktop.org/show_bug.cgi?id=107955
--- Comment #24 from Mike Lothian ---
Created attachment 141910
--> https://bugs.freedesktop.org/attachment.cgi?id=141910&action=edit
mpv debugging log
--
You are receiving this mail because:
You are the assignee for the bug.
Den 04.10.2018 21.35, skrev Daniel Vetter:
On Thu, Oct 04, 2018 at 05:04:21PM +0200, Arnd Bergmann wrote:
On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
Den 04.10.2018 09.48, skrev Daniel Vetter:
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
On Wed, Oct 3, 2018 at 6:13 PM Danie
https://bugs.freedesktop.org/show_bug.cgi?id=107955
Mike Lothian changed:
What|Removed |Added
Attachment #141908|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=100953
--- Comment #1 from Heiko ---
I have a similar problem on PITCAIRN. For me it's not just bright car
reflections but also bright track lights, making driving somewhat difficult.
I've got an apitrace, though still need to upload it. But I'll attac
https://bugs.freedesktop.org/show_bug.cgi?id=100953
--- Comment #2 from Heiko ---
Created attachment 141912
--> https://bugs.freedesktop.org/attachment.cgi?id=141912&action=edit
Bright track lights on PITCAIRN
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=100953
--- Comment #3 from Heiko ---
Created attachment 141913
--> https://bugs.freedesktop.org/attachment.cgi?id=141913&action=edit
No bright track lights on POLARIS
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100953
--- Comment #4 from Heiko ---
Darn, I just noticed that these aren't track lights, but flags. That matches
the graphics settings: If setting rendering option "CLOTH" to "High", the issue
appears. If setting it to "Low", the issue disappears.
--
https://bugs.freedesktop.org/show_bug.cgi?id=104602
Juan A. Suarez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104602
Timothy Arceri changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=100953
--- Comment #5 from Heiko ---
The apitrace can be found under
https://www.dropbox.com/s/283tyeu4eqbc20r/GridAutosport.trace.xz
This is '-benchmarkAttract' with graphics preset "Low" and "CLOTH" on "High".
As mentioned before: Renders fine on P
https://bugs.freedesktop.org/show_bug.cgi?id=108095
--- Comment #8 from Paul Menzel ---
libXpresent was not installed here, so xfwm didn’t have support for it.
```
$ xfwm4 --version
This is xfwm4 version 4.13.1 (revision 942156e4) for Xfce 4.12
Released under the terms of the GNU
https://bugzilla.kernel.org/show_bug.cgi?id=201275
gr...@sub.red changed:
What|Removed |Added
CC||gr...@sub.red
--- Comment #17 from gr...@
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h
On Fri, Oct 05, 2018 at 11:03:13AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/arm/malidp_drv.c: In function
> 'malidp_verify_afbc_framebuffer_size':
> drivers/gpu/drm/arm/malidp_drv.c:318:6: warning:
> variable 'afbc_superblock_size' set but not
The size of the superblocks being added to the total AFBC buffer size
got lost in the upstreaming process. Add it back.
Cc: Ayan Kumar Halder
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ar
The feature allows the guest request an EDID blob (describing monitor
capabilities) for a given scanout (aka virtual monitor connector).
It brings a new command message, which has just a scanout field (beside
the standard virtio-gpu header) and a response message which carries the
EDID data.
Sign
On Thu, Oct 04, 2018 at 10:24:39PM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutd
Some hardware variants contain a system level cache or the last level
cache(llc). This cache is typically a large block which is shared by multiple
clients on the SOC. GPU uses the system cache to cache both the GPU data
buffers(like textures) as well the SMMU pagetables. This helps with
improved r
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 8 +++
Add the registers needed for configuring the system cache slice info and
other parameters in the GPU.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno
From: Vivek Gautam
Qualcomm SoCs have an additional level of cache called as
System cache or Last level cache[1]. This cache sits right
before the DDR, and is tightly coupled with the memory
controller.
The cache is available to all the clients present in the
SoC system. The clients request their
From: Jordan Crouse
llcc_slice_getd can return a ERR_PTR code on failure. Add a IS_ERR_OR_NULL
check to subsequent API calls that use struct llcc_slice_desc to guard
against faults and to let the leaf drivers get away with safely using a
ERR_PTR() encoded "pointer" in the aftermath of a llcc_slic
This patch adds a register range in the gpu CX domain. This is needed to
support the last level system cache(LLC).
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
Allow different Adreno targets the ability to pass
specific mmu features to the generic layers. This will
help conditionally configure certain iommu features for
certain Adreno targets.
Also Add a few simple support functions to support a bitmask of
features that a specific MMU implementation supp
The last level system cache can be partitioned to 32 different slices
of which GPU has two slices preallocated. One slice is used for caching GPU
buffers and the other slice is used for caching the GPU SMMU pagetables.
This patch talks to the core system cache driver to acquire the slice handles,
c
From: Hans Verkuil
The calculation of the Signal Free Time in the framework was not
correct. If a message was received, then the next transmit should be
considered a New Initiator and use a shorter SFT value.
This was not done with the result that if both sides where continually
sending messages
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7604.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ad
From: Hans Verkuil
Clarify that calling cec_transmit_done can start a new transmit and
that you should put the hardware in a state that allows for a new
transmit before calling this function.
Signed-off-by: Hans Verkuil
---
Documentation/media/kapi/cec-core.rst | 4
1 file changed, 4 inse
From: Hans Verkuil
If a receive is in progress or starts before the transmit has
a chance, then lower the Signal Free Time of the upcoming transmit
to no more than CEC_SIGNAL_FREE_TIME_NEW_INITIATOR.
This is per the specification requirements.
Signed-off-by: Hans Verkuil
---
drivers/media/cec
From: Hans Verkuil
If the HDMI cable is disconnected or the CEC adapter is manually
unconfigured, then all pending transmits and wait-for-replies are
aborted. Signal this with new status bits (CEC_RX/TX_STATUS_ABORTED).
If due to (usually) a driver bug a transmit never ends (i.e. the
transmit_do
From: Hans Verkuil
When there is no EDID the CEC adapter should be unconfigured as
well. So call cec_phys_addr_invalidate() when this happens.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7842.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ad
From: Hans Verkuil
This patch series replaces patches 1-3 of:
https://www.spinics.net/lists/linux-media/msg141216.html
Patches 4 & 5 of that series remain as-is and are omap4 bug fixes.
This patch series can be applied to the media subsystem since it
has no drm changes.
Changes since the prev
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #18 from quirin.blae...@freenet.de ---
(In reply to Alex Deucher from comment #9)
> I don't think this is a bug. The problem is, prior to that patch, the
> display component was requesting minimum clocks that were 10x too low. This
>
https://bugs.freedesktop.org/show_bug.cgi?id=108014
--- Comment #7 from Jerry Zuo ---
I am retesting on HP Zbook.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
Tomi,
Can you review this patch and the next? They should go to 4.20.
This patch in particular is a nasty one, hard to reproduce.
This patch should also be Cc-ed to stable for 4.15 and up.
Tracking down randomly disappearing CEC transmits was no fun :-(
Regards,
Hans
On 10/04/18 11:08
On Fri, 2018-09-14 at 18:59 +0200, Lucas Stach wrote:
> This allows channels using the PRG to check if a requested configuration
> update has been applied or is still pending.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/ipu-v3/ipu-prg.c | 16
> include/video/imx-ipu-v3.h
Hi Lucas,
On Fri, 2018-09-14 at 18:59 +0200, Lucas Stach wrote:
> This allows the upper layers to check if a double buffer update has
> been applied by the PRE or is still pending.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/ipu-v3/ipu-pre.c | 6 ++
> drivers/gpu/ipu-v3/ipu-prv.h | 1
On Fri, 2018-09-14 at 18:59 +0200, Lucas Stach wrote:
> This function allows upper layer to check if a requested atomic update
> to the plane has been applied or is still pending.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 20
> drivers/gpu/dr
Hi Liviu,
On Fri, Oct 05, 2018 at 01:38:19PM +0100, Liviu Dudau wrote:
> The size of the superblocks being added to the total AFBC buffer size
> got lost in the upstreaming process. Add it back.
>
> Cc: Ayan Kumar Halder
> Signed-off-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 4
On Fri, Oct 5, 2018 at 12:14 PM Benjamin Gaignard
wrote:
>
> From: Daniel Vetter
>
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use dr
> On 5 Oct 2018, at 14:51, Gerd Hoffmann wrote:
>
> The feature allows the guest request an EDID blob (describing monitor
> capabilities) for a given scanout (aka virtual monitor connector).
>
> It brings a new command message, which has just a scanout field (beside
> the standard virtio-gpu h
On Fri, Oct 05, 2018 at 04:38:11PM +0200, Christophe de Dinechin wrote:
>
>
> > On 5 Oct 2018, at 14:51, Gerd Hoffmann wrote:
> >
> > The feature allows the guest request an EDID blob (describing monitor
> > capabilities) for a given scanout (aka virtual monitor connector).
> >
> > It brings a
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #19 from Michel Dänzer (mic...@daenzer.net) ---
People on the Phoronix forum mentioned that this doesn't seem to happen with
4.19-rc kernels. If people here can confirm that, maybe there are other
corresponding changes that need to be
On Fri, Oct 05, 2018 at 09:26:47AM +, Alexandru-Cosmin Gheorghe wrote:
> For some pixel formats .cpp structure in drm_format info it's not
> enough to describe the peculiarities of the pixel layout, for example
> tiled formats or packed formats at bit level.
>
> What's implemented here is to a
On Fri, Oct 05, 2018 at 09:26:57AM +, Alexandru-Cosmin Gheorghe wrote:
> For formats that are supported only with non-linear modifiers it
> doesn't make to much sense to define cpp or char_per_block, so that
> will be set to 0.
>
> This patch adds a restriction to force having a modifier attac
On Fri, Oct 05, 2018 at 09:26:43AM +, Alexandru-Cosmin Gheorghe wrote:
> There has been some discussion about extending drm core to handle
> linear tile formats, in the series sent by me here [1] and how to
> handle formats that are intended to be used just with
> modifiers(particularly AFBC mo
On Fri, Oct 05, 2018 at 06:38:32PM +0530, Sharat Masetty wrote:
> Add the registers needed for configuring the system cache slice info and
> other parameters in the GPU.
This would conflict with msm-next or at least with the latest update from the
rnndb. It is good to have this out here for people
On Fri, Oct 05, 2018 at 06:38:35PM +0530, Sharat Masetty wrote:
> The last level system cache can be partitioned to 32 different slices
> of which GPU has two slices preallocated. One slice is used for caching GPU
> buffers and the other slice is used for caching the GPU SMMU pagetables.
> This pat
On Fri, 2018-09-14 at 18:59 +0200, Lucas Stach wrote:
> Currently there is a small race window where we could manage to arm the
> vblank event from atomic flush, but programming the hardware was too close
> to the frame end, so the hardware will only apply the current state on the
> next vblank. In
Hi Dave,
I've realised that the commit 3dae1c0919d8 ("drm/arm/malidp: Implemented
the size validation for AFBC framebuffers") got bungled up in the
upstreaming process and it was missing an important line from the
function that calculates the size of the AFBC framebuffer. The patch to
fix it has n
On Thu, Oct 04, 2018 at 09:33:59PM +0530, Jagan Teki wrote:
> On Thu, Sep 27, 2018 at 10:47 PM Maxime Ripard
> wrote:
> >
> > On Thu, Sep 27, 2018 at 05:18:50PM +0530, Jagan Teki wrote:
> > > This patch add support for Bananapi S070WV20-CT16 DSI panel to
> > > BPI-M64 board.
> > >
> > > DSI panel
1 - 100 of 178 matches
Mail list logo
