[Freedreno] [PATCH] dt-bindings: display: Drop unneeded quotes

[Rob Herring]

Cleanup bindings dropping unneeded quotes. Once all these are fixed,
checking for this can be enabled in yamllint.

Signed-off-by: Rob Herring 
---
 .../bindings/auxdisplay/holtek,ht16k33.yaml|  2 +-
 .../bindings/display/bridge/nxp,ptn3460.yaml   |  2 +-
 .../display/bridge/toshiba,tc358767.yaml   |  2 +-
 .../bindings/display/dp-aux-bus.yaml   |  2 +-
 .../display/mediatek/mediatek,hdmi.yaml|  2 +-
 .../display/msm/dsi-controller-main.yaml   |  8 
 .../bindings/display/msm/dsi-phy-10nm.yaml |  2 +-
 .../bindings/display/panel/ronbo,rb070d30.yaml |  2 +-
 .../bindings/display/renesas,du.yaml   |  4 ++--
 .../display/tegra/nvidia,tegra114-mipi.yaml|  2 +-
 .../display/tegra/nvidia,tegra124-sor.yaml | 12 ++--
 .../display/tegra/nvidia,tegra186-dc.yaml  |  4 ++--
 .../tegra/nvidia,tegra186-dsi-padctl.yaml  |  2 +-
 .../display/tegra/nvidia,tegra20-dsi.yaml  | 12 ++--
 .../display/tegra/nvidia,tegra20-hdmi.yaml |  6 +++---
 .../bindings/display/ti/ti,am65x-dss.yaml  |  2 +-
 .../display/xylon,logicvc-display.yaml | 18 +-
 17 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml 
b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
index fc4873deb76f..4f6ffb8182a9 100644
--- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
+++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Robin van der Gracht 
 
 allOf:
-  - $ref: "/schemas/input/matrix-keymap.yaml#"
+  - $ref: /schemas/input/matrix-keymap.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml 
b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
index 107dd138e6c6..cdeb67bc05f0 100644
--- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml
@@ -18,7 +18,7 @@ properties:
 maxItems: 1
 
   edid-emulation:
-$ref: "/schemas/types.yaml#/definitions/uint32"
+$ref: /schemas/types.yaml#/definitions/uint32
 description:
   The EDID emulation entry to use
   Value  Resolution  Description
diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index 140927884418..e1494b5007cb 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -23,7 +23,7 @@ properties:
 i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
 
   clock-names:
-const: "ref"
+const: ref
 
   clocks:
 maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml 
b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
index 5e4afe9f98fb..0ece7b01790b 100644
--- a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
+++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml
@@ -26,7 +26,7 @@ description:
 
 properties:
   $nodename:
-const: "aux-bus"
+const: aux-bus
 
   panel:
 $ref: panel/panel-common.yaml#
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index 8afdd67d6780..b90b6d18a828 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -50,7 +50,7 @@ properties:
   - const: hdmi
 
   mediatek,syscon-hdmi:
-$ref: '/schemas/types.yaml#/definitions/phandle-array'
+$ref: /schemas/types.yaml#/definitions/phandle-array
 items:
   - items:
   - description: phandle to system configuration registers
diff --git 
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index e75a3efe4dac..2188d7c9b0bb 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -74,7 +74,7 @@ properties:
 
   syscon-sfpb:
 description: A phandle to mmss_sfpb syscon node (only for DSIv2).
-$ref: "/schemas/types.yaml#/definitions/phandle"
+$ref: /schemas/types.yaml#/definitions/phandle
 
   qcom,dual-dsi-mode:
 type: boolean
@@ -105,14 +105,14 @@ properties:
 type: object
 
   ports:
-$ref: "/schemas/graph.yaml#/properties/ports"
+$ref: /schemas/graph.yaml#/properties/ports
 description: |
   Contains DSI controller input and output ports as children, each
   containing one endpoint subnode.
 
 properties:
   port@0:
-$ref: "/schemas/graph.yaml#/$defs/port-base"
+$ref: /schemas/graph.yaml#/

[Freedreno] Reminder: Only 2 days left to nominate candidates for the 2023 X.Org Board of Directors Elections

[Ricardo Garcia]

Further reminder that the nomination period for the X.Org Board of
Director elections finishes in only 2 days, on March 19th.

Please send your nominations or self-nominations as soon as possible
following the instructions below.

Thanks again for your attention.

On Mon, 2023-03-13 at 16:27 +0100, Ricardo Garcia wrote:
> This is a reminder that the nomination period for the X.Org Board of
> Director elections finishes in a week, on March 19th.
> 
> If you would like to nominate yourself please send email to the election
> committee electi...@x.org, giving your
> 
> name
> current professional affiliation
> a statement of contribution to X.Org or related technologies
> a personal statement.
> 
> To vote or to be elected to the Board you needed to be a Member of the
> X.Org Foundation. To be a Member of the X.Org Foundation you need to
> apply or renew your membership until the end of the nomination period.
> 
> Original email follows below. Thanks for your attention.
> 
> On Wed, 2023-02-15 at 21:53 +0100, Ricardo Garcia wrote:
> > We are seeking nominations for candidates for election to the X.Org
> > Foundation Board of Directors. All X.Org Foundation members are eligible
> > for election to the board.
> > 
> > Nominations for the 2023 election are now open and will remain open
> > until 23:59 UTC on 19 March 2023.
> > 
> > The Board consists of directors elected from the membership. Each year,
> > an election is held to bring the total number of directors to eight. The
> > four members receiving the highest vote totals will serve as directors
> > for two year terms.
> > 
> > The directors who received two year terms starting in 2022 were Emma
> > Anholt, Mark Filion, Alyssa Rosenzweig and Ricardo Garcia. They will
> > continue to serve until their term ends in 2024. Current directors whose
> > term expires in 2023 are Samuel Iglesias Gonsálvez, Manasi D Navare,
> > Lyude Paul and Daniel Vetter.
> > 
> > A director is expected to participate in the fortnightly IRC meeting to
> > discuss current business and to attend the annual meeting of the X.Org
> > Foundation, which will be held at a location determined in advance by
> > the Board of Directors.
> > 
> > A member may nominate themselves or any other member they feel is
> > qualified. Nominations should be sent to the Election Committee at
> > elections at x.org.
> > 
> > Nominees shall be required to be current members of the X.Org
> > Foundation, and submit a personal statement of up to 200 words that will
> > be provided to prospective voters. The collected statements, along with
> > the statement of contribution to the X.Org Foundation in the member's
> > account page on http://members.x.org, will be made available to all
> > voters to help them make their voting decisions.
> > 
> > Nominations, membership applications or renewals and completed personal
> > statements must be received no later than 23:59 UTC on 19 March 2023.
> > 
> > The slate of candidates will be published 26 March 2023 and candidate
> > Q&A will begin then. The deadline for Xorg membership applications and
> > renewals is 26 March 2023.
> > 
> > Cheers,
> > Ricardo Garcia, on behalf of the X.Org BoD
> > 
> 

