LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-05 19:01 UTC (permalink / raw)
  To: Zhang, Yanmin
  Cc: Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev, linux-pci maillist
In-Reply-To: <1157423528.20092.365.camel@ymzhang-perf.sh.intel.com>

On Tue, Sep 05, 2006 at 10:32:08AM +0800, Zhang, Yanmin wrote:
> Is it the exclusive reason to have multi-steps?

I don't understand the question. A previous email explained the reason
to have mutiple steps.

> 1) Here link reset and hard reset are hardware operations, not the
> link_reset and slot_reset callback in pci_error_handlers.

I don't understand the comment.

> 2) Callback error_detected will notify drivers there is PCI errors. Drivers
> shouldn't do any I/O in error_detected.

It shouldn't matter. If it is truly important for a particular platform
to make sure that there is no i/o, then the low-level i/o routines
could be modified to drop any accidentally issued i/o on the floor.
This doesn't require a change to either the API or the policy.

> 3) If both the link and slot are reset after all error_detected are called,
> the device should go back to initial status and all DMA should be stopped
> automatically. Why does the driver still need a chance to stop DMA? 

As explained previously, not all drivers may want to have a full
electrical device reset.

> The
> error_detected of the drivers in the latest kernel who support err handlers
> always returns PCI_ERS_RESULT_NEED_RESET. They are typical examples.

Just because the current drivers do it this way does not mean that this is
the best way to do things. A full reset is time-consuming. Some drivers
may want to implement a faster and quicker reset.

--linas

^ permalink raw reply

* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-05 19:17 UTC (permalink / raw)
  To: Zhang, Yanmin
  Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157348850.20092.304.camel@ymzhang-perf.sh.intel.com>

On Mon, Sep 04, 2006 at 01:47:30PM +0800, Zhang, Yanmin wrote:
> > 
> > Again, consider the multi-function cards. On pSeries, I can  only enable 
> > DMA on a per-slot basis, not a per-function basis. So if one driver
> > enables DMA before some other driver has reset appropriately, everything
> > breaks.
> Does here 'reset' mean hardware slot reset? 

I should have said: If one driver of a multi-function card enables DMA before 
another driver has stabilized its harware, then everything breaks.

> Then, if the slot is always reset, there will be no the problem. 

But that assumes that a hardware #RST will always be done. The API
was designed to get away from this requirement.

> If mmio_enabled is not used currently, I think we could delete it firstly. Later on,
> if a platform really need it, we could add it, so we could keep the simplied codes.

It would be very difficult to add it later. And it would be especially
silly, given that someone would find this discussion in the mailing list 
archives.

> Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
> to map to pSeries platform hardware operation steps. I know little about pSeries hardware,

The hardware was designed that way because the hardware engineers
thought that this is what the device driver writers would need. 
Thay are there to map to actual recovery steps that actual device
drivers might want to do.

> but is it possible to merge such hardware steps from software point of view?

The previous email explained why this would be a bad idea. 

> > The platform. By "electrical reset", I mean "dropping the #RST pin low
> > for 200mS". Only the platform can do this.
> Thanks for your explanation. I assume after the electrical reset, all device
> functions of the device slot will go back to the initial status before
> attaching their drivers.

Maybe. Depends on what yur BIOS does. On pSeries, I also need to
set up the adress BARs

> I found a problem of e1000 driver when testing its error handlers. After the NIC is resumed,
> its RX/TX packets numbers are crazy.

Hmm. There is a patch to prevent this from happening. I thought
it was applied a long time ago. e1000_update_stats() should include the
lines:

   if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
      return;

which is enough to prevent crazy stats on my machine.

--linas

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Roland Dreier @ 2006-09-05 19:49 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905122956.2cebd36d@localhost.localdomain>

 > +#include <linux/config.h>
 > +#include <linux/init.h>
 > +#include <linux/errno.h>
 > +#include <linux/sched.h>
 > +#include <linux/kernel.h>
 > +#include <linux/mm.h>
 > +#include <linux/stddef.h>
 > +#include <linux/unistd.h>
 > +#include <linux/ptrace.h>
 > +#include <linux/slab.h>
 > +#include <linux/user.h>
 > +#include <linux/a.out.h>
 > +#include <linux/tty.h>
 > +#include <linux/string.h>
 > +#include <linux/delay.h>
 > +#include <linux/ioport.h>
 > +#include <linux/major.h>
 > +#include <linux/initrd.h>
 > +#include <linux/vt_kern.h>
 > +#include <linux/console.h>
 > +#include <linux/ide.h>
 > +#include <linux/pci.h>
 > +#include <linux/adb.h>
 > +#include <linux/cuda.h>
 > +#include <linux/pmu.h>
 > +#include <linux/irq.h>
 > +#include <linux/seq_file.h>
 > +#include <linux/root_dev.h>
 > +#include <linux/serial.h>
 > +#include <linux/smp.h>
 > +
 > +#include <asm/processor.h>
 > +#include <asm/sections.h>
 > +#include <asm/prom.h>
 > +#include <asm/system.h>
 > +#include <asm/pgtable.h>
 > +#include <asm/bitops.h>
 > +#include <asm/io.h>
 > +#include <asm/pci-bridge.h>
 > +#include <asm/iommu.h>
 > +#include <asm/machdep.h>
 > +#include <asm/dma.h>
 > +#include <asm/cputable.h>
 > +#include <asm/time.h>
 > +#include <asm/of_device.h>
 > +#include <asm/lmb.h>
 > +#include <asm/mpic.h>
 > +#include <asm/smp.h>
 > +#include <asm/udbg.h>
 > +#include <asm/serial.h>

Are all of these really needed?  Seems rather crazy, considering there
are only 145 lines after this in the file...

^ permalink raw reply

* Wireless Linux(802.11) for Embedded PowerPC
From: wei.li4 @ 2006-09-05 20:03 UTC (permalink / raw)
  To: linuxppc-embedded

Hi All,

Where is the best access point for this topic? Did anyone work on this 
with MPC8xx? Thanks.

Wei

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 20:15 UTC (permalink / raw)
  To: Roland Dreier; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <ada4pvmf60c.fsf@cisco.com>

On Tue, 05 Sep 2006 12:49:39 -0700 Roland Dreier <rdreier@cisco.com> wrote:

> Are all of these really needed?  Seems rather crazy, considering there
> are only 145 lines after this in the file...

Yeah, it's crazy. I'll clean it up.


Thanks,

-Olof

^ permalink raw reply

* Re: pci error recovery procedure
From: Benjamin Herrenschmidt @ 2006-09-05 21:19 UTC (permalink / raw)
  To: Linas Vepstas
  Cc: Zhang, Yanmin, Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev,
	linux-pci maillist
In-Reply-To: <20060905185020.GD7139@austin.ibm.com>

On Tue, 2006-09-05 at 13:50 -0500, Linas Vepstas wrote:
> On Mon, Sep 04, 2006 at 07:03:12PM +1000, Benjamin Herrenschmidt wrote:
> > 
> > > As you know, all functions of a device share the same bus number and 5 bit dev number.
> > > They just have different 3 bit function number. We could deduce if functions are in the same
> > > device (slot).
> > 
> > Until you have a P2P bridge ...
> 
> And this is not theoretical: for example, the matrox graphics cards:
> 
> 0000:c8:01.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) (rev 13)
> 0000:c9:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)

