registration by
calling sysfb_disable(), if a driver requests to remove the conflicting
framebuffers.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
avoid the
and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Hans de Goede
Cc: Ilya Trukhanov
Signed-off-by: Daniel Vetter
Signed-off-
: linux-stag...@lists.linux.dev
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Matthew Wilcox
Cc: Sam Ravnborg
Cc: Tetsuo Handa
Cc: Zhen Lei
Cc: Alex Deucher
Cc: Xiyu Yang
Cc: linux-fb...@vger.kernel.org
Hello Thomas,
On 5/11/22 13:47, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 11.05.22 um 13:30 schrieb Javier Martinez Canillas:
>> Drivers that want to remove registered conflicting framebuffers prior to
>> register their own framebuffer, calls remove_conflicting_frame
Hello Thomas,
On 5/11/22 13:54, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>> These can be used by subsystems to unregister a platform device registered
>> by sysfb and also to disable future platform device registration in sys
On 5/11/22 13:24, Javier Martinez Canillas wrote:
> This function just returned 0 on success or an errno code on error, but it
> could be useful for sysfb_init() callers to have a pointer to the device.
>
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Daniel Vetter
of this function as still don't
No worries, it's my bad since I clearly failed to explain the rationale in
the commit message and comments.
> really get the purpose. It looks like a glorified wrapper around
> platform_device_unregister(). Do we need disable_lock to serialize with
> something else?
>
Yes, it has to serialize with sysfb_init() and sysfb_disable().
> Best regards
> Thomas
>
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
#x27; .remove callbacks with
a lock held.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
pe. Of course that could be abused but
> that abuse would be obvious.
>
Agreed. For the next revision, besides using an namespaced export symbol
as you suggested, I'll include a comment to make clear that it shouldn't
by any other driver and FB_OLPC_DCON fixed instead.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
some device from exposing it's display functionalities we should
> rather push that into the drm layer.
>
Absolutely agree on this. I think what we want is a drm.modeset parameter
that would have more precedence than "nomodeset". Because the latter is a
built-in parameter and so it can't be disabled at runtime using sysfs.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
DRM_DEBUG_KMS("Not using %s mode: %s\n",
Does it make sense to keep this line when verbose is set if there's a warn
now. Maybe just keep the drm_mode_debug_printmode() but remove the rest ?
I think the patch is good as is too, so regardless you do:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
mdline_mode(struct
> drm_connector *connector)
This seems like an unrelated cleanup.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
{simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.
So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 5/11/22 13:30, Javier Martinez Canillas wrote:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
>
> This function takes the registration_lock mutex, to prevent a races when
> d
On 5/5/22 14:04, Javier Martinez Canillas wrote:
> The driver has runtime but no build time dependency with X86, so it can
> be built for testing purposes if the COMPILE_TEST option is enabled.
>
> This is useful to have more build coverage and make sure that the driver
> is
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 62
> 1 file changed, 26 insertions(+), 36 deletions(-)
>
Nice cleanup. For the patch:
Reviewed-by: Javier Martinez Canillas
I just have a few minor comments b
to subtil bugs with
> uninitialized data in instances of struct iosys_map. [1]
>
> Signed-off-by: Thomas Zimmermann
> Link:
> https://lore.kernel.org/dri-devel/20210730183511.20080-1-tzimmerm...@suse.de/T/#md0172b10bb588d8f20f4f456e304f08d2a4505f7
> # 1
> ---
Reviewed-by: Javier Mart
On 5/9/22 10:16, Thomas Zimmermann wrote:
> Only handle color planes that exist in a framebuffer's color format.
> Ignore non-existing planes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
> @@ -673,7 +679,10 @@ drm_gem_vram_plane_h
On 5/9/22 10:16, Thomas Zimmermann wrote:
> Warn if callers of drm_gem_fb_get_obj() try to use a GEM buffer for
> a non-existing or unset plane.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux
-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
;s
> infrastructure.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
I think you could push this without waiting for 2/2 to be ready.
> MAINTAINERS | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MAI
don't rebuild list on recurring calls */
> +
Nice optimization to cache this.
> + /*
> + * TODO: The ofdrm driver converts framebuffers to the native
> + * format when copying them to device memory. If there are more
> + * formats listed than supported by the driver, the native format
> + * is not supported by the conversion helpers. Therefore *only*
> + * support the native format and add a conversion helper ASAP.
> + */
> + if (drm_WARN_ONCE(dev, i != odev->nformats,
> + "format conversion helpers required for %p4cc",
> + &odev->format->format)) {
> + odev->nformats = 1;
> + }
> +
Interesting. Did you find some formats that were not supported ?
The rest of the patch looks good to me, thanks a lot for writing this.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
t18003-t01C*
alias: of:N*T*Cjianda,jd-t18003-t01
alias: spi:jd-t18003-t01
To workaround this issue, add in the SPI table an entry for that device.
Fixes: d1d511d516f7 ("drm: tiny: st7735r: Add support for Okaya RH128128T")
Signed-off-by: Javier Martinez Canillas
---
ysfb_init() to be subsys_
> initcall_sync() can avoid this. But Javier Martinez Canillas has a more
> general solution.
>
You are talking about "[PATCH v5 0/7] Fix some races between sysfb device
registration and drivers probe", but unfortunately that approach was not
as gene
Hello Geert,
On 5/20/22 14:02, Geert Uytterhoeven wrote:
> Hi Javier,
>
> CC spi
>
> On Fri, May 20, 2022 at 11:16 AM Javier Martinez Canillas
> wrote:
>> The SPI core always reports a "MODALIAS=spi:", even if the device was
>> registered via OF. Thi
; dependency, which requires powered display regulators to be powered.
>
> Prepare/unprepare would power on/off the display logic regulator VDD.
>
> Enable/disable would power on/off VCC/VBAT, optionally turn on/off
> the charge pump and send the DISPLAY_ON/OFF commands.
Yes, that's the reason why I started with a drm_panel driver as well.
> The SSD1305's PWM part would likely be placed in enable/disable as well.
>
> What is Your opinion on using drm_panel for Your driver?
>
I can't remember exactly why I decided to stop using drm_panel, but I think
that was because struct drm_panel doesn't have a DRM device and so couldn't
use any of the helper functions that needed one?
At the end I found that having a standalone DRM driver and using the simple
display pipeline infrastructure was a much better way to implement it.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
) function call.
Fixes: b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than
.remove")
Reported-by: Pascal Ernster
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/vesafb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drive
is only needed when the driver built as a module to populate
the .ko alias info. It's not needed when the driver is built-in the kernel.
Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support")
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
On 5/31/22 17:10, Nathan Chancellor wrote:
> On Mon, May 30, 2022 at 04:02:46PM +0200, Javier Martinez Canillas wrote:
>> The kernel test robot reports a compile warning due the ssd130x_spi_table
>> variable being defined but not used. This happen when ssd130x-spi driver
>> i
Signed-off-by: Thomas Zimmermann
> Tested-by: Nuno Gonçalves
> Fixes: 67b723f5b742 ("drm/fb-helper: Calculate damaged area in separate
> helper")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: #
Hello Hans,
On 6/23/22 13:27, Hans de Goede wrote:
> The Lenovo Yoga Tablet 2 830F / 830L use a panel which has been mounted
> 90 degrees rotated. Add a quirk for this.
>
> Signed-off-by: Hans de Goede
> ---
The patch looks good to me.
Reviewed-by: Javier Martinez Canillas
-
Hello Daniel,
On 6/24/22 23:01, Daniel Vetter wrote:
> On Tue, Jun 14, 2022 at 02:58:29PM +0200, Javier Martinez Canillas wrote:
>> Hello José,
>>
>> On 6/13/22 19:17, José Expósito wrote:
>>
>> [snip]
>>
>>> +KUnit (Kernel unit testing framework)
t registered resource is what the firmware provides for drivers to use
the system framebuffer for scan-out. It's not the real thing, that's true
since a native driver would kick it out (leading to a resource release)
and register the real aperture.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello José,
On 6/27/22 14:36, José Expósito wrote:
> Hi Javier, Daniel,
>
> On Fri, Jun 24, 2022 at 11:18:40PM +0200, Javier Martinez Canillas wrote:
>> Hello Daniel,
>>
>> On 6/24/22 23:01, Daniel Vetter wrote:
>>>
>>> [...]
>>>
>&g
return 0;
> }
>
> static void ssd130x_i2c_shutdown(struct i2c_client *client)
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
idea, even patchwork made a mess of it, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220628140313.74984-7-u.kleine-koe...@pengutronix.de/
>
FYI, for patches like these what I usually use is:
./scripts/get_maintainer.pl --nogit-fallback --no-m --no-r
--
Best regards
PLEFB=y
> # CONFIG_DRM_SIMPLEDRM is not set
> # CONFIG_FB_SIMPLE is not set
>
Yes, and this could happen even if both drivers (e.g: simplefb and amdgpu)
are enabled but built-in. For example, if amdgpu probes before simplefb.
> After applying the 3 patches you mentioned, the issue is resolved. (at
> least on my setup).
>
Thanks for testing Jocelyn! I've pushed the patches to drm-misc-fixes now.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ity, the legacy can be dropped.
Maybe an alternative could be to add a drivers/gpu/drm/legacy directory and
move all the legacy DRM drivers there ? And the Kconfig symbol could be i.e:
CONFIG_DRM_LEGACY_VIA and same for the others legacy DRM drivers.
And the directory could only be sourced
with it.
>
I believe that there's value in having all the legacy drivers in a single
directory rather than having them scattered all across the subsystem. But
don't have a strong opinion either. I just wanted to share my thoughts.
> Best regards
> Thomas
>
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
patch-set too.
Best regards,
Javier
Javier Martinez Canillas (2):
drm: Use size_t type for len variable in drm_copy_field()
drm: Prevent drm_copy_field() to attempt copying a NULL pointer
drivers/gpu/drm/drm_ioctl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.36.1
03185] el0t_64_sync_handler+0x11c/0x150
[ +0.004418] el0t_64_sync+0x190/0x194
[ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)
[ +0.006180] ---[ end trace ]---
Reported-by: Peter Robinson
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_ioctl.c | 4 ++
t controlled by userspace. But using a size_t for len is the
correct thing to do anyways.
Reported-by: Peter Robinson
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/
mebuffer" device yet. radeon
> registered later, and /dev/fb0 created. sysfb_init() comes at last, it
> registers "efi-framebuffer" and then causes an error message "efifb: a
> framebuffer is already registered". Make sysfb_init() to be subsys_
> initcall_sync() c
e
> +
I haven't looked at the KUnits tests in detail since Daniel and David already
reviewed them. But from a quick glance, the tests look good to me as well.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
anged considerably when ported to the KUnit framework API. Same for
the other tests.
> + */
> +
> +#include
Please add a blank line here. And this also applies to all other tests.
> +#include
> +#include
> +
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
loped-by: Matheus Vieira
> Signed-off-by: Matheus Vieira
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 6/30/22 02:46, Maíra Canal wrote:
> Considering the current adoption of the KUnit framework, convert the
> DRM format selftest to the KUnit API.
>
> Acked-by: Daniel Latypov
> Tested-by: David Gow
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canill
son C. G. Filho
> Co-developed-by: Anderson Fraga
> Signed-off-by: Anderson Fraga
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
es Neto
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 6/30/22 02:46, Maíra Canal wrote:
> Considering the current adoption of the KUnit framework, convert the
> DRM framebuffer selftest to the KUnit API.
>
> Acked-by: Daniel Latypov
> Tested-by: David Gow
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martine
On 6/30/22 02:46, Maíra Canal wrote:
> Considering the current adoption of the KUnit framework, convert the
> DRM buddy selftest to the KUnit API.
>
> Acked-by: Daniel Latypov
> Tested-by: David Gow
> Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canill
Signed-off-by: Maíra Canal
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
dy been tested/reviewed.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
our attention and any feedback is welcomed!
>
Thanks a lot for the quick re-spin of the series! I'll wait a few days in case
someone else has additional feedback and then push to drm-misc (drm-misc-next).
> Best Regards,
> - Maíra Canal
>
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/4/22 14:36, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> Thanks for your feedback.
>
[snip]
>>> + /* don't attempt to copy a NULL pointer */
>>> + if (WARN_ONCE(!value, "BUG: the value to copy was not set!"))
>>> +
Hello Thomas,
Thanks for your feedback.
On 7/4/22 14:30, Thomas Zimmermann wrote:
> Hi
>
> Am 01.07.22 um 14:07 schrieb Javier Martinez Canillas:
>> The drm_copy_field() helper is used to copy some struct drm_driver fields
>> to userspace through the DRM_IOCTL_VERSION i
On 7/4/22 14:11, Xi Ruoyao wrote:
> On Mon, 2022-07-04 at 13:04 +0200, Javier Martinez Canillas wrote:
>> Hello Xi,
>>>
>>> With CONFIG_SYSFB_SIMPLEFB and CONFIG_FB_SIMPLE enabled, there is no
>>> issue.
>>>
>>> I guess it's something
thing going wrong on a "drm -> drm" pass over. For now
> I'll continue to use simpledrm with this commit reverted.
>
Yes, we need to also cherry-pick b84efa28a48 ("drm/aperture: Run fbdev
removal before internal helpers") now that the sysfb_disable() patches
are in v5.19-rc5.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
t controlled by userspace. But using a size_t for len is the
correct thing to do anyways.
Signed-off-by: Javier Martinez Canillas
Tested-by: Peter Robinson
Reviewed-by: Thomas Zimmermann
---
Changes in v2:
- Add Peter Robinson Tested-by and Thomas Zimmermann Reviewed-by tags.
drivers/gpu/drm/drm_io
] el0t_64_sync_handler+0x11c/0x150
[ +0.004418] el0t_64_sync+0x190/0x194
[ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)
[ +0.006180] ---[ end trace ]---
Reported-by: Peter Robinson
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Just warn if a value
patch-set too.
Best regards,
Javier
Changes in v2:
- Add Peter Robinson Tested-by and Thomas Zimmermann Reviewed-by tags.
- Just warn if a value isn't set and report it as a string of length 0.
(Thomas Zimmermann).
Javier Martinez Canillas (2):
drm: Use size_t type for len variable in drm_
gt; - SSD130X_SET_PRECHARGE_PERIOD1_SET(ssd130x->prechargep2));
> + SSD130X_SET_PRECHARGE_PERIOD2_SET(ssd130x->prechargep2));
It's a typo indeed. Nice catch!
I wonder how did you notice this. Or was it just looking at the code ?
Acked-by: Javier Martinez Canillas
I'll push
Hello Maíra,
On 7/2/22 15:17, Javier Martinez Canillas wrote:
> On 7/2/22 15:11, Maíra Canal wrote:
>> Hi everyone,
>>
>> Here is the v4 of the conversion of selftests to KUnit. Since the v3, there
>> have been minor fixes, asked by Javier. Basically, fixes on the S
Hello Thomas,
On 7/7/22 17:39, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
quite likely we will get rid of this driver and the
platform device registration soon. Since as you said, it's unclear that is
even used.
> static struct platform_driver vga16fb_driver = {
> .probe = vga16fb_probe,
> .remove = vga16fb_remove,
> .driver = {
> - .name = "vga16fb",
> + .name = "vga-framebuffer",
> },
Maybe "vga16-framebuffer" instead? Since for example VESA is also VGA AFAIK.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
6fb_setup(option);
> +#endif
> +
I would just drop these ifdefery and have the option unconditionally.
It seems that's what most fbdev drivers do AFAICT.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 7/11/22 09:58, Thomas Zimmermann wrote:
> Hi Javier,
>
> I'll try to give the motivation of this patch below. I known it's rather
> hypothetical as the VGA driver is probably not used much.
>
> Am 08.07.22 um 15:09 schrieb Javier Martinez Canillas:
On 7/11/22 10:01, Thomas Zimmermann wrote:
> Hi
>
> Am 08.07.22 um 15:16 schrieb Javier Martinez Canillas:
>> On 7/7/22 17:39, Thomas Zimmermann wrote:
>>> Move vgag16fb's option parsing into the driver's probe function and
>>> generate the rest of t
Agreed. The driver name is used as the last resort to match a device
only if there isn't any device ID table (ACPI, OF, platform, etc) but
that's discouraged. Specially when the same driver supports different
devices as it's the case for this driver.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
o functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
size_t size = pci_resource_len(pdev, 0);
>
> - ap = alloc_apertures(1);
> - if (!ap)
> - return -ENOMEM;
> -
> - ap->ranges[0].base = pci_resource_start(pdev, 0);
> - ap->ranges[0].size = pci_resource_len(pdev, 0);
> -
> - remove_confli
DNAME for the name and
a probe callback wrapper or something ?
But probably not worth to invest more in the fbdev drivers and could be done
as a follow-up anyways if someone feels like it.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
al
> helpers")
> Cc: Zack Rusin
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Helge Deller
> Cc: Alex Deucher
> Cc: Zhen Lei
> Cc: Changcheng Deng
> Cc: Maarten Lankhors
with the rename and think that makes it much more readable,
but think that's worth to mention the rationale for that change too.
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
rk even with fbdev disabled.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
fb_info
> *fb_info)
> put_fb_info(fb_info);
> }
>
> +static int fbm_aperture_acquire_for_platform_device(struct fb_info *fb_info)
> +{
What's the meaning of 'm' here ? Misc, memory ? I would just call it 'fb_'.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
> ---
Amazing patch! The whole series really. Thanks a lot for working on this.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ommand line parameters. It seems that isn't
documented anywhere.
But since no one complained when these were moved from drm_kms_helper.ko
and the current drm_dp_helper.ko is so recent, I would say that's fine.
If you re-spin feel free to add,
Reviewed-by: Javier Martinez Canillas
>
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
the proliferation of Kconfig options, DSC is part of DRM's
> support for DisplayPort. If necessary, a new option could make DSC an
> independent feature.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Zimmermann
> ---
After fixing Jani's comment about the drm_hdcp_helper_helper.h typo:
Reviewed-by: Javier Martinez Canillas
[snip]
> diff --git a/drivers/gpu/drm/drm_hdcp.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> similarity index 99%
> rename from drivers/gpu/drm/d
Hello Chen-Yu,
On Wed, Mar 30, 2022 at 9:09 PM Chen-Yu Tsai wrote:
>
> From: Chen-Yu Tsai
>
> Add a vendor prefix entry for SINO WEALTH Eletronics Ltd.
> (http://www.sinowealth.com).
>
> Signed-off-by: Chen-Yu Tsai
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
ing
ones are cargo culting from the previous fbdev driver to make existing
DTBs compatible with the DRM driver.
I've been thinking if I should post a patch to compatible strings
without the "fb" and mark the current ones as deprecated...
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
_LOW |
> + SSD130X_PAGE_COL_START_SET(col_start & 0xf);
> + col_high = SSD130X_PAGE_COL_START_HIGH |
> + SSD130X_PAGE_COL_START_SET((col_start >> 4) & 0xf);
Maybe instead we should define
SSD130X_PAGE_COL_START_{HIGH,LOW}_{MASK,SET} to be consistent with how
the other fields
also applies to this patch, I
believe the convention in DRM is for the subject line to be
"drm/ssd130x:" instead of "drm: ssd130x:"
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
ake existing
>> DTBs compatible with the DRM driver.
>>
>> I've been thinking if I should post a patch to compatible strings
>> without the "fb" and mark the current ones as deprecated...
>>
>> Reviewed-by: Javier Martinez Canillas
>
> I als
mono_reversed'
>
> Fixes: bcf8b616deb8 ("drm/format-helper: Add
> drm_fb_xrgb_to_mono_reversed()")
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> CC: Maxime
On 4/4/22 18:35, Chen-Yu Tsai wrote:
> On Fri, Apr 1, 2022 at 6:10 PM Javier Martinez Canillas
> wrote:
[snip]
>>
>> I wonder if we should also list SH1106 in the
>> drivers/gpu/drm/solomon/Kconfig file so people can find it ?
>
> I can add it to the help te
d that refactoring as a part of the
SPI series. Thanks a lot for the suggestion, it was very useful.
> I think a friend of mine has a SPI based SH1106 module that I
> could borrow and test/work on, but that's a big if.
>
>
Cool. If it uses 4-wire too then I believe that wou
t; --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
>
> This wasn't enough for the second patch, I had to re-do the changes by hand
> from scratch.
>
Yes, I believe the suggestion should be to use git-format-patch instead.
To make sure that was is posted can be consumed by the git-am command.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Daniel,
On 4/5/22 10:40, Daniel Vetter wrote:
> On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
>> On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
>>> On 2/8/22 22:08, Daniel Vetter wrote:
>&g
On 4/5/22 11:24, Daniel Vetter wrote:
> On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
[snip]
>>
>> This is how I think that work, please let me know if you see something
>> wrong in my logic:
>>
>> 1) A PCI device of OF device is registered for the G
On 4/5/22 12:34, Daniel Vetter wrote:
> On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
> wrote:
[snip]
>>
>> I believe the correct fix would be for the fbdev core to keep a list of
>> the apertures struct that are passed to remove_conflicting_framebuffers(),
>&
y unregistering the framebuffer
> as before without a hot unplug.
>
I believe the assumption that all firmware fb would have an underlying
device was a reasonable one and it's a pity that offb doesn't...
But that is how things are and your patch is the least intrusive fix.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
uilt as a module).
I'm sending as an RFC since there are many changes to the locking scheme
and that is always tricky to get right. Please let me know what you think.
Best regards,
Javier
Daniel Vetter (1):
Revert "fbdev: Prevent probing generic drivers if a FB is already
registe
(), if a driver requested to remove conflicting
framebuffers with remove_conflicting_framebuffers().
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a
bingzmJoZoxxU.bin
Description: Binary data
restart.
Since the framebuffer devices will already be removed, the loop would just
finish when no more conflicting framebuffers are found.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 21 ++---
include/linux/fb.h
This function just returned 0 on success or an errno code on error, but it
could be useful to sysfb_init() to get a pointer to the device registered.
Signed-off-by: Javier Martinez Canillas
---
drivers/firmware/sysfb.c | 4 ++--
drivers/firmware/sysfb_simplefb.c | 24
701 - 800 of 2340 matches
Mail list logo
