IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6 ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel console until userspace takes over, and Oops
printer for some emergencies. Looking at drm drivers and the basic
vesa/efi fbdev drivers shows that only 3 drivers support any kind of
acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for
y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick,
and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA
flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only
user of this accel code (it's not exposed as uapi through ioctls),
which means we could garbage collect fairly enormous amounts of code
if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the
drivers for that have acceleration, we'd remove a huge gap in testing.
And there's no other even remotely comprehensive testing aside from
syzbot.
This patch here just disables the acceleration code by always
redrawing when scrolling. The plan is that once this has been merged
for well over a year in released kernels, we can start to go around
and delete a lot of code.
v2:
- Drop a few more unused local variables, somehow I missed the
compiler warnings (Sam)
- Fix typo in comment (Jiri)
- add a todo entry for the cleanup (Thomas)
v3: Remove more unused variables (0day)
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Peilin Ye <yepeilin.cs@gmail.com>
Cc: George Kennedy <george.kennedy@oracle.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>
Cc: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201029132229.4068359-1-daniel.vetter@ffwll.ch
For user-provided fonts, the framebuffer layer is using a magic
negative-indexing macro, FNTCHARCNT(), to keep track of their number of
characters:
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
For built-in fonts, it is using hard-coded values (256). This results in
something like the following:
map.length = (ops->p->userfont) ?
FNTCHARCNT(ops->p->fontdata) : 256;
This is unsatisfactory. In fact, there is already a `charcount` field in
our virtual console descriptor (see `struct console_font` inside `struct
vc_data`), let us use it:
map.length = vc->vc_font.charcount;
Recently we added a `charcount` field to `struct font_desc`. Use it to set
`vc->vc_font.charcount` properly. The idea is:
- We only use FNTCHARCNT() on `vc->vc_font.data` and `p->fontdata`.
Assume FNTCHARCNT() is working as intended;
- Whenever `vc->vc_font.data` is set, also set `vc->vc_font.charcount`
properly;
- We can now replace `FNTCHARCNT(vc->vc_font.data)` with
`vc->vc_font.charcount`;
- Since `p->fontdata` always point to the same font data buffer with
`vc->vc_font.data`, we can also replace `FNTCHARCNT(p->fontdata)` with
`vc->vc_font.charcount`.
In conclusion, set `vc->vc_font.charcount` properly in fbcon_startup(),
fbcon_init(), fbcon_set_disp() and fbcon_do_set_font(), then replace
FNTCHARCNT() with `vc->vc_font.charcount`. No more if-else between
negative-indexing macros and hard-coded values.
Do not include <linux/font.h> in fbcon_rotate.c and tileblit.c, since they
no longer need it.
Depends on patch "Fonts: Add charcount field to font_desc".
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/e460a5780e54e3022661d5f09555144583b4cc59.1605169912.git.yepeilin.cs@gmail.com
.con_font_set and .con_font_default callbacks should not pass `struct
console_font *` as a parameter, since `struct console_font` is a UAPI
structure.
We are trying to let them use our new kernel font descriptor, `struct
font_desc` instead. To make that work slightly easier, first delete all of
their no-op implementations used by dummy consoles.
This will make KD_FONT_OP_SET and KD_FONT_OP_SET_DEFAULT ioctl() requests
on dummy consoles start to fail and return `-ENOSYS`, which is intended,
since no user should ever expect such operations to succeed on dummy
consoles.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/9952c7538d2a32bb1a82af323be482e7afb3dedf.1605169912.git.yepeilin.cs@gmail.com
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
v5:
- Simplify panfrost_scheduler_stop() (Steven Price)
- Always restart the queue in panfrost_scheduler_start() even if
the status is corrupted (Steven Price)
v4:
- Rework the logic to prevent a race between drm_sched_start()
(reset work) and drm_sched_job_timedout() (timeout work)
- Drop Steven's R-b
- Add dma_fence annotation to the panfrost_reset() function (Daniel Vetter)
v3:
- Replace the atomic_cmpxchg() by an atomic_xchg() (Robin Murphy)
- Add Steven's R-b
v2:
- Use atomic_cmpxchg() to conditionally schedule the reset work
(Steven Price)
Fixes: 1a11a88cfd ("drm/panfrost: Fix job timeout handling")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105151704.2010667-1-boris.brezillon@collabora.com
Copy over the width/height in millimeters to the
(somewhat redundant) display info, and set up the
bus format and bus flags for the display.
When used as DPI this display requires DE to be
active low and pixel data to be output on the
negative edge. It might be that it was previously
used with a display controller that either does
not support these settings or was hardcoded to use
these as default. This information comes from the
source code of the Samsung GT-I9070 mobile phone.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110234653.2248594-6-linus.walleij@linaro.org
The OnePlus 6/T devices use different panels however they are
functionally identical with the only differences being the resolution.
The panels also don't seem to be used by any other devices, just combine
them into one driver.
The panels are: samsung,sofef00
and samsung,s6e3fc2x01
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[fixed checkpatch warnings]
Link: https://patchwork.freedesktop.org/patch/msgid/20201112161920.2671430-2-caleb@connolly.tech
The comment about them (also removed) says:
/* fb_rsrc and aper_rsrc aren't really used currently, but still exist
* in case we decide we need information on the BAR for BSD in the
* future.
*/
Well that was written 12 years ago in 2008. We are now in the future
and they are still superfluous. We can always add them again at a
later date if they are ever required.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/savage/savage_bci.c: In function ‘savage_driver_firstopen’:
drivers/gpu/drm/savage/savage_bci.c:580:24: warning: variable ‘aper_rsrc’ set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/savage/savage_bci.c:580:15: warning: variable ‘fb_rsrc’ set but not used [-Wunused-but-set-variable]
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201112190039.2785914-2-lee.jones@linaro.org
Increase the scaled image's theorical width/height until we find a
configuration that has valid scaling coefficients, up to 102% of the
screen's resolution. This makes sure that we can scale from almost
every resolution possible at the cost of a very small distorsion.
The CRTC_W / CRTC_H are not modified.
This algorithm was already in place but would not try to go above the
screen's resolution, and as a result would only work if the CRTC_W /
CRTC_H were smaller than the screen resolution. It will now try until it
reaches 102% of the screen's resolution.
Note that this algorithm exists mostly as a band-aid for a missing
functionality: it is not possible for userspace to request the closest
mode that would encapsulate the provided one, because the GEM buffer is
created beforehand. If there was a way to let the kernel tweak the mode,
I could write a better algorithm that would result in a better looking
picture.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201105083905.8780-1-paul@crapouillou.net
Currently drivers get called to move a buffer, but if they have to
move it temporarily through another space (SYSTEM->VRAM via TT)
then they can end up with a lot of ttm->driver->ttm call stacks,
if the temprorary space moves requires eviction.
Instead of letting the driver do all the placement/space for the
temporary, allow it to report back (-EMULTIHOP) and a placement (hop)
to the move code, which will then do the temporary move, and the
correct placement move afterwards.
This removes a lot of code from drivers, at the expense of
adding some midlayering. I've some further ideas on how to turn
it inside out, but I think this is a good solution to the call
stack problems.
v2: separate out the driver patches, add WARN for getting
MULTHOP in paths we shouldn't (Daniel)
v3: use memset (Christian)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: hristian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201109005432.861936-2-airlied@gmail.com
commit f8f6ae5d07 ("mm: always have io_remap_pfn_range() set
pgprot_decrypted()") moves the pgprot_decrypted() into
io_remap_pfn_range(). Delete any, now confusing, open coded calls that
directly precede io_remap_pfn_range():
- drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range()
- fb_mmap() immediately calls vm_iomap_memory() which is a convenience
wrapper for io_remap_pfn_range()
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-2e6a0db57868+166-drm_sme_clean_jgg@nvidia.com
The Intel Keem Bay display controller is only present on Intel Keem Bay
SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent asking the
user about this driver when configuring a kernel without Intel Keem Bay
platform support.
Note that:
1. The dependency on ARM is dropped, as Keem Bay SoCs are only
supported in arm64 kernel builds,
2. The dependencies on OF and COMMON_CLK can be dropped for
compile-testing, as the driver builds fine regardless.
Fixes: ed794057b0 ("drm/kmb: Build files for KeemBay Display driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110144350.3279147-1-geert+renesas@glider.be
If CONFIG_DRM_MIPI_DSI=n:
aarch64-linux-gnu-ld: drivers/gpu/drm/kmb/kmb_dsi.o: in function `kmb_dsi_host_unregister':
kmb_dsi.c:(.text+0xa48): undefined reference to `mipi_dsi_host_unregister'
aarch64-linux-gnu-ld: drivers/gpu/drm/kmb/kmb_dsi.o: in function `kmb_dsi_host_bridge_init':
kmb_dsi.c:(.text+0xb14): undefined reference to `mipi_dsi_host_register'
Fix this be selecting DRM_MIPI_DSI, like other drivers do.
Fixes: ed794057b0 ("drm/kmb: Build files for KeemBay Display driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201110144219.3278831-1-geert+renesas@glider.be
