From: Kumar Gala <galak@kernel.crashing.org>
To: Greg KH <greg@kroah.com>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH] PCI: Add pci_assign_resource_fixed -- allow fixed address assignments
Date: Mon, 20 Mar 2006 10:09:13 -0600 [thread overview]
Message-ID: <10176D2A-5142-45CF-B519-CC324EFB5404@kernel.crashing.org> (raw)
In-Reply-To: <85D0E388-6E9A-4DCF-BA33-72B982782FAD@kernel.crashing.org>
Greg,
Any comments on this?
- kumar
On Mar 10, 2006, at 3:30 PM, Kumar Gala wrote:
>
> On Mar 10, 2006, at 3:04 PM, Randy.Dunlap wrote:
>
>> On Fri, 10 Mar 2006 09:06:32 -0600 (CST) Kumar Gala wrote:
>>
>>> On some embedded systems the PCI address for hotplug devices are
>>> not only
>>> known a priori but are required to be at a given PCI address for
>>> other
>>> master in the system to be able to access.
>>>
>>> An example of such a system would be an FPGA which is setup from
>>> user space
>>> after the system has booted. The FPGA may be access by DSPs in
>>> the system
>>> and those DSPs expect the FPGA at a fixed PCI address.
>>>
>>> Added pci_assign_resource_fixed() as a way to allow assignment of
>>> the PCI
>>> devices's BARs at fixed PCI addresses.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>
>>> ---
>>> commit 45d4a23317c459865ec740c80b6e2a2ad9f53fd3
>>> tree 432b5e41ef5f231dd57eb1a98f103239c62d63a0
>>> parent 8176dee014ec6ad1039b8c0075c9c1d02147c2c8
>>> author Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006
>>> 12:34:25 -0600
>>> committer Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006
>>> 12:34:25 -0600
>>>
>>> drivers/pci/pci.c | 1 +
>>> drivers/pci/setup-res.c | 35 +++++++++++++++++++++++++++++++++++
>>> include/linux/pci.h | 1 +
>>> 3 files changed, 37 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index d2d1879..2557e86 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -935,6 +935,7 @@ EXPORT_SYMBOL_GPL(pci_intx);
>>> EXPORT_SYMBOL(pci_set_dma_mask);
>>> EXPORT_SYMBOL(pci_set_consistent_dma_mask);
>>> EXPORT_SYMBOL(pci_assign_resource);
>>> +EXPORT_SYMBOL(pci_assign_resource_fixed);
>>> EXPORT_SYMBOL(pci_find_parent_resource);
>>>
>>> EXPORT_SYMBOL(pci_set_power_state);
>>> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
>>> index ea9277b..f485958 100644
>>> --- a/drivers/pci/setup-res.c
>>> +++ b/drivers/pci/setup-res.c
>>> @@ -155,6 +155,41 @@ int pci_assign_resource(struct pci_dev *
>>> return ret;
>>> }
>>>
>>> +int pci_assign_resource_fixed(struct pci_dev *dev, int resno)
>>> +{
>>> + struct pci_bus *bus = dev->bus;
>>> + struct resource *res = dev->resource + resno;
>>> + unsigned int type_mask;
>>> + int i, ret = -EBUSY;
>>> +
>>> + type_mask = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
>>
>> If type_mask must match (as in comment below), should it be a
>> parameter instead of hard-coded here? Does this match your FPGA
>> resource? It may not match my <hypothetical> resource.
>
> I was trying to ensure an exact match between the bus and device
> resource types. I figured if you were calling this API you should
> be able to ensure that the resource types match exactly.
>
>>> + for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
>>> + struct resource *r = bus->resource[i];
>>> + if (!r)
>>> + continue;
>>> +
>>> + /* type_mask must match */
>>> + if ((res->flags ^ r->flags) & type_mask)
>>> + continue;
>>> +
>>> + ret = request_resource(r, res);
>>> +
>>> + if (ret == 0)
>>> + break;
>>> + }
>>> +
>>> + if (ret) {
>>> + printk(KERN_ERR "PCI: Failed to allocate %s resource #%d:%lx@%
>>> lx for %s\n",
>>> + res->flags & IORESOURCE_IO ? "I/O" : "mem",
>>> + resno, res->end - res->start + 1, res->start, pci_name
>>> (dev));
>>> + } else if (resno < PCI_BRIDGE_RESOURCES) {
>>> + pci_update_resource(dev, res, resno);
>>> + }
>>
>> braces not needed.
>
> Fair, need to go find where I stole this from and possibly fix
> extra braces there as well.
>
>>
>>> +
>>> + return ret;
>>> +}
>>> +
>>
>>
>> ---
>> ~Randy
>> Please use an email client that implements proper (compliant)
>> threading.
>> (You know who you are.)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-
> kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2006-03-20 16:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-10 15:06 Kumar Gala
2006-03-10 21:04 ` Randy.Dunlap
2006-03-10 21:30 ` Kumar Gala
2006-03-20 16:09 ` Kumar Gala [this message]
2006-03-28 16:26 ` Kumar Gala
2006-04-27 17:43 Kumar Gala
2006-04-27 22:34 ` Andrew Morton
2006-04-28 0:12 ` Kumar Gala
2006-04-28 0:17 ` Greg KH
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=10176D2A-5142-45CF-B519-CC324EFB5404@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=rdunlap@xenotime.net \
/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
all inboxes | Powered by JetHome®