It's also very common with multiple ports network cards

Ben.

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Benjamin Herrenschmidt @ 2006-09-05 21:31 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905122853.4da8d0fe@localhost.localdomain>

Overall, looks good, some bits  tho:

> +static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
> +			      int offset, int len, u32 *val)
> +{
> +	struct pci_controller *hose;
> +	unsigned long addr;

 .../...

You don't seem to encode support for extended config space (offsets >
256). If it's PCIe, you should have it (flush the 4 top bits of the
offste in the 4 top bits of the cfg address in general). In any case,
you should check the passed-in offset and error out if it is above your
max offset (256 or 4096 depending if you implement extended config space
support) or the kernel might get confused.

> +	of_prop = alloc_bootmem(sizeof(struct property) +
> +				sizeof(hose->global_number));
> +	if (of_prop) {
> +		memset(of_prop, 0, sizeof(struct property));
> +		of_prop->name = "linux,pci-domain";
> +		of_prop->length = sizeof(hose->global_number);
> +		of_prop->value = (unsigned char *)&of_prop[1];
> +		memcpy(of_prop->value, &hose->global_number, sizeof(hose->global_number));
> +		prom_add_property(dev, of_prop);
> +	}

Just kill that... nobody cares about that property.

> +	if (device_is_compatible(dev, "pa-pxp"))
> +		setup_pa_pxp(hose);

And if not ? You have a non-initialized hose without config space access
methods ? Hrm... 

> +	printk(KERN_INFO "Found PA-PXP PCI host bridge. Firmware bus number: %d->%d\n",
> +		hose->first_busno, hose->last_busno);
> +
> +	/* Interpret the "ranges" property */
> +	/* This also maps the I/O region and sets isa_io/mem_base */
> +	pci_process_bridge_OF_ranges(hose, dev, 1);
> +	pci_setup_phb_io(hose, 1);
> +
> +	return 0;
> +}
> +
> +
> +void __init pas_pcibios_fixup(void)
> +{
> +	struct pci_dev *dev = NULL;
> +
> +	for_each_pci_dev(dev)
> +		pci_read_irq_line(dev);
> +}
> +
> +static void __init pas_fixup_phb_resources(void)
> +{
> +	struct pci_controller *hose, *tmp;
> +
> +	list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> +		unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
> +		hose->io_resource.start += offset;
> +		hose->io_resource.end += offset;
> +		printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
> +		       hose->global_number,
> +		       hose->io_resource.start, hose->io_resource.end);
> +	}
> +}

There is no generic code for the above ? (I have to double check). If
not, we shall fix that ;)

.../...

> +#ifdef CONFIG_SMP
> +struct smp_ops_t pas_smp_ops = {
> +	.probe		= smp_mpic_probe,
> +	.message_pass	= smp_mpic_message_pass,
> +	.kick_cpu	= smp_generic_kick_cpu,
> +	.setup_cpu	= smp_mpic_setup_cpu,
> +	.give_timebase	= smp_generic_give_timebase,
> +	.take_timebase	= smp_generic_take_timebase,
> +};

You don't have a HW timebase sync facility ? Is this the board or the
processor doesn't have a pin to freeze the timebase ? Either way, that
is bad ! Time to use the cluebat !

> +#endif /* CONFIG_SMP */
> +
> +void __init pas_setup_arch(void)
> +{
> +	/* init to some ~sane value until calibrate_delay() runs */
> +	loops_per_jiffy = 50000000;

That value still makes any sense with the new tb based delays ? I know
we still have it here or there, I'm wondering tho...

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Arnd Bergmann @ 2006-09-05 21:37 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Olof Johansson, paulus, anton
In-Reply-To: <20060905122956.2cebd36d@localhost.localdomain>

On Tuesday 05 September 2006 19:29, Olof Johansson wrote:
> Base patch for PA6T and PA6T-1682M. This introduces the
> arch/powerpc/platform/pasemi directory, together with basic
> implementations for various setup.
> 
> Much of this was based on other platform code, i.e. Maple, etc.
 
Very nice patch set, as expected ;-)

See below for the mandatory nitpicking.


> Index: merge/arch/powerpc/Kconfig
> ===================================================================
> --- merge.orig/arch/powerpc/Kconfig
> +++ merge/arch/powerpc/Kconfig
> @@ -413,6 +409,17 @@ config PPC_MAPLE
>            This option enables support for the Maple 970FX Evaluation Board.
>  	  For more informations, refer to <http://www.970eval.com>
>  
> +config PPC_PASEMI
> +	depends on PPC_MULTIPLATFORM && PPC64
> +	bool "PA Semi SoC-based platforms"
> +	default n
> +	select MPIC
> +	select PPC_UDBG_16550
> +	select GENERIC_TBSYNC
> +	help
> +	  This option enables support for PA Semi's PWRficient line
> +	  of SoC processors, including PA6T-1682M

IIRC, the GENERIC_TBSYNC code is really inefficient. Don't you
have any other way of implementing that?

> +
> +#undef DEBUG
> +

I know that this is done in other places as well, but it seems
rather pointless, and it provides setting DEBUG from EXTRA_CFLAGS
in the Makefile.


> +static struct pci_ops pa_pxp_ops =
> +{
> +	pa_pxp_read_config,
> +	pa_pxp_write_config
> +};

spacing: '{' after '=', and ',' after the final member.

> +
> +static void __init setup_pa_pxp(struct pci_controller* hose)
> +{
> +	hose->ops = &pa_pxp_ops;
> +	hose->cfg_data = ioremap(0xe0000000, 0x1000000);
> +}

Shouldn't that be in the device tree?

> +	bus_range = (int *) get_property(dev, "bus-range", &len);

Unneeded cast

> +	if (bus_range == NULL || len < 2 * sizeof(int)) {
> +		printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
> +		dev->full_name);
> +	}

