All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Basavaraj Natikar <bnatikar@amd.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Shyam-sundar.S-k@amd.com, linux-gpio@vger.kernel.org,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v2 2/3] pinctrl: amd: Get and update IOMUX details
Date: Wed, 25 May 2022 19:45:22 +0300	[thread overview]
Message-ID: <Yo5dIqADnv/puBrb@smile.fi.intel.com> (raw)
In-Reply-To: <800030c9-8a74-9186-b329-8a3edff273ff@amd.com>

On Wed, May 25, 2022 at 03:12:05PM +0530, Basavaraj Natikar wrote:
> On 5/24/2022 10:09 PM, Andy Shevchenko wrote:
> > On Tue, May 24, 2022 at 07:20:34PM +0530, Basavaraj Natikar wrote:
> >> On 5/24/2022 6:04 PM, Mika Westerberg wrote:
> >>> On Tue, May 24, 2022 at 05:54:47PM +0530, Basavaraj Natikar wrote:
> >>>> There is no CRS method defined for IOMX/0xFED80D00 in ACPI namespace // IOMX Address Base 
> >>>> Hence I added additional code to get IOMX memory region.
> >>>>
> >>>> since _CRS method is used to get GPIO pin base for AMDI0030 in
> >>>> pinctrl-amd as below, same is not available for IOMX
> >>>>  
> >>>>   Device (GPIO)
> >>>>         {
> >>>>             Name (_HID, "AMDI0030")  // _HID: Hardware ID
> >>>>             Name (_CID, "AMDI0030")  // _CID: Compatible ID
> >>>>             Name (_UID, Zero)  // _UID: Unique ID
> >>>>             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
> >>>>             {
> >>>>                 Name (RBUF, ResourceTemplate ()
> >>>>                 {
> >>>>                     Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
> >>>>                     {
> >>>>                         0x00000007,
> >>>>                     }
> >>>>                     Memory32Fixed (ReadWrite,
> >>>>                         0xFED81500,         // Address Base
> >>>>                         0x00000400,         // Address Length
> >>>>                         )
> >>> Is there something preventing you to add it here like below?
> >>>
> >>>                      Memory32Fixed (ReadWrite, 0xFED80D00 0x00000400)
> >> yes few system has different entries already defined like below      
> >>   Device (GPIO)
> >>         {
> >>             Name (_HID, "AMDI0030")  // _HID: Hardware ID
> >>             Name (_CID, "AMDI0030")  // _CID: Compatible ID
> >>             Name (_UID, Zero)  // _UID: Unique ID
> >>             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
> >>             {
> >>                 Name (RBUF, ResourceTemplate ()
> >>                 {
> >>                     Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
> >>                     {
> >>                         0x00000007,
> >>                     }
> >>                     Memory32Fixed (ReadWrite,
> >>                         0xFED81500,         // Address Base
> >>                         0x00000400,         // Address Length
> >>                         )
> >>                 })
> >>                 Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
> >>             }
> >>
> >>
> >>         Device (GPIO)
> >>         {
> >>             Name (_HID, "AMDI0030")  // _HID: Hardware ID
> >>             Name (_CID, "AMDI0030")  // _CID: Compatible ID
> >>             Name (_UID, Zero)  // _UID: Unique ID
> >>             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
> >>             {
> >>                 Name (RBUF, ResourceTemplate ()
> >>                 {
> >>                     Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
> >>                     {
> >>                         0x00000007,
> >>                     }
> >>                     Memory32Fixed (ReadWrite,
> >>                         0xFED81500,         // Address Base
> >>                         0x00000400,         // Address Length
> >>                         )
> >>                     Memory32Fixed (ReadWrite,
> >>                         0xFED81200,         // Address Base
> >>                         0x00000100,         // Address Length
> >>                         )
> >>                 })
> >>                 Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
> >>             }
> >>
> >> if we add or in future some entries added. 
> >> is there way to map particular entry for IOMUX? 
> > Straightforward way is to add it always to the end and add _DSD boolean
> > property ("amd,pinctrl-iomux-present") and act accordingly. More flexible and
> > less error prone is to name all resources with DSD property and find resource
> > by name: "amd,pinctrl-resource-names" = "bank0", "bank1", "iomux".
> >
> Idea of adding _DSD property looks good, we can add easily _DSD
> "pinctrl-iomux-present" u8 property to return index or instance
> value directly. 

Better to name them all, it will be more consistent and robust.

> But systems already in use or old platforms needs BIOS update to avail 
> this feature and it may also impact existing windows OS functionality.

I don't believe it will anyhow alter Windows, except the new part not being
tested in Windows.

> one more flexible way is to directly use _DSD property to get memory
> region as below also works, 

Strongly no. We do not allow to repeat in _DSD the existing ACPI concepts.

...

> How about adding generic new function in drivers/acpi/utils.h to avoid
> using "../acpi/acpica/accommon.h" in pinctrl-amd.c like below.
> 
> acpi_status acpi_get_sys_mem_region(acpi_handle handle, 
>                            const char *nname, struct acpi_mem_space_context *res); 
> 
> can be used directly in acpi_get_iomux_region by calling like 
> acpi_get_sys_mem_region(handle, "IOMX", &res)
> This can be generically used to get details like below Operation regions 
> which is already present in dsdt table.
> OperationRegion (IOMX, SystemMemory, 0xFED80D00, 0x0100)

It seems you missed the point of OpRegions in ACPI. We have a standart way of
subscribing to the OpRegion:s, if somebody in ACPI touches it, you will handle
writes and reads in the driver.

Using OpRegion in replace of _CRS is a huge abuse of ACPI. Fix your firmware,
because it sounds like it must be fixed.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-05-25 16:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  7:40 [PATCH v2 0/3] Enhancements to AMD pinctrl and implementation of AMD pinmux Basavaraj Natikar
2022-05-24  7:40 ` [PATCH v2 1/3] pinctrl: amd: Define and use PINCTRL_GRP Basavaraj Natikar
2022-05-24  9:36   ` Linus Walleij
2022-05-24 14:34   ` Andy Shevchenko
2022-05-24 14:38   ` Andy Shevchenko
2022-05-25  6:05     ` Linus Walleij
2022-05-26  6:27       ` Basavaraj Natikar
2022-05-24  7:40 ` [PATCH v2 2/3] pinctrl: amd: Get and update IOMUX details Basavaraj Natikar
2022-05-24  9:38   ` Linus Walleij
2022-05-24 11:18     ` Basavaraj Natikar
2022-05-24 11:37       ` Mika Westerberg
2022-05-24 11:52         ` Basavaraj Natikar
2022-05-24 12:07           ` Mika Westerberg
2022-05-24 12:24             ` Basavaraj Natikar
2022-05-24 12:34               ` Mika Westerberg
2022-05-24 13:50                 ` Basavaraj Natikar
2022-05-24 16:39                   ` Andy Shevchenko
2022-05-25  9:42                     ` Basavaraj Natikar
2022-05-25 16:45                       ` Andy Shevchenko [this message]
2022-05-26  6:30                         ` Basavaraj Natikar
2022-05-24 13:06   ` Andy Shevchenko
2022-05-24  7:40 ` [PATCH v2 3/3] pinctrl: amd: Implement pinmux functionality Basavaraj Natikar
2022-05-24  9:41   ` Linus Walleij

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=Yo5dIqADnv/puBrb@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=bnatikar@amd.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.