Hello Ville,
On 10/22/21 21:12, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 04:40:40PM +0200, Javier Martinez Canillas wrote:
>> The simpledrm driver allows to use the frame buffer that was set-up by the
>> firmware. This gives early video output before the platform DRM driver i
We
> hot-unplug the generic platform device, so that the driver for the
> native device can operate the HW without interference.)
>
> Simpledrm only acquires an aperture, but never removes a driver. If
> there is a driver already, simpledrm would fail. Only native drivers try > to
> remove d
.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
(no changes since v1)
drivers/gpu/drm/drm_aperture.c | 39 ++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
avier
Changes in v2:
- Rename command line parameter to drm.disable_native_drivers.
- Return -EBUSY instead of -EINVAL when the function fails.
- Invert the parameter logic and make it false by default.
Javier Martinez Canillas (2):
drm/aperture: Move conflicting fbdev frame buffer removal to a h
this could be implemented.
Suggested-by: Neal Gompa
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Rename command line parameter to drm.disable_native_drivers.
- Return -EBUSY instead of -EINVAL when the function fails.
- Invert the parameter logic and make it false by default.
d
Hello Michel,
On 10/25/21 12:45, Michel Dänzer wrote:
> On 2021-10-24 22:32, Javier Martinez Canillas wrote:
>> Hello Ville,
>>
>> On 10/22/21 21:12, Ville Syrjälä wrote:
>>> On Fri, Oct 22, 2021 at 04:40:40PM +0200, Javier Martinez Canillas wrote:
>>>&
spend'
...
To prevent this, make following changes to the config option dependencies:
* Depend on FB && !(DRM_KMS_HELPER=y && FB=m), to avoid invalid configs.
* Depend on DRM_KMS_HELPER instead selecting it, to avoid circular deps.
Reported-by: Justin M. Forbes
Sign
ON && FB) || !DRM_FBDEV_EMULATION
help
CRTC helpers for KMS drivers.
@@ -104,7 +105,6 @@ config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
depends on FB
- select DRM_KMS_HELPER
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
elected while its
> dependencies
> are not met.
>
> To work around that, every single driver that has 'selects DRM_KMS_HELPER'
> would
> now have to also list 'depends on (DRM_FBDEV_EMULATION && FB) ||
> !DRM_FBDEV_EMULATION'.
>
Ah, I see now. Thanks a lot for the explanation.
>Arnd
>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
m] || !DRM_FBDEV_EMULATION [=y])
Selected by [y]:
- DRM_SIMPLEDRM [=y] && HAS_IOMEM [=y] && DRM [=y]
Selected by [m]:
- DRM_I915 [=m] && HAS_IOMEM [=y] && DRM [=y] && X86 [=y] && PCI [=y]
- DRM_VIRTIO_GPU [=m] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO_MENU [=y] &&
MMU [=y]
so CONFIG_DRM_KMS_HELPER will wrongly set to =y which will cause the issue.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
FB_COPYAREA
> select FB_CFB_IMAGEBLIT
>
> That would probably make it work for DRM=y, FB=m, DRM_KMS_HELPER=m,
> but it needs more randconfig testing, which I can help with.
Looks good to me as well.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
://patchwork.kernel.org/project/linux-fbdev/list/?series=538227
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
7;t be considered an ABI but now we found that people are using it.
So I agree that would be better to revert this patch. Johannes, will you
post a revert or do you want me to do it ?
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
just last week I had to fix issues in the vga16fb driver
that started to occur after a change to support simpledrm in aarch64:
https://lore.kernel.org/all/2022031601.u36j6grsvnir5gvp@houat/T/
If there is a separate tree for fbdev, then this would require to do
some coordination, share and merge immutable branches, etc for no
clear benefit.
Best regards,--
Javier Martinez Canillas
Linux Engineering
Red Hat
e the benefit of doing that split, same 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
x40);
> - 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
>>
) seems 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-b
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_conflicting*
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
uld work if you use simpledrm instead of
> simplefb. 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 b
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
uld you consider 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
.
> 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
G_FBCON_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
o_unregister_framebuffer(fb_info);
> - mutex_unlock(®istration_lock);
> + if (!forced_out)
> + mutex_unlock(®istration_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
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(®istration_lock);
>> +bool forced_out =
eviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
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
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 Mar
>
>> Shouldn't we always hold the 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
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
It will 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
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
>
not be added anymore, otherwise
the number of existing drivers that need conversion will keep growing.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
ssd1331.c
fb_ssd1351.c
fb_st7735r.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
eady
> 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
st bought 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
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 record, I
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 just
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
curve.
Add a section to the intro that contains these DRM introductory materials.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
Documentation/gpu/introduction.rst | 36 ++
1 file changed, 36 insertions(+)
diff --git a/Documentatio
Hello Pekka,
Thanks a lot for your feedback.
On 1/27/22 10:05, Pekka Paalanen wrote:
> On Thu, 27 Jan 2022 09:20:58 +0100
> Javier Martinez Canillas wrote:
>
>> The Linux DRM subsystem supports complex graphics devices and it could be
>> quite overwhelming for newcome
such section as a follow-up. Maybe referring to some
of the drivers in drivers/gpu/drm/tiny.
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/27/22 12:31, Daniel Vetter wrote:
> On Thu, Jan 27, 2022 at 11:50:30AM +0100, Javier Martinez Canillas wrote:
[snip]
>> Indeed. And we can add such section as a follow-up. Maybe referring to some
>> of the drivers in drivers/gpu/drm/tiny.
>
> Do we have a talk an
ith DRM helpers
> drm/qxl: Move ioctl array next to its only user
> drm/qxl: Replace module-init boiler-plate code with DRM helpers
> drm/vboxvideo: Replace module-init boiler-plate code with DRM helpers
> drm/vmwgfx: Replace module-init boiler-plate code with DRM helpers
>
Push
On 12/17/21 01:37, 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
tors).
But that is also true if the user wants to disable the real DRM driver with
modprobe.blacklist=rcar-du-drm.
What this patch does is just to make all DRM drivers consistent and honour the
nomodeset param (whose name is really misleading but we can't change that).
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 1/26/22 15:15, Javier Martinez Canillas wrote:
> 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/2
s slow anyways
and the multiple copies are not a bottleneck AFAICT.
I believe is worth to propose this driver as is and then try to optimize later.
Another thing that's missing is a DRM_MODE_CONNECTOR_I2C, because I used for
now a DRM_MODE_CONNECTOR_Unknown.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
the original ssd1307 name then 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 Solomon SSD1
Add support to convert 8-bit grayscale to reversed monochrome for drivers
that control monochromatic displays, that only have 1 bit per pixel depth.
This helper function was based on repaper_gray8_to_mono_reversed() from
the drivers/gpu/drm/tiny/repaper.c driver.
Signed-off-by: Javier Martinez
uld be more accurate) to avoid confusion for users who want to
migrate from the existing ssd1307fb fbdev driver.
Patch #4 just adds a MAINTAINERS entry for this new DRM driver.
Best regards,
Javier
Javier Martinez Canillas (4):
drm: Add I2C connector type
drm/format-helper: Add drm_fb_gr
pe"), user-space should be able to cope with a connector type that does
not yet understand.
Tested with `modetest -M ssd1307 -c` and shows the connector as unknown-1.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 f
/bindings/display/repaper.txt
F: drivers/gpu/drm/tiny/repaper.c
+DRM DRIVER FOR SOLOMON SSD1307 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
binding for the ssd1307fb driver.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/Kconfig | 12 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ssd1307.c | 976 +
3 files changed, 989 insertions(+)
create mode 100644 drivers/gpu
we can wire up al the needed bits to have a DRM/KMS driver that
could expose a R1 format.
> Let me know if you want me to type up any of the user-space bits.
>
Thanks! I also could help to add the needed support in the user-space stack.
Best reagards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Sam,
Thanks a lot for your feedback.
On 1/31/22 21:46, Sam Ravnborg wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 09:15:37PM +0100, Javier Martinez Canillas wrote:
>> To make sure that tools like the get_maintainer.pl script will suggest
>> to Cc me if patches are p
On 1/31/22 21:52, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 09:12:21PM +0100, Javier Martinez Canillas wrote:
>> There isn't a connector type for display controllers accesed through I2C,
>> most drivers use DRM_MODE_CONNECTOR_Unknown or DRM_MODE_CONNECTOR_VIRTUAL.
>&g
On 1/31/22 21:56, Sam Ravnborg wrote:
> Hi Javier,
> On Mon, Jan 31, 2022 at 09:12:20PM +0100, 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 drive
Hello Sam,
Thanks for your suggestions.
On 1/31/22 22:30, Sam Ravnborg wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 09:29:16PM +0100, Javier Martinez Canillas wrote:
>> Add a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon OLED
>> controllers that can be
gt; Dx path.
But we still need RxGxBxAx as a fallback for compatibility with the
existing user-space, so all this could be done as a follow-up as an
optimization and shouldn't block monochromatic panel drivers IMO.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Geert,
On 2/1/22 09:43, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Mon, Jan 31, 2022 at 9:12 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,
On 2/1/22 10:32, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 09:15:37PM +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/1/22 10:37, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 09:56:23PM +0100, Sam Ravnborg wrote:
>> On Mon, Jan 31, 2022 at 09:12:20PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> Patch #3 adds the driver. The name ssd1307 was used instead of ssd13
On 2/1/22 10:41, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 10:30:46PM +0100, Sam Ravnborg wrote:
>> On Mon, Jan 31, 2022 at 09:29:16PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> +config TINYDRM_SSD1307
>>> + tristate "DRM support
On 2/1/22 10:44, Andy Shevchenko wrote:
> On Tue, Feb 01, 2022 at 01:14:22AM +0100, Javier Martinez Canillas wrote:
>> On 1/31/22 22:30, Sam Ravnborg wrote:
>>> On Mon, Jan 31, 2022 at 09:29:16PM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> The d
Hello Thomas,
Thanks a lot for your feedback.
On 2/1/22 10:59, Thomas Zimmermann wrote:
> Hi
>
> Am 31.01.22 um 21:12 schrieb Javier Martinez Canillas:
>> Add support to convert 8-bit grayscale to reversed monochrome for drivers
>> that control monochromatic displays, tha
e_init(drm, &ssd1307->pipe,
>> &ssd1307_pipe_funcs,
>> + ssd1307_formats,
>> ARRAY_SIZE(ssd1307_formats),
>> + NULL, &ssd1307->connector);
>> +if (ret)
>> +goto pwm_disable;
>> +
>> +drm_plane_enable_fb_damage_clips(&ssd1307->pipe.plane);
>> +
>> +drm_mode_config_reset(drm);
>
> Moving anything related to mode-config into a function would improve
> readability.
>
Ok.
[snip]
>> +regulator_disable:
>> +if (ssd1307->vbat_reg)
>> +regulator_disable(ssd1307->vbat_reg);
>> +return ret;
>
> Can this be handled by managed clean-up helpers?
>
I believe so, I'll use the devm_* when possible.
>> +}
>> +
>> +static int ssd1307_remove(struct i2c_client *client)
>> +{
>> +struct ssd1307_device *ssd1307 = i2c_get_clientdata(client);
>> +
>> +drm_dev_unplug(&ssd1307->drm);
>> +
>> +ssd1307_write_cmd(ssd1307->client, SSD1307_DISPLAY_OFF);
>
> There's drm_atomic_helper_shutdown for switching of the device.
>
> https://elixir.bootlin.com/linux/v5.17-rc2/source/drivers/gpu/drm/drm_atomic_helper.c#L3136
>
I'll use that then, thanks.
Best regards, --
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Noralf,
On 2/1/22 13:58, Noralf Trønnes wrote:
>
>
> Den 31.01.2022 21.52, skrev Sam Ravnborg:
>> On Mon, Jan 31, 2022 at 09:12:21PM +0100, Javier Martinez Canillas wrote:
>>> There isn't a connector type for display controllers accesed thro
quot; suffix in the compatible strings.
Having said that, my opinion is that we should just keep with the existing
bindings and make compatible to that even if isn't completely correct.
Since that will ease adoption of the new DRM driver and allow users to use
it without the need to update their DTBs.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
On 2/1/22 14:20, Noralf Trønnes wrote:
>
>
> Den 01.02.2022 14.06, skrev Javier Martinez Canillas:
>> Hello Noralf,
>>
>> On 2/1/22 13:58, Noralf Trønnes wrote:
>>>
>>>
>>> Den 31.01.2022 21.52, skrev Sam Ravnborg:
>>>> On Mon
t; the one who's stuck with this.
>
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Linus Torvalds
> Cc: Linux Fbdev development list
> Cc: Pavel Machek
> Cc: Sam Ravnborg
> Cc: Greg Kroah-Hartman
> Cc: Javier Martinez Canillas
> Cc: DRI Development
> Cc:
On 2/1/22 15:05, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Tue, Feb 1, 2022 at 2:02 PM Javier Martinez Canillas
> wrote:
>> On 2/1/22 10:33, Thomas Zimmermann wrote:
>>>> +{
>>>> +u8 col_end = col_start + cols - 1;
>>>> +int ret
Hello Geert,
On 2/1/22 15:14, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Tue, Feb 1, 2022 at 2:09 PM Javier Martinez Canillas
> wrote:
>> On 2/1/22 12:38, Geert Uytterhoeven wrote:
>>>> Since the current binding has a compatible "ssd1305fb-i2c&quo
On 2/1/22 15:02, Andy Shevchenko wrote:
> On Tue, Feb 01, 2022 at 12:45:53PM +0100, Javier Martinez Canillas wrote:
>> On 2/1/22 10:44, Andy Shevchenko wrote:
>>> On Tue, Feb 01, 2022 at 01:14:22AM +0100, Javier Martinez Canillas wrote:
>
> ...
>
>>> The pr
, that a makes sense to me. I'll look into
it when working on v2. Probably during the weekend.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
As I mentioned in this thread I wouldn't propose to drop the fbdev variant.
I prefer to use the carrot and not the stick. Peter Robinson suggested to
make the driver mutually exclusive and add !FB_SSD1307 in the config symbol.
I think that makes sense and will do it in v2.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
e all the context and thought
that was an opportunity to add an I2C type, since there was a SPI type already.
But seems to be more controversial than I expected and shouldn't really matter
for a tiny driver like this. I will just go ahead and use the Unknown type.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Andy,
On 2/2/22 12:06, Andy Shevchenko wrote:
> On Wed, Feb 02, 2022 at 09:38:51AM +0100, Javier Martinez Canillas wrote:
>> On 2/1/22 21:40, Sam Ravnborg wrote:
>
> ...
>
>> Peter Robinson suggested to
>> make the driver mutually exclusive and add !F
work together. If user doesn't care, the first one
> wins.
>
I don't think this is a good idea but as mentioned I don't really care that much
since we will disable all fbdev drivers anyway. So I'm happy to allow them both.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
The comment mentions that the KMS is enabled by default unless either the
i915.modeset module parameter or vga_text_mode_force boot option are used.
But the latter does not exist and instead the nomodeset option was meant.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/i915
o check this instead of just
checking if nomodeset has been set.
Javier Martinez Canillas (5):
drm/i915: Fix comment about modeset parameters
drm: Move nomodeset kernel parameter handler to the DRM subsystem
drm: Rename vgacon_text_force() function to drm_modeset_disabled()
drm: Add a drm_
that it
is part of the DRM subsystem.
Also, vgacon_text_force() is guarded by #ifdef CONFIG_VGA_CONSOLE already
so there is no need to do the same when calling the function.
Suggested-by: Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
DRM drivers can use this to determine whether they can be enabled or not.
For now it's just a wrapper around drm_modeset_disabled() but having the
indirection level will allow to add other conditions besides "nomodeset".
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Ma
.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/Makefile| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +--
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/drm_nomodeset.c | 26 +
Hello Thomas,
On 11/3/21 13:41, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.21 um 13:28 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by D
ange, and break the connection to CONFIG_VGA_CONSOLE
> altogether, also in the header?
>
> (Maybe we'll also need a proxy drm kconfig option to only have
> drm_modeset.o builtin when CONFIG_DRM != n.)
>
See my other email. I believe the issue is drivers/gpu/drm always
being
tion to drm_check_modeset() and have it
> return a negative errno code on failure. This gives maximum flexibility
> and reduces errors in drivers. Right now the drivers return something
> like -EINVAL, which seems wrong. Returning -ENODEV seems more appropriate.
>
Good idea. I'll do it in v2 as well.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Thomas,
On 11/3/21 14:01, Thomas Zimmermann wrote:
[snip]
>>
>>
>> Javier Martinez Canillas (5):
>>drm/i915: Fix comment about modeset parameters
>>drm: Move nomodeset kernel parameter handler to the DRM subsystem
>>drm: Re
Hello Jani,
On 11/4/21 12:10, Jani Nikula wrote:
> On Wed, 03 Nov 2021, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 03.11.21 um 14:41 schrieb Jani Nikula:
>>> On Wed, 03 Nov 2021, Javier Martinez Canillas wrote:
>>>> DRM drivers can use this to de
make it return -ENODEV.
Javier Martinez Canillas (2):
drm: Add a drm_drv_enabled() to check if drivers should be enabled
drm: Move nomodeset kernel parameter to the DRM subsystem
drivers/gpu/drm/Makefile| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 +++-
driv
;s no need for callers to do it.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Squash patch to add drm_drv_enabled() and make drivers use it.
- Make the drivers changes before moving nomodeset logic to DRM.
- Make drm_drv_enabled() return an errno and
acon_text_force() function and related logic to the DRM
subsystem. While doing that, rename the function to drm_check_modeset()
which better reflects what the function is really used to test for.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Cond
i915_vma.h"
>>
>> +static const struct drm_driver driver;
>> +
>
> No, this makes absolutely no sense, and will also oops on nomodeset.
>
Ups, sorry about that. For some reason I thought that it was defined in
the same compilation unit, but I noticed now that it is
101 - 200 of 2504 matches
Mail list logo
