On 10/19/20 2:54 AM, Laurent Pinchart wrote:
> Hi Marek,
Hi,
> Thank you for the patch.
>
> On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
>> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
>> select input pixel data sampling edge. Add DT property "pixelcl
On Fri, 2020-10-16 at 12:14 -0500, Rob Herring wrote:
> On Tue, Oct 13, 2020 at 04:52:05PM +0800, Chunfeng Yun wrote:
> > Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
> >
>
> There's some refactoring of usb-hcd.yaml and XHCI schema under review
> and this may need some ref
On Fri, 2020-10-16 at 12:00 -0500, Rob Herring wrote:
> On Tue, Oct 13, 2020 at 04:52:00PM +0800, Chunfeng Yun wrote:
> > Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2: modify description and compatible definition suggested by Rob
On Fri, 2020-10-16 at 12:04 -0500, Rob Herring wrote:
> On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote:
> > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2: modify description and compatible
> > ---
> > .../bindings/phy/
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am won
On 9/28/20 12:30 PM, Alexandru Gagniuc wrote:
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
voltage before the reset sequence is initiated. On most boards, this
assumption is true at boot-up, so initialization succeeds.
However, when we try to initialize the chip with inco
On Fri, 2020-10-16 at 12:05 -0500, Rob Herring wrote:
> On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote:
> > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2: modify description and compatible
> > ---
> > .../bindings/phy/
On 10/16/20 7:44 PM, Sam Ravnborg wrote:
> Hi Marek.
Hi,
> On Sat, Oct 03, 2020 at 01:07:26AM +0200, Marek Vasut wrote:
>> The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
>> or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode.
>
> So after reading this paragrahp
Hi Alex.
On Mon, Oct 19, 2020 at 08:24:40PM -0500, Alex G. wrote:
> On 9/28/20 12:30 PM, Alexandru Gagniuc wrote:
> > On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
> > voltage before the reset sequence is initiated. On most boards, this
> > assumption is true at boot-up, so
On Mon, Oct 19, 2020 at 11:43:53AM +0800, Kever Yang wrote:
> Hi Daniel,
>
> On 2020/10/15 下午11:23, Daniel Vetter wrote:
> > On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:
> > > Hi Maintainers,
> > >
> > > Does this patch ready to merge?
> > Would maybe be good to get some acks
On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> In particular, converting the async atomic commit (for cursor updates,
> etc) to SCHED_FIFO kthread_worker helps with some cases where we
> wouldn't manage to flush the updates within the 1ms-before-vblank
> deadline
On Mon, 19 Oct 2020, Anshuman Gupta wrote:
> Add support for multiple mst stream in hdcp port data
> which will be used by RepeaterAuthStreamManage msg and
> HDCP 2.2 security f/w for m' validation.
>
> v2:
> Init the hdcp port data k for HDMI/DP SST strem.
>
> Cc: Ramalingam C
> Signed-off-by: A
Yes, please! That approach looks even better than what I had in mind.
A few comments below:
Am 20.10.20 um 06:16 schrieb Dave Airlie:
From: Dave Airlie
[SNIP]
+ /* don't go from system->vram in one hop,
+ report this back to the caller tell it
+ where to bounce this bu
On Fri, Oct 16, 2020 at 07:10:56AM -0300, Melissa Wen wrote:
> Hi,
>
> Thanks for this improvement.
>
> I could see that it increased the IGT test coverage, including now the
> fbdev test cases.
>
> On 10/10, Daniel Vetter wrote:
> > Hooray for generic fbdev support, making this a oneliner. We
There's a confusion between the preferred_depth uapi and the generic
fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
they don't match. Which hit me with vkms, which wants that.
All other drivers setting this and using the generic fbdev helpers use
16, where both numbers match
On 2020-10-20 at 11:31:37 +0300, Jani Nikula wrote:
> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
> > Add support for multiple mst stream in hdcp port data
> > which will be used by RepeaterAuthStreamManage msg and
> > HDCP 2.2 security f/w for m' validation.
> >
> > v2:
> > Init the hdcp port data
On Tuesday, October 20, 2020 10:35 AM, Daniel Vetter
wrote:
> There's a confusion between the preferred_depth uapi and the generic
> fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
> they don't match. Which hit me with vkms, which wants that.
>
> All other drivers setting t
Hi
On 20.10.20 10:35, Daniel Vetter wrote:
> There's a confusion between the preferred_depth uapi and the generic
> fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
> they don't match. Which hit me with vkms, which wants that.
>
> All other drivers setting this and using the
Am 20.10.20 um 00:22 schrieb Dave Airlie:
From: Dave Airlie
This was adding size to start, but pfn and start are in pages,
so it should be using num_pages.
Not sure this fixes anything in the real world, just noticed it
during refactoring.
Oh, yes it most likely does!
Signed-off-by: Dave A
You can just nuke the whole handling.
As far as I can see ttm_bo_move_memcpy() is never used with overlapping
memory objects because those are illegal in TTM for other reasons.
Christian.
Am 20.10.20 um 00:22 schrieb Dave Airlie:
From: Dave Airlie
start is in page units, so compare with pa
Am 20.10.20 um 00:22 schrieb Dave Airlie:
From: Dave Airlie
This is stored in the mem field, everywhere that a new mem is
created, the bo->mem is either copied or this field is copied
explicitly.
In generally yes, but I would like to have a bo->size field instead.
See we have a bunch of allo
On 10/19/20 8:27 PM, Dmitry Osipenko wrote:
19.10.2020 11:13, Mikko Perttunen пишет:
On 10/19/20 5:21 AM, Dmitry Osipenko wrote:
07.10.2020 20:12, Mikko Perttunen пишет:
+int tegra_drm_ioctl_channel_map(struct drm_device *drm, void *data,
+ struct drm_file *file)
+{
Hello, Mik
Hi Thomas.
> I'd be interested in this as well. If you could share an URL to the
> repo, I'd take a look. I think I even have a Via machine somewhere to
> give it a try.
You can find it here:
git://anongit.freedesktop.org/openchrome/drm-openchrome
Sam
On Tue, Oct 20, 2020 at 10:42 AM Simon Ser wrote:
>
> On Tuesday, October 20, 2020 10:35 AM, Daniel Vetter
> wrote:
>
> > There's a confusion between the preferred_depth uapi and the generic
> > fbdev helpers. Former wants depth, latter wants bpp, and for XRGB
> > they don't match. Which hit
On Tue, 20 Oct 2020, Anshuman Gupta wrote:
> On 2020-10-20 at 11:31:37 +0300, Jani Nikula wrote:
>> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
>> > Add support for multiple mst stream in hdcp port data
>> > which will be used by RepeaterAuthStreamManage msg and
>> > HDCP 2.2 security f/w for m' v
On Mon, 19 Oct 2020, Anshuman Gupta wrote:
> Let's define Maximum MST content streams up to four
> generically which can be supported by modern display
> controllers.
>
> Cc: Sean Paul
> Cc: Ramalingam C
> Signed-off-by: Anshuman Gupta
Hey drm-misc maintainers,
I'd like to get an ack to merge
On Tue, Oct 20, 2020 at 11:37 AM Biju Das wrote:
> dev_err_probe function simplifies error handling. So use the same in probe
> function wherever possible.
>
> Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- T
Op 20-10-2020 om 11:42 schreef Jani Nikula:
> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
>> Let's define Maximum MST content streams up to four
>> generically which can be supported by modern display
>> controllers.
>>
>> Cc: Sean Paul
>> Cc: Ramalingam C
>> Signed-off-by: Anshuman Gupta
> Hey
On 2020-10-20 at 12:39:04 +0300, Jani Nikula wrote:
> On Tue, 20 Oct 2020, Anshuman Gupta wrote:
> > On 2020-10-20 at 11:31:37 +0300, Jani Nikula wrote:
> >> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
> >> > Add support for multiple mst stream in hdcp port data
> >> > which will be used by Repeat
On Tue, 20 Oct 2020, Maarten Lankhorst
wrote:
> Op 20-10-2020 om 11:42 schreef Jani Nikula:
>> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
>>> Let's define Maximum MST content streams up to four
>>> generically which can be supported by modern display
>>> controllers.
>>>
>>> Cc: Sean Paul
>>> C
On Tue, 20 Oct 2020, Anshuman Gupta wrote:
> On 2020-10-20 at 12:39:04 +0300, Jani Nikula wrote:
>> On Tue, 20 Oct 2020, Anshuman Gupta wrote:
>> > On 2020-10-20 at 11:31:37 +0300, Jani Nikula wrote:
>> >> On Mon, 19 Oct 2020, Anshuman Gupta wrote:
>> >> > Add support for multiple mst stream in
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
This just gives the driver control over some of the bind paths.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
drivers/gpu/drm/nouveau/nouveau_bo.c| 10 ++
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
resource free already sets the domain to system, and old_mem
isn't really needed.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +---
1 file changed, 1 insertion(+), 3 delet
On Tue, Oct 20, 2020 at 11:07 AM Viresh Kumar wrote:
>
> On 12-10-20, 08:43, Rob Clark wrote:
> > On Mon, Oct 12, 2020 at 7:35 AM Daniel Vetter wrote:
> > >
> > > On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > Unfortunately, due to an dev_pm_op
On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>
> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > This is a upcoming change to clean up a new warning treewide.
> > I am wondering if the change could be one mega patch (see below) or
> > normal patch per
On Mon, Oct 19, 2020 at 7:27 PM Dmitry Osipenko wrote:
>
> 19.10.2020 11:13, Mikko Perttunen пишет:
> > On 10/19/20 5:21 AM, Dmitry Osipenko wrote:
> >> 07.10.2020 20:12, Mikko Perttunen пишет:
> >>> +int tegra_drm_ioctl_channel_map(struct drm_device *drm, void *data,
> >>> +struct
On Tue, Oct 20, 2020 at 1:24 PM Viresh Kumar wrote:
>
> On 20-10-20, 12:56, Daniel Vetter wrote:
> > Yeah that's bad practice. Generally you shouldn't need to hold locks
> > in setup/teardown code, since there's no other thread which can
> > possible hold a reference to anything your touching anym
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
This moves the to system move into the drivers, and moves all
the unbinds in the move path under driver control
Note: radeon/nouveau already wait so don't duplicate it.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
--
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
The drivers now control this, so drop unbinding.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/d
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
This show the remaining bind callback, which my next series of
patches will aim to remove.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 16 +---
drivers/gpu/drm/t
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
The drivers now do this in the move callback.
move_notify is still needed in the destroy path.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 13 +--
drivers/gpu/
Am 20.10.20 um 03:03 schrieb Dave Airlie:
From: Dave Airlie
This moves the call to tt binding into the driver move,
and drops the driver callback.
Signed-off-by: Dave Airlie
amdgpu should now get some cleanup, but that is certainly not topic of
this patch.
Really nice work, patch is Revi
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-bu
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and wri
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drive
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Teste
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modi
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either sys
On 10/20/20 2:40 PM, Daniel Vetter wrote:
On Mon, Oct 19, 2020 at 7:27 PM Dmitry Osipenko wrote:
19.10.2020 11:13, Mikko Perttunen пишет:
On 10/19/20 5:21 AM, Dmitry Osipenko wrote:
07.10.2020 20:12, Mikko Perttunen пишет:
+int tegra_drm_ioctl_channel_map(struct drm_device *drm, void *data,
On Tuesday, October 13, 2020 4:26 PM, Simon Ser wrote:
> On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
> pankaj.laxminarayan.bharad...@intel.com wrote:
>
> > Now, Sameer has implemented Integer scaling in Kodi Retro gaming
> > framework which demonstrate how Integer scaling gives distinc
Am 20.10.20 um 14:20 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
v2 version of this series has added below two patch in this series.
[PATCH v2 09/15] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
[PATCH v2 10/15] drm/hdcp: Max MST content streams
([PATCH v2 10/15] has received an Ack from drm-misc maintainer
in separate patch https://patchwork.freedesktop.o
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
update_pipe instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actually hdcp->value was ENABLED.
T
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gup
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 5 +-
driver
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c| 12 +++---
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
1 file
This requires for HDCP 2.2 MST check link.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/d
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
v2:
Init the hdcp port data k for HDMI/DP SST strem.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types
Enable HDCP 2.2 over DP MST.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/dri
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.
Cc: Tomas Winkler
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/misc/mei/hdcp
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/d
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Acked-by: Maarten Lankhorst
Signed-off-by: Anshuman Gupta
---
include/drm/drm_hdcp.h | 8
1 file changed, 4 insertions(+), 4 deletions(
On 10/19/20 12:42 PM, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
>>> From: Tom Rix
>>>
>>> This is a upcoming change to clean up a new warning treewide.
>>> I am wondering if the change could be o
On 10/19/2020 8:29 PM, Jordan Crouse wrote:
On Mon, Oct 19, 2020 at 06:49:18PM +0530, Akhil P Oommen wrote:
On targets with a6xx gpu, there is a duplicate gpu icc node listed in
the interconnect summary. On these targets, calling
This first sentence is confusing to me. I think the following fe
On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
>
> On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > In particular, converting the async atomic commit (for cursor updates,
> > etc) to SCHED_FIFO kthread_worker helps with some cases where we
> > wouldn't
On 10/19/20 4:05 PM, Jason Gunthorpe wrote:
> On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
>> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
>>> On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
From: Tom Rix
This is a upcoming change to clean
On Tue, Oct 20, 2020 at 4:24 AM Viresh Kumar wrote:
>
> On 20-10-20, 12:56, Daniel Vetter wrote:
> > Yeah that's bad practice. Generally you shouldn't need to hold locks
> > in setup/teardown code, since there's no other thread which can
> > possible hold a reference to anything your touching anym
On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > In particular, converting the async atomic commit (for cursor updates,
> > > etc) to SCHE
It's the horror and shouldn't be used. Realized we're not clear on
this in a discussion with Rob about what msm is doing to better
support async commits.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vette
Also cc Sean, who reviewed the msm patch to double down on the
not-so-awesome async solution (I think at least, I'm still not
entirely sure what's all going on there):
commit 2d99ced787e3d0f251fa370d2aae83cf2085a8d9
Author: Rob Clark
Date: Thu Aug 29 09:45:16 2019 -0700
drm/msm: async commi
Hi
On 20.10.20 16:39, Daniel Vetter wrote:
> It's the horror and shouldn't be used. Realized we're not clear on
> this in a discussion with Rob about what msm is doing to better
> support async commits.
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripar
On Tue, Oct 13, 2020 at 12:11:29AM +0530, Pankaj Bharadiya wrote:
> Integer scaling (IS) is a nearest-neighbor upscaling technique that
> simply scales up the existing pixels by an integer
> (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
> works by filling in the missing color
On Mon, Oct 19, 2020 at 11:08:27PM -0400, Vitaly Prosyak wrote:
>
> On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
> > On Fri, 16 Oct 2020 16:50:16 +0300
> > Ville Syrjälä wrote:
> >
> >> On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> >>> On Fri, 9 Oct 2020 17:20:18 +0300
> >>>
Hi Alex.
On Tue, Oct 20, 2020 at 09:01:27AM -0500, Alex G. wrote:
>
>
> On 10/20/20 2:16 AM, Sam Ravnborg wrote:
> > Hi Alex.
>
> [snip]
>
> > >
> > >
> > > > diff --git a/drivers/gpu/drm/bridge/sii902x.c
> > > > b/drivers/gpu/drm/bridge/sii902x.c
> > > > index 33fd33f953ec..d15e9f2c0d8a 10
On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
>
> On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
> >
> > On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
> > >
> > > On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > In particular, co
Kodi patches are reviewed and accepted for merge now.
Here is the userspace patch series link:
https://github.com/xbmc/xbmc/pull/18567
Background on Integer scaling:
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer (i.e., whol
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
chan
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest so
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the fu
On Tue, Oct 20, 2020 at 4:55 PM Thomas Zimmermann wrote:
>
> Hi
>
> On 20.10.20 16:39, Daniel Vetter wrote:
> > It's the horror and shouldn't be used. Realized we're not clear on
> > this in a discussion with Rob about what msm is doing to better
> > support async commits.
> >
> > Cc: Rob Clark
>
It's the horror and shouldn't be used. Realized we're not clear on
this in a discussion with Rob about what msm is doing to better
support async commits.
v2: Refine existing todo item to include this (Thomas)
Cc: Sean Paul
Cc: Rob Clark
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: M
On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Oct 19, 2020 at 02:10:50PM -0700, Rob Clark
On Mon, Oct 19, 2020 at 3:43 PM Kevin Brace wrote:
>
> Hi Sam,
>
> Thanks for asking the question.
> The current OpenChrome DRM code has these two major issues.
>
> 1) It does not support atomic modesetting
>
> I do internally have working code to support atomic modesetting, but it is
> not ready
The pull request you sent on Mon, 19 Oct 2020 15:21:40 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f9915b964c25193a6be1aed744c946d6ff177149
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
>
> On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
> >
> > On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
> > >
> > > On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
> > > >
> > > > On Tue, Oct 20, 2020 at 1:24 AM Daniel Vetter wro
On Tue, Oct 20, 2020 at 1:17 PM Alex Deucher wrote:
>
> On Mon, Oct 19, 2020 at 3:43 PM Kevin Brace wrote:
> >
> > Hi Sam,
> >
> > Thanks for asking the question.
> > The current OpenChrome DRM code has these two major issues.
> >
> > 1) It does not support atomic modesetting
> >
> > I do interna
For the docs:
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Oct 20, 2020 at 7:23 PM Rob Clark wrote:
>
> On Tue, Oct 20, 2020 at 10:02 AM Daniel Vetter wrote:
> >
> > On Tue, Oct 20, 2020 at 5:08 PM Rob Clark wrote:
> > >
> > > On Tue, Oct 20, 2020 at 7:29 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Oct 20, 2020 at 4:01 PM Rob Clark wrote:
On Tue, 20 Oct 2020, Anshuman Gupta wrote:
> Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
> It is based upon the actual number of MST streams and size
> of wired_cmd_repeater_auth_stream_req_in.
> Excluding the size of hdcp_cmd_header.
>
> Cc: Tomas Winkler
> Cc: Ramalingam C
1 - 100 of 112 matches
Mail list logo