if (!bus_range || len < 2 * sizeof(int)) {

> +
> +	hose = pcibios_alloc_controller(dev);
> +	if (hose == NULL)
> +		return -ENOMEM;

if (!hose)

> +	if (root == NULL) {

if (!root)
> +#undef DEBUG

remove

> +extern int pas_set_rtc_time(struct rtc_time *tm);
> +extern void pas_get_rtc_time(struct rtc_time *tm);
> +extern unsigned long pas_get_boot_time(void);
> +extern void pas_pci_init(void);
> +extern void pas_pcibios_fixup(void);

Extern declarations should never be in a source file, please
move them to a header

> +static void iommu_dev_setup_null(struct pci_dev *dev) { }
> +static void iommu_bus_setup_null(struct pci_bus *bus) { }
> +
> +static void __init pas_init_early(void)
> +{
> +	/* No iommu code yet */
> +	ppc_md.iommu_dev_setup = iommu_dev_setup_null;
> +	ppc_md.iommu_bus_setup = iommu_bus_setup_null;
> +	pci_direct_iommu_init();
> +}
> +
> +/* No legacy IO on our parts */
> +static int pas_check_legacy_ioport(unsigned int baseport)
> +{
> +	return -ENODEV;
> +}

Should we maybe change the default behavior so that you don't need
to provide nops for these functions?

> +
> +static __init void pas_init_IRQ(void)
> +{
> +	struct device_node *np = NULL;
> +	struct device_node *root, *mpic_node  = NULL;
> +	unsigned long openpic_addr = 0;

These three should not be initialized.


> +	BUG_ON(mpic == NULL);

BUG_ON(!mpic);

> +
> +#undef DEBUG

remove

> +void pas_get_rtc_time(struct rtc_time *tm)
> +{
> +}
> +
> +int pas_set_rtc_time(struct rtc_time *tm)
> +{
> +	return -ENODEV;
> +}

again, it probably makes sense to not have to provide these.

	Arnd <><

^ permalink raw reply

* Re: [PATCH] Unwire set/get_robust_list
From: David Woodhouse @ 2006-09-05 21:41 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jeodtvfn4x.fsf@sykes.suse.de>

On Mon, 2006-09-04 at 21:27 +0200, Andreas Schwab wrote:
> The syscalls set/get_robust_list must not be wired up until
> futex_atomic_cmpxchg_inatomic is implemented.  Otherwise the kernel
> will hang in handle_futex_death. 

Either Andreas' or my patch ought to go into 2.6.18, since
[gs]et_robust_list() are otherwise broken there.

-- 
dwmw2

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 21:48 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <200609052337.11557.arnd@arndb.de>

On Tue, 5 Sep 2006 23:37:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> On Tuesday 05 September 2006 19:29, Olof Johansson wrote:
> > Base patch for PA6T and PA6T-1682M. This introduces the
> > arch/powerpc/platform/pasemi directory, together with basic
> > implementations for various setup.
> > 
> > Much of this was based on other platform code, i.e. Maple, etc.
>  
> Very nice patch set, as expected ;-)
> 
> See below for the mandatory nitpicking.

Thanks Arnd, good feedback, see some comments below.

> 
> 
> > Index: merge/arch/powerpc/Kconfig
> > ===================================================================
> > --- merge.orig/arch/powerpc/Kconfig
> > +++ merge/arch/powerpc/Kconfig
> > @@ -413,6 +409,17 @@ config PPC_MAPLE
> >            This option enables support for the Maple 970FX Evaluation Board.
> >  	  For more informations, refer to <http://www.970eval.com>
> >  
> > +config PPC_PASEMI
> > +	depends on PPC_MULTIPLATFORM && PPC64
> > +	bool "PA Semi SoC-based platforms"
> > +	default n
> > +	select MPIC
> > +	select PPC_UDBG_16550
> > +	select GENERIC_TBSYNC
> > +	help
> > +	  This option enables support for PA Semi's PWRficient line
> > +	  of SoC processors, including PA6T-1682M
> 
> IIRC, the GENERIC_TBSYNC code is really inefficient. Don't you
> have any other way of implementing that?

Yes, we do. It'll be submitted in a later patch for various reasons. We'll use 
the generic sync for now.

> > +
> > +#undef DEBUG
> > +
> 
> I know that this is done in other places as well, but it seems
> rather pointless, and it provides setting DEBUG from EXTRA_CFLAGS
> in the Makefile.

Yes, mostly leftovers from older debug code. I've taken a few out already, 
will go through and take care of the rest.

> > +static struct pci_ops pa_pxp_ops =
> > +{
> > +	pa_pxp_read_config,
> > +	pa_pxp_write_config
> > +};
> 
> spacing: '{' after '=', and ',' after the final member.
> 
> > +
> > +static void __init setup_pa_pxp(struct pci_controller* hose)
> > +{
> > +	hose->ops = &pa_pxp_ops;
> > +	hose->cfg_data = ioremap(0xe0000000, 0x1000000);
> > +}
> 
> Shouldn't that be in the device tree?

I was torn between using device tree and hardcoded values here, and went with 
hardcoded since that's what maple uses. They're not movable on the chip, but 
for future versions I guess device tree makes more sense (if it for some 
reason will move).

> 
> > +	bus_range = (int *) get_property(dev, "bus-range", &len);
> 
> Unneeded cast
> 
> > +	if (bus_range == NULL || len < 2 * sizeof(int)) {
> > +		printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
> > +		dev->full_name);
> > +	}
> 
> if (!bus_range || len < 2 * sizeof(int)) {
> 
> > +
> > +	hose = pcibios_alloc_controller(dev);
> > +	if (hose == NULL)
> > +		return -ENOMEM;
> 
> if (!hose)
> 
> > +	if (root == NULL) {
> 
> if (!root)
> > +#undef DEBUG
> 
> remove
> 
> > +extern int pas_set_rtc_time(struct rtc_time *tm);
> > +extern void pas_get_rtc_time(struct rtc_time *tm);
> > +extern unsigned long pas_get_boot_time(void);
> > +extern void pas_pci_init(void);
> > +extern void pas_pcibios_fixup(void);
> 
> Extern declarations should never be in a source file, please
> move them to a header
> 
> > +static void iommu_dev_setup_null(struct pci_dev *dev) { }
> > +static void iommu_bus_setup_null(struct pci_bus *bus) { }
> > +
> > +static void __init pas_init_early(void)
> > +{
> > +	/* No iommu code yet */
> > +	ppc_md.iommu_dev_setup = iommu_dev_setup_null;
> > +	ppc_md.iommu_bus_setup = iommu_bus_setup_null;
> > +	pci_direct_iommu_init();
> > +}
> > +
> > +/* No legacy IO on our parts */
> > +static int pas_check_legacy_ioport(unsigned int baseport)
> > +{
> > +	return -ENODEV;
> > +}
> 
> Should we maybe change the default behavior so that you don't need
> to provide nops for these functions?

Good point, most platforms no longer implement this anyway. I'll code that up 
as a separate patch and submit later.

> 
> > +
> > +static __init void pas_init_IRQ(void)
> > +{
> > +	struct device_node *np = NULL;
> > +	struct device_node *root, *mpic_node  = NULL;
> > +	unsigned long openpic_addr = 0;
> 
> These three should not be initialized.
> 
> 
> > +	BUG_ON(mpic == NULL);
> 
> BUG_ON(!mpic);
> 
> > +
> > +#undef DEBUG
> 
> remove
> 
> > +void pas_get_rtc_time(struct rtc_time *tm)
> > +{
> > +}
> > +
> > +int pas_set_rtc_time(struct rtc_time *tm)
> > +{
> > +	return -ENODEV;
> > +}
> 
> again, it probably makes sense to not have to provide these.

Yep, I could take out the #if 0 as well. It's all a big placeholder anyway.


-Olof

^ permalink raw reply

* Re: [4/5] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 22:10 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1157491909.22705.143.camel@localhost.localdomain>

On Wed, 06 Sep 2006 07:31:49 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> Overall, looks good, some bits  tho:

Thanks! See below.


> 
> > +static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
> > +			      int offset, int len, u32 *val)
> > +{
> > +	struct pci_controller *hose;
> > +	unsigned long addr;
> 
>  .../...
> 
> You don't seem to encode support for extended config space (offsets >
> 256). If it's PCIe, you should have it (flush the 4 top bits of the
> offste in the 4 top bits of the cfg address in general). In any case,
> you should check the passed-in offset and error out if it is above your
> max offset (256 or 4096 depending if you implement extended config space
> support) or the kernel might get confused.

I'll take a look at this, thanks for pointing it out.

> > +	of_prop = alloc_bootmem(sizeof(struct property) +
> > +				sizeof(hose->global_number));
> > +	if (of_prop) {
> > +		memset(of_prop, 0, sizeof(struct property));
> > +		of_prop->name = "linux,pci-domain";
> > +		of_prop->length = sizeof(hose->global_number);
> > +		of_prop->value = (unsigned char *)&of_prop[1];
> > +		memcpy(of_prop->value, &hose->global_number, sizeof(hose->global_number));
> > +		prom_add_property(dev, of_prop);
> > +	}
> 
> Just kill that... nobody cares about that property.

Done

> > +	if (device_is_compatible(dev, "pa-pxp"))
> > +		setup_pa_pxp(hose);
> 
> And if not ? You have a non-initialized hose without config space access
> methods ? Hrm... 

True. Just a leftover from forking off the maple setup code.

> > +	printk(KERN_INFO "Found PA-PXP PCI host bridge. Firmware bus number: %d->%d\n",
> > +		hose->first_busno, hose->last_busno);
> > +
> > +	/* Interpret the "ranges" property */
> > +	/* This also maps the I/O region and sets isa_io/mem_base */
> > +	pci_process_bridge_OF_ranges(hose, dev, 1);
> > +	pci_setup_phb_io(hose, 1);
> > +
> > +	return 0;
> > +}
> > +
> > +
> > +void __init pas_pcibios_fixup(void)
> > +{
> > +	struct pci_dev *dev = NULL;
> > +
> > +	for_each_pci_dev(dev)
> > +		pci_read_irq_line(dev);
> > +}
> > +
> > +static void __init pas_fixup_phb_resources(void)
> > +{
> > +	struct pci_controller *hose, *tmp;
> > +
> > +	list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> > +		unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
> > +		hose->io_resource.start += offset;
> > +		hose->io_resource.end += offset;
> > +		printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
> > +		       hose->global_number,
> > +		       hose->io_resource.start, hose->io_resource.end);
> > +	}
> > +}
> 
> There is no generic code for the above ? (I have to double check). If
> not, we shall fix that ;)

