ONFIG_VIRTIO_UML=y \
> --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
>
> Suggested-by: Javier Martinez Canillas
> Signed-off-by: José Expósito
>
> ---
Thanks for addressing the issues pointed out. Patch looks good to me now.
Reviewed-by: Javier Martinez Canillas
By the way, I think you
tecture with something like "--arch=x86_64".
The following works correctly but it won't use User Mode Linux:
./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/.kunitconfig
--arch=x86_64
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Maxime,
On 6/6/22 15:52, Maxime Ripard wrote:
> hi,
>
> On Mon, Jun 06, 2022 at 03:49:57PM +0200, Javier Martinez Canillas wrote:
>> Hello Maxime,
>>
>> On 6/6/22 15:42, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Mon, Jun 06, 2022 a
n, it was David who explicitly suggested it shouldn't
> go in there.
> https://lists.freedesktop.org/archives/dri-devel/2022-June/357611.html
>
Ups, sorry for getting that wrong. I should had looked at the thread
again before writing my answer.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e needed if sysfb does
the disable (and unregistration) before the loop.
So by doing it before the loop, we should be able to drop [PATCH v5 4/7]
fbdev: Make sysfb to unregister its own registered devices:
https://lists.freedesktop.org/archives/dri-devel/2022-May/355201.html
Since by the
o you want to
remove the {vesa,efi,simple}fb and simpledrm drivers or is there a need
to also remove real fbdev and DRM drivers?
[0]: https://lore.kernel.org/lkml/ynvrxicnisxu6...@ravnborg.org/T/
[1]: https://www.ibm.com/docs/en/linux-on-systems?topic=through-pci
[2]: https://www.kernel.org/doc/Documentation/vfio.txt
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
This 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 v6:
- Drop sysfb_try_unregister
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
---
(no changes since v3)
Changes in v3
registration by
calling sysfb_disable(), if a driver requests to remove the conflicting
framebuffers.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v6:
- Move the sysfb_disable() before the remove conflicting framebuffers
loop
: linux-stag...@lists.linux.dev
Signed-off-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Matthew Wilcox
Cc: Sam Ravnborg
Cc: Tetsuo Handa
Cc: Zhen Lei
Cc: Alex Deucher
Cc: Xiyu Yang
Cc: linux-fb...@vger.kernel.org
and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann
Cc: Zack Rusin
Cc: Javier Martinez Canillas
Cc: Zack Rusin
Cc: Hans de Goede
Cc: Ilya Trukhanov
Signed-off-by: Daniel Vetter
Signed-off-
rs 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 registered_fb[]
pci_request_region() / request_mem_region()
and drivers that want to unbind another bound device could do something like
pci_request_region_force() / request_mem_region_force() to kick them out.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
tches through the Broadcom ARM SoC pull request,
> but the first three should probably go via the DRM tree unless you want
> me to merge them all?
I can merge the first 3 patches through the drm-misc tree. Can I get
an ack from you for those ?
The changes are independent so there's no need for an immutable branch
or any kind of cross tree coordination.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e I don't plan to push patches that are known to cause issues.
I mentioned that could help merging the DRM changes if needed before
you sent your bug report.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 6/9/22 13:49, Thomas Zimmermann wrote:
> Hi Javier
>
> Am 07.06.22 um 20:23 schrieb Javier Martinez Canillas:
>> From: Daniel Vetter
>>
>> Well except when the olpc dcon fbdev driver is enabled, that thing
>> digs around in there in rat
On 6/7/22 20:23, Javier Martinez Canillas wrote:
> The patches in this series contain mostly changes suggested by Daniel Vetter
> Thomas Zimmermann. They aim to fix existing races between the Generic System
> Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.
ed to DRM if is something that's still useful.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
one can then work on making
it not depend on the num_registered_fb symbol, allowing to drop the broken
dependency again.
Suggested-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
---
drivers/staging/olpc_dcon/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
uilt if
COMPILE_TEST is enabled") was to have more build coverage for the driver
but it wrongly assumed that all architectures would define a screen_info.
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
---
drivers/video/fbdev/Kconfig | 2 +-
1 file changed, 1 inser
https://lkml.org/lkml/2022/6/10/316
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Melissa,
On 6/10/22 13:05, Melissa Wen wrote:
> On 06/08, Javier Martinez Canillas wrote:
[snip]
>
> Hi Javier,
>
> Thanks for waiting a little.
>
> Stefan guided me to the missing part and I'm okay on this serie.
>
No worries and thanks for the testing.
On 6/10/22 11:47, Daniel Vetter wrote:
> On Fri, Jun 10, 2022 at 10:54:50AM +0200, Javier Martinez Canillas wrote:
>> This reverts commit fa0e256450f27a7d85f65c63f05e6897954a1d53. The kernel
>> test robot reported that attempting to build the vesafb driver fails on
>> some a
On 6/13/22 17:35, andriy.shevche...@linux.intel.com wrote:
> On Mon, Jun 13, 2022 at 11:39:30AM +, Dominik Kierner wrote:
>> On 5/25/2022 21:46, Javier Martinez Canillas wrote:
>
> ...
>
>>> Thanks, I looked at the code briefly and think that there are things there
ry otherwise.
>
Great that we are on the same page here.
>
>>> What is Your opinion on using drm_panel for Your driver?
>>>
>>
>> I can't remember exactly why I decided to stop using drm_panel, but I think
>> that
>> was because struct drm_panel doesn't have a DRM device and so couldn't use
>> any of
>> the helper functions that needed one?
>
> I likely hit the same roadblock.
> I would say, this approach should be revisited, when appropriate
> helpers for this approach exist, as it would further clean up and
> generify the ssd130x device configuration.
>
It's unlikely that drm_panel will get a drm_device since that was the case
but was changed by commit aa6c43644bc5 ("drm/panel: drop drm_device from
drm_panel"). But yes, I agree that we could revisit if there are helpers in
the future to manage a backlight device that is handled by a DRM driver.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
/testing/kunit/kunit.py run
--kunitconfig=drivers/gpu/drm/kunit \
--arch=x86_64
Regardless, the patch looks good to me:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
her things that could be made more consistent, like
the naming conventions for the tests, suites, etc.
[0]: https://lore.kernel.org/all/20220608010709.272962-4-maira.ca...@usp.br/T/
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
e: Inline fbdev conflict helpers into
aperture helpers").
Instead, you should use the drm_aperture_remove_framebuffers() function, i.e:
+ drm_aperture_remove_framebuffers(false, &hdlcd_driver);
If you do that and re-spin the patch, feel free to add:
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 6/14/22 20:09, José Expósito wrote:
> Hi Javier,
>
> On Tue, Jun 14, 2022 at 02:58:29PM +0200, Javier Martinez Canillas wrote:
>> Hello José,
>>
>> On 6/13/22 19:17, José Expósito wrote:
>>
>> [snip]
>>
>>> +KUnit (Kernel unit testing fram
got bug reports on Fedora about regressions caused by the fact that some
programs made the (wrong) assumption that /dev/dri/card0 would be the "main"
display and just hard-coded that path.
But removing the conflicting framebuffers after calling devm_drm_dev_alloc()
breaks this assumption, since the registered device will be /dev/dri/card1.
All this is to say that doing it too late, even if nothing is touching the HW
yet, could still have unexpected consequences across your graphics stack.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 6/15/22 09:53, Thomas Zimmermann wrote:
>
>
> Am 15.06.22 um 09:50 schrieb Javier Martinez Canillas:
> [...]
>>> Historically, most drivers call this function very early. But for error
>>> recovery it would be better to do it as late as possible. Ideally,
>
vely) a lot here, I didn't want to
> second-guess Javier's opinion so left off the R-b tag from v1.
>
Yes, v2 looks good to me so feel free to keep my R-b:
Reviewed-by: Javier Martinez Canillas
[snip]
>
> + /* If EFI left us running, take over from efifb/sysfb */
ion/gpu/todo.rst, so I think that you could add
a patch removing that as a part of this series.
[0]: https://cgit.freedesktop.org/drm/drm/tree/Documentation/gpu/todo.rst#n620
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Zack,
On 6/16/22 21:29, Zack Rusin wrote:
> On Tue, 2022-06-07 at 20:23 +0200, Javier Martinez Canillas wrote:
>> The platform devices registered by sysfb match with firmware-based DRM or
>> fbdev drivers, that are used to have early graphics using a framebuffer
>> p
On 6/16/22 23:03, Zack Rusin wrote:
> On Thu, 2022-06-16 at 21:55 +0200, Javier Martinez Canillas wrote:
>> Hello Zack,
>>
>> On 6/16/22 21:29, Zack Rusin wrote:
>>> On Tue, 2022-06-07 at 20:23 +0200, Javier Martinez Canillas wrote:
>>>> The platform devic
On 6/17/22 00:18, Javier Martinez Canillas wrote:
> On 6/16/22 23:03, Zack Rusin wrote:
[snip]
>
> I'll look at this tomorrow but in the meantime, could you please look if the
> following
> commits on top of drm-misc-next help ?
>
> d258d00fb9c7 fbdev: efifb: Clea
Hello Zack,
On 6/17/22 03:35, Zack Rusin wrote:
> On Fri, 2022-06-17 at 01:21 +0200, Javier Martinez Canillas wrote:
>> On 6/17/22 00:18, Javier Martinez Canillas wrote:
>>> On 6/16/22 23:03, Zack Rusin wrote:
>>
>> [snip]
>>
>>>
>>> I&#
IMO.
That way we won't re-introduce the issue that was fixed by the
sysfb_unregister() function, that is to remove a pdev even if wasn't
bound to a driver to prevent a late simpledrm registration to match.
Reviewed-by: Javier Martinez Canillas
I wonder what's the best way to coo
ymore and could just be dropped.
Signed-off-by: Javier Martinez Canillas
---
This patch depends on the following regmap fixes:
https://lkml.org/lkml/2022/6/16/198
drivers/gpu/drm/solomon/ssd130x-spi.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/dr
t; Due to a production error a batch or two have their board names prefixed
> by "AYANEO", this makes it 6 different DMI board names. To save some
> space in final kernel image DMI_MATCH is used instead of
> DMI_EXACT_MATCH.
>
> Signed-off-by: Maya Matuszczyk
>
Patch
mp; MMU [=n]
> Selected by [m]:
> - DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m]
> - DRM_HISI_HIBMC [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && (ARM64
> || COMPILE_TEST [=y])
>
> Fixes: 4f7f1973b0c8 ("drm/vram: fix Kc
On 6/19/22 16:05, Javier Martinez Canillas wrote:
> Hello Randy,
>
> On 5/31/22 04:55, Randy Dunlap wrote:
>> Prevent a kconfig warning when MMU is not enabled by making
>> DRM_HISI_HIBMC depend on MMU.
>>
>> WARNING: unmet direct dependencies detected for DRM_T
it
description. There's no need to resend though, I can do it when pushing.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Hans,
On 6/19/22 16:57, Hans de Goede wrote:
> Hi,
>
> On 6/19/22 13:46, Javier Martinez Canillas wrote:
>> Hello Maya,
>>
>> On 6/19/22 13:19, Maccraft123 wrote:
>>> From: Maya Matuszczyk
>>>
>>> The device is identified by "NE
;m wrong on this.
[...]
> +static void detach_platform_device(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + /*
> + * Remove the device from the device hierarchy. This is the right thing
> + * to do for firmware-based DRM drivers, such as EFI, VESA or VGA. After
> + * the new driver takes over the hardware, the firmware device's state
> + * will be lost.
> + *
> + * For non-platform devices, a new callback would be required.
> + *
I wonder if we ever are going to need this. AFAICT the problem only happens for
platform devices. Or do you envision a case when some a bus could need this and
the aperture unregister the device instead of the Linux kernel device model ?
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
the aperture helpers to remove these conflicts.
>
> Reported-by: Laszlo Ersek
> Suggested-by: Gerd Hoffmann
> Signed-off-by: Alex Williamson
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
struct device.
>
Ok, I was wondering what was the value of the indirection level other than
making the code more complex and supporting an hypothetical case of a FW
driver that would not bind against a platform device.
But if the goal is to move this at some point to a more generic place (i.e:
the Linux device model itself) then I agree that we can just keep it as is.
When you re-spin this patch, feel free to add my R-b since looks good to me.
And thanks again for working on this!
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
as for devices 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
s changed, 3 insertions(+)
>
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
eviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/11/22 13:00, Thomas Zimmermann wrote:
> The ITE66121 is an HDMI transmitter chip. There's no code for
> detecting or programming the chip within ast. Remove the enum
> constant.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
B
On 1/11/22 13:00, Thomas Zimmermann wrote:
> Remove reading the link-rate. The value is maintained by the connector
> code but never used.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/11/22 13:00, Thomas Zimmermann wrote:
> Prepare for introducing other connectors besides VGA. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ned-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
[snip]
> - encoder->possible_crtcs = 1;
[snip]
> + encoder->possible_crtcs = drm_crtc_mask(crtc);
This is a somewhat unrelated change. It's OK because is fairly simple
but I would probably still
a VGA connector.
>
> Remove the DP501 code from ast_vga_connector_helper_get_modes(). Also
> remove the call to drm_connector_update_edid_property(), which is
> performed by drm_get_edid().
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best r
> &ast_sil164_connector->i2c->adapter);
> + else
> + ret = drm_connector_init(dev, connector,
> &ast_sil164_connector_funcs,
> + DRM_MODE_CONNECTOR_DVII);
> + if (ret)
I think you want a kfree(i2c) here before returning.
And where is the struct ast_i2c_chan freed if the function succeeds ?
With that,
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
o_mono_reversed_line() helper (Thomas Zimmermann)
Javier Martinez Canillas (4):
drm/format-helper: Add drm_fb_{xrgb,gray8}_to_mono_reversed()
drm/tiny: Add driver for Solomon SSD130X OLED displays
MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver
dt-bindings: display: ssd1
-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/drm_format_helper.c | 80 +
include/drm/drm_format_helper.h | 7 +++
2 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
+++ b/MAINTAINERS
@@ -6102,6 +6102,13 @@ T: git git://anongit.freedesktop.org/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
binding for the ssd1307fb driver.
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/tiny/Kconfig | 12 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ssd130x.c | 971 +
3 files changed, 984 insertions(+)
create
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
b/Documentation/devicetree
Hello Andy,
On 2/4/22 14:57, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
>> To make sure that tools like the get_maintainer.pl script will suggest
>> to Cc me if patches are posted for this driver.
>>
>> Also incl
On 2/4/22 15:28, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 03:12:17PM +0100, Javier Martinez Canillas wrote:
>> On 2/4/22 14:57, Andy Shevchenko wrote:
>>> On Fri, Feb 04, 2022 at 02:43:46PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> Stray
Hello Geert,
On 2/4/22 15:31, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Fri, Feb 4, 2022 at 2:43 PM 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 th
Hello Andy,
Thanks for your feedback.
On 2/4/22 15:26, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
>> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
>> controllers that can be programmed via an I2C int
p = kmalloc(size of a single line of gray8)
>
> for (heigth) {
> drm_fb_xrgb_to_gray8_line(tmp, ..., src, ...);
> drm_fb_gray8_to_mono_reversed(dst, ..., tmp, ...);
>
> src += fb->pitches[0]
> dst += dst_pitch;
> }
>
> kfree(tmp);
>}
>
I see. Yes, that sounds a much better approach. I'll change it in v3.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/5/22 14:04, Andy Shevchenko wrote:
> On Fri, Feb 04, 2022 at 08:19:12PM +0100, Javier Martinez Canillas wrote:
>> On 2/4/22 15:26, Andy Shevchenko wrote:
>>> On Fri, Feb 04, 2022 at 02:43:45PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>>>
On 2/7/22 15:15, Thomas Zimmermann wrote:
> Read the encoder's possible-CRTC mask from the involved CRTC instead
> of hard-coding it.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
Thanks a lot for testing!
On 2/8/22 15:19, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Fri, Feb 4, 2022 at 2:43 PM Javier Martinez Canillas
> wrote:
>> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
>> SSD1307 and SSD1309 displ
Hello Mark,
On 2/8/22 16:18, Mark Brown wrote:
> On Tue, Feb 08, 2022 at 04:10:49PM +0100, Javier Martinez Canillas wrote:
>> On 2/8/22 15:19, Geert Uytterhoeven wrote:
>
>>> - "time ls" on the serial console (no files in the current directory,
>>> s
the fbdev API.
>
> Fbcon does small writes to the shadow frame buffer, while fbtest
> writes to the mmap()ed /dev/fbX, causing a full page to be updated.
>
I see. Thanks for the information.
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/8/22 16:40, Javier Martinez Canillas wrote:
> On 2/8/22 16:23, Geert Uytterhoeven wrote:
[snip]
>>
>> Fbcon does small writes to the shadow frame buffer, while fbtest
>> writes to the mmap()ed /dev/fbX, causing a full page to be updated.
>>
>
> I see.
> Signed-off-by: Daniel Vetter
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
time on fb_flashcursor().
The patch looks good to me and makes the logic much simpler than before.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
appens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't reve
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
---
Changes in v3:
- Add a drm_fb_xrgb_to_gray8_line
probe to make it more legible (Thomas Zimmermann)
- ssd130x_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
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
-by: Javier Martinez Canillas
---
Changes in v3:
- Also add a drm_fb_xrgb_to_mono_reversed() helper (Thomas Zimmermann)
- Split lines copy to drm_fb_gray8_to_mono_reversed_line() (Thomas Zimmermann)
- Handle case where the source buffer is not aligned to 8 (Thomas Zimmermann)
drivers/gpu/drm
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 v3:
- Add a separate driver for SSD130X chips I2C support (Andy Shevchenko)
drivers/gpu
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.
Signed-off-by: Javier Martinez Canillas
---
Changes in v3:
- Add a separate driver for SSD130X chips SPI support (Andy Shevchenko)
drivers/gpu
RIVER 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 FOR QEMU'S CIRRUS
-by: Sam Ravnborg
Signed-off-by: Javier Martinez Canillas
---
(no changes since v2)
Changes in v2:
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a
ly set the max_error_tasks parameter to enable the
> feature.
>
> Signed-off-by: Erico Nunes
> ---
Looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ngth.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ates the buffer object from the shadow buffer for all
> such areas. The graphics driver's later has the option of clipping
> the damaged area against the viewport when updating the screen
> from the buffer object.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ry_range() or
drm_fb_helper_memory_range_to_clip() instead ?
Otherwise it looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
accordingly.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
> drivers/gpu/drm/drm_fb_helper.c | 28 +---
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/driver
On 2/6/22 20:29, Thomas Zimmermann wrote:
> Clip the damage area horizontally if only a single scanline has been
> changed. This is helpful to reduce the memcpy overhead for small writes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
Best rega
Hello Geert,
On 2/9/22 13:19, Geert Uytterhoeven wrote:
> Hi Javier,
>
> 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, SSD1306,
>> SSD1307 and SSD1309 displays. It is a port of th
= (void *)&ssd130x_ssd1305_deviceinfo,
>
> The casts are not needed.
>
Right. I copied the table from the ssd1307fb driver verbatim. I'll clean it up.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/9/22 13:25, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Wed, Feb 9, 2022 at 10:12 AM 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 interfac
t;> + *
>> + * 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_offset = clip->x2 % 8;
>
> end_len, again. If you have 1 single bit set in the final byte, the
> offset is 0, but the length is 1.
>
Agreed, will change it too.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Mark,
Thanks for your feedback.
On 2/9/22 14:43, Mark Brown wrote:
> On Wed, Feb 09, 2022 at 10:03:10AM +0100, Javier Martinez Canillas wrote:
>
>> +if (ssd130x->vbat_reg) {
>> +ret = regulator_enable(ssd130x->vbat_reg);
Hello Geert,
On 2/9/22 15:27, Geert Uytterhoeven wrote:
> Hi Andy,
>
> On Wed, Feb 9, 2022 at 2:48 PM Andy Shevchenko
> wrote:
>> On Tue, Feb 08, 2022 at 04:10:49PM +0100, Javier Martinez Canillas wrote:
>>> On 2/8/22 15:19, Geert Uytterhoeven wrote:
>>>>
On 2/9/22 15:22, Mark Brown wrote:
> On Wed, Feb 09, 2022 at 03:17:06PM +0100, Javier Martinez Canillas wrote:
>> On 2/9/22 14:43, Mark Brown wrote:
>
>>> Unless the device supports power being physically omitted regulator
>>> usage should not be optional, it'
On 2/9/22 16:03, Mark Brown wrote:
> On Wed, Feb 09, 2022 at 03:50:13PM +0100, Javier Martinez Canillas wrote:
[snip]
>
>> But I understand why the Device Tree binding and fbdev driver used VBAT
>> since that's what the documentation mentions.
>
> What is "
are not aligned and set the
>>>> + * offsets for the reversed mono line conversion function to adjust.
>>>> + */
>>>> + start_offset = clip->x1 % 8;
>>>> + end_offset = clip->x2 % 8;
>>>
>>> end_len, again. If you have 1 single bit set in the final byte, the
>>> offset is 0, but the length is 1.
>>>
>>
>> Agreed, will change it too.
>
> Feel free to add my
>
> Reviewed-by: Thomas Zimmermann
>
Thanks!
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Andy,
Thanks for your feedback.
On 2/9/22 16:12, Andy Shevchenko wrote:
> On Wed, Feb 09, 2022 at 10:03:10AM +0100, Javier Martinez Canillas wrote:
>> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
>> OLED display controllers.
>>
>> It&
401 - 500 of 2504 matches
Mail list logo
