Re: [PATCH v7 03/12] dt-bindings: display/msm: add interconnects property to qcom,mdss-smd845
On 15/09/2022 15:37, Dmitry Baryshkov wrote:
> Add interconnects required for the SDM845 MDSS device tree node. This
> change was made in the commit c8c61c09e38b ("arm64: dts: qcom: sdm845:
> Add interconnects property for display"), but was not reflected in the
> schema.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH v7 04/12] dt-bindings: display/msm: move common DPU properties to dpu-common.yaml
On 15/09/2022 15:37, Dmitry Baryshkov wrote: > Move properties common to all DPU DT nodes to the dpu-common.yaml. > > Note, this removes description of individual DPU port@ nodes. However > such definitions add no additional value. The reg values do not > correspond to hardware INTF indices. The driver discovers and binds > these ports not paying any care for the order of these items. Thus just > leave the reference to graph.yaml#/properties/ports and the description. This is okay, but you loose required:ports@[01]. Best regards, Krzysztof
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 15/09/2022 15:37, Dmitry Baryshkov wrote: > Move properties common to all MDSS DT nodes to the mdss-common.yaml. > > This extends qcom,msm8998-mdss schema to allow interconnect nodes, which > will be added later, once msm8998 gains interconnect support. > > Signed-off-by: Dmitry Baryshkov > --- (...) > - "#interrupt-cells": > -const: 1 > - >iommus: > -items: > - - description: Phandle to apps_smmu node with SID mask for Hard-Fail > port0 > - - description: Phandle to apps_smmu node with SID mask for Hard-Fail > port1 > - > - ranges: true > +maxItems: 2 > >interconnects: > -items: > - - description: Interconnect path from mdp0 port to the data bus > - - description: Interconnect path from mdp1 port to the data bus > +maxItems: 2 I think this is not equivalent now, because you have in total minItems:1 and maxItems:2, while in past minItems was 2. The same might apply to iommus. clocks look good. Best regards, Krzysztof
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 15/09/2022 15:37, Dmitry Baryshkov wrote: > Move properties common to all MDSS DT nodes to the mdss-common.yaml. > > This extends qcom,msm8998-mdss schema to allow interconnect nodes, which > will be added later, once msm8998 gains interconnect support. > > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/display/msm/dpu-msm8998.yaml | 41 + > .../bindings/display/msm/dpu-qcm2290.yaml | 51 ++-- > .../bindings/display/msm/dpu-sc7180.yaml | 50 ++- > .../bindings/display/msm/dpu-sc7280.yaml | 50 ++- > .../bindings/display/msm/dpu-sdm845.yaml | 54 ++-- > .../bindings/display/msm/mdss-common.yaml | 83 +++ > 6 files changed, 111 insertions(+), 218 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/mdss-common.yaml > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > index 200eeace1c71..67791dbc3b5d 100644 > --- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > @@ -14,20 +14,13 @@ description: | >sub-blocks like DPU display controller, DSI and DP interfaces etc. Device > tree >bindings of MDSS and DPU are mentioned for MSM8998 target. > missing allOf > +$ref: /schemas/display/msm/mdss-common.yaml# > + > properties: Best regards, Krzysztof
Re: [PATCH v7 06/12] dt-bindings: display/msm: split dpu-sc7180 into DPU and MDSS parts
On 15/09/2022 15:37, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-sc7180 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
Thank you for your patch. There is something to discuss/improve.
> +---
> +$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Display DPU dt properties for SC7180 target
> +
> +maintainers:
> + - Krishna Manikandan
> +
missing allOf
> +$ref: /schemas/display/msm/dpu-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - const: qcom,sc7180-dpu
> +
> + reg:
> +items:
> + - description: Address offset and size for mdp register set
> + - description: Address offset and size for vbif register set
> +
> + reg-names:
> +items:
> + - const: mdp
> + - const: vbif
> +
> + clocks:
> +items:
> + - description: Display hf axi clock
> + - description: Display ahb clock
> + - description: Display rotator clock
> + - description: Display lut clock
> + - description: Display core clock
> + - description: Display vsync clock
> +
> + clock-names:
> +items:
> + - const: bus
> + - const: iface
> + - const: rot
> + - const: lut
> + - const: core
> + - const: vsync
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +display-controller@ae01000 {
> +compatible = "qcom,sc7180-dpu";
> +reg = <0x0ae01000 0x8f000>,
> + <0x0aeb 0x2008>;
> +
> +reg-names = "mdp", "vbif";
> +
> +clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_ROT_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> +clock-names = "bus", "iface", "rot", "lut", "core",
> + "vsync";
> +
> +interrupt-parent = <&mdss>;
> +interrupts = <0>;
> +power-domains = <&rpmhpd SC7180_CX>;
> +operating-points-v2 = <&mdp_opp_table>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +endpoint {
> +remote-endpoint = <&dsi0_in>;
> +};
> +};
> +
> +port@2 {
> +reg = <2>;
> +endpoint {
> +remote-endpoint = <&dp_in>;
> +};
> +};
> +};
> +};
> +...
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> new file mode 100644
> index ..e507c091b60f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-mdss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SC7180 Display MDSS
> +
> +maintainers:
> + - Krishna Manikandan
> +
> +description:
> + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that
> encapsulates
> + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device
> tree
> + bindings of MDSS are mentioned for SC7180 target.
> +
missing allOf.
> +$ref: /schemas/display/msm/mdss-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - const: qcom,sc7180-mdss
> +
> + clocks:
> +items:
> + - description: Display AHB clock from gcc
> + - description: Display AHB clock from dispcc
> + - description: Display core clock
> +
> + clock-names:
> +items:
> + - const: iface
> + - const: ahb
> + - const: core
> +
> + iommus:
> +maxItems: 1
> +
> + interconnects:
> +maxItems: 1
> +
> + interconnect-names:
> +maxItems: 1
> +
> +patternProperties:
> + "^display-controller@[0-9a-f]+$":
> +type: object
> +properties:
> + compatible:
> +const: qcom,sc7180-dpu
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +display-subsystem@ae0 {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +compatible = "qcom,sc7180-mdss";
> +reg = <0xae0 0x1000>;
> +reg-names = "mdss";
> +power-domains = <&dispcc MDSS_GDSC>;
> +clocks = <&gcc GCC_DISP_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>;
> +clock-names = "iface", "ahb", "core"
Re: [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On 9/21/2022 8:23 PM, Nilawar, Badal wrote:
On 21-09-2022 17:15, Gupta, Anshuman wrote:
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6:
- Fix review comments (Ashutosh)
- Update date, kernel version in documentation
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 6 +
4 files changed, 187 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index e2974f928e58..bc061238e35c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-devel@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit
in microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 45745afa5c5b..5183cf51a49b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to
hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock; /* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the
scaling
+ * of the field taken from the 32-bit register value might cause a
result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear = field_msk;
+ bits_to_set = FIELD_PREP(field_msk, nval);
+
+ hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
+
Re: [PATCH v7 11/12] dt-bindings: display/msm: add missing device nodes to mdss-* schemas
On 15/09/2022 15:37, Dmitry Baryshkov wrote: > Add missing device nodes (DSI, PHYs, DP/eDP) to the existing MDSS > schemas. > > Reviewed-by: Rob Herring > Signed-off-by: Dmitry Baryshkov > --- > .../display/msm/qcom,msm8998-mdss.yaml| 12 + > .../display/msm/qcom,qcm2290-mdss.yaml| 6 + > .../display/msm/qcom,sc7180-mdss.yaml | 18 + > .../display/msm/qcom,sc7280-mdss.yaml | 26 +++ > .../display/msm/qcom,sdm845-mdss.yaml | 12 + > 5 files changed, 74 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > index c2550cfb797e..f749821725b1 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,msm8998-mdss.yaml > @@ -43,6 +43,18 @@ patternProperties: >compatible: > const: qcom,msm8998-dpu > > + "^dsi@[0-9a-f]+$": > +type: object > +properties: > + compatible: > +const: qcom,mdss-dsi-ctrl > + > + "^phy@[0-9a-f]+$": > +type: object > +properties: > + compatible: > +const: qcom,dsi-phy-10nm-8998 > + > unevaluatedProperties: false Your example should also include them (unless it's removed on purpose?). Best regards, Krzysztof
Re: [PATCH v7 12/12] dt-bindings: display/msm: add support for the display on SM8250
On 15/09/2022 15:37, Dmitry Baryshkov wrote: > Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm > SM8250 platform. > > Signed-off-by: Dmitry Baryshkov > --- > .../bindings/display/msm/mdss-common.yaml | 4 +- > .../bindings/display/msm/qcom,sm8250-dpu.yaml | 92 > .../display/msm/qcom,sm8250-mdss.yaml | 103 ++ > 3 files changed, 197 insertions(+), 2 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml > > diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > index 2a476bd0215e..27d7242657b2 100644 > --- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > +++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml > @@ -27,11 +27,11 @@ properties: > >clocks: > minItems: 2 > -maxItems: 3 > +maxItems: 4 > >clock-names: > minItems: 2 > -maxItems: 3 > +maxItems: 4 > >interrupts: > maxItems: 1 > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml > new file mode 100644 > index ..9ff8a265c85f > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-dpu.yaml > @@ -0,0 +1,92 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/qcom,sm8250-dpu.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Qualcomm SM8250 Display DPU > + > +maintainers: > + - Dmitry Baryshkov > + > +$ref: /schemas/display/msm/dpu-common.yaml# Same problem as in other bindings. Best regards, Krzysztof
Re: [PATCH v1 01/17] dt-bindings: clk: mediatek: Add MT8195 DPI clocks
On 19/09/2022 18:55, Guillaume Ranquet wrote: > From: Pablo Sun > > Expand dt-bindings slot for VDOSYS1 of MT8195. > This clock is required by the DPI1 hardware > and is a downstream of the HDMI pixel clock. > > Signed-off-by: Pablo Sun > Signed-off-by: Guillaume Ranquet > Reviewed-by: Mattijs Korpershoek > Looks like broken patch. Best regards, Krzysztof
Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()
Am 22.09.22 um 05:10 schrieb Kees Cook: Hi, This series fixes up the cases where callers of ksize() use it to opportunistically grow their buffer sizes, which can run afoul of the __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE use to perform dynamic buffer bounds checking. Good cleanup, but one question: What other use cases we have for ksize() except the opportunistically growth of buffers? Of hand I can't see any. So when this patch set is about to clean up this use case it should probably also take care to remove ksize() or at least limit it so that it won't be used for this use case in the future. Regards, Christian. Quoting the first patch: In the effort to help the compiler reason about buffer sizes, the __alloc_size attribute was added to allocators. This improves the scope of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well, as the vast majority of callers are not expecting to use more memory than what they asked for. There is, however, one common exception to this: anticipatory resizing of kmalloc allocations. These cases all use ksize() to determine the actual bucket size of a given allocation (e.g. 128 when 126 was asked for). This comes in two styles in the kernel: 1) An allocation has been determined to be too small, and needs to be resized. Instead of the caller choosing its own next best size, it wants to minimize the number of calls to krealloc(), so it just uses ksize() plus some additional bytes, forcing the realloc into the next bucket size, from which it can learn how large it is now. For example: data = krealloc(data, ksize(data) + 1, gfp); data_len = ksize(data); 2) The minimum size of an allocation is calculated, but since it may grow in the future, just use all the space available in the chosen bucket immediately, to avoid needing to reallocate later. A good example of this is skbuff's allocators: data = kmalloc_reserve(size, gfp_mask, node, &pfmemalloc); ... /* kmalloc(size) might give us more room than requested. * Put skb_shared_info exactly at the end of allocated zone, * to allow max possible filling before reallocation. */ osize = ksize(data); size = SKB_WITH_OVERHEAD(osize); In both cases, the "how large is the allocation?" question is answered _after_ the allocation, where the compiler hinting is not in an easy place to make the association any more. This mismatch between the compiler's view of the buffer length and the code's intention about how much it is going to actually use has already caused problems[1]. It is possible to fix this by reordering the use of the "actual size" information. We can serve the needs of users of ksize() and still have accurate buffer length hinting for the compiler by doing the bucket size calculation _before_ the allocation. Code can instead ask "how large an allocation would I get for a given size?". Introduce kmalloc_size_roundup(), to serve this function so we can start replacing the "anticipatory resizing" uses of ksize(). [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FClangBuiltLinux%2Flinux%2Fissues%2F1599&data=05%7C01%7Cchristian.koenig%40amd.com%7C491e7c24ddc64e9e505b08da9c47fe36%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637994130356907320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=te%2BJ46%2B8L8oBTyGS3C7ueORFYI%2BhMRbfEoflVErr4k0%3D&reserved=0 https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F183&data=05%7C01%7Cchristian.koenig%40amd.com%7C491e7c24ddc64e9e505b08da9c47fe36%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637994130356907320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lrOCZN6EE%2BnDBA5DfOqteQt0nKCbJJ9bxlh2F13%2B3Es%3D&reserved=0 --- And after adding kmalloc_size_roundup(), put it to use with the various ksize() callers, restore the previously removed __alloc_size hint, and fix the use of __malloc annotations. I tried to trim the CC list on this series since it got rather long. I kept all the suggested mailing lists, though. :) Thanks! -Kees Kees Cook (12): slab: Introduce kmalloc_size_roundup() skbuff: Proactively round up to kmalloc bucket size net: ipa: Proactively round up to kmalloc bucket size btrfs: send: Proactively round up to kmalloc bucket size dma-buf: Proactively round up to kmalloc bucket size coredump: Proactively round up to kmalloc bucket size igb: Proactively round up to kmalloc bucket size openvswitch: Proactively round up to kmalloc bucket size x86/microcode/AMD: Track patch allocation size explicitly iwlwifi: Track scan_cmd allocation size explicitly slab: Remove __malloc attribut
Re: [PATCH v1 03/17] dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible
On 19/09/2022 18:56, Guillaume Ranquet wrote: > Add a compatible for the HDMI PHY on MT8195 > > Signed-off-by: Guillaume Ranquet The same... maybe it works, maybe not, I don't know. Any reason not using standard tools and producing standard patches? Best regards, Krzysztof
Re: [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 4 +
4 files changed, 129 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cc70596fff44..7995a885c9d6 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: September 2022
+KernelVersion: 6
+Contact: dri-devel@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: September 2022
KernelVersion:6
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index bd9ba312c474..7d85a81bc39b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
+ * - time - milliseconds
*/
#define SF_VOLTAGE1000
#define SF_POWER 100
#define SF_CURR 1000
#define SF_ENERGY 100
+#define SF_TIME1000
struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -161,6 +164,114 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
AFAIU we need to read r from PACKAGE_POWER_SKU reg untill unless it has
some known issue?
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ if (val > max_win)
+ return -EINVAL;
+
+ /* val in hw units */
+ val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
+ /* Convert to 1.x * power(2,y) */
+ if (!val)
+
Re: [PATCH 01/18] phy: mediatek: add a new helper to update bitfield
Il 22/09/22 04:36, Chunfeng Yun ha scritto:
On Wed, 2022-09-21 at 10:15 +0200, AngeloGioacchino Del Regno wrote:
Il 20/09/22 11:00, Chunfeng Yun ha scritto:
Due to FIELD_PREP() macro can be used to prepare a bitfield value,
local ones can be remove; add the new helper to make bitfield
update
easier.
Signed-off-by: Chunfeng Yun
---
drivers/phy/mediatek/phy-mtk-io.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/phy/mediatek/phy-mtk-io.h
b/drivers/phy/mediatek/phy-mtk-io.h
index 500fcdab165d..a723d4afc9b4 100644
--- a/drivers/phy/mediatek/phy-mtk-io.h
+++ b/drivers/phy/mediatek/phy-mtk-io.h
@@ -8,6 +8,7 @@
#ifndef __PHY_MTK_H__
#define __PHY_MTK_H__
+#include
#include
static inline void mtk_phy_clear_bits(void __iomem *reg, u32
bits)
@@ -35,4 +36,10 @@ static inline void mtk_phy_update_bits(void
__iomem *reg, u32 mask, u32 val)
writel(tmp, reg);
}
+/* field @mask should be constant and continuous */
"Field @mask shall be [...]"
^
Ok, will modify it
+static inline void mtk_phy_update_field(void __iomem *reg, u32
mask, u32 val)
...so, (void __iomem *reg, const u32 mask, u32 val)
Maybe no need const, @mask will be checked it in compile time when
use FIELD_PREP(), means @mask is a constant value, but not a variable.
Adding const is not *required*, but `mask` is, effectively, a constant, hence
it fully makes sense to add const.
Thanks
+{
+ mtk_phy_update_bits(reg, mask, FIELD_PREP(mask, val));
+}
+
#endif
Re: [PATCH v1 04/17] dt-bindings: display: mediatek: add MT8195 hdmi bindings
On 19/09/2022 18:56, Guillaume Ranquet wrote:
> Add mt8195 SoC bindings for hdmi and hdmi-ddc
>
> Make port1 optional for mt8195 as it only supports HDMI tx for now.
> Requires a ddc-i2c-bus phandle.
> Requires a power-domains phandle.
>
> Signed-off-by: Guillaume Ranquet
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> index bdaf0b51e68c..abb231a0694b 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> @@ -21,6 +21,10 @@ properties:
>- mediatek,mt7623-hdmi
>- mediatek,mt8167-hdmi
>- mediatek,mt8173-hdmi
> + - mediatek,mt8195-hdmi
> +
> + clocks: true
> + clock-names: true
Why is this moved?
>
>reg:
> maxItems: 1
> @@ -28,20 +32,6 @@ properties:
>interrupts:
> maxItems: 1
>
> - clocks:
> -items:
> - - description: Pixel Clock
> - - description: HDMI PLL
> - - description: Bit Clock
> - - description: S/PDIF Clock
> -
> - clock-names:
> -items:
> - - const: pixel
> - - const: pll
> - - const: bclk
> - - const: spdif
Clock definition with constraints should stay here. You just customize
it per variant.
> -
>phys:
> maxItems: 1
>
> @@ -58,6 +48,16 @@ properties:
> description: |
>phandle link and register offset to the system configuration registers.
>
> + ddc-i2c-bus:
> +$ref: '/schemas/types.yaml#/definitions/phandle'
Drop quotes
> +description: Phandle to the ddc-i2c device
Isn't this property of panel?
> +
> + power-domains:
> +description:
> + A phandle and PM domain specifier as defined by bindings
> + of the power controller specified by phandle. See
> + Documentation/devicetree/bindings/power/power-domain.yaml for details.
No need for this text. This is standard property. You miss maxItems.
> +
>ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> @@ -76,7 +76,6 @@ properties:
>
> required:
>- port@0
> - - port@1
>
> required:
>- compatible
> @@ -86,9 +85,55 @@ required:
>- clock-names
>- phys
>- phy-names
> - - mediatek,syscon-hdmi
>- ports
>
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: mediatek,mt8195-hdmi
> +then:
> + properties:
> +clocks:
> + items:
> +- description: APB
> +- description: HDCP
> +- description: HDCP 24M
> +- description: Split HDMI
> +clock-names:
> + items:
> +- const: hdmi_apb_sel
> +- const: hdcp_sel
> +- const: hdcp24_sel
> +- const: split_hdmi
Clocks are entirely different. I am not sure there is benefit in keeping
these devices in one bindings.
> +
> + required:
> +- power-domains
> +- ddc-i2c-bus
Blank line,
> +else:
> + properties:
> +clocks:
> + items:
> +- description: Pixel Clock
> +- description: HDMI PLL
> +- description: Bit Clock
> +- description: S/PDIF Clock
> +
> +clock-names:
> + items:
> +- const: pixel
> +- const: pll
> +- const: bclk
> +- const: spdif
> +
> +ports:
> + required:
> +- port@1
> +
> + required:
> +- mediatek,syscon-hdmi
> +
> additionalProperties: false
>
> examples:
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
>
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
> new file mode 100644
> index ..3c80bcebe6d3
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/display/mediatek/mediatek,mt8195-hdmi-ddc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek HDMI DDC Device Tree Bindings for mt8195
Drop Device Tree Bindings
> +
> +maintainers:
> + - CK Hu
> + - Jitao shi
> +
> +description: |
> + The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
Why is this different than existing ddc bindings?
> +
> +properties:
> + compatible:
> +enum:
> + - mediatek,mt8195-hdmi-ddc
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names:
> +items:
> + - const: ddc-i2c
> +
> +required:
> + - compatible
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +hdmiddc0: ddc_i2c {
No underscores in node names. Generic node names.
Best regards,
Re: [PATCH v1 06/17] dt-bindings: mediatek: set the hdmi to be compatible with syscon
On 19/09/2022 18:56, Guillaume Ranquet wrote: > In order to share register with a dedicated ddc driver, set the hdmi > compatible to syscon. > > Signed-off-by: Guillaume Ranquet > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > index abb231a0694b..86297b7eb7f7 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml > @@ -16,12 +16,14 @@ description: | > > properties: >compatible: > -enum: > - - mediatek,mt2701-hdmi > - - mediatek,mt7623-hdmi > - - mediatek,mt8167-hdmi > - - mediatek,mt8173-hdmi > - - mediatek,mt8195-hdmi > +items: > + - enum: > + - mediatek,mt2701-hdmi > + - mediatek,mt7623-hdmi > + - mediatek,mt8167-hdmi > + - mediatek,mt8173-hdmi > + - const: syscon So you just broke all DTS and I do not see patches fixing them... Best regards, Krzysztof
Re: [PATCH v1 15/17] dt-bindings: display: mediatek: dpi: Add compatible for MediaTek MT8195
On 19/09/2022 18:56, Guillaume Ranquet wrote: > Add dt-binding documentation of dpi for MediaTek MT8195 SoC. > > Signed-off-by: Guillaume Ranquet > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml > index 5bb23e97cf33..2c7ecef54986 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml > @@ -24,6 +24,7 @@ properties: >- mediatek,mt8183-dpi >- mediatek,mt8186-dpi >- mediatek,mt8192-dpi > + - mediatek,mt8195-dpi >- mediatek,mt8195-dp-intf Aren't these the same? Best regards, Krzysztof
Re: [PATCH v1 17/17] drm/mediatek: Add mt8195-dpi support to drm_drv
On 19/09/2022 18:56, Guillaume Ranquet wrote:
> Add dpi support to enable the HDMI path.
>
> Signed-off-by: Guillaume Ranquet
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 72049a530ae1..27f029ca760b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -820,6 +820,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8192-dpi",
> .data = (void *)MTK_DPI },
> + { .compatible = "mediatek,mt8195-dpi",
> + .data = (void *)MTK_DPI },
It's compatible with the others. You don't need more compatibles.
Best regards,
Krzysztof
Re: [PATCH v1 16/17] drm/mediatek: dpi: Add mt8195 hdmi to DPI driver
On 19/09/2022 18:56, Guillaume Ranquet wrote: > Add the DPI1 hdmi path support in mtk dpi driver > > Signed-off-by: Guillaume Ranquet > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c > b/drivers/gpu/drm/mediatek/mtk_dpi.c > index 630a4e301ef6..91212b7610e8 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c > @@ -15,7 +15,10 @@ > #include > #include > #include > +#include > #include > +#include > +#include Why do you need these headers in this patch? Best regards, Krzysztof
[PATCH v1] drivers:adp8870_bl: check the return value of adp8870_write
Check and propagate the return value of adp8870_write() when it fails,
which is possible when SMBus writing byte fails.
Signed-off-by: Li Zhong
---
drivers/video/backlight/adp8870_bl.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 8b5213a39527..0eb4ae2ff592 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -567,9 +567,13 @@ static ssize_t adp8870_store(struct device *dev, const
char *buf,
return ret;
mutex_lock(&data->lock);
- adp8870_write(data->client, reg, val);
+ ret = adp8870_write(data->client, reg, val);
mutex_unlock(&data->lock);
+ if (ret) {
+ return ret;
+ }
+
return count;
}
--
2.25.1
[PATCH v2] drivers/amd/pm: check the return value of amdgpu_bo_kmap
amdgpu_bo_kmap() returns error when fails to map buffer object. Add the
error check and propagate the error.
Signed-off-by: Li Zhong
---
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
index 1eb4e613b27a..ec055858eb95 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
@@ -1485,6 +1485,7 @@ static int pp_get_prv_buffer_details(void *handle, void
**addr, size_t *size)
{
struct pp_hwmgr *hwmgr = handle;
struct amdgpu_device *adev = hwmgr->adev;
+ int err;
if (!addr || !size)
return -EINVAL;
@@ -1492,7 +1493,9 @@ static int pp_get_prv_buffer_details(void *handle, void
**addr, size_t *size)
*addr = NULL;
*size = 0;
if (adev->pm.smu_prv_buffer) {
- amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
+ err = amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
+ if (err)
+ return err;
*size = adev->pm.smu_prv_buffer_size;
}
--
2.25.1
[PATCH -next] video: fbdev: tridentfb: Fix missing pci_disable_device() in probe and remove
Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() and pci_release_regions() will be called in release automatically. Signed-off-by: ruanjinjie --- drivers/video/fbdev/tridentfb.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c index f9c3b1d38fc2..7933e01aacc5 100644 --- a/drivers/video/fbdev/tridentfb.c +++ b/drivers/video/fbdev/tridentfb.c @@ -1475,7 +1475,7 @@ static int trident_pci_probe(struct pci_dev *dev, if (err) return err; - err = pci_enable_device(dev); + err = pcim_enable_device(dev); if (err) return err; @@ -1715,12 +1715,10 @@ static int trident_pci_probe(struct pci_dev *dev, kfree(info->pixmap.addr); if (info->screen_base) iounmap(info->screen_base); - release_mem_region(tridentfb_fix.smem_start, tridentfb_fix.smem_len); disable_mmio(info->par); out_unmap1: if (default_par->io_virt) iounmap(default_par->io_virt); - release_mem_region(tridentfb_fix.mmio_start, tridentfb_fix.mmio_len); framebuffer_release(info); return err; } @@ -1735,8 +1733,6 @@ static void trident_pci_remove(struct pci_dev *dev) i2c_del_adapter(&par->ddc_adapter); iounmap(par->io_virt); iounmap(info->screen_base); - release_mem_region(tridentfb_fix.smem_start, tridentfb_fix.smem_len); - release_mem_region(tridentfb_fix.mmio_start, tridentfb_fix.mmio_len); kfree(info->pixmap.addr); fb_dealloc_cmap(&info->cmap); framebuffer_release(info); -- 2.25.1
Re: [PATCH v1] drivers:amdgpu: check the return value of amdgpu_bo_kmap
On Wed, Sep 21, 2022 at 7:11 PM Chen, Guchun wrote:
>
> Perhaps you need to update the prefix of patch subject to 'drm/amd/pm: check
> return value ...'.
>
> With above addressed, it's: Acked-by: Guchun Chen
>
> Regards,
> Guchun
>
> -Original Message-
> From: Li Zhong
> Sent: Thursday, September 22, 2022 9:27 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: jiapeng.ch...@linux.alibaba.com; Powell, Darren ;
> Chen, Guchun ; Limonciello, Mario
> ; Quan, Evan ; Lazar, Lijo
> ; dan...@ffwll.ch; airl...@linux.ie; Pan, Xinhui
> ; Koenig, Christian ; Deucher,
> Alexander ; Li Zhong
> Subject: [PATCH v1] drivers:amdgpu: check the return value of amdgpu_bo_kmap
>
> amdgpu_bo_kmap() returns error when fails to map buffer object. Add the error
> check and propagate the error.
>
> Signed-off-by: Li Zhong
> ---
> drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> index 1eb4e613b27a..ec055858eb95 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> @@ -1485,6 +1485,7 @@ static int pp_get_prv_buffer_details(void *handle, void
> **addr, size_t *size) {
> struct pp_hwmgr *hwmgr = handle;
> struct amdgpu_device *adev = hwmgr->adev;
> + int err;
>
> if (!addr || !size)
> return -EINVAL;
> @@ -1492,7 +1493,9 @@ static int pp_get_prv_buffer_details(void *handle, void
> **addr, size_t *size)
> *addr = NULL;
> *size = 0;
> if (adev->pm.smu_prv_buffer) {
> - amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
> + err = amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
> + if (err)
> + return err;
> *size = adev->pm.smu_prv_buffer_size;
> }
>
> --
> 2.25.1
>
Thanks for your reply! It's updated in the v2 patch.
Re: [PATCH v1 11/17] drm/mediatek: hdmi: add mt8195 support
On 19/09/2022 18:56, Guillaume Ranquet wrote:
> Adds hdmi and hdmi-ddc support for mt8195.
>
> Signed-off-by: Guillaume Ranquet
> +static int mtk_hdmi_ddc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mtk_hdmi_ddc *ddc;
> + int ret;
> +
> + ddc = devm_kzalloc(dev, sizeof(struct mtk_hdmi_ddc), GFP_KERNEL);
> + if (!ddc)
> + return -ENOMEM;
> +
> + ddc->regs = syscon_regmap_lookup_by_compatible("mediatek,mt8195-hdmi");
That's not how you get regmaps. If you the driver grows, are you going
to grow the list to e.g. 10 syscon_regmap_lookup_by_compatible() calls?
This has to be by phandle.
Best regards,
Krzysztof
[PATCH v1] drivers:amdgpu: check the return value of amdgpu_bo_kmap
amdgpu_bo_kmap() returns error when fails to map buffer object. Add the
error check and propagate the error.
Signed-off-by: Li Zhong
---
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
index 1eb4e613b27a..ec055858eb95 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
@@ -1485,6 +1485,7 @@ static int pp_get_prv_buffer_details(void *handle, void
**addr, size_t *size)
{
struct pp_hwmgr *hwmgr = handle;
struct amdgpu_device *adev = hwmgr->adev;
+ int err;
if (!addr || !size)
return -EINVAL;
@@ -1492,7 +1493,9 @@ static int pp_get_prv_buffer_details(void *handle, void
**addr, size_t *size)
*addr = NULL;
*size = 0;
if (adev->pm.smu_prv_buffer) {
- amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
+ err = amdgpu_bo_kmap(adev->pm.smu_prv_buffer, addr);
+ if (err)
+ return err;
*size = adev->pm.smu_prv_buffer_size;
}
--
2.25.1
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
On Thu, Sep 22, 2022 at 08:42:23AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 21.09.22 um 18:48 schrieb Geert Uytterhoeven:
> > Hi Thomas,
> >
> > On Wed, Sep 21, 2022 at 2:55 PM Thomas Zimmermann
> > wrote:
> > > Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
> > > > On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
> > > > > +#if !defined(CONFIG_PPC)
> > > > > +static inline void out_8(void __iomem *addr, int val)
> > > > > +{ }
> > > > > +static inline void out_le32(void __iomem *addr, int val)
> > > > > +{ }
> > > > > +static inline unsigned int in_le32(const void __iomem *addr)
> > > > > +{
> > > > > + return 0;
> > > > > +}
> > > > > +#endif
> > > >
> > > > These guys could just be replaced with readb/writel/readl respectively
> > > > (beware of the argument swap).
> > >
> > > I only added them for COMPILE_TEST. There appears to be no portable
> > > interface that implements out_le32() and in_le32()?
> >
> > iowrite32() and ioread32()?
>
> Do they always use little endian, as these *_le32 helpers do? I though they
> use host byte order.
They use either outl or writel under the hood, which are always little-endian
Maxime
signature.asc
Description: PGP signature
[PATCH v7,0/3] Add dpi output format control for MT8186
From: Xinlei Lee Base on the branch of ck-linux-next/mediatek-drm-fixes. Changes since v6: 1. Different from other ICs, when mt8186 DPI changes the output format, the mmsys_base+400 register needs to be set to be valid at the same time. In this series, all the situations that mmsys need to be set up are perfected (not necessarily used in practice). 2. Put the value that controls the mmsys function in mtk-mmsys.h. 3. Encountered the sink ic switched between dual edge and single edge, perfected setting and clearing mmsys bit operations in mtk_dpi.c. Changes since v5: 1. Separate the patch that adds edge_cfg_in_mmsys from the patch that adds mt8186 dpi support. 2. Move the mmsys register definition to mmsys driver. Changes since v4: 1. This series of cancellations is based on the following patches: [1] Add MediaTek SoC(vdosys1) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/cover/20220711075245.10492-1-nancy@mediatek.com/ [2] Add MediaTek SoC DRM (vdosys1) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/cover/20220804072827.22383-1-nancy@mediatek.com/ 2. Added mtk_mmsys_update_bits function in mtk-mmsys.c; 3. MMSYS 0x400 register is modified to MT8186_MMSYS_DPI_OUTPUT_FORMAT; 4. Fix formatting issues. Changes since v3: 1. Fix formatting issues; 2. Modify the edge output control name & description; 3. Fix the threading problem. Changes since v2: 1. Modify key nouns in the description; 2. Add the label of jitao to Co-developed-by; 3. Macro definition address lowercase problem and function naming; 4. Add missing a description of this property in the mtk_dpi_conf. Change since v1: 1. Modify mt8186 compatiable location. 2. Modify MT8186_DPI_OUTPUT_FORMAT name. When MT8186 outputs dpi signal, it is necessary to add dual edge output format control in mmsys. Xinlei Lee (3): soc: mediatek: Add mmsys func to adapt to dpi output for MT8186 drm: mediatek: Adjust the dpi output format to MT8186 drm: mediatek: Add mt8186 dpi compatible to mtk_dpi.c drivers/gpu/drm/mediatek/mtk_dpi.c | 32 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ drivers/soc/mediatek/mt8186-mmsys.h| 8 +++ drivers/soc/mediatek/mtk-mmsys.c | 32 ++ include/linux/soc/mediatek/mtk-mmsys.h | 9 5 files changed, 83 insertions(+) -- 2.18.0
[PATCH v7,3/3] drm: mediatek: Add mt8186 dpi compatible to
From: Xinlei Lee
Add the compatible because use edge_cfg_in_mmsys in mt8186.
Signed-off-by: Xinlei Lee
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bd1870a8504a..2fcf7a61c340 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -941,6 +941,24 @@ static const struct mtk_dpi_conf mt8183_conf = {
.csc_enable_bit = CSC_ENABLE,
};
+static const struct mtk_dpi_conf mt8186_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+ .max_clock_khz = 15,
+ .output_fmts = mt8183_output_fmts,
+ .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+ .edge_cfg_in_mmsys = true,
+ .pixels_per_iter = 1,
+ .is_ck_de_pol = true,
+ .swap_input_support = true,
+ .support_direct_pin = true,
+ .dimension_mask = HPW_MASK,
+ .hvsize_mask = HSIZE_MASK,
+ .channel_swap_shift = CH_SWAP,
+ .yuv422_en_bit = YUV422_EN,
+ .csc_enable_bit = CSC_ENABLE,
+};
+
static const struct mtk_dpi_conf mt8192_conf = {
.cal_factor = mt8183_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -1091,6 +1109,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8183-dpi",
.data = &mt8183_conf,
},
+ { .compatible = "mediatek,mt8186-dpi",
+ .data = &mt8186_conf,
+ },
{ .compatible = "mediatek,mt8192-dpi",
.data = &mt8192_conf,
},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 546b79412815..3d32fbc66ac1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -646,6 +646,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8183-dpi",
.data = (void *)MTK_DPI },
+ { .compatible = "mediatek,mt8186-dpi",
+ .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8192-dpi",
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8195-dp-intf",
--
2.18.0
[PATCH v7,2/3] drm: mediatek: Adjust the dpi output format to MT8186
From: Xinlei Lee
Due to the mt8186 hardware changes, we need to modify the dpi output
format corresponding to the mmsys register(mmsys_base+0x400).
Because different sink ICs may support other output formats.
The current DRM architecture supports retrieving the output format of
all bridges (eg dpi is implemented via DRM's .atomic_check and
.atomic_get_output_bus_fmts and .atomic_get_input_bus_fmts).
If no unified output format is found, the default soc format
(MEDIA_BUS_FMT_RGB888_2X12_LE in mt8186) is used.
Therefore, if there are other format sink ICs (RGB888_DDR/RGB888_SDR) in
the future, the sink IC needs to add the func implementation mentioned
above needs to be added.
And the drm architecture will select the appropriate format to change
the dpi output.
Co-developed-by: Jitao Shi
Signed-off-by: Jitao Shi
Signed-off-by: Xinlei Lee
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 630a4e301ef6..bd1870a8504a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,6 +31,7 @@
#include "mtk_disp_drv.h"
#include "mtk_dpi_regs.h"
#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
enum mtk_dpi_out_bit_num {
MTK_DPI_OUT_BIT_NUM_8BITS,
@@ -82,6 +84,7 @@ struct mtk_dpi {
struct pinctrl_state *pins_dpi;
u32 output_fmt;
int refcount;
+ struct device *mmsys_dev;
};
static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
@@ -135,6 +138,7 @@ struct mtk_dpi_yc_limit {
* @yuv422_en_bit: Enable bit of yuv422.
* @csc_enable_bit: Enable bit of CSC.
* @pixels_per_iter: Quantity of transferred pixels per iteration.
+ * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be
set in MMSYS.
*/
struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -153,6 +157,7 @@ struct mtk_dpi_conf {
u32 yuv422_en_bit;
u32 csc_enable_bit;
u32 pixels_per_iter;
+ bool edge_cfg_in_mmsys;
};
static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -449,8 +454,12 @@ static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE ?
EDGE_SEL : 0, EDGE_SEL);
+ if (dpi->conf->edge_cfg_in_mmsys)
+ mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
MTK_DPI_RGB888_DDR_CON);
} else {
mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE, 0);
+ if (dpi->conf->edge_cfg_in_mmsys)
+ mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
MTK_DPI_RGB888_SDR_CON);
}
}
@@ -778,8 +787,10 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
{
struct mtk_dpi *dpi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ struct mtk_drm_private *priv = drm_dev->dev_private;
int ret;
+ dpi->mmsys_dev = priv->mmsys_dev;
ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
DRM_MODE_ENCODER_TMDS);
if (ret) {
--
2.18.0
[PATCH v7, 1/3] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
From: Xinlei Lee
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect.
So when setting the dpi output format, we need to call mmsys_func to set
it to MT8186 synchronously.
Co-developed-by: Jitao Shi
Signed-off-by: Jitao Shi
Signed-off-by: Xinlei Lee
---
drivers/soc/mediatek/mt8186-mmsys.h| 8 +++
drivers/soc/mediatek/mtk-mmsys.c | 32 ++
include/linux/soc/mediatek/mtk-mmsys.h | 9
3 files changed, 49 insertions(+)
diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
b/drivers/soc/mediatek/mt8186-mmsys.h
index eb1ad9c37a9c..536005d1cc55 100644
--- a/drivers/soc/mediatek/mt8186-mmsys.h
+++ b/drivers/soc/mediatek/mt8186-mmsys.h
@@ -3,6 +3,14 @@
#ifndef __SOC_MEDIATEK_MT8186_MMSYS_H
#define __SOC_MEDIATEK_MT8186_MMSYS_H
+/* Values for DPI configuration in MMSYS address space */
+#define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
+#define DPI_FORMAT_MASK0x3
+#define DPI_RGB888_SDR_CON 0
+#define DPI_RGB888_DDR_CON 1
+#define DPI_RGB565_SDR_CON 2
+#define DPI_RGB565_DDR_CON 3
+
#define MT8186_MMSYS_OVL_CON 0xF04
#define MT8186_MMSYS_OVL0_CON_MASK 0x3
#define MT8186_MMSYS_OVL0_2L_CON_MASK 0xC
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 06d8e83a2cb5..0857806206dc 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -227,6 +227,38 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
}
EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
+static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32 offset, u32
mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl_relaxed(mmsys->regs + offset);
+ tmp = (tmp & ~mask) | val;
+ writel_relaxed(tmp, mmsys->regs + offset);
+}
+
+void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
+{
+ switch (val) {
+ case MTK_DPI_RGB888_DDR_CON:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+ break;
+ case MTK_DPI_RGB565_SDR_CON:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_SDR_CON);
+ break;
+ case MTK_DPI_RGB565_DDR_CON:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_DDR_CON);
+ break;
+ default:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+ break;
+ }
+}
+EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
+
static int mtk_mmsys_reset_update(struct reset_controller_dev *rcdev, unsigned
long id,
bool assert)
{
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 59117d970daf..b85f66db33e1 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,13 @@
enum mtk_ddp_comp_id;
struct device;
+enum mtk_dpi_out_format_con {
+ MTK_DPI_RGB888_SDR_CON,
+ MTK_DPI_RGB888_DDR_CON,
+ MTK_DPI_RGB565_SDR_CON,
+ MTK_DPI_RGB565_DDR_CON
+};
+
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL0,
DDP_COMPONENT_AAL1,
@@ -65,4 +72,6 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next);
+void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val);
+
#endif /* __MTK_MMSYS_H */
--
2.18.0
Re: [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fixed review comments (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7995a885c9d6..851525d2117d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: September 2022
KernelVersion:6
Contact: dri-devel@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 65336514554d..3c385395aaef 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1591,4 +1591,9 @@
*/
#define MTL_MEDIA_GSI_BASE0x38
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
Keep these before MTL_MEDIA_GSI_BASE to mainitain proper numeric order?
other then that patch looks good to me.
Reviewed-by: Anshuman Gupta
Br,
Anshuman.
+
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7d85a81bc39b..4a4aec1c67ab 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
mutex_lock(&hwmon->hwmon_lock);
@@ -280,6 +287,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -409,7 +421,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -544,6 +559,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
+ default:
+
Re: [PATCH v7 04/12] dt-bindings: display/msm: move common DPU properties to dpu-common.yaml
On Thu, 22 Sept 2022 at 10:02, Krzysztof Kozlowski wrote: > > On 15/09/2022 15:37, Dmitry Baryshkov wrote: > > Move properties common to all DPU DT nodes to the dpu-common.yaml. > > > > Note, this removes description of individual DPU port@ nodes. However > > such definitions add no additional value. The reg values do not > > correspond to hardware INTF indices. The driver discovers and binds > > these ports not paying any care for the order of these items. Thus just > > leave the reference to graph.yaml#/properties/ports and the description. > > This is okay, but you loose required:ports@[01]. This is fine for me. The ports do not have 1:1 correspondence to intfs. Usually platforms add ports as new sinks are added. For example a platform can start with a single DSI node and later get second DSI, DP, eDP, etc. as they are receiving support/required by end-user devices. -- With best wishes Dmitry
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On Thu, 22 Sept 2022 at 10:05, Krzysztof Kozlowski wrote: > > On 15/09/2022 15:37, Dmitry Baryshkov wrote: > > Move properties common to all MDSS DT nodes to the mdss-common.yaml. > > > > This extends qcom,msm8998-mdss schema to allow interconnect nodes, which > > will be added later, once msm8998 gains interconnect support. > > > > Signed-off-by: Dmitry Baryshkov > > --- > > .../bindings/display/msm/dpu-msm8998.yaml | 41 + > > .../bindings/display/msm/dpu-qcm2290.yaml | 51 ++-- > > .../bindings/display/msm/dpu-sc7180.yaml | 50 ++- > > .../bindings/display/msm/dpu-sc7280.yaml | 50 ++- > > .../bindings/display/msm/dpu-sdm845.yaml | 54 ++-- > > .../bindings/display/msm/mdss-common.yaml | 83 +++ > > 6 files changed, 111 insertions(+), 218 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/msm/mdss-common.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > > b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > > index 200eeace1c71..67791dbc3b5d 100644 > > --- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > > +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml > > @@ -14,20 +14,13 @@ description: | > >sub-blocks like DPU display controller, DSI and DP interfaces etc. > > Device tree > >bindings of MDSS and DPU are mentioned for MSM8998 target. > > > > missing allOf Rob asked to remove this while reviewing v6 ([1]). And indeed the allOf's around a single $ref do not seem to be necessary > > > +$ref: /schemas/display/msm/mdss-common.yaml# > > + > > properties: [1] https://lore.kernel.org/dri-devel/20220907195904.ga98468-r...@kernel.org/ -- With best wishes Dmitry
Re: [PATCH v7,3/3] drm: mediatek: Add mt8186 dpi compatible to
Il 22/09/22 09:29, xinlei@mediatek.com ha scritto: From: Xinlei Lee Add the compatible because use edge_cfg_in_mmsys in mt8186. Signed-off-by: Xinlei Lee Please fix the commit title. drm: mediatek: Add mt8186 dpi compatibles and platform data
Re: [PATCH v7,1/3] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
On Thu, 2022-09-22 at 15:29 +0800, xinlei@mediatek.com wrote:
> From: Xinlei Lee
>
> The difference between MT8186 and other ICs is that when modifying
> the
> output format, we need to modify the mmsys_base+0x400 register to
> take
> effect.
> So when setting the dpi output format, we need to call mmsys_func to
> set
> it to MT8186 synchronously.
>
> Co-developed-by: Jitao Shi
> Signed-off-by: Jitao Shi
> Signed-off-by: Xinlei Lee
> ---
> drivers/soc/mediatek/mt8186-mmsys.h| 8 +++
> drivers/soc/mediatek/mtk-mmsys.c | 32
> ++
> include/linux/soc/mediatek/mtk-mmsys.h | 9
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
> b/drivers/soc/mediatek/mt8186-mmsys.h
> index eb1ad9c37a9c..536005d1cc55 100644
> --- a/drivers/soc/mediatek/mt8186-mmsys.h
> +++ b/drivers/soc/mediatek/mt8186-mmsys.h
> @@ -3,6 +3,14 @@
> #ifndef __SOC_MEDIATEK_MT8186_MMSYS_H
> #define __SOC_MEDIATEK_MT8186_MMSYS_H
>
> +/* Values for DPI configuration in MMSYS address space */
> +#define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
> +#define DPI_FORMAT_MASK 0x3
> +#define DPI_RGB888_SDR_CON 0
> +#define DPI_RGB888_DDR_CON 1
> +#define DPI_RGB565_SDR_CON 2
> +#define DPI_RGB565_DDR_CON 3
> +
> #define MT8186_MMSYS_OVL_CON 0xF04
> #define MT8186_MMSYS_OVL0_CON_MASK 0x3
> #define MT8186_MMSYS_OVL0_2L_CON_MASK0xC
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index 06d8e83a2cb5..0857806206dc 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -227,6 +227,38 @@ void mtk_mmsys_ddp_disconnect(struct device
> *dev,
> }
> EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
>
> +static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32
> offset, u32 mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp = readl_relaxed(mmsys->regs + offset);
> + tmp = (tmp & ~mask) | val;
> + writel_relaxed(tmp, mmsys->regs + offset);
> +}
> +
> +void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
> +{
> + switch (val) {
> + case MTK_DPI_RGB888_DDR_CON:
> + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> + DPI_FORMAT_MASK,
> DPI_RGB888_DDR_CON);
> + break;
> + case MTK_DPI_RGB565_SDR_CON:
> + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> + DPI_FORMAT_MASK,
> DPI_RGB565_SDR_CON);
> + break;
> + case MTK_DPI_RGB565_DDR_CON:
> + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> + DPI_FORMAT_MASK,
> DPI_RGB565_DDR_CON);
> + break;
> + default:
> + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> + DPI_FORMAT_MASK,
> DPI_RGB888_DDR_CON);
> + break;
> + }
> +}
> +EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
> +
> static int mtk_mmsys_reset_update(struct reset_controller_dev
> *rcdev, unsigned long id,
> bool assert)
> {
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 59117d970daf..b85f66db33e1 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -9,6 +9,13 @@
> enum mtk_ddp_comp_id;
> struct device;
>
> +enum mtk_dpi_out_format_con {
> + MTK_DPI_RGB888_SDR_CON,
> + MTK_DPI_RGB888_DDR_CON,
> + MTK_DPI_RGB565_SDR_CON,
> + MTK_DPI_RGB565_DDR_CON
> +};
> +
> enum mtk_ddp_comp_id {
> DDP_COMPONENT_AAL0,
> DDP_COMPONENT_AAL1,
> @@ -65,4 +72,6 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next);
>
> +void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val);
> +
> #endif /* __MTK_MMSYS_H */
Hi matthias:
Sorry I didn't notice that this one has been applied in the v6
version.
I will submit a diff patch based on the v6 patch later.
Best Regards!
Xineli
Re: [PATCH v2 10/10] drm/ofdrm: Support color management
Hi
Am 22.09.22 um 09:28 schrieb Maxime Ripard:
On Thu, Sep 22, 2022 at 08:42:23AM +0200, Thomas Zimmermann wrote:
Hi
Am 21.09.22 um 18:48 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, Sep 21, 2022 at 2:55 PM Thomas Zimmermann wrote:
Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
+#if !defined(CONFIG_PPC)
+static inline void out_8(void __iomem *addr, int val)
+{ }
+static inline void out_le32(void __iomem *addr, int val)
+{ }
+static inline unsigned int in_le32(const void __iomem *addr)
+{
+ return 0;
+}
+#endif
These guys could just be replaced with readb/writel/readl respectively
(beware of the argument swap).
I only added them for COMPILE_TEST. There appears to be no portable
interface that implements out_le32() and in_le32()?
iowrite32() and ioread32()?
Do they always use little endian, as these *_le32 helpers do? I though they
use host byte order.
They use either outl or writel under the hood, which are always little-endian
I see. I'll replace the custom helpers.
Best regards
Thomas
Maxime
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
On 21/09/2022 19:00, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
I can't spot that you are adding any code which would need this?
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.
This include should have been added in a later patch for calling
i915_gem_vm_lookup(). But got added here while patch refactoring.
Will fix.
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region
**placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the
regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements
passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct
intel_memory_region **placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct
drm_i915_private *i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements,
n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
Because of the changes above this path is now unreachable. I suppose
it was meant to tell the user "you have supplied no placements"? But
then GEM_BUG_ON (which you remove) used to be wrong.
Yah, looks like an existing problem. May be this "size == 0" check
should have been made before we do the round_up()? ie., check input 'size'
paramter is not 0?
I think for now, I will remove this check as it was unreachable anyhow.
Hm that's true as well. i915_gem_create_ext_ioctl ensures at least one
placement and internal callers do as well.
To be safe, instead of removing maybe move to before "size = " and
change to "if (GEM_WARN_ON(n_placements == 0))"? Not sure.. Matt any
thoughts here given the changes in this patch?
Regards,
Tvrtko
Niranjana
Regards,
Tvrtko
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..8c97bddad921 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,8 @@ static inline bool i915_gem_object_size_2big(u64 size)
}
void i915_gem_init__objects(struct drm_i915_private *i915);
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements);
void i915_objects_module_exit(void);
int i915_objects_module_init(void);
Re: [Intel-gfx] [PATCH] drm/i915: Noop lrc_init_wa_ctx() on recent/future platforms
On 07.09.2022 16:08, Lucas De Marchi wrote:
> Except for graphics version 8 and 9, nothing is done in
> lrc_init_wa_ctx(). Assume this won't be needed on future platforms as
> well and remove the warning.
>
> Note that this function is not called for anything below version 8 since
> those don't use either guc or execlist, i.e. HAS_EXECLISTS() is false.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
Reviewed-by: Balasubramani Vivekanandan
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 070cec4ff8a4..43fa7b3422c4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1695,24 +1695,16 @@ void lrc_init_wa_ctx(struct intel_engine_cs *engine)
> unsigned int i;
> int err;
>
> - if (!(engine->flags & I915_ENGINE_HAS_RCS_REG_STATE))
> + if (GRAPHICS_VER(engine->i915) >= 11 ||
> + !(engine->flags & I915_ENGINE_HAS_RCS_REG_STATE))
> return;
>
> - switch (GRAPHICS_VER(engine->i915)) {
> - case 12:
> - case 11:
> - return;
> - case 9:
> + if (GRAPHICS_VER(engine->i915) == 9) {
> wa_bb_fn[0] = gen9_init_indirectctx_bb;
> wa_bb_fn[1] = NULL;
> - break;
> - case 8:
> + } else if (GRAPHICS_VER(engine->i915) == 8) {
> wa_bb_fn[0] = gen8_init_indirectctx_bb;
> wa_bb_fn[1] = NULL;
> - break;
> - default:
> - MISSING_CASE(GRAPHICS_VER(engine->i915));
> - return;
> }
>
> err = lrc_create_wa_ctx(engine);
> --
> 2.37.2
>
Re: [PATCH v7,1/3] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
Il 22/09/22 09:29, xinlei@mediatek.com ha scritto:
From: Xinlei Lee
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect.
So when setting the dpi output format, we need to call mmsys_func to set
it to MT8186 synchronously.
Co-developed-by: Jitao Shi
Signed-off-by: Jitao Shi
Signed-off-by: Xinlei Lee
---
drivers/soc/mediatek/mt8186-mmsys.h| 8 +++
drivers/soc/mediatek/mtk-mmsys.c | 32 ++
include/linux/soc/mediatek/mtk-mmsys.h | 9
3 files changed, 49 insertions(+)
diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
b/drivers/soc/mediatek/mt8186-mmsys.h
index eb1ad9c37a9c..536005d1cc55 100644
--- a/drivers/soc/mediatek/mt8186-mmsys.h
+++ b/drivers/soc/mediatek/mt8186-mmsys.h
@@ -3,6 +3,14 @@
#ifndef __SOC_MEDIATEK_MT8186_MMSYS_H
#define __SOC_MEDIATEK_MT8186_MMSYS_H
+/* Values for DPI configuration in MMSYS address space */
+#define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
+#define DPI_FORMAT_MASK0x3
This is GENMASK(1, 0)
+#define DPI_RGB888_SDR_CON 0
+#define DPI_RGB888_DDR_CON 1
+#define DPI_RGB565_SDR_CON 2
+#define DPI_RGB565_DDR_CON 3
+
#define MT8186_MMSYS_OVL_CON 0xF04
#define MT8186_MMSYS_OVL0_CON_MASK0x3
#define MT8186_MMSYS_OVL0_2L_CON_MASK 0xC
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 06d8e83a2cb5..0857806206dc 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -227,6 +227,38 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
}
EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
+static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32 offset, u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl_relaxed(mmsys->regs + offset);
+ tmp = (tmp & ~mask) | val;
+ writel_relaxed(tmp, mmsys->regs + offset);
+}
+
+void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
+{
+ switch (val) {
You're not handling the MTK_DPI_RGB888_SDR_CON case.
+ case MTK_DPI_RGB888_DDR_CON: > +
mtk_mmsys_update_bits(dev_get_drvdata(dev), MT8186_MMSYS_DPI_OUTPUT_FORMAT,
Are there any other (future, past, present) MTK SoCs having a MMSYS
DPI_OUTPUT_FORMAT register?
I don't like seeing this kind of model-agnostic function in a not model-agnostic
driver, especially when this is only because of a register address.
That would change if no other future (or present) MediaTek SoCs have this
register.
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+ break;
+ case MTK_DPI_RGB565_SDR_CON:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_SDR_CON);
+ break;
+ case MTK_DPI_RGB565_DDR_CON:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_DDR_CON);
+ break;
This goes here...
case MTK_DPI_RGB888_DDR_CON:
+ default:
+ mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+ break;
+ }
+}
+EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
+
static int mtk_mmsys_reset_update(struct reset_controller_dev *rcdev,
unsigned long id,
bool assert)
{
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 59117d970daf..b85f66db33e1 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,13 @@
enum mtk_ddp_comp_id;
struct device;
+enum mtk_dpi_out_format_con {
+ MTK_DPI_RGB888_SDR_CON,
+ MTK_DPI_RGB888_DDR_CON,
+ MTK_DPI_RGB565_SDR_CON,
+ MTK_DPI_RGB565_DDR_CON
+};
+
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL0,
DDP_COMPONENT_AAL1,
@@ -65,4 +72,6 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next);
+void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val);
+
#endif /* __MTK_MMSYS_H */
[PATCH] drm/i915: Fix double word in comments
Remove the repeated word "not" in comments.
Signed-off-by: Bo Liu
---
drivers/gpu/drm/i915/display/intel_bw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 4ace026b29bd..a5cb253f6dc5 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -646,7 +646,7 @@ static unsigned int intel_bw_crtc_num_active_planes(const
struct intel_crtc_stat
{
/*
* We assume cursors are small enough
-* to not not cause bandwidth problems.
+* to not cause bandwidth problems.
*/
return hweight8(crtc_state->active_planes & ~BIT(PLANE_CURSOR));
}
@@ -661,7 +661,7 @@ static unsigned int intel_bw_crtc_data_rate(const struct
intel_crtc_state *crtc_
for_each_plane_id_on_crtc(crtc, plane_id) {
/*
* We assume cursors are small enough
-* to not not cause bandwidth problems.
+* to not cause bandwidth problems.
*/
if (plane_id == PLANE_CURSOR)
continue;
--
2.27.0
Re: [Intel-gfx] [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions
On 21/09/2022 19:17, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common functionalities into a separate file where possible.
Looks like a good start to me. A couple comments/questions below.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 507 ++---
.../drm/i915/gem/i915_gem_execbuffer_common.c | 530 ++
.../drm/i915/gem/i915_gem_execbuffer_common.h | 47 ++
4 files changed, 612 insertions(+), 473 deletions(-)
create mode 100644
drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.c
create mode 100644
drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index 9bf939ef18ea..bf952f478555 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -148,6 +148,7 @@ gem-y += \
gem/i915_gem_create.o \
gem/i915_gem_dmabuf.o \
gem/i915_gem_domain.o \
+ gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 33d989a20227..363b2a788cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -9,8 +9,6 @@
#include
#include
-#include
-
#include "display/intel_frontbuffer.h"
#include "gem/i915_gem_ioctls.h"
@@ -28,6 +26,7 @@
#include "i915_file_private.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
#include "i915_gem_evict.h"
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
@@ -235,13 +234,6 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
-struct eb_fence {
- struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
- struct dma_fence *dma_fence;
- u64 value;
- struct dma_fence_chain *chain_fence;
-};
-
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -2446,164 +2438,29 @@ static const enum intel_engine_id
user_ring_map[] = {
[I915_EXEC_VEBOX] = VECS0
};
-static struct i915_request *eb_throttle(struct i915_execbuffer *eb,
struct intel_context *ce)
-{
- struct intel_ring *ring = ce->ring;
- struct intel_timeline *tl = ce->timeline;
- struct i915_request *rq;
-
- /*
- * Completely unscientific finger-in-the-air estimates for suitable
- * maximum user request size (to avoid blocking) and then backoff.
- */
- if (intel_ring_update_space(ring) >= PAGE_SIZE)
- return NULL;
-
- /*
- * Find a request that after waiting upon, there will be at
least half
- * the ring available. The hysteresis allows us to compete for the
- * shared ring and should mean that we sleep less often prior to
- * claiming our resources, but not so long that the ring completely
- * drains before we can submit our next request.
- */
- list_for_each_entry(rq, &tl->requests, link) {
- if (rq->ring != ring)
- continue;
-
- if (__intel_ring_space(rq->postfix,
- ring->emit, ring->size) > ring->size / 2)
- break;
- }
- if (&rq->link == &tl->requests)
- return NULL; /* weird, we will check again later for real */
-
- return i915_request_get(rq);
-}
-
-static int eb_pin_timeline(struct i915_execbuffer *eb, struct
intel_context *ce,
- bool throttle)
-{
- struct intel_timeline *tl;
- struct i915_request *rq = NULL;
-
- /*
- * Take a local wakeref for preparing to dispatch the execbuf as
- * we expect to access the hardware fairly frequently in the
- * process, and require the engine to be kept awake between
accesses.
- * Upon dispatch, we acquire another prolonged wakeref that we hold
- * until the timeline is idle, which in turn releases the wakeref
- * taken on the engine, and the parent device.
- */
- tl = intel_context_timeline_lock(ce);
- if (IS_ERR(tl))
- return PTR_ERR(tl);
-
- intel_context_enter(ce);
- if (throttle)
- rq = eb_throttle(eb, ce);
- intel_context_timeline_unlock(tl);
-
- if (rq) {
- bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
- long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
-
- if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
- timeout) < 0) {
- i915_request_put(rq);
-
- /*
- * Error path, cannot use intel_context_timeline_lo
[PATCH resend v2] drm/amdgpu: fix enum conversion in display_mode_vba
Fix below compile warning when open enum-conversion
option check (compiled with -Wenum-conversion):
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:
In function ‘dml20_ModeSupportAndSystemConfigurationFull’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3900:44:
error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’
[-Werror=enum-conversion]
3900 | locals->ODMCombineEnablePerState[i][k] = false;
|^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3904:46:
error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’
[-Werror=enum-conversion]
3904 | locals->ODMCombineEnablePerState[i][k] = true;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3907:46:
error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’
[-Werror=enum-conversion]
3907 | locals->ODMCombineEnablePerState[i][k] = true;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3960:45:
error: implicit conversion from ‘enum ’ to ‘enum odm_combine_mode’
[-Werror=enum-conversion]
3960 | locals->ODMCombineEnablePerState[i][k] = false;
Use the proper value from the right enumerated type,
dm_odm_combine_mode_disabled & dm_odm_combine_mode_2to1,
so there is no more implicit conversion.
The numerical values of dm_odm_combine_mode_disabled
& false and dm_odm_combine_mode_2to1 & true
happen to be the same, so there is no change in
behavior.
Signed-off-by: Zeng Heng
---
.../amd/display/dc/dml/dcn20/display_mode_vba_20.c | 8
.../amd/display/dc/dml/dcn20/display_mode_vba_20v2.c | 10 +-
.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
index d3b5b6fedf04..6266b0788387 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
@@ -3897,14 +3897,14 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine = mode_lib->vba.PixelClock[k]
/ 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMCombineEnablePerState[i][k] =
dm_odm_combine_mode_disabled;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine;
if (mode_lib->vba.ODMCapability) {
if
(locals->PlaneRequiredDISPCLKWithoutODMCombine >
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
} else if (locals->HActive[k] >
DCN20_MAX_420_IMAGE_WIDTH && locals->OutputFormat[k] == dm_420) {
-
locals->ODMCombineEnablePerState[i][k] = true;
+
locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
}
}
@@ -3957,7 +3957,7 @@ void dml20_ModeSupportAndSystemConfigurationFull(struct
display_mode_lib *mode_l
locals->RequiredDISPCLK[i][j] = 0.0;
locals->DISPCLK_DPPCLK_Support[i][j] = true;
for (k = 0; k <=
mode_lib->vba.NumberOfActivePlanes - 1; k++) {
- locals->ODMCombineEnablePerState[i][k]
= false;
+ locals->ODMCombineEnablePerState[i][k]
= dm_odm_combine_mode_disabled;
if (locals->SwathWidthYSingleDPP[k] <=
locals->MaximumSwathWidth[k]) {
locals->NoOfDPP[i][j][k] = 1;
locals->RequiredDPPCLK[i][j][k]
= locals->MinDPPCLKUsingSingleDPP[k]
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
b/driver
Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions
On Thu, Sep 22, 2022 at 5:10 AM Kees Cook wrote: > > -#ifdef __alloc_size__ > -# define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc > -#else > -# define __alloc_size(x, ...) __malloc > -#endif > +#define __alloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) __malloc > +#define __realloc_size(x, ...) __alloc_size__(x, ## __VA_ARGS__) These look unconditional now, so we could move it to `compiler_attributes.h` in a later patch (or an independent series). Cheers, Miguel
Re: [RFC v4 02/14] drm/i915/vm_bind: Add __i915_sw_fence_await_reservation()
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add function __i915_sw_fence_await_reservation() for
> asynchronous wait on a dma-resv object with specified
> dma_resv_usage. This is required for async vma unbind
> with vm_bind.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> drivers/gpu/drm/i915/i915_sw_fence.c | 25 ++---
> drivers/gpu/drm/i915/i915_sw_fence.h | 7 ++-
> 2 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
> b/drivers/gpu/drm/i915/i915_sw_fence.c
> index 6fc0d1b89690..0ce8f4efc1ed 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.c
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -569,12 +569,11 @@ int __i915_sw_fence_await_dma_fence(struct
> i915_sw_fence *fence,
> return ret;
> }
>
> -int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> - struct dma_resv *resv,
> - const struct dma_fence_ops *exclude,
> - bool write,
> - unsigned long timeout,
> - gfp_t gfp)
> +int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> + struct dma_resv *resv,
> + enum dma_resv_usage usage,
> + unsigned long timeout,
> + gfp_t gfp)
> {
> struct dma_resv_iter cursor;
> struct dma_fence *f;
> @@ -583,7 +582,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
> *fence,
> debug_fence_assert(fence);
> might_sleep_if(gfpflags_allow_blocking(gfp));
>
> - dma_resv_iter_begin(&cursor, resv, dma_resv_usage_rw(write));
> + dma_resv_iter_begin(&cursor, resv, usage);
> dma_resv_for_each_fence_unlocked(&cursor, f) {
> pending = i915_sw_fence_await_dma_fence(fence, f, timeout,
> gfp);
> @@ -598,6 +597,18 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
> *fence,
> return ret;
> }
>
> +int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> + struct dma_resv *resv,
> + const struct dma_fence_ops *exclude,
> + bool write,
> + unsigned long timeout,
> + gfp_t gfp)
> +{
> + return __i915_sw_fence_await_reservation(fence, resv,
> + dma_resv_usage_rw(write),
> + timeout, gfp);
> +}
> +
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> #include "selftests/lib_sw_fence.c"
> #include "selftests/i915_sw_fence.c"
> diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
> b/drivers/gpu/drm/i915/i915_sw_fence.h
> index 619fc5a22f0c..3cf4b6e16f35 100644
> --- a/drivers/gpu/drm/i915/i915_sw_fence.h
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.h
> @@ -10,13 +10,13 @@
> #define _I915_SW_FENCE_H_
>
> #include
> +#include
As a GCC extension you can drop this and forward declare enum
dma_resv_usage. We use it extensively.
> #include
> #include
> #include /* for NOTIFY_DONE */
> #include
>
> struct completion;
> -struct dma_resv;
> struct i915_sw_fence;
>
> enum i915_sw_fence_notify {
> @@ -89,6 +89,11 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence
> *fence,
> unsigned long timeout,
> gfp_t gfp);
>
> +int __i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> + struct dma_resv *resv,
> + enum dma_resv_usage usage,
> + unsigned long timeout,
> + gfp_t gfp);
> int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
> struct dma_resv *resv,
> const struct dma_fence_ops *exclude,
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Remove unused function parameter
On 22/09/2022 05:43, Niranjana Vishwanathapura wrote:
The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 1 -
drivers/gpu/drm/i915/i915_sw_fence.h | 1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index aaa6708256d5..ecb8d71d36c0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -1005,7 +1005,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
*/
if (intel_crtc_needs_modeset(crtc_state)) {
ret =
i915_sw_fence_await_reservation(&state->commit_ready,
-
old_obj->base.resv, NULL,
+
old_obj->base.resv,
false, 0,
GFP_KERNEL);
if (ret < 0)
@@ -1039,8 +1039,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
struct dma_fence *fence;
ret = i915_sw_fence_await_reservation(&state->commit_ready,
- obj->base.resv, NULL,
- false,
+ obj->base.resv, false,
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index 0512afdd20d8..b3b398fe689c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -113,7 +113,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
*obj,
clflush = clflush_work_create(obj);
if (clflush) {
i915_sw_fence_await_reservation(&clflush->base.chain,
- obj->base.resv, NULL, true,
+ obj->base.resv, true,
i915_fence_timeout(i915),
I915_FENCE_GFP);
dma_resv_add_fence(obj->base.resv, &clflush->base.dma,
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 6fc0d1b89690..cc2a8821d22a 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -571,7 +571,6 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
- const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 619fc5a22f0c..f752bfc7c6e1 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -91,7 +91,6 @@ int i915_sw_fence_await_dma_fence(struct i915_sw_fence *fence,
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
- const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [Intel-gfx] [RFC v4 04/14] drm/i915/vm_bind: Implement bind and unbind of object
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add uapi and implement support for bind and unbind of an
> object at the specified GPU virtual addresses.
>
> The vm_bind mode is not supported in legacy execbuf2 ioctl.
> It will be supported only in the newer execbuf3 ioctl.
>
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Prathap Kumar Valsan
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 5 +
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 27 ++
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 308 ++
> drivers/gpu/drm/i915/gt/intel_gtt.c | 10 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 17 +
> drivers/gpu/drm/i915/i915_driver.c| 3 +
> drivers/gpu/drm/i915/i915_vma.c | 3 +-
> drivers/gpu/drm/i915/i915_vma.h | 2 -
> drivers/gpu/drm/i915/i915_vma_types.h | 14 +
> include/uapi/drm/i915_drm.h | 167 ++
> 11 files changed, 554 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index a26edcdadc21..9bf939ef18ea 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -166,6 +166,7 @@ gem-y += \
> gem/i915_gem_ttm_move.o \
> gem/i915_gem_ttm_pm.o \
> gem/i915_gem_userptr.o \
> + gem/i915_gem_vm_bind_object.o \
> gem/i915_gem_wait.o \
> gem/i915_gemfs.o
> i915-y += \
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index cd75b0ca2555..f85f10cf9c34 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
> if (unlikely(IS_ERR(ctx)))
> return PTR_ERR(ctx);
>
> + if (ctx->vm->vm_bind_mode) {
> + i915_gem_context_put(ctx);
> + return -EOPNOTSUPP;
> + }
> +
> eb->gem_context = ctx;
> if (i915_gem_context_has_full_ppgtt(ctx))
> eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> new file mode 100644
> index ..4f3cfa1f6ef6
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_GEM_VM_BIND_H
> +#define __I915_GEM_VM_BIND_H
> +
> +#include
This one's needed for u64, but none of the below includes are needed.
Please drop them and use forward declarations instead.
As a rule of thumb, don't include headers from headers if it can be
avoided. The interdependencies we have are already huge, and need to be
reduced, not increased.
BR,
Jani.
> +#include
> +#include
> +
> +#include "gt/intel_gtt.h"
> +#include "i915_vma_types.h"
> +
> +struct i915_vma *
> +i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
> +
> +int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file);
> +int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file);
> +
> +void i915_gem_vm_unbind_all(struct i915_address_space *vm);
> +
> +#endif /* __I915_GEM_VM_BIND_H */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> new file mode 100644
> index ..c24e22657617
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -0,0 +1,308 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#include
> +
> +#include
> +
> +#include "gem/i915_gem_context.h"
> +#include "gem/i915_gem_vm_bind.h"
> +
> +#include "gt/intel_gpu_commands.h"
> +
> +#define START(node) ((node)->start)
> +#define LAST(node) ((node)->last)
> +
> +INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
> + START, LAST, static inline, i915_vm_bind_it)
> +
> +#undef START
> +#undef LAST
> +
> +/**
> + * DOC: VM_BIND/UNBIND ioctls
> + *
> + * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
> + * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
> + * specified address space (VM). Multiple mappings can map to the same
> physical
> + * pages of an object (aliasing). These mappings (also referred to as
> persistent
> + * mappings) will be persistent across multiple GPU submissions (execbuf
> calls)
> + * issued by the UMD, without user having to provide a list of all required
> + * mappings during each s
Re: [Intel-gfx] [RFC v4 07/14] drm/i915/vm_bind: Add out fence support
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> Add support for handling out fence for vm_bind call.
>
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 81 +++
> drivers/gpu/drm/i915/i915_vma.c | 6 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
> 4 files changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> index 4f3cfa1f6ef6..facba29ead04 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> @@ -6,6 +6,7 @@
> #ifndef __I915_GEM_VM_BIND_H
> #define __I915_GEM_VM_BIND_H
>
> +#include
Unnecessary. Please use forward declarations.
> #include
>
> #include
> @@ -24,4 +25,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
> *data,
>
> void i915_gem_vm_unbind_all(struct i915_address_space *vm);
>
> +void i915_vm_bind_signal_fence(struct i915_vma *vma,
> +struct dma_fence * const fence);
> +
> #endif /* __I915_GEM_VM_BIND_H */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index 236f901b8b9c..5cd788404ee7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -7,6 +7,8 @@
>
> #include
>
> +#include
> +
> #include "gem/i915_gem_context.h"
> #include "gem/i915_gem_vm_bind.h"
>
> @@ -106,6 +108,75 @@ static void i915_gem_vm_bind_remove(struct i915_vma
> *vma, bool release_obj)
> i915_gem_object_put(vma->obj);
> }
>
> +static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma
> *vma,
> + u32 handle, u64 point)
> +{
> + struct drm_syncobj *syncobj;
> +
> + syncobj = drm_syncobj_find(file, handle);
> + if (!syncobj) {
> + DRM_DEBUG("Invalid syncobj handle provided\n");
> + return -ENOENT;
> + }
> +
> + /*
> + * For timeline syncobjs we need to preallocate chains for
> + * later signaling.
> + */
> + if (point) {
> + vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
> + if (!vma->vm_bind_fence.chain_fence) {
> + drm_syncobj_put(syncobj);
> + return -ENOMEM;
> + }
> + } else {
> + vma->vm_bind_fence.chain_fence = NULL;
> + }
> + vma->vm_bind_fence.syncobj = syncobj;
> + vma->vm_bind_fence.value = point;
> +
> + return 0;
> +}
> +
> +static void i915_vm_bind_put_fence(struct i915_vma *vma)
> +{
> + if (!vma->vm_bind_fence.syncobj)
> + return;
> +
> + drm_syncobj_put(vma->vm_bind_fence.syncobj);
> + dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
> +}
> +
> +/**
> + * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
> + * @vma: vma mapping requiring signaling
> + * @fence: fence to be added
> + *
> + * Associate specified @fence with the @vma's syncobj to be
> + * signaled after the @fence work completes.
> + */
> +void i915_vm_bind_signal_fence(struct i915_vma *vma,
> +struct dma_fence * const fence)
> +{
> + struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
> +
> + if (!syncobj)
> + return;
> +
> + if (vma->vm_bind_fence.chain_fence) {
> + drm_syncobj_add_point(syncobj,
> + vma->vm_bind_fence.chain_fence,
> + fence, vma->vm_bind_fence.value);
> + /*
> + * The chain's ownership is transferred to the
> + * timeline.
> + */
> + vma->vm_bind_fence.chain_fence = NULL;
> + } else {
> + drm_syncobj_replace_fence(syncobj, fence);
> + }
> +}
> +
> static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
> struct drm_i915_gem_vm_unbind *va)
> {
> @@ -233,6 +304,13 @@ static int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
> goto unlock_vm;
> }
>
> + if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL) {
> + ret = i915_vm_bind_add_fence(file, vma, va->fence.handle,
> + va->fence.value);
> + if (ret)
> + goto put_vma;
> + }
> +
> pin_flags = va->start | PIN_OFFSET_FIXED | PIN_USER;
>
> for_i915_gem_ww(&ww, ret, true) {
> @@ -257,6 +335,9 @@ static int i915_gem_vm_bind_obj(struct i915_address_space
> *vm,
> i915_gem_object_get(vma->obj);
> }
>
> + if (va->fence.flags & I915_TIMELINE_FENCE_SIGNAL)
> + i915_vm_bind_put_fence(vma);
> +put_vma:
> if (ret)
>
Re: [PATCH v1] drivers:adp8870_bl: check the return value of adp8870_write
On Wed, Sep 21, 2022 at 02:50:49PM -0700, Li Zhong wrote:
> Subject: [PATCH v1] drivers:adp8870_bl: check the return value of
> adp8870_write
Should be backlight: adp8870_bl.
> Check and propagate the return value of adp8870_write() when it fails,
> which is possible when SMBus writing byte fails.
This looks like a sensible change, however...
When writing patches like this please review the whole file for similar
concerns and fix all instances of the same issue. In this case there is another
unchecked call to adp8870_write() in
adp8870_bl_ambient_light_zone_store() (this function also contains
other unchecked calls).
Note that the unchecked use in adp8870_led_work() because there is no
way to propogate the error from this function (and adp8870_write()
already logged the error).
It would also be good to review and fix adp8860_bl.c at the same time
since these drivers are very similar (ideally the identical code in
these drivers should be factored out).
> Signed-off-by: Li Zhong
> ---
> drivers/video/backlight/adp8870_bl.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/adp8870_bl.c
> b/drivers/video/backlight/adp8870_bl.c
> index 8b5213a39527..0eb4ae2ff592 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -567,9 +567,13 @@ static ssize_t adp8870_store(struct device *dev, const
> char *buf,
> return ret;
>
> mutex_lock(&data->lock);
> - adp8870_write(data->client, reg, val);
> + ret = adp8870_write(data->client, reg, val);
> mutex_unlock(&data->lock);
>
> + if (ret) {
> + return ret;
> + }
No need for braces here.
> +
> return count;
> }
>
Thanks
Daniel.
Re: [PATCH] gpu: dc: fix enum conversion in display_mode_vba
I just correct the subject line and resend the patch mail.
Please refer to:
[PATCH resend v2] drm/amdgpu: fix enum conversion in display_mode_vba
On 2022/9/19 15:44, Christian König wrote:
Am 19.09.22 um 03:41 schrieb Zeng Heng:
Fix below compile warning when open enum-conversion
option check (compiled with -Wenum-conversion):
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:
In function ‘dml20_ModeSupportAndSystemConfigurationFull’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3900:44:
error: implicit conversion from ‘enum ’ to ‘enum
odm_combine_mode’ [-Werror=enum-conversion]
3900 | locals->ODMCombineEnablePerState[i][k] = false;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3904:46:
error: implicit conversion from ‘enum ’ to ‘enum
odm_combine_mode’ [-Werror=enum-conversion]
3904 | locals->ODMCombineEnablePerState[i][k] = true;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3907:46:
error: implicit conversion from ‘enum ’ to ‘enum
odm_combine_mode’ [-Werror=enum-conversion]
3907 | locals->ODMCombineEnablePerState[i][k] = true;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3960:45:
error: implicit conversion from ‘enum ’ to ‘enum
odm_combine_mode’ [-Werror=enum-conversion]
3960 | locals->ODMCombineEnablePerState[i][k] = false;
Use the proper value from the right enumerated type,
dm_odm_combine_mode_disabled & dm_odm_combine_mode_2to1,
so there is no more implicit conversion.
The numerical values of dm_odm_combine_mode_disabled
& false and dm_odm_combine_mode_2to1 & true
happen to be the same, so there is no change in
behavior.
In the subject line the correct prefix is "drm/amdgpu: ", but
apart from that looks good to me as well.
But our DC team has to take a closer look.
Thanks,
Christian.
Signed-off-by: Zeng Heng
---
.../amd/display/dc/dml/dcn20/display_mode_vba_20.c | 8
.../amd/display/dc/dml/dcn20/display_mode_vba_20v2.c | 10 +-
.../amd/display/dc/dml/dcn21/display_mode_vba_21.c | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git
a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
index d3b5b6fedf04..6266b0788387 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c
@@ -3897,14 +3897,14 @@ void
dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_l
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine =
mode_lib->vba.PixelClock[k] / 2
* (1 +
mode_lib->vba.DISPCLKDPPCLKDSCCLKDownSpreading / 100.0);
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMCombineEnablePerState[i][k] =
dm_odm_combine_mode_disabled;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithoutODMCombine;
if (mode_lib->vba.ODMCapability) {
if
(locals->PlaneRequiredDISPCLKWithoutODMCombine >
mode_lib->vba.MaxDispclkRoundedDownToDFSGranularity) {
- locals->ODMCombineEnablePerState[i][k] = true;
+ locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
} else if (locals->HActive[k] >
DCN20_MAX_420_IMAGE_WIDTH && locals->OutputFormat[k] == dm_420) {
- locals->ODMCombineEnablePerState[i][k] = true;
+ locals->ODMCombineEnablePerState[i][k] = dm_odm_combine_mode_2to1;
mode_lib->vba.PlaneRequiredDISPCLK =
mode_lib->vba.PlaneRequiredDISPCLKWithODMCombine;
}
}
@@ -3957,7 +3957,7 @@ void
dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_l
locals->RequiredDISPCLK[i][j] = 0.0;
locals->DISPCLK_DPPCLK_Support[i][j] = true;
for (k = 0; k <= mode_lib->vba.NumberOfActivePlanes
- 1; k++) {
- locals->ODMCombineEnablePerState[i][k] = false;
+ locals->ODMCombineEnablePerState[i][k] =
dm_odm_combine_mode_disabled;
if (locals->SwathWidthYSingleDPP[k] <=
locals->MaximumSwathWidth[k]) {
locals->NoOfDPP[i][j][k] = 1;
locals->RequiredDPPCLK[i][j][k] =
locals->MinDPPCLKUsingSingleDPP[k]
diff --git
a/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
b/drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20v2.c
index edd098c7eb92..989d83ee3842 100644
--- a/drivers/gpu
Re: [RFC v4 08/14] drm/i915/vm_bind: Abstract out common execbuf functions
On Wed, 21 Sep 2022, Niranjana Vishwanathapura
wrote:
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
> new file mode 100644
> index ..725febfd6a53
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer_common.h
> @@ -0,0 +1,47 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#ifndef __I915_GEM_EXECBUFFER_COMMON_H
> +#define __I915_GEM_EXECBUFFER_COMMON_H
> +
> +#include
> +
> +#include "gt/intel_context.h"
You don't need these includes. Most of it can be handled using forward
declarations. You'll need
> +
> +struct eb_fence {
> + struct drm_syncobj *syncobj;
> + struct dma_fence *dma_fence;
> + u64 value;
> + struct dma_fence_chain *chain_fence;
> +};
> +
> +int __eb_pin_engine(struct intel_context *ce, struct i915_gem_ww_ctx *ww,
> + bool throttle, bool nonblock);
> +void __eb_unpin_engine(struct intel_context *ce);
> +int __eb_select_engine(struct intel_context *ce);
> +void __eb_put_engine(struct intel_context *context, struct intel_gt *gt);
> +
> +struct intel_context *
> +eb_find_context(struct intel_context *context, unsigned int context_number);
> +
> +int add_timeline_fence(struct drm_file *file, u32 handle, u64 point,
> +struct eb_fence *f, bool wait, bool signal);
> +void put_fence_array(struct eb_fence *fences, u64 num_fences);
> +int await_fence_array(struct eb_fence *fences, u64 num_fences,
> + struct i915_request *rq);
> +void signal_fence_array(struct eb_fence *fences, u64 num_fences,
> + struct dma_fence * const fence);
> +
> +int eb_requests_add(struct i915_request **requests, unsigned int num_batches,
> + struct intel_context *context, struct i915_sched_attr sched,
struct i915_sched_attr is passed by value, so you either need to turn
that into a pointer, or you need the definition. The definition is just
a wrapper around an int. (For strict type safety or for future proofing
or what, I don't know.) And this all brings me to my pet peeve about
gem/gt headers.
To get that definition of a struct wrapper around an int, you need to
include i915_scheduler_types.h, which recursively includes a total of 16
headers. Touch any of those files, and you get a rebuild butterfly
effect.
28% of i915 header files, when modified, cause the rebuild of 83% of the
driver. Please let's not make it worse.
BR,
Jani.
> + int err);
> +void eb_requests_get(struct i915_request **requests, unsigned int
> num_batches);
> +void eb_requests_put(struct i915_request **requests, unsigned int
> num_batches);
> +
> +struct dma_fence *__eb_composite_fence_create(struct i915_request **requests,
> + unsigned int num_batches,
> + struct intel_context *context);
> +
> +#endif /* __I915_GEM_EXECBUFFER_COMMON_H */
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH v3 0/7] New DRM driver for Intel VPU
Hi, This patchset contains a new Linux* Kernel Driver for Intel® VPUs. VPU stands for Versatile Processing Unit and it is an AI inference accelerator integrated with Intel non-server CPUs starting from 14th generation. VPU enables efficient execution of Deep Learning applications like object detection, classification etc. Driver is part of gpu/drm subsystem because VPU is similar in operation to an integrated GPU. Reusing drm driver init, ioctl handling, gem and prime helpers and drm_mm allows to minimize code duplication in the kernel. The whole driver is licensed under GPL-2.0-only except for two headers imported from the firmware that are MIT licensed. User mode driver stack consists of Level Zero API driver and OpenVINO plugin. Both should be open-sourced by the end of Q4. The firmware for the VPU will be distributed as a closed source binary. Regards, Jacek v3: - Fixed alignment warning in ivpu_ipc.c when building with W=1 v2: https://lore.kernel.org/all/20220913121017.993825-1-jacek.lawrynow...@linux.intel.com/ - Rename the driver from "drm/vpu" to "drm/ivpu" - Add a TODO file - Add support for WC buffers v1: https://lore.kernel.org/all/20220728131709.1087188-1-jacek.lawrynow...@linux.intel.com/ Jacek Lawrynowicz (7): drm/ivpu: Introduce a new DRM driver for Intel VPU drm/ivpu: Add Intel VPU MMU support drm/ivpu: Add GEM buffer object management drm/ivpu: Add IPC driver and JSM messages drm/ivpu: Implement firmware parsing and booting drm/ivpu: Add command buffer submission logic drm/ivpu: Add PM support MAINTAINERS |8 + drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/ivpu/Kconfig| 12 + drivers/gpu/drm/ivpu/Makefile | 16 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c | 643 ++ drivers/gpu/drm/ivpu/ivpu_drv.h | 178 drivers/gpu/drm/ivpu/ivpu_fw.c | 426 + drivers/gpu/drm/ivpu/ivpu_fw.h | 38 + drivers/gpu/drm/ivpu/ivpu_gem.c | 836 ++ drivers/gpu/drm/ivpu/ivpu_gem.h | 128 +++ drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1060 +++ drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 ++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ drivers/gpu/drm/ivpu/ivpu_ipc.c | 508 +++ drivers/gpu/drm/ivpu/ivpu_ipc.h | 90 ++ drivers/gpu/drm/ivpu/ivpu_job.c | 629 ++ drivers/gpu/drm/ivpu/ivpu_job.h | 73 ++ drivers/gpu/drm/ivpu/ivpu_jsm_msg.c | 220 + drivers/gpu/drm/ivpu/ivpu_jsm_msg.h | 25 + drivers/gpu/drm/ivpu/ivpu_mmu.c | 888 +++ drivers/gpu/drm/ivpu/ivpu_mmu.h | 53 ++ drivers/gpu/drm/ivpu/ivpu_mmu_context.c | 419 + drivers/gpu/drm/ivpu/ivpu_mmu_context.h | 49 ++ drivers/gpu/drm/ivpu/ivpu_pm.c | 352 drivers/gpu/drm/ivpu/ivpu_pm.h | 38 + drivers/gpu/drm/ivpu/vpu_boot_api.h | 241 ++ drivers/gpu/drm/ivpu/vpu_jsm_api.h | 616 + include/uapi/drm/ivpu_drm.h | 343 31 files changed, 8651 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_fw.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_fw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_ipc.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_ipc.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_job.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_job.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_jsm_msg.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_jsm_msg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_pm.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_pm.h create mode 100644 drivers/gpu/drm/ivpu/vpu_boot_api.h create mode 100644 drivers/gpu/drm/ivpu/vpu_jsm_api.h create mode 100644 include/uapi/drm/ivpu_drm.h -- 2.34.1
[PATCH v3 1/7] drm/ivpu: Introduce a new DRM driver for Intel VPU
VPU stands for Versatile Processing Unit and it's a CPU-integrated inference accelerator for Computer Vision and Deep Learning applications. The VPU device consist of following componensts: - Buttress - provides CPU to VPU integration, interrupt, frequency and power management. - Memory Management Unit (based on ARM MMU-600) - translates VPU to host DMA addresses, isolates user workloads. - RISC based microcontroller - executes firmware that provides job execution API for the kernel-mode driver - Neural Compute Subsystem (NCS) - does the actual work, provides Compute and Copy engines. - Network on Chip (NoC) - network fabric connecting all the components This driver supports VPU IP v2.7 integrated into Intel Meteor Lake client CPUs (14th generation). Module sources are at drivers/gpu/drm/ivpu and module name is "intel_vpu.ko". This patch includes only very besic functionality: - module, PCI device and IRQ initialization - register definitions and low level register manipulation functions - SET/GET_PARAM ioctls - power up without firmware Signed-off-by: Krystian Pradzynski Signed-off-by: Jacek Lawrynowicz --- MAINTAINERS|8 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivpu/Kconfig | 12 + drivers/gpu/drm/ivpu/Makefile |8 + drivers/gpu/drm/ivpu/TODO |7 + drivers/gpu/drm/ivpu/ivpu_drv.c| 392 + drivers/gpu/drm/ivpu/ivpu_drv.h| 153 drivers/gpu/drm/ivpu/ivpu_hw.h | 169 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 1021 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h | 468 +++ drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h | 115 +++ include/uapi/drm/ivpu_drm.h| 95 +++ 13 files changed, 2451 insertions(+) create mode 100644 drivers/gpu/drm/ivpu/Kconfig create mode 100644 drivers/gpu/drm/ivpu/Makefile create mode 100644 drivers/gpu/drm/ivpu/TODO create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_drv.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl.c create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_mtl_reg.h create mode 100644 drivers/gpu/drm/ivpu/ivpu_hw_reg_io.h create mode 100644 include/uapi/drm/ivpu_drm.h diff --git a/MAINTAINERS b/MAINTAINERS index 9475aa701a3f..d72ceef107e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7046,6 +7046,14 @@ F: Documentation/devicetree/bindings/gpu/vivante,gc.yaml F: drivers/gpu/drm/etnaviv/ F: include/uapi/drm/etnaviv_drm.h +DRM DRIVERS FOR VPU +M: Jacek Lawrynowicz +M: Stanislaw Gruszka +S: Supported +T: git git://anongit.freedesktop.org/drm/drm-misc +F: drivers/gpu/drm/ivpu/ +F: include/uapi/drm/ivpu_drm.h + DRM DRIVERS FOR XEN M: Oleksandr Andrushchenko L: dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 198ba846d34b..0aaac0e5366f 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -364,6 +364,8 @@ source "drivers/gpu/drm/v3d/Kconfig" source "drivers/gpu/drm/vc4/Kconfig" +source "drivers/gpu/drm/ivpu/Kconfig" + source "drivers/gpu/drm/etnaviv/Kconfig" source "drivers/gpu/drm/hisilicon/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 25d0ba310509..1bfd7415c2d0 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -94,6 +94,7 @@ obj-$(CONFIG_DRM_KMB_DISPLAY) += kmb/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_IVPU) += ivpu/ obj-$(CONFIG_DRM_SIS) += sis/ obj-$(CONFIG_DRM_SAVAGE)+= savage/ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ diff --git a/drivers/gpu/drm/ivpu/Kconfig b/drivers/gpu/drm/ivpu/Kconfig new file mode 100644 index ..30af359c52f2 --- /dev/null +++ b/drivers/gpu/drm/ivpu/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-only +config DRM_IVPU + tristate "Intel VPU for Meteor Lake and newer" + depends on DRM + depends on X86_64 && PCI + select SHMEM + help + Choose this option if you have a system that has an 14th generation Intel CPU + or newer. VPU stands for Versatile Processing Unit and it's a CPU-integrated + inference accelerator for Computer Vision and Deep Learning applications. + + If "M" is selected, the module will be called intel_vpu. diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile new file mode 100644 index ..e59dc65abe6a --- /dev/null +++ b/drivers/gpu/drm/ivpu/Makefile @@ -0,0 +1,8 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Copyright © 2022 Intel Corporation + +intel_vpu-y := \ + ivpu_drv.o \ + ivpu_hw_mtl.o + +obj-$(CONFIG_DRM_IVPU) += intel_vpu.o diff --git a/drivers/gpu/drm/ivpu/TOD
[PATCH v3 2/7] drm/ivpu: Add Intel VPU MMU support
VPU Memory Management Unit is based on ARM MMU-600.
It allows to create multiple virtual address spaces for the device and
map noncontinuous host memory (there is no dedicated memory on the VPU).
Address space is implemented as a struct ivpu_mmu_context, it has an ID,
drm_mm allocator for VPU addresses and struct ivpu_mmu_pgtable that holds
actual 3-level, 4KB page table.
Context with ID 0 (global context) is created upon driver initialization
and it's mainly used for mapping memory required to execute
the firmware.
Contexts with non-zero IDs are user contexts allocated each time
the devices is open()-ed and they map command buffers and other
workload-related memory.
Workloads executing in a given contexts have access only
to the memory mapped in this context.
This patch is has to main files:
- ivpu_mmu_context.c handles MMU page tables and memory mapping
- ivpu_mmu.c implements a driver that programs the MMU device
Signed-off-by: Karol Wachowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 4 +-
drivers/gpu/drm/ivpu/ivpu_drv.c | 59 +-
drivers/gpu/drm/ivpu/ivpu_drv.h | 7 +
drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 10 +
drivers/gpu/drm/ivpu/ivpu_mmu.c | 883
drivers/gpu/drm/ivpu/ivpu_mmu.h | 53 ++
drivers/gpu/drm/ivpu/ivpu_mmu_context.c | 419 +++
drivers/gpu/drm/ivpu/ivpu_mmu_context.h | 49 ++
include/uapi/drm/ivpu_drm.h | 4 +
9 files changed, 1485 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu.h
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_mmu_context.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index e59dc65abe6a..95bb04f26296 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,8 @@
intel_vpu-y := \
ivpu_drv.o \
- ivpu_hw_mtl.o
+ ivpu_hw_mtl.o \
+ ivpu_mmu.o \
+ ivpu_mmu_context.o
obj-$(CONFIG_DRM_IVPU) += intel_vpu.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index a01c7244f6e5..cbeb9a801a31 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -14,6 +14,8 @@
#include "ivpu_drv.h"
#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
+#include "ivpu_mmu_context.h"
#ifndef DRIVER_VERSION_STR
#define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
@@ -50,6 +52,11 @@ char *ivpu_platform_to_str(u32 platform)
void ivpu_file_priv_get(struct ivpu_file_priv *file_priv, struct
ivpu_file_priv **link)
{
+ struct ivpu_device *vdev = file_priv->vdev;
+
+ ivpu_dbg(KREF, "file_priv get: ctx %u refcount %u\n",
+file_priv->ctx.id, kref_read(&file_priv->ref));
+
kref_get(&file_priv->ref);
*link = file_priv;
}
@@ -57,6 +64,12 @@ void ivpu_file_priv_get(struct ivpu_file_priv *file_priv,
struct ivpu_file_priv
static void file_priv_release(struct kref *ref)
{
struct ivpu_file_priv *file_priv = container_of(ref, struct
ivpu_file_priv, ref);
+ struct ivpu_device *vdev = file_priv->vdev;
+
+ ivpu_dbg(FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
+
+ if (file_priv->ctx.id)
+ ivpu_mmu_user_context_fini(file_priv);
kfree(file_priv);
}
@@ -64,6 +77,10 @@ static void file_priv_release(struct kref *ref)
void ivpu_file_priv_put(struct ivpu_file_priv **link)
{
struct ivpu_file_priv *file_priv = *link;
+ struct ivpu_device *vdev = file_priv->vdev;
+
+ ivpu_dbg(KREF, "file_priv put: ctx %u refcount %u\n",
+file_priv->ctx.id, kref_read(&file_priv->ref));
*link = NULL;
kref_put(&file_priv->ref, file_priv_release);
@@ -75,7 +92,11 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, void
*data, struct drm_f
struct ivpu_device *vdev = file_priv->vdev;
struct pci_dev *pdev = to_pci_dev(vdev->drm.dev);
struct drm_ivpu_param *args = data;
- int ret = 0;
+ int ret;
+
+ ret = ivpu_mmu_user_context_init(file_priv);
+ if (ret)
+ return ret;
switch (args->param) {
case DRM_IVPU_PARAM_DEVICE_ID:
@@ -99,6 +120,9 @@ static int ivpu_get_param_ioctl(struct drm_device *dev, void
*data, struct drm_f
case DRM_IVPU_PARAM_CONTEXT_PRIORITY:
args->value = file_priv->priority;
break;
+ case DRM_IVPU_PARAM_CONTEXT_ID:
+ args->value = file_priv->ctx.id;
+ break;
default:
ret = -EINVAL;
}
@@ -110,7 +134,11 @@ static int ivpu_set_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
{
struct ivpu_file_priv *file_priv = file->driver_priv;
struct drm_ivpu_param *args = data;
- int r
[PATCH v3 3/7] drm/ivpu: Add GEM buffer object management
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are relased when the
buffer is destroyed.
Eviction mechism is planned for future versions.
Add three new IOCTLs: BO_CREATE, BO_INFO, BO_USERPTR
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 9 +
drivers/gpu/drm/ivpu/ivpu_gem.c | 823
drivers/gpu/drm/ivpu/ivpu_gem.h | 128 +
include/uapi/drm/ivpu_drm.h | 127 +
5 files changed, 1088 insertions(+)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_gem.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 95bb04f26296..4053fe341d56 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index cbeb9a801a31..b0442e2a4960 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include "ivpu_drv.h"
+#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -187,6 +189,9 @@ static void ivpu_postclose(struct drm_device *dev, struct
drm_file *file)
static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl,
DRM_RENDER_ALLOW),
};
DEFINE_DRM_GEM_FOPS(ivpu_fops);
@@ -210,6 +215,10 @@ static const struct drm_driver driver = {
.open = ivpu_open,
.postclose = ivpu_postclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ivpu_gem_prime_import,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
diff --git a/drivers/gpu/drm/ivpu/ivpu_gem.c b/drivers/gpu/drm/ivpu/ivpu_gem.c
new file mode 100644
index ..54319a25c18e
--- /dev/null
+++ b/drivers/gpu/drm/ivpu/ivpu_gem.c
@@ -0,0 +1,823 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2020-2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
+#include "ivpu_mmu_context.h"
+
+MODULE_IMPORT_NS(DMA_BUF);
+
+static const struct drm_gem_object_funcs ivpu_gem_funcs;
+
+static int __must_check prime_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+ return 0;
+}
+
+static void prime_free_pages_locked(struct ivpu_bo *bo)
+{
+ /* Pages are managed by the underlying dma-buf */
+}
+
+static int prime_map_pages_locked(struct ivpu_bo *bo)
+{
+ struct ivpu_device *vdev = ivpu_bo_to_vdev(bo);
+ struct sg_table *sgt;
+
+ WARN_ON(!bo->base.import_attach);
+
+ sgt = dma_buf_map_attachment(bo->base.import_attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt)) {
+ ivpu_err(vdev, "Failed to map attachment: %ld\n", PTR_ERR(sgt));
+ return PTR_ERR(sgt);
+ }
+
+ bo->sgt = sgt;
+ return 0;
+}
+
+static void prime_unmap_pages_locked(struct ivpu_bo *bo)
+{
+ WARN_ON(!bo->base.import_attach);
+
+ dma_buf_unmap_attachment(bo->base.import_attach, bo->sgt,
DMA_BIDIRECTIONAL);
+ bo->sgt = NULL;
+}
+
+static const struct ivpu_bo_ops prime_ops = {
+ .type = IVPU_BO_TYPE_PRIME,
+ .name = "prime",
+ .alloc_pages = prime_alloc_pages_locked,
+ .free_pages = prime_free_pages_locked,
+ .map_pages = prime_map_pages_locked,
+ .unmap_pages = prime_unmap_pages_locked,
+};
+
+static int __must_check shmem_alloc_pages_locked(struct ivpu_bo *bo)
+{
+ int npages = bo->base.size >> PAGE_SHIFT;
+ struct page **pages;
+
+ pages = drm_gem_get_pages(&bo->base);
+ if (IS_ERR(pages))
+ return PTR_ERR(pages);
+
+
[PATCH v3 5/7] drm/ivpu: Implement firmware parsing and booting
Read, parse and boot VPU firmware image.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 122 +++-
drivers/gpu/drm/ivpu/ivpu_drv.h | 10 +
drivers/gpu/drm/ivpu/ivpu_fw.c | 422
drivers/gpu/drm/ivpu/ivpu_fw.h | 38 +++
drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 11 +
drivers/gpu/drm/ivpu/vpu_boot_api.h | 241
include/uapi/drm/ivpu_drm.h | 21 ++
8 files changed, 865 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_fw.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_fw.h
create mode 100644 drivers/gpu/drm/ivpu/vpu_boot_api.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 4e33860c0dc4..8e9b3ae1a4cc 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_fw.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index b7e2bc54897a..67384671092e 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -13,10 +13,13 @@
#include
#include
+#include "vpu_boot_api.h"
#include "ivpu_drv.h"
+#include "ivpu_fw.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -31,6 +34,10 @@ int ivpu_dbg_mask;
module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);
MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros.");
+int ivpu_test_mode;
+module_param_named_unsafe(test_mode, ivpu_test_mode, int, 0644);
+MODULE_PARM_DESC(test_mode, "Test mode: 0 - normal operation, 1 - fw unit
test, 2 - null hw");
+
u8 ivpu_pll_min_ratio;
module_param_named(pll_min_ratio, ivpu_pll_min_ratio, byte, 0644);
MODULE_PARM_DESC(pll_min_ratio, "Minimum PLL ratio used to set VPU frequency");
@@ -126,6 +133,28 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
case DRM_IVPU_PARAM_CONTEXT_ID:
args->value = file_priv->ctx.id;
break;
+ case DRM_IVPU_PARAM_FW_API_VERSION:
+ if (args->index < VPU_FW_API_VER_NUM) {
+ struct vpu_firmware_header *fw_hdr;
+
+ fw_hdr = (struct vpu_firmware_header
*)vdev->fw->file->data;
+ args->value = fw_hdr->api_version[args->index];
+ } else {
+ ret = -EINVAL;
+ }
+ break;
+ case DRM_IVPU_PARAM_ENGINE_HEARTBEAT:
+ ret = ivpu_jsm_get_heartbeat(vdev, args->index, &args->value);
+ break;
+ case DRM_IVPU_PARAM_UNIQUE_INFERENCE_ID:
+ args->value =
(u64)atomic64_inc_return(&vdev->unique_id_counter);
+ break;
+ case DRM_IVPU_PARAM_TILE_CONFIG:
+ args->value = vdev->hw->tile_fuse;
+ break;
+ case DRM_IVPU_PARAM_SKU:
+ args->value = vdev->hw->sku;
+ break;
default:
ret = -EINVAL;
}
@@ -197,6 +226,70 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DEFINE_DRM_GEM_FOPS(ivpu_fops);
+static int ivpu_wait_for_ready(struct ivpu_device *vdev)
+{
+ struct ivpu_ipc_consumer cons;
+ struct ivpu_ipc_hdr ipc_hdr;
+ unsigned long timeout;
+ int ret;
+
+ if (ivpu_test_mode == IVPU_TEST_MODE_FW_TEST)
+ return 0;
+
+ ivpu_ipc_consumer_add(vdev, &cons, IVPU_IPC_CHAN_BOOT_MSG);
+
+ timeout = jiffies + msecs_to_jiffies(vdev->timeout.boot);
+ while (1) {
+ if (ivpu_ipc_irq_handler(vdev) != IRQ_HANDLED) {
+ ret = -EIO;
+ break;
+ }
+ ret = ivpu_ipc_receive(vdev, &cons, &ipc_hdr, NULL, 0);
+ if (ret != -ETIMEDOUT || time_after_eq(jiffies, timeout))
+ break;
+
+ cond_resched();
+ }
+
+ ivpu_ipc_consumer_del(vdev, &cons);
+
+ if (!ret && ipc_hdr.data_addr != IVPU_IPC_BOOT_MSG_DATA_ADDR) {
+ ivpu_err(vdev, "Invalid VPU ready message: 0x%x\n",
+ipc_hdr.data_addr);
+ return -EIO;
+ }
+
+ if (!ret)
+ ivpu_info(vdev, "VPU ready message received successfully\n");
+
+ return ret;
+}
+
+int ivpu_boot(struct ivpu_device *vdev)
+{
+ int ret;
+
+ /* Update boot params located at first 4KB of FW memory */
+ ivpu_fw_boot_params_setup(vdev, vdev->fw->mem->kvaddr);
+
+ ret = ivpu_hw_boot_fw(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to start the firmware: %d\n", ret);
+ return ret;
+ }
+
+ ret
[PATCH v3 7/7] drm/ivpu: Add PM support
- Implement cold and warm firmware boot flows
- Add hang recovery support
- Add runtime power management support
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 3 +-
drivers/gpu/drm/ivpu/ivpu_drv.c| 34 ++-
drivers/gpu/drm/ivpu/ivpu_drv.h| 2 +
drivers/gpu/drm/ivpu/ivpu_fw.c | 4 +
drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 16 +-
drivers/gpu/drm/ivpu/ivpu_ipc.c| 11 +-
drivers/gpu/drm/ivpu/ivpu_job.c| 14 +-
drivers/gpu/drm/ivpu/ivpu_mmu.c| 7 +-
drivers/gpu/drm/ivpu/ivpu_pm.c | 352 +
drivers/gpu/drm/ivpu/ivpu_pm.h | 38
10 files changed, 475 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_pm.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_pm.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index e87d8182c5c7..c17e4a25f751 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -10,6 +10,7 @@ intel_vpu-y := \
ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
- ivpu_mmu_context.o
+ ivpu_mmu_context.o \
+ ivpu_pm.o
obj-$(CONFIG_DRM_IVPU) += intel_vpu.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index 51e1f124139a..c31ce1bbc5be 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -23,6 +23,7 @@
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
+#include "ivpu_pm.h"
#ifndef DRIVER_VERSION_STR
#define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
@@ -80,9 +81,11 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
if (file_priv->ctx.id) {
+ ivpu_rpm_get(vdev);
ivpu_cmdq_release_all(file_priv);
ivpu_bo_remove_all_bos_from_context(&file_priv->ctx);
ivpu_mmu_user_context_fini(file_priv);
+ ivpu_rpm_put(vdev);
}
kfree(file_priv);
@@ -273,6 +276,7 @@ static int ivpu_wait_for_ready(struct ivpu_device *vdev)
int ivpu_boot(struct ivpu_device *vdev)
{
+ struct ivpu_pm_info *pm = vdev->pm;
int ret;
/* Update boot params located at first 4KB of FW memory */
@@ -290,6 +294,7 @@ int ivpu_boot(struct ivpu_device *vdev)
return ret;
}
+ atomic_set(&pm->in_recovery, 0);
ivpu_hw_irq_clear(vdev);
ivpu_hw_irq_enable(vdev);
ivpu_ipc_enable(vdev);
@@ -427,6 +432,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->ipc)
return -ENOMEM;
+ vdev->pm = devm_kzalloc(vdev->drm.dev, sizeof(*vdev->pm), GFP_KERNEL);
+ if (!vdev->pm)
+ return -ENOMEM;
+
vdev->hw->ops = &ivpu_hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
@@ -485,10 +494,16 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_fini;
}
+ ret = ivpu_pm_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize PM: %d\n", ret);
+ goto err_ipc_fini;
+ }
+
ret = ivpu_job_done_thread_init(vdev);
if (ret) {
ivpu_err(vdev, "Failed to initialize job done thread: %d\n",
ret);
- goto err_ipc_fini;
+ goto err_pm_fini;
}
ret = ivpu_fw_load(vdev);
@@ -507,6 +522,8 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
err_job_done_thread_fini:
ivpu_job_done_thread_fini(vdev);
+err_pm_fini:
+ ivpu_pm_fini(vdev);
err_ipc_fini:
ivpu_ipc_fini(vdev);
err_fw_fini:
@@ -529,6 +546,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
ivpu_shutdown(vdev);
ivpu_job_done_thread_fini(vdev);
+ ivpu_pm_fini(vdev);
ivpu_ipc_fini(vdev);
ivpu_fw_fini(vdev);
ivpu_mmu_fini(vdev);
@@ -583,11 +601,25 @@ static void ivpu_remove(struct pci_dev *pdev)
ivpu_dev_fini(vdev);
}
+static const struct dev_pm_ops ivpu_drv_pci_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(ivpu_pm_suspend_cb, ivpu_pm_resume_cb)
+ SET_RUNTIME_PM_OPS(ivpu_pm_runtime_suspend_cb,
ivpu_pm_runtime_resume_cb, NULL)
+};
+
+static const struct pci_error_handlers ivpu_drv_pci_err = {
+ .reset_prepare = ivpu_pm_reset_prepare_cb,
+ .reset_done = ivpu_pm_reset_done_cb,
+};
+
static struct pci_driver ivpu_pci_driver = {
.name = KBUILD_MODNAME,
.id_table = ivpu_pci_ids,
.probe = ivpu_probe,
.remove = ivpu_remove,
+ .driver = {
+ .pm = &ivpu_drv_pci_pm,
+ },
+ .err_handler = &ivpu_drv_pci_err,
};
static __init int ivpu_init(void)
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.h b/drivers/gpu/drm/ivpu/ivpu_drv.h
index 59544b3efec8..57f87e0a62c8 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.h
+++ b/drivers/gpu/drm/
[PATCH v3 4/7] drm/ivpu: Add IPC driver and JSM messages
The IPC driver is used to send and receive messages to/from firmware
running on the VPU.
The only supported IPC message format is Job Submission Model (JSM)
defined in vpu_jsm_api.h header.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 2 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 15 +
drivers/gpu/drm/ivpu/ivpu_drv.h | 2 +
drivers/gpu/drm/ivpu/ivpu_hw_mtl.c | 4 +
drivers/gpu/drm/ivpu/ivpu_ipc.c | 499 ++
drivers/gpu/drm/ivpu/ivpu_ipc.h | 90
drivers/gpu/drm/ivpu/ivpu_jsm_msg.c | 220 ++
drivers/gpu/drm/ivpu/ivpu_jsm_msg.h | 25 ++
drivers/gpu/drm/ivpu/vpu_jsm_api.h | 616
9 files changed, 1473 insertions(+)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_ipc.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_ipc.h
create mode 100644 drivers/gpu/drm/ivpu/ivpu_jsm_msg.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_jsm_msg.h
create mode 100644 drivers/gpu/drm/ivpu/vpu_jsm_api.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 4053fe341d56..4e33860c0dc4 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -5,6 +5,8 @@ intel_vpu-y := \
ivpu_drv.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
+ ivpu_ipc.o \
+ ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index b0442e2a4960..b7e2bc54897a 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -16,6 +16,7 @@
#include "ivpu_drv.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -201,6 +202,7 @@ int ivpu_shutdown(struct ivpu_device *vdev)
int ret;
ivpu_hw_irq_disable(vdev);
+ ivpu_ipc_disable(vdev);
ivpu_mmu_disable(vdev);
ret = ivpu_hw_power_down(vdev);
@@ -318,6 +320,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->mmu)
return -ENOMEM;
+ vdev->ipc = devm_kzalloc(vdev->drm.dev, sizeof(*vdev->ipc), GFP_KERNEL);
+ if (!vdev->ipc)
+ return -ENOMEM;
+
vdev->hw->ops = &ivpu_hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
@@ -361,8 +367,16 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_mmu_gctx_fini;
}
+ ret = ivpu_ipc_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize IPC: %d\n", ret);
+ goto err_mmu_fini;
+ }
+
return 0;
+err_mmu_fini:
+ ivpu_mmu_fini(vdev);
err_mmu_gctx_fini:
ivpu_mmu_global_context_fini(vdev);
err_power_down:
@@ -378,6 +392,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_ipc_fini(vdev);
ivpu_mmu_fini(vdev);
ivpu_mmu_global_context_fini(vdev);
ivpu_irq_fini(vdev);
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.h b/drivers/gpu/drm/ivpu/ivpu_drv.h
index 6eec3eb76c2f..48e5ed442f71 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.h
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.h
@@ -73,6 +73,7 @@ struct ivpu_wa_table {
struct ivpu_hw_info;
struct ivpu_mmu_info;
+struct ivpu_ipc_info;
struct ivpu_device {
struct drm_device drm; /* Must be first */
@@ -84,6 +85,7 @@ struct ivpu_device {
struct ivpu_wa_table wa;
struct ivpu_hw_info *hw;
struct ivpu_mmu_info *mmu;
+ struct ivpu_ipc_info *ipc;
struct ivpu_mmu_context gctx;
struct xarray context_xa;
diff --git a/drivers/gpu/drm/ivpu/ivpu_hw_mtl.c
b/drivers/gpu/drm/ivpu/ivpu_hw_mtl.c
index 525b57c4029c..5e31aec36bfa 100644
--- a/drivers/gpu/drm/ivpu/ivpu_hw_mtl.c
+++ b/drivers/gpu/drm/ivpu/ivpu_hw_mtl.c
@@ -7,6 +7,7 @@
#include "ivpu_hw_mtl_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#define TILE_FUSE_ENABLE_BOTH 0x0
@@ -931,6 +932,9 @@ static irqreturn_t ivpu_hw_mtl_irqv_handler(struct
ivpu_device *vdev, int irq)
REGV_WR32(MTL_VPU_HOST_SS_ICB_CLEAR_0, status);
+ if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, HOST_IPC_FIFO_INT,
status))
+ ret &= ivpu_ipc_irq_handler(vdev);
+
if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_0_INT, status))
ret &= ivpu_mmu_irq_evtq_handler(vdev);
diff --git a/drivers/gpu/drm/ivpu/ivpu_ipc.c b/drivers/gpu/drm/ivpu/ivpu_ipc.c
new file mode 100644
index ..9eac5d25f3ea
--- /dev/null
+++ b/drivers/gpu/drm/ivpu/ivpu_ipc.c
@@ -0,0 +1,499 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2020-2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ivpu_drv.h"
+#include "ivpu_gem.h"
+#include "ivpu_hw.h"
+#include "ivpu_hw_reg_io.h"
+#include "ivpu_i
[PATCH v3 6/7] drm/ivpu: Add command buffer submission logic
Each of the user contexts has two command queues, one for compute engine
and one for the copy engine. Command queues are allocated and registered
in the device when the first job (command buffer) is submitted from
the user space to the VPU device. The userspace provides a list of
GEM buffer object handles to submit to the VPU, the driver resolves
buffer handles, pins physical memory if needed, increments ref count
for each buffer and stores pointers to buffer objects in
the ivpu_job objects that track jobs submitted to the device.
The VPU signals job completion with an asynchronous message that
contains the job id passed to firmware when the job was submitted.
Currently, the driver supports simple scheduling logic
where jobs submitted from user space are immediately pushed
to the VPU device command queues. In the future, it will be
extended to use hardware base scheduling and/or drm_sched.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Jacek Lawrynowicz
---
drivers/gpu/drm/ivpu/Makefile | 1 +
drivers/gpu/drm/ivpu/ivpu_drv.c | 26 +-
drivers/gpu/drm/ivpu/ivpu_drv.h | 6 +-
drivers/gpu/drm/ivpu/ivpu_gem.c | 13 +
drivers/gpu/drm/ivpu/ivpu_job.c | 617
drivers/gpu/drm/ivpu/ivpu_job.h | 73
include/uapi/drm/ivpu_drm.h | 96 +
7 files changed, 828 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/ivpu/ivpu_job.c
create mode 100644 drivers/gpu/drm/ivpu/ivpu_job.h
diff --git a/drivers/gpu/drm/ivpu/Makefile b/drivers/gpu/drm/ivpu/Makefile
index 8e9b3ae1a4cc..e87d8182c5c7 100644
--- a/drivers/gpu/drm/ivpu/Makefile
+++ b/drivers/gpu/drm/ivpu/Makefile
@@ -7,6 +7,7 @@ intel_vpu-y := \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
+ ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/gpu/drm/ivpu/ivpu_drv.c b/drivers/gpu/drm/ivpu/ivpu_drv.c
index 67384671092e..51e1f124139a 100644
--- a/drivers/gpu/drm/ivpu/ivpu_drv.c
+++ b/drivers/gpu/drm/ivpu/ivpu_drv.c
@@ -19,6 +19,7 @@
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_job.h"
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -78,8 +79,11 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
- if (file_priv->ctx.id)
+ if (file_priv->ctx.id) {
+ ivpu_cmdq_release_all(file_priv);
+ ivpu_bo_remove_all_bos_from_context(&file_priv->ctx);
ivpu_mmu_user_context_fini(file_priv);
+ }
kfree(file_priv);
}
@@ -222,6 +226,8 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(IVPU_BO_USERPTR, ivpu_bo_userptr_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_SUBMIT, ivpu_submit_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_WAIT, ivpu_bo_wait_ioctl, DRM_RENDER_ALLOW),
};
DEFINE_DRM_GEM_FOPS(ivpu_fops);
@@ -428,6 +434,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
vdev->context_xa_limit.max = IVPU_CONTEXT_LIMIT;
+ xa_init_flags(&vdev->submitted_jobs_xa, XA_FLAGS_ALLOC1);
atomic64_set(&vdev->unique_id_counter, 0);
ret = ivpu_pci_init(vdev);
@@ -478,20 +485,30 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_fini;
}
+ ret = ivpu_job_done_thread_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize job done thread: %d\n",
ret);
+ goto err_ipc_fini;
+ }
+
ret = ivpu_fw_load(vdev);
if (ret) {
ivpu_err(vdev, "Failed to load firmware: %d\n", ret);
- goto err_fw_fini;
+ goto err_job_done_thread_fini;
}
ret = ivpu_boot(vdev);
if (ret) {
ivpu_err(vdev, "Failed to boot: %d\n", ret);
- goto err_fw_fini;
+ goto err_job_done_thread_fini;
}
return 0;
+err_job_done_thread_fini:
+ ivpu_job_done_thread_fini(vdev);
+err_ipc_fini:
+ ivpu_ipc_fini(vdev);
err_fw_fini:
ivpu_fw_fini(vdev);
err_mmu_fini:
@@ -511,6 +528,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_job_done_thread_fini(vdev);
ivpu_ipc_fini(vdev);
ivpu_fw_fini(vdev);
ivpu_mmu_fini(vdev);
@@ -520,6 +538,8 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
WARN_ON(!xa_empty(&vdev->context_xa));
xa_destroy(&vdev->context_xa);
+ WARN_ON(!xa_empty(&vdev->submitted_jobs_xa));
+ xa_destroy(&vdev->submitted_jobs_xa);
}
static struct pci_device_id ivpu_pci_ids[] = {
Re: [PATCH v7 06/12] dt-bindings: display/msm: split dpu-sc7180 into DPU and MDSS parts
On Thu, 22 Sept 2022 at 10:08, Krzysztof Kozlowski
wrote:
>
> On 15/09/2022 15:37, Dmitry Baryshkov wrote:
> > In order to make the schema more readable, split dpu-sc7180 into the DPU
> > and MDSS parts, each one describing just a single device binding.
> >
> > Signed-off-by: Dmitry Baryshkov
>
>
> Thank you for your patch. There is something to discuss/improve.
>
> > +---
> > +$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-dpu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm Display DPU dt properties for SC7180 target
> > +
> > +maintainers:
> > + - Krishna Manikandan
> > +
>
> missing allOf
>
> > +$ref: /schemas/display/msm/dpu-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - const: qcom,sc7180-dpu
> > +
> > + reg:
> > +items:
> > + - description: Address offset and size for mdp register set
> > + - description: Address offset and size for vbif register set
> > +
> > + reg-names:
> > +items:
> > + - const: mdp
> > + - const: vbif
> > +
> > + clocks:
> > +items:
> > + - description: Display hf axi clock
> > + - description: Display ahb clock
> > + - description: Display rotator clock
> > + - description: Display lut clock
> > + - description: Display core clock
> > + - description: Display vsync clock
> > +
> > + clock-names:
> > +items:
> > + - const: bus
> > + - const: iface
> > + - const: rot
> > + - const: lut
> > + - const: core
> > + - const: vsync
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +
> > +display-controller@ae01000 {
> > +compatible = "qcom,sc7180-dpu";
> > +reg = <0x0ae01000 0x8f000>,
> > + <0x0aeb 0x2008>;
> > +
> > +reg-names = "mdp", "vbif";
> > +
> > +clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
> > + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> > + <&dispcc DISP_CC_MDSS_ROT_CLK>,
> > + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
> > + <&dispcc DISP_CC_MDSS_MDP_CLK>,
> > + <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> > +clock-names = "bus", "iface", "rot", "lut", "core",
> > + "vsync";
> > +
> > +interrupt-parent = <&mdss>;
> > +interrupts = <0>;
> > +power-domains = <&rpmhpd SC7180_CX>;
> > +operating-points-v2 = <&mdp_opp_table>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +endpoint {
> > +remote-endpoint = <&dsi0_in>;
> > +};
> > +};
> > +
> > +port@2 {
> > +reg = <2>;
> > +endpoint {
> > +remote-endpoint = <&dp_in>;
> > +};
> > +};
> > +};
> > +};
> > +...
> > diff --git
> > a/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> > b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> > new file mode 100644
> > index ..e507c091b60f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sc7180-mdss.yaml
> > @@ -0,0 +1,84 @@
> > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/msm/qcom,sc7180-mdss.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm SC7180 Display MDSS
> > +
> > +maintainers:
> > + - Krishna Manikandan
> > +
> > +description:
> > + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that
> > encapsulates
> > + sub-blocks like DPU display controller, DSI and DP interfaces etc.
> > Device tree
> > + bindings of MDSS are mentioned for SC7180 target.
> > +
>
> missing allOf.
>
> > +$ref: /schemas/display/msm/mdss-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - const: qcom,sc7180-mdss
> > +
> > + clocks:
> > +items:
> > + - description: Display AHB clock from gcc
> > + - description: Display AHB clock from dispcc
> > + - description: Display core clock
> > +
> > + clock-names:
> > +items:
> > + - const: iface
> > + - const: ahb
> > + - const: core
> > +
> > + iommus:
> > +maxItems: 1
> > +
> > + interconnects:
> > +maxItems: 1
> > +
> > + interconnect-names:
> > +maxItems: 1
> > +
> > +patternProperties:
> > + "^display-controller@[0-9a-f]+$":
> > +type: object
> > +properties:
> > + compatible:
> > +const: qcom,sc7180-dpu
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +display-subsystem@ae0 {
> > +
Re: [PATCH AUTOSEL 5.4 3/5] drm/amdgpu: use dirty framebuffer helper
On 2022-09-21 17:54, Sasha Levin wrote:
> From: Hamza Mahfooz
>
> [ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
>
> Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
> drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
> struct.
>
> Signed-off-by: Hamza Mahfooz
> Acked-by: Alex Deucher
> Signed-off-by: Alex Deucher
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index b588e0e409e7..d8687868407d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -495,6 +496,7 @@ bool amdgpu_display_ddc_probe(struct amdgpu_connector
> *amdgpu_connector,
> static const struct drm_framebuffer_funcs amdgpu_fb_funcs = {
> .destroy = drm_gem_fb_destroy,
> .create_handle = drm_gem_fb_create_handle,
> + .dirty = drm_atomic_helper_dirtyfb,
> };
>
> uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev,
This patch has issues, see https://patchwork.freedesktop.org/patch/503749/ .
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Re: [PATCH 01/12] slab: Introduce kmalloc_size_roundup()
On Wed, Sep 21, 2022 at 08:10:02PM -0700, Kees Cook wrote: > In the effort to help the compiler reason about buffer sizes, the > __alloc_size attribute was added to allocators. This improves the scope > of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near > future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well, > as the vast majority of callers are not expecting to use more memory > than what they asked for. > > There is, however, one common exception to this: anticipatory resizing > of kmalloc allocations. These cases all use ksize() to determine the > actual bucket size of a given allocation (e.g. 128 when 126 was asked > for). This comes in two styles in the kernel: > > 1) An allocation has been determined to be too small, and needs to be >resized. Instead of the caller choosing its own next best size, it >wants to minimize the number of calls to krealloc(), so it just uses >ksize() plus some additional bytes, forcing the realloc into the next >bucket size, from which it can learn how large it is now. For example: > > data = krealloc(data, ksize(data) + 1, gfp); > data_len = ksize(data); > > 2) The minimum size of an allocation is calculated, but since it may >grow in the future, just use all the space available in the chosen >bucket immediately, to avoid needing to reallocate later. A good >example of this is skbuff's allocators: > > data = kmalloc_reserve(size, gfp_mask, node, &pfmemalloc); > ... > /* kmalloc(size) might give us more room than requested. >* Put skb_shared_info exactly at the end of allocated zone, >* to allow max possible filling before reallocation. >*/ > osize = ksize(data); > size = SKB_WITH_OVERHEAD(osize); > > In both cases, the "how large is the allocation?" question is answered > _after_ the allocation, where the compiler hinting is not in an easy place > to make the association any more. This mismatch between the compiler's > view of the buffer length and the code's intention about how much it is > going to actually use has already caused problems[1]. It is possible to > fix this by reordering the use of the "actual size" information. > > We can serve the needs of users of ksize() and still have accurate buffer > length hinting for the compiler by doing the bucket size calculation > _before_ the allocation. Code can instead ask "how large an allocation > would I get for a given size?". > > Introduce kmalloc_size_roundup(), to serve this function so we can start > replacing the "anticipatory resizing" uses of ksize(). > Cc-ing Feng Tang who may welcome this series ;) > [1] https://github.com/ClangBuiltLinux/linux/issues/1599 > https://github.com/KSPP/linux/issues/183 > > Cc: Vlastimil Babka > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton > Cc: linux...@kvack.org > Signed-off-by: Kees Cook > --- > include/linux/slab.h | 31 +++ > mm/slab_common.c | 17 + > 2 files changed, 48 insertions(+) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 0fefdf528e0d..4fc41e4ed4a2 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -188,7 +188,21 @@ void * __must_check krealloc(const void *objp, size_t > new_size, gfp_t flags) __a > void kfree(const void *objp); > void kfree_sensitive(const void *objp); > size_t __ksize(const void *objp); > + > +/** > + * ksize - Report actual allocation size of associated object > + * > + * @objp: Pointer returned from a prior kmalloc()-family allocation. > + * > + * This should not be used for writing beyond the originally requested > + * allocation size. Either use krealloc() or round up the allocation size > + * with kmalloc_size_roundup() prior to allocation. If this is used to > + * access beyond the originally requested allocation size, UBSAN_BOUNDS > + * and/or FORTIFY_SOURCE may trip, since they only know about the > + * originally allocated size via the __alloc_size attribute. > + */ > size_t ksize(const void *objp); When users call ksize(), slab expects that it may access beyond the originally requested allocation size. (i.e. KASAN unpoisons the whole object.) Maybe don't let KASAN unpoison to catch such users? > + > #ifdef CONFIG_PRINTK > bool kmem_valid_obj(void *object); > void kmem_dump_obj(void *object); > @@ -779,6 +793,23 @@ extern void kvfree(const void *addr); > extern void kvfree_sensitive(const void *addr, size_t len); > > unsigned int kmem_cache_size(struct kmem_cache *s); > + > +/** > + * kmalloc_size_roundup - Report allocation bucket size for the given size > + * > + * @size: Number of bytes to round up from. > + * > + * This returns the number of bytes that would be available in a kmalloc() > + * allocation of @size bytes. For example, a 126 byte request would be > + * rounded up to the next sized kmalloc bucket, 128 bytes. (This is strictly > + * for the g
[PATCH 2/5] drm/msm/dsi: add support for DSI 2.6.0
Add support for DSI 2.6.0 (block used on sm8450).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 7e97c239ed48..59a4cc95a251 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -300,6 +300,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
&sc7180_dsi_cfg, &msm_dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_5_0,
&sc7280_dsi_cfg, &msm_dsi_6g_v2_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_6_0,
+ &sdm845_dsi_cfg, &msm_dsi_6g_v2_host_ops},
};
const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 8f04e685a74e..95957fab499d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -25,6 +25,7 @@
#define MSM_DSI_6G_VER_MINOR_V2_4_00x2004
#define MSM_DSI_6G_VER_MINOR_V2_4_10x20040001
#define MSM_DSI_6G_VER_MINOR_V2_5_00x2005
+#define MSM_DSI_6G_VER_MINOR_V2_6_00x2006
#define MSM_DSI_V2_VER_MINOR_8064 0x0
--
2.35.1
[PATCH 3/5] drm/msm/dpu: add support for MDP_TOP blackhole
On sm8450 a register block was removed from MDP TOP. Accessing it during
snapshotting results in NoC errors / immediate reboot. Skip accessing
these registers during snapshot.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 38aa38ab1568..4730f8268f2a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -92,6 +92,7 @@ enum {
DPU_MDP_UBWC_1_0,
DPU_MDP_UBWC_1_5,
DPU_MDP_AUDIO_SELECT,
+ DPU_MDP_PERIPH_0_REMOVED,
DPU_MDP_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 5e6e2626151e..b0bb693c10ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -939,8 +939,15 @@ static void dpu_kms_mdp_snapshot(struct msm_disp_state
*disp_state, struct msm_k
msm_disp_snapshot_add_block(disp_state, cat->wb[i].len,
dpu_kms->mmio + cat->wb[i].base, "wb_%d", i);
- msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len,
- dpu_kms->mmio + cat->mdp[0].base, "top");
+ if (top->caps->features & BIT(DPU_MDP_PERIPH_0_REMOVED)) {
+ msm_disp_snapshot_add_block(disp_state, 0x380,
+ dpu_kms->mmio + cat->mdp[0].base, "top");
+ msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len - 0x3a8,
+ dpu_kms->mmio + cat->mdp[0].base + 0x3a8,
"top_2");
+ } else {
+ msm_disp_snapshot_add_block(disp_state, cat->mdp[0].len,
+ dpu_kms->mmio + cat->mdp[0].base, "top");
+ }
pm_runtime_put_sync(&dpu_kms->pdev->dev);
}
--
2.35.1
[PATCH 0/5] drm/msm: add support for SM8450
This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform. Dmitry Baryshkov (5): drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450 drm/msm/dsi: add support for DSI 2.6.0 drm/msm/dpu: add support for MDP_TOP blackhole drm/msm/dpu: add support for SM8450 drm/msm: mdss add support for SM8450 drivers/gpu/drm/msm/Kconfig | 6 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +- drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 132 ++- drivers/gpu/drm/msm/msm_mdss.c| 8 + 11 files changed, 381 insertions(+), 15 deletions(-) -- 2.35.1
[PATCH 5/5] drm/msm: mdss add support for SM8450
Add support for the MDSS block on SM8450 platform.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index e13c5c12b775..9e011762396b 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -219,6 +219,13 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
case DPU_HW_VER_720:
writel_relaxed(0x101e, msm_mdss->mmio + UBWC_STATIC);
break;
+ case DPU_HW_VER_810:
+ /* FIXME: merge with 6.0.0? */
+ /* TODO: 0x102e for LP_DDR4 */
+ writel_relaxed(0x103e, msm_mdss->mmio + UBWC_STATIC);
+ writel_relaxed(2, msm_mdss->mmio + UBWC_CTRL_2);
+ writel_relaxed(1, msm_mdss->mmio + UBWC_PREDICTION_MODE);
+ break;
}
return ret;
@@ -447,6 +454,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sc8180x-mdss" },
{ .compatible = "qcom,sm8150-mdss" },
{ .compatible = "qcom,sm8250-mdss" },
+ { .compatible = "qcom,sm8450-mdss" },
{}
};
MODULE_DEVICE_TABLE(of, mdss_dt_match);
--
2.35.1
[PATCH 1/5] drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
Co-developed-by: Robert Foss
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 6 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 132 --
4 files changed, 131 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 4e0cbd682725..e6c5dfbad009 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -140,12 +140,12 @@ config DRM_MSM_DSI_10NM_PHY
Choose this option if DSI PHY on SDM845 is used on the platform.
config DRM_MSM_DSI_7NM_PHY
- bool "Enable DSI 7nm PHY driver in MSM DRM"
+ bool "Enable DSI 7nm/5nm PHY driver in MSM DRM"
depends on DRM_MSM_DSI
default y
help
- Choose this option if DSI PHY on SM8150/SM8250/SC7280 is used on
- the platform.
+ Choose this option if DSI PHY on SM8150/SM8250/SM8350/SM8450/SC7280
+ is used on the platform.
config DRM_MSM_HDMI
bool "Enable HDMI support in MSM DRM driver"
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 7fc0975cb869..97cf6b8b34cc 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -567,6 +567,10 @@ static const struct of_device_id dsi_phy_dt_match[] = {
.data = &dsi_phy_7nm_8150_cfgs },
{ .compatible = "qcom,sc7280-dsi-phy-7nm",
.data = &dsi_phy_7nm_7280_cfgs },
+ { .compatible = "qcom,dsi-phy-5nm-8350",
+ .data = &dsi_phy_5nm_8350_cfgs },
+ { .compatible = "qcom,dsi-phy-5nm-8450",
+ .data = &dsi_phy_5nm_8450_cfgs },
#endif
{}
};
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 60a99c6525b2..654cbfa14d6e 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -56,6 +56,8 @@ extern const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_7nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_7nm_8150_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_7nm_7280_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_5nm_8350_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_5nm_8450_cfgs;
struct msm_dsi_dphy_timing {
u32 clk_zero;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
index 9e7fa7d88ead..1696ff150b9e 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
@@ -39,8 +39,14 @@
#define VCO_REF_CLK_RATE 1920
#define FRAC_BITS 18
+/* Hardware is pre V4.1 */
+#define DSI_PHY_7NM_QUIRK_PRE_V4_1 BIT(0)
/* Hardware is V4.1 */
-#define DSI_PHY_7NM_QUIRK_V4_1 BIT(0)
+#define DSI_PHY_7NM_QUIRK_V4_1 BIT(1)
+/* Hardware is V4.2 */
+#define DSI_PHY_7NM_QUIRK_V4_2 BIT(2)
+/* Hardware is V4.3 */
+#define DSI_PHY_7NM_QUIRK_V4_3 BIT(3)
struct dsi_pll_config {
bool enable_ssc;
@@ -116,7 +122,7 @@ static void dsi_pll_calc_dec_frac(struct dsi_pll_7nm *pll,
struct dsi_pll_config
dec_multiple = div_u64(pll_freq * multiplier, divider);
dec = div_u64_rem(dec_multiple, multiplier, &frac);
- if (!(pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_V4_1))
+ if (pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_PRE_V4_1)
config->pll_clock_inverters = 0x28;
else if (pll_freq <= 10ULL)
config->pll_clock_inverters = 0xa0;
@@ -197,16 +203,25 @@ static void dsi_pll_config_hzindep_reg(struct dsi_pll_7nm
*pll)
void __iomem *base = pll->phy->pll_base;
u8 analog_controls_five_1 = 0x01, vco_config_1 = 0x00;
- if (pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_V4_1) {
+ if (!(pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_PRE_V4_1))
if (pll->vco_current_rate >= 31ULL)
analog_controls_five_1 = 0x03;
+ if (pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_V4_1) {
if (pll->vco_current_rate < 152000ULL)
vco_config_1 = 0x08;
else if (pll->vco_current_rate < 299000ULL)
vco_config_1 = 0x01;
}
+ if ((pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_V4_2) ||
+ (pll->phy->cfg->quirks & DSI_PHY_7NM_QUIRK_V4_3)) {
+ if (pll->vco_current_rate < 152000ULL)
+ vco_config_1 = 0x08;
+ else if (pll->vco_current_rate >= 299000ULL)
+ vco_config_1 = 0x01;
+ }
+
dsi_phy_write(base + REG_DSI_7nm_PHY_PLL_ANALOG_CONTROLS_FIVE_1,
[PATCH 4/5] drm/msm/dpu: add support for SM8450
Add definitions for the display hardware used on Qualcomm SM8450
platform.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
4 files changed, 229 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 27f029fdc682..c647ea1207be 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -124,6 +124,15 @@
BIT(MDP_AD4_0_INTR) | \
BIT(MDP_AD4_1_INTR))
+#define IRQ_SM8450_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+BIT(MDP_SSPP_TOP0_INTR2) | \
+BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+BIT(MDP_INTF0_7xxx_INTR) | \
+BIT(MDP_INTF1_7xxx_INTR) | \
+BIT(MDP_INTF2_7xxx_INTR) | \
+BIT(MDP_INTF3_7xxx_INTR) | \
+0)
+
#define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
BIT(DPU_WB_UBWC) | \
BIT(DPU_WB_YUV_CONFIG) | \
@@ -364,6 +373,20 @@ static const struct dpu_caps sm8250_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps sm8450_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .qseed_type = DPU_SSPP_SCALER_QSEED4,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_caps sc7280_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0x7,
@@ -501,6 +524,33 @@ static const struct dpu_mdp_cfg sm8250_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sm8450_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+ .reg_off = 0x2B4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+ .reg_off = 0x2BC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+ .reg_off = 0x2C4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+ .reg_off = 0x2B4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .reg_off = 0x2BC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .reg_off = 0x2C4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
+ .reg_off = 0x2BC, .bit_off = 20},
+ },
+};
+
static const struct dpu_mdp_cfg sc7280_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -659,6 +709,45 @@ static const struct dpu_ctl_cfg sm8150_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sm8450_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY) |
BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY) |
BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ },
+ {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x19000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+ },
+ {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a000, .len = 0x204,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_FETCH_ACTIVE),
+ .intr_start = DPU_IRQ_IDX
[PATCH v3 2/4] drm/ofdrm: Add CRTC state
Add a dedicated CRTC state to ofdrm to later store information for
palette updates.
v3:
* rework CRTC state helpers (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 59 ++--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 5ac9aa769513..a78aee800956 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -279,6 +279,21 @@ static struct resource *ofdrm_find_fb_resource(struct
ofdrm_device *odev,
* Modesetting
*/
+struct ofdrm_crtc_state {
+ struct drm_crtc_state base;
+};
+
+static struct ofdrm_crtc_state *to_ofdrm_crtc_state(struct drm_crtc_state
*base)
+{
+ return container_of(base, struct ofdrm_crtc_state, base);
+}
+
+static void ofdrm_crtc_state_destroy(struct ofdrm_crtc_state *ofdrm_crtc_state)
+{
+ __drm_atomic_helper_crtc_destroy_state(&ofdrm_crtc_state->base);
+ kfree(ofdrm_crtc_state);
+}
+
/*
* Support all formats of OF display and maybe more; in order
* of preference. The display's update function will do any
@@ -429,13 +444,51 @@ static const struct drm_crtc_helper_funcs
ofdrm_crtc_helper_funcs = {
.atomic_check = ofdrm_crtc_helper_atomic_check,
};
+static void ofdrm_crtc_reset(struct drm_crtc *crtc)
+{
+ struct ofdrm_crtc_state *ofdrm_crtc_state =
+ kzalloc(sizeof(*ofdrm_crtc_state), GFP_KERNEL);
+
+ if (crtc->state)
+ ofdrm_crtc_state_destroy(to_ofdrm_crtc_state(crtc->state));
+
+ if (ofdrm_crtc_state)
+ __drm_atomic_helper_crtc_reset(crtc, &ofdrm_crtc_state->base);
+ else
+ __drm_atomic_helper_crtc_reset(crtc, NULL);
+}
+
+static struct drm_crtc_state *ofdrm_crtc_atomic_duplicate_state(struct
drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *crtc_state = crtc->state;
+ struct ofdrm_crtc_state *new_ofdrm_crtc_state;
+
+ if (drm_WARN_ON(dev, !crtc_state))
+ return NULL;
+
+ new_ofdrm_crtc_state = kzalloc(sizeof(*new_ofdrm_crtc_state),
GFP_KERNEL);
+ if (!new_ofdrm_crtc_state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc,
&new_ofdrm_crtc_state->base);
+
+ return &new_ofdrm_crtc_state->base;
+}
+
+static void ofdrm_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *crtc_state)
+{
+ ofdrm_crtc_state_destroy(to_ofdrm_crtc_state(crtc_state));
+}
+
static const struct drm_crtc_funcs ofdrm_crtc_funcs = {
- .reset = drm_atomic_helper_crtc_reset,
+ .reset = ofdrm_crtc_reset,
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .atomic_duplicate_state = ofdrm_crtc_atomic_duplicate_state,
+ .atomic_destroy_state = ofdrm_crtc_atomic_destroy_state,
};
static int ofdrm_connector_helper_get_modes(struct drm_connector *connector)
--
2.37.3
[PATCH v3 0/4] drm: Add driver for PowerPC OF displays
PowerPC's Open Firmware offers a simple display buffer for graphics output. Add ofdrm, a DRM driver for the device. As with the existing simpledrm driver, the graphics hardware is pre-initialized by the firmware. The driver only provides blitting, no actual DRM modesetting is possible. For version 3 of this patchset, all preparatory changes have been merged into the DRM codebase. Only ofdrm changes are left. Patch 1 adds ofdrm, which has again been significantly reworked. The FWFB library has been removed infavor of various functions in existing DRM helper libraries. Ofdrm now supports damage iterators and synchronization for imported GEM BOs. Patches 2 to 4 add support for color management. The code has been taken from fbdev's offb. I have no hardware available for testing the functionality. Qemu's stdvga apparently does not support gamma tables in RGB modes. I verified that the color management code is executed by running Gnome's night-mode settings, but the display's color tone does not change. Thomas Zimmermann (4): drm/ofdrm: Add ofdrm for Open Firmware framebuffers drm/ofdrm: Add CRTC state drm/ofdrm: Add per-model device function drm/ofdrm: Support color management MAINTAINERS |1 + drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile |1 + drivers/gpu/drm/tiny/ofdrm.c | 1351 + drivers/video/fbdev/Kconfig |1 + 5 files changed, 1367 insertions(+) create mode 100644 drivers/gpu/drm/tiny/ofdrm.c base-commit: a7d5d07d5ac5ac58ec81932b3f732e3127d17af9 -- 2.37.3
[PATCH v3 3/4] drm/ofdrm: Add per-model device function
Add a per-model device-function structure in preparation of adding
color-management support. Detection of the individual models has been
taken from fbdev's offb.
v3:
* define constants for PCI ids (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 125 +++
1 file changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index a78aee800956..9a8e5696999c 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -28,6 +28,21 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+#define PCI_VENDOR_ID_ATI_R520 0x7100
+#define PCI_VENDOR_ID_ATI_R600 0x9400
+
+enum ofdrm_model {
+ OFDRM_MODEL_UNKNOWN,
+ OFDRM_MODEL_MACH64, /* ATI Mach64 */
+ OFDRM_MODEL_RAGE128, /* ATI Rage128 */
+ OFDRM_MODEL_RAGE_M3A, /* ATI Rage Mobility M3 Head A */
+ OFDRM_MODEL_RAGE_M3B, /* ATI Rage Mobility M3 Head B */
+ OFDRM_MODEL_RADEON, /* ATI Radeon */
+ OFDRM_MODEL_GXT2000, /* IBM GXT2000 */
+ OFDRM_MODEL_AVIVO, /* ATI R5xx */
+ OFDRM_MODEL_QEMU, /* QEMU VGA */
+};
+
/*
* Helpers for display nodes
*/
@@ -149,14 +164,63 @@ static u64 display_get_address_of(struct drm_device *dev,
struct device_node *of
return address;
}
+static bool is_avivo(__be32 vendor, __be32 device)
+{
+ /* This will match most R5xx */
+ return (vendor == PCI_VENDOR_ID_ATI) &&
+ ((device >= PCI_VENDOR_ID_ATI_R520 && device < 0x7800) ||
+ (PCI_VENDOR_ID_ATI_R600 >= 0x9400));
+}
+
+static enum ofdrm_model display_get_model_of(struct drm_device *dev, struct
device_node *of_node)
+{
+ enum ofdrm_model model = OFDRM_MODEL_UNKNOWN;
+
+ if (of_node_name_prefix(of_node, "ATY,Rage128")) {
+ model = OFDRM_MODEL_RAGE128;
+ } else if (of_node_name_prefix(of_node, "ATY,RageM3pA") ||
+ of_node_name_prefix(of_node, "ATY,RageM3p12A")) {
+ model = OFDRM_MODEL_RAGE_M3A;
+ } else if (of_node_name_prefix(of_node, "ATY,RageM3pB")) {
+ model = OFDRM_MODEL_RAGE_M3B;
+ } else if (of_node_name_prefix(of_node, "ATY,Rage6")) {
+ model = OFDRM_MODEL_RADEON;
+ } else if (of_node_name_prefix(of_node, "ATY,")) {
+ return OFDRM_MODEL_MACH64;
+ } else if (of_device_is_compatible(of_node, "pci1014,b7") ||
+ of_device_is_compatible(of_node, "pci1014,21c")) {
+ model = OFDRM_MODEL_GXT2000;
+ } else if (of_node_name_prefix(of_node, "vga,Display-")) {
+ struct device_node *of_parent;
+ const __be32 *vendor_p, *device_p;
+
+ /* Look for AVIVO initialized by SLOF */
+ of_parent = of_get_parent(of_node);
+ vendor_p = of_get_property(of_parent, "vendor-id", NULL);
+ device_p = of_get_property(of_parent, "device-id", NULL);
+ if (vendor_p && device_p && is_avivo(*vendor_p, *device_p))
+ model = OFDRM_MODEL_AVIVO;
+ of_node_put(of_parent);
+ } else if (of_device_is_compatible(of_node, "qemu,std-vga")) {
+ model = OFDRM_MODEL_QEMU;
+ }
+
+ return model;
+}
+
/*
* Open Firmware display device
*/
+struct ofdrm_device_funcs {
+};
+
struct ofdrm_device {
struct drm_device dev;
struct platform_device *pdev;
+ const struct ofdrm_device_funcs *funcs;
+
/* simplefb settings */
struct iosys_map screen_base;
struct drm_display_mode mode;
@@ -520,6 +584,33 @@ static const struct drm_mode_config_funcs
ofdrm_mode_config_funcs = {
* Init / Cleanup
*/
+static const struct ofdrm_device_funcs ofdrm_unknown_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_mach64_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_rage128_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_rage_m3a_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_rage_m3b_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_radeon_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_gxt2000_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_avivo_device_funcs = {
+};
+
+static const struct ofdrm_device_funcs ofdrm_qemu_device_funcs = {
+};
+
static struct drm_display_mode ofdrm_mode(unsigned int width, unsigned int
height)
{
/*
@@ -541,6 +632,7 @@ static struct ofdrm_device *ofdrm_device_create(struct
drm_driver *drv,
struct device_node *of_node = pdev->dev.of_node;
struct ofdrm_device *odev;
struct drm_device *dev;
+ enum ofdrm_model model;
int width, height, linebytes;
const struct drm_format_info *format;
u64 address;
@@ -569,6 +661,39 @@ static struct ofdrm_device *ofdrm_device_create(struct
drm_
[PATCH v3 1/4] drm/ofdrm: Add ofdrm for Open Firmware framebuffers
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the system's firmware. Runtime
modesetting via DRM is not possible. The display is useful during
early boot stages or as error fallback.
Similar functionality is already provided by fbdev's offb driver,
which is insufficient for modern userspace. The old driver includes
support for BootX device tree, which can be found on old 32-bit
PowerPC Macintosh systems. If these are still in use, the
functionality can be added to ofdrm or implemented in a new
driver. As with simpledrm, the fbdev driver cannot be selected if
ofdrm is already enabled.
Two notable points about the driver:
* Reading the framebuffer aperture from the device tree is not
reliable on all systems. Ofdrm takes the heuristics and a comment
from offb to pick the correct range.
* No resource management may be tied to the underlying PCI device.
Otherwise the handover to the native driver will fail with a resource
conflict. PCI management is therefore done as part of the platform
device's cleanup.
The driver has been tested on qemu's ppc64le emulation. The device
hand-over has been tested with bochs.
v3:
* reintegrate FWFB helpers into ofdrm
* use damage iterator
* sync GEM BOs with drm_gem_fb_{begin,end}_cpu_access()
* fix various atomic_check helpers
* remove CRTC atomic_{enable,disable} (Javier)
* compute stride with drm_format_info_min_pitch() (Daniel)
v2:
* removed simple-pipe helpers
* built driver on top of FWFB helpers
* merged all init code into single function
* make PCI support optional (Michal)
* support COMPILE_TEST (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
MAINTAINERS | 1 +
drivers/gpu/drm/tiny/Kconfig | 13 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ofdrm.c | 741 ++
drivers/video/fbdev/Kconfig | 1 +
5 files changed, 757 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ofdrm.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5dea02ce7b24..55f3a9def47f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6655,6 +6655,7 @@ L:dri-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/drm_aperture.c
+F: drivers/gpu/drm/tiny/ofdrm.c
F: drivers/gpu/drm/tiny/simpledrm.c
F: drivers/video/aperture.c
F: include/drm/drm_aperture.h
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 565957264875..a300b03a3c7a 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -51,6 +51,19 @@ config DRM_GM12U320
This is a KMS driver for projectors which use the GM12U320 chipset
for video transfer over USB2/3, such as the Acer C120 mini projector.
+config DRM_OFDRM
+ tristate "Open Firmware display driver"
+ depends on DRM && OF && (PPC || COMPILE_TEST)
+ select APERTURE_HELPERS
+ select DRM_GEM_SHMEM_HELPER
+ select DRM_KMS_HELPER
+ help
+ DRM driver for Open Firmware framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the Open Firmware before the kernel boots. Scanout buffer, size,
+ and display format must be provided via device tree.
+
config DRM_PANEL_MIPI_DBI
tristate "DRM support for MIPI DBI compatible panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 1d9d6227e7ab..76dde89a044b 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ARCPGU)+= arcpgu.o
obj-$(CONFIG_DRM_BOCHS)+= bochs.o
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_OFDRM)+= ofdrm.o
obj-$(CONFIG_DRM_PANEL_MIPI_DBI) += panel-mipi-dbi.o
obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
new file mode 100644
index ..5ac9aa769513
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -0,0 +1,741 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"ofdrm"
+#define DRIVER_DESC"DRM driver for OF platform devices"
+#define DRIVER_DATE"20220501"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+/*
+ * Helpers f
[PATCH v3 4/4] drm/ofdrm: Support color management
Support the CRTC's color-management property and implement each model's
palette support.
The OF hardware has different methods of setting the palette. The
respective code has been taken from fbdev's offb and refactored into
per-model device functions. The device functions integrate this
functionality into the overall modesetting.
As palette handling is a CRTC property that depends on the primary
plane's color format, the plane's atomic_check helper now updates the
format field in ofdrm's custom CRTC state. The CRTC's atomic_flush
helper updates the palette for the format as needed.
v3:
* lookup CRTC state with drm_atomic_get_new_crtc_state()
* access HW palette with writeb(), writel(), and readl() (Ben)
* declare register values as u32
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/tiny/ofdrm.c | 442 ++-
1 file changed, 437 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 9a8e5696999c..f891588375e7 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,6 +32,33 @@
#define PCI_VENDOR_ID_ATI_R520 0x7100
#define PCI_VENDOR_ID_ATI_R600 0x9400
+#define OFDRM_GAMMA_LUT_SIZE 256
+
+/* Definitions used by the Avivo palette */
+#define AVIVO_DC_LUT_RW_SELECT 0x6480
+#define AVIVO_DC_LUT_RW_MODE0x6484
+#define AVIVO_DC_LUT_RW_INDEX 0x6488
+#define AVIVO_DC_LUT_SEQ_COLOR 0x648c
+#define AVIVO_DC_LUT_PWL_DATA 0x6490
+#define AVIVO_DC_LUT_30_COLOR 0x6494
+#define AVIVO_DC_LUT_READ_PIPE_SELECT 0x6498
+#define AVIVO_DC_LUT_WRITE_EN_MASK 0x649c
+#define AVIVO_DC_LUT_AUTOFILL 0x64a0
+#define AVIVO_DC_LUTA_CONTROL 0x64c0
+#define AVIVO_DC_LUTA_BLACK_OFFSET_BLUE 0x64c4
+#define AVIVO_DC_LUTA_BLACK_OFFSET_GREEN0x64c8
+#define AVIVO_DC_LUTA_BLACK_OFFSET_RED 0x64cc
+#define AVIVO_DC_LUTA_WHITE_OFFSET_BLUE 0x64d0
+#define AVIVO_DC_LUTA_WHITE_OFFSET_GREEN0x64d4
+#define AVIVO_DC_LUTA_WHITE_OFFSET_RED 0x64d8
+#define AVIVO_DC_LUTB_CONTROL 0x6cc0
+#define AVIVO_DC_LUTB_BLACK_OFFSET_BLUE 0x6cc4
+#define AVIVO_DC_LUTB_BLACK_OFFSET_GREEN0x6cc8
+#define AVIVO_DC_LUTB_BLACK_OFFSET_RED 0x6ccc
+#define AVIVO_DC_LUTB_WHITE_OFFSET_BLUE 0x6cd0
+#define AVIVO_DC_LUTB_WHITE_OFFSET_GREEN0x6cd4
+#define AVIVO_DC_LUTB_WHITE_OFFSET_RED 0x6cd8
+
enum ofdrm_model {
OFDRM_MODEL_UNKNOWN,
OFDRM_MODEL_MACH64, /* ATI Mach64 */
@@ -212,7 +240,14 @@ static enum ofdrm_model display_get_model_of(struct
drm_device *dev, struct devi
* Open Firmware display device
*/
+struct ofdrm_device;
+
struct ofdrm_device_funcs {
+ void __iomem *(*cmap_ioremap)(struct ofdrm_device *odev,
+ struct device_node *of_node,
+ u64 fb_bas);
+ void (*cmap_write)(struct ofdrm_device *odev, unsigned char index,
+ unsigned char r, unsigned char g, unsigned char b);
};
struct ofdrm_device {
@@ -227,6 +262,9 @@ struct ofdrm_device {
const struct drm_format_info *format;
unsigned int pitch;
+ /* colormap */
+ void __iomem *cmap_base;
+
/* modesetting */
uint32_t formats[8];
struct drm_plane primary_plane;
@@ -339,12 +377,322 @@ static struct resource *ofdrm_find_fb_resource(struct
ofdrm_device *odev,
return max_res;
}
+/*
+ * Colormap / Palette
+ */
+
+static void __iomem *get_cmap_address_of(struct ofdrm_device *odev, struct
device_node *of_node,
+int bar_no, unsigned long offset,
unsigned long size)
+{
+ struct drm_device *dev = &odev->dev;
+ const __be32 *addr_p;
+ u64 max_size, address;
+ unsigned int flags;
+ void __iomem *mem;
+
+ addr_p = of_get_pci_address(of_node, bar_no, &max_size, &flags);
+ if (!addr_p)
+ addr_p = of_get_address(of_node, bar_no, &max_size, &flags);
+ if (!addr_p)
+ return ERR_PTR(-ENODEV);
+
+ if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
+ return ERR_PTR(-ENODEV);
+
+ if ((offset + size) >= max_size)
+ return ERR_PTR(-ENODEV);
+
+ address = of_translate_address(of_node, addr_p);
+ if (address == OF_BAD_ADDR)
+ return ERR_PTR(-ENODEV);
+
+ mem = devm_ioremap(dev->dev, address + offset, size);
+ if (!mem)
+ return ERR_PTR(-ENOMEM);
+
+ return mem;
+}
+
+static void __iomem *ofdrm_mach64_cmap_ioremap(struct ofdrm_device *odev,
+
Re: [PATCH v7 04/12] dt-bindings: display/msm: move common DPU properties to dpu-common.yaml
On 22/09/2022 09:50, Dmitry Baryshkov wrote: > On Thu, 22 Sept 2022 at 10:02, Krzysztof Kozlowski > wrote: >> >> On 15/09/2022 15:37, Dmitry Baryshkov wrote: >>> Move properties common to all DPU DT nodes to the dpu-common.yaml. >>> >>> Note, this removes description of individual DPU port@ nodes. However >>> such definitions add no additional value. The reg values do not >>> correspond to hardware INTF indices. The driver discovers and binds >>> these ports not paying any care for the order of these items. Thus just >>> leave the reference to graph.yaml#/properties/ports and the description. >> >> This is okay, but you loose required:ports@[01]. > > This is fine for me. The ports do not have 1:1 correspondence to > intfs. Usually platforms add ports as new sinks are added. For example > a platform can start with a single DSI node and later get second DSI, > DP, eDP, etc. as they are receiving support/required by end-user > devices. Then at least port@0 would be required. Node without ports does not look correct. Best regards, Krzysztof
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 22/09/2022 09:53, Dmitry Baryshkov wrote: > On Thu, 22 Sept 2022 at 10:05, Krzysztof Kozlowski > wrote: >> >> On 15/09/2022 15:37, Dmitry Baryshkov wrote: >>> Move properties common to all MDSS DT nodes to the mdss-common.yaml. >>> >>> This extends qcom,msm8998-mdss schema to allow interconnect nodes, which >>> will be added later, once msm8998 gains interconnect support. >>> >>> Signed-off-by: Dmitry Baryshkov >>> --- >>> .../bindings/display/msm/dpu-msm8998.yaml | 41 + >>> .../bindings/display/msm/dpu-qcm2290.yaml | 51 ++-- >>> .../bindings/display/msm/dpu-sc7180.yaml | 50 ++- >>> .../bindings/display/msm/dpu-sc7280.yaml | 50 ++- >>> .../bindings/display/msm/dpu-sdm845.yaml | 54 ++-- >>> .../bindings/display/msm/mdss-common.yaml | 83 +++ >>> 6 files changed, 111 insertions(+), 218 deletions(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/msm/mdss-common.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml >>> b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml >>> index 200eeace1c71..67791dbc3b5d 100644 >>> --- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml >>> +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml >>> @@ -14,20 +14,13 @@ description: | >>>sub-blocks like DPU display controller, DSI and DP interfaces etc. >>> Device tree >>>bindings of MDSS and DPU are mentioned for MSM8998 target. >>> >> >> missing allOf > > Rob asked to remove this while reviewing v6 ([1]). And indeed the > allOf's around a single $ref do not seem to be necessary He commented on one of properties, not top-level, maybe it is different case for dtschema. In the past it was required, so are you sure something changed in dtschema? Best regards, Krzysztof
Re: [Freedreno] [PATCH 0/5] drm/msm: add support for SM8450
On 22-09-22, 14:30, Dmitry Baryshkov wrote: > This adds support for the MDSS/DPU/DSI on the Qualcomm SM8450 platform. Tested this on DM8450-HDK with HDMI and it works for me. For whole series: Tested-by: Vinod Koul Reviewed-by: Vinod Koul > > Dmitry Baryshkov (5): > drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450 > drm/msm/dsi: add support for DSI 2.6.0 > drm/msm/dpu: add support for MDP_TOP blackhole > drm/msm/dpu: add support for SM8450 > drm/msm: mdss add support for SM8450 > > drivers/gpu/drm/msm/Kconfig | 6 +- > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 224 ++ > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 3 + > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 +- > drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 + > drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 2 + > drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 132 ++- > drivers/gpu/drm/msm/msm_mdss.c| 8 + > 11 files changed, 381 insertions(+), 15 deletions(-) > > -- > 2.35.1 -- ~Vinod
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 22/09/2022 14:43, Krzysztof Kozlowski wrote: On 22/09/2022 09:53, Dmitry Baryshkov wrote: On Thu, 22 Sept 2022 at 10:05, Krzysztof Kozlowski wrote: On 15/09/2022 15:37, Dmitry Baryshkov wrote: Move properties common to all MDSS DT nodes to the mdss-common.yaml. This extends qcom,msm8998-mdss schema to allow interconnect nodes, which will be added later, once msm8998 gains interconnect support. Signed-off-by: Dmitry Baryshkov --- .../bindings/display/msm/dpu-msm8998.yaml | 41 + .../bindings/display/msm/dpu-qcm2290.yaml | 51 ++-- .../bindings/display/msm/dpu-sc7180.yaml | 50 ++- .../bindings/display/msm/dpu-sc7280.yaml | 50 ++- .../bindings/display/msm/dpu-sdm845.yaml | 54 ++-- .../bindings/display/msm/mdss-common.yaml | 83 +++ 6 files changed, 111 insertions(+), 218 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/mdss-common.yaml diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml index 200eeace1c71..67791dbc3b5d 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml @@ -14,20 +14,13 @@ description: | sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree bindings of MDSS and DPU are mentioned for MSM8998 target. missing allOf Rob asked to remove this while reviewing v6 ([1]). And indeed the allOf's around a single $ref do not seem to be necessary He commented on one of properties, not top-level, maybe it is different case for dtschema. In the past it was required, so are you sure something changed in dtschema? I do not know if something has changed or not. But judging from the fact that unevaluatedProperties:false do not generate any warnings, the referenced schema is processed and applied. Best regards, Krzysztof -- With best wishes Dmitry
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 22/09/2022 10:04, Krzysztof Kozlowski wrote: On 15/09/2022 15:37, Dmitry Baryshkov wrote: Move properties common to all MDSS DT nodes to the mdss-common.yaml. This extends qcom,msm8998-mdss schema to allow interconnect nodes, which will be added later, once msm8998 gains interconnect support. Signed-off-by: Dmitry Baryshkov --- (...) - "#interrupt-cells": -const: 1 - iommus: -items: - - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 - - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1 - - ranges: true +maxItems: 2 interconnects: -items: - - description: Interconnect path from mdp0 port to the data bus - - description: Interconnect path from mdp1 port to the data bus +maxItems: 2 I think this is not equivalent now, because you have in total minItems:1 and maxItems:2, while in past minItems was 2. This means that I should have minItems:2, maxItems:2, which, if I got it right, is frowned upon. Let me doublecheck though if it works as expected. The same might apply to iommus. clocks look good. -- With best wishes Dmitry
Re: [PATCH v7,1/3] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186
On Thu, 2022-09-22 at 10:16 +0200, AngeloGioacchino Del Regno wrote:
> Il 22/09/22 09:29, xinlei@mediatek.com ha scritto:
> > From: Xinlei Lee
> >
> > The difference between MT8186 and other ICs is that when modifying
> > the
> > output format, we need to modify the mmsys_base+0x400 register to
> > take
> > effect.
> > So when setting the dpi output format, we need to call mmsys_func
> > to set
> > it to MT8186 synchronously.
> >
> > Co-developed-by: Jitao Shi
> > Signed-off-by: Jitao Shi
> > Signed-off-by: Xinlei Lee
> > ---
> > drivers/soc/mediatek/mt8186-mmsys.h| 8 +++
> > drivers/soc/mediatek/mtk-mmsys.c | 32
> > ++
> > include/linux/soc/mediatek/mtk-mmsys.h | 9
> > 3 files changed, 49 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
> > b/drivers/soc/mediatek/mt8186-mmsys.h
> > index eb1ad9c37a9c..536005d1cc55 100644
> > --- a/drivers/soc/mediatek/mt8186-mmsys.h
> > +++ b/drivers/soc/mediatek/mt8186-mmsys.h
> > @@ -3,6 +3,14 @@
> > #ifndef __SOC_MEDIATEK_MT8186_MMSYS_H
> > #define __SOC_MEDIATEK_MT8186_MMSYS_H
> >
> > +/* Values for DPI configuration in MMSYS address space */
> > +#define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
> > +#define DPI_FORMAT_MASK0x3
>
> This is GENMASK(1, 0)
>
> > +#define DPI_RGB888_SDR_CON 0
> > +#define DPI_RGB888_DDR_CON 1
> > +#define DPI_RGB565_SDR_CON 2
> > +#define DPI_RGB565_DDR_CON 3
> > +
> > #define MT8186_MMSYS_OVL_CON 0xF04
> > #define MT8186_MMSYS_OVL0_CON_MASK0x3
> > #define MT8186_MMSYS_OVL0_2L_CON_MASK 0xC
> > diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> > b/drivers/soc/mediatek/mtk-mmsys.c
> > index 06d8e83a2cb5..0857806206dc 100644
> > --- a/drivers/soc/mediatek/mtk-mmsys.c
> > +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > @@ -227,6 +227,38 @@ void mtk_mmsys_ddp_disconnect(struct device
> > *dev,
> > }
> > EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
> >
> > +static void mtk_mmsys_update_bits(struct mtk_mmsys *mmsys, u32
> > offset, u32 mask, u32 val)
> > +{
> > + u32 tmp;
> > +
> > + tmp = readl_relaxed(mmsys->regs + offset);
> > + tmp = (tmp & ~mask) | val;
> > + writel_relaxed(tmp, mmsys->regs + offset);
> > +}
> > +
> > +void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
> > +{
> > + switch (val) {
>
> You're not handling the MTK_DPI_RGB888_SDR_CON case.
>
> > + case MTK_DPI_RGB888_DDR_CON: > +mtk_mmsys_update_bi
> > ts(dev_get_drvdata(dev), MT8186_MMSYS_DPI_OUTPUT_FORMAT,
>
> Are there any other (future, past, present) MTK SoCs having a MMSYS
> DPI_OUTPUT_FORMAT register?
>
> I don't like seeing this kind of model-agnostic function in a not
> model-agnostic
> driver, especially when this is only because of a register address.
> That would change if no other future (or present) MediaTek SoCs have
> this register.
>
> > + DPI_FORMAT_MASK,
> > DPI_RGB888_DDR_CON);
> > + break;
> > + case MTK_DPI_RGB565_SDR_CON:
> > + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > + DPI_FORMAT_MASK,
> > DPI_RGB565_SDR_CON);
> > + break;
> > + case MTK_DPI_RGB565_DDR_CON:
> > + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > + DPI_FORMAT_MASK,
> > DPI_RGB565_DDR_CON);
> > + break;
>
> This goes here...
>
> case MTK_DPI_RGB888_DDR_CON:
> > + default:
> > + mtk_mmsys_update_bits(dev_get_drvdata(dev),
> > MT8186_MMSYS_DPI_OUTPUT_FORMAT,
> > + DPI_FORMAT_MASK,
> > DPI_RGB888_DDR_CON);
> > + break;
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
> > +
> > static int mtk_mmsys_reset_update(struct reset_controller_dev
> > *rcdev, unsigned long id,
> > bool assert)
> > {
> > diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> > b/include/linux/soc/mediatek/mtk-mmsys.h
> > index 59117d970daf..b85f66db33e1 100644
> > --- a/include/linux/soc/mediatek/mtk-mmsys.h
> > +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> > @@ -9,6 +9,13 @@
> > enum mtk_ddp_comp_id;
> > struct device;
> >
> > +enum mtk_dpi_out_format_con {
> > + MTK_DPI_RGB888_SDR_CON,
> > + MTK_DPI_RGB888_DDR_CON,
> > + MTK_DPI_RGB565_SDR_CON,
> > + MTK_DPI_RGB565_DDR_CON
> > +};
> > +
> > enum mtk_ddp_comp_id {
> > DDP_COMPONENT_AAL0,
> > DDP_COMPONENT_AAL1,
> > @@ -65,4 +72,6 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
> > enum mtk_ddp_comp_id cur,
> > enum mtk_ddp_comp_id next);
> >
> > +void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev,
[PATCH] drm/i915: Improve debug print in vm_fault_ttm
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..9619c0fe1025 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n", err);
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
--
2.37.3
Re: [PATCH v7 06/12] dt-bindings: display/msm: split dpu-sc7180 into DPU and MDSS parts
On 22/09/2022 12:30, Dmitry Baryshkov wrote:
>>> +display-subsystem@ae0 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +compatible = "qcom,sc7180-mdss";
>>> +reg = <0xae0 0x1000>;
>>> +reg-names = "mdss";
>>> +power-domains = <&dispcc MDSS_GDSC>;
>>> +clocks = <&gcc GCC_DISP_AHB_CLK>,
>>> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
>>> + <&dispcc DISP_CC_MDSS_MDP_CLK>;
>>> +clock-names = "iface", "ahb", "core";
>>> +
>>> +interrupts = ;
>>> +interrupt-controller;
>>> +#interrupt-cells = <1>;
>>> +
>>> +interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>;
>>> +interconnect-names = "mdp0-mem";
>>> +
>>> +iommus = <&apps_smmu 0x800 0x2>;
>>> +ranges;
>>
>> This should come with full example, so with display-controller child
>> (unless Rob asked not to?)
>
> I'm not sure here. We have an example of a display-controller in a
> separate schema file. Why would you like to duplicate it?
To validate the child node (display-controller) in the context of this
schema. The child node is essential, so I would also say that example is
incomplete.
Best regards,
Krzysztof
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 22/09/2022 13:47, Dmitry Baryshkov wrote: missing allOf >>> >>> Rob asked to remove this while reviewing v6 ([1]). And indeed the >>> allOf's around a single $ref do not seem to be necessary >> >> He commented on one of properties, not top-level, maybe it is different >> case for dtschema. In the past it was required, so are you sure >> something changed in dtschema? > > I do not know if something has changed or not. But judging from the fact > that unevaluatedProperties:false do not generate any warnings, the > referenced schema is processed and applied. Hm, indeed looking at the dtschema code should be no difference between ref and allOf-ref. Best regards, Krzysztof
Re: [PATCH v7 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml
On 22/09/2022 13:46, Dmitry Baryshkov wrote: >>> - ranges: true >>> +maxItems: 2 >>> >>> interconnects: >>> -items: >>> - - description: Interconnect path from mdp0 port to the data bus >>> - - description: Interconnect path from mdp1 port to the data bus >>> +maxItems: 2 >> >> I think this is not equivalent now, because you have in total minItems:1 >> and maxItems:2, while in past minItems was 2. > > This means that I should have minItems:2, maxItems:2, which, if I got it > right, is frowned upon. Let me doublecheck though if it works as expected. It is frowned upon only if it is alone, because for missing minItems, maxItems implies minItems. Here you have minItems in other schema, so there is no such case Best regards, Krzysztof
[PATCH v8,0/3] Add dpi output format control for MT8186
From: Xinlei Lee Base on the branch of ck-linux-next/mediatek-drm-fixes. Changes since v7: 1. This series is based on the following patch: [1] soc: mediatek: Add mmsys func to adapt to dpi output for MT8186 https://patchwork.kernel.org/project/linux-mediatek/patch/1663161662-1598-2-git-send-email-xinlei@mediatek.com/ 2. Modify the DPI_FORMAT_MASK macro definition to GENMASK(1, 0); 3. Add all settings to mtk_mmsys_ddp_dpi_fmt_config; 4. Modify the commit title to Add mt8186 dpi compatibles and platform data. Changes since v6: 1. Different from other ICs, when mt8186 DPI changes the output format, the mmsys_base+400 register needs to be set to be valid at the same time. In this series, all the situations that mmsys need to be set up are perfected (not necessarily used in practice). 2. Put the value that controls the mmsys function in mtk-mmsys.h. 3. Encountered the sink ic switched between dual edge and single edge, perfected setting and clearing mmsys bit operations in mtk_dpi.c. Changes since v5: 1. Separate the patch that adds edge_cfg_in_mmsys from the patch that adds mt8186 dpi support. 2. Move the mmsys register definition to mmsys driver. Changes since v4: 1. This series of cancellations is based on the following patches: [1] Add MediaTek SoC(vdosys1) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/cover/20220711075245.10492-1-nancy@mediatek.com/ [2] Add MediaTek SoC DRM (vdosys1) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/cover/20220804072827.22383-1-nancy@mediatek.com/ 2. Added mtk_mmsys_update_bits function in mtk-mmsys.c; 3. MMSYS 0x400 register is modified to MT8186_MMSYS_DPI_OUTPUT_FORMAT; 4. Fix formatting issues. Changes since v3: 1. Fix formatting issues; 2. Modify the edge output control name & description; 3. Fix the threading problem. Changes since v2: 1. Modify key nouns in the description; 2. Add the label of jitao to Co-developed-by; 3. Macro definition address lowercase problem and function naming; 4. Add missing a description of this property in the mtk_dpi_conf. Change since v1: 1. Modify mt8186 compatiable location. 2. Modify MT8186_DPI_OUTPUT_FORMAT name. When MT8186 outputs dpi signal, it is necessary to add dual edge output format control in mmsys. Xinlei Lee (3): soc: mediatek: Add all settings to mtk_mmsys_ddp_dpi_fmt_config func drm: mediatek: Adjust the dpi output format to MT8186 drm: mediatek: Add mt8186 dpi compatibles and platform data drivers/gpu/drm/mediatek/mtk_dpi.c | 32 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ drivers/soc/mediatek/mt8186-mmsys.h| 8 --- drivers/soc/mediatek/mtk-mmsys.c | 27 +- include/linux/soc/mediatek/mtk-mmsys.h | 7 ++ 5 files changed, 67 insertions(+), 9 deletions(-) -- 2.18.0
[PATCH v8, 1/3] soc: mediatek: Add all settings to mtk_mmsys_ddp_dpi_fmt_config func
From: Xinlei Lee
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect.
So when setting the dpi output format, we need to call mmsys_func to set
it to MT8186 synchronously.
Adding mmsys all the settings that need to be modified with dpi are for mt8186.
Fixes: a071e52f75d1 ("soc: mediatek: Add mmsys func to adapt to dpi output for
MT8186")
Signed-off-by: Xinlei Lee
---
drivers/soc/mediatek/mt8186-mmsys.h| 8 +---
drivers/soc/mediatek/mtk-mmsys.c | 27 --
include/linux/soc/mediatek/mtk-mmsys.h | 7 +++
3 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/mediatek/mt8186-mmsys.h
b/drivers/soc/mediatek/mt8186-mmsys.h
index 09b1ccbc0093..035aec1eb616 100644
--- a/drivers/soc/mediatek/mt8186-mmsys.h
+++ b/drivers/soc/mediatek/mt8186-mmsys.h
@@ -5,9 +5,11 @@
/* Values for DPI configuration in MMSYS address space */
#define MT8186_MMSYS_DPI_OUTPUT_FORMAT 0x400
-#define DPI_FORMAT_MASK0x1
-#define DPI_RGB888_DDR_CON BIT(0)
-#define DPI_RGB565_SDR_CON BIT(1)
+#define DPI_FORMAT_MASKGENMASK(1, 0)
+#define DPI_RGB888_SDR_CON 0
+#define DPI_RGB888_DDR_CON 1
+#define DPI_RGB565_SDR_CON 2
+#define DPI_RGB565_DDR_CON 3
#define MT8186_MMSYS_OVL_CON 0xF04
#define MT8186_MMSYS_OVL0_CON_MASK 0x3
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 2e20b24da363..952e636b282e 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -238,12 +238,27 @@ static void mtk_mmsys_update_bits(struct mtk_mmsys
*mmsys, u32 offset, u32 mask,
void mtk_mmsys_ddp_dpi_fmt_config(struct device *dev, u32 val)
{
- if (val)
- mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
- DPI_RGB888_DDR_CON, DPI_FORMAT_MASK);
- else
- mtk_mmsys_update_bits(dev_get_drvdata(dev),
MT8186_MMSYS_DPI_OUTPUT_FORMAT,
- DPI_RGB565_SDR_CON, DPI_FORMAT_MASK);
+struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
+
+switch (val) {
+case MTK_DPI_RGB888_SDR_CON:
+mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_SDR_CON);
+break;
+case MTK_DPI_RGB565_SDR_CON:
+mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_SDR_CON);
+break;
+case MTK_DPI_RGB565_DDR_CON:
+mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB565_DDR_CON);
+break;
+case MTK_DPI_RGB888_DDR_CON:
+default:
+mtk_mmsys_update_bits(mmsys, MT8186_MMSYS_DPI_OUTPUT_FORMAT,
+ DPI_FORMAT_MASK, DPI_RGB888_DDR_CON);
+break;
+}
}
EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_dpi_fmt_config);
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index d2b02bb43768..b85f66db33e1 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,13 @@
enum mtk_ddp_comp_id;
struct device;
+enum mtk_dpi_out_format_con {
+ MTK_DPI_RGB888_SDR_CON,
+ MTK_DPI_RGB888_DDR_CON,
+ MTK_DPI_RGB565_SDR_CON,
+ MTK_DPI_RGB565_DDR_CON
+};
+
enum mtk_ddp_comp_id {
DDP_COMPONENT_AAL0,
DDP_COMPONENT_AAL1,
--
2.18.0
[PATCH v8, 3/3] drm: mediatek: Add mt8186 dpi compatibles and platform data
From: Xinlei Lee
Add the compatible because use edge_cfg_in_mmsys in mt8186.
Signed-off-by: Xinlei Lee
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bd1870a8504a..2fcf7a61c340 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -941,6 +941,24 @@ static const struct mtk_dpi_conf mt8183_conf = {
.csc_enable_bit = CSC_ENABLE,
};
+static const struct mtk_dpi_conf mt8186_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+ .max_clock_khz = 15,
+ .output_fmts = mt8183_output_fmts,
+ .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+ .edge_cfg_in_mmsys = true,
+ .pixels_per_iter = 1,
+ .is_ck_de_pol = true,
+ .swap_input_support = true,
+ .support_direct_pin = true,
+ .dimension_mask = HPW_MASK,
+ .hvsize_mask = HSIZE_MASK,
+ .channel_swap_shift = CH_SWAP,
+ .yuv422_en_bit = YUV422_EN,
+ .csc_enable_bit = CSC_ENABLE,
+};
+
static const struct mtk_dpi_conf mt8192_conf = {
.cal_factor = mt8183_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -1091,6 +1109,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8183-dpi",
.data = &mt8183_conf,
},
+ { .compatible = "mediatek,mt8186-dpi",
+ .data = &mt8186_conf,
+ },
{ .compatible = "mediatek,mt8192-dpi",
.data = &mt8192_conf,
},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 546b79412815..3d32fbc66ac1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -646,6 +646,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8183-dpi",
.data = (void *)MTK_DPI },
+ { .compatible = "mediatek,mt8186-dpi",
+ .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8192-dpi",
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8195-dp-intf",
--
2.18.0
[PATCH v8,2/3]drm: mediatek: Adjust the dpi output format to MT8186
From: Xinlei Lee
Due to the mt8186 hardware changes, we need to modify the dpi output
format corresponding to the mmsys register(mmsys_base+0x400).
Because different sink ICs may support other output formats.
The current DRM architecture supports retrieving the output format of
all bridges (eg dpi is implemented via DRM's .atomic_check and
.atomic_get_output_bus_fmts and .atomic_get_input_bus_fmts).
If no unified output format is found, the default soc format
(MEDIA_BUS_FMT_RGB888_2X12_LE in mt8186) is used.
Therefore, if there are other format sink ICs (RGB888_DDR/RGB888_SDR) in
the future, the sink IC needs to add the func implementation mentioned
above needs to be added.
And the drm architecture will select the appropriate format to change
the dpi output.
Co-developed-by: Jitao Shi
Signed-off-by: Jitao Shi
Signed-off-by: Xinlei Lee
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 630a4e301ef6..bd1870a8504a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -30,6 +31,7 @@
#include "mtk_disp_drv.h"
#include "mtk_dpi_regs.h"
#include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
enum mtk_dpi_out_bit_num {
MTK_DPI_OUT_BIT_NUM_8BITS,
@@ -82,6 +84,7 @@ struct mtk_dpi {
struct pinctrl_state *pins_dpi;
u32 output_fmt;
int refcount;
+ struct device *mmsys_dev;
};
static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
@@ -135,6 +138,7 @@ struct mtk_dpi_yc_limit {
* @yuv422_en_bit: Enable bit of yuv422.
* @csc_enable_bit: Enable bit of CSC.
* @pixels_per_iter: Quantity of transferred pixels per iteration.
+ * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be
set in MMSYS.
*/
struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -153,6 +157,7 @@ struct mtk_dpi_conf {
u32 yuv422_en_bit;
u32 csc_enable_bit;
u32 pixels_per_iter;
+ bool edge_cfg_in_mmsys;
};
static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -449,8 +454,12 @@ static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE ?
EDGE_SEL : 0, EDGE_SEL);
+ if (dpi->conf->edge_cfg_in_mmsys)
+ mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
MTK_DPI_RGB888_DDR_CON);
} else {
mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE, 0);
+ if (dpi->conf->edge_cfg_in_mmsys)
+ mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev,
MTK_DPI_RGB888_SDR_CON);
}
}
@@ -778,8 +787,10 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
{
struct mtk_dpi *dpi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ struct mtk_drm_private *priv = drm_dev->dev_private;
int ret;
+ dpi->mmsys_dev = priv->mmsys_dev;
ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
DRM_MODE_ENCODER_TMDS);
if (ret) {
--
2.18.0
Re: [PATCH v1 01/17] dt-bindings: clk: mediatek: Add MT8195 DPI clocks
On Thu, 22 Sep 2022 09:11, Krzysztof Kozlowski wrote: >On 19/09/2022 18:55, Guillaume Ranquet wrote: >> From: Pablo Sun >> >> Expand dt-bindings slot for VDOSYS1 of MT8195. >> This clock is required by the DPI1 hardware >> and is a downstream of the HDMI pixel clock. >> >> Signed-off-by: Pablo Sun >> Signed-off-by: Guillaume Ranquet >> Reviewed-by: Mattijs Korpershoek >> > >Looks like broken patch. > >Best regards, >Krzysztof > Hi Bo-Chen and Krzysztof, I've sent the patches using the rather new b4 prep/send commands. Though it produces valid patches, it's using `git show --format=email` to produce the patches, which lacks a diffstat. My understanding is that the diffstat is considered to be comments and thus are not necessary to produce a valid patch. I've reported the issue on the tools mailing list [1], I'm looking at providing a fix. I'll be extra careful at the patch format for V2. Sorry for the inconveniance, Guillaume. [1] https://lore.kernel.org/tools/CABnWg9uBOGqJMq=yCtn7SoEME=+2u1-ZK9ftb6=_jrhkhl_...@mail.gmail.com/T/#u
Re: [PATCH v1 01/17] dt-bindings: clk: mediatek: Add MT8195 DPI clocks
On 22/09/2022 14:45, Guillaume Ranquet wrote: > On Thu, 22 Sep 2022 09:11, Krzysztof Kozlowski > wrote: >> On 19/09/2022 18:55, Guillaume Ranquet wrote: >>> From: Pablo Sun >>> >>> Expand dt-bindings slot for VDOSYS1 of MT8195. >>> This clock is required by the DPI1 hardware >>> and is a downstream of the HDMI pixel clock. >>> >>> Signed-off-by: Pablo Sun >>> Signed-off-by: Guillaume Ranquet >>> Reviewed-by: Mattijs Korpershoek >>> >> >> Looks like broken patch. >> >> Best regards, >> Krzysztof >> > > Hi Bo-Chen and Krzysztof, > I've sent the patches using the rather new b4 prep/send commands. > > Though it produces valid patches, it's using `git show --format=email` > to produce the patches, which lacks a diffstat. > > My understanding is that the diffstat is considered to be comments and thus > are not necessary to produce a valid patch. > > I've reported the issue on the tools mailing list [1], I'm looking at > providing > a fix. > > I'll be extra careful at the patch format for V2. Thanks for explanation! Probably your patches are perfectly fine and should apply, although I must admit diffstat is often useful. Best regards, Krzysztof
Re: [PATCH v1 01/17] dt-bindings: clk: mediatek: Add MT8195 DPI clocks
On 19/09/2022 18:55, Guillaume Ranquet wrote: > From: Pablo Sun > > Expand dt-bindings slot for VDOSYS1 of MT8195. > This clock is required by the DPI1 hardware > and is a downstream of the HDMI pixel clock. > > Signed-off-by: Pablo Sun > Signed-off-by: Guillaume Ranquet > Reviewed-by: Mattijs Korpershoek Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v1 03/17] dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible
On 19/09/2022 18:56, Guillaume Ranquet wrote: > Add a compatible for the HDMI PHY on MT8195 > > Signed-off-by: Guillaume Ranquet > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH 1/5] drm/simpledrm: Compute linestride with drm_format_info_min_pitch()
If not given, compute the stride with drm_format_info_min_pitch(). It's
the standard helper for this purpose.
Suggested-by: Daniel Vetter
Signed-off-by: Thomas Zimmermann
Fixes: fd9e3169e42b ("drm/simpledrm: Compute framebuffer stride if not set")
Cc: Javier Martinez Canillas
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/tiny/simpledrm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index ea5b3239a659..51d01e34d5eb 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -687,8 +687,11 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
drm_err(dev, "no simplefb configuration found\n");
return ERR_PTR(-ENODEV);
}
- if (!stride)
- stride = DIV_ROUND_UP(drm_format_info_bpp(format, 0) * width,
8);
+ if (!stride) {
+ stride = drm_format_info_min_pitch(format, 0, width);
+ if (drm_WARN_ON(dev, !stride))
+ return ERR_PTR(-EINVAL);
+ }
sdev->mode = simpledrm_mode(width, height);
sdev->format = format;
--
2.37.3
[PATCH 2/5] drm/simpledrm: Use drm_atomic_get_new_plane_state()
Lookup the plane's state in atomic_update with the helper
drm_atomic_get_new_plane_state(). Also rename the helpers'
state arguments. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 51d01e34d5eb..14782a50f816 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -470,10 +470,10 @@ static const uint64_t
simpledrm_primary_plane_format_modifiers[] = {
};
static void simpledrm_primary_plane_helper_atomic_update(struct drm_plane
*plane,
-struct
drm_atomic_state *old_state)
+struct
drm_atomic_state *state)
{
- struct drm_plane_state *plane_state = plane->state;
- struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(old_state, plane);
+ struct drm_plane_state *plane_state =
drm_atomic_get_new_plane_state(state, plane);
+ struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state, plane);
struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
struct drm_device *dev = plane->dev;
@@ -503,7 +503,7 @@ static void
simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
}
static void simpledrm_primary_plane_helper_atomic_disable(struct drm_plane
*plane,
- struct
drm_atomic_state *old_state)
+ struct
drm_atomic_state *state)
{
struct drm_device *dev = plane->dev;
struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
--
2.37.3
[PATCH 0/5] drm/simpledrm: Various improvements
This patchset contains various improvements to simpledrm that have piled up over time. Thomas Zimmermann (5): drm/simpledrm: Compute linestride with drm_format_info_min_pitch() drm/simpledrm: Use drm_atomic_get_new_plane_state() drm/simpledrm: Remove !fb check from atomic_update drm/simpledrm: Iterate over damage clips drm/simpledrm: Synchronize access to GEM BOs drivers/gpu/drm/tiny/simpledrm.c | 48 +++- 1 file changed, 28 insertions(+), 20 deletions(-) base-commit: a7d5d07d5ac5ac58ec81932b3f732e3127d17af9 -- 2.37.3
[PATCH 5/5] drm/simpledrm: Synchronize access to GEM BOs
Synchronize CPU access to GEM BOs with other drivers when updating the
screen buffer. Imported buffers might otherwise contain stale data.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 5f242558891e..18489779fb8a 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -480,11 +480,15 @@ static void
simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
struct drm_atomic_helper_damage_iter iter;
struct drm_rect damage;
- int idx;
+ int ret, idx;
- if (!drm_dev_enter(dev, &idx))
+ ret = drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE);
+ if (ret)
return;
+ if (!drm_dev_enter(dev, &idx))
+ goto out_drm_gem_fb_end_cpu_access;
+
drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
drm_atomic_for_each_plane_damage(&iter, &damage) {
struct iosys_map dst = IOSYS_MAP_INIT_VADDR(sdev->screen_base);
@@ -499,6 +503,8 @@ static void
simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
}
drm_dev_exit(idx);
+out_drm_gem_fb_end_cpu_access:
+ drm_gem_fb_end_cpu_access(fb, DMA_FROM_DEVICE);
}
static void simpledrm_primary_plane_helper_atomic_disable(struct drm_plane
*plane,
--
2.37.3
[PATCH 3/5] drm/simpledrm: Remove !fb check from atomic_update
The primary plane implements atomic_disable, so atomic_update will not be called without a framebuffer set. Remove the test for !fb. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/tiny/simpledrm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c index 14782a50f816..8fab22a26e26 100644 --- a/drivers/gpu/drm/tiny/simpledrm.c +++ b/drivers/gpu/drm/tiny/simpledrm.c @@ -482,9 +482,6 @@ static void simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane struct drm_rect src_clip, dst_clip; int idx; - if (!fb) - return; - if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state, &src_clip)) return; -- 2.37.3
[PATCH 4/5] drm/simpledrm: Iterate over damage clips
Iterate over all damage clips and updated them one by one. Replaces
the merging of damage areas, which can result in significant overhead
if damage areas are not close to each other.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 8fab22a26e26..5f242558891e 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -478,23 +478,25 @@ static void
simpledrm_primary_plane_helper_atomic_update(struct drm_plane *plane
struct drm_framebuffer *fb = plane_state->fb;
struct drm_device *dev = plane->dev;
struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
- struct iosys_map dst = IOSYS_MAP_INIT_VADDR(sdev->screen_base);
- struct drm_rect src_clip, dst_clip;
+ struct drm_atomic_helper_damage_iter iter;
+ struct drm_rect damage;
int idx;
- if (!drm_atomic_helper_damage_merged(old_plane_state, plane_state,
&src_clip))
+ if (!drm_dev_enter(dev, &idx))
return;
- dst_clip = plane_state->dst;
- if (!drm_rect_intersect(&dst_clip, &src_clip))
- return;
+ drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
+ drm_atomic_for_each_plane_damage(&iter, &damage) {
+ struct iosys_map dst = IOSYS_MAP_INIT_VADDR(sdev->screen_base);
+ struct drm_rect dst_clip = plane_state->dst;
- if (!drm_dev_enter(dev, &idx))
- return;
+ if (!drm_rect_intersect(&dst_clip, &damage))
+ continue;
- iosys_map_incr(&dst, drm_fb_clip_offset(sdev->pitch, sdev->format,
&dst_clip));
- drm_fb_blit(&dst, &sdev->pitch, sdev->format->format,
shadow_plane_state->data, fb,
- &src_clip);
+ iosys_map_incr(&dst, drm_fb_clip_offset(sdev->pitch,
sdev->format, &dst_clip));
+ drm_fb_blit(&dst, &sdev->pitch, sdev->format->format,
shadow_plane_state->data, fb,
+ &damage);
+ }
drm_dev_exit(idx);
}
--
2.37.3
Re: [PATCH 1/2] drm/rockchip: dw_hdmi: relax mode_valid hook
On 25/08/2022 12:40 pm, Sascha Hauer wrote: On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote: On 2022-08-22 16:20, Sascha Hauer wrote: The driver checks if the pixel clock of the given mode matches an entry in the mpll config table. The frequencies in the mpll table are meant as a frequency range up to which the entry works, not as a frequency that must match the pixel clock. Return MODE_OK when the pixelclock is smaller than one of the mpll frequencies to allow for more display resolutions. Has the issue been fixed that this table is also used to validate modes on RK3328, which doesn't even *have* the Synopsys phy? Last time I looked, that tended to lead to complete display breakage when the proper phy driver later decides it doesn't like a pixel clock that mode_valid already said was OK. The more general concern is that these known-good clock rates are good, but others may not be even when nominally supported, which I suspect is the dirty secret of why it was implemented this way to begin with. I would really really love this patch so my RK3399 board can drive my 1920x1200 monitor at native resolution, but on the other hand my RK3288 box generates such a crap 154MHz clock for that mode that - unless that's been improved in the meantime too - patch #2 might be almost be considered a regression if it means such a setup would start defaulting to an unusably glitchy display instead of falling back to 1920x1080 which does at least work perfectly (even if the slightly squished aspect ratio is ugly). I could limit the change to rk3568 only. Would that be an option? Not sure if I should rk3399 as well then as this would work, at least in your setup. I think for now it might be enough to force an exact match if hdmi->plat_data.phy_force_vendor is set, with a big fat comment that it's to preserve the previous behaviour until vendor phy support can be sorted out properly. Beyond that, given that RK3288 and RK3399 do nominally support 4K as well, I don't think we actually have to leave them out, I just wanted to flag up that untested non-standard clock rates are a known source of potential issues once we open the door to them. Cheers, Robin.
Re: [PATCH 04/12] btrfs: send: Proactively round up to kmalloc bucket size
On Wed, Sep 21, 2022 at 08:10:05PM -0700, Kees Cook wrote: > Instead of discovering the kmalloc bucket size _after_ allocation, round > up proactively so the allocation is explicitly made for the full size, > allowing the compiler to correctly reason about the resulting size of > the buffer through the existing __alloc_size() hint. > > Cc: linux-bt...@vger.kernel.org > Signed-off-by: Kees Cook Acked-by: David Sterba
Re: [PATCH 03/12] net: ipa: Proactively round up to kmalloc bucket size
On 9/21/22 10:10 PM, Kees Cook wrote:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Alex Elder
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
Cc: Paolo Abeni
Cc: net...@vger.kernel.org
Signed-off-by: Kees Cook
---
drivers/net/ipa/gsi_trans.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ipa/gsi_trans.c b/drivers/net/ipa/gsi_trans.c
index 18e7e8c405be..cec968854dcf 100644
--- a/drivers/net/ipa/gsi_trans.c
+++ b/drivers/net/ipa/gsi_trans.c
@@ -89,6 +89,7 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool, size_t
size, u32 count,
u32 max_alloc)
{
void *virt;
+ size_t allocate;
I don't care about this but the reverse Christmas tree
convention would put the "allocate" variable definition
above "virt".
Whether you fix that or not, this patch looks good to me.
Reviewed-by: Alex Elder
if (!size)
return -EINVAL;
@@ -104,13 +105,15 @@ int gsi_trans_pool_init(struct gsi_trans_pool *pool,
size_t size, u32 count,
* If there aren't enough entries starting at the free index,
* we just allocate free entries from the beginning of the pool.
*/
- virt = kcalloc(count + max_alloc - 1, size, GFP_KERNEL);
+ allocate = size_mul(count + max_alloc - 1, size);
+ allocate = kmalloc_size_roundup(allocate);
+ virt = kzalloc(allocate, GFP_KERNEL);
if (!virt)
return -ENOMEM;
pool->base = virt;
/* If the allocator gave us any extra memory, use it */
- pool->count = ksize(pool->base) / size;
+ pool->count = allocate / size;
pool->free = 0;
pool->max_alloc = max_alloc;
pool->size = size;
[PATCH v2 01/10] drm/panel: db7430: Silence no spi_device_id warning
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver db7430-panel has no spi_device_id for samsung,lms397kf04
Add spi_device_id entries to silence the warning, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/panel/panel-samsung-db7430.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-samsung-db7430.c
b/drivers/gpu/drm/panel/panel-samsung-db7430.c
index 04640c5256a8..c341b45c8a36 100644
--- a/drivers/gpu/drm/panel/panel-samsung-db7430.c
+++ b/drivers/gpu/drm/panel/panel-samsung-db7430.c
@@ -331,9 +331,16 @@ static const struct of_device_id db7430_match[] = {
};
MODULE_DEVICE_TABLE(of, db7430_match);
+static const struct spi_device_id db7430_ids[] = {
+ { "lms397kf04" },
+ {},
+};
+MODULE_DEVICE_TABLE(spi, db7430_ids);
+
static struct spi_driver db7430_driver = {
.probe = db7430_probe,
.remove = db7430_remove,
+ .id_table = db7430_ids,
.driver = {
.name = "db7430-panel",
.of_match_table = db7430_match,
--
2.34.1
[PATCH v2 03/10] drm/panel: innolux-ej030na: Silence no spi_device_id warning
From: Wei Yongjun
SPI devices use the spi_device_id for module autoloading even on
systems using device tree, after commit 5fa6863ba692 ("spi: Check
we have a spi_device_id for each DT compatible"), kernel warns as
follows since the spi_device_id is missing:
SPI driver panel-innolux-ej030na has no spi_device_id for innolux,ej030na
Add spi_device_id entries to silence the warning, and ensure driver
module autoloading works.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/panel/panel-innolux-ej030na.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
index b2b0ebc9e943..331735bb2b4c 100644
--- a/drivers/gpu/drm/panel/panel-innolux-ej030na.c
+++ b/drivers/gpu/drm/panel/panel-innolux-ej030na.c
@@ -293,6 +293,12 @@ static const struct of_device_id ej030na_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ej030na_of_match);
+static const struct spi_device_id ej030na_ids[] = {
+ { "ej030na" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, ej030na_ids);
+
static struct spi_driver ej030na_driver = {
.driver = {
.name = "panel-innolux-ej030na",
@@ -300,6 +306,7 @@ static struct spi_driver ej030na_driver = {
},
.probe = ej030na_probe,
.remove = ej030na_remove,
+ .id_table = ej030na_ids,
};
module_spi_driver(ej030na_driver);
--
2.34.1
