The purpose of this series is to add the display support for the mt8365-evk.
This is the list of HWs / IPs support added:
- Connectors (HW):
- HDMI
- MIPI DSI (Mobile Industry Processor Interface Display Serial Interface)
- HDMI bridge (it66121)
- DSI pannel (startek,kd070fhfid015)
- SoC displ
On Tue, 12 Dec 2023 12:52:38 -0800, Abhinav Kumar wrote:
> Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline
> which among other things has a CSC block that can convert RGB input
> from the DPU to YUV data.
>
> This block can be used with either HDMI, DP or writeback inter
Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline
which among other things has a CSC block that can convert RGB input
from the DPU to YUV data.
This block can be used with either HDMI, DP or writeback interface.
In this series, lets first add the support for CDM block to be
On Wed, 21 Sep 2022 18:43:46 +0800
Kevin Tian wrote:
> The idea is to let vfio core manage the vfio_device life cycle instead
> of duplicating the logic cross drivers. Besides cleaner code in driver
> side this also allows adding struct device to vfio_device as the first
> step toward adding cdev
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. Besides cleaner code in driver
side this also allows adding struct device to vfio_device as the first
step toward adding cdev uAPI in the future. Another benefit is that
user can now look
> On DG2, HuC loading is performed by the GSC, via a PXP command. The load
> operation itself is relatively simple (just send a message to the GSC with the
> physical address of the HuC in LMEM), but there are timing changes that
> requires special attention. In particular, to send a PXP command
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to
Please ignore this cover letter, I've only realized I was missing a
title and aborted the git-send after sending it. Proper series coming in
a couple of mins.
Daniele
On 9/8/2022 5:10 PM, Daniele Ceraolo Spurio wrote:
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
op
On DG2, HuC loading is performed by the GSC, via a PXP command. The load
operation itself is relatively simple (just send a message to the GSC
with the physical address of the HuC in LMEM), but there are timing
changes that requires special attention. In particular, to send a PXP
command we need to
From: Rob Clark
Unchanged other than small update in 09/15
original description below:
This is mostly motivated by getting drm/msm to pass an i-g-t shrinker
test that I've been working on. In particular the test creates and
cycles between more GEM buffers than what will fit in RAM to force
evi
Hello,
This patchset introduces memory shrinker for the VirtIO-GPU DRM driver.
During OOM, the shrinker will release BOs that are marked as "not needed"
by userspace using the new madvise IOCTL, it will also evict idling BOs
to SWAP. The userspace in this case is the Mesa VirGL driver, it will mar
Hello Yunfei,
Le lundi 10 janvier 2022 à 16:34 +0800, Yunfei Dong a écrit :
> This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly,
> refactor
> power/clock/interrupt interfaces for mt8192 is lat and core architecture.
>
> Secondly, add new functions to get frame buffer size
This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly,
refactor
power/clock/interrupt interfaces for mt8192 is lat and core architecture.
Secondly, add new functions to get frame buffer size and resolution according
to decoder capability from scp side. Then add callback functi
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be specified
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
On Thu, Oct 29, 2020 at 10:28 AM Christoph Hellwig wrote:
>
> On Thu, Oct 29, 2020 at 10:25:16AM +0100, Daniel Vetter wrote:
> > On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig
> > wrote:
> > >
> > > Maybe I'm missing something, but shouldn't follow_pfn be unexported
> > > at the end of the se
On Thu, Oct 29, 2020 at 9:57 AM Christoph Hellwig wrote:
>
> Maybe I'm missing something, but shouldn't follow_pfn be unexported
> at the end of the series?
kvm is a legit user and modular afaict. But since you can't use this
without an mmu_notifier anyway (or digging around in pagetable
locking)
Hi all
Round 3 of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.3509076-1-da
Hi,
On 7/11/20 8:19 AM, Uwe Kleine-König wrote:
Hi Hans,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
On 7/9/20 4:14 PM, Sam Ravnborg wrote:
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
Here is v4 of my patch series converting the i915 driver's code for
c
Hi Hans,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Here is v4 of my patch series converting the i915 driver's code for
> > > controlling the panel's backlight with
Hi,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> Hi,
>
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > Hi Hans.
> >
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Hi All,
> > >
> > > Here is v4 of my patch series converting the i915 driver's code for
>
Hi,
On 7/9/20 4:14 PM, Sam Ravnborg wrote:
Hi Hans.
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below
Hi Hans.
On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v4 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
Why is it that i
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to supp
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over drivers.
The current implementation looks at state of a device wrt vblanking. If
vblanking has been initial
Everyone:
This series contains various improvements (at least in my mind) and
fixes that I made to tc358767 while working with the code of the
driver. Hopefuly each patch is self explanatory.
Feedback is welcome!
Thanks,
Andrey Smirnov
Changes since [v3]:
- Collected Reviewed-bys from Andr
On Thu, Dec 14, 2017 at 07:01:57AM +, Priit Laes wrote:
> On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > Here is an attempt at supporting the LVDS output in our DRM driver. This
> > has been tested on the A83T (with DE2), but since everything is basically
> > in
On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote:
> Hi,
>
> Here is an attempt at supporting the LVDS output in our DRM driver. This
> has been tested on the A83T (with DE2), but since everything is basically
> in the TCON, it should also be usable on the older SoCs with minor
> modif
Hi,
Here is an attempt at supporting the LVDS output in our DRM driver. This
has been tested on the A83T (with DE2), but since everything is basically
in the TCON, it should also be usable on the older SoCs with minor
modifications.
This was the occasion to refactor a bunch of things. The most no
This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.
First 2 patches, comple
30 matches
Mail list logo
