X86 platform drivers
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	markgross@kernel.org, Sanket.Goswami@amd.com,
	mario.limonciello@amd.com, platform-driver-x86@vger.kernel.org,
	Mark Hasemeyer <markhas@chromium.org>
Subject: Re: [PATCH v4] platform/x86/amd/pmc: adjust getting DRAM size behavior
Date: Mon, 20 Nov 2023 10:03:13 +0200 (EET)	[thread overview]
Message-ID: <d5b83819-8384-1acf-cd1c-1a52ba982939@linux.intel.com> (raw)
In-Reply-To: <1405ce97-f1c4-4c56-abff-385554f9efe9@amd.com>

[-- Attachment #1: Type: text/plain, Size: 3004 bytes --]

On Mon, 20 Nov 2023, Shyam Sundar S K wrote:
> On 11/17/2023 3:41 PM, Ilpo Järvinen wrote:
> > On Thu, 16 Nov 2023, Shyam Sundar S K wrote:
> > 
> >> amd_pmc_get_dram_size() is used to get the DRAM size information. But in
> >> the current code, mailbox command to get the DRAM size info is sent based
> >> on the values of dev->major and dev->minor.
> >>
> >> But dev->major and dev->minor will have either junk or zero assigned to
> >> them until at least once a call to amd_pmc_get_smu_version() is made which
> >> ideally populates dev->major and dev->minor.
> >>
> >> Ideally to suffice this, adding a amd_pmc_get_smu_version() call to
> >> amd_pmc_get_dram_size() would solve, but that has a downside of elevating
> >> the boot times.
> >>
> >> After talking to the PMFW team, its understood that the "get dram size"
> >> mbox command would only be supported on specific platforms (like Mendocino)
> >> and not all. So, adjust getting DRAM size behavior such that,
> >>
> >> - if that's Rembrandt or Mendocino and the underlying PMFW knows how
> >> to execute the "get dram size" command it shall give the custom dram size.
> >>
> >> - if the underlying FW does not report the dram size, we just proceed
> >> further and assign the default dram size.
> >>
> >> Simplest way to address this is to remove amd_pmc_get_dram_size() function
> >> and directly call the "get dram size" command in the amd_pmc_s2d_init().
> >>
> >> Reported-by: Mark Hasemeyer <markhas@chromium.org>
> >> Closes: https://lore.kernel.org/platform-driver-x86/3b224c62-a1d8-41bd-aced-5825f5f20e66@amd.com/
> >> Fixes: be8325fb3d8c ("platform/x86/amd: pmc: Get STB DRAM size from PMFW")
> >> Suggested-by: Sanket Goswami <Sanket.Goswami@amd.com>
> >> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> >> ---
> >> v4:
> >> - Based on review-ilpo branch (tip commit: 94ace9eda882)
> >> - Add Mark as "Reported-by:"
> >> - Add more commit log notes.
> > 
> > Thank, applied now to review-ilpo branch. I had to reflow your commit 
> > message because the lines were too long (try to remain within 72 
> > characters in the future). I also made other minor adjustments to the 
> > commit message.
> 
> Thank you for the rewords :-)
> 
> on the commit message part, you prefer 72 or 75 characters?
> Because I did use, checkpatch with "--strict" and did not find it
> complaining.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?h=v6.7-rc2#n3275

I'd have said 72 characters but since you now pointed out checkpatch seems 
to have only a slightly higher limit we can go along with that 75 
characters. I think that 72 char limit is derived from 80-2*4 (4 char wide 
margins on both sides on 80 char wide terminal). Be aware though some 
other maintainers do require 72 chars.

And obviously for URLs (or other stuff) that should be kept on a single 
line, you have the license to break that limit even if checkpatch would 
complain but I guess you knew that :-).

-- 
 i.

      reply	other threads:[~2023-11-20  8:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 17:01 [PATCH v4] platform/x86/amd/pmc: adjust getting DRAM size behavior Shyam Sundar S K
2023-11-16 17:05 ` Mario Limonciello
2023-11-16 17:15   ` Ilpo Järvinen
2023-11-17 10:11 ` Ilpo Järvinen
2023-11-20  6:52   ` Shyam Sundar S K
2023-11-20  8:03     ` Ilpo Järvinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5b83819-8384-1acf-cd1c-1a52ba982939@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=Sanket.Goswami@amd.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=hdegoede@redhat.com \
    --cc=mario.limonciello@amd.com \
    --cc=markgross@kernel.org \
    --cc=markhas@chromium.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox