Re: [PATCH 09/12] i2c: icy: Constify the software node

On Thu, 8 Apr 2021 23:22:51 +0200 Wolfram Sang wrote: > I read this as "Reviewed-by" ;) Sure, why not :) Reviewed-by: Max Staudt

Re: [PATCH 09/12] i2c: icy: Constify the software node

This looks great, thank you for constifying this. Finally it's clean again, yet much more flexible than the original platform_data approach when I first submitted the driver. Thanks everyone for your work Max

Re: [PATCH] fs/affs: Fix basic permission bits to actually work

On 9/25/20 12:07 PM, John Paul Adrian Glaubitz wrote: > Has there already been any progress on reviewing this? It has already been merged, and the maintainers have been so kind as to backport it to all maintained stable branches. Thanks for your help, everyone! Max

[PATCH] fs/affs: Fix basic permission bits to actually work

in the most peaceful manner. Also, update the documentation to represent the current state of things. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: sta...@vger.kernel.org Signed-off-by: Max Staudt --- Documentation/filesystems/affs.rst | 16 ++-- fs/affs/

[PATCH] i2c: icy: Fix build with CONFIG_AMIGA_PCMCIA=n

Amiga") Reported-by: kernel test robot Signed-off-by: Max Staudt --- drivers/i2c/busses/i2c-icy.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-icy.c b/drivers/i2c/busses/i2c-icy.c index 271470f4d..66c9923fc 100644 --- a/drivers/i2c/busses/i2c-icy.c +++ b/drivers/

Re: [PATCH] m68k: defconfig: Enable ICY I2C and LTC2990 on Amiga

Looks good, thanks Geert! Acked-by: Max Staudt

Re: [PATCH] m68k: defconfig: Update defconfigs for v5.4-rc1

Hi Geert, (CC linux-ide) As for the Amiga defconfig, how about moving from IDE drivers to ATA? The old IDE stack is slated for removal in less than 2 years, and people should probably move over to libata instead. How about the following changes? Is there any Amiga IDE controller left without

Re: [PATCH] m68k: defconfig: Update defconfigs for v5.4-rc1

On 10/01/2019 09:35 AM, Geert Uytterhoeven wrote: > Should support for ICY and LTC2990 be enabled in amiga_defconfig and/or > multi_defconfig? > > +CONFIG_I2C=m > +CONFIG_I2C_CHARDEV=m > +CONFIG_I2C_ICY=m > > +CONFIG_HWMON=m > +CONFIG_SENSORS_LTC2990=m Sounds like a good

Re: [PATCH v7] ata/pata_buddha: Probe via modalias instead of initcall

On 08/23/2019 02:59 PM, Jens Axboe wrote: > On 8/23/19 4:49 AM, Max Staudt wrote: >> Up until now, the pata_buddha driver would only check for cards on >> initcall time. Now, the kernel will call its probe function as soon >> as a compatible card is detected. > > Appli

[PATCH v7] ata/pata_buddha: Probe via modalias instead of initcall

ent device removal. v2: Rename 'zdev' to 'z' to make the patch easy to analyse with git diff --ignore-space-change Signed-off-by: Max Staudt --- drivers/ata/pata_buddha.c | 228 +++--- 1 file changed, 135 insertions(+), 93 deletions(-) diff --git a/driv

Re: [PATCH v6] ata/pata_buddha: Probe via modalias instead of initcall

