- 03 Aug, 2023 14 commits
-
-
Arnd Bergmann authored
When a symbol is selected that has extra dependencies, anything that selects it must have the same dependencies. With the added CONFIG_DRM reference from I2C_HID_CORE, this broke a couple of drivers that now also depend on DRM: WARNING: unmet direct dependencies detected for I2C_HID_CORE Depends on [m]: HID_SUPPORT [=y] && I2C_HID [=y] && (DRM [=m] || !DRM [=m]) Selected by [y]: - I2C_HID_OF [=y] && HID_SUPPORT [=y] && I2C_HID [=y] - I2C_HID_ACPI [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && ACPI [=y] - I2C_HID_OF_GOODIX [=y] && HID_SUPPORT [=y] && I2C_HID [=y] && OF [=y] x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_remove': (.text+0xfc8826): undefined reference to `drm_panel_remove_follower' x86_64-linux-ld: vmlinux.o: in function `i2c_hid_core_probe': (.text+0xfc8da0): undefined reference to `drm_is_panel_follower' Add the corresponding DRM||!DRM dependencies on each one that is affected. Fixes: 96a37bfd ("HID: i2c-hid: Support being a panel follower") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Thomas Zimmermann authored
Use fb_info() to print status message at the end of the probe function, which avoids decoding the devices. fb_info() works with or without an fbdev kernel device. Fixes the following error: ../drivers/video/fbdev/ps3fb.c: In function 'ps3fb_probe': ../drivers/video/fbdev/ps3fb.c:1172:40: error: 'struct fb_info' has no member named 'dev' 1172 | dev_driver_string(info->dev), dev_name(info->dev), | ^~ ../include/linux/dev_printk.h:110:37: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info' 1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n", | ^~~~~~~~ ../drivers/video/fbdev/ps3fb.c:1172:61: error: 'struct fb_info' has no member named 'dev' 1172 | dev_driver_string(info->dev), dev_name(info->dev), | ^~ ../include/linux/dev_printk.h:110:37: note: in definition of macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ ../drivers/video/fbdev/ps3fb.c:1171:9: note: in expansion of macro 'dev_info' 1171 | dev_info(info->device, "%s %s, using %u KiB of video memory\n", | ^~~~~~~~ Reported-by:Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/lkml/ccc63065-2976-88ef-1211-731330bf2866@infradead.org/Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: 701d2054 ("fbdev: Make support for userspace interfaces configurable") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Helge Deller <deller@gmx.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Simon Ser authored
Since commit 6b85aa68 ("drm: Enable PRIME import/export for all drivers"), import/export is always supported. Document this so that user-space knows what to expect. Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Jeffrey Hugo <quic_jhugo@quicinc.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230712183156.191445-1-contact@emersion.fr
-
Simon Ser authored
Convert struct drm_event to a kernel doc comment. Link to the generic DRM event types. Add a basic description of each event type. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230717093032.600773-1-contact@emersion.fr
-
Simon Ser authored
Mention that the connector_type_id is not stable: it depends on driver and device probe order. Signed-off-by:
-
Simon Ser authored
When I originally wrote these docs, I couldn't manage to insert a cross-reference to a section. Here's how it can be done. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
-
GUO Zihua authored
fbcon_registered_fb and fbcon_num_registered_fb is not referred outside drivers/video/fbdev/core/fbcon.c, so make them static. Signed-off-by:
GUO Zihua <guozihua@huawei.com> Signed-off-by:
-
Sui Jingfeng authored
Signed-off-by:
Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230409131547.494128-1-15330273260@189.cnSigned-off-by:
-
Alexander Stein authored
This bridge has an interrupt line for event signaling. Add the corresponding property. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230718084411.1189831-1-alexander.stein@ew.tq-group.com
-
Sandor Yu authored
CEC interrupt status/mask and logical address registers will be reset when device enter suspend. It will cause cec fail to work after device resume. Add CEC suspend/resume functions, reinitialize logical address registers and restore interrupt status/mask registers after resume. Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com> Reviewed-by:
-
Marek Vasut authored
Add support for Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel. Documentation is available at [1]. The middle frequency is tuned slightly upward from 70.93 MHz to 72 MHz, otherwise the panel shows slight flicker. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdfSigned-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
-
Marek Vasut authored
Add entry for Innolux G156HCE-L01 15.6" 1920x1080 24bpp dual-link LVDS TFT panel. Documentation is available at [1]. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G156HCE-L01_Rev.C3_Datasheet.pdfSigned-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Douglas Anderson authored
In commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel") the formatting for a code block was not quite right. This caused an error when building htmldocs: Documentation/gpu/todo.rst:469: ERROR: Unexpected indentation. Fix the error by using the proper syntax for a code block. Fixes: d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20230802141724.0edce253@canb.auug.org.auSigned-off-by:
-
Douglas Anderson authored
In the kernel doc for the `follower_lock` member of `struct drm_panel` there was a typo where it was called `followers_lock`. This resulted in a warning when making "htmldocs": ./include/drm/drm_panel.h:270: warning: Function parameter or member 'follower_lock' not described in 'drm_panel' Fix the typo. Fixes: de087416 ("drm/panel: Add a way for other devices to follow panel state") Reported-by:
-
- 02 Aug, 2023 4 commits
-
-
Colin Ian King authored
Pointer pexec is being assigned a value however it is never read. The assignment is redundant and can be removed. Replace sizeof(*pexec) with sizeof the type and remove the declaration of pointer pexec. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
-
Otto Pflüger authored
Displays that are connected to the same SPI bus may share the D/C GPIO. Use GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow access to the same GPIO for multiple panel-mipi-dbi instances. Exclusive access to the GPIO during transfers is ensured by the locking in drm_mipi_dbi.c. Signed-off-by:
Otto Pflüger <otto.pflueger@abscue.de> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230724065654.5269-3-otto.pflueger@abscue.de
-
Otto Pflüger authored
Multiple displays may be connected to the same bus and share a D/C GPIO, so the display driver needs exclusive access to the bus to ensure that it can control the D/C GPIO safely. Signed-off-by:
David Lechner <david@lechnology.com> Signed-off-by:
-
Tomi Valkeinen authored
DRM bridges are not visible to the userspace and it may not be immediately clear if the chain is somehow constructed incorrectly. I have had two separate instances of a bridge driver failing to do a drm_bridge_attach() call, resulting in the bridge connector not being part of the chain. In some situations this doesn't seem to cause issues, but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used. Add a debugfs file to print the bridge chains. For me, on this TI AM62 based platform, I get the following output: encoder[39] bridge[0] type: 0, ops: 0x0 bridge[1] type: 0, ops: 0x0, OF: /bus@f0000/i2c@20000000/dsi@e:toshiba,tc358778 bridge[2] type: 0, ops: 0x3, OF: /bus@f0000/i2c@20010000/hdmi@48:lontium,lt8912b bridge[3] type: 11, ops: 0x7, OF: /hdmi-connector:hdmi-connector Tested-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by:
-
- 01 Aug, 2023 22 commits
-
-
Douglas Anderson authored
Turning on an i2c-hid device can be a slow process. This is why i2c-hid devices use PROBE_PREFER_ASYNCHRONOUS. Unfortunately, when we're a panel follower the i2c-hid power up sequence now blocks the power on of the panel. Let's fix that by scheduling the work on the system_wq. Reviewed-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Benjamin Tissoires <bentiss@kernel.org> Acked-by:
-
Douglas Anderson authored
As talked about in the patch ("drm/panel: Add a way for other devices to follow panel state"), we really want to keep the power states of a touchscreen and the panel it's attached to in sync with each other. In that spirit, add support to i2c-hid to be a panel follower. This will let the i2c-hid driver get informed when the panel is powered on and off. From there we can match the i2c-hid device's power state to that of the panel. NOTE: this patch specifically _doesn't_ use pm_runtime to keep track of / manage the power state of the i2c-hid device, even though my first instinct said that would be the way to go. Specific problems with using pm_runtime(): * The initial power up couldn't happen in a runtime resume function since it create sub-devices and, apparently, that's not good to do in your resume function. * Managing our power state with pm_runtime meant fighting to make the right thing happen at system suspend to prevent the system from trying to resume us only to suspend us again. While this might be able to be solved, it added complexity. Overall the code without pm_runtime() ended up being smaller and easier to understand. Reviewed-by: -
Douglas Anderson authored
In the i2c-hid remove() function we currently try to power off, depopulate our child device, and free our resources. That's OK, but... * If the i2c-hid device is on a power rail that can't turn off (either an always-on or a shared power rail) we won't try to put the device in a low power state during remove(). This probably doesn't matter for very many devices but it could be nice in some instances. * If the i2c-hid device somehow manages to generate an interrupt after we tried to power off it is conceivable that the interrupt could arrive during or after the call to hid_destroy_device() but before the call to free_irq(). That could cause a crash since our IRQ handler isn't expecting it. One could imagine this happening in the case where we couldn't turn off (see the previous bullet) or, possibly, if the interrupt line could glitch shortly after the device powered off. Let's call the suspend code during remove to avoid these issues. That will put the device into a low power state and also disable interrupts. Technically, one could consider this a "fix" of commit 4a200c3b ("HID: i2c-hid: introduce HID over i2c specification implementation"). However, since the above bullet points are more theoretical than problems seen on real systems and since the remove() of an i2c-hid touchscreen isn't terribly likely to be called in production, it's probably not worth the bother of trying to backport it. Reviewed-by:
-
Douglas Anderson authored
In a future patch we'd like to be able to call the current i2c-hid suspend and resume functions from times other than system suspend. Move the functions higher up in the file and have them take a "struct i2c_hid" to make this simpler. We'll then add tiny wrappers of the functions for use with system suspend. This change is expected to have no functional effect. Reviewed-by:
-
Douglas Anderson authored
In a future patch, we want to change i2c-hid not to necessarily power up the touchscreen during probe. In preparation for that, rearrange the probe function so that we put as much stuff _before_ powering up the device as possible. This change is expected to have no functional effect. Reviewed-by:
-
Douglas Anderson authored
The SYSTEM_SLEEP_PM_OPS() allows us to get rid of '#ifdef CONFIG_PM_SLEEP', as talked about in commit 1a3c7bb0 ("PM: core: Add new *_PM_OPS macros, deprecate old ones"). This change is expected to have no functional effect. Reviewed-by:
-
Douglas Anderson authored
Inform fw_devlink of the fact that a panel follower (like a touchscreen) is effectively a consumer of the panel from the purposes of fw_devlink. NOTE: this patch isn't required for correctness but instead optimizes probe order / helps avoid deferrals. Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Douglas Anderson authored
These days, it's fairly common to see panels that have touchscreens attached to them. The panel and the touchscreen can somewhat be thought of as totally separate devices and, historically, this is how Linux has treated them. However, treating them as separate isn't necessarily the best way to model the two devices, it was just that there was no better way. Specifically, there is little practical reason to have the touchscreen powered on when the panel is turned off, but if we model the devices separately we have no way to keep the two devices' power states in sync with each other. The issue described above makes it sound as if the problem here is just about efficiency. We're wasting power keeping the touchscreen powered up when the screen is off. While that's true, the problem can go deeper. Specifically, hardware designers see that there's no reason to have the touchscreen on while the screen is off and then build hardware assuming that software would never turn the touchscreen on while the screen is off. In the very simplest case of hardware designs like this, the touchscreen and the panel share some power rails. In most cases, this turns out not to be terrible and is, again, just a little less efficient. Specifically if we tell Linux that the touchscreen and the panel are using the same rails then Linux will keep the rails on when _either_ device is turned on. That ends to work OK-ish, but now if you turn the panel off not only will the touchscreen remain powered, but the power rails for the panel itself won't be switched off, burning extra power. The above two inefficiencies are _extra_ minor when you consider the fact that laptops rarely spend much time with the screen off. The main use case would be when an external screen (and presumably a power supply) is attached. Unfortunately, it gets worse from here. On sc7180-trogdor-homestar, for instance, the display's TCON (timing controller) sometimes crashes if you don't power cycle it whenever you stop and restart the video stream (like during a modeset). The touchscreen keeping the power rails on causes real problems. One proposal in the homestar timeframe was to move the touchscreen to an always-on rail, dedicating the main power rail to the panel. That caused _different_ problems as talked about in commit 557e05fa ("HID: i2c-hid: goodix: Stop tying the reset line to the regulator"). The end result of all of this was to add an extra regulator to the board, increasing cost. Recently, Cong Yang posted a patch [1] where things are even worse. The panel and touch controller on that system seem even more intimately tied together and really can't be thought of separately. To address this issue, let's start allowing devices to register themselves as "panel followers". These devices will get called after a panel has been powered on and before a panel is powered off. This makes the panel the primary device in charge of the power state, which matches how userspace uses it. The panel follower API should be fairly straightforward to use. The current code assumes that panel followers are using device tree and have a "panel" property pointing to the panel to follow. More flexibility and non-DT implementations could be added as needed. Right now, panel followers can follow the prepare/unprepare functions. There could be arguments made that, instead, they should follow enable/disable. I've chosen prepare/unprepare for now since those functions are guaranteed to power up/power down the panel and it seems better to start the process earlier. A bit of explaining about why this is a roll-your-own API instead of using something more standard: 1. In standard APIs in Linux, parent devices are automatically powered on when a child needs power. Applying that here, it would mean that we'd force the panel on any time someone was listening to the touchscreen. That, unfortunately, would have broken homestar's need (if we hadn't changed the hardware, as per above) where the panel absolutely needs to be able to power cycle itself. While one could argue that homestar is broken hardware and we shouldn't have the API do backflips for it, _officially_ the eDP timing guidelines agree with homestar's needs and the panel power sequencing diagrams show power going off. It's nice to be able to support this. 2. We could, conceibably, try to add a new flag to device_link causing the parent to be in charge of power. Then we could at least use normal pm_runtime APIs. This sounds great, except that we run into problems with initial probe. As talked about in the later patch ("HID: i2c-hid: Support being a panel follower") the initial power on of a panel follower might need to do things (like add sub-devices) that aren't allowed in a runtime_resume function. The above complexities explain why this API isn't using common functions. That being said, this patch is very small and self-contained, so if someone was later able to adapt it to using more common APIs while solving the above issues then that could happen in the future. [1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.comReviewed-by:
-
Douglas Anderson authored
In a whole pile of panel drivers, we have code to make the prepare/unprepare/enable/disable callbacks behave as no-ops if they've already been called. It's silly to have this code duplicated everywhere. Add it to the core instead so that we can eventually delete it from all the drivers. Note: to get some idea of the duplicated code, try: git grep 'if.*>prepared' -- drivers/gpu/drm/panel git grep 'if.*>enabled' -- drivers/gpu/drm/panel NOTE: arguably, the right thing to do here is actually to skip this patch and simply remove all the extra checks from the individual drivers. Perhaps the checks were needed at some point in time in the past but maybe they no longer are? Certainly as we continue transitioning over to "panel_bridge" then we expect there to be much less variety in how these calls are made. When we're called as part of the bridge chain, things should be pretty simple. In fact, there was some discussion in the past about these checks [1], including a discussion about whether the checks were needed and whether the calls ought to be refcounted. At the time, I decided not to mess with it because it felt too risky. Looking closer at it now, I'm fairly certain that nothing in the existing codebase is expecting these calls to be refcounted. The only real question is whether someone is already doing something to ensure prepare()/unprepare() match and enabled()/disable() match. I would say that, even if there is something else ensuring that things match, there's enough complexity that adding an extra bool and an extra double-check here is a good idea. Let's add a drm_warn() to let people know that it's considered a minor error to take advantage of drm_panel's double-checking but we'll still make things work fine. We'll also add an entry to the official DRM todo list to remove the now pointless check from the panels after this patch lands and, eventually, fixup anyone who is triggering the new warning. [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeidAcked-by:
-
Douglas Anderson authored
As talked about in the patch ("drm/panel: Add a way for other devices to follow panel state"), touchscreens that are connected to panels are generally expected to be power sequenced together with the panel they're attached to. Today, nothing provides information allowing you to find out that a touchscreen is connected to a panel. Let's add a phandle for this. The proerty is added to the generic touchscreen bindings and then enabled in the bindings for the i2c-hid backed devices. This can and should be added for other touchscreens in the future, but for now let's start small. Reviewed-by: -
Nikita Travkin authored
Add timings for InnoLux N140HCA-EAC. This panel is found on some laptops such as Acer Aspire 1. Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Reviewed-by:
-
Miquel Raynal authored
A very basic debugging rule when a device is connected for the first time is to access a read-only register which contains known data in order to ensure the communication protocol is properly working. This driver lacked any read helper which is often a critical piece for speeding-up bring-ups. Add a read helper and use it to verify the communication with the panel is working as soon as possible in order to inform the user early if this is not the case. As this panel may work with no MISO line, the check is discarded in this case. Upon error, we do not fail probing but just warn the user, in case the DT description would be lacking the Rx bus width (which is likely on old descriptions) in order to avoid breaking existing devices. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Sebastian Reichel <sre@kernel.org> Tested-by: Sebastian Reichel <sre@kernel.org> # no MISO line Signed-off-by:
-
Miquel Raynal authored
This panel from Emerging Display Technologies Corporation features an ST7789V2 LCD controller panel inside which is almost identical to what the Sitronix panel driver supports. In practice, the module physical size is specific, and experiments show that the display will malfunction if any of the following situation occurs: * Pixel clock is above 3MHz * Pixel clock is not inverted I could not properly identify the reasons behind these failures, scope captures show valid input signals. Signed-off-by:
-
Miquel Raynal authored
The Sitronix datasheet explains BIT(1) of the RGBCTRL register as the DOTCLK/PCLK edge used to sample the data lines: “0” The data is input on the positive edge of DOTCLK “1” The data is input on the negative edge of DOTCLK IOW, this bit implies a falling edge and not a high state. Correct the definition to ease the comparison with the datasheet. Signed-off-by: -
Miquel Raynal authored
The Sitronix controller expects 9-bit words, provide this as default at probe time rather than specifying this in each and every access. Signed-off-by:
-
Miquel Raynal authored
The ST7789V LCD controller supports regular SPI wiring, as well as no Rx data line at all. The operating system needs to know whether it can read registers from the device or not. Let's detail this specific design possibility by bounding the spi-rx-bus-width property. Signed-off-by:
-
Miquel Raynal authored
The ST7789V LCD controller is also embedded in the ET028013DMA panel. Add a compatible string to describe this other panel. Signed-off-by:
-
Sebastian Reichel authored
UNI-T UTi260b has a Inanbo T28CP45TN89 v17 panel. I could not find proper documentation for the panel apart from a technical drawing, but according to the vendor U-Boot it is based on a Sitronix st7789v chip. I generated the init sequence by modifying the default one until proper graphics output has been seen on the device. Reviewed-by:
Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by:
-
Sebastian Reichel authored
Add polarity information via mode and bus flags, so that they are no longer hardcoded and forward the information to the DRM stack. This is required for adding panels with different settings. Reviewed-by:
-
Sebastian Reichel authored
While the default panel uses invert mode, some panels require non-invert mode instead. Reviewed-by:
-
Sebastian Reichel authored
Add support for describing the media bus format in the panel configuration and expose that to userspace. Since both supported formats (RGB565 and RGB666) are using 6 bits per color also hardcode that information. Reviewed-by:
-
Sebastian Reichel authored
Move the panel size information to the mode struct, so that different panel sizes can be specified depending on the panel type. Reviewed-by:
-
