The BOE NV133FHM-N61 is documented in the original commit to be a
13.3" panel, but the size listed in our struct doesn't match.
Specifically:
math.sqrt(30.0 * 30.0 + 18.7 * 18.7) / 2.54 ==> 13.92
Searching around on the Internet shows that the size that was in the
structure was the "Outline Size", not the "Display Area". Let's fix
it.
Also the Internet says that this panel supports 262K colors. That's
6bpp, not 8bpp.
Fixes: b0c664cc80 ("panel: simple: Add BOE NV133FHM-N61")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.1.I4d29651c0837b4095fb4951253f44036a371732f@changeid
Make an additional note on DRM format modifiers for x and y tiling. These
format modifiers are defined for BDW+ platforms and therefore definition
is not valid for older gens. This is due to address swizzling for tiled
surfaces is no longer used. For newer platforms main memory controller has
a more effective address swizzling algorithm.
v2: Rephrase comment (Daniel)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200506120827.12250-1-mika.kahola@intel.com
Suspending failed because there's no mode if the CRTC is being
disabled. Early-out in this case. This fixes runtime PM for ast.
v3:
* fixed commit message
v2:
* added Tested-by/Reported-by tags
* added Fixes tags and CC (Sam)
* improved comment
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reported-by: Cary Garrett <cogarre@gmail.com>
Tested-by: Cary Garrett <cogarre@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: b48e1b6ffd ("drm/ast: Add CRTC helpers for atomic modesetting")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: <stable@vger.kernel.org> # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090640.21561-1-tzimmermann@suse.de
Fix the following sparse warning:
drivers/gpu/drm/ast/ast_mode.c:564:6: warning:
symbol 'ast_primary_plane_helper_atomic_update'
was not declared. Should it be static?
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1588819206-11406-1-git-send-email-zou_wei@huawei.com
This adds support for TMP5P5 NT35596 1080x1920 video
mode panel that can be found on some Asus Zenfone 2
Laser (Z00T) devices.
This panel seems to only be found in this device
and we have no straightforward way of actually
getting the correct model number, as no schematics
are released publicly.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[fixed checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20200506210957.344590-2-konradybcio@gmail.com
We need to keep the reference to the drm_gem_object
until the last access by vkms_dumb_create.
Therefore, the put the object after it is used.
This fixes a use-after-free issue reported by syzbot.
While here, change vkms_gem_create() symbol to static.
Reported-and-tested-by: syzbot+e3372a2afe1e7ef04bc7@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200427214405.13069-1-ezequiel@collabora.com
This patch proposes a change in the behavior of the cursor to enable it as
soon as the vkms module is added. Enabling the cursor by default appears
to be an expected and more friendly behavior, especially when running IGT
tests.
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200321203740.pg3r7f4vybruowox@smtp.gmail.com
Fix the following coccicheck warning:
drivers/video/fbdev/valkyriefb.c:348:10-11: WARNING comparing pointer to
0, suggest !E
drivers/video/fbdev/valkyriefb.c:334:12-13: WARNING comparing pointer to
0
drivers/video/fbdev/valkyriefb.c:348:10-11: WARNING comparing pointer to
0
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429140942.8137-1-yanaijie@huawei.com
Some memory is vmalloc'ed in the 'w100fb_save_vidmem' function and freed in
the 'w100fb_restore_vidmem' function. (these functions are called
respectively from the 'suspend' and the 'resume' functions)
However, it is also freed in the 'remove' function.
In order to avoid a potential double free, set the corresponding pointer
to NULL once freed in the 'w100fb_restore_vidmem' function.
Fixes: aac51f09d9 ("[PATCH] w100fb: Rewrite for platform independence")
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Antonino Daplas <adaplas@pol.net>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: <stable@vger.kernel.org> # v2.6.14+
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200506181902.193290-1-christophe.jaillet@wanadoo.fr
Fix the following coccicheck warning:
drivers/video/fbdev/aty/atyfb_base.c:3822:3-10: WARNING: Assignment of
0/1 to bool variable
drivers/video/fbdev/aty/atyfb_base.c:3824:3-9: WARNING: Assignment of
0/1 to bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422071854.513-1-yanaijie@huawei.com
Fix the following coccicheck warning:
drivers/video/fbdev/uvesafb.c:48:12-17: WARNING: Assignment of 0/1 to
bool variable
drivers/video/fbdev/uvesafb.c:1827:3-13: WARNING: Assignment of 0/1 to
bool variable
drivers/video/fbdev/uvesafb.c:1829:3-13: WARNING: Assignment of 0/1 to
bool variable
drivers/video/fbdev/uvesafb.c:1835:3-9: WARNING: Assignment of 0/1 to
bool variable
drivers/video/fbdev/uvesafb.c:1837:3-9: WARNING: Assignment of 0/1 to
bool variable
drivers/video/fbdev/uvesafb.c:1839:3-8: WARNING: Assignment of 0/1 to
bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422071845.403-1-yanaijie@huawei.com
Fix the following coccicheck warning:
drivers/video/fbdev/udlfb.c:67:12-19: WARNING: Assignment of 0/1 to bool
variable
drivers/video/fbdev/udlfb.c:68:12-20: WARNING: Assignment of 0/1 to bool
variable
drivers/video/fbdev/udlfb.c:69:12-18: WARNING: Assignment of 0/1 to bool
variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422071836.49123-1-yanaijie@huawei.com
Fix the following coccicheck warning:
drivers/video/fbdev/i810/i810_main.c:1969:3-7: WARNING: Assignment of
0/1 to bool variable
drivers/video/fbdev/i810/i810_main.c:1971:3-8: WARNING: Assignment of
0/1 to bool variable
drivers/video/fbdev/i810/i810_main.c:1973:3-9: WARNING: Assignment of
0/1 to bool variable
drivers/video/fbdev/i810/i810_main.c:1975:3-7: WARNING: Assignment of
0/1 to bool variable
drivers/video/fbdev/i810/i810_main.c:2001:3-9: WARNING: Assignment of
0/1 to bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422071826.49038-1-yanaijie@huawei.com
Userspace can severely fragment rb_hole_addr rbtree by manipulating
alignment while allocating buffers. Fragmented rb_hole_addr rbtree
would result in large delays while allocating buffer object for a
userspace application. It takes long time to find suitable hole
because if we fail to find a suitable hole in the first attempt
then we look for neighbouring nodes using rb_prev()/rb_next().
Traversing rbtree using rb_prev()/rb_next() can take really long
time if the tree is fragmented.
This patch improves searches in fragmented rb_hole_addr rbtree by
modifying it to an augmented rbtree which will store an extra field
in drm_mm_node, subtree_max_hole. Each drm_mm_node now stores maximum
hole size for its subtree in drm_mm_node->subtree_max_hole. Using
drm_mm_node->subtree_max_hole, it is possible to eliminate a complete
subtree if that subtree is unable to serve a request hence reducing
number of rb_prev()/rb_next() used.
With this patch applied, 1 million bo allocs on amdgpu took ~8 sec,
compared to 50k bo allocs which took 28 sec without it.
partial test code:
int test_fragmentation(void)
{
int i = 0;
uint32_t minor_version;
uint32_t major_version;
struct amdgpu_bo_alloc_request request = {};
amdgpu_bo_handle vram_handle[MAX_ALLOC] = {};
amdgpu_device_handle device_handle;
request.alloc_size = 4096;
request.phys_alignment = 8192;
request.preferred_heap = AMDGPU_GEM_DOMAIN_VRAM;
int fd = open("/dev/dri/card0", O_RDWR | O_CLOEXEC);
amdgpu_device_initialize(fd, &major_version, &minor_version,
&device_handle);
for (i = 0; i < MAX_ALLOC; i++) {
amdgpu_bo_alloc(device_handle, &request, &vram_handle[i]);
}
for (i = 0; i < MAX_ALLOC; i++)
amdgpu_bo_free(vram_handle[i]);
return 0;
}
v2:
Use RB_DECLARE_CALLBACKS_MAX to maintain subtree_max_hole
v3:
insert_hole_addr() should be static a function
fix return value of next_hole_high_addr()/next_hole_low_addr()
Reported-by: kbuild test robot <lkp@intel.com>
v4:
Fix commit message.
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/364341/
Signed-off-by: Christian König <christian.koenig@amd.com>
It was removed in:
Author: Christian König <christian.koenig@amd.com>
Date: Wed Sep 25 11:38:50 2019 +0200
drm/ttm: remove pointers to globals
Signed-off-by: Maya Rashish <coypu@sdf.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/360750/
Signed-off-by: Christian König <christian.koenig@amd.com>
Source file was dual licenced but the header was omitted, fix that.
Contributors for this file are:
Daniel Vetter <daniel.vetter@ffwll.ch>
Matt Roper <matthew.d.roper@intel.com>
Maxime Ripard <mripard@kernel.org>
Noralf Trønnes <noralf@tronnes.org>
Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Emmanuel Vadot <manu@FreeBSD.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200430153347.85323-1-manu@FreeBSD.org
The Amlogic S805X/Y uses the same die as the S905X, but with more
limited graphics capabilities.
This adds a soc version detection adding specific limitations on the HDMI
mode selections.
Here, we limit to HDMI 1.2a max HDMI PHY clock frequency.
Changes sinces v1:
- Moved frequency check in the vclk code, and also checks DMT modes
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[narmstrong: fixed commit message with HDMI 1.2a instead of HDMI 1.3a]
Link: https://patchwork.freedesktop.org/patch/msgid/20200428092147.13698-1-narmstrong@baylibre.com
This is a driver for video encoder with VGA and DVI/HDMI outputs.
There is no documentation for the chip -- the operation was guessed from
what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
come from the ch7035 driver in Mediatek's GPL code dump.
Only bare minimum is implemented -- no fancy stuff, such as scaling. That
would only worsen our misery. We don't load the firmware and we don't need
to even bother enabling the MCU. There are probably no distributable
firmware images anyway.
Tested with a handful of monitors ranging from 1024x768@75 to 1400x1050@60,
with VGA as well as DVI.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424213539.93157-4-lkundrak@v3.sk
AM65x PG1 has a HW issue with YUV pixel formats, resulting in wrong
colors on the screen. This issue is fixed in PG2 hardware.
The driver currently has code to hide YUV pixel formats from the
userspace. To support PG2, we would need to add code to detect the SoC
version and hide the YUV formats based on that.
However, as PG1 will be phased out and PG2 will be the main platform, a
much simpler solution is just to drop the code in question. The downside
is that the users will be able to use YUV formats on PG1, getting wrong
colors on the screen. On the other hand, that may also be a plus, as the
same applications will now work on PG1 and PG2, even if the colors are
wrong on PG1.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429121022.3871-1-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
If the given videomode does not specify DISPLAY_FLAG_* for the specific
signal property, the driver used a default value. These defaults were
never thought through, as the expectation was that all the DISPLAY_FLAGS
are always set explicitly.
With DRM bridge and panel drivers this is not the case, and while that
issue should be resolved in the future, it's still good to have sane
signal defaults.
This patch changes the defaults to what the hardware has as reset
defaults. Also, based on my experience, I think they make sense and are
more likely correct than the defaults without this patch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200417114151.25843-1-tomi.valkeinen@ti.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
fix boe_tv105wum_nw0 display shift.
Signed-off-by: David Lu <david.lu@bitland.com.cn>
Fixes: 963518c124 ("drm/panel: support for boe,tv105wum-nw0 dsi video mode panel")
Cc: David Lu <david.lu@bitland.com.cn>
Cc: Nicolas Boichat <drinkcat@chromium.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[added fixes tag]
Link: https://patchwork.freedesktop.org/patch/msgid/20200428064521.21511-1-david.lu@bitland.com.cn
This converts the Synopsis MIPI DSI binding documentation to yaml and
should be quite straightforward. I've added a missing ref clk and also
added Philippe as maintainer b/c he's the original txt author following
the algorithm provided in Message-ID 20200420175909.GA5810@ravnborg.org.
Cc: Philippe CORNU <philippe.cornu@st.com>
Cc: devicetree@vger.kernel.org
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423100058.1734009-1-adrian.ratiu@collabora.com
The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
indicated by the current bus_format.
Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
connector_type to LVDS.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[updated patch subject]
Link: https://patchwork.freedesktop.org/patch/msgid/20200417114043.25381-1-tomi.valkeinen@ti.com
ITE Tech. Inc. (abbreviated as ITE ) is a professional fabless IC
design house. ITE's core technology includes PC and NB Controller chips,
Super I/O, High Speed Serial Interface, Video Codec, Touch Sensing,
Surveillance, OFDM, Sensor Fusion, and so on.
Our official name is "ITE Tech. Inc.", so change "ITE," to "ITE.".
more information on: http://www.ite.com.tw/
Signed-off-by: Allen Chen <allen.chen@ite.com.tw>
Acked-by: Rob Herring <robh@kernel.org>
Fixes: 17ff9478ff ("dt-bindings: Add ITE Tech prefix")
Cc: Marek Vasut <marex@denx.de>
Cc: devicetree@vger.kernel.org
Cc: Allen Chen <allen.chen@ite.com.tw>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[added fixes tag and updated subject]
Link: https://patchwork.freedesktop.org/patch/msgid/1587979103-5630-2-git-send-email-allen.chen@ite.com.tw
In the file drm_dp_helper.h we have a macro named
DP_DSC_THROUGHPUT_MODE_{0,1}_UPSUPPORTED, the correct name should be
DP_DSC_THROUGHPUT_MODE_{0,1}_UNSUPPORTED. This commits adjusts this typo
in the header file and in other places that attempt to access this
macro.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429184142.1867987-1-Rodrigo.Siqueira@amd.com
The struct member 'set_config' was assigned twice:
static const struct drm_crtc_funcs ast_crtc_funcs = {
.reset = ast_crtc_reset,
.set_config = drm_crtc_helper_set_config,
......
.set_config = drm_atomic_helper_set_config,
......
};
Since the second one is which we use now in fact, we can remove the
first one.
This fixes the following coccicheck warning:
drivers/gpu/drm/ast/ast_mode.c:932:50-51: set_config: first occurrence
line 934, second occurrence line 937
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429141010.8445-1-yanaijie@huawei.com
Some older versions of gcc badly optimize code that passes
an inline function argument into another function by reference,
causing huge stack usage:
drivers/gpu/drm/bridge/tc358768.c: In function 'tc358768_bridge_pre_enable':
drivers/gpu/drm/bridge/tc358768.c:840:1: error: the frame size of 2256 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Use a temporary variable as a workaround and add a comment pointing
to the gcc bug.
Fixes: ff1ca6397b ("drm/bridge: Add tc358768 driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428215408.4111675-1-arnd@arndb.de
powerpc allyesconfig fails like this:
drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'? [-Werror=implicit-function-declaration]
756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
| ^~~~~~~~~~~~~~~~~~~
| pgprot_cached
drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when assigning to type 'pgprot_t' {aka 'struct <anonymous>'} from type 'int'
Fix it by adding missing PPC32 dependency.
Fixes: a07a63b0e2 ("video: fbdev: controlfb: add COMPILE_TEST support")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/fe520316-3863-e6c4-9581-5d709f49e906@samsung.com
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
v2: Move drm_mode_hsync() next to its only users
Drop the TODO
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-2-ville.syrjala@linux.intel.com
MAINTAINERS got sorted in
commit 4400b7d68f ("MAINTAINERS: sort entries by entry name")
Merging from drm-next into drm-misc-next duplicated some of the
entries by restoring old, unsorted sections. Restore the sorted
list by removing the duplicates.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 08d99b2c23 ("Merge drm/drm-next into drm-misc-next")
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Dariusz Marcinkiewicz <darekm@google.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423074003.9637-1-tzimmermann@suse.de
Since the VExpress setup in pl111_vexpress.c is now just a single
function call, let's move it into pl111_versatile.c and we can further
simplify pl111_versatile_init() by moving the other pieces for VExpress
into pl111_vexpress_clcd_init().
Cc: Eric Anholt <eric@anholt.net>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200409013947.12667-4-robh@kernel.org
The init VExpress variants currently instantiates a 'muxfpga' driver for
the sole purpose of getting a regmap for it. There's no reason to
instantiate a driver and doing so just complicates things. The muxfpga
driver also isn't unregistered properly on module unload. Let's
just simplify all this this by just calling
devm_regmap_init_vexpress_config() directly.
Cc: Eric Anholt <eric@anholt.net>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200409013947.12667-3-robh@kernel.org
Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP.
As drm_file uses unkeyed wakeups, such a poll receives many spurious
wakeups from uninteresting events.
Use keyed wakeups to allow the wakeup target to more efficiently discard
these uninteresting events.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424145103.3048-1-kl@kl.wtf
This is only needed for hotpluggable connectors set up after
drm_dev_register().
Reviewed-by: Thomas Zimemrmann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Emil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-59-daniel.vetter@ffwll.ch
