Re: [PATCH] mmc: sdhci-pci: Only do AMD tuning for HS200
On 4/7/2018 3:37 AM, Daniel Kurtz wrote:
> Commit c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode
> on AMD, eMMC-4.5.1") added a HS200 tuning method for use with AMD SDHCI
> controllers. As described in the commit subject, this tuning is specific
> for HS200. However, as implemented, this method is used for all host
> timings, because platform_execute_tuning, if it exists, is called
> unconditionally by sdhci_execute_tuning(). This breaks tuning when using
> the AMD controller with, for example, a DDR50 SD card.
>
> Instead, we can implement an amd execute_tuning wrapper callback, and
> then conditionally do the HS200 specific tuning for HS200, and otherwise
> call back to the standard sdhci_execute_tuning().
>
> Signed-off-by: Daniel Kurtz
Looks good.
Acked-by: Shyam Sundar S K
Re: [PATCH] pinctrl: amd: avoid maybe-uninitalized warning
Hi Linus,
You have already added patch for the same "[PATCH] pinctrl: amd: fix
compilation warning" and applied to one of your fixed branch.
Do you feel this patch needs to be taken ?
Thanks,
Shyam
On 1/12/2017 1:19 PM, Linus Walleij wrote:
> On Wed, Jan 11, 2017 at 3:36 PM, Arnd Bergmann wrote:
>
>> Since gpio_dev->hwbank_num is now a variable, the compiler cannot
>> figure out if pin_num is initialized at all:
>>
>> drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show':
>> drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>for (; i < pin_num; i++) {
>>^~~
>> drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized
>> in this function [-Wmaybe-uninitialized]
>>
>> This adds a 'default' statement to make that case well-defined.
>>
>> Fixes: 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO")
>> Signed-off-by: Arnd Bergmann
>
> Patch applied.
>
> Yours,
> Linus Walleij
>
Re: amd-pmc s2idle driver issues
On 12/22/2020 10:14 PM, Deucher, Alexander wrote: > [AMD Public Use] > >> -Original Message- >> From: Alexander Monakov >> Sent: Tuesday, December 22, 2020 10:57 AM >> To: Deucher, Alexander >> Cc: platform-driver-...@vger.kernel.org; S-k, Shyam-sundar > sundar@amd.com>; Hans de Goede ; linux- >> ker...@vger.kernel.org >> Subject: RE: amd-pmc s2idle driver issues >> >> On Tue, 22 Dec 2020, Deucher, Alexander wrote: >> Yes. Out-of-the-box it's a "modern standby" laptop. There's a "hidden" bios menu with extra settings that apparently allows to select legacy S3. I did not change it, so I'm testing the "modern" mode. Note that this driver fetches SMU version from MMIO, which looks odd to me: elsewhere (i.e. in the amdgpu driver) SMU version is retrieved by issuing the corresponding SMU command, as far as I can tell. >>> >>> There are multiple interfaces to the SMU. It's shared by the entire >>> SoC on APUs. >> >> Just pointing that out because evidently this interface does not work on this >> laptop, producing all-ones instead of something resembling a version >> number. >> >> Which APU generations does this driver support? If it does not support >> Renoir >> (yet?) it should be documented in the Kconfig text. Is Renoir support related >> to missing AMD0005 ACPI id binding, and borked version number info? > > The current code supports both Raven/Picasso and Renoir parts. At least some > Renoir parts are supported as that is what we are mainly testing now. I'm > not sure why some boards have AMDI0005 vs AMD0005. We'll have to check with > the sbios or windows teams. > I think newer sbios'es have the AMDI0005 for Renior also. So, I am guessing you might be running an older BIOS. This driver is supposed to work for all generations of RYZEN starting from Picasso (provided you the right bios which supports modern standby). You can keep an eye if some of the devices are not entering the lowest device state if your kernel is built with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=146f1ed852a87b802ed6e71c31e189c64871383c Also, on my reference platform I see the debugfs giving some valid information. Since you have a sbios with AMD0005, I cannot comment much on it. Thanks, Shyam
Re: [PATCH] ACPI: PM: s2idle: More x86-specific code to the x86 directory
On 12/18/2020 12:53 AM, Rafael J. Wysocki wrote: > [CAUTION: External Email] > > From: Rafael J. Wysocki > > Some code in drivers/acpi/sleep.c (which is regarded as a generic > file) related to suspend-to-idle support has grown direct dependencies > on x86, but in fact it has been specific to x86 (which is the only > user of it) anyway for a long time. > > For this reason, move that code to a separate file under acpi/x86/ > and make it build and run as before under the right conditions. > > While at it, rename a vendor checking function in that code and > consistently use acpi_handle_debug() for printing debug-related > information in it. > > No expected functional impact. > > Signed-off-by: Rafael J. Wysocki Thank you Rafael.. This really helps!
Re: [PATCH] pinctrl: amd: Honor IRQ trigger type requested by the caller
On 6/27/2020 2:40 AM, Furquan Shaikh wrote: [CAUTION: External Email] This change drops the override in `amd_gpio_irq_set_type()` that ignores the IRQ trigger type settings from the caller. The device driver (caller) is in a better position to identify the right trigger type for the device based on the usage as well as the information exposed by the BIOS. There are instances where the device driver might want to configure the trigger type differently in different modes. An example of this is gpio-keys driver which configures IRQ type as trigger on both edges (to identify assert and deassert events) when in S0 and reconfigures the trigger type using the information provided by the BIOS when going into suspend to ensure that the wake happens on the required edge. This override in `amd_gpio_irq_set_type()` prevents the caller from being able to reconfigure trigger type once it is set either based on ACPI information or the type used by the first caller for IRQ on a given GPIO line. Without this change, pen-insert gpio key (used by garaged stylus on a Chromebook) works fine in S0 (i.e. insert and eject events are correctly identified), however, BIOS configuration for wake on only pen eject i.e. only-rising edge or only-falling edge is not honored. With this change, it was verified that pen-insert gpio key behavior is correct in both S0 and for wakeup from S3. Signed-off-by: Furquan Shaikh Signed-off-by: Shyam Sundar S K
