On 2020-11-06 at 10:52:03 +0530, Anshuman Gupta wrote:
> On 2020-11-05 at 21:04:03 +0530, Ramalingam C wrote:
> > On 2020-10-27 at 22:11:58 +0530, Anshuman Gupta wrote:
> > > Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
> > > in TRANS_DDI_FUNC_CTL in order to enable/disable
On 2020-11-06 at 10:20:35 +0530, Anshuman Gupta wrote:
> On 2020-11-05 at 22:09:12 +0530, Ramalingam C wrote:
> > On 2020-10-27 at 22:12:00 +0530, Anshuman Gupta wrote:
> > > Pass dig_port as an argument to intel_hdcp_init()
> > > and intel_hdcp2_init().
> > > This will be required for HDCP 2.2 str
On Thu, 05 Nov 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Thu, Nov 05, 2020 at 02:45:14PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value
> > 'ILI9322_INPUT_SRGB_THROUGH' not described in
On Thu, 05 Nov 2020, Ahmad Fatoum wrote:
> Hello Lee,
>
> On 11/5/20 3:45 PM, Lee Jones wrote:
> > In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
> > as a container for state->crtcs[i].new_state, but is not utilised in
> > this use-case. We cannot simply delete the variabl
On 11/5/2020 2:28 AM, Rob Clark wrote:
On Wed, Nov 4, 2020 at 12:03 PM Rob Herring wrote:
On Fri, 30 Oct 2020 16:17:12 +0530, Akhil P Oommen wrote:
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
Revie
Hi
Am 06.11.20 um 01:31 schrieb Kuo-Hsiang Chou:
> To Sir
>
> Yes, I ran scripts/checkpatch.pl and cleared 3 errors about tailing spaces.
>
> OK, would you please give me the mail-address of Daniel?
It's
> And will be removed from CC.
Thanks!
> Because I ran get_maintainers.pl and got the
On 2020-11-05 at 21:11:52 +0530, Ramalingam C wrote:
> On 2020-10-27 at 22:11:59 +0530, Anshuman Gupta wrote:
> > Enable HDCP 1.4 over DP MST for Gen12.
> > This also enable the stream encryption support for
> > older generations, which was missing earlier.
> It will be nice to have them in separat
On 2020-11-05 at 22:04:15 +0530, Ramalingam C wrote:
> On 2020-10-27 at 22:12:04 +0530, 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 h
On 2020-11-05 at 21:04:03 +0530, Ramalingam C wrote:
> On 2020-10-27 at 22:11:58 +0530, Anshuman Gupta wrote:
> > 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.
> >
> >
On 2020-11-05 at 22:15:37 +0530, Ramalingam C wrote:
> On 2020-10-27 at 22:12:05 +0530, Anshuman Gupta wrote:
> > This requires for HDCP 2.2 MST check link.
> >
> > Cc: Ramalingam C
> > Reviewed-by: Uma Shankar
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/display/intel_di
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:44PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This converts the panel-dsi-cm driver to use the transfer
> API instead of specific functions, so that the specific
> functions can be unexported and squ
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:43PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This prepares the driver for becoming a mipi_dsi_host implementation,
> which provides a generic transfer function instead of all kind of
> different rea
On 2020-11-05 at 22:09:12 +0530, Ramalingam C wrote:
> On 2020-10-27 at 22:12:00 +0530, Anshuman Gupta wrote:
> > 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
> > Reviewed-by: Uma S
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:42PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The write buffers are not modified, so they can be constant.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Lauren
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:41PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This replaces OMAP specific enum for pixel format with
> common implementation.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:40PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The panel-dsi-cm's ddata->pin_config is always NULL, so this
> callback is never called. Instead the DSI encoder gets the pin
> configuration directly fr
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:39PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This reverts commit 4ff8e98879e6eeae9d125dfcf3b642075d00089d.
With this fixed as requested by Sam,
Reviewed-by: Laurent Pinchart
> This is still need
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:38PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> DSI command mode panels are self-refreshing displays, that
> can be updated very rarely for static images. For this kind
> of scenario some panels suppor
Hi Lee,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:45:06PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_status’:
> drivers/gpu/drm/omapdrm/dss/dsi.c:1131:6: warning: variable ‘l’ set but
Hey Linus,
It's Friday here so that means another installment of drm fixes to
distract you from the counting process.
Changes all over the place, the amdgpu changes contain support for a
new GPU that is close to current one already in the tree (Green
Sardine) so it shouldn't have much side effect
On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
/*
* If we can't determine whether or not a pte is special, then fail immediately
* for ptes. Note, we can still pin HugeTLB and THP as these are guaranteed not
* to be special.
*
On 2020-11-05 10:36, Daniel Vetter wrote:
> On Wed, Nov 04, 2020 at 11:04:25AM +0100, Daniel Vetter wrote:
>> From: Luben Tuikov
>>
>> Make the definition of struct drm_driver
>> a constant, to follow the latest developments
>> in the DRM layer.
>>
>> Signed-off-by: Luben Tuikov
>> [danvet: Rebas
Make use of the devm_drm_dev_alloc() API to bind the lifetime of
nouveau_drm structure to the drm_device. This is important because a
reference to nouveau_drm is accessible from drm_device, which is
provided to a number of DRM layer callbacks that can run after the
deallocation of nouveau_drm curre
Start on documentation for the Nouveau device structure and the NVIF
client structure it uses. This documentation is not complete as the
structures are non-trivial and I am not familiar with large portions of
them.
Signed-off-by: Jeremy Cline
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 67 ++
Hi folks,
Currently, when the device is removed (or the driver is unbound) the
nouveau_drm structure de-allocated. However, it's still accessible from
and used by some DRM layer callbacks. For example, file handles can be
closed after the device has been removed (physically or otherwise). This
ser
In order to use the resource-managed allocation of a struct drm_device
instance, it is recommended to embed the drm_device instance within the
driver-specific structure.
As there is already a helper to convert a drm_device to a nouveau_drm
struct, this adds an inverse function and changes all dire
On Fri, Oct 30, 2020 at 4:48 AM Dan Carpenter
wrote:
> This is freed both here and in the caller (virtio_gpu_vram_map()) so
> it's a double free. The correct place is only in the caller.
>
> Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram
> object")
> Signed-off-by: Da
To Sir,
Is the mail-address of "daniel.vet...@intel.com" correct for Daniel?
Because, got the message of " The current directory does not appear to be a
linux kernel source tree. " after running get_maintainers.pl
So, find Daniel out by gitk /drivers/gpu/drm/ast
Have a good day,
Kuo-Hsi
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, November 05, 2020 4:25 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
To Sir
Yes, I ran scripts/checkpatch.pl and cleared 3 errors about tailing spaces.
OK, would you please give me the mail-address of Daniel? And
will be removed from CC.
Because I ran get_maintainers.pl and got the result of " The current directory
does not appear to be a linux kernel source t
On Thu, Nov 5, 2020 at 6:57 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Changes si
Noticed this when trying to compile with -Wall on a kernel fork. We potentially
don't set width here, which causes the compiler to complain about width
potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
Changes since v1:
* Don't emit an error as this code isn't reachable, just
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
dma_virt_ops is used by virtual devices that map pages / scatterlists to
virtual addresses for CPU access instead of performing DMA. This is not
the intended use of dma_buf_attach() and dma_buf_map_attachment(). CPU
access of dma-buf should use dma_buf_vmap() and related functions.
Signed-off-by:
This is the eighth version of the patch set. Changelog:
v8:
* Modify the dma-buf sg list in place to get a proper umem sg list and
restore it before calling dma_buf_unmap_attachment()
* Validate the umem sg list with ib_umem_find_best_pgsz()
* Remove the logic for slicing the sg list at runtime
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koe
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 112 ++
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buf
On 05/11/2020 20:14, H. Nikolaus Schaller wrote:
>
>> Am 05.11.2020 um 18:36 schrieb Tomi Valkeinen :
>>
>> Hi,
>>
>> On 05/11/2020 19:15, H. Nikolaus Schaller wrote:
>>
>>> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for
>>> the panel of the Pyra handheld (omap 5 based)
Hi Dave, Daniel,
Updates for 5.11. This should merge pretty cleanly. I created a backmerge
branch[1] in case you run into any issues.
[1] https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.11-backmerge
The following changes since commit f2fa07b39fafb2a5f49c71a504862c5efa57d03e:
drm
Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes
(one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
them here.
Note that the panel datasheet requires 80 ms between HPD asserting and
the backlight power being turned on. We'll use the new timing
constraints s
Add yet another eDP panel.
Signed-off-by: Douglas Anderson
Acked-by: Rob Herring
---
(no changes since v1)
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b
The simple panel code currently allows panels to define fixed delays
at certain stages of initialization. These work OK, but they don't
really map all that clearly to the requirements presented in many
panel datasheets. Instead of defining a fixed delay, those datasheets
provide a timing diagram
Hi,
On Wed, Oct 28, 2020 at 3:58 PM Douglas Anderson wrote:
> @@ -249,18 +327,19 @@ static int panel_simple_unprepare(struct drm_panel
> *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
>
> - if (!p->prepared)
> + if (p->prepared_time != 0)
Though I swear I te
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc: Laurent Pinchart
> Signed-off-by: Rob Herring
Reviewed-by: Sam Ravnborg
I expect you to apply the patch
Hi Rob/Sameer
On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to r
Hi,
On 05/11/2020 19:15, H. Nikolaus Schaller wrote:
> Next, I migrated my long waiting mipi_dsi/drm_panel driver conversion for
> the panel of the Pyra handheld (omap 5 based) to compile on 5.10-rc2. And
> I followed the latest existing panel-orisetech-otm8009a.c which uses a
> similar video mod
Hi Tomi
On Thu, Nov 05, 2020 at 02:02:37PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> This is third version of the series sent by Sebastian in February:
>
> https://www.spinics.net/lists/linux-omap/msg153465.html
>
> I took the patches from his git tree, and rebased on 5.10-rc2. There
> were some c
Hi Tomi
On Thu, Nov 05, 2020 at 02:02:39PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This reverts commit 4ff8e98879e6eeae9d125dfcf3b642075d00089d.
Please use proper commit reference like:
2f62f4990dca ("gpu: drm: bridge: bla bla)
The above commit-id does not exist in my drm-mi
On Thu, Nov 5, 2020 at 12:21 PM Deepak R Varma wrote:
>
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> ID range and it is #defined to 1. The new function idr_init_base allows
> IDR to set the ID l
Hi Lee
On Thu, Nov 05, 2020 at 02:45:10PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c:571:5: warning: no
> previous prototype for ‘analogix_dp_write_byte_to_dpcd’ [-Wmissing-prototypes]
>
> Cc: Andrzej Hajda
Hi Lee.
On Thu, Nov 05, 2020 at 02:45:14PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value
> 'ILI9322_INPUT_SRGB_THROUGH' not described in enum 'ili9322_input'
> drivers/gpu/drm/panel/panel-ili
Hi Lee
On Thu, Nov 05, 2020 at 02:45:09PM +, Lee Jones wrote:
> Struct headers should start with 'struct '
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/panel/panel-simple.c:42: warning: Cannot understand *
> @modes: Pointer to array of fixed modes appropriate f
Hi Lee.
On Thu, Nov 05, 2020 at 02:44:59PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/host1x/bus.c:40: warning: Function parameter or member 'driver'
> not described in 'host1x_subdev_add'
>
> Cc: Thierry Reding
> Cc: dri-devel@lists.freedesktop.
Hi YueHaibing
On Mon, Nov 02, 2020 at 10:30:24PM +0800, YueHaibing wrote:
> gpiod_to_irq() return negative value in case of error,
> the existing code doesn't handle negative error codes.
> If the HPD gpio supports IRQs (gpiod_to_irq returns a
> valid number), we use the IRQ. If it doesn't (gpiod_
On 05/11/2020 16:45, Lee Jones wrote:
> The API has been updated, but the header was not.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/omapdrm/omap_irq.c:115: warning: Function parameter or
> member 'crtc' not described in 'omap_irq_enable_vblank'
> drivers/gpu/drm/
On 05/11/2020 16:45, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_status’:
> drivers/gpu/drm/omapdrm/dss/dsi.c:1131:6: warning: variable ‘l’ set but not
> used [-Wunused-but-set-variable]
> drivers/gpu/
On Wed, 04 Nov 2020 19:48:48 +0300, Dmitry Osipenko wrote:
> Memory controller is interconnected with memory clients and with the
> External Memory Controller. Document new interconnect property which
> turns memory controller into interconnect provider.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
On Wed, 04 Nov 2020 19:48:44 +0300, Dmitry Osipenko wrote:
> The SoC core voltage can't be changed without taking into account the
> clock rate of External Memory Controller. Document OPP table that will
> be used for dynamic voltage frequency scaling, taking into account EMC
> voltage requirement.
On 05/11/2020 14:03, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The panel driver is no longer using any OMAP specific APIs, so
> let's move it into the generic panel directory.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
> Cc: Thierry Reding
> Cc: Sam Ravnbor
On Thu, Nov 5, 2020 at 10:25 AM Deepak R Varma wrote:
>
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> ID range and it is #defined to 1. The new function idr_init_base allows
> IDR to set the ID l
On Tue, Nov 3, 2020 at 7:04 PM Viresh Kumar wrote:
>
> On 03-11-20, 08:50, Rob Clark wrote:
> > sorry, it didn't apply cleanly (which I guess is due to some other
> > dependencies that need to be picked back to v5.4 product kernel), and
> > due to some other things I'm in middle of debugging I did
On Thu, Nov 05, 2020 at 08:02:56PM +0100, Thomas Zimmermann wrote:
> The gma500 driver expects 3 pipelines in several it's IRQ functions.
> Accessing struct drm_device.vblank[], this fails with devices that only
> have 2 pipelines. An example KASAN report is shown below.
>
> [ 62.267688]
> ==
On Thu, Nov 05, 2020 at 01:00:19PM -0400, Jason Gunthorpe wrote:
> commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set
> pgprot_decrypted()") moves the pgprot_decrypted() into
> io_remap_pfn_range(). Delete any, now confusing, open coded calls that
> directly precede io_remap_pfn_range()
Hi
Am 05.11.20 um 17:45 schrieb Maxime Ripard:
> Many drivers reference the crtc->pointer in order to get the current CRTC
> state in their atomic_begin or atomic_flush hooks, which would be the new
> CRTC state in the global atomic state since _swap_state happened when those
> hooks are run.
>
>
The gma500 driver expects 3 pipelines in several it's IRQ functions.
Accessing struct drm_device.vblank[], this fails with devices that only
have 2 pipelines. An example KASAN report is shown below.
[ 62.267688]
==
[ 62.26885
Hi Anitha.
On Wed, Nov 04, 2020 at 05:15:24PM -0800, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the reference baord
> for Keem Bay SOC
On Thu, 05 Nov 2020, Daniel Vetter wrote:
> On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote:
> >
> > On Thu, 05 Nov 2020, Thierry Reding wrote:
> >
> > > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel
On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote:
>
> On Thu, 05 Nov 2020, Thierry Reding wrote:
>
> > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
On Thu, 05 Nov 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
>
> Thanks for looki
On Thu, 05 Nov 2020, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > There are 5000 warnings
On Thu, 05 Nov 2020, Tomi Valkeinen wrote:
> On 05/11/2020 16:45, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/omapdrm/dss/dsi.c: In function ‘_dsi_print_reset_status’:
> > drivers/gpu/drm/omapdrm/dss/dsi.c:1131:6: warning: variable ‘l’ set but
On 2020-11-05 12:30 p.m., Maxime Ripard wrote:
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Now that the CRTCs
Hi Dave and Daniel,
This includes gvt-fixes that had come last week, now with clean tags
for dim.
Also, 306bb61d6bb3 ("drm/i915/gt: Expose more parameters for emitting writes
into the ring") is only a dependency of its following patch.
In summary:
drm-intel-fixes-2020-11-05:
- GVT fixes includ
On Thu, Nov 05, 2020 at 05:35:28PM +0100, Maxime Ripard wrote:
> On Tue, Nov 03, 2020 at 06:28:24PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 03, 2020 at 05:15:51PM +0100, Maxime Ripard wrote:
> > > Hi Ville,
> > >
> > > On Mon, Nov 02, 2020 at 06:04:06PM +0200, Ville Syrjälä wrote:
> > > > On M
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There are 5000 warnings to work through.
>
> It will take a couple more sets.
On Thu, Nov 05, 2020 at 02:45:14PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/panel/panel-ilitek-ili9322.c:177: warning: Enum value
> 'ILI9322_INPUT_SRGB_THROUGH' not described in enum 'ili9322_input'
> drivers/gpu/drm/panel/panel-ilitek-ili93
On 2020-10-27 at 22:12:06 +0530, Anshuman Gupta wrote:
> Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
> and HDCP2_AUTH_STREAM register in i915_reg header.
Reviewed-by: Ramalingam C
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/i915_re
On Thu, Nov 05, 2020 at 02:44:59PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/host1x/bus.c:40: warning: Function parameter or member 'driver'
> not described in 'host1x_subdev_add'
>
> Cc: Thierry Reding
> Cc: dri-devel@lists.freedesktop.org
> Cc
On Thu, Nov 05, 2020 at 02:45:09PM +, Lee Jones wrote:
> Struct headers should start with 'struct '
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/panel/panel-simple.c:42: warning: Cannot understand *
> @modes: Pointer to array of fixed modes appropriate for this
On 2020-10-27 at 22:12:05 +0530, Anshuman Gupta wrote:
> This requires for HDCP 2.2 MST check link.
>
> Cc: Ramalingam C
> Reviewed-by: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c
Hi Lee.
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Thanks for looking into this.
> There are 5000 warnings to work through.
On 2020-10-27 at 22:12:00 +0530, Anshuman Gupta wrote:
> 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
> Reviewed-by: Uma Shankar
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i
On Thu, Nov 5, 2020 at 4:15 PM Christian König wrote:
>
> Am 05.11.20 um 15:38 schrieb Daniel Vetter:
> > On Thu, Nov 5, 2020 at 3:31 PM Daniel Vetter wrote:
> >> On Thu, Nov 5, 2020 at 2:22 PM Christian König
> >> wrote:
> >>> Am 05.11.20 um 14:20 schrieb Daniel Vetter:
> On Thu, Nov 05,
On 2020-10-27 at 22:12:04 +0530, 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.
>
> v3:
> Cosmetic changes.
: h8300-randconfig-r031-20201105 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
nommu platform?
If you have a hard time finding a cross compiler for this, there's some
nommu arm platforms. I used that for compile teesting nommu support
recently.
If it's not that, then it&#
On Thu, Nov 05, 2020 at 02:44:18AM +0300, Dmitry Osipenko wrote:
> Add initial OPP and SoC core voltage scaling support to the Tegra EHCI
> driver. This is required for enabling system-wide DVFS on older Tegra
> SoCs.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry
On 2020-10-27 at 22:12:03 +0530, 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
> Acked-by: Maarten Lankhorst
> Reviewed-by: Uma Shankar
> Signed-off-by: Ansh
From: Sebastian Reichel
The DSI command mode panel is no longer specific
to OMAP and thus the config option has been renamed
slightly.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
---
arch/arm/configs/omap2plus_defconfig | 2 +-
1 file changed, 1 insertion
dispc_ops was created to help with the multi-module architecture and
giving us the possibility of multiple dispc implementations. Neither of
these is valid anymore, and we can remove dispc_ops and use direct
calls to dispc.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c
dssdev->owner is set, but never used. We can drop the field.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 1 -
drivers/gpu/drm/omapdrm/dss/dsi.c | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 1 -
drivers/gpu/drm/omapd
dss_mgr_ops was needed with the multi-module architecture, but is no
longer needed. We can thus remove it and use direct calls.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 42 +++
drivers/gpu/drm/
The functions in display.c are not used, so drop the file.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/display.c | 58 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 --
3 files changed, 1 insertion(+), 63 d
From: Sebastian Reichel
Implement check timings, which will check if its possible to
configure the clocks for the provided mode using the same code
as the set_config() hook.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 70 +
From: Sebastian Reichel
This moves the panel refresh/update function from the panel
driver into the DSI host driver to prepare for common drm_panel
support.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 68
dri
From: Sebastian Reichel
This moves the bus locking into the host driver and unexports
the custom API in preparation for drm_panel support.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 46 +--
drivers/gpu/drm
From: Sebastian Reichel
Move dsi_ops into the main structure, since all other ops
are gone. Instead of checking the device type we can simply
check if dsi_ops are set.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 10 --
dri
From: Sebastian Reichel
The panel driver is no longer using any OMAP specific APIs, so
let's move it into the generic panel directory.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/omapdrm/Kconfig
From: Sebastian Reichel
Move ULPS handling into the DSI host controller, so that we
no longer need a custom API for the DSI client.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 273 +-
drivers/gpu/drm/omapdr
From: Sebastian Reichel
Create a custom function pointer for ULPS and use it instead of
reusing disable/enable functions for ULPS mode switch. This allows
us to use the common disable/enable functions pointers for DSI.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
---
.../gpu
1 - 100 of 313 matches
Mail list logo