Didn't see anything, but then I didn't look that long. I'll follow up with a 
separate patch if it doesn't exist, since other platforms can use it too.

>
> > +#ifdef CONFIG_SMP
> > +struct smp_ops_t pas_smp_ops = {
> > +	.probe		= smp_mpic_probe,
> > +	.message_pass	= smp_mpic_message_pass,
> > +	.kick_cpu	= smp_generic_kick_cpu,
> > +	.setup_cpu	= smp_mpic_setup_cpu,
> > +	.give_timebase	= smp_generic_give_timebase,
> > +	.take_timebase	= smp_generic_take_timebase,
> > +};
> 
> You don't have a HW timebase sync facility ? Is this the board or the
> processor doesn't have a pin to freeze the timebase ? Either way, that
> is bad ! Time to use the cluebat !

See comment to Arnd in another email: We have hardware support for it, just 
not including it at this time.

> 
> > +#endif /* CONFIG_SMP */
> > +
> > +void __init pas_setup_arch(void)
> > +{
> > +	/* init to some ~sane value until calibrate_delay() runs */
> > +	loops_per_jiffy = 50000000;
> 
> That value still makes any sense with the new tb based delays ? I know
> we still have it here or there, I'm wondering tho...

I haven't tried doing without it, I'll take a look.


-Olof

^ permalink raw reply

* where can I find MPC8245 assembler reference?
From: Reeve Yang @ 2006-09-05 22:22 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

Could anyone point me to online document for MPC8245 assembler reference? I
couldn't find it anywhere but the command list in user manual. Thanks!

- Reeve

[-- Attachment #2: Type: text/html, Size: 168 bytes --]

^ permalink raw reply

* Re: where can I find MPC8245 assembler reference?
From: Becky Bruce @ 2006-09-05 22:30 UTC (permalink / raw)
  To: Reeve Yang; +Cc: linuxppc-embedded
In-Reply-To: <198592450609051522i572697f8nb252ea58e7f60ae@mail.gmail.com>

MPC8245 refers to the integrated product (core + peripherals, all on  
one chip).  The MPC8245 has a powerpc 603e core (also known as the  
G2).  That's a classic 32-bit powerpc, so the assembler reference you  
want is:

http://www.freescale.com/files/product/doc/MPCFPE32B.pdf

Hope this helps,
Becky


On Sep 5, 2006, at 5:22 PM, Reeve Yang wrote:

> Could anyone point me to online document for MPC8245 assembler  
> reference? I couldn't find it anywhere but the command list in user  
> manual. Thanks!
>
> - Reeve
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: [POWERPC] merge iSeries i/o operations with the rest
From: Stephen Rothwell @ 2006-09-05 23:19 UTC (permalink / raw)
  To: Linas Vepstas; +Cc: ppc-dev, paulus
In-Reply-To: <20060905164146.GA7139@austin.ibm.com>

Hi Linas,

On Tue, 5 Sep 2006 11:41:46 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
>
> On Tue, Sep 05, 2006 at 12:08:17PM +1000, Stephen Rothwell wrote:
> > @@ -273,25 +234,30 @@ #define iobarrier_w()  eieio()
> > + *
> > + * For some of these, we force the target/source register to be
> > + * r0 to ease decoding on iSeries.
> 
> ???
> Why?

Because we were considering runtime patching of the i/o instruction on
iSeries and it seemed it would be simpler.  I have a new patch (coming
soon) the removes the forcing of r0.

> > -	int ret;
> > +	register unsigned int ret __asm__("r0");
> 
> Such as here .. why is this being forced ??

See above.

> > -	__asm__ __volatile__("lbz%U1%X1 %0,%1; twi 0,%0,0; isync"
> > -			     : "=r" (ret) : "m" (*addr));
> > +	__asm__ __volatile__("lbzx %0,0,%1; twi 0,%0,0; isync"
> > +			     : "=r" (ret) : "r" (addr));
> 
> Why make this change? The old code allows the compiler to optimize
> better than the new code.  One might argue that, in the grand scheme of
> things, i/o is very slow, so a few cycles here doesn't matter much.
> But still, I don't understand why this change is needed.

Because the original could produce any of 4 (?) different instructions
that we would have to emulate.   Interestingly the change actually made
my pSeries kernel slightly smaller (though I don't know if it was more or
less efficient).  But I will think a bit more about this.

> > +static inline void memset_io(volatile void __iomem *addr, int c,
> > +                                 unsigned long n)
> > +{
> > +	if (firmware_has_feature(FW_FEATURE_ISERIES))
> > +		iSeries_memset_io(addr, c, n);
> > +	else
> > +		eeh_memset_io(addr, c, n);
> > +}
> 
> !! I think it would be much better to have this be a compile-time
> check rather than a run-time check. No only does it save cycles, 
> but it makes the iSeries kernel smaller (by not needing eeh code 
> in it) and the p-series code smaller (by not compiling iseries
> code into it.

On a kernel built for only iSeries, firmware_has_feature(FW_FEATURE_ISERIES)
evaluates to a compile time 1 so the eeh code is not required as the
compiler elides the call.  Similarly, on a kernel that does not include
iSeries support at all, firmware_has_feature(FW_FEATURE_ISERIES)
evaluates to a compiler time 0, so the iSeries code is not required. The
only time this is a run time check is if you compile a MULTIPLATFORM
kernel incluing iSeries support (which is currently impossible but is
what we are aiming for as a possibility).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

^ permalink raw reply

* [patch 3/5] [v2] powerpc: PA6T cputable entry, PVR value
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

Introduce PWRficient PA6T cputable entries and feature bits.


Signed-off-by: Olof Johansson <olof@lixom.net>

Index: merge/arch/powerpc/kernel/cputable.c
===================================================================
--- merge.orig/arch/powerpc/kernel/cputable.c
+++ merge/arch/powerpc/kernel/cputable.c
@@ -58,6 +58,9 @@ extern void __restore_cpu_ppc970(void);
 #define COMMON_USER_POWER6	(COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
 				 PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
 				 PPC_FEATURE_TRUE_LE)
+#define COMMON_USER_PA6T	(COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
+				 PPC_FEATURE_TRUE_LE | \
+				 PPC_FEATURE_HAS_ALTIVEC_COMP)
 #define COMMON_USER_BOOKE	(PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU | \
 				 PPC_FEATURE_BOOKE)
 
