Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
Javier Martinez Canillas (4):
firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
firmware: sysfb: Add helpers to unregister a pdev and disable
registration
fbdev: Restart confli
These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/firmware/sysfb.c | 47
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
(), 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
binttweoHDOUR.bin
Description: Binary data
ost of the patches in v1 already? But it seems you
didn't pick them up.
You addressed the comments I had in v1 so those stand, for all patches:
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
On 4/6/22 21:08, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 30.03.22 um 11:23 schrieb Javier Martinez Canillas:
>> On 3/22/22 20:27, Thomas Zimmermann wrote:
>>> Replace the DP-helper module with a display-helper module. Update
>>> all related Kconfig and Ma
Hello Daniel,
On 4/7/22 11:03, Daniel Vetter wrote:
> On Wed, Apr 06, 2022 at 11:39:15PM +0200, Javier Martinez Canillas wrote:
>> 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 registere
On 4/7/22 11:06, Daniel Vetter wrote:
> On Wed, Apr 06, 2022 at 11:39:16PM +0200, Javier Martinez Canillas wrote:
[snip]
>> +}
>> +EXPORT_SYMBOL_GPL(sysfb_try_unregister);
>
> Kerneldoc for these plus adding that to
> Documentation/firmware/other_interfaces.rst would b
On 4/7/22 11:11, Daniel Vetter wrote:
> On Wed, Apr 06, 2022 at 11:39:18PM +0200, Javier Martinez Canillas wrote:
[snip]
>
> Yeah it's disappointing, but no worse than the piles of hacks we have now.
>
> With the bikesheds addressed above:
>
Agree with all your comme
for the vc4 DRM driver. I've this patch locally
which seems to work but I don't know enough about the fence API to know if
is correct.
If you think is the proper fix then I can post it as a patch.
>From 3e96db4827ef69b38927476659cbb4469a0246e6 Mon Sep 17 00:00:00 2001
From: Javier Mar
On 4/7/22 15:13, Christian König wrote:
> Am 07.04.22 um 15:08 schrieb Javier Martinez Canillas:
>> Hello Christian,
>>
>> On 4/7/22 10:59, Christian König wrote:
>>> Instead of distingting between shared and exclusive fences specify
>>> the fence usage
do it properly in two callers of the vc4 driver,
leading to build errors.
Fixes: 73511edf8b19 ("dma-buf: specify usage while adding fences to dma_resv
obj v7")
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Christian König
---
drivers/gpu/drm/vc4/vc4_gem.c | 6 --
1 file ch
On 4/7/22 15:19, Javier Martinez Canillas wrote:
> The commit 73511edf8b19 ("dma-buf: specify usage while adding fences to
> dma_resv obj v7") ported all the DRM drivers to use the newer fence API
> that specifies the usage with the enum dma_resv_usage rather than doing
&
On 4/6/22 19:29, Chen-Yu Tsai wrote:
Pushed this series to drm-misc (drm-misc-next), thanks again for your patches!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ch #5 adds the ssd130x-spi DRM driver for the OLED controllers
that come with a 4-wire SPI interface, instead of an I2C interface.
Best regards,
Javier
Javier Martinez Canillas (5):
dt-bindings: display: ssd1307fb: Deprecate fbdev compatible strings
dt-bindings: display: ssd1307fb: Extend schem
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the compatible strings, properties and examples for SPI.
Signed-off-by: Javier Martinez Canillas
---
.../bindings/display/solomon,ssd1307fb.yaml | 89 +++
1 file changed, 71
tains
compatible strings that don't have a -fb suffix. These will be matched by
the ssd130x-i2c DRM driver.
Signed-off-by: Javier Martinez Canillas
---
.../bindings/display/solomon,ssd1307fb.yaml | 36 ---
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/Doc
t have
the -fb suffix. The old entries are still kept for backward compatibility.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/d
.
For this reason the standard SPI regmap can't be used and a custom .write
bus handler is needed.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/Kconfig | 9 ++
drivers/gpu/drm/solomon/Makefile | 1 +
drivers/gpu/drm/solomon/ssd130x-spi.c
.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
bytes. Since even though are used by the I2C interface, it could also be
useful for other transport protocols such as SPI.
Suggested-by: Chen-Yu Tsai
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon
x_variant_to_info ?
>
Indeed. I'll change that in v2.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
- Add a FIXME comment about drivers registering devices (Daniel Vetter).
- Drop RFC prefix since patches were already reviewed by Daniel Vetter.
- Add Daniel Reviewed-by tags to the patches.
Daniel Vetter (1):
Revert "fbdev: Prevent probing generic drivers if a FB is already
registe
These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v2:
- Add kernel-doc comments and
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
---
Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts
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
Reviewed-by: Daniel Vetter
---
(no changes since v1)
drivers/video/fbdev/core/fbmem.c
ls to do the unregister.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
as fallback if a driver registered the device itself (Daniel Vetter).
- Also ex
binV13Y2gY6Jf.bin
Description: Binary data
Hello Rob,
On 4/8/22 20:22, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 10:02:00PM +0200, Javier Martinez Canillas wrote:
>> The current compatible strings for SSD130x I2C controllers contain an -fb
>> suffix, this seems to indicate that are for a fbdev driver. But the DT is
On 4/8/22 21:19, Javier Martinez Canillas wrote:
[snip]
>>
>> There's also no reason to put the bus interface into the compatible as
>> the same compatible will work on different buses. But since you want to
>> add SPI, just using the 'i2c' one will
ps, this is already commit 97a40c23cda5d64a ("dt-bindings:
> display: ssd1307fb: Add entry for SINO WEALTH SH1106") in
> drm-misc/for-linux-next...
>
Yeah, too late :/ I didn't think it would be controversial at the time.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
On 4/11/22 15:47, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Thu, Apr 7, 2022 at 10:03 PM Javier Martinez Canillas
> wrote:
>> The current compatible strings for SSD130x I2C controllers contain an -fb
>> suffix, this seems to indicate that are for a fbd
n).
- Don't add compatible strings with an "-spi" suffix (Geert Uytterhoeven).
- Drop ssd13x_variant_to_info() and just use the array index (Neil Armstrong).
- Add Mark Brown's Acked-by tag to all patches.
Javier Martinez Canillas (5):
dt-bindings: display: ssd1307fb: Deprecate &quo
Linux implementation
details. So let's deprecate those compatible strings and add new ones that
only contain the vendor and device name, without any of these suffixes.
These will just describe the device and can be matched by both I2C and SPI
DRM drivers.
Signed-off-by: Javier Martinez Canil
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked
.
For this reason the standard SPI regmap can't be used and a custom .write
bus handler is needed.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
---
(no changes since v1)
drivers/gpu/drm/solomon/Kconfig | 9 ++
drivers/gpu/drm/solomon/Makefile | 1 +
drivers/gp
.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
bytes. Since even though are used by the I2C interface, it could also be
useful for other transport protocols such as SPI.
Suggested-by: Chen-Yu Tsai
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
---
Changes in v2:
- Don't add compatible strings with an "-spi"
Hello Geert,
On 4/12/22 09:16, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
>> add to the schema the properties and examples fo
On 4/12/22 09:19, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> The current compatible strings for SSD130x I2C controllers contain an "fb"
>> and "-i2c" suffixes. These have been de
On 4/12/22 09:23, Geert Uytterhoeven wrote:
> Hi Javier,
>
> Thanks for your patch!
>
> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> wrote:
>> These are declared in the ssd130x-i2c transport driver but the information
>> is not I2C specific, and
lified (no need for the PTR_ERR(ERR_PTR(...) dance)
> by open-coding ssd130x_spi_get_dc() here.
>
Right, that will be better indeed.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
for SPI, if possible at all.
>
I see. Let's go with a comment then and we can later enforce it, if someone
knows if is possible / how to do it.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Andy,
Thanks for your feedback.
On 4/12/22 13:21, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
>> On 4/12/22 09:23, Geert Uytterhoeven wrote:
>>> On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez C
On 4/12/22 13:22, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote:
>> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
>>> On 4/12/22 09:23, Geert Uytterhoeven wrote:
>>>> On Mon, Apr 11, 2022 at 11:
Hello Maxime,
On 4/12/22 13:28, Maxime Ripard wrote:
> On Mon, Apr 11, 2022 at 11:12:39PM +0200, Javier Martinez Canillas wrote:
[snip]
>>
>>reg:
>> maxItems: 1
>> @@ -136,7 +147,7 @@ allOf:
>>properties:
>> compatible:
>&g
Hello Chen-Yu,
On 4/12/22 14:07, Chen-Yu Tsai wrote:
> On Tue, Apr 12, 2022 at 5:12 AM Javier Martinez Canillas
> wrote:
[snip]
>
> I think you can just drop this one, since it was just merged and isn't
> part of any release yet. It's not even in -rc.
>
I believe
quot;fb-i2c" (Geert Uytterhoeven).
- Drop ssd13x_variant_to_info() and just use the array index (Neil Armstrong).
- Add the same compatible strings than I2C (Geert Uytterhoeven)
- Add Mark Brown's Acked-by tag to all patches.
Javier Martinez Canillas (5):
dt-bindings: display: ssd1307fb:
be enforced for old ones.
While being there, just drop the "sinowealth,sh1106-i2c" compatible string
since that was never present in a released Linux version.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Drop the &
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v3:
- Add a comment to the
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked
.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
bytes. Since even though they are used by the I2C interface, they could
also be useful for other transport protocols such as SPI.
Suggested-by: Chen-Yu Tsai
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
.
For this reason the standard SPI regmap can't be used and a custom .write
bus handler is needed.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
---
Changes in v3:
- Drop ssd130x_spi_get_dc() helper and open code it (Geert Uytterhoeven)
- Export variants array and use &in
e called without the console_lock being held.
The changes themselves look good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 4/13/22 11:21, Daniel Vetter wrote:
> On Wed, Apr 13, 2022 at 11:16:08AM +0200, Javier Martinez Canillas wrote:
>> Hello Daniel,
>>
>> On 4/13/22 10:21, Daniel Vetter wrote:
>>> I messed up the delayed takover path in the locking conversion in
>>> 6e7d
Hello Geert,
On 4/13/22 10:04, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Tue, Apr 12, 2022 at 6:27 PM Javier Martinez Canillas
> wrote:
>> The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
>> add to the schema the properties and examples fo
oot_display = node;
> + break;
> + }
> + for_each_node_by_type(node, "display") {
> + if (!of_get_property(node, "linux,opened", NULL) || node ==
> boot_display)
> + continue;
> + of_platform_devi
do this ?
Or at least a warning if the do_unregister_framebuffer() call is removed.
Regardless of what you chose to do, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Andy,
On 4/13/22 12:46, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 06:27:28PM +0200, Javier Martinez Canillas wrote:
>> These are declared in the ssd130x-i2c transport driver but the information
>> is not I2C specific, and could be used by other SSD130x transport driv
be enforced for old ones.
While being there, just drop the "sinowealth,sh1106-i2c" compatible string
since that was never present in a released Linux version.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
(no changes since v3)
Changes i
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
Changes in v4:
- Add a description for the dc
.
For this reason the standard SPI regmap can't be used and a custom .write
bus handler is needed.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
---
Changes in v4:
- Use MODULE_IMPORT_NS(DRM_SSD130X) in the ssd130x-spi driver (Andy Shevchenko)
Changes in v3:
- Drop ssd130x_spi_g
.
While being there, also move the SSD130X_DATA and SSD130X_COMMAND control
bytes. Since even though they are used by the I2C interface, they could
also be useful for other transport protocols such as SPI.
Suggested-by: Chen-Yu Tsai
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
compatible strings that don't have "fb-i2c" (Geert Uytterhoeven).
- Drop ssd13x_variant_to_info() and just use the array index (Neil Armstrong).
- Add the same compatible strings than I2C (Geert Uytterhoeven)
- Add Mark Brown's Acked-by tag to all patches.
Javier Martinez Canillas (5):
On 4/13/22 19:02, Andy Shevchenko wrote:
> On Wed, Apr 13, 2022 at 06:23:57PM +0200, Javier Martinez Canillas wrote:
>> These are declared in the ssd130x-i2c transport driver but the information
>> is not I2C specific, and could be used by other SSD130x transport drivers.
>>
f-else" depending on PPC. I'll drop
> of_platform_populate_framebuffers() from the patch and make a separate
> implementation of of_platform_default_populate_init for PPC. Seems like
> the easiest solution to me.
>
That sounds reasonable to me as well. Feel free to retain my R-B tag
when posting v2.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
driver should look like.
Add sections to the introduction page, that contains references to these.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Acked-by: Pekka Paalanen
Acked-by: Thomas Zimmermann
---
Changes in v2:
- Remove paragraph that gave wrong impression that DRM
I know that we follow
https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst
but still my opinion is that having a warning for a couple of releases
if registered_fb[i]->device is NULL, instead of just crashing would be
a better way to handle this.
> With offb converted, we could practically remove all of the checks here
> and call platform_device_unregister() unconditionally.
>
Yes for mainline, but as mentioned I thought mostly about out-of-tree. If
folks agree that we shouldn't care about these, I'm Ok with that as well.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ice_uevent_modalias support")
and 96c8395e2166 ("spi: Revert modalias changes") have some more context.
[0]: https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi.c#L360
[1]:
https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-core-base.c#L139
> The rest LGTM, so
> Reviewed-by: Geert Uytterhoeven
>
Thanks!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
line layer may
not be worth it.
For these reasons, let's follow that trend and make ssd130x a plain DRM
driver that creates its own primary plane, CRTC, enconder and connector.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/
new_plane_state->visible isn't set, but returns zero regardless.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/simpledrm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm
eshed but I disagree with this. The
> majority of the kunit tests already out there start with the framework
> name, including *all* the examples in the kunit doc. Plus, it's fairly
> obvious that it's a test, kunit is only about running tests in the first
> place.
>
Agree with Maxime on this.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Hello Thomas,
Thanks for your feedback and comments.
On 9/5/22 12:41, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 28.08.22 um 17:11 schrieb Javier Martinez Canillas:
>> The simple display pipeline is a set of helpers that can be used by DRM
>> drivers to avoid dealin
Hello Thomas,
On 9/5/22 12:57, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 31.08.22 um 13:12 schrieb Javier Martinez Canillas:
>> The simpledrm_primary_plane_helper_atomic_check() function is more complex
>> than needed. It first checks drm_atomic_helper_check_plane_state(
On 9/5/22 13:00, Javier Martinez Canillas wrote:
>>> +static void ssd130x_encoder_helper_atomic_enable(struct drm_encoder
>>> *encoder,
>>> +struct drm_atomic_state *state)
>>> +{
>>> + struct d
; Sure. I can add a preparatory change in v2 that adds that helper and then
>> use it in the follow-up patch.
>>
>
> Maybe wait for your ssd130x changes to land and then you can convert
> both drivers to the new helper.
>
Makes sense. I'll do that.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
n the CRTC reset function. It's
> purpose is to set hardware and software to a clean state.
>
I need to check if it survives a disable/enable cycle. Specially since
on disable the VCC regulator is disabled, which might lead to the chip
state to get lost.
> Best regards
> Thomas
>
>>
>>> Best regards
>>> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
line layer may
not be worth it.
For these reasons, let's follow that trend and make ssd130x a plain DRM
driver that creates its own primary plane, CRTC, enconder and connector.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
---
Changes
On Tue, 6 Sep 2022 at 00:28 Javier Martinez Canillas
wrote:
> The simple display pipeline is a set of helpers that can be used by DRM
> drivers to avoid dealing with all the needed components and just define
> a few functions to operate a simple display device with one full-screen
elper and
make drivers use it.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_plane_helper.c | 29 +
drivers/gpu/drm/solomon/ssd130x.c | 18 +-
drivers/gpu/drm/tiny/simpledrm.c
new state (i.e., the one in plane->state) IIRC. (As I mentioned,
> there was a related bug in one of the drivers.) So we began to call this
> 'old_state'.
>
> My point is: the state passed to the check and commit functions are
> different things, even though they appear to be the same.
>
Agree.
Maybe instead of new and old `current_state` and `commit_state` would
be more clear ?
>>
>> I've proposed renaming drm_atomic_state to eg. drm_atomic_transaction
>> a few times before but no one took the bait so far...
>>
>
> If you really don't like new_state, then let's call it state_tx.
>
I would prefer if for this patch we call it either `new_state` or just
`state` to be consistent with the other helpers. And then we can as a
follow-up change the naming used by all the helpers.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
elper and
make drivers use it.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Fix `new_state` field comment (Ville Syrjälä).
- Rename `new_state` to just `state` (Ville Syrjälä).
drivers/gpu/drm/drm_plane_helper.c
On 9/13/22 15:49, Harry Wentland wrote:
>
>
> On 2022-09-13 05:33, Javier Martinez Canillas wrote:
>> Provides a default plane state check handler for primary planes that are a
>> fullscreen scanout buffer and whose state scale and position can't change.
>>
&g
elper and
make drivers use it.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v3:
- Use plane-state and atomic-state (Thomas Zimmermann).
- Drop primary and just refer to plane (Thomas Zimmermann).
- Make kernel-doc comment
DRM_PLANE_TYPE_OVERLAY, NULL);
Not only drm_plane_init() doesn't add much value but makes the code
harder to read. Since by calling drm_universal_plane_init() instead,
it's explicit whether the initialized plane is primary or an overlay.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
drmm_*_alloc() managed interfaces should use the
drmm_k{z,m}alloc() helpers, so that the memory is automatically freed
on the last drm_dev_put() call ?
Other than those two nits, the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 9/9/22 12:59, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez C
ned-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
ent's question on that topic.
>
Ah, never mind. I misread the function name definition and thought that
you had a drmm_ suffix but, now on second read I see that is only drm_
so just ignore my comment about using managed memory alloc / release.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 9/13/22 18:23, Javier Martinez Canillas wrote:
> Provides a default plane state check handler for primary planes that are a
> fullscreen scanout buffer and whose state scale and position can't change.
>
> There are some drivers that duplicate this logic in their helpers, su
"drm/simpledrm: Compute framebuffer stride if not set")
> Cc: Javier Martinez Canillas
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/tiny/simpledrm.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
--
Bes
off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
t; 1 file changed, 3 deletions(-)
>
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
eviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
and would never come from an imported dma-buf, so
could the GEM BOs even be shared with other drivers?
Or is this done just for the sake of correctness ?
> Signed-off-by: Thomas Zimmermann
> ---
The change looks good to me though if is for the latter.
Reviewed-by: Javier Martinez Canillas
-
avier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index 7fae9480aa11..a537692100d1 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/dr
Hello Ville,
On 9/23/22 11:05, Ville Syrjälä wrote:
> On Fri, Sep 23, 2022 at 10:34:47AM +0200, Javier Martinez Canillas wrote:
>> The struct drm_plane .state shouldn't be accessed directly but instead the
>> drm_atomic_get_new_plane_state() helper function should be used.
&g
rn drm_connector_pick_cmdline_mode(connector)
> }
> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
> #endif
>
> The wrapper's declaration can be located in the kunit test file.
>
But that's also not nice since we are artificially exposing these only
to allow the static functions to be called from unit tests. And would
be a different approach than the one used by all other subsystems...
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 9/23/22 12:43, Thomas Zimmermann wrote:
> Hi
>
> Am 23.09.22 um 10:06 schrieb Javier Martinez Canillas:
>> On 9/22/22 15:09, Thomas Zimmermann wrote:
>>> Synchronize CPU access to GEM BOs with other drivers when updating the
>>> screen buffer. Imported buff
801 - 900 of 2337 matches
Mail list logo
