On Tue, Dec 08, 2020 at 02:39:15PM -0800, Jianxin Xiong wrote:
> 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
>
On Tue, Dec 08, 2020 at 02:39:12PM -0800, Jianxin Xiong wrote:
> 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
Hi Tomi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on linus/master v5.10-rc7]
[cannot apply to drm-tip/drm-tip anholt/for-next next-20201208]
[If your patch is applied to the wrong git tree, kindly drop us
Hi Andrey,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc7
next-20201208]
[cannot apply to drm/drm-next
On Tue, Dec 8, 2020 at 3:16 PM Andrey Grodzovsky
wrote:
>
> For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
> was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
> and amdgpu_gem_object_funcs setting into single function called
> from both code
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/gt/intel_mocs.c: In function 'get_mocs_settings':
drivers/gpu/drm/i915/gt/intel_mocs.c:363:22: error: 'GEN11_NUM_MOCS_ENTRIES'
undeclared (first use in this function); did
On Wed, Dec 09, 2020 at 02:07:35AM +0530, Sumera Priyadarsini wrote:
> Update the vkms documentation to contain steps to:
>
> - setup the vkms driver
> - run tests using igt
>
> Signed-off-by: Sumera Priyadarsini
> ___
> Changes in v2:
> - Change heading to title case (Daniel)
> - Add
On Tue, Dec 08, 2020 at 05:55:11PM +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Dec 08, 2020 at 03:57:58PM +0200, Tomi Valkeinen wrote:
> > We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> > be used to handle legacy gamma-set ioctl.
On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
> Use devm_drm_irq_install to register interrupts so that
> drm_irq_uninstall is not needed to be called.
>
> Signed-off-by: Tian Tao
There's another drm_irq_install in the error path. But I'm not sure this
is safe since you're chaning
On Mon, Dec 07, 2020 at 11:20:58AM +0800, Liu Ying wrote:
> Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning.
> The precedent has already been set by other macros in the same file.
>
> Signed-off-by: Liu Ying
Acked-by: Daniel Vetter
I'm assuming someone will push this
On Sun, Dec 06, 2020 at 04:34:15PM +, Simon Ser wrote:
> The previous wording could be understood by user-space evelopers as "a
> primary/cursor plane is only compatible with a single CRTC" [1].
>
> Reword the planes description to make it clear the DRM-internal
> drm_crtc.primary and
On Mon, Dec 07, 2020 at 09:10:00AM +, Simon Ser wrote:
> On Monday, December 7th, 2020 at 9:45 AM, Pekka Paalanen
> wrote:
>
> > > > > > > - * Cursor and overlay planes are optional. All drivers should
> > > > > > > provide one
> > > > > > > - * primary plane per CRTC to avoid surprising
On Mon, Dec 07, 2020 at 09:54:13PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Daniel Vetter
> >Sent: Friday, December 4, 2020 3:03 PM
> >To: DRI Development
> >Cc: Daniel Vetter ; Vetter, Daniel
> >
> >Subject: [PATCH] dma-buf: Fix kerneldoc
On Fri, Dec 04, 2020 at 04:11:35PM +0100, Maxime Ripard wrote:
> If we're having two subsequent, non-blocking, commits on two different
> CRTCs that share no resources, there's no guarantee on the order of
> execution of both commits.
>
> However, the second one will consider the first one as the
On Sat, Dec 05, 2020 at 08:57:38PM +0200, Laurent Pinchart wrote:
> Hi Philipp,
>
> On Fri, Dec 04, 2020 at 11:12:20AM +0100, Philipp Zabel wrote:
> > On Fri, 2020-12-04 at 11:17 +0200, Laurent Pinchart wrote:
> > > On Fri, Sep 11, 2020 at 03:57:18PM +0200, Philipp Zabel wrote:
> > > > Add an
On Fri, Dec 04, 2020 at 09:28:33AM +0800, Tian Tao wrote:
> patch #1 add a new file to implements i2c adapters, #2 read the
> resolution from the edid, if that fails, set the resolution to fixed.
> patch #3 update the destroy callback function to release the i2c adapters.
>
> Tian Tao (3):
>
On Fri, Dec 04, 2020 at 09:47:08AM +0100, Christian König wrote:
> Am 04.12.20 um 09:32 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 03.12.20 um 21:41 schrieb Daniel Vetter:
> > > On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am 03.12.20 um 16:26
On Mon, Dec 07, 2020 at 05:45:02PM +0200, Tomi Valkeinen wrote:
> On 07/12/2020 17:31, Ville Syrjälä wrote:
> > On Sat, Dec 05, 2020 at 12:35:25AM +0200, Laurent Pinchart wrote:
> >> Hi Tomi,
> >>
> >> Thank you for the patch.
> >>
> >> On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen
On Tue, Dec 08, 2020 at 04:02:16PM -0600, Bjorn Andersson wrote:
> On Tue 08 Dec 06:47 CST 2020, Thierry Reding wrote:
>
> > On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> > > Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> > > means of generating a PWM
On Sun, Nov 29, 2020 at 11:48:17PM -0800, Wendy Liang wrote:
> Xilinx AI engine array can be partitioned statically for different
> applications. In the device tree, there will be device node for the AI
> engine device, and device nodes for the statically configured AI engine
> partitions. Each of
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
Reviewed-by: Leon Romanovsky
---
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
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
This is the fourteenth version of the patch set. Changelog:
v14:
* Check return value of dma_fence_wait()
* Fix a dma-buf leak in ib_umem_dmabuf_get()
* Fix return value type cast for ib_umem_dmabuf_get()
* Return -EOPNOTSUPP instead of -EINVAL for unimplemented functions
* Remove an unnecessary
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
On Tue, Dec 8, 2020 at 7:21 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Tue, Dec 8, 2020 at 6:26 AM Arnd Bergmann wrote:
> >
> > On Mon, Dec 7, 2020 at 11:28 PM 'Nick Desaulniers' via Clang Built
> > Linux wrote:
> Hmm...no warnings for me with t
On Tue, Dec 8, 2020 at 3:16 PM Andrey Grodzovsky
wrote:
>
> For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
> was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
> and amdgpu_gem_object_funcs setting into single function called
> from both code
Update the vkms documentation to contain steps to:
- setup the vkms driver
- run tests using igt
Signed-off-by: Sumera Priyadarsini
___
Changes in v2:
- Change heading to title case (Daniel)
- Add examples to run tests directly (Daniel)
- Add examples to run subtests (Melissa)
---
On Tue, Dec 08, 2020 at 02:33:54PM +0200, Jani Nikula wrote:
> The VBT fields match the DPCD data, so use the same helper.
>
> Cc: Manasi Navare
> Cc: Vandita Kulkarni
> Signed-off-by: Jani Nikula
Only for DSI so far right?
In that case looks good
Reviewed-by: Manasi Navare
Manasi
> ---
On Tue, Dec 08, 2020 at 02:33:52PM +0200, Jani Nikula wrote:
> Move the intialization of the rc_model_size from the common code into
> encoder code, allowing different encoders to specify the size according
> to their needs. Keep using the hard coded value in the encoders for now
> to make this a
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
and amdgpu_gem_object_funcs setting into single function called
from both code paths.
Fixes: d693def4fd1c ("drm: Remove obsolete GEM and PRIME
On 08/12/2020 17:38, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Dec 08, 2020 at 02:28:37PM +0200, Tomi Valkeinen wrote:
>> To start fixing the issues related to channels and vcs described in the
>> previous commit, pass vc to various functions which will need it
> -Original Message-
> From: Jason Gunthorpe
> Sent: Tuesday, December 08, 2020 10:59 AM
> To: Xiong, Jianxin
> Cc: Leon Romanovsky ; linux-r...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; Doug Ledford
> ; Sumit Semwal ; Christian
> Koenig ; Vetter, Daniel
>
> Subject: Re:
Am 08.12.20 um 20:11 schrieb Andrey Grodzovsky:
On 12/8/20 2:01 PM, Christian König wrote:
Am 08.12.20 um 19:52 schrieb Andrey Grodzovsky:
On 12/8/20 1:47 PM, Christian König wrote:
Am 08.12.20 um 19:44 schrieb Andrey Grodzovsky:
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um
On 12/8/20 2:01 PM, Christian König wrote:
Am 08.12.20 um 19:52 schrieb Andrey Grodzovsky:
On 12/8/20 1:47 PM, Christian König wrote:
Am 08.12.20 um 19:44 schrieb Andrey Grodzovsky:
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20
On Tue, Dec 08, 2020 at 06:13:20PM +, Xiong, Jianxin wrote:
> > -Original Message-
> > From: Leon Romanovsky
> > Sent: Monday, December 07, 2020 11:06 PM
> > To: Xiong, Jianxin
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug
> > Ledford ; Jason Gunthorpe ;
Am 08.12.20 um 19:52 schrieb Andrey Grodzovsky:
On 12/8/20 1:47 PM, Christian König wrote:
Am 08.12.20 um 19:44 schrieb Andrey Grodzovsky:
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um
On 12/8/20 1:47 PM, Christian König wrote:
Am 08.12.20 um 19:44 schrieb Andrey Grodzovsky:
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs
Hi Philipp,
On Tue, Dec 08, 2020 at 04:54:33PM +0100, Philipp Zabel wrote:
> Simple managed encoders do not require the .destroy callback,
> make the whole funcs structure optional.
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> ---
> New in v4.
> ---
>
Am 08.12.20 um 19:44 schrieb Andrey Grodzovsky:
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs imported from outside of amdgpu, setting of
On 12/8/20 1:29 PM, Christian König wrote:
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in
Am 08.12.20 um 19:26 schrieb Andrey Grodzovsky:
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs imported from outside of amdgpu, setting of
amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO
creation
On 12/8/20 12:36 PM, Christian König wrote:
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
and amdgpu_gem_object_funcs setting into single
> -Original Message-
> From: Leon Romanovsky
> Sent: Monday, December 07, 2020 11:06 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> Subject: Re: [PATCH
On Sun, Dec 06, 2020 at 08:02:34PM +0100, Sam Ravnborg wrote:
> Following the great work of Lee Jones in other subsystems
> here is a set of patches that address all remaining W=1
> warnings in drivers/video/.
> Lee Jones already fixed all warnings in video/backlight/ so
> this is mostly fbdev
To support legacy gamma ioctls the drivers need to set
drm_crtc_funcs.gamma_set either to a custom implementation or to
drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
latter.
We can simplify this by making the core handle it automatically.
Add two functions:
We currently have drm_atomic_helper_legacy_gamma_set() helper which can
be used to handle legacy gamma-set ioctl.
drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
CTM and DEGAMMA_LUT. This works fine on HW where we have either:
degamma -> ctm -> gamma -> out
or
ctm -> gamma ->
Hi,
This is v2 of the series.
The first patch fixes legacy gamma table for HW which have a degamma lut
block before CTM block, but no gamma lut after the CTM. This will allow
us to add CTM support to omapdrm, which only has "pre-gamma" i.e.
de-gamma table.
The second one cleans up the legacy
On Mon, Dec 07, 2020 at 11:58:44AM -0800, James Bottomley wrote:
> On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > > and that function is
On Mon, Dec 07, 2020 at 03:28:03PM -0400, Jason Gunthorpe wrote:
> On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > Just as a side note. I was looking at tpm_tis_probe_irq_single() and
> > that function is leaking the interrupt request if any of the checks
> > afterwards fails,
Am 08.12.20 um 18:10 schrieb Andrey Grodzovsky:
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
and amdgpu_gem_object_funcs setting into single function called
from both code paths.
Can you
On Tue, Dec 8, 2020 at 12:10 PM Andrey Grodzovsky
wrote:
>
> For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
> was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
> and amdgpu_gem_object_funcs setting into single function called
> from both code
For BOs imported from outside of amdgpu, setting of amdgpu_gem_object_funcs
was missing in amdgpu_dma_buf_create_obj. Fix by refactoring BO creation
and amdgpu_gem_object_funcs setting into single function called
from both code paths.
This fixes null ptr regression casued by commit
d693def drm:
Panel drivers can send DSI commands in panel's prepare(), which happens
before the bridge's enable() is called. The OMAP DSI driver currently
only sets up the DSI interface at bridge's enable(), so prepare() cannot
be used to send DSI commands.
This patch fixes the issue by making it possible to
ULPS doesn't work, and I have been unable to get it to work. As ULPS is
a minor power-saving feature which requires substantial amount of
non-trivial code, and we have trouble just getting and
keeping DSI working at all, remove ULPS support.
When the DSI driver works reliably for command and
We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when
the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this
right by accident, but now we set DCS_CMD_ENABLE for video mode panels
too.
Fix this by skipping the set for video mode.
Signed-off-by: Tomi Valkeinen
We can drop dsi_display_disable() which just calls
_dsi_display_disable(), and rename _dsi_display_disable() to
dsi_display_disable().
The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_disable is extra and
can be dropped, as _dsi_display_disable() has the same WARN_ON().
Signed-off-by: Tomi
Clean up the code by separating video-mode enable/disable code into
functions of their own.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 101 +-
1 file changed, 57 insertions(+), 44 deletions(-)
diff --git
Add a panel database to the driver instead of reading propertes from DT
data. This is similar to panel-simple, and I believe it's more future
safe way to handle the panels.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 107
Drop unneeded includes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
b/drivers/gpu/drm/panel/panel-dsi-cm.c
index
Clean up the code by inlining dsi_enable_video_outputs and
dsi_disable_video_outputs functions.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 55 +--
1 file changed, 22 insertions(+), 33 deletions(-)
diff --git
For command mode panels we can use a single VC for sending command and
video data, even if we have to change the data source for that VC when
going from command to video or vice versa.
However, with video mode panels we want to keep the pixel data VC
enabled, and use another VC for command data,
The driver ignores MIPI_DSI_CLOCK_NON_CONTINUOUS, and always uses
non-continuous clock.
Fix this by using MIPI_DSI_CLOCK_NON_CONTINUOUS and at the same time,
drop ddr_clk_always_on field which seems pretty useless.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
As we now have a fixed setup for VCs (VC0 for video stream, VC1 for
commands), we can simplify the VC setup.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 85 +++
1 file changed, 31 insertions(+), 54 deletions(-)
diff --git
We can drop dsi_display_enable(), which just calls
_dsi_display_enable(), and rename _dsi_display_enable() to
dsi_display_enable().
The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_enable is extra and
can be dropped, as _dsi_display_enable() has the same WARN_ON().
Signed-off-by: Tomi
The function names have evolved to be very confusing, and bunch of them
have "display" in them even if the function doesn't deal with display as
such (e.g. dsi_display_enable which just enables the DSI interface).
Rename them by dropping the "display".
Signed-off-by: Tomi Valkeinen
Reviewed-by:
We have a useless 'if' in the dsicm_bl_update_status(), a left over from
the conversion to DRM model. Drop the if.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
Move structs and defines to a private dsi.h header file to make dsi.c a
bit easier to navigate. Also move the (now) private structs and defines
from omapdss.h to dsi.h.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 384
We currently use a single VC for sending commands and pixel data. The
LP/HS mode for pixel data is correctly set to HS by accident, as we have
set the VC to HS already earlier.
However, if we use a different VC for video data, the VC is in LP mode.
Fix this by always enabling HS mode before
DSI virtual channel and hardware VC blocks have gotten tangled as
described in the previous commits. This has not caused any issues, as
the value for both is 0, so it happens to work.
To fix the issue, change the code to use the correct one of the two.
Signed-off-by: Tomi Valkeinen
---
Simplify the code by moving code from _dsicm_enable_te() into
dsicm_power_on().
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff
The "channel" usage in omap dsi driver is confusing. As the first step,
change "channel" to "dispc_channel" when dealing with the dispc channel.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
A DSI peripheral can have virtual channel ID of 0-3. This should be
always the case, and there's no need in the driver to validate the
channel.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 11 ---
1 file changed, 11 deletions(-)
Simplify and optimize dsi_vc_enable_hs() so that it can be called
without checking the current HS/LP mode. Make dsi_vc_enable_hs() return
if the VC is already in the correct mode.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 10 --
To start fixing the issues related to channels and vcs described in the
previous commit, pass vc to various functions which will need it do
properly handle different DSI channels and VCs.
No functional changes.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 54
The "channel" usage in omap dsi driver is confusing. We have three
different "channels":
1) DSI virtual channel ID. This is a number from 0 to 3, included in the
packet payload.
2) VC. This is a register block in the DSI IP. There are four of those
blocks. A VC is a DSI "pipeline", with defined
The VC handling has gotten quite tangled up. As the first step to clean
it up, lets define that we only support a single DSI peripheral (which
was really already the case), and we always use VC0 (define VC_DEFAULT
0) register block to send data to the peripheral.
We can thus have a single
Add address-cells & size-cells to DSI nodes so that board files do not
need to define them.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
Acked-by: Tony Lindgren
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi
The OMAP DSI command mode panel driver used to send page & column
address before each frame update, and this code was moved into the DSI
host driver when converting it to the DRM bridge model.
However, it's not really required to send the page & column address
before each frame. It's also
The DSI host driver currently ignores the video mode flags in
client->mode_flags. Add the code to take the transfer mode from client's
mode_flags.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 7 +++
1 file changed, 7 insertions(+)
Hi,
This is version 5 of the series OMAP DSI conversion series. Previous
version can be found from:
https://www.spinics.net/lists/linux-omap/msg157480.html
To lessen the patch spam, I'm sending only patches starting from patch
56/80. There has been no changes to the patches before 56/80.
Diff
Set the column & page address once during setup, instead of relying the
DSI host driver to set those.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 20
1 file changed, 20 insertions(+)
If the PLL calc function is given bad parameters, n_start/m_start may be
higher than n_stop/m_stop, which leads to the loops iterating through
the whole u32 number space.
Fix this by failing early on such cases.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
https://bugzilla.kernel.org/show_bug.cgi?id=210543
--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your full dmesg output.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
Hi Tomi,
Thank you for the patch.
On Tue, Dec 08, 2020 at 03:57:59PM +0200, Tomi Valkeinen wrote:
> To support legacy gamma ioctls the drivers need to set
> drm_crtc_funcs.gamma_set either to a custom implementation or to
> drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
>
On Tue, 2020-12-08 at 16:54 +0100, Philipp Zabel wrote:
> Hi,
>
> this is an update of the drmm_(simple_)encoder_alloc(),
> drmm_universal_plane_alloc(), and drmm_crtc_alloc_with_plane()
> functions in v3 [1] together with the imx-drm managed allocation
> conversion from [2] as an example usage.
Use drmm_simple_encoder_alloc() to align encoder memory lifetime with
the drm device. drm_encoder_cleanup() is called automatically before
the memory is freed.
Also fold imx_tve_register() into imx_tve_bind().
Signed-off-by: Philipp Zabel
---
Changes since v3:
- use drmm_simple_encoder_alloc()
Add an alternative to drm_simple_encoder_init() that allocates and
initializes a simple encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
---
Changes since v3:
- drop drmm_simple_encoder_funcs_empty, now that
Use drmm_universal_plane_alloc() to align plane memory lifetime with
the drm device. drm_plane_cleanup() is called automatically before the
memory is freed.
Also move the call to ipu_plane_get_resources() into ipu_plane_init()
and use drm managed resources to put IPU resources automatically when
Use use drmm_crtc_alloc_with_planes() to align crtc memory lifetime
with the drm device. drm_crtc_cleanup() is called automatically before
the memory is freed.
Also use drmm_add_action_or_reset() to make sure IPU resources are
released automatically.
Signed-off-by: Philipp Zabel
---
Changes
Introduce local variables for encoder and connector.
This simplifies the following commits.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-tve.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c
Use drmm_simple_encoder_alloc() to align encoder memory lifetime with
the drm device. drm_encoder_cleanup() is called automatically.
Signed-off-by: Philipp Zabel
---
Changes since v3:
- use drmm_simple_encoder_alloc()
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 25 +
1 file
Parts of the initialization that do not require the drm device can be
done once during probe instead of possibly multiple times during bind.
The bind function only creates the encoder and attaches the bridge.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 74
Parts of the initialization that do not require the drm device can be
done once during probe instead of possibly multiple times during bind.
The bind function only creates the encoder.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-tve.c | 42 ---
1
Add an alternative to drm_encoder_init() that allocates and initializes
an encoder and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
---
Changes since v3:
- allow the funcs parameter to __drmm_encoder_alloc() to be
Add an alternative to drm_universal_plane_init() that allocates
and initializes a plane and registers drm_plane_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/drm_plane.c | 126 +++-
Use drmm_simple_encoder_alloc() to align encoder memory lifetime with
the drm device. drm_encoder_cleanup() is called automatically before
the memory is freed.
Signed-off-by: Philipp Zabel
---
Changes since v3:
- use drmm_simple_encoder_alloc()
---
drivers/gpu/drm/imx/parallel-display.c | 57
Use drmm_simple_encoder_alloc() to align encoder memory lifetime with
the drm device. drm_encoder_cleanup() is called automatically before
the memory is freed.
Signed-off-by: Philipp Zabel
---
Changes since v3:
- use drmm_simple_encoder_alloc()
---
drivers/gpu/drm/imx/imx-ldb.c | 31
Use local variables for bridge and connector.
This simplifies the following commits.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
Simple managed encoders do not require the .destroy callback,
make the whole funcs structure optional.
Signed-off-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
---
New in v4.
---
drivers/gpu/drm/drm_encoder.c | 4 ++--
drivers/gpu/drm/drm_mode_config.c | 5 +++--
1 - 100 of 213 matches
Mail list logo
