On 07/07/2019 21:18, Laurent Pinchart wrote:
The drmP.h header is deprecated, replace it with the headers
specifically needed by the tfp410 driver. While at it, replace the DRM
print macros with dev_info() and dev_err() instead of including
drm_print.h
Signed-off-by: Laurent Pinchart
---
On 07/07/2019 21:18, Laurent Pinchart wrote:
The TI OP362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
1 file changed, 5 insertions(+)
diff --git
On 26/08/2019 17:26, Boris Brezillon wrote:
> And use it in drivers accessing the bridge->next field directly.
> This is part of our attempt to make the bridge chain a double-linked list
> based on the generic list helpers.
Reviewed-by: Neil Armstrong
>
> Signed-off-by: Boris Brezillon
> ---
On 26/08/2019 16:51, Laurent Pinchart wrote:
Hi Tomi,
On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi Valkeinen wrote:
On 20/08/2019 04:16, Laurent Pinchart wrote:
The patches can be found at
git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel
I took your branch, booted AM5
Hi Tomi,
On Tue, Aug 27, 2019 at 10:43:15AM +0300, Tomi Valkeinen wrote:
> On 20/08/2019 04:16, Laurent Pinchart wrote:
> > Now that a driver is available for display connectors, replace the
> > manual connector handling code with usage of the DRM bridge API. The
> > tfp410 driver doesn't deal
Hi Andrey,
On Mon, Aug 26, 2019 at 09:24:57PM -0700, Andrey Smirnov wrote:
> On Mon, Aug 26, 2019 at 3:08 PM Laurent Pinchart wrote:
> > On Mon, Aug 26, 2019 at 11:25:24AM -0700, Andrey Smirnov wrote:
> > > Presently, the driver code artificially limits test pattern mode to a
> > > single pattern
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444
This patchset is based on Boris's v2 "drm: Add support for bus-format
negotiation" at [1]
patchset to implement full bus-format negotiation for DW-HDMI, including YUV420
support and
10/12/16bit YUV444, YUV422 and RGB. The Color Space Converter support is
already implemented.
And the
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
To allow using formats from negociation, stop enforcing input_bus_format
in the private dw-plat-data struct.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
This patch adds encoding support for the YUV420 output from the
Amlogic Meson SoCs Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the
Switch the dw-hdmi driver to drm_bridge_funcs, and implement the
atomic_get_input_bus_fmts/atomic_get_output_bus_fmts.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 67 +--
1 file changed, 54 insertions(+), 13 deletions(-)
diff --git
Hi Tomi,
On Tue, Aug 27, 2019 at 10:34:59AM +0300, Tomi Valkeinen wrote:
> On 26/08/2019 16:51, Laurent Pinchart wrote:
> > On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi Valkeinen wrote:
> >> On 20/08/2019 04:16, Laurent Pinchart wrote:
> >>
> >>> The patches can be found at
> >>>
> >>>
Add the suspens and resume hooks to:
- reset the whole HDMI glue and HDMI controller on suspend
- re-init the HDMI glue and HDMI controller on resume
The HDMI glue init is refactored to be re-used from the resume hook.
It makes usage of dw_hdmi_resume() to recover a functionnal DDC bus.
Add the suspend and resume hooks to:
- save and disable the entire DRM driver on suspend
- re-init the entire VPU subsystem on resume, to recover CRTC and pixel
generator functionnal usage after DDR suspend, then recover DRM driver
state
Signed-off-by: Neil Armstrong
---
This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
and the DW-HDMI Glue driver to correctly save state and disable HW before
suspend, and succesfully re-init the HW to recover functionnal display
after resume.
This serie has been tested on Amlogic G12A based SEI510
Hi Tomi,
On Tue, Aug 27, 2019 at 09:16:42AM +0300, Tomi Valkeinen wrote:
> On 07/07/2019 21:18, Laurent Pinchart wrote:
> > The TI OP362 is an analog video amplifier controlled through a GPIO. Add
> > support for it to the simple-bridge driver.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
>
Hi Tomi,
On Tue, Aug 27, 2019 at 09:38:18AM +0300, Tomi Valkeinen wrote:
> On 07/07/2019 21:18, Laurent Pinchart wrote:
> > The drmP.h header is deprecated, replace it with the headers
> > specifically needed by the tfp410 driver. While at it, replace the DRM
> > print macros with dev_info() and
Hi Laurent,
I tried this series with my Pandaboard, but it broke my Pandaboard. After
doing a git bisect it ended up with this patch as the culprit.
If I boot my Pandaboard I get this:
[3.271881] omapdss_dss 5800.dss: 5800.dss supply vdda_video not
found, using dummy regulator
[
Hi Peter,
On Tue, Aug 27, 2019 at 10:54 AM Peter Rosin wrote:
> On 2019-08-27 10:36, Geert Uytterhoeven wrote:
> > On Mon, Aug 26, 2019 at 10:46 PM Peter Rosin wrote:
> >> Probably most useful if you only want one logo regardless of how many
> >> CPU cores you have.
> >>
> >> Signed-off-by:
Hi Tomi,
On Tue, Aug 27, 2019 at 12:32:46PM +0300, Tomi Valkeinen wrote:
> On 27/08/2019 12:29, Laurent Pinchart wrote:
> > On Tue, Aug 27, 2019 at 10:34:59AM +0300, Tomi Valkeinen wrote:
> >> On 26/08/2019 16:51, Laurent Pinchart wrote:
> >>> On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi
Hi Laurent,
On Tue, Aug 27, 2019 at 01:43:37AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> Should you squash this with the patches that add CMM units to the other
> SoCs ?
I don't know, I guess it depends on Geert's preferences. Geert?
>
> On Sun, Aug 25, 2019
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #3 from Robert ---
Thanks Andrew for you comment! At least now I know that I'm not alone ;-) The
funny thing is that one of the users in the Archlinux forum thread
(https://bbs.archlinux.org/viewtopic.php?pid=1860353#p1860353)
On 26/08/2019 17:26, Boris Brezillon wrote:
> This takes the form of various helpers, plus the addition of 2 new
> structs:
> * drm_bus_caps: describe the bus capabilities of a bridge/encoder. For
> bridges we have one for the input port and one for the output port.
> Encoders just have one
Hi Peter,
On Mon, Aug 26, 2019 at 10:46 PM Peter Rosin wrote:
> Probably most useful if you only want one logo regardless of how many
> CPU cores you have.
>
> Signed-off-by: Peter Rosin
Thanks for your patch!
> --- a/Documentation/fb/fbcon.rst
> +++ b/Documentation/fb/fbcon.rst
> @@ -174,6
On Tue, 27 Aug 2019 10:15:19 +0200
Philipp Zabel wrote:
> Hi Boris,
>
> On Mon, 2019-08-26 at 17:26 +0200, Boris Brezillon wrote:
> > Now that bridges can expose the bus format/flags they expect, we can
> > use those instead of the relying on the display_info provided by the
> > connector
[...]
> > IIUC the conclusion is that there is no need for a string attribute
> > because we only need to distinguish between 'perceptual' and
> > 'non-perceptual'. If that is correct, do you have any preference for
> > the attribute name ('perceptual_scale', 'perceptual', ...)?
>
> More a
On Tue, 27 Aug 2019 11:23:02 +0200
Philipp Zabel wrote:
> On Tue, 2019-08-27 at 10:43 +0200, Boris Brezillon wrote:
> [...]
> > > > +static void
> > > > +imx_pd_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> > > > +struct drm_bridge_state
Hi Jacopo,
On Tue, Aug 27, 2019 at 11:53 AM Jacopo Mondi wrote:
> On Tue, Aug 27, 2019 at 01:43:37AM +0300, Laurent Pinchart wrote:
> > Should you squash this with the patches that add CMM units to the other
> > SoCs ?
>
> I don't know, I guess it depends on Geert's preferences. Geert?
If you
On 07/07/2019 21:18, Laurent Pinchart wrote:
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig| 8 +
drivers/gpu/drm/bridge/Makefile
On Mon, 26 Aug 2019, "Francis, David" wrote:
> On 2019-08-26 2:05 p.m., David Francis wrote:
>>> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
>>> support virtual DPCD registers, but do support DSC.
>>> The DSC caps can be read from the physical aux,
>>> like in SST DSC. These hubs have many
On 20/08/2019 04:16, Laurent Pinchart wrote:
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector
> -Original Message-
> From: Michael Kelley
> Sent: Thursday, August 22, 2019 7:49 AM
> To: Wei Hu ; b.zolnier...@samsung.com; linux-
> hyp...@vger.kernel.org; dri-devel@lists.freedesktop.org; linux-
> fb...@vger.kernel.org; linux-ker...@vger.kernel.org; sas...@kernel.org;
> Stephen
https://bugs.freedesktop.org/show_bug.cgi?id=111498
Bug ID: 111498
Summary: [amdgpu, Ryzen 7 Pro 3700U] freeze when suspending
shortly after wakeup
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Tue, 2019-08-27 at 10:43 +0200, Boris Brezillon wrote:
[...]
> > > +static void
> > > +imx_pd_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> > > + struct drm_bridge_state *bridge_state,
> > > + struct
Hi Hans,
On Tue, Aug 27, 2019 at 11:07:56AM +0200, Hans Verkuil wrote:
> Hi Laurent,
>
> I tried this series with my Pandaboard, but it broke my Pandaboard. After
> doing a git bisect it ended up with this patch as the culprit.
>
> If I boot my Pandaboard I get this:
>
> [3.271881]
On Mon, 22 Jul 2019 16:38:15 +0200,
Takashi Iwai wrote:
>
> This patch adds the support for the notification of HD-audio hotplug
> via the already existing drm_audio_component framework. This allows
> us more reliable hotplug notification and ELD transfer without
> accessing HD-audio bus; it's
Hi Hans,
On Tue, Aug 27, 2019 at 12:51:08PM +0300, Laurent Pinchart wrote:
> On Tue, Aug 27, 2019 at 11:07:56AM +0200, Hans Verkuil wrote:
> > Hi Laurent,
> >
> > I tried this series with my Pandaboard, but it broke my Pandaboard. After
> > doing a git bisect it ended up with this patch as the
On 26/08/2019 23:33, Rob Herring wrote:
There's no need to serialize io-pgtable calls and the as_lock is
sufficient to serialize flush operations, so we can remove the per
page table lock.
Reviewed-by: Robin Murphy
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports deferred IO for screens in
graphics mode and also enables the frame buffer on-demand refresh. The
On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote:
> Probably most useful if you want no logo at all, or if you only want one
> logo regardless of how many CPU cores you have.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
On 26/08/2019 23:33, Rob Herring wrote:
Currently, page tables are freed without disabling the address space first.
This probably is fine as we'll switch to new page tables when the address
space is allocated again and runtime PM suspend will reset the GPU
clearing the registers. However, it's
On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote:
> Three shall be the number thou shalt count, and the number of the
> counting shall be three. Four shalt thou not count...
>
> One! Two! Five!
>
> Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer
> console documentation")
On 26/08/2019 23:33, Rob Herring wrote:
It's not entirely clear if this is required, but add a flush of GPU caches
and TLBs before we change an address space to new page tables.
This might work out to be partially redundant with some of the revamped
flushing in #7, but unless it proves to be
Hi Chris,
When running the new dmabuf-selftests on two different systems, I get:
dma-buf: Running sanitycheck
dma-buf: Running dma_fence
sizeof(dma_fence)=48
dma-buf: Running dma_fence/sanitycheck
dma-buf: Running dma_fence/test_signaling
dma-buf: Running
https://bugs.freedesktop.org/show_bug.cgi?id=111498
Rohan Lean changed:
What|Removed |Added
Priority|not set |high
--- Comment #1 from Rohan Lean ---
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
v3:
comment is added for fw_ddi init for gen12+ [Shashank]
only hdcp capable transcoder is translated into
Hi Peter,
On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote:
> The variable is only ever used from fbcon.c which is linked into the
> same module. Therefore, the export is not needed.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Geert Uytterhoeven
But note that the same is true for fb_class,
Quoting Christian König (2019-08-26 15:57:23)
> The function is supposed to give a hint even if signaling is not enabled.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-fence-array.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git
On 25/08/2019 23:23, Ilia Mirkin wrote:
You'll probably get a more detailed reply during the week, but for now
have a look at the "link-status" property, which was made for
precisely this situation. I think basically the idea is to ignore link
training as part of the modeset, and just return the
On Thu, Aug 22, 2019 at 5:44 AM Guido Günther wrote:
>
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++
> 1 file changed, 155 insertions(+)
> create mode
On Fri, Aug 23, 2019 at 7:16 AM Brian Masney wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by:
Quoting Geert Uytterhoeven (2019-08-27 13:30:04)
> Hi Chris,
>
> When running the new dmabuf-selftests on two different systems, I get:
>
> dma-buf: Running sanitycheck
> dma-buf: Running dma_fence
> sizeof(dma_fence)=48
> dma-buf: Running dma_fence/sanitycheck
> dma-buf:
On 26/08/2019 23:33, Rob Herring wrote:
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which
Hi!
The first patch fixes the fact that there are two items numbered "4" in
the list of fbcon options. This bug is a teenager...
The second patch extends that list with a new option that allows the
user to display any number of logos (that fits on the screen). I need it
to limit the display to
Probably most useful if you want no logo at all, or if you only want one
logo regardless of how many CPU cores you have.
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 5 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/video/fbdev/core/fbmem.c | 12 +---
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console
documentation")
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 8
The variable is only ever used from fbcon.c which is linked into the
same module. Therefore, the export is not needed.
Signed-off-by: Peter Rosin
---
drivers/video/fbdev/core/fbmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_tc and add as a member into
the struct hdcp_port_data.
v2:
Typo in commit msg is fixed [Shashank]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h |
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v10:
Review comments from shashank addressed
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to i915 header
drm: Extend I915 mei
We dont need the definition of the enum port outside I915, anymore.
Hence move enum port definition into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
v4:
commit msg is rephrased.
Signed-off-by: Ramalingam C
Reviewed-by: Jani
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
---
>From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in
On 26/08/2019 23:33, Rob Herring wrote:
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks
From: Maxime Ripard
The named modes support has introduced a number of glitches that were in
part due to the fact that the parser will take any string as a named mode.
Since we shouldn't have a lot of options there (and they should be pretty
standard), let's introduce a whitelist of the
From: Maxime Ripard
Let's add some unit tests for the recent bugs we just fixed.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/selftests/drm_cmdline_selftests.h | 7 +
.../drm/selftests/test-drm_cmdline_parser.c | 130 ++
2 files changed, 137 insertions(+)
diff --git
From: Maxime Ripard
Some extra command line options can be either specified without anything
else on the command line (basically all the force connection options), but
some other are only relevant when matched with a resolution (margin and
interlace).
Let's add a switch to restrict if needed
From: Maxime Ripard
The command line parser when it has been rewritten introduced a regression
when the only thing on the command line is an option to force the detection
of a connector (such as video=HDMI-A-1:d), which are completely valid.
It's been further broken by the support for the named
Hi Thomas,
On 8/26/2019 6:50 PM, Thomas Zimmermann wrote:
Hi Feng
Am 24.08.19 um 07:16 schrieb Feng Tang:
Hi Thomas,
On Thu, Aug 22, 2019 at 07:25:11PM +0200, Thomas Zimmermann wrote:
Hi
I was traveling and could reply earlier. Sorry for taking so long.
No problem! I guessed so :)
Am
On 27/08/2019 07:40, Martin Blumenstingl wrote:
> On Mon, Aug 26, 2019 at 4:47 PM Neil Armstrong
> wrote:
>>
>> When calculating the HDMI PLL settings for a DMT mode PHY frequency,
>> use the correct max fractional PLL value for G12A VPU.
>>
>> With this fix, we can finally setup the 1024x76-60
On 26/08/2019 17:26, Boris Brezillon wrote:
> Will be useful for bridge drivers that want to do bus format
> negotiation with their neighbours.
Reviewed-by: Neil Armstrong
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v2:
> * Fix the kerneldoc
> * Drop the !bridge || !bridge->encoder
On 26/08/2019 17:26, Boris Brezillon wrote:
> To iterate over all bridges attached to a specific encoder.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Boris Brezillon
Reviewed-by: Neil Armstrong
> ---
> Changes in v2:
> * New patch
> ---
> include/drm/drm_bridge.h | 11 +++
>
On Mon, 26 Aug 2019, "Siqueira, Rodrigo" wrote:
> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
>
> Changes since V1:
> - Adjusts registers names to be aligned with spec and the
On Mon, Aug 26, 2019 at 05:51:26PM -0400, Lyude Paul wrote:
> *sigh* finally have some time to go through these reviews
Hey it took me longer to start even reviewing this, and not even through
:-( than it took you to reply here. So no worries!
> jfyi: I realized after looking over this patch
On Wed, 14 Aug 2019 20:48:44 -0400, Brian Masney wrote:
> Add support for the analogix,anx7808, analogix,anx7812, and
> analogix,anx7818 variants.
>
> Signed-off-by: Brian Masney
> ---
> .../devicetree/bindings/display/bridge/anx7814.txt | 6 +-
> 1 file changed, 5 insertions(+), 1
On Mon, Aug 26, 2019 at 07:30:08AM +0300, Lionel Landwerlin wrote:
> On 26/08/2019 00:01, Daniel Vetter wrote:
> > On Fri, Aug 23, 2019 at 8:53 PM Jason Ekstrand wrote:
> > >
> > > On Thu, Aug 22, 2019 at 5:28 PM Lionel Landwerlin
> > > wrote:
> > > > On 22/08/2019 21:24, Jason Ekstrand wrote:
Hi Laurent,
On Tue, Aug 27, 2019 at 04:56:19PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 27, 2019 at 03:24:22AM +0300, Laurent Pinchart wrote:
> > On Sun, Aug 25, 2019 at 03:51:48PM +0200, Jacopo Mondi wrote:
> > > Add a driver for the R-Car Display Unit Color Correction Module.
> > >
> > > In
On Tue, 27 Aug 2019 14:51:20 +0200
Philipp Zabel wrote:
> [...]
> > > > I can do that if you like. Note that we are forwarding
> > > > the ->output_bus_cfg.fmt value to the IPU DI, not ->input_bus_cfg.fmt.
> > > > I just assumed that input format wouldn't be used in the dummy bridge
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=111502
Bug ID: 111502
Summary: Dell XPS15 (HD530 & GeForce 950) external screen via
dock/HDMI no text display & gdm freeze
Product: DRI
Version: unspecified
Hardware: x86-64
On Mon, Jul 22, 2019 at 10:38 AM Takashi Iwai wrote:
>
> This patch adds the support for the notification of HD-audio hotplug
> via the already existing drm_audio_component framework to radeon
> driver. This allows us more reliable hotplug notification and ELD
> transfer without accessing
On Fri, Aug 23, 2019 at 10:13:14AM +0200, Thomas Hellström (VMware) wrote:
> From: Thomas Hellstrom
>
> The new header is intended to be used by drivers using the backdoor.
> Follow the kvm example using alternatives self-patching to
> choose between vmcall, vmmcall and io instructions.
>
>
On 2019-08-27 at 18:32:13 +0530, Winkler, Tomas wrote:
>
> > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> > from DDI into transcoder.
>
> In some files needs to bump the copyright to 2019.
Tomas,
I am not aware when a copyright year needs to be bumped, as
Only files are that are modified in this year should be updated.
For example.
include/drm/i915_mei_hdcp_interface.h
- * Copyright © 2017-2018 Intel Corporation
+ * Copyright © 2017-2019 Intel Corporation
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, August 27, 2019 16:23
On Tue, 2019-08-27 at 15:20 +0200, Boris Brezillon wrote:
> On Tue, 27 Aug 2019 14:51:20 +0200
> Philipp Zabel wrote:
>
> > [...]
> > > > > I can do that if you like. Note that we are forwarding
> > > > > the ->output_bus_cfg.fmt value to the IPU DI, not ->input_bus_cfg.fmt.
> > > > > I just
On Tue, 2019-08-27 at 11:57 +0200, Boris Brezillon wrote:
> On Tue, 27 Aug 2019 11:23:02 +0200
> Philipp Zabel wrote:
> > On Tue, 2019-08-27 at 10:43 +0200, Boris Brezillon wrote:
[...]
> > Absolutely. This was just a cosmetic remark. I'm suggesting to put this
> > branch below the other two, to
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
In some files needs to bump the copyright to 2019.
>
> v10:
> Review comments from shashank addressed
>
> Ramalingam C (6):
> drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
>
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
This issue should be fixed with this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=98f58ada2d37e68125c056f1fc005748251879c2
--
You are receiving
>
> I915 needs to send the index of the transcoder as per ME FW.
>
> To support this, define enum mei_fw_tc and add as a member into the struct
> hdcp_port_data.
>
> v2:
> Typo in commit msg is fixed [Shashank]
>
> Signed-off-by: Ramalingam C
> Acked-by: Jani Nikula
> ---
>
On 2019-08-27 3:09 a.m., YueHaibing wrote:
> After commit a9f54ce3c603 ("drm/amd/display: Refactoring VTEM"),
> there is no caller in tree.
>
> Reported-by: Hulk Robot Signed-off-by: YueHaibing
>
Reviewed-by: Harry Wentland
Harry
> ---
>
On 2019-08-26 3:25 p.m., Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
From: Rob Clark
Add ->flush_commit(crtc_mask). Currently a no-op, but kms backends
should migrate writing flush registers to this hook, so we can decouple
pushing updates to hardware, and flushing the updates.
Once we add async commit support, the hw updates will be pushed down to
the hw
From: Wei Hu Sent: Tuesday, August 27, 2019 4:09 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite what the host specifies. The VM resolution on the host
> could be set
https://bugs.freedesktop.org/show_bug.cgi?id=108194
--- Comment #9 from Timothy Arceri ---
Do you think you can test git master now that this fix [1] has landed?
[1]
https://cgit.freedesktop.org/mesa/mesa/commit/?id=360cf3c4b05679709574ef4d20b5097b0fd0be82
--
You are receiving this mail
On 8/24/19 4:03 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-08-24-16-02 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
On Mon, Aug 19, 2019 at 3:27 PM John Stultz wrote:
> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn
> wrote:
> >
> > In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
> > which attach to the DSI host via mipi_dsi_attach() at probe time, the
> > ADV7533 bridge device does not.
On 8/27/19 11:41 AM, Jason Gunthorpe wrote:
On Fri, Aug 23, 2019 at 03:17:53PM -0700, Ralph Campbell wrote:
Signed-off-by: Ralph Campbell
mm/hmm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/hmm.c b/mm/hmm.c
index 29371485fe94..4882b83aeccb 100644
+++ b/mm/hmm.c
@@ -292,6
From: Rob Clark
The extra line-break in traces was annoying me.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #122 from ReddestDream ---
Tested 5.3-rc6. Still has the same issues. Only it's maybe actually worse
because I lose display completely when I use amdgpu.dpm=2 w/Radeon VII
multimonitor on 5.3-rc6, whereas on 5.2.9 I just got
From: Rob Clark
It attempted to avoid fps drops in the presence of cursor updates. But
it is racing, and can result in hw updates after flush before vblank,
which leads to underruns.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 41 ++---
1 - 100 of 196 matches
Mail list logo
