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. The one
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 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 should b
/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 DRIVER
-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
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
---
Changes
.
The 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
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_lin
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
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.
>&g
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
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
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 drive
n 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
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 patch #4
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
---
Changes
org)
- 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_fb_xrgb_to_mono_reversed()
drm: Add driver for Solomon SSD130x OLED displays
drm/solomon: Add SS
.
The 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
: 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/display/solomon
-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:
- Add
ices registered via OF)" but it was
a considerable amount of effort.
For the whole series:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
nged, 3 insertions(+)
>
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
and not
rename it to ssd130x (even though it would be more precise since supports a
family of displays).
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/31/22 14:23, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 01:08:32PM +0100, Javier Martinez Canillas wrote:
>> On 1/31/22 12:36, Andy Shevchenko wrote:
>
> ...
>
>>>> +config TINYDRM_SSD130X
>>>> + tristate "DRM support for Solomo
for having a
separate fbdev tree. Using drm-misc only have advantages, among other
things providing redundancy in cases that a maintainer isn't available
for a period of time.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
- WREG_GFX(6, 0x05);
> + WREG_GFX(6, 0x0d);
My worry is if this could cause other issues so I would only do this change
if (is_kdump_kernel()), to make it as non intrusive as possible. And also
add a verbose comment about why this is needed.
If you make those changes, feel free to add:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/18/22 17:52, Jocelyn Falempe wrote:
> On 18/01/2022 17:38, Javier Martinez Canillas wrote:
>> Hello Jocelyn,
>>
>> On 1/14/22 10:47, Jocelyn Falempe wrote:
>
>>
>> My worry is if this could cause other issues so I would only do this change
>>
to have merit
on its own.
> Signed-off-by: Zack Rusin
> Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64")
> Cc: dri-devel@lists.freedesktop.org
> Cc:
> Reviewed-by: Martin Krastev
> ---
The patch looks good to me, thanks a lot for fixing this:
Reviewed-by: Javier
On 1/18/22 20:00, Javier Martinez Canillas wrote:
> Hello Zack,
>
> On 1/17/22 19:03, Zack Rusin wrote:
>> From: Zack Rusin
>>
>> When sysfb_simple is enabled loading vmwgfx fails because the regions
>> are held by the platform. In that case remove_conflict
plefb. Could you try please? You'd have to build DRM and simpledrm
> into the kernel binary.
>
Yes, I believe that should work.
Zack, could you please try if just the following [0] make it works ?
That is, dropping the IORESOURCE_BUSY but not doing the memory region
request / release i
On 12/22/21 09:28, Javier Martinez Canillas wrote:
> The nomodeset kernel command line parameter is used to prevent the KMS/DRM
> drivers to be registered/probed. But only a few drivers implement support
> for this and most DRM drivers just ignore it.
>
> This patch series is a
r protecting pci_request_region()
>> with
>> #if not defined(CONFIG_FB_SIMPLE)
>> #endif
>>
>> with a FIXME comment?
>
> Yes, I think that's a good compromise. I'll respin the patch with that.
>
Agreed. Thanks a lot for testing the other patches anyways.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
[adding Enric's personal email address to Cc list]
Hello Krzysztof,
On Thu, Jan 20, 2022 at 11:40 AM Krzysztof Kozlowski
wrote:
>
> Enric Balletbo i Serra emails bounce:
>
> : Recipient address rejected: User unknown in
> local recipient table
>
> so drop him from the maintainers, similarly
On 12/22/21 09:28, Javier Martinez Canillas wrote:
> The nomodeset kernel command line parameter is used to prevent the KMS/DRM
> drivers to be registered/probed. But only a few drivers implement support
> for this and most DRM drivers just ignore it.
>
> This patch series is a
_HELPER
> select DRM_LIB_RANDOM
> select DRM_KMS_HELPER
> select DRM_EXPORT_FOR_TESTS if m
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ions(+), 2 deletions(-)
>
This patch looks good to me as well.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ON_HW_SCROLLING and have it selected by the fbdev drivers that
> absolutely need HW acceleration. That option would then protect the rsp
> code.
>
Agreed that this option would be better and allow distros
to disable the code that was reverted.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
files.
> c) That way we can use "#if defined(CONFIG_FB_DRIVERS).." to exclude code in
> fbcon which
>isn't needed by DRM.
>
I proposed something similar in:
https://lore.kernel.org/lkml/20210827100027.1577561-1-javi...@redhat.com/t/
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/24/22 14:52, Javier Martinez Canillas wrote:
[snip]
>> @@ -1898,9 +1917,13 @@ EXPORT_SYMBOL(register_framebuffer);
>> void
>> unregister_framebuffer(struct fb_info *fb_info)
>> {
>> -mutex_lock(_lock);
>> +bool forced_out = fb_info->f
eviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
egister_framebuffer(fb_info);
> - mutex_unlock(_lock);
> + if (!forced_out)
> + mutex_unlock(_lock);
> }
I'm not sure to follow the logic here. The forced_out bool is set when the
platform device is unregistered in do_remove_conflicting_framebuffers(),
but shouldn't the struct platform_driver .remove callback be executed even
in this case ?
That is, the platform_device_unregister() will trigger the call to the
.remove callback that in turn will call unregister_framebuffer().
Shouldn't we always hold the mutex when calling do_unregister_framebuffer() ?
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
he mutex when calling do_unregister_framebuffer() ?
>
> Doing the hot-unplug will end up in unregister_framebuffer(), but we
> already hold the lock from the do_remove_conflicting_framebuffer() code.
>
Yes, I realized that just after sending the first email. Sorry for the noise.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/24/22 13:36, Thomas Zimmermann wrote:
> Add a TODO item about requesting memory regions for each driver. The
> current DRM drivers don't do this consistently.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez
m->start, resource_size(mem), "simplefb")) {
> + request_mem_succeeded = true;
and if you do the request_mem_region() after the struct fb_info allocation then
this could just be:
par->mem = mem;
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
for later cleanup (Javier)
>
> Signed-off-by: Thomas Zimmermann
> ---
Thanks a lot for updating the patch. Now this logic is also more
similar to the changes done for the simpledrm driver in PATCH 3/5.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
c (DRM driver in drivers/gpu/drm/tiny/st7735r.c)
fb_st7789v.c (DRM driver in drivers/gpu/drm/panel/panel-sitronix-st7789v.c)
fb_tinylcd.c
fb_tls8204.c
fb_uc1611.c
fb_uc1701.c
fb_upd161704.c
fb_watterott.c
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ught a SSD1306 (I2C) based one and will attempt to write a DRM
driver using drivers/staging/fbtft/fb_ssd1306.c as a reference.
I didn't find one with a SPI interface but we can later add a transport for
that if I succeed.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
added anymore, otherwise
the number of existing drivers that need conversion will keep growing.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
> handled by a DRM driver like you list here.
>
Sure, I'll post a patch later today. If there's something missing in
the DRM driver, anyone can get the needed bits from the git history.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/26/22 14:18, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 01:56:11PM +0100, Greg Kroah-Hartman wrote:
>> On Wed, Jan 26, 2022 at 01:37:00PM +0100, Javier Martinez Canillas wrote:
>>> On 1/26/22 11:28, Dan Carpenter wrote:
>
> ...
>
>>>fb_hx8347d.c
On 1/26/22 15:11, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
>> On 1/26/22 14:27, Andy Shevchenko wrote:
>>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
>>>> On 1/26/22 11:59, Helge
On 1/26/22 15:10, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 04:08:32PM +0200, Andy Shevchenko wrote:
>> On Wed, Jan 26, 2022 at 02:46:08PM +0100, Javier Martinez Canillas wrote:
>>> On 1/26/22 14:12, Andy Shevchenko wrote:
>
> ...
>
>>> I've j
On 1/26/22 14:27, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
>> On 1/26/22 11:59, Helge Deller wrote:
>>> On 1/26/22 11:02, Andy Shevchenko wrote:
>>
>> [snip]
>>
>>>> P.S. For the reco
KNOWN - 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
> ---
Patch looks good to me.
R
On 1/26/22 00:25, Doug Anderson wrote:
> On Tue, Jan 25, 2022 at 2:55 PM Javier Martinez Canillas
> wrote:
[snip]
>> Should this new sysfs entry be documented in Documentation/ABI/ ?
>
> I'm not sure what the policy is here. I actually don't know that I'm
> too worried ab
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 you are co
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
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
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 explain
binV13Y2gY6Jf.bin
Description: Binary data
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
registered"
Javi
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
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
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 confuse people.
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
op 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 stri
nforced 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
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-by:
.
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 [ID] in device
his 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
d 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
>>>
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
y = node;
> + break;
> + }
> + for_each_node_by_type(node, "display") {
> + if (!of_get_property(node, "linux,opened", NULL) || node ==
> boot_display)
> + continue;
> + of_platform_device_create(
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
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
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 an
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 comment
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.
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
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/drm/solomon
.
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 | 184
.
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
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 schema
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
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/Documentation
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
&
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 Martinez Cani
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
t 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 changed
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
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
registered"
Javi
601 - 700 of 2259 matches
Mail list logo