On 08/23/2019 12:42 PM, Bartlomiej Zolnierkiewicz wrote: >> +static struct zorro_driver pata_buddha_driver = { >> +.name = "pata_buddha", >> +.id_table = pata_buddha_zorro_tbl, >> +.probe = pata_buddha_probe, >> +.remove = pata_buddha_remove, >> +

[PATCH v6] ata/pata_buddha: Probe via modalias instead of initcall

ake the patch easy to analyse with git diff --ignore-space-change Signed-off-by: Max Staudt --- drivers/ata/pata_buddha.c | 231 +++--- 1 file changed, 138 insertions(+), 93 deletions(-) diff --git a/drivers/ata/pata_buddha.c b/drivers/ata/pata_buddh

Re: [PATCH v5] ata/pata_buddha: Probe via modalias instead of initcall

Hi Bartlomiej, On 08/20/2019 02:06 PM, Bartlomiej Zolnierkiewicz wrote: > WARNING: line over 80 characters > #354: FILE: drivers/ata/pata_buddha.c:287: > +while ((z = > zorro_find_device(ZORRO_PROD_INDIVIDUAL_COMPUTERS_X_SURF, z))) { I see no good way to shorten this one. I think it's

Re: [PATCH v5] ata/pata_buddha: Probe via modalias instead of initcall

Hi Bartlomiej, Thank you very much for your review! Question below. On 08/20/2019 02:06 PM, Bartlomiej Zolnierkiewicz wrote: >> +/* Workaround for X-Surf: Save drvdata in case zorro8390 has set it */ >> +old_drvdata = dev_get_drvdata(>dev); > > This should be done only for type ==

Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support

On 08/16/2019 02:36 PM, Geert Uytterhoeven wrote: > Hi Max, > > On Fri, Aug 16, 2019 at 2:25 PM Max Staudt wrote: >> On 08/16/2019 01:07 PM, Geert Uytterhoeven wrote: >>> One minor nit: as the driver no longer uses any of_*() symbols, you can >>> replace &g

Re: [PATCH v3 2/3] hwmon/ltc2990: Generalise DT to fwnode support

On 08/16/2019 12:43 AM, Guenter Roeck wrote: > On Fri, Aug 16, 2019 at 12:19:42AM +0200, Max Staudt wrote: >> On 08/15/2019 02:58 PM, Max Staudt wrote: >>> - if (of_node) { >>> - ret = of_property_read_u32_arr

Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

On 08/15/2019 02:04 PM, Wolfram Sang wrote: >> When the PCF8584 is addressed as slave, this register >> must be loaded with the 7-bit I 2 C-bus address to which the >> PCF8584 is to respond. During initialization, the own >> address register S0' must be written to, regardless >> whether

Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support

Hi Guenter, Thanks for your feedback! Reply below. On 08/13/2019 03:24 PM, Guenter Roeck wrote: > Sorry, I don't understand. Why exactly can't you replace > of_property_read_u32_array() > with device_property_read_u32_array() and use fwnode_create_software_node() > in the calling code to set

Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support

On 08/13/2019 10:02 AM, Guenter Roeck wrote: > On Tue, Aug 13, 2019 at 01:52:36AM +0200, Max Staudt wrote: >> This allows code using i2c_new_device() to specify a measurement mode. >> >> Signed-off-by: Max Staudt >> Reviewed-by: Geert Uytterhoeven >>

Re: [PATCH] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

On 08/12/2019 11:37 AM, Geert Uytterhoeven wrote: >> + iowrite8(val, address); > > As this is on a Zorro bus, z_writeb()? I forgot to ask about this. What is the reasoning behind having a separate z_writeb() for Zorro? As far as I can see in arch/m68k/include/asm this maps 1:1 to a direct

Re: [PATCH v5] ata/pata_buddha: Probe via modalias instead of initcall

On 08/12/2019 06:48 PM, Max Staudt wrote: > +/* > + * We cannot have a modalias for X-Surf boards, as it competes with the > + * zorro8390 network driver. As a stopgap measure until we have proper > + * MFC support for this board, we manually attach to it late after Zorro > + * has

[PATCH v5] ata/pata_buddha: Probe via modalias instead of initcall

in case zorro8390 is active. v4: Clean up pata_buddha_probe() by using ent->driver_data. Support X-Surf via late_initcall() v3: Clean up devm_*, implement device removal. v2: Rename 'zdev' to 'z' to make the patch easy to analyse with git diff --ignore-space-change Signed-off-by:

Re: [PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

On 08/12/2019 05:01 PM, Bartlomiej Zolnierkiewicz wrote: >> Unfortunately, pata_buddha_exit() is void, and thus can't fail. According to >> Documentation/kernel-hacking/hacking.rst this is by design. > > You are of course right and the example code is broken > (+ I need more caffeine). Hey!

Re: [PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

On 08/12/2019 02:15 PM, Bartlomiej Zolnierkiewicz wrote: >> What's a good way to do that, given that we now have module_exit()> defined >> and an exit function is void? > > What about something like this: > > static bool xsurf_present; > ... > static int __init pata_buddha_late_init(void) > ...

Re: [PATCH] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

On 08/12/2019 01:07 PM, Geert Uytterhoeven wrote: >> It sets the sensor modes in the LTC2990 and enables the three sensors listed >> below. I should have clarified this. >> >> I tried to integrate this in the driver, but ltc2990 only allows reading >> this configuration out of a device tree. Is

Re: [PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

Hi Bartlomiej, Thanks for your feedback! On 08/12/2019 12:42 PM, Bartlomiej Zolnierkiewicz wrote: > > ide/buddha driver cannot be unloaded currently (it lacks module_exit()). > > [... snip ...] > > It should work exactly like the old code in case of X-Surf, > what do we need to release? So

Re: [PATCH] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

Hi Geert, Thanks for your feedback! Replies below. On 08/12/2019 11:37 AM, Geert Uytterhoeven wrote: > What about the RTC? The schematics show both a ds1620 and pcf8583. Oh no! I missed those in the original project, in my mind it didn't have any extra hardware at all. I only own the new

Re: [PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

Replying to my own patch with two more questions: On 08/11/2019 05:36 PM, Max Staudt wrote: > - /* allocate host */ > - host = ata_host_alloc(>dev, nr_ports); Actually, this is an issue even the existing pata_buddha has: ata_host_alloc() will dev_set_drvdata(

Re: [PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

Hi all, Thank you for your reviews. I hope this patch fixes all issues that have been raised. In case I've missed something, please let me know. Unfortunately I can't test the X-Surf part, as I don't own that board. I would be grateful for extra careful review of that part. Max

[PATCH v4] ata/pata_buddha: Probe via modalias instead of initcall

vm_*, implement device removal. v2: Rename 'zdev' to 'z' to make the patch easy to analyse with git diff --ignore-space-change Tested-by: Max Staudt Signed-off-by: Max Staudt --- drivers/ata/pata_buddha.c | 243 -- 1 file changed, 150 insertions(+),

Re: [PATCH] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

On 08/11/2019 06:32 AM, Max Staudt wrote: > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -1300,6 +1300,17 @@ config I2C_ELEKTOR > This support is also available as a module. If so, the module > will be called i2c-elektor. >

[PATCH] i2c/busses: Add i2c-icy for I2C on m68k/Amiga

machine. Tested-by: Max Staudt Signed-off-by: Max Staudt --- MAINTAINERS | 6 ++ drivers/i2c/busses/Kconfig | 11 +++ drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-icy.c | 224 +++ 4 files changed, 242 insertions(+) create

Re: [PATCH v3] ata/pata_buddha: Probe via modalias instead of initcall

On 07/29/2019 01:30 PM, Geert Uytterhoeven wrote: >> What shall I do? Maybe as a stop-gap measure, we could hard-code a >> module_init() again, just for X-Surf? It's been good enough until a >> few weeks ago, so what could go wrong ;) > > In the short run: keep on using drivers/ide/buddha.c? See

Re: [PATCH v3] ata/pata_buddha: Probe via modalias instead of initcall

Hi Geert, On 07/29/2019 11:05 AM, Geert Uytterhoeven wrote: >> --- a/drivers/ata/pata_buddha.c >> +++ b/drivers/ata/pata_buddha.c > >> +static const struct zorro_device_id pata_buddha_zorro_tbl[] = { >> + { ZORRO_PROD_INDIVIDUAL_COMPUTERS_BUDDHA, }, >> + {

[PATCH v3] ata/pata_buddha: Probe via modalias instead of initcall

--ignore-space-change Tested-by: Max Staudt Signed-off-by: Max Staudt --- drivers/ata/pata_buddha.c | 215 ++ 1 file changed, 121 insertions(+), 94 deletions(-) diff --git a/drivers/ata/pata_buddha.c b/drivers/ata/pata_buddha.c index 11a8044ff..b68392935

Re: [PATCH v2] ata/pata_buddha: Probe via modalias instead of initcall

On 07/25/2019 07:33 PM, Max Staudt wrote: > On 07/25/2019 07:03 PM, Bartlomiej Zolnierkiewicz wrote: >> Please try to implement it, should be as simple as: >> >> static void pata_buddha_remove(struct zorro_dev *zdev) >> { >> struct ata_

Re: [PATCH v2] ata/pata_buddha: Probe via modalias instead of initcall

On 07/25/2019 07:03 PM, Bartlomiej Zolnierkiewicz wrote: >> +err_ata_host_alloc: >> +switch (type) { >> +case BOARD_BUDDHA: >> +case BOARD_CATWEASEL: >> +default: >> +devm_release_mem_region(>dev, >> +board + BUDDHA_BASE1, >> +

[PATCH v2] ata/pata_buddha: Probe via modalias instead of initcall

to analyse with git diff --ignore-space-change Tested-by: Max Staudt Signed-off-by: Max Staudt --- drivers/ata/pata_buddha.c | 240 -- 1 file changed, 146 insertions(+), 94 deletions(-) diff --git a/drivers/ata/pata_buddha.c b/drivers/ata/pata_buddha.c

[RFC PATCH v3 04/13] bootsplash: Add corner positioning

This allows showing multiple logos, each in its own position, relative to the eight screen corners. Signed-off-by: Max Staudt <msta...@suse.de> --- drivers/video/fbdev/core/bootsplash_render.c | 136 ++- include/uapi/linux/bootsplash_file.h | 45 ++

[RFC PATCH v3 04/13] bootsplash: Add corner positioning

This allows showing multiple logos, each in its own position, relative to the eight screen corners. Signed-off-by: Max Staudt --- drivers/video/fbdev/core/bootsplash_render.c | 136 ++- include/uapi/linux/bootsplash_file.h | 45 - 2 files changed, 178

[RFC PATCH v3 02/13] bootsplash: Add file reading and picture rendering

* and tell the kernel to use it as follows: bootsplash.bootfile=mypath/myfile Since the splash code is using request_firmware() to load the file, the path has to be beneath /lib/firmware. Signed-off-by: Max Staudt <msta...@suse.de> --- MAINTAINERS| 1

[RFC PATCH v3 02/13] bootsplash: Add file reading and picture rendering

* and tell the kernel to use it as follows: bootsplash.bootfile=mypath/myfile Since the splash code is using request_firmware() to load the file, the path has to be beneath /lib/firmware. Signed-off-by: Max Staudt --- MAINTAINERS| 1 + drivers/video/

[RFC PATCH v3 07/13] vt: Add keyboard hook to disable bootsplash

Let's disable the splash if the user presses ESC or F1-F12 on a VT. The F1-F12 check is to disable the splash on VT switches. Signed-off-by: Max Staudt <msta...@suse.de> --- drivers/tty/vt/keyboard.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/

[RFC PATCH v3 07/13] vt: Add keyboard hook to disable bootsplash

Let's disable the splash if the user presses ESC or F1-F12 on a VT. The F1-F12 check is to disable the splash on VT switches. Signed-off-by: Max Staudt --- drivers/tty/vt/keyboard.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/tty/vt/keyboard.c b

[RFC PATCH v3 09/13] fbcon: Disable bootsplash on oops

Signed-off-by: Max Staudt <msta...@suse.de> Reviewed-by: Oliver Neukum <oneu...@suse.com> --- drivers/video/fbdev/core/fbcon.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 9a39a6fcfe98..

[RFC PATCH v3 09/13] fbcon: Disable bootsplash on oops

Signed-off-by: Max Staudt Reviewed-by: Oliver Neukum --- drivers/video/fbdev/core/fbcon.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 9a39a6fcfe98..8a9c67e1c5d8 100644 --- a/drivers/video/fbdev/core

[RFC PATCH v3 01/13] bootsplash: Initial implementation showing black screen

/linux/if_bonding.h +BOOTSPLASH +M: Max Staudt <msta...@suse.de> +L: linux-fb...@vger.kernel.org +S: Maintained +F: drivers/video/fbdev/core/bootsplash*.* +F: drivers/video/fbdev/core/dummycon.c +F: include/linux/bootsplash.h + BPF (Safe dynamic programs and tools)

[RFC PATCH v3 05/13] bootsplash: Add animation support

really make sense to animate more than one object at a time anyway. Furthermore, this patch introduces a check for reusing a framebuffer where the splash has recently been painted on - in this case, we only redraw the objects that are animated. Signed-off-by: Max Staudt <msta...@suse

[RFC PATCH v3 05/13] bootsplash: Add animation support

really make sense to animate more than one object at a time anyway. Furthermore, this patch introduces a check for reusing a framebuffer where the splash has recently been painted on - in this case, we only redraw the objects that are animated. Signed-off-by: Max Staudt --- drivers/video

[RFC PATCH v3 01/13] bootsplash: Initial implementation showing black screen

BOOTSPLASH +M: Max Staudt +L: linux-fb...@vger.kernel.org +S: Maintained +F: drivers/video/fbdev/core/bootsplash*.* +F: drivers/video/fbdev/core/dummycon.c +F: include/linux/bootsplash.h + BPF (Safe dynamic programs and tools) M: Alexei Starovoitov M: Daniel Borkman

[RFC PATCH v3 10/13] Documentation: Add bootsplash main documentation

Signed-off-by: Max Staudt <msta...@suse.de> --- .../ABI/testing/sysfs-platform-bootsplash | 11 + Documentation/bootsplash.rst | 285 + MAINTAINERS| 2 + 3 files changed, 298 insertions(+) creat

[RFC PATCH v3 10/13] Documentation: Add bootsplash main documentation

Signed-off-by: Max Staudt --- .../ABI/testing/sysfs-platform-bootsplash | 11 + Documentation/bootsplash.rst | 285 + MAINTAINERS| 2 + 3 files changed, 298 insertions(+) create mode 100644

[RFC PATCH v3 06/13] vt: Redraw bootsplash fully on console_unblank

. Enable splash 3. Start X (or any other KD_GRAPHICS program) 4. Exit X 5. Splash is not seen, apart from animations Signed-off-by: Max Staudt <msta...@suse.de> Reviewed-by: Oliver Neukum <oneu...@suse.com> --- drivers/tty/vt/vt.c | 2 ++ drivers/video/fbdev/core/boots

[RFC PATCH v3 06/13] vt: Redraw bootsplash fully on console_unblank

. Enable splash 3. Start X (or any other KD_GRAPHICS program) 4. Exit X 5. Splash is not seen, apart from animations Signed-off-by: Max Staudt Reviewed-by: Oliver Neukum --- drivers/tty/vt/vt.c | 2 ++ drivers/video/fbdev/core/bootsplash.c | 15 +-- include/linux

[RFC PATCH v3 13/13] tools/bootsplash: Add script and data to create sample file

Also, mention this in the bootsplash documentation. Signed-off-by: Max Staudt <msta...@suse.de> --- Documentation/bootsplash.rst | 10 ++ tools/bootsplash/.gitignore| 3 ++ tools/bootsplash/ajax-loader.gif | Bin 0 -> 3208 bytes tools/bootsplash/bootsplash-tux

[RFC PATCH v3 13/13] tools/bootsplash: Add script and data to create sample file

Also, mention this in the bootsplash documentation. Signed-off-by: Max Staudt --- Documentation/bootsplash.rst | 10 ++ tools/bootsplash/.gitignore| 3 ++ tools/bootsplash/ajax-loader.gif | Bin 0 -> 3208 bytes tools/bootsplash/bootsplash-tux.sh |

[RFC PATCH v3 11/13] bootsplash: sysfs entries to load and unload files

Oct 2017 +KernelVersion: 4.14 +Contact: Max Staudt <msta...@suse.de> +Description: + Can only be set. + + Any value written will cause the splash to be disabled and + internal memory structures to be freed. + + A fir

[RFC PATCH v3 11/13] bootsplash: sysfs entries to load and unload files

whenever fbcon would show a text console (i.e. no graphical application is running), and a splash file is loaded. + +What: /sys/devices/platform/bootsplash.0/drop_splash +Date: Oct 2017 +KernelVersion: 4.14 +Contact: Max Staudt

[RFC PATCH v3 03/13] bootsplash: Flush framebuffer after drawing

interface - we also match some known ones, currently: - ast - cirrus - mgag200 Signed-off-by: Max Staudt <msta...@suse.de> Reviewed-by: Oliver Neukum <oneu...@suse.com> --- drivers/video/fbdev/core/bootsplash.c | 2 ++ drivers/video/fbdev/core/bootsplash_internal.h | 1 + d

[RFC PATCH v3 03/13] bootsplash: Flush framebuffer after drawing

interface - we also match some known ones, currently: - ast - cirrus - mgag200 Signed-off-by: Max Staudt Reviewed-by: Oliver Neukum --- drivers/video/fbdev/core/bootsplash.c | 2 ++ drivers/video/fbdev/core/bootsplash_internal.h | 1 + drivers/video/fbdev/core/bootsplash_render.c | 33

[RFC PATCH v3 12/13] tools/bootsplash: Add a basic splash file creation tool

Signed-off-by: Max Staudt <msta...@suse.de> --- MAINTAINERS | 1 + tools/bootsplash/.gitignore | 1 + tools/bootsplash/Makefile| 9 + tools/bootsplash/bootsplash-packer.c | 471 +++ 4 files changed, 482 inse

[RFC PATCH v3 12/13] tools/bootsplash: Add a basic splash file creation tool

Signed-off-by: Max Staudt --- MAINTAINERS | 1 + tools/bootsplash/.gitignore | 1 + tools/bootsplash/Makefile| 9 + tools/bootsplash/bootsplash-packer.c | 471 +++ 4 files changed, 482 insertions(+) create mode

[RFC PATCH v3 00/13] Kernel based bootsplash

Dear fbdev/fbcon/dri developers, Thanks for all the valuable feedback. I've looked into the suggestions you made, and found that it doesn't currently make sense to continue working on the splash code, given the low practical interest I've received on LKML. The code is, and always has been,

[RFC PATCH v3 00/13] Kernel based bootsplash

Dear fbdev/fbcon/dri developers, Thanks for all the valuable feedback. I've looked into the suggestions you made, and found that it doesn't currently make sense to continue working on the splash code, given the low practical interest I've received on LKML. The code is, and always has been,

[RFC PATCH v3 08/13] sysrq: Disable bootsplash on SAK

When the user requests a clean TTY via the SAK SysRq, that means he really wants to use the console. Let's disable the bootsplash, even if the request is not on a VT, as the user probably knows what he's doing and it's more helpful to get out of his way. Signed-off-by: Max Staudt <m

[RFC PATCH v3 08/13] sysrq: Disable bootsplash on SAK

When the user requests a clean TTY via the SAK SysRq, that means he really wants to use the console. Let's disable the bootsplash, even if the request is not on a VT, as the user probably knows what he's doing and it's more helpful to get out of his way. Signed-off-by: Max Staudt Reviewed

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/31/2017 01:53 PM, Alan Cox wrote: > On Tue, 19 Dec 2017 15:07:53 +0100 > Oliver Neukum wrote: > >> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/31/2017 01:53 PM, Alan Cox wrote: > On Tue, 19 Dec 2017 15:07:53 +0100 > Oliver Neukum wrote: > >> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter: Would you like me to extend the FB API or not? >>> >>> Yes. Well for real I'd like you to do kms, so maybe you need to

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/31/2017 01:44 PM, Alan Cox wrote: >> So fundamentally I don't think an in-kernel bootsplash is a bad idea. >> But most likely you want this on a highly embedded system, which > > It wouldn't be in kernel on such a device, it'll be in the bootstrap > before (or on a dual core device quite

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/31/2017 01:44 PM, Alan Cox wrote: >> So fundamentally I don't think an in-kernel bootsplash is a bad idea. >> But most likely you want this on a highly embedded system, which > > It wouldn't be in kernel on such a device, it'll be in the bootstrap > before (or on a dual core device quite

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/31/2017 01:35 PM, Alan Cox wrote: > For embedded every KB counts. That is likely to remain the same for some > time because at the end of the day small devices are constrained about the > amount of SRAM you can put on die and the amount of power you can afford > for DRAM. Fascinating,

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/31/2017 01:35 PM, Alan Cox wrote: > For embedded every KB counts. That is likely to remain the same for some > time because at the end of the day small devices are constrained about the > amount of SRAM you can put on die and the amount of power you can afford > for DRAM. Fascinating,

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/29/2017 06:13 PM, Jani Nikula wrote: > I think the first issue is the boot manager (e.g. grub) messing up > whatever the BIOS or GOP or whatever drew. If I don't touch any buttons, > I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC > some BIOSes let you set up your own

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/29/2017 06:13 PM, Jani Nikula wrote: > I think the first issue is the boot manager (e.g. grub) messing up > whatever the BIOS or GOP or whatever drew. If I don't touch any buttons, > I'd prefer the Lenovo or VAIO or NUC or whatever logo stay there. IIRC > some BIOSes let you set up your own

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/21/2017 10:48 AM, Daniel Vetter wrote: > Ok, here's my expectation: > > - fix plymouth and driver loading > > If the plymouth maintainer tells me that's impossible, I'll look at this > again. And no, this does not require killing drivers with SIGBUS, at least > not with drm. Meanwhile I

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/21/2017 10:48 AM, Daniel Vetter wrote: > Ok, here's my expectation: > > - fix plymouth and driver loading > > If the plymouth maintainer tells me that's impossible, I'll look at this > again. And no, this does not require killing drivers with SIGBUS, at least > not with drm. Meanwhile I

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/21/2017 03:51 PM, Ray Strode wrote: > Hi, > > On Wed, Dec 20, 2017 at 11:44 AM Max Staudt <msta...@suse.de> wrote: >> It'd be nice to see this bug fixed, as it happens only occasionally (as is >> the nature of a >> race condition), and was thus really har

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/21/2017 03:51 PM, Ray Strode wrote: > Hi, > > On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote: >> It'd be nice to see this bug fixed, as it happens only occasionally (as is >> the nature of a >> race condition), and was thus really hard to debug. I'm sure it

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/20/2017 04:35 PM, Ray Strode wrote: > Hi, > >> Actually, I don't want that :) >> >> This was a design decision that I've made to keep the code small and simple >> to audit. >> As it is, the simple bootsplash code will make 99% of people happy. > You think only 1% of linux users have more

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/20/2017 04:35 PM, Ray Strode wrote: > Hi, > >> Actually, I don't want that :) >> >> This was a design decision that I've made to keep the code small and simple >> to audit. >> As it is, the simple bootsplash code will make 99% of people happy. > You think only 1% of linux users have more

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:21 PM, Ray Strode wrote: > If we've reached the scenario you're discussing above, the real > failure is that the KMS > driver took too long to load. DRM is the platform graphics api. If > it's not loading > timely enough to show graphics then that's the problem! It sounds > like

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:21 PM, Ray Strode wrote: > If we've reached the scenario you're discussing above, the real > failure is that the KMS > driver took too long to load. DRM is the platform graphics api. If > it's not loading > timely enough to show graphics then that's the problem! It sounds > like

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:19 PM, Daniel Vetter wrote: > On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter <dan...@ffwll.ch> wrote: >> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt <msta...@suse.de> wrote: >>> On 12/20/2017 11:14 AM, Daniel Vetter wrote: >>>> btw since I

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:19 PM, Daniel Vetter wrote: > On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote: >> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote: >>> On 12/20/2017 11:14 AM, Daniel Vetter wrote: >>>> btw since I'm probably sounding a bit too grumpy he

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:11 PM, Daniel Vetter wrote: > So fundamentally I don't think an in-kernel bootsplash is a bad idea. > But most likely you want this on a highly embedded system, which > probably is compiled for your exact hw, with pretty much everything > built in. Also, no fbcon, maybe even no vt

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 04:11 PM, Daniel Vetter wrote: > So fundamentally I don't think an in-kernel bootsplash is a bad idea. > But most likely you want this on a highly embedded system, which > probably is compiled for your exact hw, with pretty much everything > built in. Also, no fbcon, maybe even no vt

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 11:14 AM, Daniel Vetter wrote: > btw since I'm probably sounding a bit too grumpy here: I'd very much > support this. I think bootsplash in kernel has a bunch of uses, and it > shouldn't be hard to get non-suse people to cheer for it (makes merging > easier if it's not just a one-off

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 11:14 AM, Daniel Vetter wrote: > btw since I'm probably sounding a bit too grumpy here: I'd very much > support this. I think bootsplash in kernel has a bunch of uses, and it > shouldn't be hard to get non-suse people to cheer for it (makes merging > easier if it's not just a one-off

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 11:06 AM, Neil Armstrong wrote: > My 2cents about this patchset: > You did a good job about all the animation and splash logic, but for me all > this fbcon > stuff is a huge hack, please use a standard and modern display subsystem en > leave fbcon > die alone Thanks for the

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 11:06 AM, Neil Armstrong wrote: > My 2cents about this patchset: > You did a good job about all the animation and splash logic, but for me all > this fbcon > stuff is a huge hack, please use a standard and modern display subsystem en > leave fbcon > die alone Thanks for the

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 10:43 AM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: >>> So essentially you're telling me that on a current general purpose >>> distro the gfx driver loading is a dump

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/20/2017 10:43 AM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: >>> So essentially you're telling me that on a current general purpose >>> distro the gfx driver loading is a dump

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 10:01 PM, Ray Strode wrote: > Hi, > > On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt <msta...@suse.de> wrote: >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a >> functional extension of that. It just happens that fbcon

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

On 12/19/2017 10:01 PM, Ray Strode wrote: > Hi, > > On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote: >> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a >> functional extension of that. It just happens that fbcon sits on top of FB, >> s

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 09:30 PM, Ray Strode wrote: > Hi, > >> For example, having a userspace splash that starts as early as it can >> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail >> reserving the entirety of video RAM, and thus fail loading. This cannot be >> fixed. > well the fix

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 09:30 PM, Ray Strode wrote: > Hi, > >> For example, having a userspace splash that starts as early as it can >> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail >> reserving the entirety of video RAM, and thus fail loading. This cannot be >> fixed. > well the fix

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 06:26 PM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt <msta...@suse.de> wrote: >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a >> difference anyway if they're powerful enough to run Linux. As long as the &

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 06:26 PM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote: >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a >> difference anyway if they're powerful enough to run Linux. As long as the >> bootsplash is sh

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 05:16 PM, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote: >> Dear fbdev and fbcon developers, >> >> Thank you very much for your input for the first patch series. >> >> I've included your feedback into this second

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/19/2017 05:16 PM, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote: >> Dear fbdev and fbcon developers, >> >> Thank you very much for your input for the first patch series. >> >> I've included your feedback into this second

  1   2   3   >