aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-04-21drm/i915/gvt: devirtualize ->gfn_to_mfnChristoph Hellwig4-35/+5
Just open code it in the only caller. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->is_valid_gfnChristoph Hellwig4-37/+18
Just call the code directly and move towards the callers. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->inject_msiChristoph Hellwig4-63/+39
Just open code the MSI injection in a single place instead of going through the method table. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->detach_vgpuChristoph Hellwig5-20/+3
Just call the function directly. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->set_edid and ->set_opregionChristoph Hellwig5-42/+8
Just call the code to setup the opregions and EDID data directly. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->{get,put}_vfio_deviceChristoph Hellwig4-59/+7
Just open code the calls to the VFIO APIs. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: devirtualize ->{read,write}_gpaChristoph Hellwig10-97/+72
Just call the VFIO functions directly instead of through the method table. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove vgpu->handleChristoph Hellwig5-116/+71
Always pass the actual vgpu structure instead of encoding it as a "handle" and add a bool flag to denote if a VGPU is attached. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpuChristoph Hellwig2-73/+52
Consolidate the per-VGPU structures into a single one. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpuChristoph Hellwig5-216/+128
Move towards having only a single structure for the per-VGPU state. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove the unused from_virt_to_mfn opChristoph Hellwig3-19/+0
Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area opsChristoph Hellwig3-120/+17
The map_gfn_to_mfn and set_trap_area ops are never defined, so remove them and clean up code that depends on them in the callers. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove intel_gvt_opsChristoph Hellwig5-69/+19
Remove these pointless indirect alls by just calling the only instance of each method directly. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: move the gvt code into kvmgt.koChristoph Hellwig12-153/+192
Instead of having an option to build the gvt code into the main i915 module, just move it into the kvmgt.ko module. This only requires a new struct with three entries that the KVMGT modules needs to register with the main i915 module, and a proper list of GVT-enabled devices instead of global device pointer. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_opsChristoph Hellwig1-3/+3
Free the intel_vgpu_ops symbol name for something that fits better. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove enum hypervisor_typeChristoph Hellwig5-141/+34
The only supported hypervisor is KVM, so don't bother with dead code enumerating hypervisors. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: remove module refcounting in intel_gvt_{,un}register_hypervisorChristoph Hellwig1-6/+0
THIS_MODULE always is reference when a symbol called by it is used, so don't bother with the additional reference. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Zhi Wang <[email protected]>
2022-04-21drm/i915/gvt: better align the Makefile with i915 MakefileJani Nikula2-10/+26
Drop extra ccflags, drop extra intermediate variables, list object files one per line alphabetically. Cc: Zhi Wang <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/8bc0895376c077156a671e24ac6a5c75b7db4c9c.1649852517.git.jani.nikula@intel.com Reviewed-by: Zhi Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2022-04-21drm/i915/gvt: fix trace TRACE_INCLUDE_PATHJani Nikula1-1/+1
TRACE_INCLUDE_PATH should be a path relative to define_trace.h, not the file including it. (See the comment in include/trace/define_trace.h.) Cc: Zhi Wang <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/48b772795b7ab674f609ecad53b4882c66a8262a.1649852517.git.jani.nikula@intel.com Reviewed-by: Zhi Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2022-04-21i915/gvt: Use the initial HW state snapshot saved in i915Zhi Wang1-16/+9
The code of saving initial HW state snapshot has been moved into i915. Let the GVT-g core logic use that snapshot. Cc: Christoph Hellwig <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Vivi Rodrigo <[email protected]> Cc: Zhenyu Wang <[email protected]> Cc: Zhi Wang <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Christoph Hellwig <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21i915/gvt: Save the initial HW state snapshot in i915Zhi Wang2-2/+92
Save the initial HW state snapshot in i915 so that the rest code of GVT-g can be moved into a dedicated module while it can still get a clean initial HW state saved at the correct time during the initialization of i915. The futhrer vGPU created by GVT-g will use this HW state as the initial HW state. v6: - Remove the reference of intel_gvt_device_info.(Christoph) - Refine the save_mmio() function. (Christoph) Cc: Christoph Hellwig <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Vivi Rodrigo <[email protected]> Cc: Zhenyu Wang <[email protected]> Cc: Zhi Wang <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Christoph Hellwig <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-21i915/gvt: Separate the MMIO tracking table from GVT-gZhi Wang7-899/+1458
To support the new mdev interfaces and the re-factor patches from Christoph, which moves the GVT-g code into a dedicated module, the GVT-g MMIO tracking table needs to be separated from GVT-g. v9: - Fix a problem might cause kernel panic. - Remove the redaundant definitation of intel_get_device_type(). (Jani) - Sort the list of header reference in intel_gvt_mmio.c (Jani) - Include minimum header insted in intel_gvt_mmio.c (Jani) v8: - Use SPDX header in the intel_gvt_mmio_table.c - Reference the gvt.h with path. (Jani) - Add a missing fix on mmio emulation path during the debug. - Fix a building problem on refreshed gvt-staging branch. (Christoph) v7: - Keep the marcos of device generation in GVT-g. (Christoph, Jani) v6: - Move the mmio_table.c into i915. (Christoph) - Keep init_device_info and related structures in GVT-g. (Christoph) - Refine the callbacks of the iterator. (Christoph) - Move the flags of MMIO register defination to GVT-g. (Chrsitoph) - Move the mmio block handling to GVT-g. v5: - Re-design the mmio table framework. (Christoph) v4: - Fix the errors of patch checking scripts. v3: - Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani) v2: - Implement a mmio table instead of generating it by marco in i915. (Jani) Cc: Christoph Hellwig <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Vivi Rodrigo <[email protected]> Cc: Zhenyu Wang <[email protected]> Cc: Zhi Wang <[email protected]> Signed-off-by: Zhi Wang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Christoph Hellwig <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/radeon: Use TTM builtin resource manager debugfs codeZack Rusin1-30/+6
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]>
2022-04-20drm/qxl: Use TTM builtin resource manager debugfs codeZack Rusin1-33/+6
Switch to using the TTM resource manager debugfs helpers. The functionality is largely the same. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]>
2022-04-20drm/amdgpu: Use TTM builtin resource manager debugfs codeZack Rusin1-70/+16
Switch to using the TTM resource manager debugfs helpers. It's exactly the same functionality but the debugfs code is shared with other drivers. The TTM resource managers need to stay valid for as long as the drm debugfs_root is valid. Signed-off-by: Zack Rusin <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Felix Kuehling <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]>
2022-04-20drm/vmwgfx: Add debugfs entries for various ttm resource managersZack Rusin1-0/+18
Use the newly added TTM's ability to automatically create debugfs entries for specified placements. This creates debugfs files that can be read to get information about various TTM resource managers which are used by vmwgfx. Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]>
2022-04-20drm/ttm: Add common debugfs code for resource managersZack Rusin2-0/+38
Drivers duplicate the code required to add debugfs entries for various ttm resource managers. To fix it add common TTM resource manager debugfs code that each driver can reuse. Specific resource managers can overwrite ttm_resource_manager_func::debug to get more information from those debugfs entries. Signed-off-by: Zack Rusin <[email protected]> Cc: Huang Rui <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]>
2022-04-20drm/i915: Fixup merge of the power well refactor patchsetImre Deak1-17/+3
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Remove the XELPD specific AUX and DDI power domainsImre Deak3-38/+11
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Remove duplicate DDI/AUX power domain mappingsImre Deak1-58/+31
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Remove the ICL specific TBT power domainsImre Deak3-21/+9
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Remove the aliasing of power domain enum valuesImre Deak2-43/+67
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platformImre Deak8-89/+235
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Sanitize the ADL-S power well definitionImre Deak1-30/+39
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Simplify the DG1 power well descriptorsImre Deak1-17/+7
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Allow platforms to share power well descriptorsImre Deak1-159/+122
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Simplify power well definitions by adding power well instancesImre Deak3-1124/+499
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Convert the u64 power well domains mask to a bitmapImre Deak6-88/+116
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 <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Convert the power well descriptor domain mask to an array of domainsImre Deak4-714/+783
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 <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Sanitize the power well namesImre Deak1-127/+127
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Rename the power domain names to end with pipes/portsImre Deak6-208/+208
Make all power domain names end with the pipe/port instance for consistency. No functional changes. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Move the HSW power well flags to a common bitfieldImre Deak3-103/+104
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Move the dg2 fixed_enable_delay power well param to a common bitfieldImre Deak3-15/+14
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Move the power domain->well mappings to intel_display_power_map.cImre Deak4-2257/+2168
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 <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Unexport the for_each_power_well() macrosImre Deak3-20/+20
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/i915: Move per-platform power well hooks to intel_display_power_well.cImre Deak6-1787/+1835
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 <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/solomon: Add SSD130x OLED displays SPI supportJavier Martinez Canillas3-0/+188
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 <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/solomon: Move device info from ssd130x-i2c to the core driverJavier Martinez Canillas3-45/+56
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 <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20drm/solomon: Add ssd130x new compatible strings and deprecate old ones.Javier Martinez Canillas1-1/+18
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 <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-04-20dt-bindings: display: ssd1307fb: Extend schema for SPI controllersJavier Martinez Canillas1-2/+40
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 <[email protected]> Acked-by: Mark Brown <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.