Reviving the patch posted by Sean initially.
This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The
patches are tested on SDM845 MTP platform using the kernel based on [1].
Part of the dependent drivers are already posted on list. Rest of the
dependencies are met using
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
On Thu, Nov 01, 2018 at 05:03:15PM -0400, Sean Paul wrote:
> On Wed, Oct 10, 2018 at 10:15:59AM -0700, Chandan Uddaraju wrote:
> > Add the needed DP PLL specific files to support
> > display port interface on msm targets.
> >
> > The DP driver calls the DP PLL driver registration.
> > The DP
On Wed, Oct 10, 2018 at 10:15:59AM -0700, Chandan Uddaraju wrote:
> Add the needed DP PLL specific files to support
> display port interface on msm targets.
>
> The DP driver calls the DP PLL driver registration.
> The DP driver sets the link and pixel clock sources.
>
> Signed-off-by: Chandan
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
> DPU was using one thread per display to dispatch async
> commits and vblank requests. Since clean up already happened
> in msm to use the common thread for all the display commits,
> display threads are only used to cater vblank
On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
> msm maintains a separate structure to define vblank
> work definitions and a list to track events submitted
> to the display worker thread. We can avoid these
> redundant list and its protection mechanism, if we
> subclass the
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
> DPU was using one thread per display to dispatch async
> commits and vblank requests. Since clean up already happened
> in msm to use the common thread for all the display commits,
> display threads are only used to cater vblank
Hey Chris,
On 2018-11-01 17:26, Chris Wilson wrote:
Quoting Robert Foss (2018-11-01 16:12:28)
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
Quoting Robert Foss (2018-11-01 16:12:28)
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
> ---
>
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
1 file changed, 5 insertions(+), 5
On Thu, Nov 01, 2018 at 02:05:41PM +0530, Sharat Masetty wrote:
> When the userspace tries to read the crashstate dump, the read side
> implementation in the driver currently ascii85 encodes all the binary
> buffers and it does this each time the read system call is called.
> A userspace tool like
When the userspace tries to read the crashstate dump, the read side
implementation in the driver currently ascii85 encodes all the binary
buffers and it does this each time the read system call is called.
A userspace tool like cat typically does a page by page read and the
number of read calls
When the userspace tries to read the crashstate dump, the read side
implementation in the driver currently ascii85 encodes all the binary
buffers and it does this each time the read system call is called.
A userspace tool like cat typically does a page by page read and the
number of read calls
On 2018-10-24 22:09, Matthias Kaehlcke wrote:
Hi Sravanthi,
On Wed, Oct 10, 2018 at 02:54:33PM +0530, Sravanthi Kollukuduru wrote:
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a
14 matches
Mail list logo