@@ -286,6 +289,17 @@ struct cpu_spec	cpu_specs[] = {
 		.dcache_bsize		= 128,
 		.platform		= "ppc-cell-be",
 	},
+	{	/* PA Semi PA6T */
+		.pvr_mask		= 0x7fff0000,
+		.pvr_value		= 0x00900000,
+		.cpu_name		= "PA6T",
+		.cpu_features		= CPU_FTRS_PA6T,
+		.cpu_user_features	= COMMON_USER_PA6T,
+		.icache_bsize		= 64,
+		.dcache_bsize		= 64,
+		.num_pmcs		= 6,
+		.platform		= "pa6t",
+	},
 	{	/* default match */
 		.pvr_mask		= 0x00000000,
 		.pvr_value		= 0x00000000,
Index: merge/include/asm-powerpc/reg.h
===================================================================
--- merge.orig/include/asm-powerpc/reg.h
+++ merge/include/asm-powerpc/reg.h
@@ -592,6 +592,7 @@
 #define PV_630p	0x0041
 #define PV_970MP	0x0044
 #define PV_BE		0x0070
+#define PV_PA6T		0x0090
 
 /*
  * Number of entries in the SLB. If this ever changes we should handle
Index: merge/include/asm-powerpc/cputable.h
===================================================================
--- merge.orig/include/asm-powerpc/cputable.h
+++ merge/include/asm-powerpc/cputable.h
@@ -23,6 +23,7 @@
 #define PPC_FEATURE_SMT			0x00004000
 #define PPC_FEATURE_ICACHE_SNOOP	0x00002000
 #define PPC_FEATURE_ARCH_2_05		0x00001000
+#define PPC_FEATURE_PA6T		0x00000800
 
 #define PPC_FEATURE_TRUE_LE		0x00000002
 #define PPC_FEATURE_PPC_LE		0x00000001
@@ -332,6 +333,10 @@ extern void do_cpu_ftr_fixups(unsigned l
 	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
+#define CPU_FTRS_PA6T (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_CI_LARGE_PAGE | \
+	    CPU_FTR_PURR | CPU_FTR_REAL_LE)
 #define CPU_FTRS_COMPATIBLE	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
 	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2)
 #endif
@@ -340,7 +345,7 @@ extern void do_cpu_ftr_fixups(unsigned l
 #define CPU_FTRS_POSSIBLE	\
 	    (CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |	\
 	    CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 |	\
-	    CPU_FTRS_CELL | CPU_FTR_CI_LARGE_PAGE)
+	    CPU_FTRS_CELL | CPU_FTRS_PA6T)
 #else
 enum {
 	CPU_FTRS_POSSIBLE =
@@ -379,7 +384,7 @@ enum {
 #define CPU_FTRS_ALWAYS		\
 	    (CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 &	\
 	    CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 &	\
-	    CPU_FTRS_CELL & CPU_FTRS_POSSIBLE)
+	    CPU_FTRS_CELL & CPU_FTRS_PA6T & CPU_FTRS_POSSIBLE)
 #else
 enum {
 	CPU_FTRS_ALWAYS =

^ permalink raw reply

* [patch 4/5] [v2] powerpc: PA Semi PWRficient platform support
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

Base patch for PA6T and PA6T-1682M. This introduces the
arch/powerpc/platform/pasemi directory, together with basic
implementations for various setup.

Much of this was based on other platform code, i.e. Maple, etc.

Signed-off-by: Olof Johansson <olof@lixom.net>


Index: merge/arch/powerpc/Kconfig
===================================================================
--- merge.orig/arch/powerpc/Kconfig
+++ merge/arch/powerpc/Kconfig
@@ -413,6 +413,17 @@ config PPC_MAPLE
           This option enables support for the Maple 970FX Evaluation Board.
 	  For more informations, refer to <http://www.970eval.com>
 
+config PPC_PASEMI
+	depends on PPC_MULTIPLATFORM && PPC64
+	bool "PA Semi SoC-based platforms"
+	default n
+	select MPIC
+	select PPC_UDBG_16550
+	select GENERIC_TBSYNC
+	help
+	  This option enables support for PA Semi's PWRficient line
+	  of SoC processors, including PA6T-1682M
+
 config PPC_CELL
 	bool
 	default n
Index: merge/arch/powerpc/platforms/Makefile
===================================================================
--- merge.orig/arch/powerpc/platforms/Makefile
+++ merge/arch/powerpc/platforms/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_PPC_86xx)		+= 86xx/
 obj-$(CONFIG_PPC_PSERIES)	+= pseries/
 obj-$(CONFIG_PPC_ISERIES)	+= iseries/
 obj-$(CONFIG_PPC_MAPLE)		+= maple/
+obj-$(CONFIG_PPC_PASEMI)		+= pasemi/
 obj-$(CONFIG_PPC_CELL)		+= cell/
 obj-$(CONFIG_EMBEDDED6xx)	+= embedded6xx/
Index: merge/arch/powerpc/platforms/pasemi/Makefile
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/Makefile
@@ -0,0 +1 @@
+obj-y	+= setup.o pci.o time.o
Index: merge/arch/powerpc/platforms/pasemi/pci.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/pci.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Authors: Kip Walker, PA Semi
+ *	    Olof Johansson, PA Semi
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on arch/powerpc/platforms/maple/pci.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+
+#include <asm/pci-bridge.h>
+#include <asm/machdep.h>
+
+#include <asm/ppc-pci.h>
+
+#define PA_PXP_CFA(bus, devfn, off) (((bus) << 20) | ((devfn) << 12) | (off))
+
+#define CONFIG_OFFSET_VALID(off) ((off) < 4096)
+
+static unsigned long pa_pxp_cfg_addr(struct pci_controller *hose,
+				       u8 bus, u8 devfn, int offset)
+{
+	return ((unsigned long)hose->cfg_data) + PA_PXP_CFA(bus, devfn, offset);
+}
+
+static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
+			      int offset, int len, u32 *val)
+{
+	struct pci_controller *hose;
+	unsigned long addr;
+
+	hose = pci_bus_to_host(bus);
+	if (!hose)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!CONFIG_OFFSET_VALID(offset))
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
+
+	/*
+	 * Note: the caller has already checked that offset is
+	 * suitably aligned and that len is 1, 2 or 4.
+	 */
+	switch (len) {
+	case 1:
+		*val = in_8((u8 *)addr);
+		break;
+	case 2:
+		*val = in_le16((u16 *)addr);
+		break;
+	default:
+		*val = in_le32((u32 *)addr);
+		break;
+	}
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int pa_pxp_write_config(struct pci_bus *bus, unsigned int devfn,
+			       int offset, int len, u32 val)
+{
+	struct pci_controller *hose;
+	unsigned long addr;
+
+	hose = pci_bus_to_host(bus);
+	if (!hose)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!CONFIG_OFFSET_VALID(offset))
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
+
+	/*
+	 * Note: the caller has already checked that offset is
+	 * suitably aligned and that len is 1, 2 or 4.
+	 */
+	switch (len) {
+	case 1:
+		out_8((u8 *)addr, val);
+		(void) in_8((u8 *)addr);
+		break;
+	case 2:
+		out_le16((u16 *)addr, val);
+		(void) in_le16((u16 *)addr);
+		break;
+	default:
+		out_le32((u32 *)addr, val);
+		(void) in_le32((u32 *)addr);
+		break;
+	}
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops pa_pxp_ops = {
+	pa_pxp_read_config,
+	pa_pxp_write_config,
+};
+
+static void __init setup_pa_pxp(struct pci_controller *hose)
+{
+	hose->ops = &pa_pxp_ops;
+	hose->cfg_data = ioremap(0xe0000000, 0x1000000);
+}
+
+static int __init add_bridge(struct device_node *dev)
+{
+	int len;
+	struct pci_controller *hose;
+	const int *bus_range;
+
+	pr_debug("Adding PCI host bridge %s\n", dev->full_name);
+
+	bus_range = get_property(dev, "bus-range", &len);
+	if (!bus_range || len < 2 * sizeof(int)) {
+		printk(KERN_WARNING "Can't get bus-range for %s, assume bus 0\n",
+		dev->full_name);
+	}
+
+	hose = pcibios_alloc_controller(dev);
+	if (!hose)
+		return -ENOMEM;
+
+	hose->first_busno = bus_range ? bus_range[0] : 0;
+	hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+	setup_pa_pxp(hose);
+
+	printk(KERN_INFO "Found PA-PXP PCI host bridge. "
+		       "Firmware bus number: %d->%d\n",
+		hose->first_busno, hose->last_busno);
+
+	/* Interpret the "ranges" property */
+	/* This also maps the I/O region and sets isa_io/mem_base */
+	pci_process_bridge_OF_ranges(hose, dev, 1);
+	pci_setup_phb_io(hose, 1);
+
+	return 0;
+}
+
+
+void __init pas_pcibios_fixup(void)
+{
+	struct pci_dev *dev = NULL;
+
+	for_each_pci_dev(dev)
+		pci_read_irq_line(dev);
+}
+
+static void __init pas_fixup_phb_resources(void)
+{
+	struct pci_controller *hose, *tmp;
+
+	list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
+		unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
+		hose->io_resource.start += offset;
+		hose->io_resource.end += offset;
+		printk(KERN_INFO "PCI Host %d, io start: %lx; io end: %lx\n",
+		       hose->global_number,
+		       hose->io_resource.start, hose->io_resource.end);
+	}
+}
+
+
+void __init pas_pci_init(void)
+{
+	struct device_node *np, *root;
+
+	root = of_find_node_by_path("/");
+	if (!root) {
+		printk(KERN_CRIT "pas_pci_init: can't find root "
+			"of device tree\n");
+		return;
+	}
+
+	for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
+		if (np->name && !strcmp(np->name, "pxp") && !add_bridge(np))
+			of_node_get(np);
+
+	of_node_put(root);
+
+	pas_fixup_phb_resources();
+
+	/* Setup the linkage between OF nodes and PHBs */
+	pci_devs_phb_init();
+
+	/* Use the common resource allocation mechanism */
+	pci_probe_only = 1;
+}
Index: merge/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/setup.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Authors: Kip Walker, PA Semi
+ *	    Olof Johansson, PA Semi
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * Based on arch/powerpc/platforms/maple/setup.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <linux/config.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/console.h>
+
+#include <asm/prom.h>
+#include <asm/system.h>
+#include <asm/iommu.h>
+#include <asm/machdep.h>
+#include <asm/mpic.h>
+#include <asm/smp.h>
+#include <asm/time.h>
+
+#include "pasemi.h"
+
+static void pas_restart(char *cmd)
+{
+	printk("restart unimplemented, looping...\n");
+	for (;;) ;
+}
+
+static void pas_power_off(void)
+{
+	printk("power off unimplemented, looping...\n");
+	for (;;) ;
+}
+
+static void pas_halt(void)
+{
+	pas_power_off();
+}
+
+#ifdef CONFIG_SMP
+struct smp_ops_t pas_smp_ops = {
+	.probe		= smp_mpic_probe,
+	.message_pass	= smp_mpic_message_pass,
+	.kick_cpu	= smp_generic_kick_cpu,
+	.setup_cpu	= smp_mpic_setup_cpu,
+	.give_timebase	= smp_generic_give_timebase,
+	.take_timebase	= smp_generic_take_timebase,
+};
+#endif /* CONFIG_SMP */
+
+void __init pas_setup_arch(void)
+{
+#ifdef CONFIG_SMP
+	/* Setup SMP callback */
+	smp_ops = &pas_smp_ops;
+#endif
+	/* Lookup PCI hosts */
+	pas_pci_init();
+
+#ifdef CONFIG_DUMMY_CONSOLE
+	conswitchp = &dummy_con;
+#endif
+
+	printk(KERN_DEBUG "Using default idle loop\n");
+}
+
+static void iommu_dev_setup_null(struct pci_dev *dev) { }
+static void iommu_bus_setup_null(struct pci_bus *bus) { }
+
+static void __init pas_init_early(void)
+{
+	/* No iommu code yet */
+	ppc_md.iommu_dev_setup = iommu_dev_setup_null;
+	ppc_md.iommu_bus_setup = iommu_bus_setup_null;
+	pci_direct_iommu_init();
+}
+
+/* No legacy IO on our parts */
+static int pas_check_legacy_ioport(unsigned int baseport)
+{
+	return -ENODEV;
+}
+
+static __init void pas_init_IRQ(void)
+{
+	struct device_node *np;
+	struct device_node *root, *mpic_node;
+	unsigned long openpic_addr;
+	const unsigned int *opprop;
+	int naddr, opplen;
+	struct mpic *mpic;
+
+	np = of_find_node_by_type(NULL, "open-pic");
+	if (!np) {
+		printk(KERN_ERR "No interrupt controller in device tree.\n");
+		return;
+	}
+	mpic_node = of_node_get(np);
+
+	/* Find address list in /platform-open-pic */
+	root = of_find_node_by_path("/");
+	naddr = prom_n_addr_cells(root);
+	opprop = get_property(root, "platform-open-pic", &opplen);
+	if (!opprop) {
+		printk(KERN_ERR "No platform-open-pic property.\n");
+		of_node_put(root);
+		return;
+	}
+	openpic_addr = of_read_number(opprop, naddr);
+	printk(KERN_DEBUG "OpenPIC addr: %lx\n", openpic_addr);
+	of_node_put(root);
+
+	mpic = mpic_alloc(mpic_node, openpic_addr, MPIC_PRIMARY, 0, 0,
+			  " PAS-OPIC  ");
+	BUG_ON(!mpic);
+
+	mpic_assign_isu(mpic, 0, openpic_addr + 0x10000);
+	mpic_init(mpic);
+	of_node_put(mpic_node);
+	of_node_put(root);
+}
+
+static void __init pas_progress(char *s, unsigned short hex)
+{
+	printk("[%04x] : %s\n", hex, s ? s : "");
+}
+
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init pas_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	if (!of_flat_dt_is_compatible(root, "PA6T-1682M"))
+		return 0;
+
+	hpte_init_native();
+
+	return 1;
+}
+
+define_machine(pas) {
+	.name			= "PA Semi PA6T-1682M",
+	.probe			= pas_probe,
+	.setup_arch		= pas_setup_arch,
+	.init_early		= pas_init_early,
+	.init_IRQ		= pas_init_IRQ,
+	.get_irq		= mpic_get_irq,
+	.pcibios_fixup		= pas_pcibios_fixup,
+	.restart		= pas_restart,
+	.power_off		= pas_power_off,
+	.halt			= pas_halt,
+	.get_boot_time		= pas_get_boot_time,
+	.calibrate_decr		= generic_calibrate_decr,
+	.check_legacy_ioport    = pas_check_legacy_ioport,
+	.progress		= pas_progress,
+};
Index: merge/arch/powerpc/platforms/pasemi/time.c
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/time.c
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2006 PA Semi, Inc
+ *
+ * Maintained by: Olof Johansson <olof@lixom.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <linux/config.h>
+#include <linux/time.h>
+
+#include <asm/time.h>
+
+unsigned long __init pas_get_boot_time(void)
+{
+	/* Let's just return a fake date right now */
+	return mktime(2006, 1, 1, 12, 0, 0);
+}
Index: merge/arch/powerpc/platforms/pasemi/pasemi.h
===================================================================
--- /dev/null
+++ merge/arch/powerpc/platforms/pasemi/pasemi.h
@@ -0,0 +1,8 @@
+#ifndef _PASEMI_PASEMI_H
+#define _PASEMI_PASEMI_H
+
+extern unsigned long pas_get_boot_time(void);
+extern void pas_pci_init(void);
+extern void pas_pcibios_fixup(void);
+
+#endif /* _PASEMI_PASEMI_H */