Re: [Freedreno] [Intel-gfx] [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits

[Rob Clark]

On Fri, Mar 17, 2023 at 12:08 PM Faith Ekstrand  wrote:
>
>
> On Wed, Mar 8, 2023 at 9:54 AM Rob Clark  wrote:
>>
>> From: Rob Clark 
>>
>> Add a new flag to let userspace provide a deadline as a hint for syncobj
>> and timeline waits.  This gives a hint to the driver signaling the
>> backing fences about how soon userspace needs it to compete work, so it
>> can addjust GPU frequency accordingly.  An immediate deadline can be
>> given to provide something equivalent to i915 "wait boost".
>>
>> v2: Use absolute u64 ns value for deadline hint, drop cap and driver
>> feature flag in favor of allowing count_handles==0 as a way for
>> userspace to probe kernel for support of new flag
>> v3: More verbose comments about UAPI
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/drm_syncobj.c | 64 ---
>>  include/uapi/drm/drm.h| 17 ++
>>  2 files changed, 68 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index 0c2be8360525..a85e9464f07b 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -126,6 +126,11 @@
>>   * synchronize between the two.
>>   * This requirement is inherited from the Vulkan fence API.
>>   *
>> + * If &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
>> + * a fence deadline hint on the backing fences before waiting, to provide 
>> the
>> + * fence signaler with an appropriate sense of urgency.  The deadline is
>> + * specified as an absolute &CLOCK_MONOTONIC value in units of ns.
>> + *
>>   * Similarly, &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
>>   * handles as well as an array of u64 points and does a host-side wait on 
>> all
>>   * of syncobj fences at the given points simultaneously.
>> @@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct 
>> drm_syncobj **syncobjs,
>>   uint32_t count,
>>   uint32_t flags,
>>   signed long timeout,
>> - uint32_t *idx)
>> + uint32_t *idx,
>> + ktime_t *deadline)
>>  {
>> struct syncobj_wait_entry *entries;
>> struct dma_fence *fence;
>> @@ -1053,6 +1059,15 @@ static signed long 
>> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
>> drm_syncobj_fence_add_wait(syncobjs[i], &entries[i]);
>> }
>>
>> +   if (deadline) {
>> +   for (i = 0; i < count; ++i) {
>> +   fence = entries[i].fence;
>> +   if (!fence)
>> +   continue;
>> +   dma_fence_set_deadline(fence, *deadline);
>> +   }
>> +   }
>> +
>> do {
>> set_current_state(TASK_INTERRUPTIBLE);
>>
>> @@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device 
>> *dev,
>>   struct drm_file *file_private,
>>   struct drm_syncobj_wait *wait,
>>   struct drm_syncobj_timeline_wait 
>> *timeline_wait,
>> - struct drm_syncobj **syncobjs, bool 
>> timeline)
>> + struct drm_syncobj **syncobjs, bool 
>> timeline,
>> + ktime_t *deadline)
>>  {
>> signed long timeout = 0;
>> uint32_t first = ~0;
>> @@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device 
>> *dev,
>>  NULL,
>>  wait->count_handles,
>>  wait->flags,
>> -timeout, &first);
>> +timeout, &first,
>> +deadline);
>> if (timeout < 0)
>> return timeout;
>> wait->first_signaled = first;
>> @@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device 
>> *dev,
>>  
>> u64_to_user_ptr(timeline_wait->points),
>>  
>> timeline_wait->count_handles,
>>  
>> timeline_wait->flags,
>> -timeout, &first);
>> +timeout, &first,
>> +deadline);
>> if (timeout < 0)
>> retur

