From: Martyn Welch <martyn.welch@gefanuc.com>
To: "Emilio G. Cota" <cota@braap.org>
Cc: Greg K-H <gregkh@suse.de>,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
Sebastien Dugue <sebastien.dugue@bull.net>
Subject: Re: [patch 2/5] Staging: vme: add VME userspace driver
Date: Tue, 11 Aug 2009 13:46:53 +0100 [thread overview]
Message-ID: <4A81683D.2030408@gefanuc.com> (raw)
In-Reply-To: <20090811094025.GC3251@braap.org>
Emilio G. Cota wrote:
> Martyn Welch wrote:
>
>> suggest if you want something more complex that allows the user to just
>> pick a location/size and not worry about windows at all
>>
>
> That's exactly the whole point. I think each bridge should manage
> its resources; putting this on the upper layer would mean the
> layer should have a mechanism of 'discovering' what the bridge
> can/can't do. Anyway this could be revisited later.
> I'm preparing a patch for this.
>
I disagree. The bridge drivers should register their resources with the
core. The core, or a layer above it, can control how those resources are
used. This moves the complexity you want for managing the windows to a
level that will work on all underlying drivers rather than having to be
written explicitly for each one. The mechanism I have provided does this
discovery.
>
>>> - Most accesses are 32-bit accesses. Treating all of them
>>> as 64-bit accesses would decrease performance for most of
>>> them--which happen to be 32-bit.
>>>
>> I'm not - I'm storing them as 64-bit values, which they are, in the
>> structures used in *software*. These are then split *when* a write to
>> the hardware registers is required. Similarly, when the registers are
>> occasionally read they are combined and stored as a 64-bit value. This
>> simplifies all *software* checking and manipulation. By storing these as
>> 2 32-bit values every driver that uses the VME core will need to convert
>> pci addresses, vme addresses and counts to 2 32-bit values. That is
>> madness.
>>
>
> I agree with you on that's painful for doing 64-bit accesses.
> However I'm still not convinced on the performance side (I mean
> software), since most of the time the upper 32bits will be empty.
> Will have a look though.
>
>
Regardless of the contents of the upper 32 bits, they will need to be
checked. For example when ensuring a window offset and size fit within a
given address space. To do this the bound needs to be calculated.
To do this with 2 32-bit values. add the lower window offset and size,
which could lead to an over-flow of the lower 32-bit value, which needs
to be added to the upper 32-bit value, which is the sum of the upper
window offset and size. Then potentially check both the upper and lower
values (thinking of 16-bit address range here) to ensure they are below
the maximum address for the address range.
Compared to an addition of the window offset and size and a comparison
to the maximum address for the address range when using one 64-bit value.
Clearly neither of the above basic outlines check that the combination
has wrapped over 64 bits, but this would affect both equally.
So, which is more complex?
Martyn
> Cheers,
> E.
>
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
next prev parent reply other threads:[~2009-08-11 12:46 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090803205657.964064732@mini.kroah.org>
2009-08-03 21:00 ` [patch 0/5] [ANNOUNCE] VME Bus drivers and framework for Linux Greg K-H
2009-08-03 21:01 ` [patch 1/5] Staging: VME Framework for the Linux Kernel Greg K-H
2009-08-08 23:01 ` Emilio G. Cota
2009-08-10 12:44 ` Martyn Welch
2009-08-10 14:14 ` Emilio G. Cota
2009-08-10 15:31 ` Emilio G. Cota
2009-08-10 16:40 ` Martyn Welch
2009-08-10 19:50 ` Emilio G. Cota
2009-08-11 8:02 ` Martyn Welch
2009-08-11 8:43 ` Emilio G. Cota
2009-08-10 15:53 ` Martyn Welch
2009-08-10 16:26 ` Shawn Bohrer
2009-08-10 19:38 ` Emilio G. Cota
2009-08-11 8:29 ` Martyn Welch
2009-08-11 14:49 ` Emilio G. Cota
2009-08-11 15:10 ` Martyn Welch
2009-08-11 15:36 ` Emilio G. Cota
2009-08-11 15:41 ` Martyn Welch
2009-08-11 15:42 ` Emilio G. Cota
2009-08-11 16:38 ` Martyn Welch
2009-08-11 20:48 ` Emilio G. Cota
2009-08-12 9:54 ` Emilio G. Cota
2009-08-12 9:59 ` Martyn Welch
2009-08-12 10:09 ` Emilio G. Cota
2009-08-12 10:19 ` Martyn Welch
2009-08-11 4:54 ` Mike Frysinger
2009-08-11 7:48 ` Martyn Welch
2009-08-10 16:30 ` Greg KH
2009-08-10 14:52 ` [PATCH] Staging: vme: fix {master,slave}_get check bug Emilio G. Cota
2009-08-10 16:50 ` Martyn Welch
2009-08-03 21:01 ` [patch 2/5] Staging: vme: add VME userspace driver Greg K-H
2009-08-08 23:22 ` Emilio G. Cota
2009-08-09 12:17 ` Emilio G. Cota
2009-08-10 13:13 ` Martyn Welch
2009-08-10 15:26 ` Emilio G. Cota
2009-08-10 16:29 ` Greg KH
2009-08-10 16:30 ` Martyn Welch
2009-08-10 20:36 ` Emilio G. Cota
2009-08-11 9:03 ` Martyn Welch
2009-08-11 9:40 ` Emilio G. Cota
2009-08-11 12:46 ` Martyn Welch [this message]
2009-08-11 21:01 ` Emilio G. Cota
2009-08-12 8:17 ` Martyn Welch
2009-08-12 9:39 ` Emilio G. Cota
2009-08-12 9:57 ` Martyn Welch
2009-08-12 11:20 ` Emilio G. Cota
2009-08-12 12:19 ` Martyn Welch
2009-08-10 16:28 ` Greg KH
2009-08-10 20:05 ` Emilio G. Cota
2009-08-10 21:09 ` Greg KH
2009-08-11 7:04 ` Emilio G. Cota
2009-08-03 21:01 ` [patch 3/5] Staging: vme: add Universe I/II bridge driver Greg K-H
2009-08-03 23:00 ` Jiri Slaby
2009-08-03 21:01 ` [patch 4/5] Staging: vme: add Tundra TSI148 VME-PCI Bridge driver Greg K-H
2009-08-03 22:50 ` Jiri Slaby
2009-08-03 22:55 ` Jiri Slaby
2009-08-05 16:33 ` [PATCH] Staging: Correct tsi-148 VME interrupt free routine Martyn Welch
2009-08-05 16:38 ` [PATCH v2] " Martyn Welch
2009-08-05 21:53 ` Jiri Slaby
2009-08-06 7:20 ` Martyn Welch
2009-08-09 0:09 ` [patch 4/5] Staging: vme: add Tundra TSI148 VME-PCI Bridge driver Emilio G. Cota
2009-08-11 14:59 ` [patch 4/5] Staging: vme: add Tundra TSI148 VME-PCI Bridgedriver Martyn Welch
2009-08-03 21:01 ` [patch 5/5] Staging: vme: add TODO file Greg K-H
2009-08-04 7:56 ` [patch 0/5] [ANNOUNCE] VME Bus drivers and framework for Linux Martyn Welch
2009-08-08 22:25 ` Emilio G. Cota
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=4A81683D.2030408@gefanuc.com \
--to=martyn.welch@gefanuc.com \
--cc=cota@braap.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=sebastien.dugue@bull.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 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.