On Mon, Nov 29, 2021 at 04:43:23PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Split the readN()/writeN() helpers out into an igt_io module, so they
> can be re-used by tests.
>
> Signed-off-by: Rob Clark
> ---
> lib/igt_io.c| 96 +
> lib/i
On 02-12-21, 14:51, Stephen Boyd wrote:
> Quoting Stephen Boyd (2021-09-14 12:49:13)
> > Quoting Kuogee Hsieh (2021-09-14 09:45:01)
> > > Both voltage and pre-emphasis swing level are set during link training
> > > negotiation between host and sink. There are totally four tables added.
> > > A volt
Hi all,
On 12/7/21 13:26, Heikki Krogerus wrote:
> +Hans and Imre
>
> On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
>> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
>>> On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
(CC+ Heikki)
>> [..]
On Wed
On Tue 07 Dec 08:56 PST 2021, Hans de Goede wrote:
> Hi all,
>
> On 12/7/21 13:26, Heikki Krogerus wrote:
> > +Hans and Imre
> >
> > On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
> >> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
> >>> On Wed, Oct 06, 2021 at 01:26:35PM
On Thu, Dec 02, 2021 at 02:26:58PM -0800, Stephen Boyd wrote:
> This series is from discussion we had on reordering the device lists for
> drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
> the aggregate device onto and then we probe the aggregate device once
> all the componen
On Tue, Dec 07, 2021 at 02:26:05PM +0200, Heikki Krogerus wrote:
> +Hans and Imre
> [...]
>
> Originally I wanted an API that we could use to pass all the details
> that we have in the USB Type-C drivers (that would be the
> configuration and status) to the GPU drivers, but Hans was against
> that
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divided the driver life cycle of operation into four states,
resume (including
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Scaler and pixel_ext configuration does not contain a long living state,
it is used only during plane update, so remove these two fiels from
dpu_plane_state and allocate them on stack.
s/fiels/fields
apart from that,
Reviewed-by: Abhinav Kumar
+ Dan C for awareness as this is a follow up of our discussion on
https://lore.kernel.org/linux-arm-msm/c1537b326b654f05be247ca61d21e...@codeaurora.org/T/
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
The _dpu_hw_sspp_setup_scaler3 (hw_sspp->setup_scaler) does not use pe
argument. Let's remove i
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Add DPU_SSPP_CSC_ANY denoting any CSC block. As we are at it, rewrite
DPU_SSPP_SCALER (any scaler) to use BIT(x) instead of hand-coded
bitshifts.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dp
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Client driven prefetch (CDP) is properly setup only for SSPP REC0
currently. Enable client driven prefetch also for SSPP REC1.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 12 ++
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host.
The later functionality is already suppurted by the panel-bridge driver,
which wraps drm panel into the drm bridge instance. Using it w
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to communicate with DSI devices at the pre-enable() callback. The
reason is that for some DSI hosts enabling the video stream would
prevent other drivers
Currently the msm_dp_*** functions implement the same sequence which would
happen when drm_bridge is used. hence get rid of this intermediate layer
and align with the drm_bridge usage to avoid customized implementation.
Signed-off-by: Kuogee Hsieh
Changes in v2:
-- revise commit text
-- rename d
On 11/25/2021 10:01 AM, Dmitry Baryshkov wrote:
Commit 739b4e7756d3 ("drm/msm/dsi: Fix an error code in
msm_dsi_modeset_init()") changed msm_dsi_modeset_init() to return an
error code in case msm_dsi_manager_validate_current_config() returns
false. However this is not an error case, but a slav
16 matches
Mail list logo
