Page fault handler inside vgem driver now preallocates pages in advance
when fault occurs for the first time. Pages can be allocated in
direction of increasing/decreasing addresses, depending on memory access
profile. In case of random access no preallocation occurs.
Synthetic benchmark showed ove
On Mon, Aug 19, 2019 at 01:08:18PM -0500, Wenwen Wang wrote:
> In qxl_bo_create(), the temporary 'bo' is allocated through kzalloc().
> However, it is not deallocated in the following execution if ttm_bo_init()
> fails, leading to a memory leak bug. To fix this issue, free 'bo' before
> returning t
On Tue, Aug 20, 2019 at 12:13:59PM +0900, Sergey Senozhatsky wrote:
> Always put_filesystem() in i915_gemfs_init().
>
> Signed-off-by: Sergey Senozhatsky
> ---
> - v2: rebased (i915 does not remount gemfs anymore)
Which means it real doesn't need its mount anyore, and thus can use
plain old shm
On 8/16/19 11:31 AM, Steven Price wrote:
The hardware has a set of '_NEXT' registers that can hold a second job
while the first is executing. Make use of these registers to enqueue a
second job per slot.
I like this in principle, but upon some quick testing I found that Mesa
is around 10% slow
https://bugs.freedesktop.org/show_bug.cgi?id=111434
Bug ID: 111434
Summary: MesaTest1
Product: Mesa
Version: 5.1
Hardware: ARM
OS: All
Status: NEW
Severity: major
Priority: medium
Compon
https://bugs.freedesktop.org/show_bug.cgi?id=109380
Arek Hiler changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111414
--- Comment #3 from Dieter Nützel ---
(In reply to Marek Olšák from comment #1)
> Created attachment 145103 [details] [review]
> possible fix
>
> Does the attached patch fix it?
Yes, it fixed vdpau with Mplayer for me.
mplayer -vo vdpau /data
https://bugs.freedesktop.org/show_bug.cgi?id=111433
Ruchira changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Ruchira ---
Thi
https://bugs.freedesktop.org/show_bug.cgi?id=111433
Bug ID: 111433
Summary: Bug1 for DRI
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #25 from Marek Olšák ---
This might help:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1714/diffs?commit_id=b991b7dd54a899d0df89c809c936401baa341d9d
--
You are receiving this mail because:
You are the assignee for the bu
Modules, e.g. i915, can use exported get_fs_type(), but are
unable to put_filesystem(). Export it and let modules to
decrement file systems' reference counters.
Signed-off-by: Sergey Senozhatsky
---
fs/filesystems.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/filesystems.c b/fs/filesy
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
between commit:
70d6894d1456 ("drm/i915: Serialize against vma moves")
from the drm-intel tree and commit:
52791eeec1d9 ("dma-buf: rename reservation_object to dma_res
Hi all,
On Mon, 19 Aug 2019 18:34:41 -0700 Randy Dunlap wrote:
>
> On 8/19/19 2:18 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190816:
> >
>
> on x86_64:
>
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function ‘amdgpu_exit’:
> ../drivers/gpu/drm/amd/amdgpu/amdgpu_drv
Hi Dave, Daniel:
This include PRIME buffer and of_node fixes.
Regards,
CK
The following changes since commit
5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://github.com/ckhu-mediatek/linux.git-tags
tags/med
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
3 files change
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 6
drivers/gpu/drm/omapdrm/omap_encoder.c | 44
The drmP.h header is deprecated, replace it with the headers
specifically needed by the tfp410 driver. While at it, replace the DRM
print macros with dev_info() and dev_err() instead of including
drm_print.h
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 6 --
1 fil
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
drivers/gpu/drm/omapdrm/omap_encoder.c | 26 --
2 files changed, 29 del
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 11aa2f712ff4..
In order to support drm_bridge-based pipeline, the internal HDMI
encoders will need to expose the EDID read operation through the
drm_bridge API, and thus to expose a drm_bridge instance corresponding
to the encoder. The HDMI encoders are however handled as omap_dss_device
instances, which conflict
Now that the omap_connector is used for DSI only we can simplify its
implementation.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Remove export of omapdss_device_connector_type()
---
drivers/gpu/drm/omapdrm/dss/base.c | 1 -
drivers/gpu/drm/omapdrm/omap_connector.c | 31 ++
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 +++
driver
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Si
Due to the removal of several omapdrm display drivers, the omapdss HPD,
detected and EDID operations are not used anymore. Remove them and all
related code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 61
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 46
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 2d0eb5fcbb5
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix this, implement a bridge driver for display conne
Now that the VENC output is driven fully through the drm_bridge API its
omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 45 --
1 file changed, 45 deletions(-)
diff --git a/drivers/
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
drivers/gpu/drm/omapdrm/omap_drv.c| 7 ---
3 files changed, 4 insertions(+), 13
The TPD12S015, OPA362 and analog and HDMI connectors are now supported
by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
handled through the drm_bridge API. Switch the outputs to drm_bridge by
making the next bridge mandatory and removing the related
omapdrm-specific display drive
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can
be accessed directly from the connector's display info.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_connector.c | 11 ---
drivers/gpu/drm/omapdrm/omap_connector.h |
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Remove empty .hpd_enable() and .hpd_disable() operations
---
drivers/gpu/drm/bridge/Kconfig| 8 ++
driv
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations to the next bridge. This
brings us one step cl
Group functions based on their purpose and split them in sections to
make the source code easier to navigate.
No functional change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 146 --
1 file changed, 79 insertions(+), 67 deleti
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 89 ++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 48 +++--
drivers/gpu/d
Implement the newly added bridge connector operations, allowing the
usage of drm_bridge_panel with drm_bridge_connector.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/panel.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridg
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/dr
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
DACs that don't require configuration. Other non-VGA bridges fall in a
similar category, and would benefit from a common driver. Prepare for
this by renaming the internal symbols from dumb-vga-dac to
simple-bridge.
Signed-off-by:
The DSS core looks up the next device connected to an output by
traversing the OF graph. It currently hardcodes the local port number to
0, which breaks any output with a different port number (SDI on OMAP3
and any DPI output but the first one). Fix this by repurposing the
currently unused of_ports
In order to integrate with a chain of drm_bridge, the internal HDMI5
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on omap_
In order to integrate with a chain of drm_bridge, the internal HDMI4
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on omap_
Now that the HDMI outputs are driven fully through the drm_bridge API
their omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 18 --
drivers/gpu/drm/o
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 86 -
1 file changed, 35 insertions(+), 51 deleti
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 32 ---
1 file
As part of the move to drm_bridge ops, the dssdev ops will become empty
for some of the internal encoders. Make them optional in the driver to
allow them to be removed completely, easing the transition.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/d
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 96 -
1 file changed, 40 insertions(+), 56 deleti
The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
---
Changes since v1:
- Removed documentation of the return value
Cc: Bartlomiej Zolnierkiewicz
---
drivers/gpu/drm/drm_edid.c | 5 +
To support implementation of DRM connectors on top of DRM bridges
instead of by bridges, the drm_bridge needs to expose new operations and
data:
- Output detection, hot-plug notification, mode retrieval and EDID
retrieval operations
- Bitmask of supported operations
- Bridge output type
- I2C ad
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/dr
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 94 +++-
drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 59 +++
drivers/gpu
The dumb-vga-dac driver can support simple DRM bridges without being
limited to VGA DACs. Rename it to simple-bridge.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
---
arch/arm/configs/davinci_all_defconfig | 2 +-
arch/arm/configs/integrator_defconfig| 2 +-
The tfp410 driver can operate as part of a pipeline where the
drm_connector is created by the display controller. Enable this mode of
operation by skipping creation of a drm_connector internally.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
1 file changed, 1 ins
Hello,
This patch series (nearly, see [1]) completes the rework of the omapdrm
driver to move to drm_bridge and drm_panel.
Let's start with some context (copied from v1) to understand the
problem. omapdrm contains custom drivers for external encoders, panels
and connectors (collectively referred
The drm_display_info structure contains many fields related to HDMI
sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
populate it according to section 8.3.3 ("DVI/HDMI Device
Discrimination") of the HDMI v1.3
If an enable GPIO is declared in the firmware, assert it when enabling
the bridge and deassert it when disabling it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/bridge/simple-bridge.c | 22 ++
1 file changed, 18 i
In order to integrate with a chain of drm_bridge, the internal VENC
encoder has to expose the mode valid, fixup and set, the enable and
disable and the get modes operations through the drm_bridge API.
Register a bridge at initialisation time to do so.
Most of those operations are removed from the
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
- Keep MAX_EDID macro
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 36
Create a new simple_bridge_info structure that stores information about
the bridge model, and store the bridge timings in there, along with the
connector type. Use that new structure for of_device_id data. This
enables support for non-VGA bridges.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andr
The TI OP362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bri
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
-
drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
to name strings, but doesn't expose it. This leads to drivers having to
store a similar map.
Add a new drm_get_connector_type_name() helper function that return a
name string for a connector type.
Signed-off-by: Laurent Pinc
Peter sent a patchset out back in April to enable Lima support
on HiKey, but there's not been much action on it since since.
I've been carrying the patchset in my tree, and figured I'd send
out just these three dt-bindings changes just so hopefully they
can go in and the dependent driver changes c
From: Peter Griffin
The reset driver now supports the ao reset controller, so update the
documentation to match.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Mark Rutland
Cc: Philipp Zabel
Cc: dri-devel@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
From: Peter Griffin
This is required to bring Mali450 gpu out of reset.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Mark Rutland
Cc: Philipp Zabel
Cc: dri-devel@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Signed-off-by: Peter Griffin
Signed-off
From: Peter Griffin
The Hisilicon hi6220 uses a Mali-450MP4 with 4 PPs, so add
a compatible for it.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Mark Rutland
Cc: Philipp Zabel
Cc: dri-devel@lists.freedesktop.org
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Signed-off-b
Hi Artur and Leonard,
On 19. 8. 9. 오전 12:00, Leonard Crestez wrote:
> On 29.07.2019 04:49, Chanwoo Choi wrote:
>> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The devfreq target() callback provided by exynos
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #22 from Marek Olšák ---
How do I reproduce the Xfce hang and corruption? It's not reproducible with
Ubuntu 16.04.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Sun, Aug 18, 2019 at 9:40 PM Sam Ravnborg wrote:
> > > As Maintainers can we please get some feedback from one of you.
> > > Just an "OK to commit" would do it.
> > > But preferably an ack or a review on the individual patches.
> >
> > As I have done a pre-review and talked with the author bef
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #24 from Timothy Arceri ---
(In reply to Marek Olšák from comment #23)
> Connor, there is indeed an issue with how we set SPI_TMPRING_SIZE and same
> for compute.
I wonder if this is the issue reported in bug #108194
--
You are re
The workqueue used to reset the display when we hit an LDI
underflow error is ADE specific, so since this patch series
works to make the kirin_crtc structure more generic, move the
workqueue to the ade_hw_ctx structure instead.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vette
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the channel
format arrays into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongrong Zou
Cc:
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the number of
planes and the primary plane value to the kirin_drm_data
structure
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
C
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the drm_driver
structure to be under device specific driver data.
This will allow us to more easily add support for kirin960
hardware with later patches.
Cc: Rongrong Zou
Cc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the max_width
and max_height values used in kirin_drm_mode_config_inita to
hardware specific driver data.
This will make it easier to add support for new devices
via a new kir
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the driver_data
value to not be a global variable. Instead the driver_data value
is accessed via the of_device_get_match_data() when needed.
Cc: Rongrong Zou
Cc: Xinliang L
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch adds a flag to the
device specific driver data so that we can conditionally
register the connectors at init.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames
ade_crtc/plane_init kirin_plane/crtc_init, as they will later be
moved to kirin drm drv and shared with the kirin960 hardware
support.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the mode config
initialization values into the kirin_drm_data structure.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongr
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
alloc/clean_hw_ctx functions to be called via driver_data
specific funciton pointers.
This will allow the ade_drm_init to later be made generic and
moved to kirin_drm_dr
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the code
via a passed in driver_data pointer, rather than hardcoding
them via ade_driver_data variable.
This will allow those funcitons to be later moved to the
generic kiri
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch changes the
dev->driver_data to point to a drm_device, not ade_data.
Thus we set the driver data to drm device after alloc.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames ade_data to
kirin_drm_private, and moves crtc_init and plane_init to
kirin drm drv too. Now that they are generic the functions
can be shared between the kirin620 and (to be
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization routines so the devm_request_irq() function
is called as part of the allocation function.
This will be needed in the future when we will have different
a
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch modifies the
initialization function to dynamically allocate the ade_hw_ctx
structure previously kept as part of struct ade_data.
This is done so that later we can have the hw_ctx p
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct kirin_dc_ops to struct kirin_drm_data and cleans
up the related variable names.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-d
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves some shared
structures and helpers to the common kirin_drm_drv.h
These structures will later used by both kirin620 and
future kirin960 driver
Cc: Rongrong Zou
Cc: Xinliang L
The 'return 0' in kirin_drm_platform_probe() is unreachable
code, so remove it.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Acked-by: Xinliang Liu
Reviewed-by: Sam Ravnborg
Suggested by: Xu YiPing
Signed-off-by: John Stultz
---
dri
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch moves the crtc
and plane funcs/helper_funcs to the struct kirin_drm_data.
This will make it easier to add support for new devices
via a new kirin_drm_data structure.
Cc: Rongrong Z
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_crtc to kirin_crtc.
The struct kirin_crtc will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a futu
The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin
driver, so cut out the middleman and condense the config
logic down.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
Cc: Sam Ravnborg
Acked-by: Xinliang Liu
Reviewed-by: Sam Ravnborg
Signed-off-by:
From: Da Lv
The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).
After lots of analysis by HiSi de
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch removes the out_format
field in the struct ade_crtc, which was only ever set to
LDI_OUT_RGB_888.
Thus this patch removes the field and instead directly uses
LDI_OUT_RGB_888.
Cc: Ro
Sending this out again, to get it based on drm-misc-next.
This patchset contains one fix (in the front, so its easier to
eventually backport), and a series of changes from YiPing to
refactor the kirin drm driver so that it can be used on both
kirin620 based devices (like the original HiKey board)
From: Xu YiPing
In a few functions, we pass in a struct ade_crtc, which we only
use to get to the underlying struct ade_hw_ctx.
Thus this patch refactors the functions to just take the
struct ade_hw_ctx directly.
Cc: Rongrong Zou
Cc: Xinliang Liu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-d
From: Xu YiPing
As part of refactoring the kirin driver to better support
different hardware revisions, this patch renames the
struct ade_plane to kirin_plane.
The struct kirin_plane will later used by both kirin620 and
future kirin960 driver, and will be moved to a common
kirin_drm_drv.h in a f
Hi Andrzej,
On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
> On 14.08.2019 14:40, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
> >> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> >>> On 11.08.2019 00:43, Laurent Pincha
1 - 100 of 244 matches
Mail list logo