Re: [Freedreno] [Intel-gfx] [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits

[Faith Ekstrand]

On Wed, Mar 8, 2023 at 9:54 AM Rob Clark  wrote:

> From: Rob Clark 
>
> Add a new flag to let userspace provide a deadline as a hint for syncobj
> and timeline waits.  This gives a hint to the driver signaling the
> backing fences about how soon userspace needs it to compete work, so it
> can addjust GPU frequency accordingly.  An immediate deadline can be
> given to provide something equivalent to i915 "wait boost".
>
> v2: Use absolute u64 ns value for deadline hint, drop cap and driver
> feature flag in favor of allowing count_handles==0 as a way for
> userspace to probe kernel for support of new flag
> v3: More verbose comments about UAPI
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_syncobj.c | 64 ---
>  include/uapi/drm/drm.h| 17 ++
>  2 files changed, 68 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 0c2be8360525..a85e9464f07b 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -126,6 +126,11 @@
>   * synchronize between the two.
>   * This requirement is inherited from the Vulkan fence API.
>   *
> + * If &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also
> set
> + * a fence deadline hint on the backing fences before waiting, to provide
> the
> + * fence signaler with an appropriate sense of urgency.  The deadline is
> + * specified as an absolute &CLOCK_MONOTONIC value in units of ns.
> + *
>   * Similarly, &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
>   * handles as well as an array of u64 points and does a host-side wait on
> all
>   * of syncobj fences at the given points simultaneously.
> @@ -973,7 +978,8 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
>   uint32_t count,
>   uint32_t flags,
>   signed long timeout,
> - uint32_t *idx)
> + uint32_t *idx,
> + ktime_t *deadline)
>  {
> struct syncobj_wait_entry *entries;
> struct dma_fence *fence;
> @@ -1053,6 +1059,15 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> drm_syncobj_fence_add_wait(syncobjs[i],
> &entries[i]);
> }
>
> +   if (deadline) {
> +   for (i = 0; i < count; ++i) {
> +   fence = entries[i].fence;
> +   if (!fence)
> +   continue;
> +   dma_fence_set_deadline(fence, *deadline);
> +   }
> +   }
> +
> do {
> set_current_state(TASK_INTERRUPTIBLE);
>
> @@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
>   struct drm_file *file_private,
>   struct drm_syncobj_wait *wait,
>   struct drm_syncobj_timeline_wait
> *timeline_wait,
> - struct drm_syncobj **syncobjs, bool
> timeline)
> + struct drm_syncobj **syncobjs, bool
> timeline,
> + ktime_t *deadline)
>  {
> signed long timeout = 0;
> uint32_t first = ~0;
> @@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
>  NULL,
>
>  wait->count_handles,
>  wait->flags,
> -timeout, &first);
> +timeout, &first,
> +deadline);
> if (timeout < 0)
> return timeout;
> wait->first_signaled = first;
> @@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
>
>  u64_to_user_ptr(timeline_wait->points),
>
>  timeline_wait->count_handles,
>
>  timeline_wait->flags,
> -timeout, &first);
> +timeout, &first,
> +deadline);
> if (timeout < 0)
> return timeout;
> timeline_wait->first_signaled = first;
> @@ -1243,17 +1261,22 @@ drm_syncobj_wait_ioctl(struct drm_device *dev,
> void *data,
>  {
> struct drm_syncobj_wait *args = data;
> struct drm_syncobj **syncobjs;
> +   unsigned possible_flags;
> +   ktime_t t, *tp = NULL;
> int ret = 0;
>
> if (!drm_core_check_feature(dev, DRIVER_SYNCOB

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Rob Clark]

On Fri, Mar 17, 2023 at 3:23 AM Jonas Ådahl  wrote:
>
> On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote:
> > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
> > >
> > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:
> > > > >
> > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > > > > > > From: Rob Clark 
> > > > > > > >
> > > > > > > > Add a way to hint to the fence signaler of an upcoming 
> > > > > > > > deadline, such as
> > > > > > > > vblank, which the fence waiter would prefer not to miss.  This 
> > > > > > > > is to aid
> > > > > > > > the fence signaler in making power management decisions, like 
> > > > > > > > boosting
> > > > > > > > frequency as the deadline approaches and awareness of missing 
> > > > > > > > deadlines
> > > > > > > > so that can be factored in to the frequency scaling.
> > > > > > > >
> > > > > > > > v2: Drop dma_fence::deadline and related logic to filter 
> > > > > > > > duplicate
> > > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > > fence-context
> > > > > > > > implementation will need similar logic to track deadlines 
> > > > > > > > of all
> > > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > > v6: More docs
> > > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > > >
> > > > > > > > Signed-off-by: Rob Clark 
> > > > > > > > Reviewed-by: Christian König 
> > > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > > ---
> > > > > > >
> > > > > > > Hi Rob!
> > > > > > >
> > > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > > 
> > > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > > >  3 files changed, 87 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > :doc: fence signalling annotation
> > > > > > > >
> > > > > > > > +DMA Fence Deadline Hints
> > > > > > > > +
> > > > > > > > +
> > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > +   :doc: deadline hints
> > > > > > > > +
> > > > > > > >  DMA Fences Functions Reference
> > > > > > > >  ~~
> > > > > > > >
> > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct 
> > > > > > > > dma_fence **fences, uint32_t count,
> > > > > > > >  }
> > > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > > >
> > > > > > > > +/**
> > > > > > > > + * DOC: deadline hints
> > > > > > > > + *
> > > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > > workload sufficiently
> > > > > > > > + * that a utilization based device frequency governor could 
> > > > > > > > arrive at a minimum
> > > > > > > > + * frequency that meets the requirements of the use-case, in 
> > > > > > > > order to minimize
> > > > > > > > + * power consumption.  But in the real world there are many 
> > > > > > > > workloads which
> > > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > > + *
> > > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > > alternating periods
> > > > > > > > + *   of CPU waiting for device, and device waiting on CPU.  
> > > > > > > > This can result in
> > > > > > > > + *   devfreq and cpufreq seeing idle time in their respective 
> > > > > > > > domains and in
> > > > > > > > + *   result reduce frequency.
> > > > > > > > + *
> > > > > > > > + * * Workloads that interact with a periodic time based 
> > > > > > > > deadline, such as double
> > > > > > > > + *   buffered GPU rendering vs vblank sync'd page flipping.  
> > > > > > > > In this scenario,
> > > > > > > > + *   missing a vblank deadline results in an *increase* in 
> > > > > > > > idle time on the GPU
> > > > > > > > + 

[Freedreno] [PATCH v6 2/5] arm64: dts: qcom: sm8350: switch to combo usb3/dp phy

[Neil Armstrong]

The first QMP PHY is an USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 42 +---
 1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 1afc4311796e..975ab4cbe57e 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -661,7 +662,7 @@ gcc: clock-controller@10 {
 <&ufs_mem_phy_lanes 0>,
 <&ufs_mem_phy_lanes 1>,
 <&ufs_mem_phy_lanes 2>,
-<0>,
+<&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
 <0>;
};
 
@@ -2135,37 +2136,24 @@ usb_2_hsphy: phy@88e4000 {
resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
};
 
-   usb_1_qmpphy: phy-wrapper@88e9000 {
-   compatible = "qcom,sm8350-qmp-usb3-phy";
-   reg = <0 0x088e9000 0 0x200>,
- <0 0x088e8000 0 0x20>;
-   status = "disabled";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   usb_1_qmpphy: phy@88e9000 {
+   compatible = "qcom,sm8350-qmp-usb3-dp-phy";
+   reg = <0 0x088e8000 0 0x3000>;
 
clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
 <&rpmhcc RPMH_CXO_CLK>,
-<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-   clock-names = "aux", "ref_clk_src", "com_aux";
+<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "aux", "ref", "com_aux", "usb3_pipe";
 
resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
 <&gcc GCC_USB3_PHY_PRIM_BCR>;
reset-names = "phy", "common";
 
-   usb_1_ssphy: phy@88e9200 {
-   reg = <0 0x088e9200 0 0x200>,
- <0 0x088e9400 0 0x200>,
- <0 0x088e9c00 0 0x400>,
- <0 0x088e9600 0 0x200>,
- <0 0x088e9800 0 0x200>,
- <0 0x088e9a00 0 0x100>;
-   #phy-cells = <0>;
-   #clock-cells = <0>;
-   clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-   clock-names = "pipe0";
-   clock-output-names = "usb3_phy_pipe_clk_src";
-   };
+   #clock-cells = <1>;
+   #phy-cells = <1>;
+
+   status = "disabled";
};
 
usb_2_qmpphy: phy-wrapper@88eb000 {
@@ -2268,7 +2256,7 @@ usb_1_dwc3: usb@a60 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
-   phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+   phys = <&usb_1_hsphy>, <&usb_1_qmpphy 
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
};
};
@@ -2633,8 +2621,8 @@ dispcc: clock-controller@af0 {
clocks = <&rpmhcc RPMH_CXO_CLK>,
 <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>,
 <&mdss_dsi1_phy 0>, <&mdss_dsi1_phy 1>,
-<0>,
-<0>;
+<&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
clock-names = "bi_tcxo",
  "dsi0_phy_pll_out_byteclk",
  "dsi0_phy_pll_out_dsiclk",

-- 
2.34.1

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Sebastian Wick]

On Thu, Mar 16, 2023 at 11:59 PM Rob Clark  wrote:
>
> On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick
>  wrote:
> >
> > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark  wrote:
> > >
> > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
> > > >
> > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:
> > > > > >
> > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > > > > > > > From: Rob Clark 
> > > > > > > > >
> > > > > > > > > Add a way to hint to the fence signaler of an upcoming 
> > > > > > > > > deadline, such as
> > > > > > > > > vblank, which the fence waiter would prefer not to miss.  
> > > > > > > > > This is to aid
> > > > > > > > > the fence signaler in making power management decisions, like 
> > > > > > > > > boosting
> > > > > > > > > frequency as the deadline approaches and awareness of missing 
> > > > > > > > > deadlines
> > > > > > > > > so that can be factored in to the frequency scaling.
> > > > > > > > >
> > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter 
> > > > > > > > > duplicate
> > > > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > > > fence-context
> > > > > > > > > implementation will need similar logic to track deadlines 
> > > > > > > > > of all
> > > > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > > > v6: More docs
> > > > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > > > >
> > > > > > > > > Signed-off-by: Rob Clark 
> > > > > > > > > Reviewed-by: Christian König 
> > > > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > > > ---
> > > > > > > >
> > > > > > > > Hi Rob!
> > > > > > > >
> > > > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > > > 
> > > > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > > > >  3 files changed, 87 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > :doc: fence signalling annotation
> > > > > > > > >
> > > > > > > > > +DMA Fence Deadline Hints
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > > +   :doc: deadline hints
> > > > > > > > > +
> > > > > > > > >  DMA Fences Functions Reference
> > > > > > > > >  ~~
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct 
> > > > > > > > > dma_fence **fences, uint32_t count,
> > > > > > > > >  }
> > > > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > > > >
> > > > > > > > > +/**
> > > > > > > > > + * DOC: deadline hints
> > > > > > > > > + *
> > > > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > > > workload sufficiently
> > > > > > > > > + * that a utilization based device frequency governor could 
> > > > > > > > > arrive at a minimum
> > > > > > > > > + * frequency that meets the requirements of the use-case, in 
> > > > > > > > > order to minimize
> > > > > > > > > + * power consumption.  But in the real world there are many 
> > > > > > > > > workloads which
> > > > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > > > + *
> > > > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > > > alternating periods
> > > > > > > > > + *   of CPU waiting for device, and device waiting on CPU.  
> > > > > > > > > This can result in
> > > > > > > > > + *   devfreq and cpufreq seeing idle time in their 
> > > > > > > > > respective domains and in
> > > > > > > > > + *   result reduce frequency.
> > > > > > > > > + *
> > > > > > > > > + * * Workloads that interact with a periodic time based 
> > > > > > > > > deadline,

[Freedreno] [PATCH v6 0/5] arm64: dts: qcom: add DP Controller to SM8350 & SM8450 DTS

[Neil Armstrong]

Switch the QMP PHY to the newly documented USB3/DP Combo PHY
bindings at [1] and add the DP controller nodes.

The DP output is shared with the USB3 SuperSpeed lanes and is
usually connected to an USB-C port which Altmode is controlled
by the PMIC Glink infrastructure in discution at [1] & [2].

DT changes tying the DP controller to the USB-C port on the HDK
boards will be sent later.

Bindings dependencies merged into v6.3-rc1.

[1] 
https://lore.kernel.org/all/20230201041853.1934355-1-quic_bjora...@quicinc.com/
[2] 
https://lore.kernel.org/all/20230130-topic-sm8450-upstream-pmic-glink-v2-0-71fea2564...@linaro.org/

Signed-off-by: Neil Armstrong 
---
Changes in v6:
- Revert DP opp changes
- Fix SM8450 combo PHY memory reg range
- Link to v5: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v5-0-a27f1b26e...@linaro.org

Changes in v5:
- Add review tags
- Fixed DP opp tables
- Link to v4: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v4-0-dca33f531...@linaro.org

Changes in v4:
- Updated trailers
- Fixed patch 4 compatible and reg sizes
- Link to v3: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v3-0-636ef9e99...@linaro.org

Changes in v3:
- Added Reviewed-by, Tested-by tags
- Used QMP PHY constants for phandle parameters
- Dropped reordering of mdp ports
- Added p1 dp regs address space
- Link to v2: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v2-0-529da2203...@linaro.org

Changes in v2:
- fixed the bindings
- cleaned up the usb_1_qmpphy &  displayport-controller nodes as requested by 
dmitry
- removed invalid mdss_dp0 change in sm8450-hdk.dts
- Link to v1: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v1-0-f1345872e...@linaro.org

---
Neil Armstrong (5):
  dt-bindings: display: msm: dp-controller: document SM8450 compatible
  arm64: dts: qcom: sm8350: switch to combo usb3/dp phy
  arm64: dts: qcom: sm8350: add dp controller
  arm64: dts: qcom: sm8450: switch to usb3/dp combo phy
  arm64: dts: qcom: sm8450: add dp controller

 .../bindings/display/msm/dp-controller.yaml|  25 +++--
 arch/arm64/boot/dts/qcom/sm8350.dtsi   | 121 -
 arch/arm64/boot/dts/qcom/sm8450.dtsi   | 121 -
 3 files changed, 203 insertions(+), 64 deletions(-)
---
base-commit: bf7a33dc3cca43baa4a4ecf86dcb6838fca09451
change-id: 20230206-topic-sm8450-upstream-dp-controller-20054ab280de

Best regards,
-- 
Neil Armstrong 

[Freedreno] [PATCH v6 4/5] arm64: dts: qcom: sm8450: switch to usb3/dp combo phy

[Neil Armstrong]

The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
 1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 69695eb83897..97ce5fe0e9b0 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -748,7 +749,7 @@ gcc: clock-controller@10 {
 <&ufs_mem_phy_lanes 0>,
 <&ufs_mem_phy_lanes 1>,
 <&ufs_mem_phy_lanes 2>,
-<0>;
+<&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
clock-names = "bi_tcxo",
  "sleep_clk",
  "pcie_0_pipe_clk",
@@ -2034,37 +2035,24 @@ usb_1_hsphy: phy@88e3000 {
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
};
 
-   usb_1_qmpphy: phy-wrapper@88e9000 {
-   compatible = "qcom,sm8450-qmp-usb3-phy";
-   reg = <0 0x088e9000 0 0x200>,
- <0 0x088e8000 0 0x20>;
-   status = "disabled";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   usb_1_qmpphy: phy@88e8000 {
+   compatible = "qcom,sm8450-qmp-usb3-dp-phy";
+   reg = <0 0x088e8000 0 0x3000>;
 
clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
 <&rpmhcc RPMH_CXO_CLK>,
-<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-   clock-names = "aux", "ref_clk_src", "com_aux";
+<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "aux", "ref", "com_aux", "usb3_pipe";
 
resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
 <&gcc GCC_USB3_PHY_PRIM_BCR>;
reset-names = "phy", "common";
 
-   usb_1_ssphy: phy@88e9200 {
-   reg = <0 0x088e9200 0 0x200>,
- <0 0x088e9400 0 0x200>,
- <0 0x088e9c00 0 0x400>,
- <0 0x088e9600 0 0x200>,
- <0 0x088e9800 0 0x200>,
- <0 0x088e9a00 0 0x100>;
-   #phy-cells = <0>;
-   #clock-cells = <0>;
-   clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-   clock-names = "pipe0";
-   clock-output-names = "usb3_phy_pipe_clk_src";
-   };
+   #clock-cells = <1>;
+   #phy-cells = <1>;
+
+   status = "disabled";
};
 
remoteproc_slpi: remoteproc@240 {
@@ -2972,8 +2960,8 @@ dispcc: clock-controller@af0 {
 <&mdss_dsi0_phy 1>,
 <&mdss_dsi1_phy 0>,
 <&mdss_dsi1_phy 1>,
-<0>, /* dp0 */
-<0>,
+<&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
 <0>, /* dp1 */
 <0>,
 <0>, /* dp2 */
@@ -4168,7 +4156,7 @@ usb_1_dwc3: usb@a60 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
-   phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+   phys = <&usb_1_hsphy>, <&usb_1_qmpphy 
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
};
};

