https://bugs.freedesktop.org/show_bug.cgi?id=109138
Hai changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #79 from bmil...@gmail.com ---
any chance to backport the last version of the patch to 4.20?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Mon, Dec 24, 2018 at 6:52 PM Yongqiang Niu
wrote:
>
> This patch add ovl0/ovl0_2l usecase
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38
> ++---
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu
On Mon, Dec 24, 2018 at 6:53 PM Yongqiang Niu
wrote:
>
> This patch add function mtk_ddp_comp_get_type
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 10 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 11 insertions(+)
>
On Mon, Dec 24, 2018 at 6:53 PM Yongqiang Niu
wrote:
>
> This patch add gmc_bits for ovl private data
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 23 +--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm
On Mon, Dec 24, 2018 at 6:52 PM Yongqiang Niu
wrote:
>
> This patch redefine mtk_ddp_sout_sel
Can you describe a bit more why you are making this change?
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 32
> 1 file changed, 20 in
https://bugs.freedesktop.org/show_bug.cgi?id=109140
Bug ID: 109140
Summary: [KBL-G][GL] KHR-GL43.compute_shader.max test failed
Product: DRI
Version: XOrg git
Hardware: Other
OS: Linux (All)
Status: NEW
Se
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #37 from Shmerl ---
I wonder if it's some kind of distro specific race condition that happens
during boot. Happens to me in Debian testing (you can try reproducing it
there).
--
You are receiving this mail because:
You are the assi
https://bugs.freedesktop.org/show_bug.cgi?id=109135
toma678 changed:
What|Removed |Added
CC||gta...@gmail.com
--- Comment #3 from toma678
Having discussed with Matthew offlist, I think we've come to the
following conclusion - there's a number of drivers that buggily
ignore vm_pgoff.
So, what I proposed is:
static int __vm_insert_range(struct vm_struct *vma, struct page *pages,
size_t num, unsigned long
On Mon, Dec 24, 2018 at 03:52:55PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.12.2018 00.10, skrev Peter Wu:
> > On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 23.12.2018 01.55, skrev Peter Wu:
> > > > After drm_fb_helper_fbdev_setup calls drm_fb_helper_ini
Den 24.12.2018 00.10, skrev Peter Wu:
On Sun, Dec 23, 2018 at 02:55:52PM +0100, Noralf Trønnes wrote:
Den 23.12.2018 01.55, skrev Peter Wu:
After drm_fb_helper_fbdev_setup calls drm_fb_helper_init,
"dev->fb_helper" will be initialized (and thus drm_fb_helper_fini will
have some effect). Aft
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #75 from dwagner ---
Audio is unrelated to this bug. In my reproduction scripts, I do not output any
audio at all.
The video-at-3-fps replay that I use for reproduction seems to just trigger a
certain pattern of the memory- and sha
https://bugzilla.kernel.org/show_bug.cgi?id=202043
fin4...@hotmail.com changed:
What|Removed |Added
CC||fin4...@hotmail.com
--- Comment #2
On Mon, Dec 24, 2018 at 1:33 PM Liviu Dudau wrote:
>
> On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology
> China) wrote:
> > v2: Adjusted the position of KOMEDA by alphabetical order
> >
> > Signed-off-by: James (Qian) Wang
>
> Acked-by: Liviu Dudau
>
> Best regards,
> L
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #74 from fin4...@hotmail.com ---
The Firefox browser requires the pulseaudio driver. Use the Alsa audio and the
chrome/chromium browser. Disable hardware acceleration in browser settings.
--
You are receiving this mail because:
You
On Fri, Dec 21, 2018 at 10:00:49AM +, james qian wang (Arm Technology
China) wrote:
> v2: Some editing changes according to Randy Dunlap's comments
>
> Signed-off-by: James (Qian) Wang
Reviewed-by: Liviu Dudau
> ---
> Documentation/gpu/drivers.rst| 1 +
> Documentation/gpu/komeda-k
On Fri, Dec 21, 2018 at 10:01:06AM +, james qian wang (Arm Technology
China) wrote:
> v2: Adjusted the position of KOMEDA by alphabetical order
>
> Signed-off-by: James (Qian) Wang
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> MAINTAINERS | 9 +
> 1 file changed, 9 insertion
On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology
China) wrote:
> Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> CRTC: according to the komeda_pipeline
> PLANE: according to komeda_layer (layer input pipeline)
> PRIVATE_OBJS: komeda_pipeline/component all
The KMS mode_config elements are currently configured in vc4_kms_load,
that is called after all components are binded (component_bind_all).
However, the CRTC component (for the Pixel Valve) needs to access the
allow_fb_modifiers element at bind time, when initializing its planes
through drm_univers
On Fri, Dec 21, 2018 at 09:33:24AM -0500, Nicholas Kazlauskas wrote:
> The behavior of drm_atomic_helper_cleanup_planes differs depending on
> whether the commit was an asynchronous update or not.
>
> For a typical (non-async) atomic commit prepare_fb is called on the
> new_plane_state and cleanup
On Fri, Dec 21, 2018 at 10:00:17AM +, james qian wang (Arm Technology
China) wrote:
> komeda_framebuffer is for extending drm_framebuffer to add komeda own
> attributes and komeda specific fb handling.
>
> Changes in v3:
> - Fixed style problem found by checkpatch.pl --strict.
>
> Signed-off
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d9c54d61df327dc93374b718d7941a09e02e32e1
commit: 1d752442f3d6275b40bace55d022e792167f7fca [597/638] drm/amd/display: Use
100 Hz precision for pipe pixel clocks
config: i386-randconfig-n0-12220509 (attached as .confi
On Fri, Dec 21, 2018 at 10:00:01AM +, james qian wang (Arm Technology
China) wrote:
> komeda_format_caps is for describing ARM display specific features and
> limitations of a specific format, and format_caps will be linked into
> &komeda_framebuffer like a extension of &drm_format_info.
> And
On Fri, Dec 21, 2018 at 09:59:44AM +, james qian wang (Arm Technology
China) wrote:
> Parse DT and initialize corresponding dev/pipeline attributes.
>
> Changes in v3:
> - Fixed style problem found by checkpatch.pl --strict.
>
> Changes in v2:
> - Unified abbreviation of "pipeline" to "pipe"
On Fri, Dec 21, 2018 at 09:59:28AM +, james qian wang (Arm Technology
China) wrote:
> Implement a simple wrapper for platform module to build komeda to module,
> Also add a very simple D71 layer code to show how to discover a product.
> Komeda driver direct bind the product ENTRY function xxx_
On Fri, Dec 21, 2018 at 09:59:12AM +, james qian wang (Arm Technology
China) wrote:
> Add DT bindings documentation for the ARM display processor D71 and later
> IPs.
>
> Signed-off-by: James (Qian) Wang
>
> Changes in v3:
> - Deleted unnecessary property: interrupt-names.
> - Dropped 'port
On Fri, Dec 21, 2018 at 09:58:55AM +, james qian wang (Arm Technology
China) wrote:
> 1. Added a brief definition of komeda_dev/pipeline/component, this change
>didn't add the detailed component features and capabilities, which will
>be added in the following changes.
> 2. Correspondin
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #9 from Jan Ziak (http://atom-symbol.net)
(0xe2.0x9a.0...@gmail.com) ---
Linux 4.20 behaves the same as Linux 4.19.
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=201539
Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) changed:
What|Removed |Added
Summary|AMDGPU R9 390 automatic
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #27 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
d9c54d61df327dc93374b718d7941a09e02e32e1
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sat, Dec 22, 2018 at 01:00:46PM +, Colin King wrote:
> From: Colin Ian King
>
> In the case where state cannot be allocated, the current exit path via
> label 'out' will dereference the null state pointer when calling
> drm_atomic_state_put. Fix this by adding a new error exit label and
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
For GPU that does frame buffer compression, DMA writing out of bound
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Now, as Google's user guide, if userspace need clean ION buffer's
cache, they should call ioctl(fd, DMA_BUF_IOCTL_SYNC, sync). Then
we found that ion_dma_buf_begin_cpu_access/ion_dma_buf_end_cpu_access
will do ION buffer's map_kernel, it's not necessary. And if usersapce
only need clean cache, they
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
> > Userspace may request pitch alignment that is not supported by GPU.
> > Some requests 32, but GPU ignores it and uses default 64 when cpp is
> > 4. If GEM object is allocated based on the sm
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
which could not only corrupt memory but also reveal sensitive data.
This fix is not done in a common code pa
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi laura:
>-Original Message-
>From: Laura Abbott [mailto:labb...@redhat.com]
>Sent: Friday, December 21, 2018 4:50 AM
>To: Zengtao (B) ; sumit.sem...@linaro.org
>Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
>; Todd Kjos ; Martijn Coenen
>; Joel Fernandes ;
>de...@driverdev.osuosl.org; dri-deve
On Fri, Dec 21, 2018 at 8:56 PM Thomas Hellstrom wrote:
>
> Reviewed-by: Thomas Hellstrom
>
> Daniel, Dave, could you help try to get this patch in -next before the
> merge window. Otherwise people will start to experience random kernel
> crashes. I figure we don't want to wait until first -fixes
On Sun, Dec 23, 2018 at 09:16:13AM +, Simon Ser wrote:
> Hi all,
>
> Right now, the kernel parses EDIDs and exposes some of the data to
> userspace. For instance, drmModeConnector has mm{Width,Height} and
> subpixel.
>
> Generally, userspace also has another EDID parser. For instance,
> wlroo
On Fri, Nov 30, 2018 at 11:11:01AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
Sorry, fell through the cracks, applied for 4.22, thanks for your patch.
For next time around pls ping again after 1-2 weeks already, instead of
1-2 m
Hi all,
Lukas mentioned that there's a few patches in drm-misc-next that
should be in drm-misc-next-fixes. I found only the following two:
70bce993a7aa ("drm/bochs: add edid present check")
2312f9842854 ("drm/v3d: fix broken build")
Others look like fixes for issues in drm-misc-next itself. I gu
On Fri, Dec 21, 2018 at 8:42 PM Dhinakaran Pandiyan
wrote:
>
> On Thu, 2018-12-20 at 15:13 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-12-20 at 09:10 -0800, Rodrigo Vivi wrote:
> > > On Thu, Dec 20, 2018 at 02:21:20PM +0100, Hans de Goede wrote:
> > > > Call intel_psr_enable() and intel_edp
On Fri, Dec 21, 2018 at 8:53 PM Ross Zwisler wrote:
>
> On Fri, Dec 21, 2018 at 11:23:07AM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> > > The following commit:
> > >
> > > commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> > > ena
On Fri, Dec 21, 2018 at 9:24 PM Dan Carpenter wrote:
>
> I don't think anyone responded to this one?
Maybe time to move etnaviv into drm-misc so that there's a notch more
redundancy in maintainers? Lucas, Christian, others?
-Daniel
>
> regards,
> dan carpenter
>
> On Fri, Jul 13, 2018 at 06:00:1
On Sun, Dec 23, 2018 at 6:15 PM Lukas Wunner wrote:
>
> On Sun, Dec 23, 2018 at 02:00:15AM +0300, Sinan Kaya wrote:
> > On Sat, Dec 22, 2018 at 7:40 PM Lukas Wunner wrote:
> > > On Sat, Dec 22, 2018 at 09:07:12AM +, Sinan Kaya wrote:
> > > > This driver depends on the PCI infrastructure but t
Add two sysfs node: core_id, config_id, user can read them to fetch the
HW product information.
Signed-off-by: James (Qian) Wang
---
.../drm/arm/display/include/malidp_product.h | 12 +
.../gpu/drm/arm/display/komeda/komeda_dev.c | 48 +++
.../gpu/drm/arm/display/komeda/ko
CHIP set bus_width according to the HW configuration, and CORE will use
it as buffer alignment.
Signed-off-by: James (Qian) Wang
---
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 1 +
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(
Implement komeda_kms_check to add all affected_planes (even unchanged) to
drm_atomic_state. since komeda need to re-calculate the resources
assumption in every commit.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/komeda_kms.c | 30 ++-
1 file changed, 29
Pass enable/disable command to komeda and adjust komeda hardware for
enable/disable a display instance.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 102 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
.../drm/arm/display/komeda/k
Add a new komeda_dev_func->on_off_vblank to enable/disable HW vblank event
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 10 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 19 +++
.../gpu/drm/arm/display/komeda/komeda_dev.h |
Added functions:
- komeda_crtc_reset
- komeda_crtc_vblank_enable
- komeda_crtc_vblank_disable
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_c
A komeda flush is comprised two steps:
1. update pipeline/component state to HW.
2. call dev_func->flush to notify HW to kickoff the update.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 11 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 33
Komeda driver treats KMS-CRTC/PLANE as user which will acquire pipeline
resources, but we still need to release the unclaimed resources.
crtc_atomic_check is the final check stage, so beside build a display data
pipeline according the crtc_state, but still needs to release/disable the
unclaimed pip
These two function will be used by komeda_crtc_enable/disable to do some
prepartion works when enable/disable a crtc. like enable a crtc:
1. Adjust display operation mode.
2. Enable/prepare needed clk.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 32 +
komeda_crtc_mode_valid compares the input mode->clk with main engine clk
and AXI clk, and reject the mode if the required pixel clk can not be
satisfied by main engine clk and AXI-clk.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 52 +++
1
This function builds a display output pipeline according to crtc_state.
And this change only added single pipeline support, the dual pipeline with
slave enabled data flow support will be added in the following change.
Signed-off-by: James (Qian) Wang
---
.../drm/arm/display/komeda/komeda_pipelin
This is the 4th patchset for komeda-driver, with this patchset the driver
can bring up and enable the D71 support with basic features.
This patchset implemented komeda_crtc/crtc_helper functions for
DRM-crtc.
James (Qian) Wang (11):
drm/komeda: Add komeda_build_display_data_flow
drm/komeda: A
Per komeda design KMS-plane maps to komeda layer input pipeline.
komeda_plane_atomic_check is for building a komeda layer input pipeline.
And KMS-plane is only a user of komeda resources. so there is no real HW
update for plane, but all HW update will be handled in crtc->flush.
Signed-off-by: Jam
get_state_and_set_user packed get_state and set_user into one function,
which get pipeline/component state for a specific pipeline/component, if
success set the user to it.
Signed-off-by: James (Qian) Wang
---
drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
.../drm/arm/display/komeda/kome
build_layer_data_flow builds a input pipeline according to plane_state.
and in this initial stage only added this simplest pipeline usage:
Layer -> compiz
The scaler and layer_split will be added in the future.
Signed-off-by: James (Qian) Wang
---
.../drm/arm/display/komeda/komeda_pipeline.h
Initialize koemda_layer, komeda_compiz, komeda_improc and
komeda_timing_ctrlr as drm private object, then track komeda private
component state by drm_atomic_state.
Signed-off-by: James (Qian) Wang
---
.../arm/display/komeda/komeda_private_obj.c | 200 +-
1 file changed, 198 ins
This pair of functions return the old/new private object state for the
given private_obj, or NULL if the private_obj is not part of the global
atomic state.
Reviewed-by: Alexandru Gheorghe
Signed-off-by: James (Qian) Wang
---
drivers/gpu/drm/drm_atomic.c | 45 +++
This is the 3rd patchset for the komeda driver.
This patchset implemented plane/plane_helper functions for DRM-Plane.
per the komeda driver design, A DRM-plane maps to komeda layer input
pipeline, so the plane->atomic_check will build a layer input pipeline
according to the plane_state. and with t
Add a debugfs node "register" and entry function dump_register to
dev/pipeline/component to register dump, then user can read
"/sys/kernel/debug/komeda/register" to get the register values via these
chip function.
Signed-off-by: James (Qian) Wang
---
.../arm/display/komeda/d71/d71_component.c
1. Added irq_handler/irq_enable/irq_disable to komeda_dev_func, then the
Komeda-CORE can control the HW irq via these chip function.
2. Install irq and register irq_handler to system by DRM, so once the IRQ
coming, the handling sequence is:
komeda_kms_irq_handler(int irq, void *data)
komeda_accemble_pipelines is for:
1. Verifing the component->supported_inputs according to the
pipeline->avail_components.
2. Generating component->supported_outputs.
Signed-off-by: James (Qian) Wang
---
.../gpu/drm/arm/display/komeda/komeda_dev.c | 6 ++
.../drm/arm/display/komeda/komeda
Add and initialize improc and timing_ctrlr according to D71 capablitites
Signed-off-by: James (Qian) Wang
---
.../arm/display/komeda/d71/d71_component.c| 108 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 +
.../drm/arm/display/komeda/komeda_pipeline.h | 7 ++
3 f
Implement d71_compiz_init and add compiz component to komeda-CORE
Signed-off-by: James (Qian) Wang
---
.../arm/display/komeda/d71/d71_component.c| 95 ++-
.../drm/arm/display/komeda/komeda_pipeline.h | 26 +++--
2 files changed, 113 insertions(+), 8 deletions(-)
diff --git
D71 consists of a number of Register Blocks, every Block controls a
specific HW function, every block has a common block_header to represent
its type and pipeline information.
GCU (Global Control Unit) is the first Block which describe the global
information of D71 HW, Like number of block contain
1. Add detailed layer/layer_state definitions
2. Add d71_layer_init to report layer features and capabilities according
to D71 layer block.
3. Add d71_layer_updat/disable
Signed-off-by: James (Qian) Wang
---
.../drm/arm/display/include/malidp_utils.h| 17 ++
.../arm/display/komeda/d71/d7
This is the 2nd patchset for komeda-driver.
These patches focus on CHIP(D71) Layer for pipeline/component descovery and
initialization. All basic and essential display component: layer, compiz,
improc, timing-ctrlr and irq handling have been added, other component
support: scaler, wb_layer, merger
90 matches
Mail list logo
