This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.
Changes in v2:
- Split out the binding into a new patch (Rob)
- display-timings is a new section (Rob)
- Use the full display-timings subnode instead of picking the
This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:
-
Hello!
Here's v3 of the set. I've reintroduced the single display timing node
in the dt binding from v1, and left the improved docs and patch split
from v2. I've also added a patch to clarify that a single display timing
node should always be named panel-timing, which was feedback from v1.
Cover
Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the
Add a note in the documentation explaining when it's appropriate to use
the display-timings subnode on its own, as well as the preferred name to
use (panel-timing).
Changes in v3:
- Added
Cc: Doug Anderson
Cc: Eric Anholt
Cc: Heiko Stuebner
This patch adds an override mode for kevin devices. The mode increases
both back porches to allow a pixel clock of 2kHz as opposed to the
'typical' value of 252750kHz. This is needed to avoid interference with
the touch digitizer on these laptops.
Changes in v2:
- Wrap the timing in
In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.
Changes in v2:
- Added
Changes in v3:
- None
Cc: Doug Anderson
Cc: Eric Anholt
Cc: Heiko Stuebner
Cc:
From: Markus Elfring
Date: Thu, 8 Feb 2018 19:30:06 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul wrote:
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
>
> Changes in v2:
> - Split out the binding into a new patch (Rob)
> - display-timings
+Thierry and Archit for the drm_panel/panel_bridge bits.
Hi all,
I'm resurrecting this thread because Eric asked me to find a solution
to this problem :-).
On Mon, 20 Nov 2017 08:53:05 +0100
Andrzej Hajda wrote:
> On 18.11.2017 02:16, Eric Anholt wrote:
> > Andrzej Hajda
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 5
From: Markus Elfring
Date: Thu, 8 Feb 2018 18:42:51 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
[v2 - Update the API to be cleaner for the caller suggested by
Chris Wilson]
On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul wrote:
> In preparation for a new subnode section in a follow-on patch, add
> explicit headings to the existings sections for simple-panel.
>
> Changes in v2:
> - Added
> Changes in v3:
> - None
>
> Cc: Doug Anderson
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture.
Add the infrastructure to capture the state current state of the
GPU and store it in memory. This is useful for storing the state
of a hung GPU so it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 29
Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 54 +
This is revision 3 of my stack implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/).
The goal is to store and provide enough information to debug software
and hardware issues on the Adreno hardware in a semi human-readable
format that can also be parsed by
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping
Quoting Jordan Crouse (2018-02-08 17:31:50)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
>
> [v2 - Update the API to be
The Parfait (version 2.1.0) static code analysis tool found multiple NULL
pointer derefernce problems.
- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to
El Thu, Feb 08, 2018 at 09:33:53AM -0500 Harry Wentland ha dit:
> On 2018-02-07 08:51 PM, Matthias Kaehlcke wrote:
> > Use subdir-ccflags instead of specifying the same flags for every source
> > file.
> >
> > Signed-off-by: Matthias Kaehlcke
> > Reviewed-by: Guenter Roeck
On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul wrote:
> Add a note in the documentation explaining when it's appropriate to use
> the display-timings subnode on its own, as well as the preferred name to
> use (panel-timing).
>
> Changes in v3:
> - Added
>
> Cc: Doug Anderson
On Thu, Feb 8, 2018 at 12:31 PM, Jordan Crouse wrote:
> Convert the existing GPU show function to use the GPU state to
> dump the information rather than reading it directly from the hardware.
> This will require an additional step to capture the state before
> dumping it
From: Markus Elfring
Date: Thu, 8 Feb 2018 20:32:39 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
Hi Kieran,
On Thursday, 8 February 2018 01:30:43 EET Kieran Bingham wrote:
> On 07/02/18 21:59, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> >> On 29/01/18 10:26, Laurent Pinchart wrote:
> >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham
https://bugzilla.kernel.org/show_bug.cgi?id=197327
Eugene (ken20...@ukr.net) changed:
What|Removed |Added
CC||ken20...@ukr.net
--- Comment
From: Markus Elfring
Date: Thu, 8 Feb 2018 21:01:24 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: Comparisons should place the constant on the right side
of the test
WARNING: else is not generally useful after a break or
calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and
DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.
Probe for both compiler options and use
Use a variable for common CFLAGS instead of specifying the same flags
for every source file.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- Use variable for compiler options instead of subdir-ccflags-y
drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +
Use a variable for common CFLAGS instead of specifying the same flags
for every source file.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- patch added
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff
The following patch(s) are bugs found by the static compiler
'Parfait'. Care was taken to make sure false positive results
were removed from this patchset.
Parfait Overview
https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13
Joe Moriarty (1):
drm: Multiple
On Thu, Feb 08, 2018 at 10:27:54AM +0100, Andrzej Hajda wrote:
> On 07.02.2018 22:43, Rob Herring wrote:
> > On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> >> On 05.02.2018 07:08, Rob Herring wrote:
> >>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These
On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:
> Hi,
>
> Il 07/02/2018 11:39, Maxime Ripard ha scritto:
> > On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> > Also, how was it tested? This seems quite weird that we haven't caught
> > that one sooner, and
On 2018-02-08 04:03 PM, Harry Wentland wrote:
> On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
>> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
>> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
>> instead, which expects as parameter the
https://bugs.freedesktop.org/show_bug.cgi?id=104919
Andy Furniss changed:
What|Removed |Added
Resolution|--- |FIXED
From: Markus Elfring
Date: Thu, 8 Feb 2018 21:37:42 +0100
Three update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
Delete an error message for a failed memory allocation in three functions
Adjust layout for source
https://bugzilla.kernel.org/show_bug.cgi?id=197327
--- Comment #5 from Eugene (ken20...@ukr.net) ---
Created attachment 274071
--> https://bugzilla.kernel.org/attachment.cgi?id=274071=edit
dmesg_GA-MA790FX-DQ6
--
You are receiving this mail because:
You are watching the assignee of the bug.
From: Markus Elfring
Date: Thu, 8 Feb 2018 21:10:58 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement in the affected functions.
From: Markus Elfring
Date: Thu, 8 Feb 2018 22:23:57 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> instead, which expects as parameter the alignment in bytes, and not a
> power of two like
Which is used in wraps.
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 1342a5b3..4aaeb7e1 100644
--- a/meson.build
+++ b/meson.build
@@ -294,7 +294,7 @@ libdrm = shared_library(
ext_libdrm = declare_dependency(
link_with :
El Thu, Feb 08, 2018 at 04:44:21PM -0500 Harry Wentland ha dit:
> On 2018-02-08 04:03 PM, Harry Wentland wrote:
> > On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> >> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> >> a stack alignment of 16 bytes. Clang uses the
Am 08.02.2018 um 09:32 schrieb Chunming Zhou:
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
Reviewed-by: Christian König
On Wed, Feb 07, 2018 at 10:17:03PM +0100, Jernej Skrabec wrote:
> When parent rate is 24MHz and multiplier N >= 180, intermediate clock
> rate doesn't fit in 32 bit variable anymore.
>
> Because of that, introduce function for calculating clock rate which
> uses 64 bit variable for intermediate
Many thanks
Philippe :-)
On 02/08/2018 08:39 AM, Andrzej Hajda wrote:
> On 06.02.2018 09:42, Philippe Cornu wrote:
>> Add support for the Synopsys DesignWare MIPI DSI version 1.31
>> Two registers need to be updated/added for supporting 1.31:
>> * PHY_TMR_CFG 0x9c (updated)
>>1.30 [31:24]
Many thanks
Philippe :-)
On 02/08/2018 08:39 AM, Andrzej Hajda wrote:
> On 04.02.2018 22:31, Philippe Cornu wrote:
>> This patch adds the DCS/GENERIC DSI read feature.
>>
>> Signed-off-by: Philippe Cornu
>> ---
> Queued to drm-misc-next.
> --
> Regards
> Andrzej
>
Am 08.02.2018 um 07:00 schrieb Chunming Zhou:
get the max io mapping address of system memory to see if it is over
our card accessing range.
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1
swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later
Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
---
get the max io mapping address of system memory to see if it is over
our card accessing range.
v2: move checking later
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
---
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
---
include/drm/drm_cache.h | 13 +
1 file changed, 13 insertions(+)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=105018
ragnaros39...@yandex.com changed:
What|Removed |Added
Keywords||regression
Hi Daniel,
On Tue, 2018-01-30 at 02:27:07 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific
https://bugs.freedesktop.org/show_bug.cgi?id=92827
--- Comment #10 from Michael Zapf ---
I now believe there is a general problem with amdgpu's new DC.
On another system, without an AV receiver in the chain, my display resolution
is reset to 1368x768 when I turn off the
https://bugs.freedesktop.org/show_bug.cgi?id=105018
Bug ID: 105018
Summary: Kernel panic when waking up after screen goes blank.
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status:
"Pandiyan, Dhinakaran" writes:
> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>>
>> thanks for getting involved with PSR and sorry for not replying sooner.
>>
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really
> On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran
> wrote:
>
>
>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>>
>> thanks for getting involved with PSR and sorry for not replying sooner.
>>
>> I first saw this patch on that bugzilla
it will be used to check if the driver needs swiotlb
v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer
)
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
Hi Andy,
thanks for getting involved with PSR and sorry for not replying sooner.
I first saw this patch on that bugzilla entry but only now I stop to
really think why I have written the code that way.
So some clarity below.
On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>
On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> Hi Andy,
>
> thanks for getting involved with PSR and sorry for not replying sooner.
>
> I first saw this patch on that bugzilla entry but only now I stop to
> really think why I have written the code that way.
>
> So some clarity below.
https://bugs.freedesktop.org/show_bug.cgi?id=104142
--- Comment #5 from JohnDoe ---
I ran into this bug when upgrading to 4.15.1. Anything I can do to help?
--
You are receiving this mail because:
You are the assignee for the
This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.
Feedback or comments would be greatly appreciated!
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
On Thu, 2018-02-08 at 17:01 -0800, Andy Lutomirski wrote:
>
>
> > On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran
> > wrote:
> >
> >
> >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> >> Hi Andy,
> >>
> >> thanks for getting involved with PSR
get the max io mapping address of system memory to see if it is over
our card accessing range.
v2: move checking later
Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
Reviewed-by: Christian König
swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later
Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
Hi Daniel,
On Tue, 2018-01-30 at 02:22:40 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific
On Mon, Feb 05, 2018 at 10:45:31AM +0100, Philippe Cornu wrote:
> Some boards use a dedicated voltage regulator for this panel.
> Add & document this related optional power-supply property.
>
> Signed-off-by: Philippe Cornu
> ---
>
On Mon, Feb 05, 2018 at 03:34:27PM +0100, Heiko Stuebner wrote:
> From: Zheng Yang
>
> The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
>
> Signed-off-by: Zheng Yang
> Signed-off-by: Heiko Stuebner
>
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #16 from Matthew Scheirer ---
I get this as well with a 290 on 4.15 ONLY when DC is enabled. Its a dirty
enough taint to leave btrfs volumes in inconsistent states so its straight
crashing the kernel.
Feb
On 07/02/18 16:11, Jyri Sarha wrote:
> The new omapdss API is HW independent and cleans up some of the DSS5
> specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
> register bits and replace them with HW independent generic u64 based
> macros. The new macros make it more straight
On 07.02.2018 22:43, Rob Herring wrote:
> On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
>> On 05.02.2018 07:08, Rob Herring wrote:
>>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
These bindings allow to describe most known standard USB connectors
and
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #25 from Michel Dänzer ---
(In reply to Bong Cosca from comment #24)
> My screen width is 1280px. Is there a reason why the amdgpu driver says the
> GPU has a front buffer pitch of 6144 bytes in non-accelerated
2018-02-06 10:13 GMT+01:00 Yannick FERTRE :
> Reviewed-by: Yannick Fertré
>
>
> On 02/01/2018 11:42 AM, Philippe Cornu wrote:
>> Hw older versions support non-alpha color formats derived
>> from native alpha color formats only on the primary layer.
>>
2018-02-06 10:12 GMT+01:00 Yannick FERTRE :
> Reviewed-by: Yannick Fertré
>
>
> On 02/01/2018 11:42 AM, Philippe Cornu wrote:
>> ltdc supports natively some color formats with alpha (like
>> ARGB, ARGB1555, ARGB...). Related non-alpha formats
Call to omap_drm_irq_install() may fail with an error code. In such a
case the driver probe should fail.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
The purpose of these patches is to make easier to add support for
future DSS version.
Since v3:
- "drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops"
- Make ovl_names array static const char * const
- Add:
- "drm/omap: move common stuff from dss.h to omapdss.h"
- "drm/omap: dss:
Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
adhoc names here and there in the omapdrm code. This moves the names
of hardware entities to omapdss side where they have to be when new
omapdss backend drivers are introduced.
Signed-off-by: Jyri Sarha
---
The new omapdss API is HW independent and cleans up some of the DSS5
specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
register bits and replace them with HW independent generic u64 based
macros. The new macros make it more straight forward to implement the
IRQ code for the future
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/core.c | 66
On 2018年02月08日 17:09, Michel Dänzer wrote:
On 2018-02-08 09:32 AM, Chunming Zhou wrote:
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
---
https://bugs.freedesktop.org/show_bug.cgi?id=105005
Michel Dänzer changed:
What|Removed |Added
Attachment #137223|text/x-log |text/plain
https://bugs.freedesktop.org/show_bug.cgi?id=105005
--- Comment #6 from Michel Dänzer ---
Did you capture the Xorg log and dmesg before or after the problem occurred? If
before, can you grab them again after?
What was the last kernel version where this didn't happen?
--
Hi, Maarten!
On 02/06/2018 05:37 PM, Maarten Lankhorst wrote:
Op 06-02-18 om 15:43 schreef Oleksandr Andrushchenko:
Hello, Maarten!
On 02/01/2018 12:13 PM, Oleksandr Andrushchenko wrote:
On 02/01/2018 12:04 PM, Maarten Lankhorst wrote:
Op 01-02-18 om 08:08 schreef Oleksandr Andrushchenko:
These clocks are in kHz not in Hz, oops. Fix it so my
new bandwidth calculations patch starts working with these
panels.
Cc: Eric Anholt
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-arm-versatile.c | 8
1 file changed, 4
Hello, Ville!
On 02/06/2018 06:04 PM, Ville Syrjälä wrote:
On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:
Hello, Ville!
Thank you very much for such a comprehensive answer.
Please see inline
On 02/05/2018 06:47 PM, Ville Syrjälä wrote:
On Mon, Feb 05, 2018 at
sync_dump() is an unused, unexported, function that adds 64k to the
kernel image and doesn't even provide locking around the global array it
uses.
add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
Function old new delta
sync_dump
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #24 from Bong Cosca ---
My screen width is 1280px. Is there a reason why the amdgpu driver says the GPU
has a front buffer pitch of 6144 bytes in non-accelerated mode while the pitch
in accelerated mode is 5120?
On 07/02/18 16:11, Jyri Sarha wrote:
> Since v2:
> - Simplify dispc_mgr_has_framedone()
> - dispc_hw_to_api_irq() and dispc_api_to_hw_irq() use new dispc_irq_bits[]
> - rename dispc_ops read_irqstatus() to read_and_clear_irqstatus() and remove
> clearmask
> - precalculate priv->irq_uf_mask in
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Kconfig | 9 ++
The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").
---
Changes in v2:
Remove the AVR32 reference from the help text too.
drivers/spi/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/Kconfig
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi, hdmi phy and hdmi pinctrl entries.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +-
1 file changed, 118 insertions(+), 1
dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.
Idea was taken from the following commit:
Hi,
Il 07/02/2018 11:39, Maxime Ripard ha scritto:
> On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> Also, how was it tested? This seems quite weird that we haven't caught
> that one sooner, and I'm a bit worried about the possible regressions
> here.
It
On 2018-02-08 09:32 AM, Chunming Zhou wrote:
> it will be used to check if the driver needs swiotlb
>
> Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
> Signed-off-by: Chunming Zhou
> Reviewed-by: Monk Liu
> ---
> include/drm/drm_cache.h | 13
Am 08.02.2018 um 10:09 schrieb Michel Dänzer:
On 2018-02-08 09:32 AM, Chunming Zhou wrote:
it will be used to check if the driver needs swiotlb
Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou
Reviewed-by: Monk Liu
---
On 2018-02-08 10:15 AM, Chunming Zhou wrote:
> On 2018年02月08日 17:09, Michel Dänzer wrote:
>> On 2018-02-08 09:32 AM, Chunming Zhou wrote:
>>> it will be used to check if the driver needs swiotlb
>>>
>>> Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
>>> Signed-off-by: Chunming Zhou
1 - 100 of 172 matches
Mail list logo