^ permalink raw reply

* [patch 5/5] [v2] powerpc: PA Semi PWRficient MAINTAINER entry
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

Maintainer entry for PWRficient

Signed-off-by: Olof Johansson <olof@lixom.net>

Index: merge/MAINTAINERS
===================================================================
--- merge.orig/MAINTAINERS
+++ merge/MAINTAINERS
@@ -1783,6 +1783,13 @@ W:     http://www.penguinppc.org/
 L:     linuxppc-embedded@ozlabs.org
 S:     Maintained
 
+LINUX FOR POWERPC PA SEMI PWRFICIENT
+P:	Olof Johansson
+M:	olof@lixom.net
+W:	http://www.pasemi.com/
+L:	linuxppc-dev@ozlabs.org
+S:	Supported
+
 LLC (802.2)
 P:	Arnaldo Carvalho de Melo
 M:	acme@conectiva.com.br

^ permalink raw reply

* [patch 0/5] [v2] powerpc: PA Semi PWRficient patches
From: Olof Johansson @ 2006-09-05 23:43 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev

Hi,

The following series of patches introduces basic support for PA Semi's
PA6T core, and the base platform support for PWRficient PA6T-1682M.

It is split up in 5 separate patches:

1. Reduce default cacheline size to 64 bytes
2. Divorce CPU_FTR_CTRL from CPU_FTR_PPCAS_ARCH_V2_BASE
3. Cpu table entry, PVR value
4. Basic arch/powerpc/platforms/pasemi contents
5. MAINTAINER entry


