tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e2425464bc87159274879ab30f9d4fe624b9fcd2 Add linux-next specific
files for 20240105
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202401061458.1ympozgi-...@intel.com
Error
On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip wrote:
>
>
> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> > For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
> > possible to support this platform via the DPU driver (e.g. to provide
> > support for DP, multirect, etc). Add a
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
Include the actual CTL_FLUSH value into the timeout message. This allows
us to identify the DPU block that gets stuck.
Signed-off-by: Dmitry Baryshkov
---
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Co-developed-by: Konrad Dybcio
Signed-off-by: Konrad
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms supported by both drivers are by default handled
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
Signed-off-by: Dmitry Baryshkov
---
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU driver asks for it.
It is not possible to generate
: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240105-fd-migrate-mdp5-6a2aa51bc83b
Best regards,
--
Dmitry Baryshkov
On Thu, Jan 4, 2024 at 3:17 PM Jani Nikula wrote:
>
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
>
> There are some files that get drm/drm_edid.h by proxy; include it where
> needed.
>
> v2-v4: Fix build (kernel test robot )
>
> Cc: Rob Clark
> Cc:
Hi Jani,
On Thu, Jan 04, 2024 at 10:16:32PM +0200, Jani Nikula wrote:
> hdmi-codec.h does not appear to directly need drm/drm_edid.h for
> anything. Remove it.
>
> There are some files that get drm/drm_edid.h by proxy; include it where
> needed.
>
> v2-v4: Fix build (kernel test robot )
>
>
11 matches
Mail list logo