All of lore.kernel.org
 help / color / mirror / Atom feed
From: Armin Kuster <akuster@mvista.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: ppcdevel <linuxppc-dev@lists.linuxppc.org>
Subject: Re: New API for non cache coherent ppc cpu's
Date: Wed, 21 Nov 2001 10:29:11 -0800	[thread overview]
Message-ID: <3BFBF277.A05245D6@mvista.com> (raw)
In-Reply-To: Pine.LNX.4.33.0111211152230.6681-100000@serv


Roman Zippel wrote:
>
> Hi,
>
> On Tue, 20 Nov 2001, Armin Kuster wrote:
>
> > About a month ago a new API made its way into the ppc,
> > consistent_sync_page.
>
> Another one?
> We have now 3 APIs for this:
> - cache_(push|clear): that's the old m68k API (and also used by APUS)
> - dma_cache_(inv|wback|wback_inv): used by mips(64), parisc, sh
> - consistent_sync_page: ppc
>
> >  For CONFIG_NOT_COHERENT_CACHE  processors,
> > requires
> > proper flushing of the page being used.  Please review and provide feed
> > back
>
> Two comments:
> - I'm not sure about the page argument, although I'd like to see it, the
> problem is the drivers usually don't have a page pointer.

example as it is used today.

mapping = pci_map_page(pdev,
			       virt_to_page(cmd->request_buffer),
			       ((unsigned long)cmd->request_buffer &
				~PAGE_MASK),
			       cmd->request_bufflen, dma_dir);

/*
 * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t.
identical
 * to pci_map_single, but takes a struct page instead of a virtual
address
 */
static inline dma_addr_t pci_map_page(struct pci_dev *hwdev, struct page
*page,
				      unsigned long offset, size_t size,
				      int direction)
{
	if (direction == PCI_DMA_NONE)
		BUG();
	consistent_sync_page(page, offset, size, direction);
	return (page - mem_map) * PAGE_SIZE + PCI_DRAM_OFFSET + offset;
}

> - I think it was never defined, what should be done if offset/size isn't
> cache line aligned. That's especially a problem in the invalidate only
> case. I'd prefer to make this illegal, as it's mostly not a problem for
> drivers.
>

wouldn't it also be a problem for consistent_sync?  we don't check for
offset/size are cache line aligned.

> bye, Roman



-- armin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-11-21 18:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-20 20:13 New API for non cache coherent ppc cpu's Armin Kuster
2001-11-21 11:15 ` Roman Zippel
2001-11-21 18:29   ` Armin Kuster [this message]
2001-11-21 20:20     ` Roman Zippel
2001-11-22 20:57 ` Paul Mackerras
2001-11-22 23:07   ` Dan Malek
2001-11-22 23:54     ` Roman Zippel
2001-11-23  1:32     ` Paul Mackerras
2001-11-23 16:08       ` Dan Malek
2001-11-22 23:50   ` Roman Zippel
2001-11-23  1:09     ` Paul Mackerras

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=3BFBF277.A05245D6@mvista.com \
    --to=akuster@mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=zippel@linux-m68k.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.