-- 
2.34.1

[Freedreno] [PATCH v6 5/5] arm64: dts: qcom: sm8450: add dp controller

[Neil Armstrong]

Add the Display Port controller subnode to the MDSS node.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 97ce5fe0e9b0..da6d1881ef60 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2751,6 +2751,13 @@ dpu_intf2_out: endpoint {
};
};
 
+   port@2 {
+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp0_in>;
+   };
+   };
+
};
 
mdp_opp_table: opp-table {
@@ -2783,6 +2790,78 @@ opp-5 {
};
};
 
+   mdss_dp0: displayport-controller@ae9 {
+   compatible = "qcom,sm8450-dp", "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0xc00>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8450_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp0_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
+   };
+ 

[Freedreno] [PATCH v6 3/5] arm64: dts: qcom: sm8350: add dp controller

[Neil Armstrong]

Add the Display Port controller subnode to the MDSS node.

Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 975ab4cbe57e..2618aaa6a9f2 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2415,6 +2415,85 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<&mdss_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp_in>;
+   };
+   };
+   };
+   };
+
+   mdss_dp: displayport-controller@ae9 {
+   compatible = "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8350_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
};
}

[Freedreno] [PATCH v6 1/5] dt-bindings: display: msm: dp-controller: document SM8450 compatible

[Neil Armstrong]

The SM8450 & SM350 shares the same DT TX IP version, use the
SM8350 compatible as fallback for SM8450.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Neil Armstrong 
---
 .../bindings/display/msm/dp-controller.yaml| 25 +-
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 0e8d8df686dc..f0c2237d5f82 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -15,16 +15,21 @@ description: |
 
 properties:
   compatible:
-enum:
-  - qcom,sc7180-dp
-  - qcom,sc7280-dp
-  - qcom,sc7280-edp
-  - qcom,sc8180x-dp
-  - qcom,sc8180x-edp
-  - qcom,sc8280xp-dp
-  - qcom,sc8280xp-edp
-  - qcom,sdm845-dp
-  - qcom,sm8350-dp
+oneOf:
+  - enum:
+  - qcom,sc7180-dp
+  - qcom,sc7280-dp
+  - qcom,sc7280-edp
+  - qcom,sc8180x-dp
+  - qcom,sc8180x-edp
+  - qcom,sc8280xp-dp
+  - qcom,sc8280xp-edp
+  - qcom,sdm845-dp
+  - qcom,sm8350-dp
+  - items:
+  - enum:
+  - qcom,sm8450-dp
+  - const: qcom,sm8350-dp
 
   reg:
 minItems: 4

-- 
2.34.1

Re: [Freedreno] [PATCH v5 4/5] arm64: dts: qcom: sm8450: switch to usb3/dp combo phy

[Neil Armstrong]

On 17/03/2023 13:09, Dmitry Baryshkov wrote:

On 17/03/2023 11:12, Neil Armstrong wrote:

