From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Jean Delvare <jdelvare@suse.com>,
Andi Shyti <andi.shyti@kernel.org>,
linux-i2c@vger.kernel.org, Sanket.Goswami@amd.com,
Patil.Reddy@amd.com
Subject: Re: [PATCH v5 7/8] i2c: amd-asf: Clear remote IRR bit to get successive interrupt
Date: Wed, 18 Sep 2024 17:05:22 +0300 [thread overview]
Message-ID: <ZureIjs-7x6Hvl9g@smile.fi.intel.com> (raw)
In-Reply-To: <027f723f-a276-4e63-8578-167d74e14d12@amd.com>
On Wed, Sep 18, 2024 at 03:58:11PM +0530, Shyam Sundar S K wrote:
> On 9/18/2024 15:33, Andy Shevchenko wrote:
> > On Wed, Sep 18, 2024 at 12:01:19AM +0530, Shyam Sundar S K wrote:
> >> On 9/14/2024 00:49, Andy Shevchenko wrote:
> >>> On Fri, Sep 13, 2024 at 05:41:09PM +0530, Shyam Sundar S K wrote:
...
> >>>> + eoi_addr = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>>> + if (!eoi_addr)
> >>>> + return dev_err_probe(&pdev->dev, -EINVAL, "missing MEM resources\n");
> >>>> +
> >>>> + asf_dev->eoi_base = devm_ioremap(&pdev->dev, eoi_addr->start, resource_size(eoi_addr));
> >>>> + if (!asf_dev->eoi_base)
> >>>> + return dev_err_probe(&pdev->dev, -EBUSY, "failed mapping IO region\n");
> >>>
> >>> Home grown copy of devm_platform_ioremap_resource().
> >>
> >> devm_platform_ioremap_resource() internally calls
> >> devm_platform_get_and_ioremap_resource(), performing two main actions:
> >>
> >> It uses platform_get_resource().
> >> It then calls devm_ioremap_resource().
> >>
> >> However, there's an issue.
> >>
> >> devm_ioremap_resource() invokes devm_request_mem_region() followed by
> >> __devm_ioremap(). In this driver, the resource obtained via ASL might
> >> not actually belong to the ASF device address space. Instead, it could
> >> be within other IP blocks of the ASIC, which are crucial for
> >> generating subsequent interrupts (the main focus of this patch). As a
> >> result, devm_request_mem_region() fails, preventing __devm_ioremap()
> >> from being executed.
> >>
> >> TL;DR, it’s more appropriate to call platform_get_resource() and
> >> devm_ioremap() separately in this scenario.
> >
> > Okay, at bare minimum this must be commented in the code (like the above
> > summary).
>
> Okay, I will leave a comment.
>
> > Ideally it should be done differently as the resource regions
> > should not be shared (it's an exceptional case and usually shows bad design
> > of the driver). If you can't really split, regmap APIs help with that
> > (and they also may provide an adequate serialisation to IO).
>
> Unfortunately, this is the only way to get subsequent interrupts from
> the ASF IP block (based on the AMD ASF databook).
How is it related to the pure software concept of the assigning (exclusively)
the resources? Again, if you need to share, switch over to use regmap APIs.
See how I2C DesignWare driver does. It's also used as the part of complex
hardware where the register windows may not be clearly split between drivers.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-09-18 14:08 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 12:11 [PATCH v5 0/8] Introduce initial AMD ASF Controller driver support Shyam Sundar S K
2024-09-13 12:11 ` [PATCH v5 1/8] i2c: piix4: Change the parameter list of piix4_transaction function Shyam Sundar S K
2024-09-13 19:21 ` Andy Shevchenko
2024-09-13 12:11 ` [PATCH v5 2/8] i2c: piix4: Move i2c_piix4 macros and structures to common header Shyam Sundar S K
2024-09-13 18:44 ` Andy Shevchenko
2024-09-13 12:11 ` [PATCH v5 3/8] i2c: piix4: Export i2c_piix4 driver functions as library Shyam Sundar S K
2024-09-13 18:54 ` Andy Shevchenko
2024-09-17 18:14 ` Shyam Sundar S K
2024-09-18 9:56 ` Andy Shevchenko
2024-09-18 10:14 ` Shyam Sundar S K
2024-09-18 20:50 ` Andi Shyti
2024-09-13 12:11 ` [PATCH v5 4/8] i2c: amd-asf: Add ACPI support for AMD ASF Controller Shyam Sundar S K
2024-09-13 19:18 ` Andy Shevchenko
2024-09-13 22:45 ` kernel test robot
2024-09-19 19:44 ` kernel test robot
2024-09-13 12:11 ` [PATCH v5 5/8] i2c: amd-asf: Add i2c_algorithm operations to support AMD ASF with SMBus Shyam Sundar S K
2024-09-13 19:08 ` Andy Shevchenko
2024-09-17 18:17 ` Shyam Sundar S K
2024-09-18 9:58 ` Andy Shevchenko
2024-09-18 10:24 ` Shyam Sundar S K
2024-09-13 12:11 ` [PATCH v5 6/8] i2c: amd-asf: Add routine to handle the ASF slave process Shyam Sundar S K
2024-09-13 19:17 ` Andy Shevchenko
2024-09-17 18:21 ` Shyam Sundar S K
2024-09-18 10:00 ` Andy Shevchenko
2024-09-13 12:11 ` [PATCH v5 7/8] i2c: amd-asf: Clear remote IRR bit to get successive interrupt Shyam Sundar S K
2024-09-13 19:19 ` Andy Shevchenko
2024-09-17 18:31 ` Shyam Sundar S K
2024-09-18 10:03 ` Andy Shevchenko
2024-09-18 10:28 ` Shyam Sundar S K
2024-09-18 14:05 ` Andy Shevchenko [this message]
2024-09-13 12:11 ` [PATCH v5 8/8] MAINTAINERS: Add AMD ASF driver entry Shyam Sundar S K
2024-09-13 19:20 ` [PATCH v5 0/8] Introduce initial AMD ASF Controller driver support Andy Shevchenko
2024-09-17 18:11 ` Shyam Sundar S K
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=ZureIjs-7x6Hvl9g@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=Patil.Reddy@amd.com \
--cc=Sanket.Goswami@amd.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=andi.shyti@kernel.org \
--cc=jdelvare@suse.com \
--cc=linux-i2c@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;
as well as URLs for NNTP newsgroup(s).