| Message ID | 20220917004404.414981-1-anusha.srivatsa@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce struct cdclk_step | expand |
On Fri, 16 Sep 2022 18:35:13 -0700, Patchwork wrote: > Hi Lakshmi, > Series: Introduce struct cdclk_step > URL: https://patchwork.freedesktop.org/series/108685/ > State: failure > Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > CI Bug Log - changes from CI_DRM_12148 -> Patchwork_108685v1 > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_108685v1 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108685v1, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > Participating hosts (43 -> 41) > > Additional (2): fi-icl-u2 fi-pnv-d510 > Missing (4): fi-ctg-p8600 fi-hsw-4200u fi-bdw-samus bat-dg1-5 > > Possible new issues > > Here are the unknown changes that may have been introduced in Patchwork_108685v1: > > IGT changes > > Possible regressions > > • igt@debugfs_test@read_all_entries: > □ fi-pnv-d510: NOTRUN -> INCOMPLETE This failure is unrelated and needs a new bug. Seems to be caused by: fe5979665f640 ("drm/i915/debugfs: Add perf_limit_reasons in debugfs") Thanks. -- Ashutosh
Filed a couple of issues and re-reported. This one Likely a regression? https://gitlab.freedesktop.org/drm/intel/-/issues/6864 Few tests - dmesg-warn/dmesg-fail/incomplete -BUG: unable to handle page fault for address .*, #PF: supervisor read access in kernel mode, RIP: 0010:__list_add_valid, Call Trace: dma_fence_default_wait, dma_fence_add_callback https://gitlab.freedesktop.org/drm/intel/-/issues/6863 igt@debugfs_test@read_all_entries - incomplete - BUG: unable to handle page fault for address: ffffc90000bb81a8, RIP: 0010:gen2_read32 Lakshmi. -----Original Message----- From: Dixit, Ashutosh <ashutosh.dixit@intel.com> Sent: Friday, September 16, 2022 7:08 PM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana <lakshminarayana.vudum@intel.com> Cc: Srivatsa, Anusha <anusha.srivatsa@intel.com> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce struct cdclk_step On Fri, 16 Sep 2022 18:35:13 -0700, Patchwork wrote: > Hi Lakshmi, > Series: Introduce struct cdclk_step > URL: https://patchwork.freedesktop.org/series/108685/ > State: failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > CI Bug Log - changes from CI_DRM_12148 -> Patchwork_108685v1 > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_108685v1 absolutely need > to be verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108685v1, please notify your bug team to allow > them to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > Participating hosts (43 -> 41) > > Additional (2): fi-icl-u2 fi-pnv-d510 > Missing (4): fi-ctg-p8600 fi-hsw-4200u fi-bdw-samus bat-dg1-5 > > Possible new issues > > Here are the unknown changes that may have been introduced in Patchwork_108685v1: > > IGT changes > > Possible regressions > > • igt@debugfs_test@read_all_entries: > □ fi-pnv-d510: NOTRUN -> INCOMPLETE This failure is unrelated and needs a new bug. Seems to be caused by: fe5979665f640 ("drm/i915/debugfs: Add perf_limit_reasons in debugfs") Thanks. -- Ashutosh
On Sun, 18 Sep 2022 23:35:56 -0700, Vudum, Lakshminarayana wrote: > Hi Lakshmi, > Filed a couple of issues and re-reported. > > This one Likely a regression? > https://gitlab.freedesktop.org/drm/intel/-/issues/6864 > Few tests - dmesg-warn/dmesg-fail/incomplete -BUG: unable to handle page fault for address .*, #PF: supervisor read access in kernel mode, RIP: 0010:__list_add_valid, Call Trace: dma_fence_default_wait, dma_fence_add_callback > > https://gitlab.freedesktop.org/drm/intel/-/issues/6863 > igt@debugfs_test@read_all_entries - incomplete - BUG: unable to handle page fault for address: ffffc90000bb81a8, RIP: 0010:gen2_read32 Not sure about https://gitlab.freedesktop.org/drm/intel/-/issues/6864, I didn't see it. I was mentioning https://gitlab.freedesktop.org/drm/intel/-/issues/6863. This is a regression. I have already submitted a fix for it: https://patchwork.freedesktop.org/series/108747/ Thanks. -- Ashutosh > Lakshmi. > > -----Original Message----- > From: Dixit, Ashutosh <ashutosh.dixit@intel.com> > Sent: Friday, September 16, 2022 7:08 PM > To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana <lakshminarayana.vudum@intel.com> > Cc: Srivatsa, Anusha <anusha.srivatsa@intel.com> > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce struct cdclk_step > > On Fri, 16 Sep 2022 18:35:13 -0700, Patchwork wrote: > > > > Hi Lakshmi, > > > Series: Introduce struct cdclk_step > > URL: https://patchwork.freedesktop.org/series/108685/ > > State: failure > > Details: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > > > CI Bug Log - changes from CI_DRM_12148 -> Patchwork_108685v1 > > > > Summary > > > > FAILURE > > > > Serious unknown changes coming with Patchwork_108685v1 absolutely need > > to be verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_108685v1, please notify your bug team to allow > > them to document this new failure mode, which will reduce false positives in CI. > > > > External URL: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108685v1/index.html > > > > Participating hosts (43 -> 41) > > > > Additional (2): fi-icl-u2 fi-pnv-d510 > > Missing (4): fi-ctg-p8600 fi-hsw-4200u fi-bdw-samus bat-dg1-5 > > > > Possible new issues > > > > Here are the unknown changes that may have been introduced in Patchwork_108685v1: > > > > IGT changes > > > > Possible regressions > > > > • igt@debugfs_test@read_all_entries: > > □ fi-pnv-d510: NOTRUN -> INCOMPLETE > > This failure is unrelated and needs a new bug. Seems to be caused by: > > fe5979665f640 ("drm/i915/debugfs: Add perf_limit_reasons in debugfs") > > Thanks. > -- > Ashutosh
Please find the review commenst for the respective patches. Also as a general rule, please add/ copy all folks nvolved in offline discussions/ triage help in order to accelerate reviews and get feedback from all. Manasi On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > This is a prep series for the actual cdclk refactoring > that will be sent following this. Idea is to have a > struct - cdclk_step that holds the following: > - cdclk action (squash, crawl or modeset) > - cdclk frequency > which gets populated in atomic check. Driver > uses the populated values during atomic commit > to do the suitable sequence of actions like > programming squash ctl registers in case of squashing > or PLL sequence incase of modeset and so on. > > This series just addresses the initial idea. The actual plumming > in the atomic commit phase will be sent shortly. > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Uma Shankar <uma.shankar@intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Anusha Srivatsa (6): > drm/i915/display Add dg2_prog_squash_ctl() helper > drm/i915/display: add cdclk action struct to cdclk_config > drm/i915/display: Embed the new struct steps for squashing > drm/i915/display: Embed the new struct steps for crawling > drm/i915/display: Embed the new struct steps for modeset > drm/i915/display: Dump the new cdclk config values > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 +++++++++++++++++----- > drivers/gpu/drm/i915/display/intel_cdclk.h | 16 ++++- > 2 files changed, 74 insertions(+), 19 deletions(-) > > -- > 2.25.1 >
On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > This is a prep series for the actual cdclk refactoring > that will be sent following this. Idea is to have a > struct - cdclk_step that holds the following: > - cdclk action (squash, crawl or modeset) > - cdclk frequency > which gets populated in atomic check. Driver > uses the populated values during atomic commit > to do the suitable sequence of actions like > programming squash ctl registers in case of squashing > or PLL sequence incase of modeset and so on. > > This series just addresses the initial idea. The actual plumming > in the atomic commit phase will be sent shortly. OK, people keep ignoring what I say so I just typed up the code quickly. This to me seems like the most straightforward way to do what we need: https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash Totally untested ofc, apart from me doing a quick scan through our cdclk tables for the crawl+squahs platforms to make sure that this approach should produce sane values. > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Uma Shankar <uma.shankar@intel.com> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Anusha Srivatsa (6): > drm/i915/display Add dg2_prog_squash_ctl() helper > drm/i915/display: add cdclk action struct to cdclk_config > drm/i915/display: Embed the new struct steps for squashing > drm/i915/display: Embed the new struct steps for crawling > drm/i915/display: Embed the new struct steps for modeset > drm/i915/display: Dump the new cdclk config values > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 +++++++++++++++++----- > drivers/gpu/drm/i915/display/intel_cdclk.h | 16 ++++- > 2 files changed, 74 insertions(+), 19 deletions(-) > > -- > 2.25.1
> -----Original Message----- > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > Sent: Tuesday, September 20, 2022 1:20 AM > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > This is a prep series for the actual cdclk refactoring that will be > > sent following this. Idea is to have a struct - cdclk_step that holds > > the following: > > - cdclk action (squash, crawl or modeset) > > - cdclk frequency > > which gets populated in atomic check. Driver uses the populated values > > during atomic commit to do the suitable sequence of actions like > > programming squash ctl registers in case of squashing or PLL sequence > > incase of modeset and so on. > > > > This series just addresses the initial idea. The actual plumming in > > the atomic commit phase will be sent shortly. > > OK, people keep ignoring what I say so I just typed up the code quickly. This > to me seems like the most straightforward way to do what we need: > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > Totally untested ofc, apart from me doing a quick scan through our cdclk > tables for the crawl+squahs platforms to make sure that this approach > should produce sane values. Ville, Why have a mid cdclk_config? Cant we use the new-cdclk-config for this purpose? Anusha > > > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Cc: Uma Shankar <uma.shankar@intel.com> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > Anusha Srivatsa (6): > > drm/i915/display Add dg2_prog_squash_ctl() helper > > drm/i915/display: add cdclk action struct to cdclk_config > > drm/i915/display: Embed the new struct steps for squashing > > drm/i915/display: Embed the new struct steps for crawling > > drm/i915/display: Embed the new struct steps for modeset > > drm/i915/display: Dump the new cdclk config values > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 > > +++++++++++++++++----- drivers/gpu/drm/i915/display/intel_cdclk.h | > > 16 ++++- > > 2 files changed, 74 insertions(+), 19 deletions(-) > > > > -- > > 2.25.1 > > -- > Ville Syrjälä > Intel
On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > -----Original Message----- > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Sent: Tuesday, September 20, 2022 1:20 AM > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > This is a prep series for the actual cdclk refactoring that will be > > > sent following this. Idea is to have a struct - cdclk_step that holds > > > the following: > > > - cdclk action (squash, crawl or modeset) > > > - cdclk frequency > > > which gets populated in atomic check. Driver uses the populated values > > > during atomic commit to do the suitable sequence of actions like > > > programming squash ctl registers in case of squashing or PLL sequence > > > incase of modeset and so on. > > > > > > This series just addresses the initial idea. The actual plumming in > > > the atomic commit phase will be sent shortly. > > > > OK, people keep ignoring what I say so I just typed up the code quickly. This > > to me seems like the most straightforward way to do what we need: > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > Totally untested ofc, apart from me doing a quick scan through our cdclk > > tables for the crawl+squahs platforms to make sure that this approach > > should produce sane values. > Ville, > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this purpose? You either - start at old, crawl to mid, then squash to new - start at old, squash to mid, then crawl to new
> -----Original Message----- > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > Sent: Tuesday, September 20, 2022 2:59 PM > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > > > > -----Original Message----- > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > This is a prep series for the actual cdclk refactoring that will > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > holds the following: > > > > - cdclk action (squash, crawl or modeset) > > > > - cdclk frequency > > > > which gets populated in atomic check. Driver uses the populated > > > > values during atomic commit to do the suitable sequence of actions > > > > like programming squash ctl registers in case of squashing or PLL > > > > sequence incase of modeset and so on. > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > in the atomic commit phase will be sent shortly. > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > quickly. This to me seems like the most straightforward way to do what > we need: > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > approach should produce sane values. > > Ville, > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > purpose? > > You either > - start at old, crawl to mid, then squash to new > - start at old, squash to mid, then crawl to new Tested the changes on TGL(legacy) and DG2(squash). Took some time to understand the code but the mid cdclk config logic works. @Ville Syrjälä does replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic check make sense? Anusha > -- > Ville Syrjälä > Intel
On Fri, Sep 23, 2022 at 04:56:53PM +0000, Srivatsa, Anusha wrote: > > > > -----Original Message----- > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Sent: Tuesday, September 20, 2022 2:59 PM > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > -----Original Message----- > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > This is a prep series for the actual cdclk refactoring that will > > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > > holds the following: > > > > > - cdclk action (squash, crawl or modeset) > > > > > - cdclk frequency > > > > > which gets populated in atomic check. Driver uses the populated > > > > > values during atomic commit to do the suitable sequence of actions > > > > > like programming squash ctl registers in case of squashing or PLL > > > > > sequence incase of modeset and so on. > > > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > > in the atomic commit phase will be sent shortly. > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > quickly. This to me seems like the most straightforward way to do what > > we need: > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > > approach should produce sane values. > > > Ville, > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > > purpose? > > > > You either > > - start at old, crawl to mid, then squash to new > > - start at old, squash to mid, then crawl to new > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to understand the code but the mid cdclk config logic works. @Ville Syrjälä does replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic check make sense? I don't think we should need any real logic at that point. If we can squash and crawl then I think we can always do the cdclk change w/o a modeset, at least with what we currently have defined in the cdclk tables.
> -----Original Message----- > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > Sent: Friday, September 23, 2022 12:04 PM > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>; Navare, > Manasi D <manasi.d.navare@intel.com>; Roper, Matthew D > <matthew.d.roper@intel.com> > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Fri, Sep 23, 2022 at 04:56:53PM +0000, Srivatsa, Anusha wrote: > > > > > > > -----Original Message----- > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Sent: Tuesday, September 20, 2022 2:59 PM > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > > This is a prep series for the actual cdclk refactoring that > > > > > > will be sent following this. Idea is to have a struct - > > > > > > cdclk_step that holds the following: > > > > > > - cdclk action (squash, crawl or modeset) > > > > > > - cdclk frequency > > > > > > which gets populated in atomic check. Driver uses the > > > > > > populated values during atomic commit to do the suitable > > > > > > sequence of actions like programming squash ctl registers in > > > > > > case of squashing or PLL sequence incase of modeset and so on. > > > > > > > > > > > > This series just addresses the initial idea. The actual > > > > > > plumming in the atomic commit phase will be sent shortly. > > > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > > quickly. This to me seems like the most straightforward way to > > > > > do what > > > we need: > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > > > Totally untested ofc, apart from me doing a quick scan through > > > > > our cdclk tables for the crawl+squahs platforms to make sure > > > > > that this approach should produce sane values. > > > > Ville, > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for > > > > this > > > purpose? > > > > > > You either > > > - start at old, crawl to mid, then squash to new > > > - start at old, squash to mid, then crawl to new > > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to > understand the code but the mid cdclk config logic works. @Ville Syrjälä does > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your > new cdclk_crawl_and_squash in atomic check make sense? > > I don't think we should need any real logic at that point. > If we can squash and crawl then I think we can always do the cdclk change > w/o a modeset, at least with what we currently have defined in the cdclk > tables. @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or should I send it on your behalf? Anusha > -- > Ville Syrjälä > Intel
On Mon, Sep 26, 2022 at 05:21:40PM +0000, Srivatsa, Anusha wrote: > > > > -----Original Message----- > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Sent: Friday, September 23, 2022 12:04 PM > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>; Navare, > > Manasi D <manasi.d.navare@intel.com>; Roper, Matthew D > > <matthew.d.roper@intel.com> > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Fri, Sep 23, 2022 at 04:56:53PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > -----Original Message----- > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Sent: Tuesday, September 20, 2022 2:59 PM > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > > > This is a prep series for the actual cdclk refactoring that > > > > > > > will be sent following this. Idea is to have a struct - > > > > > > > cdclk_step that holds the following: > > > > > > > - cdclk action (squash, crawl or modeset) > > > > > > > - cdclk frequency > > > > > > > which gets populated in atomic check. Driver uses the > > > > > > > populated values during atomic commit to do the suitable > > > > > > > sequence of actions like programming squash ctl registers in > > > > > > > case of squashing or PLL sequence incase of modeset and so on. > > > > > > > > > > > > > > This series just addresses the initial idea. The actual > > > > > > > plumming in the atomic commit phase will be sent shortly. > > > > > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > > > quickly. This to me seems like the most straightforward way to > > > > > > do what > > > > we need: > > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > > > > > Totally untested ofc, apart from me doing a quick scan through > > > > > > our cdclk tables for the crawl+squahs platforms to make sure > > > > > > that this approach should produce sane values. > > > > > Ville, > > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for > > > > > this > > > > purpose? > > > > > > > > You either > > > > - start at old, crawl to mid, then squash to new > > > > - start at old, squash to mid, then crawl to new > > > > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to > > understand the code but the mid cdclk config logic works. @Ville Syrjälä does > > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your > > new cdclk_crawl_and_squash in atomic check make sense? > > > > I don't think we should need any real logic at that point. > > If we can squash and crawl then I think we can always do the cdclk change > > w/o a modeset, at least with what we currently have defined in the cdclk > > tables. > > @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or should I send it on your behalf? You can take over again if you want.
> -----Original Message----- > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > Sent: Monday, September 26, 2022 10:30 AM > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>; Navare, > Manasi D <manasi.d.navare@intel.com>; Roper, Matthew D > <matthew.d.roper@intel.com> > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Mon, Sep 26, 2022 at 05:21:40PM +0000, Srivatsa, Anusha wrote: > > > > > > > -----Original Message----- > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Sent: Friday, September 23, 2022 12:04 PM > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>; > > > Navare, Manasi D <manasi.d.navare@intel.com>; Roper, Matthew D > > > <matthew.d.roper@intel.com> > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 23, 2022 at 04:56:53PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > Sent: Tuesday, September 20, 2022 2:59 PM > > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > <uma.shankar@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com> > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > On Tue, Sep 20, 2022 at 06:48:46PM +0000, Srivatsa, Anusha wrote: > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > > > > To: Srivatsa, Anusha <anusha.srivatsa@intel.com> > > > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > > > <uma.shankar@intel.com>; Vivi, Rodrigo > > > > > > > <rodrigo.vivi@intel.com> > > > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > > > > This is a prep series for the actual cdclk refactoring > > > > > > > > that will be sent following this. Idea is to have a struct > > > > > > > > - cdclk_step that holds the following: > > > > > > > > - cdclk action (squash, crawl or modeset) > > > > > > > > - cdclk frequency > > > > > > > > which gets populated in atomic check. Driver uses the > > > > > > > > populated values during atomic commit to do the suitable > > > > > > > > sequence of actions like programming squash ctl registers > > > > > > > > in case of squashing or PLL sequence incase of modeset and so > on. > > > > > > > > > > > > > > > > This series just addresses the initial idea. The actual > > > > > > > > plumming in the atomic commit phase will be sent shortly. > > > > > > > > > > > > > > OK, people keep ignoring what I say so I just typed up the > > > > > > > code quickly. This to me seems like the most straightforward > > > > > > > way to do what > > > > > we need: > > > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > > > > > > > Totally untested ofc, apart from me doing a quick scan > > > > > > > through our cdclk tables for the crawl+squahs platforms to > > > > > > > make sure that this approach should produce sane values. > > > > > > Ville, > > > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config > > > > > > for this > > > > > purpose? > > > > > > > > > > You either > > > > > - start at old, crawl to mid, then squash to new > > > > > - start at old, squash to mid, then crawl to new > > > > > > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time > > > > to > > > understand the code but the mid cdclk config logic works. @Ville > > > Syrjälä does replacing the intel_cdclk_can_squash() and > > > intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic > check make sense? > > > > > > I don't think we should need any real logic at that point. > > > If we can squash and crawl then I think we can always do the cdclk > > > change w/o a modeset, at least with what we currently have defined > > > in the cdclk tables. > > > > @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or > should I send it on your behalf? > > You can take over again if you want. Will do. Thanks Ville! Anusha > -- > Ville Syrjälä > Intel