The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
  arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
  1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 69695eb83897..0b5a151ce138 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -748,7 +749,7 @@ gcc: clock-controller@10 {
   <&ufs_mem_phy_lanes 0>,
   <&ufs_mem_phy_lanes 1>,
   <&ufs_mem_phy_lanes 2>,
- <0>;
+ <&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
  clock-names = "bi_tcxo",
    "sleep_clk",
    "pcie_0_pipe_clk",
@@ -2034,37 +2035,24 @@ usb_1_hsphy: phy@88e3000 {
  resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
  };
-    usb_1_qmpphy: phy-wrapper@88e9000 {
-    compatible = "qcom,sm8450-qmp-usb3-phy";
-    reg = <0 0x088e9000 0 0x200>,
-  <0 0x088e8000 0 0x20>;
-    status = "disabled";
-    #address-cells = <2>;
-    #size-cells = <2>;
-    ranges;
+    usb_1_qmpphy: phy@88e8000 {
+    compatible = "qcom,sm8450-qmp-usb3-dp-phy";
+    reg = <0 0x088e8000 0 0x4000>;


This should be 0x3000 too, like 8350


Ack thx for noticing




  clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
   <&rpmhcc RPMH_CXO_CLK>,
- <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-    clock-names = "aux", "ref_clk_src", "com_aux";
+ <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+    clock-names = "aux", "ref", "com_aux", "usb3_pipe";
  resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
   <&gcc GCC_USB3_PHY_PRIM_BCR>;
  reset-names = "phy", "common";
-    usb_1_ssphy: phy@88e9200 {
-    reg = <0 0x088e9200 0 0x200>,
-  <0 0x088e9400 0 0x200>,
-  <0 0x088e9c00 0 0x400>,
-  <0 0x088e9600 0 0x200>,
-  <0 0x088e9800 0 0x200>,
-  <0 0x088e9a00 0 0x100>;
-    #phy-cells = <0>;
-    #clock-cells = <0>;
-    clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-    clock-names = "pipe0";
-    clock-output-names = "usb3_phy_pipe_clk_src";
-    };
+    #clock-cells = <1>;
+    #phy-cells = <1>;
+
+    status = "disabled";
  };
  remoteproc_slpi: remoteproc@240 {
@@ -2972,8 +2960,8 @@ dispcc: clock-controller@af0 {
   <&mdss_dsi0_phy 1>,
   <&mdss_dsi1_phy 0>,
   <&mdss_dsi1_phy 1>,
- <0>, /* dp0 */
- <0>,
+ <&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
   <0>, /* dp1 */
   <0>,
   <0>, /* dp2 */
@@ -4168,7 +4156,7 @@ usb_1_dwc3: usb@a60 {
  iommus = <&apps_smmu 0x0 0x0>;
  snps,dis_u2_susphy_quirk;
  snps,dis_enblslpm_quirk;
-    phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+    phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
  phy-names = "usb2-phy", "usb3-phy";
  };
  };

Re: [Freedreno] [PATCH v5 5/5] arm64: dts: qcom: sm8450: add dp controller

[Neil Armstrong]

On 17/03/2023 13:19, Dmitry Baryshkov wrote:

On 17/03/2023 11:12, Neil Armstrong wrote:

Add the Display Port controller subnode to the MDSS node.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
  arch/arm64/boot/dts/qcom/sm8450.dtsi | 79 
  1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 0b5a151ce138..41f5015e615b 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2751,6 +2751,13 @@ dpu_intf2_out: endpoint {
  };
  };
+    port@2 {
+    reg = <2>;
+    dpu_intf0_out: endpoint {
+    remote-endpoint = <&mdss_dp0_in>;
+    };
+    };
+
  };
  mdp_opp_table: opp-table {
@@ -2783,6 +2790,78 @@ opp-5 {
  };
  };
+    mdss_dp0: displayport-controller@ae9 {
+    compatible = "qcom,sm8450-dp", "qcom,sm8350-dp";
+    reg = <0 0xae9 0 0x200>,
+  <0 0xae90200 0 0x200>,
+  <0 0xae90400 0 0xc00>,
+  <0 0xae91000 0 0x400>,
+  <0 0xae91400 0 0x400>;
+    interrupt-parent = <&mdss>;
+    interrupts = <12>;
+    clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+ <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK>;
+    clock-names = "core_iface",
+  "core_aux",
+  "ctrl_link",
+  "ctrl_link_iface",
+  "stream_pixel";
+
+    assigned-clocks = <&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+  <&dispcc DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>;
+    assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+ <&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+    phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+    phy-names = "dp";
+
+    #sound-dai-cells = <0>;
+
+    operating-points-v2 = <&dp_opp_table>;
+    power-domains = <&rpmhpd SM8450_MMCX>;
+
+    status = "disabled";
+
+    ports {
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    port@0 {
+    reg = <0>;
+    mdss_dp0_in: endpoint {
+    remote-endpoint = <&dpu_intf0_out>;
+    };
+    };
+    };
+
+    dp_opp_table: opp-table {
+    compatible = "operating-points-v2";
+
+    opp-1920 {
+    opp-hz = /bits/ 64 <1920>;
+    required-opps = <&rpmhpd_opp_low_svs>;
+    };


Yes, the vendor kernel has 19.2 MHz as a frequency for the low_svs. However I 
don't think we should do it this way, we list DP rates here, so the lowest 
entry should be RBR, 16000.


Ok so v4 for ok for both patches 3 & 5

Will send v6 with those reverted

Neil




+
+    opp-27000 {
+    opp-hz = /bits/ 64 <27000>;
+    required-opps = <&rpmhpd_opp_svs>;
+    };
+
+    opp-54000 {
+    opp-hz = /bits/ 64 <54000>;
+    required-opps = <&rpmhpd_opp_svs_l1>;
+    };
+
+    opp-81000 {
+    opp-hz = /bits/ 64 <81000>;
+    required-opps = <&rpmhpd_opp_nom>;
+    };
+    };
+    };
+
  mdss_dsi0: dsi@ae94000 {
  compatible = "qcom,sm8450-dsi-ctrl", "qcom,mdss-dsi-ctrl";
  reg = <0 0x0ae94000 0 0x400>;

Re: [Freedreno] [PATCH v5 5/5] arm64: dts: qcom: sm8450: add dp controller

[Dmitry Baryshkov]

On 17/03/2023 11:12, Neil Armstrong wrote:

Add the Display Port controller subnode to the MDSS node.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
  arch/arm64/boot/dts/qcom/sm8450.dtsi | 79 
  1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 0b5a151ce138..41f5015e615b 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2751,6 +2751,13 @@ dpu_intf2_out: endpoint {
};
};
  
+	port@2 {

+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp0_in>;
+   };
+   };
+
};
  
  mdp_opp_table: opp-table {

@@ -2783,6 +2790,78 @@ opp-5 {
};
};
  
+			mdss_dp0: displayport-controller@ae9 {

+   compatible = "qcom,sm8450-dp", "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0xc00>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8450_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp0_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };


Yes, the vendor kernel has 19.2 MHz as a frequency for the low_svs. 
However I don't think we should do it this way, we list DP rates here, 
so the lowest entry should be RBR, 16000.



+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bit

Re: [Freedreno] [PATCH v5 3/5] arm64: dts: qcom: sm8350: add dp controller

[Dmitry Baryshkov]

On 17/03/2023 11:12, Neil Armstrong wrote:

Add the Display Port controller subnode to the MDSS node.

Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Neil Armstrong 
---
  arch/arm64/boot/dts/qcom/sm8350.dtsi | 74 
  1 file changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 975ab4cbe57e..37ae4a948be1 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2415,6 +2415,80 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<&mdss_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp_in>;
+   };
+   };
+   };
+   };
+
+   mdss_dp: displayport-controller@ae9 {
+   compatible = "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8350_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";


I think we still need an OPP entry for RBR rate (16000). Downstream 
would resort to low_svs in such case, the min voltage for MMCX domain.



+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
};
};
  



--
With best wishes
Dmitry

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Pekka Paalanen]

On Thu, 16 Mar 2023 23:22:24 +0100
Sebastian Wick  wrote:

> On Thu, Mar 16, 2023 at 5:29 PM Rob Clark  wrote:
> >
> > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:  
> > >
> > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:  
> > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:  
> > > > >
> > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:  
> > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  
> > > > > > wrote:  
> > > > > > >
> > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:  
> > > > > > > > From: Rob Clark 
> > > > > > > >
> > > > > > > > Add a way to hint to the fence signaler of an upcoming 
> > > > > > > > deadline, such as
> > > > > > > > vblank, which the fence waiter would prefer not to miss.  This 
> > > > > > > > is to aid
> > > > > > > > the fence signaler in making power management decisions, like 
> > > > > > > > boosting
> > > > > > > > frequency as the deadline approaches and awareness of missing 
> > > > > > > > deadlines
> > > > > > > > so that can be factored in to the frequency scaling.
> > > > > > > >
> > > > > > > > v2: Drop dma_fence::deadline and related logic to filter 
> > > > > > > > duplicate
> > > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > > fence-context
> > > > > > > > implementation will need similar logic to track deadlines 
> > > > > > > > of all
> > > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > > v6: More docs
> > > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > > >
> > > > > > > > Signed-off-by: Rob Clark 
> > > > > > > > Reviewed-by: Christian König 
> > > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > > ---  
> > > > > > >
> > > > > > > Hi Rob!
> > > > > > >  
> > > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > > 
> > > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > > >  3 files changed, 87 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > :doc: fence signalling annotation
> > > > > > > >
> > > > > > > > +DMA Fence Deadline Hints
> > > > > > > > +
> > > > > > > > +
> > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > > +   :doc: deadline hints
> > > > > > > > +
> > > > > > > >  DMA Fences Functions Reference
> > > > > > > >  ~~
> > > > > > > >
> > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct 
> > > > > > > > dma_fence **fences, uint32_t count,
> > > > > > > >  }
> > > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > > >
> > > > > > > > +/**
> > > > > > > > + * DOC: deadline hints
> > > > > > > > + *
> > > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > > workload sufficiently
> > > > > > > > + * that a utilization based device frequency governor could 
> > > > > > > > arrive at a minimum
> > > > > > > > + * frequency that meets the requirements of the use-case, in 
> > > > > > > > order to minimize
> > > > > > > > + * power consumption.  But in the real world there are many 
> > > > > > > > workloads which
> > > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > > + *
> > > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > > alternating periods
> > > > > > > > + *   of CPU waiting for device, and device waiting on CPU.  
> > > > > > > > This can result in
> > > > > > > > + *   devfreq and cpufreq seeing idle time in their respective 
> > > > > > > > domains and in
> > > > > > > > + *   result reduce frequency.
> > > > > > > > + *
> > > > > > > > + * * Workloads that interact with a periodic time based 
> > > > > > > > deadline, such as double
> > > > > > > > + *   buffered GPU rendering vs vblank sync'd page flipping.  
> > > > > > > > In this scenario,
> > > > > > > > + *   missing a vblank deadline results in an *increase* in 
> > > > > > > > idle time on the GPU
> 

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Pekka Paalanen]

On Fri, 17 Mar 2023 11:17:37 +0200
Pekka Paalanen  wrote:

> On Fri, 17 Mar 2023 11:09:21 +0200
> Pekka Paalanen  wrote:
> 
> > On Thu, 16 Mar 2023 23:22:24 +0100
> > Sebastian Wick  wrote:  
> 
> > > Vblank can be really long, especially with VRR where the additional
> > > time you get to finish the frame comes from making vblank longer.  
> 
> Btw. VRR extends front porch, not vblank.

Need to correct myself too. vblank includes front porch, vsync does not.

https://electronics.stackexchange.com/questions/166681/how-exactly-does-a-vga-cable-work


Thanks,
pq


pgpYUaunRBg06.pgp
Description: OpenPGP digital signature

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Pekka Paalanen]

On Fri, 17 Mar 2023 11:09:21 +0200
Pekka Paalanen  wrote:

> On Thu, 16 Mar 2023 23:22:24 +0100
> Sebastian Wick  wrote:

> > Vblank can be really long, especially with VRR where the additional
> > time you get to finish the frame comes from making vblank longer.

Btw. VRR extends front porch, not vblank.


Thanks,
pq


pgpVxuE8kGfuk.pgp
Description: OpenPGP digital signature

Re: [Freedreno] [PATCH v5 4/5] arm64: dts: qcom: sm8450: switch to usb3/dp combo phy

[Dmitry Baryshkov]

On 17/03/2023 11:12, Neil Armstrong wrote:

The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
  arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
  1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 69695eb83897..0b5a151ce138 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -748,7 +749,7 @@ gcc: clock-controller@10 {
 <&ufs_mem_phy_lanes 0>,
 <&ufs_mem_phy_lanes 1>,
 <&ufs_mem_phy_lanes 2>,
-<0>;
+<&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
clock-names = "bi_tcxo",
  "sleep_clk",
  "pcie_0_pipe_clk",
@@ -2034,37 +2035,24 @@ usb_1_hsphy: phy@88e3000 {
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
};
  
-		usb_1_qmpphy: phy-wrapper@88e9000 {

-   compatible = "qcom,sm8450-qmp-usb3-phy";
-   reg = <0 0x088e9000 0 0x200>,
- <0 0x088e8000 0 0x20>;
-   status = "disabled";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   usb_1_qmpphy: phy@88e8000 {
+   compatible = "qcom,sm8450-qmp-usb3-dp-phy";
+   reg = <0 0x088e8000 0 0x4000>;


This should be 0x3000 too, like 8350

  
  			clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,

 <&rpmhcc RPMH_CXO_CLK>,
-<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-   clock-names = "aux", "ref_clk_src", "com_aux";
+<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "aux", "ref", "com_aux", "usb3_pipe";
  
  			resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,

 <&gcc GCC_USB3_PHY_PRIM_BCR>;
reset-names = "phy", "common";
  
-			usb_1_ssphy: phy@88e9200 {

-   reg = <0 0x088e9200 0 0x200>,
- <0 0x088e9400 0 0x200>,
- <0 0x088e9c00 0 0x400>,
- <0 0x088e9600 0 0x200>,
- <0 0x088e9800 0 0x200>,
- <0 0x088e9a00 0 0x100>;
-   #phy-cells = <0>;
-   #clock-cells = <0>;
-   clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-   clock-names = "pipe0";
-   clock-output-names = "usb3_phy_pipe_clk_src";
-   };
+   #clock-cells = <1>;
+   #phy-cells = <1>;
+
+   status = "disabled";
};
  
  		remoteproc_slpi: remoteproc@240 {

@@ -2972,8 +2960,8 @@ dispcc: clock-controller@af0 {
 <&mdss_dsi0_phy 1>,
 <&mdss_dsi1_phy 0>,
 <&mdss_dsi1_phy 1>,
-<0>, /* dp0 */
-<0>,
+<&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
 <0>, /* dp1 */
 <0>,
 <0>, /* dp2 */
@@ -4168,7 +4156,7 @@ usb_1_dwc3: usb@a60 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
-   phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+   phys = <&usb_1_hsphy>, <&usb_1_qmpphy 
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
};
};



--
With best wishes
Dmitry

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Jonas Ådahl]

