All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: linux-input@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org, paulus@samba.org, anton@samba.org,
	greg@kroah.com
Subject: Re: DMA APIs gumble grumble
Date: Wed, 08 Nov 2006 16:44:42 +1100	[thread overview]
Message-ID: <1162964682.28571.715.camel@localhost.localdomain> (raw)
In-Reply-To: <20061107.212937.70218368.davem@davemloft.net>


> > Then, maybe 6 month, maybe 1 year later, we can change archs that use
> > the "alternate" semantic like sparc64 to no longer fail
> > pci_set_dma_mask(64bits).
> > 
> > In fact, the only breakage here would be for those archs to have some
> > drivers start going slowly, though we could expect drivers to have been
> > fixed by then.... (And we can delay that second part of the change as
> > long as deemed necessary).
> 
> The arch implementations of pci_map_*() et al. might start
> failing since they were written assuming that DAC never got
> enabled.

True. However, as I said, we don't have to deprecate the old technique
right away, we have time to get the drivers fixed, provided we agree
that this is the way to go.

> > Yup, but you didn't fix sparc32 :-) I suppose I can try to do it and ask
> > Anton for help if things go wrong, though I can't be bothered building a
> > cross toolchain or getting a box on ebay so I'll rely on your for
> > testing :-)
> 
> I only do sparc32 build testing, which you can do on a sparc64
> box and Al Viro has great recipies for cross tool building and
> usage.

Yup, I might have a look. (Or maybe can you give accounts on a box I can
use ? That would be even easier)

> > Thus, that is 3 pointers gone for archs who don't use these, and the ability
> > to put things like your dma ops in every struct device.
> 
> How exactly does your device struct extension work?  I ask because
> struct device is embedded into other structs, such as pci_dev,
> so it has to be fixed in size unless you have some clever trick. :)

Nah, my extension is fixed, it's just that it's defined by the arch. So
archs who don't care don't get the bloat.

Right now, my implementation just hijacks firmare_data, so it's a
pointer (and thus potentially could be variable size) but I want to have
it "flat" in for performances.

My current device_ext on powerpc is:

struct device_ext {
        /* Optional pointer to an OF device node */
        struct device_node      *of_node;

        /* DMA operations on that device */
        struct dma_mapping_ops  *dma_ops;
        void                    *dma_data;

        /* NUMA node if applicable */
        int                     numa_node;
};

If we remove plaform_data and firmware_data from struct device, then the
size difference is one pointer and one int, which isn't -that- much (for
powerpc, I consider that acceptable).

The idea is just to have asm/device.h do

struct device_ext {
};

That is, define an empty struct, for all archs that don't care about it,
though I want to move the dma_cohrerent_map thingy into the extension
for the 3 archs that seem to use it (x86, frv and m32.

Cheers,
Ben



  reply	other threads:[~2006-11-08  5:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-08  1:54 DMA APIs gumble grumble Benjamin Herrenschmidt
2006-11-08  4:46 ` David Miller
2006-11-08  5:23   ` Benjamin Herrenschmidt
2006-11-08  5:29     ` David Miller
2006-11-08  5:44       ` Benjamin Herrenschmidt [this message]
2006-11-10  1:02   ` Benjamin Herrenschmidt
2006-11-10  2:50     ` David Miller
2006-11-10  2:55       ` Benjamin Herrenschmidt
2006-11-10  3:01         ` David Miller
2006-11-10  4:07           ` Benjamin Herrenschmidt
2006-11-08  8:25 ` Muli Ben-Yehuda
2006-11-08  8:47   ` Benjamin Herrenschmidt
2006-11-08  9:21     ` Muli Ben-Yehuda
2006-11-08 10:00       ` Benjamin Herrenschmidt
2006-11-08 22:56     ` Russell King
2006-11-08 23:41       ` Benjamin Herrenschmidt
2006-11-09  0:43       ` Benjamin Herrenschmidt

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=1162964682.28571.715.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=anton@samba.org \
    --cc=davem@davemloft.net \
    --cc=greg@kroah.com \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.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 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.