Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@dsl2.external.hp.com>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: James.Bottomley@steeleye.com, parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Untested port of parisc_device to generic device interface
Date: Fri, 08 Nov 2002 18:56:11 -0700	[thread overview]
Message-ID: <20021109015611.571B44829@dsl2.external.hp.com> (raw)
In-Reply-To: Message from "Adam J. Richter" <adam@yggdrasil.com> of "Fri, 08 Nov 2002 17:28:05 PST." <200211090128.RAA31693@adam.yggdrasil.com>

"Adam J. Richter" wrote:
> 	One question about the machine that has no consistent memory
> option: does it take PCI cards?

Adam (and James),
They don't have PCI slots.
I hedge because HP makes a "card-mode Dino" type of card that will
fit into 715 which has a GSCtoPCI bus controller on-board along
with the target PCI device (eg 21143 tulip)

The only non-coherent machines I can think of off hand are fairly old.
Common feature is they have PCX-T and older processor:
	http://hwdb.parisc-linux.org/view.php3?type=cpu&name=PA7000%20(PCX-S)
	http://hwdb.parisc-linux.org/view.php3?type=cpu&name=PA7100%2FPA7150%20(PCX-T)

> If so, then all PCI device drivers
> should theoretically use something like wback_fake_consistent.

I don't think that would fly even if it was needed.

> If not, then it sounds like the facility needs only to apply to
> generic DMA operations for "parisc" bus cards.

I think so.
Matthew "willy" Wilcox is more familiar with the issues than I though.
I've focus'd on systems with PCI.