On Thu, Mar 16, 2023 at 09:28:55AM -0700, Rob Clark wrote:
> On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
> >
> > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
> > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:
> > > >
> > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
> > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  wrote:
> > > > > >
> > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote:
> > > > > > > From: Rob Clark 
> > > > > > >
> > > > > > > Add a way to hint to the fence signaler of an upcoming deadline, 
> > > > > > > such as
> > > > > > > vblank, which the fence waiter would prefer not to miss.  This is 
> > > > > > > to aid
> > > > > > > the fence signaler in making power management decisions, like 
> > > > > > > boosting
> > > > > > > frequency as the deadline approaches and awareness of missing 
> > > > > > > deadlines
> > > > > > > so that can be factored in to the frequency scaling.
> > > > > > >
> > > > > > > v2: Drop dma_fence::deadline and related logic to filter duplicate
> > > > > > > deadlines, to avoid increasing dma_fence size.  The 
> > > > > > > fence-context
> > > > > > > implementation will need similar logic to track deadlines of 
> > > > > > > all
> > > > > > > the fences on the same timeline.  [ckoenig]
> > > > > > > v3: Clarify locking wrt. set_deadline callback
> > > > > > > v4: Clarify in docs comment that this is a hint
> > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT.
> > > > > > > v6: More docs
> > > > > > > v7: Fix typo, clarify past deadlines
> > > > > > >
> > > > > > > Signed-off-by: Rob Clark 
> > > > > > > Reviewed-by: Christian König 
> > > > > > > Acked-by: Pekka Paalanen 
> > > > > > > Reviewed-by: Bagas Sanjaya 
> > > > > > > ---
> > > > > >
> > > > > > Hi Rob!
> > > > > >
> > > > > > >  Documentation/driver-api/dma-buf.rst |  6 +++
> > > > > > >  drivers/dma-buf/dma-fence.c  | 59 
> > > > > > > 
> > > > > > >  include/linux/dma-fence.h| 22 +++
> > > > > > >  3 files changed, 87 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst 
> > > > > > > b/Documentation/driver-api/dma-buf.rst
> > > > > > > index 622b8156d212..183e480d8cea 100644
> > > > > > > --- a/Documentation/driver-api/dma-buf.rst
> > > > > > > +++ b/Documentation/driver-api/dma-buf.rst
> > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations
> > > > > > >  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > :doc: fence signalling annotation
> > > > > > >
> > > > > > > +DMA Fence Deadline Hints
> > > > > > > +
> > > > > > > +
> > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> > > > > > > +   :doc: deadline hints
> > > > > > > +
> > > > > > >  DMA Fences Functions Reference
> > > > > > >  ~~
> > > > > > >
> > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > index 0de0482cd36e..f177c56269bb 100644
> > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence 
> > > > > > > **fences, uint32_t count,
> > > > > > >  }
> > > > > > >  EXPORT_SYMBOL(dma_fence_wait_any_timeout);
> > > > > > >
> > > > > > > +/**
> > > > > > > + * DOC: deadline hints
> > > > > > > + *
> > > > > > > + * In an ideal world, it would be possible to pipeline a 
> > > > > > > workload sufficiently
> > > > > > > + * that a utilization based device frequency governor could 
> > > > > > > arrive at a minimum
> > > > > > > + * frequency that meets the requirements of the use-case, in 
> > > > > > > order to minimize
> > > > > > > + * power consumption.  But in the real world there are many 
> > > > > > > workloads which
> > > > > > > + * defy this ideal.  For example, but not limited to:
> > > > > > > + *
> > > > > > > + * * Workloads that ping-pong between device and CPU, with 
> > > > > > > alternating periods
> > > > > > > + *   of CPU waiting for device, and device waiting on CPU.  This 
> > > > > > > can result in
> > > > > > > + *   devfreq and cpufreq seeing idle time in their respective 
> > > > > > > domains and in
> > > > > > > + *   result reduce frequency.
> > > > > > > + *
> > > > > > > + * * Workloads that interact with a periodic time based 
> > > > > > > deadline, such as double
> > > > > > > + *   buffered GPU rendering vs vblank sync'd page flipping.  In 
> > > > > > > this scenario,
> > > > > > > + *   missing a vblank deadline results in an *increase* in idle 
> > > > > > > time on the GPU
> > > > > > > + *   (since it has to wait an additional vblank period), sending 
> > > > > > > a signal to
> > > > > > > + *   the GPU's devfreq to reduce frequency, when in fact the 
> > > > > > > opposite is what is
> > > > > > > + *   needed.
> > > > > >
> > > > > > This is the use case I'd like to get s

Re: [Freedreno] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness

[Michel Dänzer]

On 3/16/23 23:22, Sebastian Wick wrote:
> On Thu, Mar 16, 2023 at 5:29 PM Rob Clark  wrote:
>> On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl  wrote:
>>> On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote:
 On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl  wrote:
> On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote:
>> On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl  wrote:
>>>
 + *
 + * To this end, deadline hint(s) can be set on a &dma_fence via 
 &dma_fence_set_deadline.
 + * The deadline hint provides a way for the waiting driver, or 
 userspace, to
 + * convey an appropriate sense of urgency to the signaling driver.
 + *
 + * A deadline hint is given in absolute ktime (CLOCK_MONOTONIC for 
 userspace
 + * facing APIs).  The time could either be some point in the future 
 (such as
 + * the vblank based deadline for page-flipping, or the start of a 
 compositor's
 + * composition cycle), or the current time to indicate an immediate 
 deadline
 + * hint (Ie. forward progress cannot be made until this fence is 
 signaled).
>>>
>>> Is it guaranteed that a GPU driver will use the actual start of the
>>> vblank as the effective deadline? I have some memories of seing
>>> something about vblank evasion browsing driver code, which I might have
>>> misunderstood, but I have yet to find whether this is something
>>> userspace can actually expect to be something it can rely on.
>>
>> I guess you mean s/GPU driver/display driver/ ?  It makes things more
>> clear if we talk about them separately even if they happen to be the
>> same device.
>
> Sure, sorry about being unclear about that.
>
>>
>> Assuming that is what you mean, nothing strongly defines what the
>> deadline is.  In practice there is probably some buffering in the
>> display controller.  For ex, block based (including bandwidth
>> compressed) formats, you need to buffer up a row of blocks to
>> efficiently linearize for scanout.  So you probably need to latch some
>> time before you start sending pixel data to the display.  But details
>> like this are heavily implementation dependent.  I think the most
>> reasonable thing to target is start of vblank.
>
> The driver exposing those details would be quite useful for userspace
> though, so that it can delay committing updates to late, but not too
> late. Setting a deadline to be the vblank seems easy enough, but it
> isn't enough for scheduling the actual commit.

 I'm not entirely sure how that would even work.. but OTOH I think you
 are talking about something on the order of 100us?  But that is a bit
 of another topic.
>>>
>>> Yes, something like that. But yea, it's not really related. Scheduling
>>> commits closer to the deadline has more complex behavior than that too,
>>> e.g. the need for real time scheduling, and knowing how long it usually
>>> takes to create and commit and for the kernel to process.
> 
> Vblank can be really long, especially with VRR where the additional
> time you get to finish the frame comes from making vblank longer.
> Using the start of vblank as a deadline makes VRR useless.

Not really. We normally still want to aim for start of vblank with VRR, which 
would result in the maximum refresh rate. Missing that target just incurs less 
of a penalty than with fixed refresh rate.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

[Freedreno] [PATCH v5 3/5] arm64: dts: qcom: sm8350: add dp controller

[Neil Armstrong]

Add the Display Port controller subnode to the MDSS node.

Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 74 
 1 file changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 975ab4cbe57e..37ae4a948be1 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -2415,6 +2415,80 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<&mdss_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp_in>;
+   };
+   };
+   };
+   };
+
+   mdss_dp: displayport-controller@ae9 {
+   compatible = "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DP_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DP_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8350_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
};
};
 

-- 
2.34.1

[Freedreno] [PATCH v5 5/5] arm64: dts: qcom: sm8450: add dp controller

[Neil Armstrong]

Add the Display Port controller subnode to the MDSS node.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 0b5a151ce138..41f5015e615b 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -2751,6 +2751,13 @@ dpu_intf2_out: endpoint {
};
};
 
+   port@2 {
+   reg = <2>;
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<&mdss_dp0_in>;
+   };
+   };
+
};
 
mdp_opp_table: opp-table {
@@ -2783,6 +2790,78 @@ opp-5 {
};
};
 
+   mdss_dp0: displayport-controller@ae9 {
+   compatible = "qcom,sm8450-dp", "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0xc00>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <&mdss>;
+   interrupts = <12>;
+   clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_AUX_CLK>,
+<&dispcc DISP_CC_MDSS_DPTX0_LINK_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>,
+<&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = <&dispcc 
DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>,
+ <&dispcc 
DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>;
+   assigned-clock-parents = <&usb_1_qmpphy 
QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy 
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+   phys = <&usb_1_qmpphy QMP_USB43DP_DP_PHY>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <&dp_opp_table>;
+   power-domains = <&rpmhpd SM8450_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp0_in: endpoint {
+   remote-endpoint = 
<&dpu_intf0_out>;
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
+  

[Freedreno] [PATCH v5 4/5] arm64: dts: qcom: sm8450: switch to usb3/dp combo phy

[Neil Armstrong]

The QMP PHY is a USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 42 +---
 1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi 
b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 69695eb83897..0b5a151ce138 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -748,7 +749,7 @@ gcc: clock-controller@10 {
 <&ufs_mem_phy_lanes 0>,
 <&ufs_mem_phy_lanes 1>,
 <&ufs_mem_phy_lanes 2>,
-<0>;
+<&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>;
clock-names = "bi_tcxo",
  "sleep_clk",
  "pcie_0_pipe_clk",
@@ -2034,37 +2035,24 @@ usb_1_hsphy: phy@88e3000 {
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
};
 
-   usb_1_qmpphy: phy-wrapper@88e9000 {
-   compatible = "qcom,sm8450-qmp-usb3-phy";
-   reg = <0 0x088e9000 0 0x200>,
- <0 0x088e8000 0 0x20>;
-   status = "disabled";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   usb_1_qmpphy: phy@88e8000 {
+   compatible = "qcom,sm8450-qmp-usb3-dp-phy";
+   reg = <0 0x088e8000 0 0x4000>;
 
clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
 <&rpmhcc RPMH_CXO_CLK>,
-<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-   clock-names = "aux", "ref_clk_src", "com_aux";
+<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "aux", "ref", "com_aux", "usb3_pipe";
 
resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
 <&gcc GCC_USB3_PHY_PRIM_BCR>;
reset-names = "phy", "common";
 
-   usb_1_ssphy: phy@88e9200 {
-   reg = <0 0x088e9200 0 0x200>,
- <0 0x088e9400 0 0x200>,
- <0 0x088e9c00 0 0x400>,
- <0 0x088e9600 0 0x200>,
- <0 0x088e9800 0 0x200>,
- <0 0x088e9a00 0 0x100>;
-   #phy-cells = <0>;
-   #clock-cells = <0>;
-   clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-   clock-names = "pipe0";
-   clock-output-names = "usb3_phy_pipe_clk_src";
-   };
+   #clock-cells = <1>;
+   #phy-cells = <1>;
+
+   status = "disabled";
};
 
remoteproc_slpi: remoteproc@240 {
@@ -2972,8 +2960,8 @@ dispcc: clock-controller@af0 {
 <&mdss_dsi0_phy 1>,
 <&mdss_dsi1_phy 0>,
 <&mdss_dsi1_phy 1>,
-<0>, /* dp0 */
-<0>,
+<&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>,
 <0>, /* dp1 */
 <0>,
 <0>, /* dp2 */
@@ -4168,7 +4156,7 @@ usb_1_dwc3: usb@a60 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
-   phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+   phys = <&usb_1_hsphy>, <&usb_1_qmpphy 
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
};
};

-- 
2.34.1

[Freedreno] [PATCH v5 2/5] arm64: dts: qcom: sm8350: switch to combo usb3/dp phy

[Neil Armstrong]

The first QMP PHY is an USB3/DP combo phy, switch to the newly
documented bindings and register the clocks to the GCC
and DISPCC controllers.

Reviewed-by: Dmitry Baryshkov 
Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Konrad Dybcio 
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 42 +---
 1 file changed, 15 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi 
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 1afc4311796e..975ab4cbe57e 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -661,7 +662,7 @@ gcc: clock-controller@10 {
 <&ufs_mem_phy_lanes 0>,
 <&ufs_mem_phy_lanes 1>,
 <&ufs_mem_phy_lanes 2>,
-<0>,
+<&usb_1_qmpphy QMP_USB43DP_USB3_PIPE_CLK>,
 <0>;
};
 
@@ -2135,37 +2136,24 @@ usb_2_hsphy: phy@88e4000 {
resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
};
 
