First off, lets remember that this discussion started over two different, but
related, problem sets. One was the DMA api and the other was the device model.
As far as the DMA API goes, consistent memory allocation has always annoyed me
because there are three separate cases
1. machine is consistent, consistent allocation always succeeds (unless we're
out of memory)
2. machine is fully inconsistent, consistent allocation always fails.
3. Machine is partially consistent. consistent allocation may fail because
we're out of consistent memory so we have to fall back to the old.
What I'd like is an improvement to the DMA API where drivers can advertise
levels of conformance (I only work with consistent memory or I work correctly
with any dma'able memory and do all the sync points), and where all the sync
point stuff optimises out for a machine architecture which is recognisably
fully consistent at compile time.
Ok, I'll get off my soapbox now. I never quite recovered from the awful
#ifdef mess that doing the above correctly for the parisc introduced into the
53c700 driver...
As far as the device model goes:
[email protected] said:
> No, lets start pulling stuff out of pci_dev and relying on struct
> device. The reason this hasn't happened yet is no one has been
> willing to break all of the PCI drivers, yet.
I'd like to see that. It's always annoyed me that my MCA machines have to
bounce highmem just because they don't have a pci_dev to put the bounce mask
in.
> The SCSI people are being drug kicking and screaming into it,
> _finally_ now (hell, SCSI is still not using the updated PCI
> interface, those people _never_ update their drivers if they can avoid
> it.)
That't not entirely fair. Most of the unbroken drivers in the tree (those
with active 2.5 maintainers) are using the up to date pci/dma interface. The
mid layer is `sort of' using the device api.
Where I'd like to see the device model go for SCSI is:
- we have a device node for every struct scsi_device (even unattached ones)
- unattached devices are really minimal entities with as few resources
allocated as we can get away with, so we can have lazy attachment more easily.
- on attachment, the device node gets customised by the attachment type (and
remember, we can have more than one attachment).
- whatever the permanent `name' field for the device is going to be needs to
be writeable from user level, that way it can eventually be determined by the
user level and simply written there as a string (rather than having all the
wwn fallback cruft in the mid-layer).
- Ultimately, I'd like us to dump the host/channel/target numbering scheme in
favour of the unique device node name (we may still number them in the
mid-layer for convenience) so that we finesse the FC mapping problems---FC
devices can embed the necessary identification in the target strings.
- Oh, and of course, we move to a hotplug/coldplug model where the root device
is attached in initramfs and everything else is discovered in user space from
the boot process.
> Patches for this stuff are going to be happening for quite some time
> now, don't despair.
> And they are greatly appreciated, and welcomed from everyone :)
As far as extending the generic device model goes, I'll do it for the MCA bus.
I have looked at doing it previously, but giving the MCA bus a struct pci_dev
is a real pain because of the underlying assumptions when one of these exists
in an x86 machine.
But, while were on the subject of sorting out the device model abstraction,
does the `power' node entry really belong at the top level? It serves no
purpose for something like a legacy MCA bus.
James
On Sat, Nov 09, 2002 at 10:33:56AM -0500, J.E.J. Bottomley wrote:
>
> > The SCSI people are being drug kicking and screaming into it,
> > _finally_ now (hell, SCSI is still not using the updated PCI
> > interface, those people _never_ update their drivers if they can avoid
> > it.)
>
> That't not entirely fair. Most of the unbroken drivers in the tree (those
> with active 2.5 maintainers) are using the up to date pci/dma interface. The
> mid layer is `sort of' using the device api.
I was referring to the pci_module_init() model of PCI drivers, which, as
of 2.5.47, is only implemented in the ips, nsp32 and aic7xxx drivers.
Every other PCI SCSI controller driver will crash and burn a nasty death
if placed in a machine with a PCI hotplug controller, and someone tries
to remove it. Hopefully someday this will be fixed... :)
> Where I'd like to see the device model go for SCSI is:
>
> - we have a device node for every struct scsi_device (even unattached ones)
>
> - unattached devices are really minimal entities with as few resources
> allocated as we can get away with, so we can have lazy attachment more easily.
>
> - on attachment, the device node gets customised by the attachment type (and
> remember, we can have more than one attachment).
>
> - whatever the permanent `name' field for the device is going to be needs to
> be writeable from user level, that way it can eventually be determined by the
> user level and simply written there as a string (rather than having all the
> wwn fallback cruft in the mid-layer).
>
> - Ultimately, I'd like us to dump the host/channel/target numbering scheme in
> favour of the unique device node name (we may still number them in the
> mid-layer for convenience) so that we finesse the FC mapping problems---FC
> devices can embed the necessary identification in the target strings.
>
> - Oh, and of course, we move to a hotplug/coldplug model where the root device
> is attached in initramfs and everything else is discovered in user space from
> the boot process.
All of that sounds very reasonable, and would be nice to see
implemented.
> > Patches for this stuff are going to be happening for quite some time
> > now, don't despair.
>
> > And they are greatly appreciated, and welcomed from everyone :)
>
> As far as extending the generic device model goes, I'll do it for the MCA bus.
> I have looked at doing it previously, but giving the MCA bus a struct pci_dev
> is a real pain because of the underlying assumptions when one of these exists
> in an x86 machine.
What is the real reason for needing this, pci_alloc_consistent()? We
have talked about renaming that to dev_alloc_consistent() in the past,
which I think will work for you, right?
thanks,
greg k-h
Greg KH <[email protected]> writes:
> What is the real reason for needing this, pci_alloc_consistent()? We
> have talked about renaming that to dev_alloc_consistent() in the past,
> which I think will work for you, right?
This this would end up [or have the ability to] invoking a bus-specific
routine at some point, right? [so that a truly PCI-specific definition
could be still be had]
Thanks,
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
On Wed, Nov 13, 2002 at 04:46:58PM +0900, Miles Bader wrote:
> Greg KH <[email protected]> writes:
> > What is the real reason for needing this, pci_alloc_consistent()? We
> > have talked about renaming that to dev_alloc_consistent() in the past,
> > which I think will work for you, right?
>
> This this would end up [or have the ability to] invoking a bus-specific
> routine at some point, right? [so that a truly PCI-specific definition
> could be still be had]
If that was needed, yes, we should not break that functionality.
Are there any existing archs that need more than just dma_mask moved to
struct device out of pci_dev? Hm, ppc might need a bit more...
thanks,
greg k-h
Greg KH <[email protected]> writes:
> > This this would end up [or have the ability to] invoking a bus-specific
> > routine at some point, right? [so that a truly PCI-specific definition
> > could be still be had]
>
> If that was needed, yes, we should not break that functionality.
>
> Are there any existing archs that need more than just dma_mask moved to
> struct device out of pci_dev? Hm, ppc might need a bit more...
I can't speak for `real machines,' but on my wierd embedded board,
pci_alloc_consistent allocates from a special area of memory (not
located at 0) that is the only shared memory between PCI devices and the
CPU. pci_alloc_consistent happens to fit this situation quite well, but
I don't think a bitmask is enough to express the situation.
-Miles
--
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
On Wed, Nov 13, 2002 at 05:02:39PM +0900, Miles Bader wrote:
> Greg KH <[email protected]> writes:
> > > This this would end up [or have the ability to] invoking a bus-specific
> > > routine at some point, right? [so that a truly PCI-specific definition
> > > could be still be had]
> >
> > If that was needed, yes, we should not break that functionality.
> >
> > Are there any existing archs that need more than just dma_mask moved to
> > struct device out of pci_dev? Hm, ppc might need a bit more...
>
> I can't speak for `real machines,' but on my wierd embedded board,
> pci_alloc_consistent allocates from a special area of memory (not
> located at 0) that is the only shared memory between PCI devices and the
> CPU. pci_alloc_consistent happens to fit this situation quite well, but
> I don't think a bitmask is enough to express the situation.
What does your pci_alloc_consistent() function need from the pci_dev
structure in order to do what you need it to do? Anything other than
the dma_mask value?
thanks,
greg k-h
On Wed, Nov 13, 2002 at 05:26:34PM +0900, Miles Bader wrote:
> Greg KH <[email protected]> writes:
> > > I can't speak for `real machines,' but on my wierd embedded board,
> > > pci_alloc_consistent allocates from a special area of memory (not
> > > located at 0) that is the only shared memory between PCI devices and the
> > > CPU. pci_alloc_consistent happens to fit this situation quite well, but
> > > I don't think a bitmask is enough to express the situation.
> >
> > What does your pci_alloc_consistent() function need from the pci_dev
> > structure in order to do what you need it to do? Anything other than
> > the dma_mask value?
>
> Currently, it ignores the pci_dev argument entirely (I've never had a
> device that needed the mask, so I haven't bothered with it). It just
> allocates a block from the special memory region and returns the result.
So merely renaming that function to dev_alloc_consistent(), changing the
first paramater to be a struct device, and proving a macro for all of
the pci drivers for the old pci_alloc_consistent() name would work just
fine for you?
greg k-h
Greg KH <[email protected]> writes:
> > I can't speak for `real machines,' but on my wierd embedded board,
> > pci_alloc_consistent allocates from a special area of memory (not
> > located at 0) that is the only shared memory between PCI devices and the
> > CPU. pci_alloc_consistent happens to fit this situation quite well, but
> > I don't think a bitmask is enough to express the situation.
>
> What does your pci_alloc_consistent() function need from the pci_dev
> structure in order to do what you need it to do? Anything other than
> the dma_mask value?
Currently, it ignores the pci_dev argument entirely (I've never had a
device that needed the mask, so I haven't bothered with it). It just
allocates a block from the special memory region and returns the result.
-Miles
--
$B<+$i$r6u$K$7$F!"?4$r3+$/;~!"F;$O3+$+$l$k(B
Greg KH <[email protected]> writes:
> > Currently, it ignores the pci_dev argument entirely (I've never had a
> > device that needed the mask, so I haven't bothered with it). It just
> > allocates a block from the special memory region and returns the result.
>
> So merely renaming that function to dev_alloc_consistent(), changing the
> first paramater to be a struct device, and proving a macro for all of
> the pci drivers for the old pci_alloc_consistent() name would work just
> fine for you?
Except that this function doesn't make any sense except for PCI devices.
I don't know whether there will ever be any devices that (1) call
`dev_alloc_consistent', (2) aren't PCI devices, and (3) would stand a
chance of ever working on this platform -- probably not.
Never-the-less, it provides (a non-artificial) example of a case where
it's wrong to assume that all busses are the same, and I think that
merits some attention.
-Miles
--
97% of everything is grunge
On Tue, Nov 12, 2002 at 11:52:23PM -0800, Greg KH wrote:
> On Wed, Nov 13, 2002 at 04:46:58PM +0900, Miles Bader wrote:
> > This this would end up [or have the ability to] invoking a bus-specific
> > routine at some point, right? [so that a truly PCI-specific definition
> > could be still be had]
>
> If that was needed, yes, we should not break that functionality.
>
> Are there any existing archs that need more than just dma_mask moved to
> struct device out of pci_dev? Hm, ppc might need a bit more...
Add alpha, parisc, sparc and so on. ;-)
pci_dev->sysdata needs to be moved as well, but not only.
It seems that two things are fundamentally missing in generic
device model:
1. clean way to detect the type of container structure from arbitrary
struct device *;
2. parent/child relationship between devices of different bus types.
Example (not exactly real life, but close enough):
to do DMA mapping properly for, say, some legacy device, I need to know
that it's sitting behind ISA-to-PCI bridge X belonging in PCI domain Y of
the root-level IO controller Z.
Ivan.
>>>>> "Ivan" == Ivan Kokshaysky <[email protected]> writes:
Ivan> It seems that two things are fundamentally missing in generic
Ivan> device model:
Ivan> 1. clean way to detect the type of container structure from arbitrary
Ivan> struct device *;
Indeed.
I'm using the following stuff in some EISA drivers :
#ifdef CONFIG_EISA
#define DEVICE_EISA(dev) (((dev)->bus == &eisa_bus_type) ? to_eisa_device((dev)) : NULL)
#else
#define DEVICE_EISA(dev) NULL
#endif
and frankly, it's really awful. On drivers which are both EISA and
PCI (3c59x, aic7xxx), this is a major pain.
M.
--
Places change, faces change. Life is so very strange.
On Wednesday 13 November 2002 12:52 am, Greg KH wrote:
> On Wed, Nov 13, 2002 at 04:46:58PM +0900, Miles Bader wrote:
> > Greg KH <[email protected]> writes:
> > > What is the real reason for needing this, pci_alloc_consistent()? We
> > > have talked about renaming that to dev_alloc_consistent() in the past,
> > > which I think will work for you, right?
> >
> > This this would end up [or have the ability to] invoking a bus-specific
> > routine at some point, right? [so that a truly PCI-specific definition
> > could be still be had]
>
> If that was needed, yes, we should not break that functionality.
>
> Are there any existing archs that need more than just dma_mask moved to
> struct device out of pci_dev? Hm, ppc might need a bit more...
Absolutely. Boxes with multiple IOMMUs (at least ia64, sparc64, parisc)
need to look up the correct IOMMU with which to map the allocated buffer.
Typically this is in the pci_dev sysdata.
Bjorn