Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem
On Sat, Aug 06, 2022 at 07:26:07PM +0300, Markuss Broks wrote: > Hi Greg, > > On 7/28/22 18:01, Greg Kroah-Hartman wrote: > > On Thu, Jul 28, 2022 at 05:52:04PM +0300, Markuss Broks wrote: > > > Hi Greg, > > > > > > On 7/28/22 17:39, Greg Kroah-Hartman wrote: > > > > On Thu, Jul 28, 2022 at 05:28:19PM +0300, Markuss Broks wrote: > > > > > Add early console support for generic linear framebuffer devices. > > > > > This driver supports probing from cmdline early parameters > > > > > or from the device-tree using information in simple-framebuffer node. > > > > > The EFI functionality should be retained in whole. > > > > > The driver was disabled on ARM because of a bug in early_ioremap > > > > > implementation on ARM. > > > > > > > > > > Signed-off-by: Markuss Broks > > > > > --- > > > > >.../admin-guide/kernel-parameters.txt | 12 +- > > > > >MAINTAINERS | 5 + > > > > >drivers/firmware/efi/Kconfig | 6 +- > > > > >drivers/firmware/efi/Makefile | 1 - > > > > >drivers/firmware/efi/earlycon.c | 246 -- > > > > >drivers/video/fbdev/Kconfig | 11 + > > > > >drivers/video/fbdev/Makefile | 1 + > > > > >drivers/video/fbdev/earlycon.c| 301 > > > > > ++ > > > > >8 files changed, 327 insertions(+), 256 deletions(-) > > > > >delete mode 100644 drivers/firmware/efi/earlycon.c > > > > >create mode 100644 drivers/video/fbdev/earlycon.c > > > > > > > > That should be a rename, not a delete/create, right? > > > > > > Should this change be split into two separate commits, > > > one for moving the file and the second for making changes? > > > > Git will show a rename and modification properly, if you use -M to git > > format-patch, so it should be fine. > > It appears that there are so many changes Git would refuse to make it a > "move" no matter what I do. What should be done here: should it be two > separate commits for move/change or should it just be kept as delete/create? One commit to move the file, and then add your changes on top of it might be the easiest to review, right? thanks, greg k-h
Re: New subsystem for acceleration devices
On Fri, Aug 5, 2022 at 6:03 AM Dave Airlie wrote: > > On Thu, 4 Aug 2022 at 17:44, Oded Gabbay wrote: > > > > On Thu, Aug 4, 2022 at 2:54 AM Dave Airlie wrote: > > > > > > On Thu, 4 Aug 2022 at 06:21, Oded Gabbay wrote: > > > > > > > > On Wed, Aug 3, 2022 at 10:04 PM Dave Airlie wrote: > > > > > > > > > > On Sun, 31 Jul 2022 at 22:04, Oded Gabbay > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > Greg and I talked a couple of months ago about preparing a new accel > > > > > > subsystem for compute/acceleration devices that are not GPUs and I > > > > > > think your drivers that you are now trying to upstream fit it as > > > > > > well. > > > > > > > > > > We've had some submissions for not-GPUs to the drm subsystem recently. > > > > > > > > > > Intel GNA, Intel VPU, NVDLA, rpmsg AI processor unit. > > > > > > > > > > why is creating a new subsystem at this time necessary? > > > > > > > > > > Are we just creating a subsystem to avoid the open source userspace > > > > > consumer rules? Or do we have some concrete reasoning behind it? > > > > > > > > > > Dave. > > > > > > > > Hi Dave. > > > > The reason it happened now is because I saw two drivers, which are > > > > doing h/w acceleration for AI, trying to be accepted to the misc > > > > subsystem. > > > > Add to that the fact I talked with Greg a couple of months ago about > > > > doing a subsystem for any compute accelerators, which he was positive > > > > about, I thought it is a good opportunity to finally do it. > > > > > > > > I also honestly think that I can contribute much to these drivers from > > > > my experience with the habana driver (which is now deployed in mass at > > > > AWS) and contribute code from the habana driver to a common framework > > > > for AI drivers. > > > > > > Why not port the habana driver to drm now instead? I don't get why it > > > wouldn't make sense? > > > > imho, no, I don't see the upside. This is not a trivial change, and > > will require a large effort. What will it give me that I need and I > > don't have now ? > > The opportunity for review, code sharing, experience of locking > hierarchy, mm integration? > > IMHO The biggest thing that drm has is the community of people who > understand accelerators, memory management, userspace command > submissions, fencing, dma-buf etc. > > It's hard to have input to those discussions from the outside, and > they are always ongoing. > > I think one of the Intel teams reported dropping a lot of code on > their drm port due to stuff already being there, I'd expect the same > for you. > > The opposite question is also valid, what does moving to a new > subsystem help you or others, when there is one with all the > infrastructure and more importantly reviewers. > > I'd be happy to have accelerator submaintainers, I'd be happy to even > create an ACCELERATOR property for non-gpu drivers, so they can opt > out of some of the GPUier stuff, like multiple device node users etc, > or even create a new class of device nodes under /dev/dri. > I'm taking all what you wrote seriously, these are all good points. As I wrote to Jason, I don't want to jump the gun here. I think we should discuss this and explore the possibilities that you suggested because I would like to reach consensus if possible. Maybe this is something we can discuss in LPC or in the kernel summit ? Oded > > > I totally agree. We need to set some rules and make sure everyone in > > the kernel community is familiar with them, because now you get > > different answers based on who you consult with. > > > > My rules of thumb that I thought of was that if you don't have any > > display (you don't need to support X/wayland) and you don't need to > > support opengl/vulkan/opencl/directx or any other gpu-related software > > stack, then you don't have to go through drm. > > In other words, if you don't have gpu-specific h/w and/or you don't > > need gpu uAPI, you don't belong in drm. > > What happens when NVIDIA submit a driver for just compute or intel? > for what is actually a GPU? > This has been suggested as workaround for our userspace rules a few times. > > If my GPU can do compute tasks, do I have to add an accelerator > subsystem driver alongside my GPU one? > > > After all, memory management services, or common device chars handling > > I can get from other subsystems (e.g. rdma) as well. I'm sure I could > > model my uAPI to be rdma uAPI compliant (I can define proprietary uAPI > > there as well), but this doesn't mean I belong there, right ? > > Good point, but I think accelerators do mostly belong in drm or media, > because there is enough framework around them to allow them to work, > without reinventing everything. > > > > > > > I think the one area I can see a divide where a new subsystem is for > > > accelerators that are single-user, one shot type things like media > > > drivers (though maybe they could be just media drivers). > > > > > > I think anything that does command offloading to firmware or qu
Re: New subsystem for acceleration devices
On Fri, Aug 5, 2022 at 3:22 AM Jason Gunthorpe wrote: > > On Thu, Aug 04, 2022 at 08:48:28PM +0300, Oded Gabbay wrote: > > > > The flip is true of DRM - DRM is pretty general. I bet I could > > > implement an RDMA device under DRM - but that doesn't mean it should > > > be done. > > > > > > My biggest concern is that this subsystem not turn into a back door > > > for a bunch of abuse of kernel APIs going forward. Though things > > > are > > > > How do you suggest to make sure it won't happen ? > > Well, if you launch the subsystem then it is your job to make sure it > doesn't happen - or endure the complaints :) Understood, I'll make sure there is no room for complaints. > > Accelerators have this nasty tendancy to become co-designed with their > SOCs in nasty intricate ways and then there is a desire to punch > through all the inconvenient layers to make it go faster. > > > > better now, we still see this in DRM where expediency or performance > > > justifies hacky shortcuts instead of good in-kernel architecture. At > > > least DRM has reliable and experienced review these days. > > Definitely. DRM has some parts that are really well written. For > > example, the whole char device handling with sysfs/debugfs and managed > > resources code. > > Arguably this should all be common code in the driver core/etc - what > value is a subsystem adding beyond that besides using it properly? I mainly see two things here: 1. If there is a subsystem which is responsible for creating and exposing the device character files, then there should be some code that connects between each device driver to that subsystem. i.e. There should be functions that each driver should call from its probe and release callback functions. Those functions should take care of the following: - Create metadata for the device, the device's minor(s) and the driver's ioctls table and driver's callback for file operations (both are common for all the driver's devices). Save all that metadata with proper locking. - Create the device char files themselves and supply file operations that will be called per each open/close/mmap/etc. - Keep track of all these objects' lifetime in regard to the device driver's lifetime, with proper handling for release. - Add common handling and entries of sysfs/debugfs for these devices with the ability for each device driver to add their own unique entries. 2. I think that you underestimate (due to your experience) the "using it properly" part... It is not so easy to do this properly for inexperienced kernel people. If we provide all the code I mentioned above, the device driver writer doesn't need to be aware of all these kernel APIs. > > It would be nice to at least identify something that could obviously > be common, like some kind of enumeration and metadata kind of stuff > (think like ethtool, devlink, rdma tool, nvemctl etc) Definitely. I think we can have at least one ioctl that will be common to all drivers from the start. A kind of information retrieval ioctl. There are many information points that I'm sure are common to most accelerators. We have an extensive information ioctl in the habanalabs driver and most of the information there is not habana specific imo. > > > I think that it is clear from my previous email what I intended to > > provide. A clean, simple framework for devices to register with, get > > services for the most basic stuff such as device char handling, > > sysfs/debugfs. > > This should all be trivially done by any driver using the core codes, > if you see gaps I'd ask why not improve the core code? > > > Later on, add more simple stuff such as memory manager > > and uapi for memory handling. I guess someone can say all that exists > > in drm, but like I said it exists in other subsystems as well. > > This makes sense to me, all accelerators need a way to set a memory > map, but on the other hand we are doing some very nifty stuff in this > area with iommufd and it might be very interesting to just have the > accelerator driver link to that API instead of building yet another > copy of pin_user_pages() code.. Especially with PASID likely becoming > part of any accelerator toolkit. Here I disagree with you. First of all, there are many relatively simple accelerators, especially in edge, where PASID is really not relevant. Second, even for the more sophisticated PCIe/CXL-based ones, PASID is not mandatory and I suspect that it won't be in 100% of those devices. But definitely that should be an alternative to the "classic" way of handling dma'able memory (pin_user_pages()). > > > I want to be perfectly honest and say there is nothing special here > > for AI. It's actually the opposite, it is a generic framework for > > compute only. Think of it as an easier path to upstream if you just > > want to do compute acceleration. Maybe in the future it will be more, > > but I can't predict the future. > > I can't either, and to be clear I'm only questioning the merit of a > "subsystem" eg with
Re: How to test whether a buffer is in linear format
Oh, facepalm. I didn’t even think to look at the numeric value. Sorry for the confusion. From: Simon Ser Sent: Saturday, August 6, 2022 3:10:53 PM To: Hoosier, Matt Cc: Pekka Paalanen; dri-devel@lists.freedesktop.org; wayland-de...@lists.freedesktop.org Subject: Re: How to test whether a buffer is in linear format CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set > to 0? What does that mean? A buffer only has a single modifier, and LINEAR == 0. > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://urldefense.com/v3/__https://source.puri.sm/Librem5/wlroots/-/merge_requests/63__;!!EJc4YC3iFmQ!RegnOCvgB8sugB2skP7I220urpYpvjg8fLOw4lDYr0BxH49vOvVoFTbpykg8Nvb5Wxn33tnxgLNRAW2eePiR$ This is not upstream wlroots. This change doesn't make sense to me at all. Either a driver supports modifiers and advertises support for it, either it doesn't and gbm_surface_create_with_modifiers fails. At any rate, forcing LINEAR in this code-path doesn't make sense. CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: [PATCH v2 3/3] efi: earlycon: Add support for generic framebuffers and move to console subsystem
On Sat, Aug 6, 2022 at 6:38 PM Markuss Broks wrote:
>
> Add early console support for generic linear framebuffer devices.
> This driver supports probing from cmdline early parameters
> or from the device-tree using information in simple-framebuffer node.
> The EFI functionality should be retained in whole.
> The driver was disabled on ARM because of a bug in early_ioremap
We refer to functions like func().
> implementation on ARM and on IA64 because of lack of early_memremap_prot.
Ditto.
...
> +#include
Can it be placed after linux/* ones?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
...
> +static int __init simplefb_earlycon_remap_fb(void)
> +{
> + unsigned long mapping;
+ Blank line.
> + /* bail if there is no bootconsole or it has been disabled already */
> + if (!earlycon_console || !(earlycon_console->flags & CON_ENABLED))
> + return 0;
> +
> + if (region_intersects(info.phys_base, info.size,
> + IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE) ==
> REGION_INTERSECTS)
> + mapping = MEMREMAP_WB;
> + else
> + mapping = MEMREMAP_WC;
> + info.virt_base = memremap(info.phys_base, info.size, mapping);
> +
> + return info.virt_base ? 0 : -ENOMEM;
Easier to read the standard pattern:
if (!info.virt_base)
return -ENOMEM;
return 0;
> +}
...
> +static void simplefb_earlycon_write_char(u8 *dst, unsigned char c, unsigned
> int h)
> +{
> + const u8 *src;
> + int m, n, bytes;
> + u8 x;
> +
> + bytes = BITS_TO_BYTES(font->width);
> + src = font->data + c * font->height * bytes + h * bytes;
> +
> + for (m = 0; m < font->width; m++) {
> + n = m % 8;
> + x = *(src + m / 8);
I would write it as
x = src[m / 8];
> + if ((x >> (7 - n)) & 1)
> + memset(dst, 0xff, (info.depth / 8));
Too many parentheses.
> + else
> + memset(dst, 0, (info.depth / 8));
Ditto.
> + dst += (info.depth / 8);
Ditto.
> + }
> +}
--
With Best Regards,
Andy Shevchenko
Re: How to test whether a buffer is in linear format
On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt wrote: > Any idea what’s up with some compositors adding code to infer > DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set > to 0? What does that mean? A buffer only has a single modifier, and LINEAR == 0. > Wlroots, for example, added this as a “safety net for drm drivers not > announcing modifiers”. > > https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 This is not upstream wlroots. This change doesn't make sense to me at all. Either a driver supports modifiers and advertises support for it, either it doesn't and gbm_surface_create_with_modifiers fails. At any rate, forcing LINEAR in this code-path doesn't make sense.
[GIT PULL] fbdev updates & fixes for v5.20-rc1
The following changes since commit ff6992735ade75aae3e35d16b17da1008d753d28: Linux 5.19-rc7 (2022-07-17 13:30:22 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/for-5.20/fbdev-1 for you to fetch changes up to 6ba592fa014f21f35a8ee8da4ca7b95a018f13e8: video: fbdev: s3fb: Check the size of screen before memset_io() (2022-08-05 18:44:59 +0200) fbdev fixes and updates for kernel v5.20-rc1 The two major changes in this patchset corrects VGA modes, color handling and various other smaller fixes in the Atari framebuffer (by Geert Uytterhoeven), and devm_* conversion, platform data fixes and header cleanups in the imxfb driver (by Uwe Kleine-König). Other small patches clean up code in sa1100fb, cirrusfb and omapfb, fix a refcount leak in amba-clcd (by Liang He), and adds parameter checks to arkfb, i740fb, vt8623fb and s3fb (by Zheyu Ma). Geert Uytterhoeven (14): video: fbdev: amiga: Simplify amifb_pan_display() video: fbdev: sa1100fb: Remove unused sa1100fb_setup() video: fbdev: cirrusfb: Make cirrusfb_zorro_unregister() static video: fbdev: Make *fb_setup() and *fb_init() static video: fbdev: atari: Simplify atafb_pan_display() video: fbdev: atari: Remove bogus FB_VMODE_YWRAP flags video: fbdev: atari: Fix inverse handling video: fbdev: atari: Fix ext_setcolreg() video: fbdev: atari: Remove unneeded casts from void * video: fbdev: atari: Remove unneeded casts to void * video: fbdev: atari: Fix TT High video mode vertical refresh video: fbdev: atari: Fix VGA modes video: fbdev: atari: Remove unused definitions and variables video: fbdev: atari: Remove backward bug-compatibility Helge Deller (1): video: fbdev: omapfb: Unexport omap*_update_window_async() Liang He (1): video: fbdev: amba-clcd: Fix refcount leak bugs Rustam Subkhankulov (1): video: fbdev: sis: fix typos in SiS_GetModeID() Uwe Kleine-König (4): video: fbdev: imxfb: Drop platform data support video: fbdev: imxfb: Drop unused symbols from header video: fbdev: imxfb: Fold into only user video: fbdev: imxfb: Convert request_mem_region + ioremap to devm_ioremap_resource Yang Yingliang (1): video: fbdev: imxfb: fix return value check in imxfb_probe() Zheyu Ma (5): video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() video: fbdev: i740fb: Check the argument of i740_calc_vclk() video: fbdev: vt8623fb: Check the size of screen before memset_io() video: fbdev: arkfb: Check the size of screen before memset_io() video: fbdev: s3fb: Check the size of screen before memset_io() Documentation/m68k/kernel-options.rst | 4 +- MAINTAINERS | 1 - drivers/video/fbdev/68328fb.c | 7 +- drivers/video/fbdev/amba-clcd.c | 24 -- drivers/video/fbdev/amifb.c | 15 +--- drivers/video/fbdev/arkfb.c | 9 +- drivers/video/fbdev/atafb.c | 103 +++ drivers/video/fbdev/cirrusfb.c| 2 +- drivers/video/fbdev/dnfb.c| 2 +- drivers/video/fbdev/fm2fb.c | 4 +- drivers/video/fbdev/hpfb.c| 4 +- drivers/video/fbdev/i740fb.c | 9 +- drivers/video/fbdev/imxfb.c | 134 +++--- drivers/video/fbdev/omap/hwa742.c | 3 +- drivers/video/fbdev/omap/omapfb.h | 9 -- drivers/video/fbdev/omap/omapfb_main.c| 3 +- drivers/video/fbdev/q40fb.c | 2 +- drivers/video/fbdev/s3fb.c| 2 + drivers/video/fbdev/sa1100fb.c| 41 - drivers/video/fbdev/sis/init.c| 4 +- drivers/video/fbdev/skeletonfb.c | 6 +- drivers/video/fbdev/valkyriefb.c | 10 +-- drivers/video/fbdev/vt8623fb.c| 2 + include/linux/platform_data/video-imxfb.h | 70 24 files changed, 136 insertions(+), 334 deletions(-) delete mode 100644 include/linux/platform_data/video-imxfb.h
Re: How to test whether a buffer is in linear format
Hi Pekka, Thanks. If I paraphrase, I think you’re telling me that gbm_bo_get_modifiers() == 0 is not strong enough then. That fits with the notes on the drm_fourcc.h declaration of the linear format flag: https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L448 Any idea what’s up with some compositors adding code to infer DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set to 0? Wlroots, for example, added this as a “safety net for drm drivers not announcing modifiers”. https://source.puri.sm/Librem5/wlroots/-/merge_requests/63 -Matt From: Pekka Paalanen Sent: Saturday, August 6, 2022 6:47:00 AM To: Hoosier, Matt Cc: wayland-de...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: Re: How to test whether a buffer is in linear format On Fri, 5 Aug 2022 12:32:01 + "Hoosier, Matt" wrote: > Suppose that I want to map a GPU buffer to the CPU and do image > analysis on it. I know all the usual cautions about this being a > poor performance option, etc. But suppose for the moment that the > use-case requires it. > > What's the right set of preconditions to conclude that the buffer > is in vanilla linear representation? In other words: no > compression, tiling, or any other proprietary GPU tricks that > would prevent accessing the pixel data in the same way you would > for a dumb buffer. > Hi Matt, whoever produced the buffer must *explicitly* tell you that the buffer is using the DRM format modifier DRM_FORMAT_MOD_LINEAR. > I think that requiring the modifiers to be 0x0 would suffice. But > is that overkill? Maybe there are situations when some modifiers > are set, but they don't affect the interpretation of the pixel > data. It is not overkill, it is strictly necessary. It is not sufficient though, you must know things like stride and offset for each plane as well in addition to width, height and pixel format. All those together should be enough. Note, that DRM_FORMAT_MOD_LINEAR must be explicit. If you lack a modifier, you cannot assume it is linear. No modifier can ever be ignored. If there is no modifier, or it is invalid, then you must use some originating-driver specific means to figure out what the "real modifier" is. Thanks, pq CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: [PATCH v2 1/3] drivers: serial: earlycon: Correct argument name
On Sat, Aug 6, 2022 at 6:37 PM Markuss Broks wrote: > > The "node" argument is actually an offset, and it's also > an "int", and not "unsigned long". Correct the of_setup_earlycon > function. Suggested-by: Greg KH? > Signed-off-by: Markuss Broks -- With Best Regards, Andy Shevchenko
[PATCH v2 2/3] drivers: serial: earlycon: Pass device-tree node
Pass a pointer to device-tree node in case the driver probed from
OF. This makes early console drivers able to fetch options from
device-tree node properties.
Signed-off-by: Markuss Broks
---
drivers/tty/serial/earlycon.c | 3 +++
include/linux/serial_core.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index
bc210ae8173d97d5ef422468acf2755a853cb943..be2f01520f6608f6ece725dd83d2526e30477b47
100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -304,6 +304,9 @@ int __init of_setup_earlycon(const struct earlycon_id
*match,
strlcpy(early_console_dev.options, options,
sizeof(early_console_dev.options));
}
+
+ early_console_dev.offset = offset;
+
earlycon_init(&early_console_dev, match->name);
err = match->setup(&early_console_dev, options);
earlycon_print_info(&early_console_dev);
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index
cbd5070bc87f42aa450c4ca7af8a9b59fbe88574..e65b9aba4e5fdaedb560d2cbbf326a11cfecbcac
100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -349,6 +349,7 @@ struct earlycon_device {
struct uart_port port;
char options[16]; /* e.g., 115200n8 */
unsigned int baud;
+ int offset;
};
struct earlycon_id {
--
2.37.0
[PATCH v2 1/3] drivers: serial: earlycon: Correct argument name
The "node" argument is actually an offset, and it's also
an "int", and not "unsigned long". Correct the of_setup_earlycon
function.
Signed-off-by: Markuss Broks
---
drivers/tty/serial/earlycon.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index
57c70851f22a0e78805f34d1a7700708104b6f6a..bc210ae8173d97d5ef422468acf2755a853cb943
100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -244,7 +244,7 @@ early_param("earlycon", param_setup_earlycon);
#ifdef CONFIG_OF_EARLY_FLATTREE
int __init of_setup_earlycon(const struct earlycon_id *match,
-unsigned long node,
+int offset,
const char *options)
{
int err;
@@ -255,25 +255,25 @@ int __init of_setup_earlycon(const struct earlycon_id
*match,
spin_lock_init(&port->lock);
port->iotype = UPIO_MEM;
- addr = of_flat_dt_translate_address(node);
+ addr = of_flat_dt_translate_address(offset);
if (addr == OF_BAD_ADDR) {
pr_warn("[%s] bad address\n", match->name);
return -ENXIO;
}
port->mapbase = addr;
- val = of_get_flat_dt_prop(node, "reg-offset", NULL);
+ val = of_get_flat_dt_prop(offset, "reg-offset", NULL);
if (val)
port->mapbase += be32_to_cpu(*val);
port->membase = earlycon_map(port->mapbase, SZ_4K);
- val = of_get_flat_dt_prop(node, "reg-shift", NULL);
+ val = of_get_flat_dt_prop(offset, "reg-shift", NULL);
if (val)
port->regshift = be32_to_cpu(*val);
- big_endian = of_get_flat_dt_prop(node, "big-endian", NULL) != NULL ||
+ big_endian = of_get_flat_dt_prop(offset, "big-endian", NULL) != NULL ||
(IS_ENABLED(CONFIG_CPU_BIG_ENDIAN) &&
-of_get_flat_dt_prop(node, "native-endian", NULL) != NULL);
- val = of_get_flat_dt_prop(node, "reg-io-width", NULL);
+of_get_flat_dt_prop(offset, "native-endian", NULL) != NULL);
+ val = of_get_flat_dt_prop(offset, "reg-io-width", NULL);
if (val) {
switch (be32_to_cpu(*val)) {
case 1:
@@ -291,11 +291,11 @@ int __init of_setup_earlycon(const struct earlycon_id
*match,
}
}
- val = of_get_flat_dt_prop(node, "current-speed", NULL);
+ val = of_get_flat_dt_prop(offset, "current-speed", NULL);
if (val)
early_console_dev.baud = be32_to_cpu(*val);
- val = of_get_flat_dt_prop(node, "clock-frequency", NULL);
+ val = of_get_flat_dt_prop(offset, "clock-frequency", NULL);
if (val)
port->uartclk = be32_to_cpu(*val);
--
2.37.0
[PATCH v2 0/3] Add generic framebuffer support to EFI earlycon driver
Make the EFI earlycon driver be suitable for any linear framebuffers. This should be helpful for early porting of boards with no other means of output, like smartphones/tablets. There seems to be an issue with early_ioremap function on ARM32, but I am unable to find the exact cause. It appears the mappings returned by it are somehow incorrect, thus the driver is disabled on ARM. EFI early console was disabled on IA64 previously because of missing early_memremap_prot, and this is inherited to this driver. This patch also changes behavior on EFI systems, by selecting the mapping type based on if the framebuffer region intersects with system RAM. If it does, it's common sense that it should be in RAM as a whole, and so the system RAM mapping is used. It was tested to be working on my PC (Intel Z490 platform), as well as several ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...). Markuss Broks (2): drivers: serial: earlycon: Pass device-tree node efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem v1 -> v2: - a new patch correcting serial/earlycon.c argument name to "offset" instead of "node" - move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig (IA64 has no early_memremap_prot) - move driver from fbdev to console subsystem - select EFI earlycon by default - fetch stride manually from device-tree, as on some devices it seems stride doesn't match the horizontal resolution * bpp. - use saner format (e.g. 1920x1080x32 instead of 1920,1080,32). .../admin-guide/kernel-parameters.txt | 12 +- MAINTAINERS | 5 + drivers/firmware/efi/Kconfig | 6 +- drivers/firmware/efi/Makefile | 1 - drivers/firmware/efi/earlycon.c | 246 -- drivers/tty/serial/earlycon.c | 3 + drivers/video/fbdev/Kconfig | 11 + drivers/video/fbdev/Makefile | 1 + drivers/video/fbdev/earlycon.c| 301 ++ include/linux/serial_core.h | 1 + 10 files changed, 331 insertions(+), 256 deletions(-) delete mode 100644 drivers/firmware/efi/earlycon.c create mode 100644 drivers/video/fbdev/earlycon.c -- 2.37.0
[PATCH v2 3/3] efi: earlycon: Add support for generic framebuffers and move to console subsystem
Add early console support for generic linear framebuffer devices. This driver supports probing from cmdline early parameters or from the device-tree using information in simple-framebuffer node. The EFI functionality should be retained in whole. The driver was disabled on ARM because of a bug in early_ioremap implementation on ARM and on IA64 because of lack of early_memremap_prot. Signed-off-by: Markuss Broks --- .../admin-guide/kernel-parameters.txt | 12 +- MAINTAINERS | 5 + drivers/firmware/efi/Kconfig | 7 +- drivers/firmware/efi/Makefile | 1 - drivers/firmware/efi/earlycon.c | 246 -- drivers/video/console/Kconfig | 11 + drivers/video/console/Makefile| 1 + drivers/video/console/earlycon.c | 305 ++ 8 files changed, 332 insertions(+), 256 deletions(-) delete mode 100644 drivers/firmware/efi/earlycon.c create mode 100644 drivers/video/console/earlycon.c diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 8090130b544b0701237a7b657a29c83c000a60f4..bccb1ac8978eb5cf7e2bb20834b1881b27040666 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1281,12 +1281,9 @@ specified address. The serial port must already be setup and configured. Options are not yet supported. - efifb,[options] + efifb Start an early, unaccelerated console on the EFI - memory mapped framebuffer (if available). On cache - coherent non-x86 systems that use system memory for - the framebuffer, pass the 'ram' option so that it is - mapped with the correct attributes. + memory mapped framebuffer (if available). linflex, Use early console provided by Freescale LINFlexD UART @@ -1294,6 +1291,11 @@ address must be provided, and the serial port must already be setup and configured. + simplefb,,xx + Use early console with simple framebuffer that is + pre-initialized by firmware. A valid base address, + width, height and pixel size must be provided. + earlyprintk=[X86,SH,ARM,M68k,S390] earlyprintk=vga earlyprintk=sclp diff --git a/MAINTAINERS b/MAINTAINERS index 1fc9ead83d2aa3e60ccc4cfa8ee16df09ef579bf..af8b8e289483b6a264d477145061bd0e0ba34a25 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7033,6 +7033,11 @@ Q: http://patchwork.linuxtv.org/project/linux-media/list/ T: git git://linuxtv.org/anttip/media_tree.git F: drivers/media/tuners/e4000* +EARLY CONSOLE FRAMEBUFFER DRIVER +M: Markuss Broks +S: Maintained +F: drivers/video/console/earlycon.c + EARTH_PT1 MEDIA DRIVER M: Akihiro Tsukada L: linux-me...@vger.kernel.org diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 7aa4717cdcac46f91dd202f868c463388eb02735..ea76ccfb9bcd8ba44ddca06052eaa442ed6c30f7 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -259,10 +259,9 @@ config EFI_DISABLE_PCI_DMA may be used to override this option. config EFI_EARLYCON - def_bool y - depends on SERIAL_EARLYCON && !ARM && !IA64 - select FONT_SUPPORT - select ARCH_USE_MEMREMAP_PROT + bool "EFI early console support" + select FB_EARLYCON + default y config EFI_CUSTOM_SSDT_OVERLAYS bool "Load custom ACPI SSDT overlay from an EFI variable" diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile index c02ff25dd47707090a2ab86ee4f330e467f878f5..64eea61fbb43d76ec2d5416d467dfbb9aa21bda0 100644 --- a/drivers/firmware/efi/Makefile +++ b/drivers/firmware/efi/Makefile @@ -44,6 +44,5 @@ obj-$(CONFIG_ARM64) += $(arm-obj-y) riscv-obj-$(CONFIG_EFI):= efi-init.o riscv-runtime.o obj-$(CONFIG_RISCV)+= $(riscv-obj-y) obj-$(CONFIG_EFI_CAPSULE_LOADER) += capsule-loader.o -obj-$(CONFIG_EFI_EARLYCON) += earlycon.o obj-$(CONFIG_UEFI_CPER_ARM)+= cper-arm.o obj-$(CONFIG_UEFI_CPER_X86)+= cper-x86.o diff --git a/drivers/firmware/efi/earlycon.c b/drivers/firmware/efi/earlycon.c deleted file mode 100644 index a52236e11e5f73ddea5bb1f42ca2ca7c42425dab.. --- a/drivers/firmware/efi/earlycon.c +++ /dev/null @@ -1,246 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -/* - * Copyright (C) 2013 Intel Corporation; author Matt Fleming - */ - -#include -#include -#include -#include
Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem
Hi Greg, On 7/28/22 18:01, Greg Kroah-Hartman wrote: On Thu, Jul 28, 2022 at 05:52:04PM +0300, Markuss Broks wrote: Hi Greg, On 7/28/22 17:39, Greg Kroah-Hartman wrote: On Thu, Jul 28, 2022 at 05:28:19PM +0300, Markuss Broks wrote: Add early console support for generic linear framebuffer devices. This driver supports probing from cmdline early parameters or from the device-tree using information in simple-framebuffer node. The EFI functionality should be retained in whole. The driver was disabled on ARM because of a bug in early_ioremap implementation on ARM. Signed-off-by: Markuss Broks --- .../admin-guide/kernel-parameters.txt | 12 +- MAINTAINERS | 5 + drivers/firmware/efi/Kconfig | 6 +- drivers/firmware/efi/Makefile | 1 - drivers/firmware/efi/earlycon.c | 246 -- drivers/video/fbdev/Kconfig | 11 + drivers/video/fbdev/Makefile | 1 + drivers/video/fbdev/earlycon.c| 301 ++ 8 files changed, 327 insertions(+), 256 deletions(-) delete mode 100644 drivers/firmware/efi/earlycon.c create mode 100644 drivers/video/fbdev/earlycon.c That should be a rename, not a delete/create, right? Should this change be split into two separate commits, one for moving the file and the second for making changes? Git will show a rename and modification properly, if you use -M to git format-patch, so it should be fine. It appears that there are so many changes Git would refuse to make it a "move" no matter what I do. What should be done here: should it be two separate commits for move/change or should it just be kept as delete/create? - Markuss
Re: [PATCH v5 19/33] doc-dyndbg: edit dynamic-debug-howto for brevity, audience
On Fri, Aug 05, 2022 at 03:53:41PM -0600, Jim Cromie wrote: > Rework/modernize docs: > > - use /proc/dynamic_debug/control in examples >its *always* there (when dyndbg is config'd), even when is not. >drop talk, its a distraction here. > > - alias ddcmd='echo $* > /proc/dynamic_debug/control >focus on args: declutter, hide boilerplate, make pwd independent. > > - swap sections: Viewing before Controlling. control file as Catalog. > > - focus on use by a system administrator >add an alias to make examples more readable >drop grep-101 lessons, admins know this. > > - use init/main.c as 1st example, thread it thru doc where useful. >everybodys kernel boots, runs these. > > - add *prdbg* api section >to the bottom of the file, its for developers more than admins. >move list of api functions there. > > - simplify - drop extra words, phrases, sentences. > > - add "decorator" flags line to unify "prefix", trim fmlt descriptions > > CC: linux-...@vger.kernel.org > Signed-off-by: Jim Cromie > The documentation LGTM (no new warnings). Reviewed-by: Bagas Sanjaya -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
Re: How to test whether a buffer is in linear format
On Fri, 5 Aug 2022 12:32:01 + "Hoosier, Matt" wrote: > Suppose that I want to map a GPU buffer to the CPU and do image > analysis on it. I know all the usual cautions about this being a > poor performance option, etc. But suppose for the moment that the > use-case requires it. > > What's the right set of preconditions to conclude that the buffer > is in vanilla linear representation? In other words: no > compression, tiling, or any other proprietary GPU tricks that > would prevent accessing the pixel data in the same way you would > for a dumb buffer. > Hi Matt, whoever produced the buffer must *explicitly* tell you that the buffer is using the DRM format modifier DRM_FORMAT_MOD_LINEAR. > I think that requiring the modifiers to be 0x0 would suffice. But > is that overkill? Maybe there are situations when some modifiers > are set, but they don't affect the interpretation of the pixel > data. It is not overkill, it is strictly necessary. It is not sufficient though, you must know things like stride and offset for each plane as well in addition to width, height and pixel format. All those together should be enough. Note, that DRM_FORMAT_MOD_LINEAR must be explicit. If you lack a modifier, you cannot assume it is linear. No modifier can ever be ignored. If there is no modifier, or it is invalid, then you must use some originating-driver specific means to figure out what the "real modifier" is. Thanks, pq pgp1ljYdPgBxl.pgp Description: OpenPGP digital signature