-   usb_1_qmpphy: phy-wrapper@88e9000 {
-   compatible = "qcom,sm8350-qmp-usb3-phy";
-   reg = <0 0x088e9000 0 0x200>,
- <0 0x088e8000 0 0x20>;
-   status = "disabled";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   usb_1_qmpphy: phy@88e9000 {
+   compatible = "qcom,sm8350-qmp-usb3-dp-phy";
+   reg = <0 0x088e8000 0 0x3000>;
 
clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
 <&rpmhcc RPMH_CXO_CLK>,
-<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
-   clock-names = "aux", "ref_clk_src", "com_aux";
+<&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+<&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "aux", "ref", "com_aux", "usb3_pipe";
 
resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
 <&gcc GCC_USB3_PHY_PRIM_BCR>;
reset-names = "phy", "common";
 
-   usb_1_ssphy: phy@88e9200 {
-   reg = <0 0x088e9200 0 0x200>,
- <0 0x088e9400 0 0x200>,
- <0 0x088e9c00 0 0x400>,
- <0 0x088e9600 0 0x200>,
- <0 0x088e9800 0 0x200>,
- <0 0x088e9a00 0 0x100>;
-   #phy-cells = <0>;
-   #clock-cells = <0>;
-   clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
-   clock-names = "pipe0";
-   clock-output-names = "usb3_phy_pipe_clk_src";
-   };
+   #clock-cells = <1>;
+   #phy-cells = <1>;
+
+   status = "disabled";
};
 
usb_2_qmpphy: phy-wrapper@88eb000 {
@@ -2268,7 +2256,7 @@ usb_1_dwc3: usb@a60 {
iommus = <&apps_smmu 0x0 0x0>;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
-   phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+   phys = <&usb_1_hsphy>, <&usb_1_qmpphy 
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
};
};
@@ -2633,8 +2621,8 @@ dispcc: clock-controller@af0 {
clocks = <&rpmhcc RPMH_CXO_CLK>,
 <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>,
 <&mdss_dsi1_phy 0>, <&mdss_dsi1_phy 1>,
-<0>,
-<0>;
+<&usb_1_qmpphy QMP_USB43DP_DP_LINK_CLK>,
+<&usb_1_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>;
clock-names = "bi_tcxo",
  "dsi0_phy_pll_out_byteclk",
  "dsi0_phy_pll_out_dsiclk",

-- 
2.34.1

[Freedreno] [PATCH v5 1/5] dt-bindings: display: msm: dp-controller: document SM8450 compatible

[Neil Armstrong]

The SM8450 & SM350 shares the same DT TX IP version, use the
SM8350 compatible as fallback for SM8450.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Neil Armstrong 
---
 .../bindings/display/msm/dp-controller.yaml| 25 +-
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 0e8d8df686dc..f0c2237d5f82 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -15,16 +15,21 @@ description: |
 
 properties:
   compatible:
-enum:
-  - qcom,sc7180-dp
-  - qcom,sc7280-dp
-  - qcom,sc7280-edp
-  - qcom,sc8180x-dp
-  - qcom,sc8180x-edp
-  - qcom,sc8280xp-dp
-  - qcom,sc8280xp-edp
-  - qcom,sdm845-dp
-  - qcom,sm8350-dp
+oneOf:
+  - enum:
+  - qcom,sc7180-dp
+  - qcom,sc7280-dp
+  - qcom,sc7280-edp
+  - qcom,sc8180x-dp
+  - qcom,sc8180x-edp
+  - qcom,sc8280xp-dp
+  - qcom,sc8280xp-edp
+  - qcom,sdm845-dp
+  - qcom,sm8350-dp
+  - items:
+  - enum:
+  - qcom,sm8450-dp
+  - const: qcom,sm8350-dp
 
   reg:
 minItems: 4

-- 
2.34.1

[Freedreno] [PATCH v5 0/5] arm64: dts: qcom: add DP Controller to SM8350 & SM8450 DTS

[Neil Armstrong]

Switch the QMP PHY to the newly documented USB3/DP Combo PHY
bindings at [1] and add the DP controller nodes.

The DP output is shared with the USB3 SuperSpeed lanes and is
usually connected to an USB-C port which Altmode is controlled
by the PMIC Glink infrastructure in discution at [1] & [2].

DT changes tying the DP controller to the USB-C port on the HDK
boards will be sent later.

Bindings dependencies merged into v6.3-rc1.

[1] 
https://lore.kernel.org/all/20230201041853.1934355-1-quic_bjora...@quicinc.com/
[2] 
https://lore.kernel.org/all/20230130-topic-sm8450-upstream-pmic-glink-v2-0-71fea2564...@linaro.org/

Signed-off-by: Neil Armstrong 
---
Changes in v5:
- Add review tags
- Fixed DP opp tables
- Link to v4: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v4-0-dca33f531...@linaro.org

Changes in v4:
- Updated trailers
- Fixed patch 4 compatible and reg sizes
- Link to v3: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v3-0-636ef9e99...@linaro.org

Changes in v3:
- Added Reviewed-by, Tested-by tags
- Used QMP PHY constants for phandle parameters
- Dropped reordering of mdp ports
- Added p1 dp regs address space
- Link to v2: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v2-0-529da2203...@linaro.org

Changes in v2:
- fixed the bindings
- cleaned up the usb_1_qmpphy &  displayport-controller nodes as requested by 
dmitry
- removed invalid mdss_dp0 change in sm8450-hdk.dts
- Link to v1: 
https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v1-0-f1345872e...@linaro.org

---
Neil Armstrong (5):
  dt-bindings: display: msm: dp-controller: document SM8450 compatible
  arm64: dts: qcom: sm8350: switch to combo usb3/dp phy
  arm64: dts: qcom: sm8350: add dp controller
  arm64: dts: qcom: sm8450: switch to usb3/dp combo phy
  arm64: dts: qcom: sm8450: add dp controller

 .../bindings/display/msm/dp-controller.yaml|  25 +++--
 arch/arm64/boot/dts/qcom/sm8350.dtsi   | 116 +++-
 arch/arm64/boot/dts/qcom/sm8450.dtsi   | 121 -
 3 files changed, 198 insertions(+), 64 deletions(-)
---
base-commit: 6f72958a49f68553f2b6ff713e8c8e51a34c1e1e
change-id: 20230206-topic-sm8450-upstream-dp-controller-20054ab280de

Best regards,
-- 
Neil Armstrong 

Re: [Freedreno] [PATCH v4 5/5] arm64: dts: qcom: sm8450: add dp controller

[Neil Armstrong]

On 14/03/2023 23:12, Konrad Dybcio wrote:



On 9.03.2023 10:19, Neil Armstrong wrote:

Add the Display Port controller subnode to the MDSS node.

Signed-off-by: Neil Armstrong 
---

[...]

+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };

Downstream seems to use 1920 here


Ack, will update.

Thx,
Neil



Otherwise,

Reviewed-by: Konrad Dybcio 

Konrad


+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
+   };
+   };
+
mdss_dsi0: dsi@ae94000 {
compatible = "qcom,sm8450-dsi-ctrl", 
"qcom,mdss-dsi-ctrl";
reg = <0 0x0ae94000 0 0x400>;

Re: [Freedreno] [PATCH v4 3/5] arm64: dts: qcom: sm8350: add dp controller

[Neil Armstrong]

On 14/03/2023 23:10, Konrad Dybcio wrote:



On 9.03.2023 10:19, Neil Armstrong wrote:

Add the Display Port controller subnode to the MDSS node.

Tested-by: Dmitry Baryshkov  #SM8350-HDK
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Neil Armstrong 
---

[...]

+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };

Downstream doesn't seem to use this lowest freq


Now I know to look at, indeed, will remove.

Thanks,
Neil



Konrad

+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-81000 {
+   opp-hz = /bits/ 64 <81000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
};
};
  

Re: [Freedreno] [PATCH v5 08/10] dt-bindings: display/msm: dsi-controller-main: Fix deprecated compatible

[Krzysztof Kozlowski]

On 16/03/2023 09:51, Konrad Dybcio wrote:
> The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl"
> alone. This however didn't quite work out and the property became
> undocumented instead of deprecated. Fix that.
> 
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible 
> strings for every current SoC")
> Reviewed-by: Marijn Suijten 
> Signed-off-by: Konrad Dybcio 
> ---

You have warnings caused by your previous patch and since you fix the
same commit, this should be rather squashed with #1.

Best regards,
Krzysztof