On 2/9/22 16:16, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 10:12:04AM +0100, Javier Martinez Canillas wrote:
>> The ssd130x driver only provides the core support for these devices but it
>> does not have any bus transport logic. Add a driver to interface over SPI.
>
>
On 2/9/22 16:15, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 10:03:11AM +0100, Javier Martinez Canillas wrote:
>> The ssd130x driver only provides the core support for these devices but it
>> does not have any bus transport logic. Add a driver to interface over I
On 2/9/22 16:17, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 01:25:46PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Feb 9, 2022 at 10:12 AM Javier Martinez Canillas
>> wrote:
>
> ...
>
>>> + .compatible = "solomon,ssd1305fb-spi",
&g
On 2/9/22 16:19, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 02:04:17PM +0100, Javier Martinez Canillas wrote:
>> On 2/9/22 13:25, Geert Uytterhoeven wrote:
>>> On Wed, Feb 9, 2022 at 10:12 AM Javier Martinez Canillas
>>> wrote:
>
>> Yes, I know. Didn&#x
changelog for each revision in
>> the patches with the name of the reviewer so people can check
>> and compare.
>>
>> If something that you mentioned is not there, I apologize and
>> please point me out so I can address it in v4.
>
> It's just a feeling,
of_device_id and
spi_device_id (just for modalias reporting and alias table in module) for
SPI and a of_device_id table for I2C and platform devices.
And also having different compatible strings with a "-i2c" and "-spi" as
suffixes to allow kmod / udev to differentiate and matc
On 2/9/22 17:41, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 05:25:03PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Feb 9, 2022 at 5:07 PM Javier Martinez Canillas
>> wrote:
>
> ...
>
>> Are they all broken?
>
> I guess it's incorrect question. Th
Hello Geert,
On 2/10/22 18:06, Geert Uytterhoeven wrote:
> On Wed, Feb 9, 2022 at 1:19 PM Geert Uytterhoeven
> wrote:
>> On Wed, Feb 9, 2022 at 10:03 AM Javier Martinez Canillas
>> wrote:
>>> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD13
On 2/9/22 13:37, Javier Martinez Canillas wrote:
[snip]
>
>> There is still an issue with the cursor, though.
>> After doing "echo hello > /dev/tty0", the text appears, but the cursor
>> is gone. "clear > /dev/tty0" brings it back.
>>
&
On 2/9/22 17:26, Javier Martinez Canillas wrote:
> On 2/9/22 17:08, Andy Shevchenko wrote:
>
> [snip]
>
>>> Agreed, as mentioned I'll give it a try to sending all the data as a
>>> bulk write with regmap.
>>
>> Ah, it might be that it sho
sd130x_write_cmd() uses varargs to simplify I2C code (Thomas Zimmermann)
- Move regulator/pwm init logic to display pipe enable callback.
- Add Sam Ravnborg's acked-by to patch adding a MAINTAINERS entry (Sam Ravnborg)
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Jav
Pull the per-line conversion logic into a separate helper function.
This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v3)
Changes in v3:
- Add a
drm_fb_gray8_to_mono_reversed_line() helper was based on code from
drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v4:
- Rename end_offset to end_len (Thomas Zimmermann)
- Warn once if dst_pitch is not a multiple of 8 (Thomas
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.
Signed-off-by: Javier Martinez Canillas
---
Changes in v4:
- Remove unnecessary casting (Geert Uytterhoeven)
- Remove redundant blank lines (Andy
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.
It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.
Signed-off-by: Javier Martinez Canillas
---
Chang
/tiny/repaper.c
+DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
+M: Javier Martinez Canillas
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+F: drivers/gpu/drm/solomon/ssd130x*
+
DRM DRIVE
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
---
Changes in v4:
- Add Rob Herring Acked-by tag to patch adding as DT binding co-maintainer.
Changes in v2:
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Documentation/devicetree
Hello Andy,
On 2/11/22 11:28, Andy Shevchenko wrote:
> On Fri, Feb 11, 2022 at 10:19:22AM +0100, Javier Martinez Canillas wrote:
>> Pull the per-line conversion logic into a separate helper function.
>>
>> This will allow to do line-by-line conversion in other helpers that
* For damage handling, it is possible that only parts of the source
>> + * buffer is copied and this could lead to start and end pixels that
>> + * are not aligned to multiple of 8.
>> + *
>> + * Calculate if the start and end pixels are not aligned and set the
>> + * offsets for the reversed mono line conversion function to adjust.
>> + */
>> +start_offset = clip->x1 % 8;
>> +end_len = clip->x2 % 8;
>
> ALIGN() ?
>
But we don't want to align here but to know what's the start and end if is
not aligned since that would mean converting to mono in the middle of a byte.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/11/22 12:33, Andy Shevchenko wrote:
> On Fri, Feb 11, 2022 at 10:19:24AM +0100, Javier Martinez Canillas wrote:
>> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
>> OLED display controllers.
>>
>> It's only the core part of the dri
should be written in a way that ease
readability and make as robust and less error prone as possible.
>
> BR,
> Jani.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
27;s return value is a struct ssd130x_device pointer,
>> not a struct backlight_device pointer.
>
> Hence
>
> return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl),
> "Unable to register backlight device\n"));
>
> ?
>
Thanks, that would work.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
y pipe enable callback.
- Add Sam Ravnborg's acked-by to patch adding a MAINTAINERS entry (Sam Ravnborg)
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Javier Martinez Canillas (6):
drm/format-helper: Add drm_fb_xrgb_to_gray8_line()
drm/format-helper: Add drm
drm_fb_gray8_to_mono_reversed_line() helper was based on code from
drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v5:
- Use drm_WARN_ON* macros instead of deprecated ones (Thomas Zimmermann)
Changes in v4:
- Rename end_offset
Pull the per-line conversion logic into a separate helper function.
This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
---
Changes in v5:
- Add
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
---
Changes in v5:
- Add Andy Shevchenko's Reviewed-by tag to pat
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.
It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.
Signed-off-by: Javier Martinez Canillas
---
Chang
rm-misc
F: Documentation/devicetree/bindings/display/repaper.txt
F: drivers/gpu/drm/tiny/repaper.c
+DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
+M: Javier Martinez Canillas
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/displ
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
Reviewed-by: Andy Shevchenko
---
Changes in v5:
- Add Andy Shevchenko's Reviewed-by tag to patch #6.
Changes in v4:
- Add Rob Herring Acked-by tag to patch adding as DT binding co-maintainer.
Changes in v2:
S_ERR(bl))
>> + return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl),
>> + "Unable to register backlight
>> device\n"));
>
> Can be consistent with this then.
>
Yes. I meant to change it everywhere but seems that one slipped it through.
It's not worth to send a v6 just for the changes you mentioned but I can do
them before pushing the patches to drm-misc (once I get ack for this patch).
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/11/22 20:19, Javier Martinez Canillas wrote:
[snip]
>> I would put GENMASK() directly into FIELD(), but it's up to you
>> (and I haven't checked the use of *_MASK anyway).
>>
>
> Same. I also considered just using GENMASK() directly, but since I was
&g
t; The cast can be removed if src32 is changed to "void *".
> For symmetry, gray8 and mono can be changed to "void *", too.
>
Yes, but these being "u32 *" and "u8 *" also express that the source buffer
contains 32-bit XRGB pixels, the intermediate buffer a 8-bit grayscale
pixel format and the destination buffer a 8-bit packed reversed monochrome.
Using "void *" for these would make that less clear when reading the code IMO.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Move regulator/pwm init logic to display pipe enable callback.
- Add Sam Ravnborg's acked-by to patch adding a MAINTAINERS entry (Sam Ravnborg)
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Javier Martinez Canillas (6):
drm/format-helper: Add drm_fb_xrgb_to_gray8
Pull the per-line conversion logic into a separate helper function.
This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Andy
The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
---
(no changes since v5)
Changes in v5:
- Add Andy Shevchenko's Rev
drm_fb_gray8_to_mono_reversed_line() helper was based on code from
drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Andy Shevchenko
---
Changes in v6:
- Add Andy Shevchenko's Reviewed-by to patch #2.
Changes in v5:
This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.
It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.
Signed-off-by: Javier Martinez Canillas
---
Chang
rg/drm/drm-misc
F: Documentation/devicetree/bindings/display/repaper.txt
F: drivers/gpu/drm/tiny/repaper.c
+DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
+M: Javier Martinez Canillas
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
Acked-by: Rob Herring
Reviewed-by: Andy Shevchenko
---
(no changes since v5)
Changes in v5:
- Add Andy Shevchenko's Reviewed-by tag to patch #6.
Changes in v4:
- Add Rob Herring Acked-by tag to patch adding as DT binding co-maint
/* vrr range */
> debugfs_create_file("vrr_range", S_IRUGO, root, connector,
> &vrr_range_fops);
Same here, wonder if the return value should be checked.
I leave it to you to decide, but regardless of that the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
l have one of:
> * UNKNOWN - We tried to detect a panel but it wasn't in our table.
> * HARDCODED - We're not using generic "edp-panel" probed by EDID.
> * A panel name - This is the name of the panel from our table.
>
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
debugfs, but
> hey, it's debugfs so you shouldn't fail anything else because of that
> anyway.
>
Thanks a lot Doug and Jani for the explanations. That makes sense and it
explains why most code I looked was not checking for the return value.
I guess we should write something about this in the debugfs functions
kernel doc so it's mentioned explicitly and people don't have to guess.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/14/22 14:37, Javier Martinez Canillas wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.
>
> Using the DRM fbdev emulation, all the tests from Geert Uytterhoeven r
be the proper way and didn't get an answer.
We have many drivers doing the same and I couldn't find one that was doing
it correctly to use as a reference:
$ git grep "TODO: Use mapping abstraction properly" | wc -l
15
If you point me the proper way, I'll be happy to post a patch to change
On 2/17/22 10:25, Lucas De Marchi wrote:
> On Thu, Feb 17, 2022 at 10:00:42AM +0100, Javier Martinez Canillas wrote:
[snip]
>>> this is now called iosys_map in drm-intel... drm-tip will need a fixup
>>> for the merge.
>>>
>>
>> I thought that the drm
d for I/O memory the
> blit/conversion helpers allocate an internal temporary per-line buffer.
> The code you made for the new driver has this designed outlined already.
>
Indeed. I understand now what you meant when proposing to add those helpers.
> Best regards
> Thomas
>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
e.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
return ret;
> + /*
> + * post_crtc_powerdown will have called pm_runtime_put, so we
> + * don't need it here otherwise we'll get the reference counting
> + * wrong.
> + */
>
I'm not familiar with the BCM2711 SoC nor its HDMI controller but your
- 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: Deprecate "-i2c" compatible
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
---
(no changes since v4)
Changes in v4:
- Add a
.
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
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
Reviewed-by: Geert Uytterhoeven
---
Changes in v5:
- Remove cast by just using u8 *reg instead of void *data (Geert Uytterhoeven).
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
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 v3:
- Fix typos and grammar errors that found when re
vice, the workaround hould no longer
> be triggered. Update it with a warning and rewrite the comment. Fbdev
> drivers that trigger the hot-unplug workaround really need to be fixed.
>
> Signed-off-by: Thomas Zimmermann
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-b
- 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
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
---
(no changes since v2)
Changes in v2:
- Rebase on top of latest drm-misc
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
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
---
(no changes since v2)
Changes in v2:
- Add
ls to do the unregister.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
(no changes since v2)
Changes in v2:
- Explain in the commit message that fbmem has to unregister the device
as fallback if a driver registered the device itself (D
DRM display helpers for HDMI.
> +
Maybe you mentioned already when we discussed it in v1, but could
you please remember me why we need to select both symbols for the
drivers, even when DRM_DISPLAY_HELPER is already selected here ?
Or are select operations not transitive ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Kconfig options, SCDC is part of DRM's
> support for HDMI. If necessary, a new option could make SCDC an
> independent feature.
>
> Signed-off-by: Thomas Zimmermann
> ---
Looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 4/20/22 14:21, Thomas Zimmermann wrote:
> Hi
>
> Am 20.04.22 um 14:02 schrieb Javier Martinez Canillas:
>> Hello Thomas,
>>
>> On 4/20/22 13:08, Thomas Zimmermann wrote:
>>
>> [snip]
>>
>>> --- a/drivers/gpu/drm/bridge/synopsys/Kco
DISPLAY_HELPER.
>>
>
> Oh, well. You found a bug. It should be 'depends on' instead of 'select'.
>
Ah, I see. Yeah, that makes more sense.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
le to see if those build? But as said, by looking at
the code it seems that should build correctly.
I agree with Uwe though that is less confusing to have a semicolon after
the MODULE_DEVICE_TABLE(), but I'm not the driver maintainer to decide.
> I don't know for sure, but I'd have said that the M= stuff is for
> out-of-tree modules only.
>
It does work, I use M= to build drivers in mainline that are configured
to build as a module all the time.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Rob,
On 4/20/22 18:15, Rob Herring wrote:
> On Tue, 19 Apr 2022 23:48:19 +0200, Javier Martinez Canillas wrote:
>> The current compatible strings for SSD130x I2C controllers contain both an
>> "fb" and "-i2c" suffixes. It seems to indicate that are for
On 4/19/22 23:48, Javier Martinez Canillas wrote:
> Hello,
>
> This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
> support for SSD130x OLED controllers that can be accessed over a SPI bus.
>
> The driver is quite similar to existing ssd130x-i2c driv
On 4/20/22 17:47, Javier Martinez Canillas wrote:
[snip]
>>
>>> When I built this, it appeared to succeed. I used the command "make
>>> M=/drivers/staging/fbtft modules". Is this incorrect? For reference this
>>> is my first patch so it's highl
Shouldn't depend on DRM_FBDEV_EMULATION then?
> I looked some more at the logs and it seems weston doesn't work on his
> system without the fbdev backend. So the question is why weston isn't
> working without fbdev? Perhaps this is just a Weston configuration
> issue?
>
But is weston using the fbdev emulated by DRM or the one registered by
efifb? I thought that the latter from what was mentioned in this thread.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e statements (Jani, Javier)
> * update Kconfig symbols
>
> Signed-off-by: Thomas Zimmermann
> ---
Thanks for re-spinning this. The patch looks good to me now.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 4/21/22 14:54, Patrik Jakobsson wrote:
> On Thu, Apr 21, 2022 at 2:47 PM Javier Martinez Canillas
> wrote:
[snip]
>>>>> diff --git a/drivers/gpu/drm/gma500/Kconfig
>>>>> b/drivers/gpu/drm/gma500/Kconfig
>>>>> index 0cff20265f97..a422fa84d53
Hello Thomas,
On 4/21/22 20:17, Thomas Zimmermann wrote:
> Not all possible format conversions are supported yet. Print a
> warning on unsupported combinations.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez
clip->y1;
and drm_rect_height(clip) ?
> + void *dbuf;
> +
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
_format_helper.c | 46 +
> 1 file changed, 46 insertions(+)
Same comments than for patch 2/3.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
Thanks for the feedback.
On 4/25/22 10:27, Thomas Zimmermann wrote:
> Hi
>
> Am 20.04.22 um 10:53 schrieb Javier Martinez Canillas:
>> Drivers that want to remove registered conflicting framebuffers prior to
>> register their own framebuffer, calls remove_con
Hello Thomas,
Thanks for the feedback. It was very useful.
On 4/25/22 11:15, Thomas Zimmermann wrote:
> Hi
>
> Am 25.04.22 um 10:54 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 20.04.22 um 10:52 schrieb Javier Martinez Canillas:
>>> Hello,
>>>
>
ero.
>
> This patch is a preparation for making i2c remove callbacks return void.
>
> Signed-off-by: Uwe Kleine-König
> ---
Acked-by: Javier Martinez Canillas
and I'll push to drm-misc (drm-misc-next) now.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Daniel,
On 4/27/22 17:29, Daniel Vetter wrote:
> On Wed, Apr 20, 2022 at 09:24:11AM +0200, Javier Martinez Canillas wrote:
>> Learning about the DRM subsystem could be quite overwhelming for newcomers
>> but there are lots of useful talks, slides and articles available that
tag just to make sure that this
fix will be picked for stable once the mentioned change also lands there.
Fixes: 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module")
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/display/Kconfig | 4
1 file changed, 4 inse
On 4/27/22 22:25, Javier Martinez Canillas wrote:
> The DRM_DP_AUX_CHARDEV and DRM_DP_CEC boolean Kconfig symbols enable code
> that use DP helper functions, exported by the display-helper module.
>
[snip]
> @@ -32,6 +32,8 @@ config DRM_DISPLAY_HDMI_HELPER
> config DRM
quot;). Adding a Fixes: tag just to make sure that this
fix will be picked for stable once the mentioned change also lands there.
Fixes: 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module")
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Explain better the iss
st correct thing to do is
for
the drivers that make use of the symbols exported by DRM_DP_{AUX_CHARDEV,CEC} to
select these. What do you think ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
be used for anything
> that is user-configurable. [1]
>
Right. So giving even more thought to this, now I think that we should just
include
drm_dp_aux_dev.o, drm_dp_cec.o (and probably drm_dp_aux_bus.o?) unconditionally
to
drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER).
After all, these are not big objects and drm_display_helper can now be built as
module.
I don't see that much value to have separate user-configurable config options...
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
add the depends on then to fix the linking errors and then either
adding the stubs when disabled or just making it part of the DP_HELPER can be
done as a follow-up.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
6420b13 ("drm/display: Introduce a DRM display-helper module")
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Also make DRM_DP_AUX_CHARDEV and DRM_DP_CEC depend on DRM_DISPLAY_HELPER
(Thomas Zimmermann).
Changes in v2:
- Explain better the issue in the change description.
- O
ill preserve the
current behaviour as much as possible.
I don't have a strong opinion though and if you prefer I can change to
be a depends instead.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
was to have Suggested-by before your S-o-B.
The patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
ermediate shadow buffer.
>
> The value of page->index is required by page_mkclean(), which we
> call to reset the mappings during the writeback phase of the deferred
> I/O. The value of pageref->offset is for conveniently getting an offset
> into video memory in fb helpers.
>
&g
On 4/29/22 09:27, Thomas Zimmermann wrote:
> Hi
>
> Am 29.04.22 um 09:21 schrieb Javier Martinez Canillas:
>> Hello Thomas,
>>
>> On 4/26/22 14:03, Thomas Zimmermann wrote:
>>> Rename various instances of pagelist to pagereflist. The list now
>>> store
other way (in general at least) than by making
> sure the fw stuff is gone before driver load starts in earnest.
Yes, you are correct. I didn't realize all the possible cases when agreed
with Thomas about doing this but tried and found that it's not enough.
I've a full patch-se
The DRIVER_FIRMWARE flag denotes that a DRM driver uses a framebuffer
that was initialized and provided by the system firmware for scanout.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
include/drm/drm_drv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include
The DRIVER_FIRMWARE flag denotes that a DRM driver uses a framebuffer
that was initialized and provided by the system firmware for scanout,
which is the case for simpledrm.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file
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
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
---
(no changes since v2)
Changes in v2:
- Add
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
Reviewed-by: Thomas Zimmermann
---
Changes in v4:
- Make sysfb_disable() to
the associated device if asked to remove conflicting
framebuffers.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/drm_fb_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers
by
calling sysfb_disable(), if either a framebuffer device or a DRM device is
registered. Since in that case a display will already be present.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
(no changes since v3)
Changes in v3:
- Call sysfb_disable() when a fbdev
t 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 (2):
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make reg
by
calling sysfb_disable(), if either a framebuffer device or a DRM device is
registered. Since in that case a display will already be present.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
(no changes since v3)
Changes in v3:
- Call sysfb_disable() when a DRM device
501 - 600 of 2337 matches
Mail list logo
