- 28 Jul, 2020 9 commits
-
-
Laurent Pinchart authored
Replace the convoluted way to set the format and bus width through difficult to read macros with more explicit ones. Also remove the outdated comment related to the limitations on bus width setting as it doesn't apply anymore (the bus width can be specified through the display_info bus format). Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
mxsfb_regs.h defines macros related to register bits. Some of them are not used and don't clearly map to any particular register, so their purpose isn't known. Remove them. Signed-off-by:
-
Laurent Pinchart authored
Using BIT() is preferred over manual shifts as it's more readable, handles the 1 << 31 case properly, and avoids other mistakes as shown by the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use it. Signed-off-by:
-
Laurent Pinchart authored
Replace the manual connector implementation based on drm_panel with the drm_panel_bridge helper. This simplifies the mxsfb driver by removing connector-related code, and standardizing all pipeline control operations on bridges. A hack is needed to get hold of the connector, as that's our only source of bus flags and formats for now. As soon as the bridge API provides us with that information this can be fixed. Signed-off-by:
-
Laurent Pinchart authored
Commit 8e93f102 ("drm/mxsfb: Use drm_fbdev_generic_setup()") replaced fbdev handling with drm_fbdev_generic_setup() but left inclusion of the drm/drm_fb_cma_helper.h header. Remove it. Fixes: 8e93f102 ("drm/mxsfb: Use drm_fbdev_generic_setup()") Signed-off-by:
-
Christian König authored
We can't pipeline that during eviction because the memory needs to be available immediately. v2: fix how we cleanup the BOs resources Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Tested-by:
Alex Sierra <alex.sierra@amd.com> Link: https://patchwork.freedesktop.org/patch/379039/
-
Paul Menzel authored
The newly added hexint helper is more convenient for bitmasks. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xffffbfff Cc: amd-gfx@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
-
Paul Menzel authored
For bitmasks printing values in hex is more convenient. Prefix with `0x` to make it clear, that it’s a hex value, and pad it out. Using the helper for `amdgpu.ppfeaturemask`, it will look like below. Before: $ more /sys/module/amdgpu/parameters/ppfeaturemask 4294950911 After: $ more /sys/module/amdgpu/parameters/ppfeaturemask 0xffffbfff Cc: linux-kernel@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
-
Paul Menzel authored
The second and third arguments are aligned with tabs, so do the same for the fourth. Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
- 27 Jul, 2020 15 commits
-
-
Sam Ravnborg authored
Prepare the bridge driver for use in a chained setup. - Replacing direct use of drm_panel with drm_panel_bridge support. - Make the connector creation optional Note: the bridge panel will use the connector type from the panel. v3: - Fix wrong logic in connector creation (Laurent) v2: - Use panel_bridge for local variable name to align with other drivers - Fix that connector was created twice (Laurent) - Set bridge.type to DRM_MODE_CONNECTOR_LVDS. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Sam Ravnborg authored
Add the get_edid() bridge operation to prepare for use as a chained bridge. Add helper function that is also used by the connector. v2: - Fix memory leak (Laurent) - Do not save a copy of edid, read it when needed Signed-off-by:
-
Sam Ravnborg authored
With the bridge operations implemented the last step to prepare this driver for a chained setup is the use of the bridge panel driver. The bridge panel driver is only used when a port@2 is present in the DT. So when the display driver requests a connector support both situations: - connector created by bridge panel driver - connector created by this driver And on top, support that the display driver creates the connector, which is the preferred setup. Note: the bridge panel will use the connector type from the panel. v3: - Fix wrong logic in connector creation (Laurent) v2: - Merge connector and drm_panel_bridge patches and fix so we do not create two connectors (Laurent) Signed-off-by: -
Sam Ravnborg authored
Prepare for chained bridge with the addition of get_edid support. v2: - Fixed handling of edid storage (Laurent) Signed-off-by:
-
Sam Ravnborg authored
Prepare the bridge driver for chained operation by adding support for the detect operation. v3: - Fix code to make it readable (Laurent) v2: - Do not announce detect operation if there is no hpd pin (Laurent) Signed-off-by:
-
Sam Ravnborg authored
Make the connector creation optional to enable usage of the megachips-stdpxxxx-ge-b850v3-fw bridge with the DRM bridge connector helper. v2: - Set bridge.type to DRM_MODE_CONNECTOR_DisplayPort Signed-off-by:
-
Sam Ravnborg authored
To prepare for a chained bridge setup add support for the get_edid bridge operation. There is no need for a copy of the edid - so drop the pointer to the copy. v2: - Fix so we do not leak memory (Laurent) Signed-off-by:
-
Sam Ravnborg authored
To prepare for use in a chained bridge setup enable the detect operation. Signed-off-by:
-
Sam Ravnborg authored
Fix so drm_device is read from the bridge. This is a preparation for the connector being optional. Signed-off-by:
-
Sam Ravnborg authored
Factor out connector creation to a small helper function. Signed-off-by:
-
Sam Ravnborg authored
Prepare the bridge driver for use in a chained setup by replacing direct use of drm_panel with drm_panel_bridge support. The connecter is now either created by the panel bridge or the display driver. So all code for connector creation in this driver is no longer relevant and thus dropped. The connector code had some special polling handling: connector.polled = DRM_CONNECTOR_POLL_HPD; drm_helper_hpd_irq_event(ps8622->bridge.dev); This code was most likely added to speed up detection of the connector. If really needed then this functionality belongs somewhere else. Note: the bridge panel will use the connector type from the panel. v2: - Fix to avoid creating connector twice (Laurent) - Drop all connector code - defer to bridge panel - Use panel_bridge for local variable to align with other drivers - Set bridge.type to DRM_MODE_CONNECTOR_LVDS; Signed-off-by: -
Sam Ravnborg authored
Prepare the tc358764 bridge driver for use in a chained setup by replacing direct use of drm_panel with drm_panel_bridge support. The bridge panel will use the connector type reported by the panel, where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS. The tc358764 did not add any additional info the the connector so the connector creation is passed to the bridge panel driver. v3: - Merge with patch to make connector creation optional to avoid creating two connectors (Laurent) - Pass connector creation to bridge panel, as this bridge driver did not add any extra info to the connector. - Set bridge.type to DRM_MODE_CONNECTOR_LVDS. v2: - Use PTR_ERR_OR_ZERO() (kbuild test robot) Signed-off-by: -
Sam Ravnborg authored
Drop drm_connector handling that is not needed: - drm_dev_register() in the display controller driver takes care of registering connectors. So the call to drm_connector_register() call is not needed in the bridge driver. - Use of drm_connector_unregister() is only required for drivers that explicit have called drm_dev_register. - The reference counting using drm_connector_put() is likewise not needed. Signed-off-by:
-
Sam Ravnborg authored
All panels shall report a connector type. panel-simple has a lot of panels with no connector_type, and for these fall back to DPI as the default. v2: - Rebased on top of validation of panel description Signed-off-by:
-
Sam Ravnborg authored
Warn if we detect a panel with incomplete/wrong description. This is inspired by a similar patch by Laurent that introduced checks for LVDS panels - this extends the checks to the remaining type of connectors. This is known to warn for some of the existing panels but added despite this as we need help from people using the panels to add the missing info. The checks are not complete but will catch the most common mistakes. The checks at the same time serve as documentation for the minimum required description for a panel. The checks uses dev_warn() as we know this will hit. WARN() was too noisy at the moment for anything else than LVDS. v3: - %d => %u for bpc (Laurent) v2: - Use dev_warn (Laurent) - Check for empty bus_flags Signed-off-by:
-
- 26 Jul, 2020 4 commits
-
-
Sam Ravnborg authored
The boe,hv070wsa-100 panel is a LVDS panel. Fix connector type to reflect this. With this change users of this panel do not have to specify the connector type. v4: - Add .bpc = 4 (Laurent) v3: - Drop PIXDATA bus_flag, not relevant v2: - Add .bus_format (Laurent) - Add .bus_flags Signed-off-by:
-
Vinod Koul authored
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and I2S port as an input and HDMI port as output Co-developed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> # fix lt9611_bridge_mode_valid Link: https://patchwork.freedesktop.org/patch/msgid/20200723163442.1280414-4-vkoul@kernel.org
-
Vinod Koul authored
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output Reviewed-by:
Rob Herring <robh@kernel.org> Tested-by:
-
Vinod Koul authored
Add prefix for Lontium Semiconductor Corporation Acked-by:
-
- 24 Jul, 2020 1 commit
-
-
Ville Syrjälä authored
Add a TODO for plumbing drm_atomic_state all over to ease the hurdles of accessing additional object states. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #irc Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200717135439.5996-1-ville.syrjala@linux.intel.com
-
- 23 Jul, 2020 1 commit
-
-
Linus Walleij authored
Remove notes about migrating from the old driver which is retired as all users are now migrated. Update the text to reflect that we support PL110 and PL111 alike. Drop the bullet on memory bandwidth scaling: this has been implemented. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Russell King <linux@armlinux.org.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200720130327.92364-1-linus.walleij@linaro.org
-
- 22 Jul, 2020 3 commits
-
-
Christian König authored
Not used any more. And it is bad design to use a TTM flag to do a check inside a driver. Signed-off-by:
-
Christian König authored
The driver does support some not-mapable resources, but those are already handled correctly in the switch/case statement in the code. Signed-off-by:
-
Christian König authored
The driver doesn't expose any not-mapable memory resources. Signed-off-by:
-
- 21 Jul, 2020 7 commits
-
-
Ondrej Jirman authored
The display has one port. Allow it in the binding. Reviewed-by:
Guido Günther <agx@sigxcpu.org> Signed-off-by:
Ondrej Jirman <megous@megous.com> Signed-off-by:
-
Ondrej Jirman authored
The example is now validated against rocktech,jh057n00900 schema that was ported to yaml, and didn't validate with: - '#address-cells', '#size-cells', 'port@0' do not match any of the regexes: 'pinctrl-[0-9]+' - 'vcc-supply' is a required property - 'iovcc-supply' is a required property - 'reset-gpios' is a required property Fix it. Reviewed-by:
-
Lyude Paul authored
This is an ioctl callback, so we're guaranteed to have IRQs enabled when calling this function. Use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200720190736.180297-6-lyude@redhat.comReviewed-by:
-
Lyude Paul authored
This one's easy - we're already calling kzalloc(GFP_KERNEL) in this function, so we must already be guaranteed to have IRQs enabled when calling this. So, use the plain _irq() variants of spin_(un)lock() to make this more obvious. Signed-off-by:
-
Lyude Paul authored
This function is only ever called from ioctl context, so we're guaranteed to have interrupts enabled. Stop using the irqsave/irqrestore variants of spin_(un)lock_irq() to make this more obvious. Signed-off-by:
-
Lyude Paul authored
This is only called from: * Atomic modesetting hooks * Module probing routines * Legacy modesetting hooks All of which have IRQs enabled, so we can also get rid of irqsave/restore here to make the IRQ context of this function more obvious. Signed-off-by:
-
Lyude Paul authored
All of the drivers in the kernel tree only call this from one of the following contexts: * drm_crtc_funcs->reset * During initial module load Since both of these contexts are guaranteed to have interrupts enabled beforehand, there's no need to use the irqsave/irqrestore variants of spin_(un)lock(). So, fix this to make the irq context of this function more obvious. Signed-off-by:
-