...
> diff -u -r linux-2.5.46/include/asm-parisc/hardware.h linux/include/asm-paris
>   c/hardware.h
> --- linux-2.5.46/include/asm-parisc/hardware.h	Wed Oct 30 21:32:15 200
>   2
> +++ linux/include/asm-parisc/hardware.h	Fri Nov  8 01:49:09 2002
> @@ -1,6 +1,7 @@
>  #ifndef _PARISC_HARDWARE_H
>  #define _PARISC_HARDWARE_H
>  
> +#include <linux/device.h>
>  #include <asm/pdc.h>
>  
>  struct parisc_device_id {
> @@ -26,14 +27,10 @@
>  struct parisc_device {
>  	unsigned long   hpa;		/* Hard Physical Address */
>  	struct parisc_device_id id;
> -	struct parisc_device *parent;
> -	struct parisc_device *sibling;
> -	struct parisc_device *child;
> -	struct parisc_driver *driver;	/* Driver for this device */

you don't want to do this unless something similar replaces it.
Coherent IO machines depend on the parent/child relationships to
initialize/operate properly.

> -	void		*sysdata;	/* Driver instance private data */
>  	char		name[80];	/* The hardware description */
>  	int		irq;
>  
> +	struct device	device;

making this the first thing in the struct would allow simple
casts to/from each "flavor" of device structure. ie PCI controller
code could look at the struct for any other bus controller safely
(and vice versa).

>  	char		hw_path;        /* The module number on this bus */
>  	unsigned int	num_addrs;	/* some devices have additional address
>    ranges. */
>  	unsigned long	*addr;          /* which will be stored here */
> @@ -66,10 +63,10 @@
>  extern char *cpu_name_version[][2]; /* mapping from enum cpu_type to strings
>    */
>  
>  struct parisc_driver {
> -	struct parisc_driver *next;
>  	char *name; 
>  	const struct parisc_device_id *id_table;
>  	int (*probe) (struct parisc_device *dev); /* New device discovered */

and *dev should point to a struct device?

willy/rbrad really need to review/collaborate with this set of change
since they've put alot of effort into the current scheme.
I'm sure both would be glad to help.

thanks!
grant

  reply	other threads:[~2002-11-09  1:56 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-09  1:28 [parisc-linux] Untested port of parisc_device to generic device interface Adam J. Richter
2002-11-09  1:56 ` Grant Grundler [this message]
2002-11-09  3:46   ` Matthew Wilcox
2002-11-09 17:02     ` Grant Grundler
2002-11-09 17:50       ` Matthew Wilcox
2002-11-09 19:03         ` Grant Grundler
2002-11-09  3:37 ` Matthew Wilcox
2002-11-09  3:37 ` Matthew Wilcox
  -- strict thread matches above, loose matches on Subject: below --
2002-11-10  5:20 Adam J. Richter
2002-11-10  5:20 Adam J. Richter
2002-11-10  1:50 Adam J. Richter
2002-11-10  1:50 Adam J. Richter
2002-11-10  0:23 Adam J. Richter
2002-11-10  0:23 Adam J. Richter
2002-11-10  2:01 ` J.E.J. Bottomley
2002-11-10  2:01 ` J.E.J. Bottomley
2002-11-10  2:15   ` Matthew Wilcox
2002-11-10  2:15   ` Matthew Wilcox
2002-11-09 12:22 Adam J. Richter
2002-11-09 12:22 Adam J. Richter
2002-11-09  4:51 Adam J. Richter
2002-11-09  5:21 ` Matthew Wilcox
2002-11-09  6:03   ` Greg KH
2002-11-09  6:03   ` Greg KH
2002-11-09 15:33     ` J.E.J. Bottomley
2002-11-13  6:13       ` Greg KH
2002-11-13  7:46         ` Miles Bader
2002-11-13  7:52           ` Greg KH
2002-11-13  7:52           ` Greg KH
2002-11-13  8:02             ` Miles Bader
2002-11-13  8:02             ` Miles Bader
2002-11-13  8:10               ` Greg KH
2002-11-13  8:26                 ` Miles Bader
2002-11-13  8:26                 ` Miles Bader
2002-11-13  8:25                   ` Greg KH
2002-11-13  9:05                     ` Miles Bader
2002-11-13  9:05                     ` Miles Bader
2002-11-13  8:25                   ` Greg KH
2002-11-13  8:10               ` Greg KH
2002-11-13 20:13               ` Grant Grundler
2002-11-13 20:13               ` Grant Grundler
2002-11-13 20:21                 ` J.E.J. Bottomley
2002-11-13 20:37                   ` Grant Grundler
2002-11-13 20:37                   ` Grant Grundler
2002-11-13 20:21                 ` J.E.J. Bottomley
2002-11-13 11:59             ` Ivan Kokshaysky
2002-11-13 11:59             ` Ivan Kokshaysky
2002-11-13 12:36               ` Marc Zyngier
2002-11-13 12:36               ` Marc Zyngier
2002-11-13 16:32             ` Bjorn Helgaas
2002-11-13 16:32             ` Bjorn Helgaas
2002-11-13 17:23               ` J.E.J. Bottomley
2002-11-13 17:23               ` J.E.J. Bottomley
2002-11-13 20:33                 ` Grant Grundler
2002-11-13 20:33                 ` Grant Grundler
2002-11-13 20:44                   ` J.E.J. Bottomley
2002-11-13 20:44                   ` J.E.J. Bottomley
2002-11-13 21:42                     ` Grant Grundler
2002-11-13 21:42                     ` Grant Grundler
2002-11-13 20:12             ` Grant Grundler
2002-11-13 20:12             ` Grant Grundler
2002-11-13  7:46         ` Miles Bader
2002-11-13  6:13       ` Greg KH
2002-11-09 15:33     ` J.E.J. Bottomley
2002-11-09  7:58   ` Marc Zyngier
2002-11-09  7:58   ` Marc Zyngier
2002-11-09  5:21 ` Matthew Wilcox
2002-11-09 18:04 ` Grant Grundler
2002-11-09 18:04 ` Grant Grundler
2002-11-09  4:51 Adam J. Richter
2002-11-09  1:28 Adam J. Richter

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=20021109015611.571B44829@dsl2.external.hp.com \
    --to=grundler@dsl2.external.hp.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=adam@yggdrasil.com \
    --cc=parisc-linux@lists.parisc-linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox