From: Martyn Welch <martyn.welch@ge.com>
To: Joe Perches <joe@perches.com>
Cc: Manohar Vanga <manohar.vanga@cern.ch>,
gregkh@suse.de, cota@braap.org, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] staging: vme: make [alloc|free]_consistent bridge specific
Date: Wed, 10 Aug 2011 14:55:15 +0100 [thread overview]
Message-ID: <4E428DC3.5070302@ge.com> (raw)
In-Reply-To: <1312984261.11924.91.camel@Joe-Laptop>
On 10/08/11 14:51, Joe Perches wrote:
> On Wed, 2011-08-10 at 14:34 +0100, Martyn Welch wrote:
>> On 10/08/11 14:12, Joe Perches wrote:
>>> On Wed, 2011-08-10 at 11:33 +0200, Manohar Vanga wrote:
>>>> Make PCI dependent functions ([alloc|free]_consistent() in
>>>> 'vme.c') bridge specific. By removing the dependency of the
>>>> VME bridge framework on PCI, this patch allows for addition of
>>>> non-PCI based VME bridges.
>>> []
>>>> diff --git a/drivers/staging/vme/bridges/vme_ca91cx42.c b/drivers/staging/vme/bridges/vme_ca91cx42.c
>>> []
>>>> +void *ca91cx42_alloc_consistent(struct device *parent, size_t size,
>>>> + dma_addr_t *dma)
>>>> +{
>>>> + struct pci_dev *pdev;
>>>> +
>>>> + /* Find pci_dev container of dev */
>>>> + pdev = container_of(parent, struct pci_dev, dev);
>>>> +
>>>> + return pci_alloc_consistent(pdev, size, dma);
>>>> +}
>>>> +
>>>> +void ca91cx42_free_consistent(struct device *parent, size_t size, void *vaddr,
>>>> + dma_addr_t dma)
>>>> +{
>>>> + struct pci_dev *pdev;
>>>> +
>>>> + /* Find pci_dev container of dev */
>>>> + pdev = container_of(parent, struct pci_dev, dev);
>>>> +
>>>> + pci_free_consistent(pdev, size, vaddr, dma);
>>>> +}
>>> []
>>>> diff --git a/drivers/staging/vme/bridges/vme_tsi148.c b/drivers/staging/vme/bridges/vme_tsi148.c
>>> []
>>>> @@ -2122,6 +2122,28 @@ static int tsi148_slot_get(struct vme_bridge *tsi148_bridge)
>>>> return (int)slot;
>>>> }
>>>>
>>>> +void *tsi148_alloc_consistent(struct device *parent, size_t size,
>>>> + dma_addr_t *dma)
>>>> +{
>>>> + struct pci_dev *pdev;
>>>> +
>>>> + /* Find pci_dev container of dev */
>>>> + pdev = container_of(parent, struct pci_dev, dev);
>>>> +
>>>> + return pci_alloc_consistent(pdev, size, dma);
>>>> +}
>>>> +
>>>> +void tsi148_free_consistent(struct device *parent, size_t size, void *vaddr,
>>>> + dma_addr_t dma)
>>>> +{
>>>> + struct pci_dev *pdev;
>>>> +
>>>> + /* Find pci_dev container of dev */
>>>> + pdev = container_of(parent, struct pci_dev, dev);
>>>> +
>>>> + pci_free_consistent(pdev, size, vaddr, dma);
>>>> +}
>>>> +
>>>> static int __init tsi148_init(void)
>>>> {
>>>> return pci_register_driver(&tsi148_driver);
>>>
>>> Except for the name, those 2 blocks are identical.
>>> Maybe create a non-pci generic version instead?
>>>
>>
>> I'm not sure you can (I spent quite a bit of time attempting to do just that
>> when I wrote the original). It just so happens that both of the bridges we
>> have at the moment are PCI devices,
>
> Doesn't something like this work?
>
> void *generic_vme_pci_alloc_consistent(struct device *parent, size_t size,
> dma_addr_t *dma)
> [implementation...]
> EXPORT_SYMBOL(generic_vme_pci_alloc_consistent);
> (if necessary)
>
> void *generic_vme_pci_free_consistent(struct device *parent, size_t size,
> void *vaddr, dma_addr_t dma)
> [implementation...]
> EXPORT_SYMBOL(generic_vme_pci_free_consistent);
>
> and uses like:
>
> + ca91cx42_bridge->alloc_consistent = generic_vme_pci_alloc_consistent;
> + ca91cx42_bridge->free_consistent = generic_vme_pci_free_consistent;
>
> ?
>
Could. Though we'd have to put this in a new common file for use by
vme_tsi148.c and vme_ca91cx42.c as the point of this was to get it out of the
VME core code. I'm just not sure that it's worth it.
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
next prev parent reply other threads:[~2011-08-10 13:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:33 [PATCH 0/6] [RESEND] VME framework fixes Manohar Vanga
2011-08-10 9:33 ` [PATCH 1/6] staging: vme: allow explicit assignment of bus numbers Manohar Vanga
2011-08-10 10:02 ` Martyn Welch
2011-08-10 10:41 ` Manohar Vanga
2011-08-10 12:50 ` Martyn Welch
2011-08-23 22:06 ` Greg KH
2011-08-10 9:33 ` [PATCH 2/6] staging: vme: make [alloc|free]_consistent bridge specific Manohar Vanga
2011-08-10 10:04 ` Martyn Welch
2011-08-10 13:24 ` Dan Carpenter
2011-08-10 13:12 ` Joe Perches
2011-08-10 13:34 ` Martyn Welch
2011-08-10 13:51 ` Joe Perches
2011-08-10 13:55 ` Martyn Welch [this message]
2011-08-10 14:30 ` Joe Perches
2011-08-10 14:33 ` Martyn Welch
2011-08-10 9:33 ` [PATCH 3/6] staging: vme: keep track of registered buses Manohar Vanga
2011-08-10 10:06 ` Martyn Welch
2011-08-10 9:33 ` [PATCH 4/6] staging: vme: add functions for bridge module refcounting Manohar Vanga
2011-08-10 10:09 ` Martyn Welch
2011-08-10 19:14 ` Emilio G. Cota
2011-08-10 9:33 ` [PATCH 5/6] staging: vme: add struct vme_dev for VME devices Manohar Vanga
2011-08-10 10:14 ` Martyn Welch
2011-08-10 10:33 ` Manohar Vanga
2011-08-10 9:33 ` [PATCH 6/6] staging: vme: make match() driver specific to improve non-VME64x support Manohar Vanga
2011-08-10 10:18 ` Martyn Welch
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=4E428DC3.5070302@ge.com \
--to=martyn.welch@ge.com \
--cc=cota@braap.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manohar.vanga@cern.ch \
/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.