summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-04-20drm/i915: Fixup merge of the power well refactor patchsetImre Deak
The wrong v2 version of drm/i915: Move per-platform power well hooks to intel_display_power_well.c patch was pushed to drm-intel-next branch instead of v3, fix this up applying the difference between v2 and v3. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415082524.1826924-1-imre.deak@intel.com
2022-04-20drm/i915: Remove the XELPD specific AUX and DDI power domainsImre Deak
The spec calls the XELPD_D/E ports just D/E, the platform prefix in the domain names was only needed by the port->domain mapping relying on matching enum values for the whole port/domain range (and the corresponding aliasing between the platform specific domain enums). Since a previous patch we can define the port->domain mapping explicitly so do this by reusing the already existing D/E power domain names. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-18-imre.deak@intel.com
2022-04-20drm/i915: Remove duplicate DDI/AUX power domain mappingsImre Deak
The DDI and AUX domain -> power well mappings are identical for a few platforms/power well instances, reuse the mappings of earlier platforms for these removing the duplicate mapping of new platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-17-imre.deak@intel.com
2022-04-20drm/i915: Remove the ICL specific TBT power domainsImre Deak
The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to all later platforms), align the power domain names with the spec. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-16-imre.deak@intel.com
2022-04-20drm/i915: Remove the aliasing of power domain enum valuesImre Deak
Aliasing the intel_display_power_domain enum values was required because of the u64 power domain mask size limit. This makes the dmesg/debugfs printouts of the domain names somewhat unclear, for instance domain names for port D are shown on D12+ platforms where the corresponding port is called TC1. Make this clearer by removing the aliasing which is possible after a previous patch converting the mask to a bitmap. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-15-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platformImre Deak
Atm the port -> DDI and AUX power domain mapping is specified by relying on the aliasing of the platform specific intel_display_power_domain enum values. For instance D12+ platforms refer to the 'D' port and power domain instances, which doesn't match the bspec terminology, on these platforms the corresponding port is TC1. To make it clear what port/domain the code refers to add a mapping between them which matches the bspec terms on different display versions. This also allows for removing the aliasing in enum values in a follow-up patch. v2: Add the functions to intel_display_power.c, use intel_display_power_ prefix. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-14-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the ADL-S power well definitionImre Deak
Instead of the skip_mask special casing of the ADL-S power well descriptors, add a power well descriptor list for ADL-S as well reusing the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have TypeC PHYs, so a better way would be having ADL-S specific AUX descriptors, but I left changing this for a follow-up. This changes the ordering of the AUX and TC-cold vs. PW_4/5 power wells on TGL and ADL-S, but this shouldn't make a difference (PW_4/5 don't depend on the AUX/TC-cold power wells). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-13-imre.deak@intel.com
2022-04-20drm/i915: Simplify the DG1 power well descriptorsImre Deak
Simplify the definition of DG1 power wells by reusing the identical RKL DDI/AUX descriptors. This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't make a difference (it is the order on RKL and the DDI/AUX power wells don't have a dependency on PW4/5). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-12-imre.deak@intel.com
2022-04-20drm/i915: Allow platforms to share power well descriptorsImre Deak
Some power wells - like always-on and skl+/icl+ PW_1 - with the same name, domain list, flags, ops are used by multiple platforms, so allow platforms to reuse the descriptors of such power wells. This change also lets the follow up patches to simplify the DG1/RKL power well definitions, and remove the ADL-S skip_mask special casing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-11-imre.deak@intel.com
2022-04-20drm/i915: Simplify power well definitions by adding power well instancesImre Deak
All the port specific AUX/DDI_IO power wells share the same power well ops struct and flags, so we can save some space and simplify the definition of these by listing for all such power wells only the params specific to them (name, domains, power well register index, id). Move these params to a new i915_power_well_instance struct and convert the per-platform power well definitions accordingly. For all power well instance the name and power domain list params must be specified, while the register index and id are optional, add the I915_PW() macro that both simplifies the definitions and ensures that the required params are set. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-10-imre.deak@intel.com
2022-04-20drm/i915: Convert the u64 power well domains mask to a bitmapImre Deak
To remove the aliasing of the power domain enum values in a follow-up patch in this patchset (requiring a bigger mask) and allow for defining additional power domains in the future (at least some upcoming TypeC changes requires this) convert the u64 i915_power_well_desc::domains mask to a bitmap. For simplicity I changed the for_each_power_domain_well() macros to accept one domain only instead of a mask, as there isn't any current user passing multiple domains. v2: Don't add a typedef for the bitmap struct. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-9-imre.deak@intel.com
2022-04-20drm/i915: Convert the power well descriptor domain mask to an array of domainsImre Deak
The next patch converts the i915_power_well_desc::domain mask from a u64 mask to a bitmap. I didn't find a reasonably simple way to initialize bitmaps statically, so prepare for the next patch here by converting the masks to an array of domain enums and initing the masks from these arrays during module loading. v2: Clarify list vs. array in the commit message. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-8-imre.deak@intel.com
2022-04-20drm/i915: Sanitize the power well namesImre Deak
Use the shortest descriptive name for all power wells for simplicity and to use the same name for the same type of power wells on multiple platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-7-imre.deak@intel.com
2022-04-20drm/i915: Rename the power domain names to end with pipes/portsImre Deak
Make all power domain names end with the pipe/port instance for consistency. No functional changes. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-6-imre.deak@intel.com
2022-04-20drm/i915: Move the HSW power well flags to a common bitfieldImre Deak
Save some space by grouping the HSW power well descriptor flags along with other flags in one bitfield. This change also lets simplifying the definition of power well descriptors sharing the same flags in an upcoming patch. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-5-imre.deak@intel.com
2022-04-20drm/i915: Move the dg2 fixed_enable_delay power well param to a common bitfieldImre Deak
The DG2 fixed delay duration is always 600usec, so save some space in the power well descriptors by converting the parameter to a flag. While at it also use a bitfield for both the always_on and fixed_enable_delay flag. This change also lets simplifying the definiton of power wells sharing the same flags in an upcoming patch. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-4-imre.deak@intel.com
2022-04-20drm/i915: Move the power domain->well mappings to intel_display_power_map.cImre Deak
Move the list of platform specific power domain -> power well definitions to intel_display_power_map.c. While at it group the platforms' power domain macros with the corresponding power well lists and keep all the power domain lists in the same order (matching the enum order). No functional changes. v2: - s/intel_display_power_internal.h/intel_display_power_map.h/ (Jani) - Simplify intel_cleanup_power_wells(). - Don't move intel_display_power_domain_str(). v3: - Rename intel_init/cleanup_power_wells() to intel_display_power_map_init/cleanup(). - Add documentation to intel_display_power_map_init/cleanup(). Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-3-imre.deak@intel.com
2022-04-20drm/i915: Unexport the for_each_power_well() macrosImre Deak
The for_each_power_well() macros are only used in intel_display_power.c and intel_display_power_well.c, so unexport them. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-2-imre.deak@intel.com
2022-04-20drm/i915: Move per-platform power well hooks to intel_display_power_well.cImre Deak
Move the implementation of platform specific power well hooks to intel_display_power_well.c, to reduce the clutter in intel_display_power.c. The locking of all the power domain/power well state is handled in the power domain functions in intel_display_power.c using i915_power_domains::lock. This patch also moves the chy_phy_powergate_ch/lanes() functions to intel_display_power_well.c which borrow the same lock to protect the DISPLAY_PHY_CONTROL register state, which the HW uses both for toggling power wells and power gating PHY lanes. No functional change. v2: - Clarify in the commit log why CHV functions using the i915_power_domains::lock were moved, while others locking the power domain/well state were kept in intel_display_power.c . (Jouni) - Move forward declaration of chv_phy_powergate_ch/lanes() to intel_display_power_well.h . Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-1-imre.deak@intel.com
2022-04-20drm/i915/dg2: Add workaround 18019627453José Roberto de Souza
A new DG2 workaround added to fix some corner cases hangs. v2: - implementing the second and preferred option for this workaround BSpec: 54077 BSpec: 68173 BSpec: 71488 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-2-jose.souza@intel.com
2022-04-20drm/solomon: Add SSD130x OLED displays SPI supportJavier Martinez Canillas
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. There is a difference in the communication protocol when using 4-wire SPI instead of I2C. For the latter, a control byte that contains a D/C# field has to be sent. This field tells the controller whether the data has to be written to the command register or to the graphics display data memory. But for 4-wire SPI that control byte is not used, instead a real D/C# line must be pulled HIGH for commands data and LOW for graphics display data. For this reason the standard SPI regmap can't be used and a custom .write bus handler is needed. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-6-javierm@redhat.com
2022-04-20drm/solomon: Move device info from ssd130x-i2c to the core driverJavier Martinez Canillas
These are declared in the ssd130x-i2c transport driver but the information is not I2C specific, and could be used by other SSD130x transport drivers. Move them to the ssd130x core driver and just set the OF device entries to an ID that could be used to lookup the correct device info from an array. While being there, also move the SSD130X_DATA and SSD130X_COMMAND control bytes. Since even though they are used by the I2C interface, they could also be useful for other transport protocols such as SPI. Suggested-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-5-javierm@redhat.com
2022-04-20drm/solomon: Add ssd130x new compatible strings and deprecate old ones.Javier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain an "fb" and "-i2c" suffixes. These have been deprecated and more correct ones were added, that don't encode a subsystem or bus used to interface the devices. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-4-javierm@redhat.com
2022-04-20dt-bindings: display: ssd1307fb: Extend schema for SPI controllersJavier Martinez Canillas
The Solomon SSD130x OLED displays can either have an I2C or SPI interface, add to the schema the properties and examples for OLED devices under SPI. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-3-javierm@redhat.com
2022-04-20dt-bindings: display: ssd1307fb: Deprecate "-i2c" compatible stringsJavier Martinez Canillas
The current compatible strings for SSD130x I2C controllers contain both an "fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver and also that are for devices that can be accessed over an I2C bus. But a DT is supposed to describe the hardware and not Linux implementation details. So let's deprecate those compatible strings and add new ones that only contain the vendor and device name, without any of these suffixes. These will just describe the device and can be matched by both I2C and SPI DRM drivers. The required properties should still be enforced for old ones. While being there, just drop the "sinowealth,sh1106-i2c" compatible string since that was never present in a released Linux version. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419214824.335075-2-javierm@redhat.com
2022-04-20drm/i915/display: Add workaround 22014263786José Roberto de Souza
This workaround fixes screen flickers with FBC. BSpec: 33450 BSpec: 52890 BSpec: 54369 BSpec: 66624 Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-1-jose.souza@intel.com
2022-04-20drm/i915: Program i830 DPLL FP register laterVille Syrjälä
Follow the new i9xx DPLL FP register programming sequence introduced in commit 62d66b218386 ("drm/i915: Fold i9xx_set_pll_dividers() into i9xx_enable_pll()") in the i830 "power well" code as well. Just for consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-20drm/i915: program wm blocks to at least blocks required per lineVinod Govindapillai
In configurations with single DRAM channel, for usecases like 4K 60 Hz, FIFO underruns are observed quite frequently. Looks like the wm0 watermark values need to bumped up because the wm0 memory latency calculations are probably not taking the DRAM channel's impact into account. As per the Bspec 49325, if the ddb allocation can hold at least one plane_blocks_per_line we should have selected method2. Assuming that modern HW versions have enough dbuf to hold at least one line, set the wm blocks to equivalent to blocks per line. v2: styling and comments changes (Ville) v3: Updated the reviewed-by tag v4: max_t to max and patch styling (Ville) References: https://gitlab.freedesktop.org/drm/intel/-/issues/4321 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220417093105.729014-1-vinod.govindapillai@intel.com
2022-04-20drm/i915: Fix DISP_POS_Y and DISP_HEIGHT definesHans de Goede
Commit 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers") introduced DISP_POS_Y and DISP_HEIGHT defines but accidentally set these their masks to REG_GENMASK(31, 0) instead of REG_GENMASK(31, 16). This breaks the primary display pane on at least pineview machines, fix the mask to fix the primary display pane only showing black. Tested on an Acer One AO532h with an Intel N450 SoC. Fixes: 428cb15d5b00 ("drm/i915: Clean up pre-skl primary plane registers") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220418150936.5499-1-hdegoede@redhat.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2022-04-20fbdev: Warn in hot-unplug workaround for framebuffers without deviceThomas Zimmermann
A workaround makes fbdev hot-unplugging work for framebuffers without device. The only user for this feature was offb. As each OF framebuffer now has an associated platform device, the workaround hould no longer be triggered. Update it with a warning and rewrite the comment. Fbdev drivers that trigger the hot-unplug workaround really need to be fixed. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419100405.12600-3-tzimmermann@suse.de
2022-04-20of: Create platform devices for OF framebuffersThomas Zimmermann
Create a platform device for each OF-declared framebuffer and have offb bind to these devices. Allows for real hot-unplugging and other drivers besides offb. Originally, offb created framebuffer devices while initializing its module by parsing the OF device tree. No actual Linux device was set up. This tied OF framebuffers to offb and makes writing other drivers for the OF framebuffers complicated. The absence of a Linux device further prevented real hot-unplugging. Adding a distinct platform device for each OF framebuffer solves both problems. Specifically, a DRM driver can now provide graphics output for modern userspace. Some of the offb init code is now located in the OF initialization. There's now also an implementation of of_platform_default_populate_init(), which was missing before. The OF side creates different devices for either OF display nodes or BootX displays as they require different handling by the driver. The offb drivers picks up each type of device and runs the appropriate fbdev initialization. Tested with OF display nodes on qemu's ppc64le target. v3: * declare variable 'node' with function scope (Rob) v2: * run PPC code as part of existing initialization (Rob) * add a few more error warnings (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419100405.12600-2-tzimmermann@suse.de
2022-04-20drm/gma500: fix a potential repeat execution in psb_driver_loadXiaomeng Tong
Instead of exiting the loop as expected when an entry is found, the list_for_each_entry() continues until the traversal is complete. To avoid potential executing 'ret = gma_backlight_init(dev);' repeatly, goto outside the loop when found entry by replacing switch/case with if statement. Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> [Fixed indentation] Link: https://patchwork.freedesktop.org/patch/msgid/20220413051105.5612-1-xiam0nd.tong@gmail.com
2022-04-19drm/i915/rpl-p: Add PCI IDsMatt Atwood
Adding initial PCI ids for RPL-P. RPL-P behaves identically to ADL-P from i915's point of view. Changes since V1 : - SUBPLATFORM ADL_N and RPL_P clash as both are ADLP based - Matthew R Bspec: 55376 Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> [mattrope: Corrected comment formatting to match coding style] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220418062157.2974665-1-tejaskumarx.surendrakumar.upadhyay@intel.com
2022-04-19drm/i915/dg2: Enable Wa_22012727170/Wa_22012727685John Harrison
The above two workaronuds regarding context isolation are implemented by GuC. The KMD just needs to enable them. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-7-umesh.nerlige.ramappa@intel.com
2022-04-19drm/i915/dg2: Enable Wa_14014475959 - RCS / CCS context exitMatthew Brost
There is bug in DG2 where if the CCS contexts switches out while the RCS is running it can cause memory corruption. To workaround this add an atomic to a memory address with a value 1 and semaphore wait to the same address for a value of 0. The GuC firmware is responsible for writing 0 to the memory address when it is safe for the context to switch out. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-6-umesh.nerlige.ramappa@intel.com
2022-04-19drm/i915/guc: Apply Wa_16011777198Vinay Belgaumkar
Enable GuC Wa to reset RCS/CCS before it goes into RC6. Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-5-umesh.nerlige.ramappa@intel.com
2022-04-19drm/i915/guc: Enable GuC based workarounds for DG2John Harrison
There are some workarounds for DG2 that are implemented in the GuC firmware. However, the KMD is required to enable these by setting the appropriate flag as GuC does not know what platform it is running on. Wa_16011759253 Wa_14012630569 Wa_14013746162 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> CC: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-4-umesh.nerlige.ramappa@intel.com
2022-04-19drm/i915/guc: Enable Wa_22011802037 for gen12 GuC based platformsUmesh Nerlige Ramappa
Initiating a reset when the command streamer is not idle or in the middle of executing an MI_FORCE_WAKE can result in a hang. Multiple command streamers can be part of a single reset domain, so resetting one would mean resetting all command streamers in that domain. To workaround this, before initiating a reset, ensure that all command streamers within that reset domain are either IDLE or are not executing a MI_FORCE_WAKE. Enable GuC PRE_PARSER WA bit so that GuC follows the WA sequence when initiating engine-resets. For gt-resets, ensure that i915 applies the WA sequence. Opens to address in future patches: - The part of the WA to wait for pending forcewakes is also applicable to execlists backend. - The WA also needs to be applied for gen11 Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-3-umesh.nerlige.ramappa@intel.com
2022-04-19drm/i915: Add Wa_22011802037 force cs haltTilak Tangudu
Prior to doing a reset, SW must ensure command streamer is stopped, as a workaround, to eliminate a race condition in GPM flow. Setting both the ring stop and prefetch disable bits, will cause the command streamer to halt. Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220415224025.3693037-2-umesh.nerlige.ramappa@intel.com
2022-04-19drm: bridge: icn6211: Add DSI lane count DT property parsingMarek Vasut
The driver currently hard-codes DSI lane count to two, however the chip is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT property and program the result into DSI_CTRL register. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220407185617.179573-2-marex@denx.de
2022-04-19dt-bindings: display: bridge: icn6211: Document DSI data-lanes propertyMarek Vasut
It is necessary to specify the number of connected/used DSI data lanes when using the DSI input port of this bridge. Document the 'data-lanes' property of the DSI input port. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220407185617.179573-1-marex@denx.de
2022-04-19drm/bridge: anx7625: Use uint8 for lane-swing arraysNícolas F. R. A. Prado
As defined in the anx7625 dt-binding, the analogix,lane0-swing and analogix,lane1-swing properties are uint8 arrays. Yet, the driver was reading the array as if it were of uint32 and masking to 8-bit before writing to the registers. This means that a devicetree written in accordance to the dt-binding would have its values incorrectly parsed. Fix the issue by reading the array as uint8 and storing them as uint8 internally, so that we can also drop the masking when writing the registers. Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI input feature") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220408013034.673418-1-nfraprado@collabora.com
2022-04-19drm: bridge: dw_hdmi: Audio: Add General Parallel Audio (GPA) driverSandor Yu
General Parallel Audio (GPA) interface is one of the supported audio interface for synopsys HDMI module, which has verified for i.MX8MPlus platform. This is initial version for GPA. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/f21ba3e8c4d9d028ac74c6f3c588ddbffe739399.1649989179.git.Sandor.yu@nxp.com
2022-04-19drm: bridge: dw_hdmi: add reset function for PHY GEN1Sandor Yu
PHY reset register(MC_PHYRSTZ) active high reset control for PHY GEN2, and active low reset control for PHY GEN1. Rename function dw_hdmi_phy_reset to dw_hdmi_phy_gen2_reset. Add dw_hdmi_phy_gen1_reset function for PHY GEN1. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/e0b3be2d63fe3e95246fb8b8b0dcd57415b29e04.1649989179.git.Sandor.yu@nxp.com
2022-04-19drm: bridge: dw_hdmi: Enable GCP only for Deep ColorSandor Yu
HDMI1.4b specification section 6.5.3: Source shall only send GCPs with non-zero CD to sinks that indicate support for Deep Color. DW HDMI GCP default enabled, but only transmit CD and do not handle AVMUTE, PP norDefault_Phase (yet). Disable Auto GCP when 24-bit color for sinks that not support Deep Color. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/78fa41e4fb3d3d53354034bc221fcf870dbac617.1649989179.git.Sandor.yu@nxp.com
2022-04-19drm: bridge: dw_hdmi: default enable workaround to clear the overflowSandor Yu
i.MX8MPlus (v2.13a) has verified need the workaround to clear the overflow with one iteration. Only i.MX6Q(v1.30a) need the workaround with 4 iterations, the others versions later than v1.3a have been identified as needing the workaround with a single iteration. Default enable the workaround with one iteration for all versions later than v1.30a. Signed-off-by: Sandor Yu <Sandor.yu@nxp.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/561951005a85574dcdd108e5d6a3a87df930ea3d.1649989179.git.Sandor.yu@nxp.com
2022-04-19drm: bridge: panel: Register connector if DRM device is already registeredMarek Szyprowski
If panel_bridge_attach() happens after DRM device registration, the created connector will not be registered by the DRM core anymore. Fix this by registering it explicitly in such case. This fixes the following issue observed on Samsung Exynos4210-based Trats board with a DSI panel (the panel driver is registered after the Exynos DRM component device is bound): $ ./modetest -c -Mexynos could not get connector 56: No such file or directory Segmentation fault While touching this, move the connector reset() call also under the DRM device registered check, because otherwise it is not really needed. Fixes: 934aef885f9d ("drm: bridge: panel: Reset the connector state pointer") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419091422.4255-1-m.szyprowski@samsung.com
2022-04-19drm: bridge: adv7511: Enable DRM_BRIDGE_OP_HPD based on HPD interruptBiju Das
Connector detection using poll method won't work in case of bridge attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as the code defaults to HPD. Enable DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that it will fall back to polling, if HPD is not available. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419142453.48839-1-biju.das.jz@bp.renesas.com
2022-04-19drm/bridge: lt9211: Add Lontium LT9211 bridge driverMarek Vasut
Add driver for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly capable at converting formats, but sadly it is also highly undocumented. This driver is written without any documentation from Lontium and based only on shreds of information available in various obscure example codes, hence long runs of unknown register patches and lengthy delays in various places. Whichever register meaning could be divined from its behavior has at least a comment around it. Currently the only mode tested is Single-link DSI to Single-link LVDS. Dual-link LVDS might work as well, the register programming is in place, but is untested. Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419143958.94873-2-marex@denx.de
2022-04-19dt-bindings: display: bridge: lt9211: Add Lontium LT9211 bridge driverMarek Vasut
Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly capable at converting formats, but sadly it is also highly undocumented. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220419143958.94873-1-marex@denx.de
generated by cgit (git 2.34.1) at 2025-09-11 22:22:26 +0000