| Message ID | 20190213150810.32750-1-rajneesh.bhardwaj@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ICL support and other enhancements for PMC Core | expand |
On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> wrote: > > This patch series provides Icelake support for PMC Core driver and while > doing so it introduces the Icelake Mobile to intel-family.h as per the > CPUID from below Coreboot link > https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h > and provides some fixes and enhancements to the driver. It's not applicable to my tree. > Changes in v2: > * Addressed review comments from Thomas > * Added tags revieved > * Folded in SHA1 suggestions from Stephen Rothwell, though Andy might want to > fix it via rebasing > * Rebased and tested with Linux v5.0.0-rc6 > > This series: > - Adds ICL U/Y CPUID to intel-family.h > - Enables PMC driver for ICL > - Introduces a new "package cstate show" feature > - Fixes a customer issue related to S0ix on latest HP laptops > - Fixes some minor bugs > > Rajneesh Bhardwaj (10): > platform/x86: intel_pmc_core: Handle CFL regmap properly > platform/x86: intel_pmc_core: Fix PCH IP sts reading > platform/x86: intel_pmc_core: Fix PCH IP name > platform/x86: intel_pmc_core: Fix file permissions for ltr_show > platform/x86: intel_pmc_core: Include Reserved IP for LTR > x86/cpu: Add Icelake to Intel family > platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro > platform/x86: intel_pmc_core: Add ICL platform support > platform/x86: intel_pmc_core: Add Package cstates residency info > platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown > > arch/x86/include/asm/intel-family.h | 2 + > drivers/platform/x86/intel_pmc_core.c | 155 +++++++++++++++++++++----- > drivers/platform/x86/intel_pmc_core.h | 14 ++- > 3 files changed, 145 insertions(+), 26 deletions(-) > > -- > 2.17.1 >
On 13-Feb-19 9:03 PM, Andy Shevchenko wrote: > On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj > <rajneesh.bhardwaj@linux.intel.com> wrote: >> This patch series provides Icelake support for PMC Core driver and while >> doing so it introduces the Icelake Mobile to intel-family.h as per the >> CPUID from below Coreboot link >> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h >> and provides some fixes and enhancements to the driver. > It's not applicable to my tree. Hi Andy, I could apply and test in on latest upstream so i think its probably because you have applied 5 patches from v1 on your tree. https://github.com/dvhart/linux-pdx86/commits/for-next I sent the whole series again since https://patchwork.kernel.org/patch/10791893 referred to a wrong commit for Fixes:. If you want to address that by rebasing then can you please just consider patches 6-10. Please let me know if there is any other issue? >> Changes in v2: >> * Addressed review comments from Thomas >> * Added tags revieved >> * Folded in SHA1 suggestions from Stephen Rothwell, though Andy might want to >> fix it via rebasing >> * Rebased and tested with Linux v5.0.0-rc6 >> >> This series: >> - Adds ICL U/Y CPUID to intel-family.h >> - Enables PMC driver for ICL >> - Introduces a new "package cstate show" feature >> - Fixes a customer issue related to S0ix on latest HP laptops >> - Fixes some minor bugs >> >> Rajneesh Bhardwaj (10): >> platform/x86: intel_pmc_core: Handle CFL regmap properly >> platform/x86: intel_pmc_core: Fix PCH IP sts reading >> platform/x86: intel_pmc_core: Fix PCH IP name >> platform/x86: intel_pmc_core: Fix file permissions for ltr_show >> platform/x86: intel_pmc_core: Include Reserved IP for LTR >> x86/cpu: Add Icelake to Intel family >> platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro >> platform/x86: intel_pmc_core: Add ICL platform support >> platform/x86: intel_pmc_core: Add Package cstates residency info >> platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown >> >> arch/x86/include/asm/intel-family.h | 2 + >> drivers/platform/x86/intel_pmc_core.c | 155 +++++++++++++++++++++----- >> drivers/platform/x86/intel_pmc_core.h | 14 ++- >> 3 files changed, 145 insertions(+), 26 deletions(-) >> >> -- >> 2.17.1 >> >
On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh <rajneesh.bhardwaj@linux.intel.com> wrote: > On 13-Feb-19 9:03 PM, Andy Shevchenko wrote: > > On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj > > <rajneesh.bhardwaj@linux.intel.com> wrote: > >> This patch series provides Icelake support for PMC Core driver and while > >> doing so it introduces the Icelake Mobile to intel-family.h as per the > >> CPUID from below Coreboot link > >> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h > >> and provides some fixes and enhancements to the driver. > > It's not applicable to my tree. > > Hi Andy, I could apply and test in on latest upstream so i think its > probably because you have applied 5 patches from v1 on your tree. > https://github.com/dvhart/linux-pdx86/commits/for-next You need to use latest tip of the subsystem tree always. > I sent the whole series again since > https://patchwork.kernel.org/patch/10791893 referred to a wrong commit > for Fixes:. If you want to address that by rebasing then can you please > just consider patches 6-10. We don't do rebasing for published changes. Only in rear cases when otherwise would be worse. Darren didn't respond to my question what he thinks about this case, but at least it's not related to the code itself which, in my opinion, decreases a severity. > Please let me know if there is any other issue?
On 13-Feb-19 10:58 PM, Andy Shevchenko wrote: > On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh > <rajneesh.bhardwaj@linux.intel.com> wrote: >> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote: >>> On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj >>> <rajneesh.bhardwaj@linux.intel.com> wrote: >>>> This patch series provides Icelake support for PMC Core driver and while >>>> doing so it introduces the Icelake Mobile to intel-family.h as per the >>>> CPUID from below Coreboot link >>>> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h >>>> and provides some fixes and enhancements to the driver. >>> It's not applicable to my tree. >> Hi Andy, I could apply and test in on latest upstream so i think its >> probably because you have applied 5 patches from v1 on your tree. >> https://github.com/dvhart/linux-pdx86/commits/for-next > You need to use latest tip of the subsystem tree always. Ok. > >> I sent the whole series again since >> https://patchwork.kernel.org/patch/10791893 referred to a wrong commit >> for Fixes:. If you want to address that by rebasing then can you please >> just consider patches 6-10. > We don't do rebasing for published changes. Only in rear cases when > otherwise would be worse. > Darren didn't respond to my question what he thinks about this case, > but at least it's not related to the code itself which, in my opinion, > decreases a severity. Thanks Andy. So if i understand correctly, you are suggesting that i should ignore those patches that made to "for-next" branch already? So should i just send a v3 comprising of remaining 5 patches and of course, addressing recent review comments? >> Please let me know if there is any other issue? >
On Wed, Feb 13, 2019 at 8:02 PM Bhardwaj, Rajneesh <rajneesh.bhardwaj@linux.intel.com> wrote: > On 13-Feb-19 10:58 PM, Andy Shevchenko wrote: > > On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh > > <rajneesh.bhardwaj@linux.intel.com> wrote: > >> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote: > > We don't do rebasing for published changes. Only in rear cases when > > otherwise would be worse. > > Darren didn't respond to my question what he thinks about this case, > > but at least it's not related to the code itself which, in my opinion, > > decreases a severity. > > Thanks Andy. So if i understand correctly, you are suggesting that i > should ignore those patches that made to "for-next" branch already? I suggest you to rebase your local branch against latest subsystem tip branch, resolve conflicts if any, test, and only after that send a new version. > So should i just send a v3 comprising of remaining 5 patches and of > course, addressing recent review comments? I dunno how many patches you will get after rebasing. It might be 5, might be more, might be less. You decide what will be in next version. Just carefully describe the changes in the log.
On Wed, Feb 13, 2019 at 8:13 PM Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Feb 13, 2019 at 8:02 PM Bhardwaj, Rajneesh > <rajneesh.bhardwaj@linux.intel.com> wrote: > > On 13-Feb-19 10:58 PM, Andy Shevchenko wrote: > > > On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh > > > <rajneesh.bhardwaj@linux.intel.com> wrote: > > >> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote: > > > > We don't do rebasing for published changes. Only in rear cases when > > > otherwise would be worse. > > > Darren didn't respond to my question what he thinks about this case, > > > but at least it's not related to the code itself which, in my opinion, > > > decreases a severity. > > > > Thanks Andy. So if i understand correctly, you are suggesting that i > > should ignore those patches that made to "for-next" branch already? > > I suggest you to rebase your local branch against latest subsystem tip > branch, resolve conflicts if any, test, and only after that send a new > version. To clarify: "subsystem tip branch" in our case means for-next. The above is a generic process which would work with Linux kernel development.