Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:45PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> After converting all DSI drivers, unexport the specific transfer
> functions.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Re
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:46PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This drops the virtual channel logic. Afterwards DSI clients
> request their channel number and get the virtual channel with
> the same number or -EBUSY
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:47PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Simplify the write related messages handling by using the functionality
> provided by CONFIG_DRM_MIPI_DSI.
>
> Signed-off-by: Sebastian Reichel
> Signe
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:48PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Simplify the read related message handling by using the functionality
> provided by CONFIG_DRM_MIPI_DSI.
>
> Signed-off-by: Sebastian Reichel
> Signed-
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:49PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Simplify the DSI encoder by using mipi_dsi_msg for
> dsi_vc_send_long and dsi_vc_send_short. Further improvements
> require cleaning up the channel alloc
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:50PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This moves from custom platform driver infrastructure to mipi_dsi_host
> and mipi_dsi_device. Note, that this is a graduate step and the driver
> only us
Hi Andreas,
On Sun, Nov 1, 2020 at 1:47 PM Andreas Schwab wrote:
> On Nov 01 2020, Sam Ravnborg wrote:
> > On Sun, Nov 01, 2020 at 11:29:41AM +0100, Geert Uytterhoeven wrote:
> >> The horizontal resolution (640) for the TT High video mode (1280x960) is
> >> definitely bogus. While fixing that, c
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:51PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> After converting the driver to mipi_dsi_device we can use the generic
> message helpers to simplify the driver a lot.
>
> Signed-off-by: Sebastian Reich
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:52PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Drop custom request_vc/release_vc callbacks by using the
> generic mipi_dsi_attach/mipi_dsi_detach functions.
>
> Signed-off-by: Sebastian Reichel
> Si
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:53PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Use dsi->channel everywhere, which originates from DT.
I'm not sure DT is the right place to provide this information, but
that's an issue broader than this patch ser
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:54PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Drop local definition of common MIPI DCS 1.3 defines.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/om
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:55PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> memory_read is not used, so we can drop the code.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:56PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The get_te() callback is not used, so we can drop the
> custom API.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
You could sq
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:57PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> enable_te() is not used, so the custom API can be dropped.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:58PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The DSI sync() function only locks the bus and then releases
> it again. Currently the only invocation is directly before
> update(), which locks the bus
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:02:59PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> In order to reduce the amount of custom functionality, this moves
> handling of pixel format and DSI mode from set_config() to dsi
> attach.
>
> Signed-
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:00PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Use bulk regulator API to simplify the code. This also switches
> from _optional variant to normal variant, which will provide a
> dummy regulator (i.e.
On 09-11-20, 08:10, Dmitry Osipenko wrote:
> 09.11.2020 07:47, Dmitry Osipenko пишет:
> > 09.11.2020 07:43, Viresh Kumar пишет:
> >> On 08-11-20, 15:19, Dmitry Osipenko wrote:
> >>> I took a detailed look at the GENPD and tried to implement it. Here is
> >>> what was found:
> >>>
> >>> 1. GENPD fra
09.11.2020 07:47, Dmitry Osipenko пишет:
> 09.11.2020 07:43, Viresh Kumar пишет:
>> On 08-11-20, 15:19, Dmitry Osipenko wrote:
>>> I took a detailed look at the GENPD and tried to implement it. Here is
>>> what was found:
>>>
>>> 1. GENPD framework doesn't aggregate performance requests from the
>>
On 09-11-20, 08:08, Dmitry Osipenko wrote:
> 09.11.2020 08:00, Viresh Kumar пишет:
> > On 06-11-20, 21:41, Frank Lee wrote:
> >> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
> >>>
> >>> 06.11.2020 09:15, Viresh Kumar пишет:
> Setting regulators for count as 0 doesn't sound good to me
s/doens't/doesn't/p
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 7cc7af2a6822..a92cb137293a 100
09.11.2020 08:35, Viresh Kumar пишет:
> On 09-11-20, 08:19, Dmitry Osipenko wrote:
>> Thanks, I made it in a different way by simply adding helpers to the
>> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
>> add new kernel symbols.
>
> I will prefer to add it in core.c itse
On Fri, 2020-11-06 at 08:55 -0400, Jason Gunthorpe wrote:
> On Fri, Nov 06, 2020 at 11:27:59AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter
> > wrote:
> > > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard
> > > wrote:
> > > > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
On 06-11-20, 21:41, Frank Lee wrote:
> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
> >
> > 06.11.2020 09:15, Viresh Kumar пишет:
> > > Setting regulators for count as 0 doesn't sound good to me.
> > >
> > > But, I understand that you don't want to have that if (have_regulator)
> > > chec
09.11.2020 07:43, Viresh Kumar пишет:
> On 08-11-20, 15:19, Dmitry Osipenko wrote:
>> I took a detailed look at the GENPD and tried to implement it. Here is
>> what was found:
>>
>> 1. GENPD framework doesn't aggregate performance requests from the
>> attached devices. This means that if deviceA re
09.11.2020 08:10, Viresh Kumar пишет:
> On 09-11-20, 08:08, Dmitry Osipenko wrote:
>> 09.11.2020 08:00, Viresh Kumar пишет:
>>> On 06-11-20, 21:41, Frank Lee wrote:
On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
>
> 06.11.2020 09:15, Viresh Kumar пишет:
>> Setting regulator
On 09-11-20, 08:44, Dmitry Osipenko wrote:
> 09.11.2020 08:35, Viresh Kumar пишет:
> > On 09-11-20, 08:19, Dmitry Osipenko wrote:
> >> Thanks, I made it in a different way by simply adding helpers to the
> >> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
> >> add new kernel
09.11.2020 08:00, Viresh Kumar пишет:
> On 06-11-20, 21:41, Frank Lee wrote:
>> On Fri, Nov 6, 2020 at 9:18 PM Dmitry Osipenko wrote:
>>>
>>> 06.11.2020 09:15, Viresh Kumar пишет:
Setting regulators for count as 0 doesn't sound good to me.
But, I understand that you don't want to ha
On 09-11-20, 08:19, Dmitry Osipenko wrote:
> Thanks, I made it in a different way by simply adding helpers to the
> pm_opp.h which use devm_add_action_or_reset(). This doesn't require to
> add new kernel symbols.
I will prefer to add it in core.c itself, and yes
devm_add_action_or_reset() looks be
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:01PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Integrate low-power / high-speed bus switching into transfer
> function and drop the omapdrm specific enable_hs() callback.
>
> Signed-off-by: Sebastian
On 2020-10-30 14:53, Sai Prakash Ranjan wrote:
Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the
On 08-11-20, 15:19, Dmitry Osipenko wrote:
> I took a detailed look at the GENPD and tried to implement it. Here is
> what was found:
>
> 1. GENPD framework doesn't aggregate performance requests from the
> attached devices. This means that if deviceA requests performance state
> 10 and then devic
On Sun, 2020-11-08 at 11:04 +0800, Chun-Kuang Hu wrote:
> + Vinod:
>
> Hi, Chunfeng:
>
> Chun-Kuang Hu 於 2020年10月29日 週四 下午11:28寫道：
> >
> > Mediatek MIPI DSI phy driver is moved from drivers/gpu/drm/mediatek to
> > drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
> > infor
Hi Lee,
Lee Jones wrote on Fri, 6 Nov 2020 21:36:32
+:
> 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.
>
> v1 => v2:
> - Added tags
> - Satisfied Miquel's review comments
>
You
On Fri, Nov 6, 2020 at 1:42 PM Thomas Zimmermann wrote:
>
> Apparently, the function was never used at all.
>
> Signed-off-by: Thomas Zimmermann
Thanks Thomas,
As agreed, please apply to drm-misc-next
-Patrik
> ---
> drivers/gpu/drm/gma500/gem.c | 6 --
> drivers/gpu/drm/gma500/psb_d
Am 09.11.20 um 01:54 schrieb Dave Airlie:
From: Dave Airlie
Currently drivers get called to move a buffer, but if they have to
move it temporarily through another space (SYSTEM->VRAM via TT)
then they can end up with a lot of ttm->driver->ttm call stacks,
if the temprorary space moves requires
Am 09.11.20 um 01:54 schrieb Dave Airlie:
From: Dave Airlie
This removes the code to move resources directly between
SYSTEM and VRAM in favour of using the core ttm mulithop code.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 136 +++-
1 file
On 06/11/2020 07:03, Viresh Kumar wrote:
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so
there is no need for us to carry the extra check. Drop them.
Signed-off-by: Viresh Kumar
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 ++
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:02PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> In preparation for removing custom DSS calls from the DSI
> panel driver, this moves support for external tearing event
> GPIOs into the DSI host driver.
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:03PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Instead of using the custon enable_te() API, this automatically
s/custon/custom/
> enables/disables TE core support when a matching packet is send
s/s
[New] Support AST2600
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_main.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 467049ca8430..6b9e3b94a712 100
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:04PM +0200, Tomi Valkeinen wrote:
> 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-of
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:05PM +0200, Tomi Valkeinen wrote:
> 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 comm
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:06PM +0200, Tomi Valkeinen wrote:
> 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
> Si
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:07PM +0200, Tomi Valkeinen wrote:
> 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-
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:08PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Complete the direction reversal of the DSS device enable/disable
> operations started by 19b4200d8f4b ("drm/omap: Reverse direction
> of the DSS device e
Hi
Am 05.11.20 um 10:47 schrieb KuoHsiang Chou:
> [Bug] Change the vertical synchroous polary of 1920x1080 @60Hz
> from Negtive to Positive
>
> Signed-off-by: KuoHsiang Chou
I've merged this patch. Thanks!
Best regards
Thomas
> ---
> drivers/gpu/drm/ast/ast_tables.h | 4 ++--
> 1 file
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:09PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Due to previous changes the DSI encoder gets the capabilities
> via DSI client's mode_flags and no longer needs the omapdss
> specific caps. The core cod
Hi
Am 09.11.20 um 10:38 schrieb KuoHsiang Chou:
> [New] Support AST2600
A style issue: better write a nice sentence than these tags. For the
patch at hand, I'd preferred something like: "Only add an id for
supporting AST2600. No functional changes are required."
I assume that there areno furthe
Fixes a build failure with mediatek.
This change was supposed to be part of commit 49a3f51dfeee ("drm/gem:
Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but
mediatek was forgotten.
Signed-off-by: Thomas Zimmermann
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM
Commit 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and
convert GEM backends") changed DRM's internal GEM vmap callbacks. Msm and
mediatek were forgotten during the conversion.
Thomas Zimmermann (2):
drm/msm: Use struct dma_buf_map in GEM vmap ops
drm/mediatek: Use struct dma
Fixes a build failure with msm.
This change was supposed to be part of commit 49a3f51dfeee ("drm/gem:
Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but
msm was forgotten.
Signed-off-by: Thomas Zimmermann
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops a
On Thu, Nov 05, 2020 at 02:03:10PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This converts the DSI module to expect common drm_panel display
> drivers instead of dssdev based ones.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
> ---
> .../gpu/drm/omapdr
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:11PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The table of compatible values needed to be prefixed with "omapdss,"
> is empty, so all of this code is doing nothing now. Let's drop it.
\o/
> Signed-
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:12PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Implement check timings, which will check if its possible to
s/its/it's/
> configure the clocks for the provided mode using the same code
> as the set_
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:13PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR,
> which makes the code a bit shorter and easier to read.
>
> Signed-off-by: Sebastian Reichel
>
Hi Tomi and Sebastian,
On Thu, Nov 05, 2020 at 02:03:14PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Now, that the driver implements the common DRM panel API
> the unbind no longer needs to be suppressed.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Ac
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:15PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Do not try to reset the panel after DSI has been
> detached, since the DSI clocks may have been disabled
> at this point. The panel will be disabled and
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:16PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> We can simply provide the device to the omapdrm driver
> via pdata. omapdss_is_initialized() is no longer required
> (even before this patch), since omap
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:17PM +0200, 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
>
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:18PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> In order to integrate with a chain of drm_bridge, the internal DSI
> output has to expose its operations through the drm_bridge API.
> Register a bridge
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:19PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> All DSS devices have been converted to bridge API, so
> the device operations are always NULL. This removes
> the device ops function pointers and all co
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:20PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Remove unused code. Connectors are now created via drm_bridge_connector_init()
> and no longer OMAP specific.
>
> Signed-off-by: Sebastian Reichel
> Si
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:21PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> We no longer need to check for the DSS API, since all encoders,
> panels and connectors have been converted to the bridge API.
>
> Signed-off-by: Sebast
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:22PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Since all encoders and panels are using the bridge API now,
> we next pointer is no longer useful and can be dropped.
I would squash this with the previ
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:23PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Cleanup empty functions for encoder enable, disable and atomic check.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Reviewed-b
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:24PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> The omapdss device's ops_flags field is no longer
> used and can be dropped.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Tomi Valkeinen
Rev
On Sat, 07 Nov 2020, Sam Ravnborg wrote:
> Hi Lee,
>
> On Fri, Nov 06, 2020 at 09:49:40PM +, Lee Jones wrote:
> > Unfortunately, a suitable one didn't already exist.
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no p
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:25PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> All displays are using drm_panel instead off dssdev
drm_panel or a drm_bridge that models the connected.
> now, so this field is always 0 and can be dr
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:26PM +0200, Tomi Valkeinen wrote:
> 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.
>
>
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:27PM +0200, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> Simplify DSI pin config, which always originates from DT
> nowadays. With the code being fully contained in the DSI
> encoder, we can drop the public str
Hi Tomi and Sebastian,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:28PM +0200, Tomi Valkeinen wrote:
> 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
From: Colin Ian King
There are two spelling mistakes of the word sync in drm_info
and drm_dbg messages. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/kmb/kmb_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/g
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:30PM +0200, Tomi Valkeinen wrote:
> The functions in display.c are not used, so drop the file.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/Makefile | 2 +-
> drivers/gpu
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:29PM +0200, Tomi Valkeinen wrote:
> At the moment we have three different modules: omapdss-base, omapdss,
> omapdrm. This setup is finally obsolete, as the last omapdrm specific
> panel has been converted to DRM panel.
>
> We can th
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:31PM +0200, Tomi Valkeinen wrote:
> dssdev->owner is set, but never used. We can drop the field.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dpi.c | 1 -
> drivers/gpu
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:32PM +0200, Tomi Valkeinen wrote:
> 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
Hi Tomi,
Thank you for the patch.
On Thu, Nov 05, 2020 at 02:03:33PM +0200, Tomi Valkeinen wrote:
> 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
Acked-by: Laurent Pinchart
>
On Wed, Nov 04, 2020 at 04:58:14PM -0500, Lyude Paul wrote:
> ACK, I will send out a patch for this asap
Any update. AFAICS, v5.10-rc3 is still buggy.
--
Kirill A. Shutemov
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
On 07/11/2020 14:19, H. Nikolaus Schaller wrote:
> I have set up based on our complete letux-5.10-rc2 tree and maybe using our
> private config makes
> the difference. Anyways, the driver is now probed and I can see the call to
> w677l_get_modes().
>
> I have still no image and no calls to prep
On 05/11/2020 14:02, Tomi Valkeinen wrote:
> From: Sebastian Reichel
>
> This drops the virtual channel logic. Afterwards DSI clients
> request their channel number and get the virtual channel with
> the same number or -EBUSY if already in use.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-
On 09/11/2020 10:14, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
>
> Thank you for the patch.
>
> On Thu, Nov 05, 2020 at 02:02:46PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel
>>
>> This drops the virtual channel logic. Afterwards DSI clients
>> request their channel number and
Hi,
On Mon, Nov 09, 2020 at 12:08:33PM +0200, Tomi Valkeinen wrote:
> On 09/11/2020 11:52, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 05, 2020 at 02:03:04PM +0200, Tomi Valkeinen wrote:
> >> From: Sebastian Reichel
> >>
> >> This moves the bus lock
On 09/11/2020 10:49, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
>
> Thank you for the patch.
>
> On Thu, Nov 05, 2020 at 02:02:59PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel
>>
>> In order to reduce the amount of custom functionality, this moves
>> handling of pixel format an
On 09/11/2020 10:45, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
>
> Thank you for the patch.
>
> On Thu, Nov 05, 2020 at 02:02:56PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel
>>
>> The get_te() callback is not used, so we can drop the
>> custom API.
>>
>> Signed-off-by: Sebast
On 09/11/2020 11:52, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thu, Nov 05, 2020 at 02:03:04PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel
>>
>> This moves the bus locking into the host driver and unexports
>> the custom API in preparation for drm_panel s
On 09/11/2020 11:30, H. Nikolaus Schaller wrote:
>
>> Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen :
>>
>> On 07/11/2020 14:19, H. Nikolaus Schaller wrote:
>>
>>> I have set up based on our complete letux-5.10-rc2 tree and maybe using our
>>> private config makes
>>> the difference. Anyways, the
On 09/11/2020 12:31, H. Nikolaus Schaller wrote:
>
>> Am 09.11.2020 um 11:22 schrieb Tomi Valkeinen :
>>
>> On 09/11/2020 11:30, H. Nikolaus Schaller wrote:
>>>
Am 09.11.2020 um 09:04 schrieb Tomi Valkeinen :
On 07/11/2020 14:19, H. Nikolaus Schaller wrote:
> I have set up
On 10/31/20 1:13 AM, Dmitry Osipenko wrote:
28.10.2020 12:54, Mikko Perttunen пишет:
On 10/27/20 9:06 PM, Dmitry Osipenko wrote:
26.10.2020 12:11, Mikko Perttunen пишет:
The first patches should be the ones that are relevant to the existing
userspace code, like support for the waits.
Can yo
On Wed, Nov 11, 2020 at 06:13:02PM +0100, Christian König wrote:
> Am 09.11.20 um 01:54 schrieb Dave Airlie:
> > @@ -1432,15 +1479,18 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
> > if (bo->mem.mem_type != TTM_PL_SYSTEM) {
> > struct ttm_operation_ctx ctx = { false, false }
On 09/11/2020 10:42, Laurent Pinchart wrote:
> Hi Tomi and Sebastian,
>
> Thank you for the patch.
>
> On Thu, Nov 05, 2020 at 02:02:52PM +0200, Tomi Valkeinen wrote:
>> From: Sebastian Reichel
>>
>> Drop custom request_vc/release_vc callbacks by using the
>> generic mipi_dsi_attach/mipi_dsi_det
On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> The stack is too full.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> ‘sideband_msg_req_encode_decode’:
> drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:
Hi Lee,
> >
> > Other public functions in radeon_device.c have their prototype in
> > radeon.h - for example radeon_is_px()
> >
> > Add radeon_device_is_virtual() there so we avoiid this new header.
>
> Oh yes, I remember why this wasn't a suitable solution now:
>
> The macro "radeon_init" in r
On 09/11/2020 13:09, H. Nikolaus Schaller wrote:
>>> I see.
>>> Anyways there is missing some simple thing which makes the driver not
>>> prepared/enabled.
>>> Or is this related to VC?
>>
>> No, that's not related to the VC.
>
> Ok, then it is worth searching for that independently. Any idea/hi
On 00:57-20201030, Laurent Pinchart wrote:
> Hi Nikhil,
>
> Thank you for the patch.
>
> On Fri, Oct 16, 2020 at 04:09:14PM +0530, Nikhil Devshatwar wrote:
> > When there is a chain of bridges attached to the encoder,
> > the bus_format should be ideally set from the input format of the
> > first
On Fri, Nov 6, 2020 at 9:10 AM Christian König
wrote:
>
> The pool parameter can be NULL if we free through the shrinker.
>
> Signed-off-by: Christian König
Does this fix:
https://gitlab.freedesktop.org/drm/amd/-/issues/1362
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 2
Am 09.11.20 um 16:16 schrieb Ville Syrjälä:
On Wed, Nov 11, 2020 at 06:13:02PM +0100, Christian König wrote:
Am 09.11.20 um 01:54 schrieb Dave Airlie:
@@ -1432,15 +1479,18 @@ int ttm_bo_swapout(struct ttm_operation_ctx *ctx)
if (bo->mem.mem_type != TTM_PL_SYSTEM) {
struc
On Mon, 09 Nov 2020, Sam Ravnborg wrote:
> Hi Lee,
> > >
> > > Other public functions in radeon_device.c have their prototype in
> > > radeon.h - for example radeon_is_px()
> > >
> > > Add radeon_device_is_virtual() there so we avoiid this new header.
> >
> > Oh yes, I remember why this wasn't
On Mon, 09 Nov 2020, Ville Syrjälä wrote:
> On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> > The stack is too full.
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
> > ‘sideband_msg_req_encode_decode
On Mon, 09 Nov 2020, Lee Jones wrote:
> On Mon, 09 Nov 2020, Ville Syrjälä wrote:
>
> > On Thu, Nov 05, 2020 at 02:45:12PM +, Lee Jones wrote:
> > > The stack is too full.
> > >
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/gpu/drm/selftests/test-drm_dp_mst_hel
1 - 100 of 223 matches
Mail list logo