Changes since last submission:

* Include file cleanup (Roland)
* Whitespace/line length fixes (Mikey, Joel)
* Kill linux,pci-domain stuff (Ben)
* Remove loops_per_jiffy default (Ben)
* Enforce PCI-e config space addressing (Ben)
* Whitespace, init, cast fixes (Arnd)
* Prototypes -> pasemi.h (Arnd)
* Kill some of the RTC stubs (Arnd)


-Olof

^ permalink raw reply

* [patch 1/5] [v2] powerpc: Reduce default cacheline size to 64 bytes
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

Reduce default cacheline size on 64-bit powerpc from 128 bytes to 64.
This is the architected minimum. In most cases we'll still end up using
cache line information from the device tree, but defaults are used during
early boot and doing a few dcbst/icbi's too many there won't do any harm.


Signed-off-by: Olof Johansson <olof@lixom.net>


Index: merge/arch/powerpc/kernel/setup_64.c
===================================================================
--- merge.orig/arch/powerpc/kernel/setup_64.c
+++ merge/arch/powerpc/kernel/setup_64.c
@@ -78,10 +78,10 @@ u64 ppc64_pft_size;
  * before we've read this from the device tree.
  */
 struct ppc64_caches ppc64_caches = {
-	.dline_size = 0x80,
-	.log_dline_size = 7,
-	.iline_size = 0x80,
-	.log_iline_size = 7
+	.dline_size = 0x40,
+	.log_dline_size = 6,
+	.iline_size = 0x40,
+	.log_iline_size = 6
 };
 EXPORT_SYMBOL_GPL(ppc64_caches);
 
Index: merge/arch/powerpc/kernel/head_64.S
===================================================================
--- merge.orig/arch/powerpc/kernel/head_64.S
+++ merge/arch/powerpc/kernel/head_64.S
@@ -1748,7 +1748,7 @@ _STATIC(__after_prom_start)
 _GLOBAL(copy_and_flush)
 	addi	r5,r5,-8
 	addi	r6,r6,-8
-4:	li	r0,16			/* Use the least common		*/
+4:	li	r0,8			/* Use the smallest common	*/
 					/* denominator cache line	*/
 					/* size.  This results in	*/
 					/* extra cache line flushes	*/

^ permalink raw reply

* [patch 2/5] [v2] powerpc: Divorce CPU_FTR_CTRL from CPU_FTR_PPCAS_ARCH_V2_BASE
From: Olof Johansson @ 2006-09-05 23:47 UTC (permalink / raw)
  To: paulus, anton; +Cc: linuxppc-dev
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

The performance monitor implementation (including CTRL register behaviour)
is just included in PPC v2 as an example, it's not truly part of the base.

It's actually a somewhat misleading feature, but I'll leave that be for
now: The precense of the register is not what the feature bit is used
for, but instead it's used to determine if it contains the runlatch
bit for idle reporting of the performance monitor. For alternative
implementations, the register might still exist but the bit might have
different meaning (or no meaning at all).

For now, split it off and don't include it in CPU_FTR_PPCAS_ARCH_V2_BASE.


Signed-off-by: Olof Johansson <olof@lixom.net>

Index: merge/include/asm-powerpc/cputable.h
===================================================================
--- merge.orig/include/asm-powerpc/cputable.h
+++ merge/include/asm-powerpc/cputable.h
@@ -148,7 +148,7 @@ extern void do_cpu_ftr_fixups(unsigned l
 
 #define CPU_FTR_PPCAS_ARCH_V2_BASE (CPU_FTR_SLB | \
 					CPU_FTR_TLBIEL | CPU_FTR_NOEXECUTE | \
-					CPU_FTR_NODSISRALIGN | CPU_FTR_CTRL)
+					CPU_FTR_NODSISRALIGN)
 
 /* iSeries doesn't support large pages */
 #ifdef CONFIG_PPC_ISERIES
