files. also includes quite a few of Linux
> header files.
>
> IMHO the current convention (if any) is far from optimal and we should
> consider breaking it.
>
Yes, I agree with that. But probably we should be explicit about the
wrapper export symbols to access static functions pattern in the KUnit
docs so other subsystems could do the same and it becomes a convention ?
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
("drm/msm: Make .remove and .shutdown
HW shutdown consistent") which is already in the drm/drm-next branch.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Synchronize CPU access to GEM BOs with other drivers when updating the
screen buffer. Imported DMA buffers might otherwise contain stale data.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 7 +++
1 file changed, 7
On 9/26/22 09:24, Thomas Zimmermann wrote:
>
>
> Am 23.09.22 um 10:34 schrieb Javier Martinez Canillas:
>> The struct drm_plane .state shouldn't be accessed directly but instead the
>> drm_atomic_get_new_plane_state() helper function should be used.
>>
>>
On 9/27/22 13:18, Thomas Zimmermann wrote:
> Hi
>
> Am 27.09.22 um 11:52 schrieb Javier Martinez Canillas:
>> Synchronize CPU access to GEM BOs with other drivers when updating the
>> screen buffer. Imported DMA buffers might otherwise contain stale data.
>>
>>
Hello Thomas,
On 9/19/22 15:03, Thomas Zimmermann wrote:
> Remove the _drm_ infix from struct udl_drm_connector and introduce a
> macro for upcasting from struct drm_connector. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Cani
nfig. But since it depends on the
{h,v}display, I thought that needed to ask if instead should be for the CRTC.
Any in case,
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
0x02, (0x80 | (0x02 << 5)), bval,
> - 0xA1, read_buff, 2, 1000);
> + 0xA1, read_buff, 2, USB_CTRL_GET_TIMEOUT);
Agreed, much better than an arbitrary 1 sec.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
y: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 9/19/22 15:03, Thomas Zimmermann wrote:
> Remove the empty function udl_simple_display_pipe_mode_valid() and
> let simple-KMS helpers accept the modes. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
discoverable and simplifies code sharing.
>
> The conversion effectively open-codes the simple-KMS functions and
> data structure within udl. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best rega
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
m one by one.
Suggested-by: Jocelyn Falempe
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index bc41a5a
Hello Thomas,
Thanks a lot for your feedback.
On 9/30/22 10:26, Thomas Zimmermann wrote:
> Hi
>
> Am 30.09.22 um 10:01 schrieb Javier Martinez Canillas:
>> The drm_atomic_helper_damage_merged() helper merges all the damage clips
>> into one rectangle. If there are multi
mage
area to ssd130x_fb_blit_rect() as the struct drm_rect argument but instead
the dst_clip as filled by drm_rect_intersect(). Does that sound correct ?
In other words, the following:
drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
drm_atomic_for_each_plane
m one by one.
Suggested-by: Jocelyn Falempe
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Move the dst_clip assignment inside the drm_atomic_for_each_plane_damage()
loop (Thomas Zimmermann).
- Pass dst_clip instead of damage area as argument to ssd130x_fb_blit_rect()
fun
elcomed!
>
> Best Regards,
> - Maíra Canal
>
Thanks for the quick respin. I've pushed this to drm-misc (drm-misc-next).
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
the KUnit API.
>>>
>>> Tested-by: David Gow
>>> Acked-by: Daniel Latypov
>>> Reviewed-by: Javier Martinez Canillas
>>> Signed-off-by: Maíra Canal
>>
>> This patch results in:
>>
>> Building powerpc:allmodcon
On 7/5/22 12:02, Javier Martinez Canillas wrote:
> Hello,
>
> Peter Robinson reported me a kernel bug in one of his aarch64 test boards
> and even though I was not able to reproduce it, I think that figured out
> what the problem was. It seems the cause is that a DRM driver doesn&
_pci_devices() ?
>
> I simply don't want change too much at once, because there was this
> problem with the PCI helper on ast.
>
Makes sense. Feel free to add:
Reviewed-by: Javier Martinez Canillas
> At some point we can make a push to really fix this throughout the code
Hello Sam,
Thanks a lot for working on this patch-set.
On 7/16/22 20:17, Sam Ravnborg wrote:
> "legacy" is a general term - be specific and use the term dri1.
> The first step is to rename DRIVER_LEGACY to DRIVER_DRI1.
>
> Suggested-by: Javier Martinez Canillas
On 7/16/22 20:17, Sam Ravnborg wrote:
> The rename is done to make it more obvious what is DRI1 drivers
> and what is other type of legacy.
>
> Signed-off-by: Sam Ravnborg
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
I believe these should be chronological and so the order inverted.
Reviewed-by: Javier Martinez Canilla
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
Ditto here and other patches.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Ca
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
> Used the opportunity to rename the file to via.c to match the
> name of the driver.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewe
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
I wonder if we should just squash patches 03/11 to 09/11 into
On 7/16/22 20:17, Sam Ravnborg wrote:
> Move the DRI1 section from drm/Kconfig to a new Kconfig
> file that lives in the dri1/ directory.
> This isolates more of the DRI1 functionality.
>
> Signed-off-by: Sam Ravnborg
> ---
Reviewed-by: Javier Martinez Canillas
--
Bes
> ---
This patch shows how having them into a separate sub-directory pays
it forward since you won't even see any of these drm_ core files if
not interested about DRI1 drivers.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Sam,
On 6/24/22 21:37, Sam Ravnborg wrote:
> Hi Javier,
>
> On Sat, Jun 18, 2022 at 07:43:38PM +0200, Javier Martinez Canillas wrote:
>> Data writes for the ssd130x 4-wire SPI protocol need special handling, due
>> the Data/Command control (D/C) pin having to be toggl
nto a different dir
as Sam did would be preferable. What would be the upside of having it
in drivers/gpu/drm instead? Just to avoid the Makefile rule to have a
dri1/ prefix in the included object files ?
Regardless of this discussion, I think that at the very least we should
rename the Kconfig symbols to CONFIG_DRM_DRI1_* even if DRI1 drivers are
kept in drivers/gpu/drm/ instead of moved to a drivers/gpu/drm/dri1/ dir.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
of moving the core files into dri1/, the resulting Makefile
>>> rule looks really ugly. I'd suggest to move all code into a separate
>>
>> Maybe this could be sorted by splitting the DRI1 core bits in a separate
>> drm_dri1.ko module?
>
> The dri1 core files cannot be in a separate module as they are linked
> with other core stuff. It would result in dependency cycles IIRC.
>
Got it.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
sy to do but I will take a look at the result before posting
>>anything.
>>
>> When I have posted the above let's see what we all agree on.
>> May take a couple of days before I get back to it.
>
> Sounds like a plan to me.
>
Sounds good to me as well.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
; Fixes: 8d69d008f44c ("fbdev: Convert drivers to aperture helpers")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Sudip Mukherjee
> Cc: Teddy Wang
> Cc: Benjamin Herrenschmidt
> Cc: "K. Y. Srinivasan"
> Cc: Haiyang Zhang
> Cc: S
;failed to create panel bridge" | wc -l
38
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
ind
On 7/22/22 15:35, Doug Anderson wrote:
> Hi,
>
> On Fri, Jul 22, 2022 at 12:48 AM Javier Martinez Canillas
> wrote:
>>
>> If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
>> ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be
laces, let's unify in a single
helper function that could be used for the two callbacks.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/msm/msm_drv.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/
On 7/24/22 10:53, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 00:09, Javier Martinez Canillas
[...]
>> -
>> /*
>> * Shutdown the hw if we're far enough along where things might be
>> on.
>> * If we run this too early, we
On 7/24/22 11:06, Javier Martinez Canillas wrote:
[...]
>
> I guess one option is to do the if (dev->registered) check in the callers but
> then it won't really be worth it to have a helper and we could just add that
> check in msm_drv_shutdown() t
case GPU components failed
to bind")
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Take the registered check out of the msm_shutdown_hw() and make callers to
check instead.
- Make msm_shutdown_hw() an inline function.
- Add a Fixes: tag.
drivers/gpu/drm/msm/msm_drv.c | 29 +
n, by marking a
struct drm_mode_config as initialized during drmm_mode_config_init(). that
way helpers can check for it and not attempt to grab uninitialized mutexes.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_mode_config.c | 4
drivers/gpu/drm/drm_modeset_lock.
Hello Thomas,
Thanks for your feedback.
On 7/24/22 20:24, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 24.07.22 um 14:37 schrieb Javier Martinez Canillas:
>> DRM drivers initialize the mode configuration with drmm_mode_config_init()
>> and that function (among other things
Hello Dmitry,
Thanks for your feedback.
On 7/24/22 20:36, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 14:13, Javier Martinez Canillas
> wrote:
[...]
>>
>> +/*
>> + * Shutdown the hw if we're far enough along where things might be on.
>> + * If
On 7/24/22 20:47, Javier Martinez Canillas wrote:
> Hello Dmitry,
[...]
>> Now there is no point in having this as a separate function. Could you
>
> The only reason why I kept this was to avoid duplicating the same comment
> in two places. I thought that an inline function wo
On 7/24/22 22:10, Dmitry Baryshkov wrote:
> On Sun, 24 Jul 2022 at 22:51, Javier Martinez Canillas
> wrote:
>>
>> On 7/24/22 20:47, Javier Martinez Canillas wrote:
>>> Hello Dmitry,
>>
>> [...]
>>
>>>> Now there is no point in having this
splay
platform_driver")
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Drop the msm_shutdown_hw() wrapper and just call drm_atomic_helper_shutdown()
in both callbacks (Dmitry Baryshkov).
- Copy the comment in msm_drm_uninit() to msm_drv_shutdown() (Dmitry Baryshkov).
Change
r Martinez Canillas
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
include/linux/fb.h | 6 --
2 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 6a
all to the
drm_atomic_helper_shutdown() which will try to grab uninitialized mutexes and
crash the kernel.
Yes, I already posted a patch for msm/drm to prevent this but as mentioned a
lot of drivers still have that issue. We could audit all drivers and fix them
but I think we need to make
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Remove the unused mem field from struct simpledrm_device.
>
> Signed-off-by: Thomas Zimmermann
> ---
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
is
desirable? Without this additional context, this feels like going
backwards, since you are dropping few helpers that have quite self
contained code and making simpledrm_device_create() much larger.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Replace the remaining uses of the field pdev by upcasts from the Linux
> device and remove the field.
>
> Signed-off-by: Thomas Zimmermann
Much better indeed.
Acked-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Ca
uot;no simplefb configuration found\n");
>> return ERR_PTR(-ENODEV);
>> }
>> + if (!stride)
>> + stride = format->cpp[0] * width;
>
> DIV_ROUND_UP(drm_format_info_bpp(format) * width, 8)
>
I think you mea
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Replace the simple-KMS helpers with the regular atomic helpers. The
> regular helpers are better architectured and therefore allow for easier
> code sharing among drivers. No functional changes.
>
Acked-by: Javier Martinez Canillas
_t *fourccs_end = fourccs + nfourccs;
> +
> + while (fourccs < fourccs_end) {
> + if (*fourccs == fourcc)
> + return true;
> + ++fourccs;
> + }
> + return false;
> +}
This seems a helper that could be useful besides the drm_fwfb_helper.c fi
nd
> color format is pre-initialized by the system's firmware. Runtime
> modesetting via DRM is not possible. The display is useful during
> early boot stages or as error fallback.
>
I'm not familiar with OF display but the driver looks good to me.
Reviewed-by: Javier Martine
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Add a dedicated CRTC state to ofdrm to later store information for
> palette updates.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/ofdrm.c | 62 ++--
>
Reviewed-by: Jav
On 7/20/22 16:27, Thomas Zimmermann wrote:
> Add a per-model device-function structure in preparation of adding
> color-management support. Detection of the individual models has been
> taken from fbdev's offb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: J
> format field in ofdrm's custom CRTC state. The CRTC's atomic_flush
> helper updates the palette for the format as needed.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
[...]
> +static void __iomem *ofdrm_mach64_cmap_ioremap(struct of
Hello Michal,
On 7/26/22 16:40, Michal Suchánek wrote:
> Hello,
>
> On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
>> On 7/20/22 16:27, Thomas Zimmermann wrote:
>>> Add a per-model device-function structure in preparation of adding
>
Hello Thomas,
On 7/27/22 09:50, Thomas Zimmermann wrote:
> Hi
>
> Am 25.07.22 um 17:01 schrieb Javier Martinez Canillas:
>> Hello Thomas,
>>
>> On 7/20/22 16:27, Thomas Zimmermann wrote:
>>> Inline the helpers for initializing the hardware FB, the memory
>
On 7/27/22 10:24, Thomas Zimmermann wrote:
> Hi
>
> Am 25.07.22 um 18:23 schrieb Javier Martinez Canillas:
>> On 7/20/22 16:27, Thomas Zimmermann wrote:
>>> Move some of simpledrm's functionality into a helper library. Other
>>> drivers for firmware-provided
so the CRTC palette can be applied in
>> the .atomic_flush callback ?
>
> Yeah, this code is one reason for not sharing atomic_check in fwfb. The
> other reason is that the fwfb code is only a wrapper around the atomic
> helpers with little extra value. I did have such fwfb helpers a some
> point, but removed them.
>
Got it.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
et's just add a "-fb" suffix to denote that are DRM drivers FB:
$ cat /proc/fb
0 rockchipdrm-fb
$ cat /proc/fb
0 simpledrm-fb
Suggested-by: Peter Robinson
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
d a suffix anyway?
>
Yes, I thought the same and was torn about posting a patch to just remove
the suffix. I don't think users care that much if is a fb device from a
fbdev driver or a DRM driver using the fbdev emulation.
>> -Daniel
>>
Best regards,
--
Javier Martinez Can
and can
be moved out of the arch/x86 directory.
Signed-off-by: Javier Martinez Canillas
---
arch/x86/Kconfig | 27 +---
arch/x86/kernel/Makefile | 3 --
drivers/firmware/Kconfig | 31 +++
driver
are being introduced by these changes.
Since this touches both arch/{x86,arm,arm64,riscv} and drivers/firmware, I
don't know how it should be merged. But I didn't find a way to split these.
Best regards,
Javier
Javier Martinez Canillas (2):
drivers/firmware: move x86 Generic System
and other architectures using
EFI, consolidate the two in sysfb and remove it from the EFI init logic.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/efi.h| 5 +-
arch/arm64/Kconfig| 1 +
arch/arm64/include
logic in register_gop_device(), but that would
require even more code duplication. Another option would be to make the simple
drivers to match against "efi-framebuffer", but that would be an ugly solution.
But even without taking the lack of "simple-framebuffer" into accoun
then. Thanks you both
for the feedback.
>
> Best regards
> Thomas
>
>> -Daniel
>>
>
Best regards,
--
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering
vice, and
there are better ways to query that info than reading this procfs entry.
So let's just remove the suffix, which leads to much better device names:
$ cat /proc/fb
0 rockchipdrm
$ cat /proc/fb
0 simpledrm
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
--
Hello Thomas,
On 5/16/21 12:30 PM, Thomas Zimmermann wrote:
>
>
> Am 16.05.21 um 09:48 schrieb Javier Martinez Canillas:
>> There are drivers that register framebuffer devices very early in the boot
>> process and make use of the existing framebuffer as setup by the firm
as you mentioned.
This not only is a cleaner approach but also will allow to not touch all the
architectures platform code.
I'll wait for a few more days in case someone else has feedback and post a v2.
> Best regards
> Thomas
>
>
Best regards,
--
Javier Martinez Canillas
Software Engineer
New Platform Technologies Enablement team
RHEL Engineering
tures instead of selecting it.
- Improve commit message to explain the benefits of reusing sysfb for !X86.
Javier Martinez Canillas (2):
drivers/firmware: move x86 Generic System Framebuffers support
drivers/firmware: consolidate EFI framebuffer setup for all arches
arch/arm/incl
and can
be moved out of the arch/x86 directory.
This will allow to also support the simple{fb,drm} drivers on non-x86 EFI
platforms, such as aarch64 where these drivers are only supported with DT.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Use default y and depends on X86 inste
at's there to sysfb driver.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Use "depends on" for the supported architectures instead of selecting it.
- Improve commit message to explain the benefits of reusing sysfb for !X86.
arch/arm/include/asm/efi.h| 5 +-
arch/a
Hello Borislav,
On 6/3/21 10:27 PM, Borislav Petkov wrote:
> On Tue, Jun 01, 2021 at 04:59:10PM +0200, Javier Martinez Canillas wrote:
>> The series touches different subystems and will need coordination between
>> maintainers. Ard Biesheuvel said that can be merged through the EFI
On 6/4/21 2:20 PM, Andy Shevchenko wrote:
> On Fri, Jun 04, 2021 at 11:41:29AM +0200, Javier Martinez Canillas wrote:
>> On 6/3/21 10:27 PM, Borislav Petkov wrote:
>>> On Tue, Jun 01, 2021 at 04:59:10PM +0200, Javier Martinez Canillas wrote:
[snip]
>
> For myself I wro
uot;;
>> else
>> -name = "platform-framebuffer";
>> +pd->name = "platform-framebuffer";
>
> You're allocating the platform device with an empty name string. And
> here you're overwriting the pointer. Can you rearran
Use "depends on" for the supported architectures instead of selecting it.
- Improve commit message to explain the benefits of reusing sysfb for !X86.
Javier Martinez Canillas (2):
drivers/firmware: move x86 Generic System Framebuffers support
drivers/firmware: consoli
and can
be moved out of the arch/x86 directory.
This will allow to also support the simple{fb,drm} drivers on non-x86 EFI
platforms, such as aarch64 where these drivers are only supported with DT.
Signed-off-by: Javier Martinez Canillas
Acked-by: Borislav Petkov
Acked-by: Greg Kroah-Hartman
--
at's there to sysfb driver.
Signed-off-by: Javier Martinez Canillas
Acked-by: Borislav Petkov
---
Changes in v3:
- Also update the SYSFB_SIMPLEFB symbol name in drivers/gpu/drm/tiny/Kconfig.
- We have a a max 100 char limit now, use it to avoid multi-line statements.
- Figure out the platform devi
l. Besides fixing the panel not being turned
on when using SPI, it also gets rid of the custom CRTC .reset callback.
Fixes: 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the
atomic helpers")
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/so
On 1/25/23 20:56, Thomas Zimmermann wrote:
>
>
> Am 25.01.23 um 19:42 schrieb Javier Martinez Canillas:
>> Commit 622113b9f11f ("drm/ssd130x: Replace simple display helpers with the
>> atomic helpers") changed the driver to just use the atomic helpers instead
&
g locking to write the Rust abstractions.
>
> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
> Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
> Signed-off-by: Asahi Lina
> ---
Good catch. The patch looks good t
On 2/7/23 11:33, Asahi Lina wrote:
> On 07/02/2023 03.47, Javier Martinez Canillas wrote:
>> Hello Lina,
>>
>> On 2/5/23 13:51, Asahi Lina wrote:
>>> Other functions touching shmem->sgt take the pages lock, so do that here
>>> too. drm_gem_shmem_get_pages
On 2/6/23 19:47, Javier Martinez Canillas wrote:
> Hello Lina,
>
> On 2/5/23 13:51, Asahi Lina wrote:
>> Other functions touching shmem->sgt take the pages lock, so do that here
>> too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
>> _lo
On 1/26/23 18:05, Maxime Ripard wrote:
> The 120MHz value hardcoded in the call to max_t to compute the HSM rate
> is defined in the driver as HSM_MIN_CLOCK_FREQ, let's switch to it so
> that it's more readable.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-
do is to enable the power domain that a
controller is part of, before attempting to change the rate for one of its
clocks. So the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ryPi0-3.
>
> Since we're not using that driver for our HDMI clocks, we can now revert
> that inelegant solution.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ver on the RaspberryPi0-3.
>
> Since we're not using that driver for our HDMI clocks, we can now revert
> it.
>
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Thomas Zimmermann writes:
> Fix Daniel's email address. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Daniel Vetter
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Thomas Zimmermann writes:
> In fb_get_options(), always duplicate the returned option string and
> transfer ownership of the memory to the function's caller.
>
> Until now, only the global option string got duplicated and transferred
> to the caller; the per-driver options were owned by fb_get_op
name could be NULL ?
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Thomas Zimmermann writes:
> Get the kernel's global video= parameter with fb_get_option(). Done
> to unexport the internal fbdev state fb_mode_config. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Thomas Zimmermann writes:
> Get the kernel's global video= parameter with fb_get_option(). Done
> to unexport the internal fbdev state fb_mode_config. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Thomas Zimmermann writes:
> There are no external users of fb_mode_option. Unexport the variable
> and declare it static.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
901 - 1000 of 2340 matches
Mail list logo
