Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Drop the assigned clock rate property and vote on the mdp clock to
max frequency during bind/probe sequence.
Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during
resume sequence.
- Add fixes tag.
Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)
- Add
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
Set mdp clock to max clock rate during probe/bind sequence from the
opp table so that rails are not at undetermined state. Since we do not
know what will be the rate set in boot loader, it would be ideal to
vote at max frequency. There could be a firmware display programmed
in bootloader and we
Drop the assigned clock rate property and vote on the mdp clock as per
calculated value during the usecase.
This patch is dependent on the patch ("drm/msm/disp/dpu1: set mdp clk
to the maximum frequency in opp table during probe") [1].
[1]
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Make vc4 driver use the new API so that the embedded encoder model
can be retained in the driver and there is no change in
functionality.
changes in v5:
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware,
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote:
> On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote:
> > > drm: Add drm_mode_init()
> > > drm/bridge: Use drm_mode_copy()
> > > drm/imx: Use
Hi Liviu
On 3/21/2022 11:07 AM, Liviu Dudau wrote:
On Thu, Mar 17, 2022 at 10:26:38AM -0700, Abhinav Kumar wrote:
Hi Laurent
Thanks for the review.
On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
Hi Abhinav,
Thank you for the patch.
On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar
Hi Livid
Thanks for your review.
All your comments are valid. I think I should re-order the patches like
you have suggested. That should address all comments.
Thanks
Abhinav
On 3/21/2022 10:24 AM, Liviu Dudau wrote:
On Thu, Mar 17, 2022 at 06:45:34PM -0700, Abhinav Kumar wrote:
For some
On Thu, Mar 17, 2022 at 10:26:38AM -0700, Abhinav Kumar wrote:
> Hi Laurent
>
> Thanks for the review.
>
> On 3/17/2022 1:51 AM, Laurent Pinchart wrote:
> > Hi Abhinav,
> >
> > Thank you for the patch.
> >
> > On Wed, Mar 16, 2022 at 11:48:16AM -0700, Abhinav Kumar wrote:
> > > For some vendor
On Mon, 21 Mar 2022 at 19:21, Vinod Polimera wrote:
>
>
>
> > -Original Message-
> > From: Stephen Boyd
> > Sent: Friday, March 18, 2022 2:41 AM
> > To: quic_vpolimer ;
> > devicet...@vger.kernel.org; dri-de...@lists.freedesktop.org;
> > freedreno@lists.freedesktop.org;
On Thu, Mar 17, 2022 at 06:45:34PM -0700, Abhinav Kumar wrote:
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupts can
> also be shared between
Hi,
On Thu, Mar 17, 2022 at 06:45:33PM -0700, Abhinav Kumar wrote:
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_writeback_connector_init() and make
> -Original Message-
> From: Stephen Boyd
> Sent: Friday, March 18, 2022 2:41 AM
> To: quic_vpolimer ;
> devicet...@vger.kernel.org; dri-de...@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; robdcl...@gmail.com;
19 matches
Mail list logo