@@ -313,24 +313,25 @@ extern void do_cpu_ftr_fixups(unsigned l
 	    CPU_FTR_HPTE_TABLE | CPU_FTR_IABR | \
 	    CPU_FTR_MMCRA | CPU_FTR_CTRL)
 #define CPU_FTRS_POWER4	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
-	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_MMCRA)
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
+	    CPU_FTR_MMCRA)
 #define CPU_FTRS_PPC970	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
-	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA)
 #define CPU_FTRS_POWER5	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
-	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
 	    CPU_FTR_PURR)
 #define CPU_FTRS_POWER6 (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
-	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_MMCRA | CPU_FTR_SMT | \
 	    CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
 	    CPU_FTR_PURR | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_REAL_LE)
 #define CPU_FTRS_CELL	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
-	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | \
+	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
 	    CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
-	    CPU_FTR_CTRL | CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
+	    CPU_FTR_PAUSE_ZERO | CPU_FTR_CI_LARGE_PAGE)
 #define CPU_FTRS_COMPATIBLE	(CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
 	    CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2)
 #endif

^ permalink raw reply

* Re: MPC8245 reset register
From: Jon Scully @ 2006-09-06  0:06 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <198592450609051149h47423ebev9c94eb8aefc2a3fb@mail.gmail.com>

On 9/5/06, Reeve Yang <yang.reeve@gmail.com> wrote:
>  I'm kind of curious what's the proper way to reset the
> 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.

You could starve the watchdog (assuming SWE=1 in SYPCR).  If you own
the hardware design, you could add an addressable WO latch (FPGA) that
asserts reset for the right number of clock cycles (what I would
normally provide or ask for in a design -- but *only* during
development).  Otherwise... If this is for development purposes,
consider using JTAG (Boundary Scan) to control /SRESET.

(My reference to RST was supposed to be humorous -- as in, remember
the good old days when you could do that in S/W?! ('RST 7' in Z80 &
8085)  Sorry for my bad humor.)

^ permalink raw reply

* Re: [patch 0/5] [v2] powerpc: PA Semi PWRficient patches
From: Michael Ellerman @ 2006-09-06  0:17 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060905184316.4c1a460b@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Tue, 2006-09-05 at 18:43 -0500, Olof Johansson wrote:
> Hi,
> 
> The following series of patches introduces basic support for PA Semi's
> PA6T core, and the base platform support for PWRficient PA6T-1682M.

I have a spare 'o' and 'e' over here if you want 'em?

;)

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

^ permalink raw reply

* [PATCH] kdump : Support kernels having 64k page size.
From: Sachin P. Sant @ 2006-09-06  0:26 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: fastboot-bounces

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

The following  kernel patch [ along with a patch to kexec tools posted 
seperately ]
is required to generate proper core files using kdump on ppc64.

Thanks
-Sachin



[-- Attachment #2: ppc64-kexec-tools-64k-page-support --]
[-- Type: text/plain, Size: 663 bytes --]

* Generate proper core files using kdump on ppc64 with 64k page support.

Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---

diff -Naurp a/include/asm-powerpc/kdump.h b/include/asm-powerpc/kdump.h
--- a/include/asm-powerpc/kdump.h	2006-08-31 03:01:13.000000000 +0530
+++ b/include/asm-powerpc/kdump.h	2006-08-31 05:49:13.000000000 +0530
@@ -7,7 +7,7 @@
 /* How many bytes to reserve at zero for kdump. The reserve limit should
  * be greater or equal to the trampoline's end address.
  * Reserve to the end of the FWNMI area, see head_64.S */
-#define KDUMP_RESERVE_LIMIT	0x8000
+#define KDUMP_RESERVE_LIMIT	max(0x8000, PAGE_SIZE)
 
 #ifdef CONFIG_CRASH_DUMP
 

^ permalink raw reply

* Re: On the transfer of data from the uart.c driver to the tty layer...
From: Benjamin Herrenschmidt @ 2006-09-06  0:45 UTC (permalink / raw)
  To: Alejandro C; +Cc: linuxppc-dev
In-Reply-To: <BAY121-F225DA006048FC317F8E97BDB300@phx.gbl>

On Tue, 2006-09-05 at 14:56 +0000, Alejandro C wrote:
> Hi all,
> 
> I'm working on a the uart.c driver to add support for SCCs in HDLC mode. The 
> application I'm going to run on top will be sending Ethernet packets 
> encapsulated in the data field of an HDLC frame. The idea was to make the 
> buffer big enough so that a whole Eth. packet (max 1518 octects) could fit 
> in just one buffer. I let the CPM interrupt on a frame basis and the problem 
> I've come across is that the receive buffer in the struct tty_struct, where 
> the tty layer collects the data from the driver 
> (tty_struct.tty_flip_buffer.char_buf), is only 1024 bytes 
> (2*TTY_FLIPBUF_SIZE). The easiest at this stage would be to make those 
> buffers larger, but I don't know what sort of impact this might have... Any 
> tips?
> Any ideas on how to solve it in another fashion?
> 
> Help will be highly appreciated.

You should ask on the linux-kernel mailing list, possibly CC'ing Alan
Cox who seem to have put his hands a lot in the TTY code lately.

Ben.

^ permalink raw reply

* Re: MPC8245 reset register
From: Reeve Yang @ 2006-09-06  0:50 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <53107f6e0609051706i67eac762y114ad03bf2065548@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

LoL, my bad not understanding the humor.

This becomes an interesting topic. I looked at different CPUs, it seems
everyone uses different method to reset itself, and there is no uniformed or
easy for 603e. I searched on google but didn't see anyone have similiar
concern. Actually lots of boxes/systems using MPC8245, why nobody cares
about it? :)

To use watchdog timeout, or gpio port to assert reset line on CPU are not
flexible enough. If using watchdog, I have to enable watchdog and reduce the
timeout length (if it's too long). If using some GPIO device, I'll have to
rely on i2c bus or whatever io interface to write data. Acutally our system
has RESET by a GPIO(PCA9556) port.

Interesting enough, I resolved the problem by writing a data to an invalid
address with hoping for a machine check exception (in fact this is what
u-boot does). Would it be good to make it as a stardard "restart" function
in mpc10x_common.c? If it's acceptable I could send out my patch.

- Reeve

On 9/6/06, Jon Scully <jonscully@gmail.com> wrote:
>
> On 9/5/06, Reeve Yang <yang.reeve@gmail.com> wrote:
> >  I'm kind of curious what's the proper way to reset the
> > 8245 CPU? For anyone who doesn't know MPC8245, which is 603e core.
>
> You could starve the watchdog (assuming SWE=1 in SYPCR).  If you own
> the hardware design, you could add an addressable WO latch (FPGA) that
> asserts reset for the right number of clock cycles (what I would
> normally provide or ask for in a design -- but *only* during
> development).  Otherwise... If this is for development purposes,
> consider using JTAG (Boundary Scan) to control /SRESET.
>
> (My reference to RST was supposed to be humorous -- as in, remember
> the good old days when you could do that in S/W?! ('RST 7' in Z80 &
> 8085)  Sorry for my bad humor.)
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

[-- Attachment #2: Type: text/html, Size: 2526 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox