linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* AGPGART driver for ArticiaS - ioremap() problem
@ 2006-01-11 21:00 Gerhard Pircher
  2006-01-11 21:52 ` John W. Linville
  2006-01-12  4:44 ` Benjamin Herrenschmidt
  0 siblings, 2 replies; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-11 21:00 UTC (permalink / raw)
  To: linuxppc-dev, debian-powerpc

Hi,

David Bentam and I are trying to get a AGPGART driver working for the
AmigaOne and the Pegasos1. The driver detects the aperture size of the
ArticiaS AGP bridge, but fails at the ioremap() function in the generic GATT
table create function. Does the PowerPC platform behaves differently for the
mapping of address location for AGP operation than the x86 platform? Is it
possible to use a mask to relocate the AGP address space to a specific
location?

regards,

Gerhard Pircher

-- 
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-11 21:00 AGPGART driver for ArticiaS - ioremap() problem Gerhard Pircher
@ 2006-01-11 21:52 ` John W. Linville
  2006-01-11 22:18   ` Gerhard Pircher
  2006-01-12  4:44 ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 26+ messages in thread
From: John W. Linville @ 2006-01-11 21:52 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Wed, Jan 11, 2006 at 10:00:32PM +0100, Gerhard Pircher wrote:

> David Bentam and I are trying to get a AGPGART driver working for the
> AmigaOne and the Pegasos1. The driver detects the aperture size of the
> ArticiaS AGP bridge, but fails at the ioremap() function in the generic GATT
> table create function. Does the PowerPC platform behaves differently for the
> mapping of address location for AGP operation than the x86 platform? Is it
> possible to use a mask to relocate the AGP address space to a specific
> location?

It probably wouldn't hurt to include the source (or a url pointing
to it)... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-11 21:52 ` John W. Linville
@ 2006-01-11 22:18   ` Gerhard Pircher
  0 siblings, 0 replies; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-11 22:18 UTC (permalink / raw)
  To: John W. Linville; +Cc: linuxppc-dev, debian-powerpc

Hi,

> --- Ursprüngliche Nachricht ---
> Von: "John W. Linville" <linville@tuxdriver.com>
> An: Gerhard Pircher <gerhard_stamer@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Wed, 11 Jan 2006 16:52:21 -0500
> 
> It probably wouldn't hurt to include the source (or a url pointing
> to it)... :-)

Probably not, so here is it: ;-)

####### START ########

/*
 * ArticiaS AGPGART routines.
 */

#include <linux/types.h>
#include <linux/module.h>
#include <linux/pagemap.h>
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <linux/init.h>
#include <linux/agp_backend.h>
#include "agp.h"

static struct pci_device_id agp_articias_pci_table[];

#define ARTICIAS_DEBUG

//#define ARTICIAS_FROMUNINORTH

#define ARTICIAS_AGP_EN		0x49	/* bit 0 -> AGP enable */
#define ARTICIAS_GART_EN	0x58	/* bit 6 -> GART enable */
#define ARTICIAS_APSIZE		0x59	/* bits 2:0 set size */
#define ARTICIAS_APBASE		0x59	/* TLB address Base [31:12]*/
#define ARTICIAS_GATTBASE	0x10	/* GART base address register */
#define ARTICIAS_TLB_BASE	0x5A	/* bits 16:31 of TLB base address #define
ARTICIAS_GATT_MASK	0xF0000000
#define ARTICIAS_SIZE_MASK	0x07	/* Mask aperture size bits. */

static int articias_fetch_size(void)
{
	int i;
	u8 temp;
	struct aper_size_info_8 *values;

	values = A_SIZE_8(agp_bridge->driver->aperture_sizes);
	pci_read_config_byte(agp_bridge->dev, ARTICIAS_APSIZE, &temp);

#ifdef ARTICIAS_DEBUG	
	printk(KERN_INFO PFX "[ARTICIAS] articias_fetch_size()\n");
	printk(KERN_INFO PFX "[ARTICIAS] * non masked temp = 0x%x\n", temp);
#endif

	/* Mask the GART/Aperture size selection bits. */
	temp = temp & ARTICIAS_SIZE_MASK;

	for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {

#ifdef ARTICIAS_DEBUG
	void *temp2;

	printk(KERN_INFO PFX "[ARTICIAS] * aperature size loop index #%d\n", i);
	printk(KERN_INFO PFX "[ARTICIAS] * values[%d].size_value = %x\n", i, (u32)
values[i].size_value);
#endif
		if (temp == values[i].size_value) {
			agp_bridge->previous_size =
			    agp_bridge->current_size = (void *) (values + i);
			agp_bridge->aperture_size_idx = i;

#ifdef ARTICIAS_DEBUG
			temp2 = agp_bridge->current_size;

			printk(KERN_INFO PFX "[ARTICIAS] * masked temp = 0x%x\n", temp);
			printk(KERN_INFO PFX "[ARTICIAS] * values[%d].size = %d\n", i,
values[i].size);
			printk(KERN_INFO PFX "[ARTICIAS] * current_size->size = %d\n",
A_SIZE_8(temp2)->size);
			printk(KERN_INFO PFX "[ARTICIAS] * current_size->page_order = %d\n",
A_SIZE_8(temp2)->page_order);
			printk(KERN_INFO PFX "[ARTICIAS] * current_size->num_entries = %d\n",
A_SIZE_8(temp2)->num_entries);
			printk(KERN_INFO PFX "[ARTICIAS] * current_size->size_value = %d\n",
A_SIZE_8(temp2)->size_value);
#endif
			return values[i].size;
		}
	}

#ifdef ARTICIAS_FROMUNINORTH
	agp_bridge->previous_size =
	    agp_bridge->current_size = (void *) (values + 1);
	agp_bridge->aperture_size_idx = 1;
	return values[1].size;
#endif

	printk(KERN_ERR PFX "Unknown aperture size from AGP bridge (0x%x)\n",
temp);

	return 0;
}

static int articias_configure(void)
{
	u32 temp = 0;
	u16 shift16 = 0;
	u8 shift8 = 0;
	struct aper_size_info_8 *current_size;

#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] articias_configure()\n");
#endif

	/* Get current aperture size */
	current_size = A_SIZE_8(agp_bridge->current_size);

        printk(KERN_INFO PFX "configuring for size idx: %d\n",
	       current_size->size_value);

	temp = (u32) agp_bridge->gatt_table_real;
	/* Get upper word from dword. */
	shift16 = (u16) (temp>>16);

#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] * temp = 0x%x, shift16 = 0x%x\n", temp,
shift16);
#endif

	pci_write_config_word(agp_bridge->dev, ARTICIAS_TLB_BASE, shift16);
	/* Get the byte 1 from dword and mask it out with the aperture size. */
	shift8 = (u8) (temp>>8);
	shift8 &= ~(ARTICIAS_SIZE_MASK);
	shift8 |= current_size->size_value;
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_APBASE, shift8);

#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] * temp = 0x%x, shift8 = 0x%x\n", temp,
shift8);
#endif

	/* Get address to map too */
	pci_read_config_dword(agp_bridge->dev, ARTICIAS_GATTBASE, (void *)&temp);
	temp = temp & ARTICIAS_GATT_MASK;

	agp_bridge->gart_bus_addr = temp;

	/* GART control register */
	/* Enable GART and bus concurrency */
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, 0x41);
	/* Enable AGP operation */
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_AGP_EN, 0x01);

	return 0;
}

#ifdef ARTICIAS_FROMUNINORTH

/* Taken from the Uninorth driver (START). */
static int articias_insert_memory(struct agp_memory *mem, off_t pg_start,
int type)
{
	int i, j, num_entries;
	void *temp;

	temp = agp_bridge->current_size;
	num_entries = A_SIZE_8(temp)->num_entries;

	if (type != 0 || mem->type != 0)
		/* We know nothing of memory types */
		return -EINVAL;
	if ((pg_start + mem->page_count) > num_entries)
		return -EINVAL;

	j = pg_start;

	while (j < (pg_start + mem->page_count)) {
		if (!PGE_EMPTY(agp_bridge, agp_bridge->gatt_table[j]))
			return -EBUSY;
		j++;
	}

	for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
		agp_bridge->gatt_table[j] = cpu_to_le32((mem->memory[i] & 0xfe000000) |
0x00000001UL);
		flush_dcache_range((unsigned long)__va(mem->memory[i]),
				   (unsigned long)__va(mem->memory[i])+0x1000);
	}
	(void)in_le32((volatile u32*)&agp_bridge->gatt_table[pg_start]);
	mb();
	flush_dcache_range((unsigned long)&agp_bridge->gatt_table[pg_start], 
		(unsigned long)&agp_bridge->gatt_table[pg_start + mem->page_count]);

	/* Geri: We should perform a TLB flush too!. */
	//articias_tlbflush(mem);

	return 0;
}

/* Taken from the Uninorth driver */
static int articias_create_gatt_table(void)
{
	char *table;
	char *table_end;
	int size;
	int page_order;
	int num_entries;
	int i;
	void *temp;
	struct page *page;

	/* We can't handle 2 level gatt's */
	if (agp_bridge->driver->size_type == LVL2_APER_SIZE)
		return -EINVAL;

	table = NULL;
	i = agp_bridge->aperture_size_idx;
	temp = agp_bridge->current_size;
	size = page_order = num_entries = 0;

	do {
		size = A_SIZE_8(temp)->size;
		page_order = A_SIZE_8(temp)->page_order;
		num_entries = A_SIZE_8(temp)->num_entries;

		table = (char *) __get_free_pages(GFP_KERNEL, page_order);

		if (table == NULL) {
			i++;
			agp_bridge->current_size = A_IDX8(agp_bridge);
		} else {
			agp_bridge->aperture_size_idx = i;
		}
	} while (!table && (i < agp_bridge->driver->num_aperture_sizes));

	if (table == NULL)
		return -ENOMEM;

	table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);

	for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
		SetPageReserved(page);

	agp_bridge->gatt_table_real = (u32 *) table;
	agp_bridge->gatt_table = (u32 *)table;
	agp_bridge->gatt_bus_addr = virt_to_phys(table);

	for (i = 0; i < num_entries; i++) {
		agp_bridge->gatt_table[i] =
		    (unsigned long) agp_bridge->scratch_page;
	}

	flush_dcache_range((unsigned long)table, (unsigned long)table_end);

	return 0;
}

/* Taken from the Uninorth driver */
static int articias_free_gatt_table(void)
{
	int page_order;
	char *table, *table_end;
	void *temp;
	struct page *page;

	temp = agp_bridge->current_size;
	page_order = A_SIZE_8(temp)->page_order;

	/* Do not worry about freeing memory, because if this is
	 * called, then all agp memory is deallocated and removed
	 * from the table.
	 */

	table = (char *) agp_bridge->gatt_table_real;
	table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);

	for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
		ClearPageReserved(page);

	free_pages((unsigned long) agp_bridge->gatt_table_real, page_order);

	return 0;
}
/* Taken from the Uninorth driver (END). */

#endif /* ARTICIAS_FROMUNINORTH */

static void articias_cleanup(void)
{
	struct aper_size_info_8 *previous_size;

#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] articias_cleanup()\n");
#endif

	previous_size = A_SIZE_8(agp_bridge->previous_size);
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_APSIZE,
			      previous_size->size_value);
}

static void articias_tlbflush(struct agp_memory *mem)
{
#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] agp_tlbflush()\n");
#endif
	return;
}

static struct aper_size_info_8 articias_generic_sizes[7] =
{
	/* size, num_entries, page_order, size_value */

	{4, 1024, 1, 1},
	{8, 2048, 1, 2},
	{16, 4096, 2, 3},
	{32, 8192, 3, 4},
	{64, 16384, 4, 5},
	{128, 32768, 5, 6},
	{256, 65536, 6, 7},

	/* Original code from MAI. */
/*
	{4, 1024, 1, 1},
	{8, 2048, 1, 2},
	{16, 4096, 2, 3},
	{32, 8192, 3, 4},
	{64, 16384, 4, 5},
	{128, 32768, 5, 6}
 */
};

static struct agp_bridge_driver articias_driver = {
	.owner			= THIS_MODULE,
	.aperture_sizes		= articias_generic_sizes,
	.size_type		= U8_APER_SIZE,
	/* Geri: Was 6 before. Added 256k entry for aperture size. */
	.num_aperture_sizes	= 7,
	.configure		= articias_configure,
	.fetch_size		= articias_fetch_size,
	.cleanup		= articias_cleanup,
	.tlb_flush		= articias_tlbflush,
	.mask_memory		= agp_generic_mask_memory,
	.masks			= NULL,
	.agp_enable		= agp_generic_enable,
	.cache_flush		= global_cache_flush,
#ifdef ARTICIAS_FROMUNINORTH
	/* David: new code borrowed from Uninorth driver. */
	.create_gatt_table	= articias_create_gatt_table,
	.free_gatt_table	= articias_free_gatt_table,
	.insert_memory		= articias_insert_memory,
#else
	/* Original code form MAI. */
	.create_gatt_table	= agp_generic_create_gatt_table,
	.free_gatt_table	= agp_generic_free_gatt_table,
	.insert_memory		= agp_generic_insert_memory,
#endif
	.remove_memory		= agp_generic_remove_memory,
	.alloc_by_type		= agp_generic_alloc_by_type,
	.free_by_type		= agp_generic_free_by_type,
	.agp_alloc_page		= agp_generic_alloc_page,
	.agp_destroy_page	= agp_generic_destroy_page,
//	.cant_use_aperture	= 1,
//	.needs_scratch_page	= 1,
};

static struct agp_device_ids articias_agp_device_ids[] __devinitdata =
{
	{
		.device_id	= PCI_DEVICE_ID_MAI_ARTICIAS,
		.chipset_name	= "ArticiaS",
	},

	{ }, /* dummy final entry, always present */
};

static int __devinit agp_articias_probe(struct pci_dev *pdev,
				   const struct pci_device_id *ent)
{
	struct agp_device_ids *devs = articias_agp_device_ids;
	struct agp_bridge_data *bridge;
	int j = 0;
	u8 cap_ptr;

	cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP);
	if (!cap_ptr)
		return -ENODEV;

	j = ent - agp_articias_pci_table;
	printk (KERN_INFO PFX "Detected MAI %s chipset\n", devs[j].chipset_name);

	bridge = agp_alloc_bridge();
	if (!bridge)
		return -ENOMEM;

	bridge->dev = pdev;
	bridge->capndx = cap_ptr;
	bridge->driver = &articias_driver;

	return agp_add_bridge(bridge);
}

static void __devexit agp_articias_remove(struct pci_dev *pdev)
{
	struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

	agp_remove_bridge(bridge);
	agp_put_bridge(bridge);
}

#ifdef CONFIG_PM

static int agp_articias_suspend(struct pci_dev *pdev, pm_message_t state)
{
	pci_save_state (pdev);
	pci_set_power_state (pdev, PCI_D3hot);

	return 0;
}

static int agp_articias_resume(struct pci_dev *pdev)
{
	struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

	pci_set_power_state (pdev, PCI_D0);
	pci_restore_state(pdev);

	if (bridge->driver == &articias_driver)
		return articias_configure();

	return 0;
}

#endif /* CONFIG_PM */

/* must be the same order as name table above */
static struct pci_device_id agp_articias_pci_table[] = {
#define ID(x) \
	{						\
	.class		= (PCI_CLASS_BRIDGE_HOST << 8),	\
	.class_mask	= ~0,				\
	.vendor		= PCI_VENDOR_ID_MAI,		\
	.device		= x,				\
	.subvendor	= PCI_ANY_ID,			\
	.subdevice	= PCI_ANY_ID,			\
	}
	ID(PCI_DEVICE_ID_MAI_ARTICIAS),
	{ }
};

MODULE_DEVICE_TABLE(pci, agp_articias_pci_table);

static struct pci_driver agp_articias_pci_driver = {
	.name		= "agpgart-articias",
	.id_table	= agp_articias_pci_table,
	.probe		= agp_articias_probe,
	.remove		= agp_articias_remove,
#ifdef CONFIG_PM
	.suspend	= agp_articias_suspend,
	.resume		= agp_articias_resume,
#endif
};

static int __init agp_articias_init(void)
{
	if (agp_off)
	{
#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] agp_articias_init return EINVAL.\n");
#endif
		return -EINVAL;
	}

#ifdef ARTICIAS_DEBUG
	printk(KERN_INFO PFX "[ARTICIAS] agp_articias_init return pci driver
struct.\n");
#endif
	return pci_register_driver(&agp_articias_pci_driver);
}

static void __exit agp_articias_cleanup(void)
{
	pci_unregister_driver(&agp_articias_pci_driver);
}

module_init(agp_articias_init);
module_exit(agp_articias_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>"); 

####### END ######

The code contains a lot of debug code. The driver was based on the VIA
AGPGART driver, but we also tried to get it working with parts of the
Uninorth AGPGART driver.

This is the debug output, if the Uninorth code is not compiled in, but the
generic AGP GATT table create function is used:

Jan 11 22:42:49 localhost kernel: Linux agpgart interface v0.101 (c) Dave
Jones
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] agp_articias_init
return pci driver struct.
Jan 11 22:42:49 localhost kernel: agpgart: Detected MAI ArticiaS chipset
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] articias_fetch_size()
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * non masked temp =
0x41
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * aperature size loop
index #0
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * values[0].size_value
= 1
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * masked temp = 0x1
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * values[0].size = 4
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] * current_size->size =
4
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] *
current_size->page_order = 1
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] *
current_size->num_entries = 1024
Jan 11 22:42:49 localhost kernel: agpgart: [ARTICIAS] *
current_size->size_value = 1
Jan 11 22:42:49 localhost kernel: __ioremap(): phys addr 1fb56000 is RAM lr
c000ec60
Jan 11 22:42:49 localhost kernel: agpgart: unable to get memory for graphics
translation table.
Jan 11 22:42:49 localhost kernel: agpgart: agp_backend_initialize() failed.
Jan 11 22:42:49 localhost kernel: agpgart-articias: probe of 0000:00:00.0
failed with error -12

If the Uninorth code is used, then the driver detects the aperture size as
4MB@0x0:

Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] articias_fetch_size()
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * non masked temp =
0x41
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * aperature size loop
index #0
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * values[0].size_value
= 1
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * masked temp = 0x1
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * values[0].size = 4
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] * current_size->size =
4
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] *
current_size->page_order = 1
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] *
current_size->num_entries = 1024
Jan 11 20:34:12 localhost kernel: agpgart: [ARTICIAS] *
current_size->size_value = 1
Jan 11 20:34:12 localhost kernel: agpgart: AGP aperture is 4M @ 0x0

Regards,

Gerhard

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-11 21:00 AGPGART driver for ArticiaS - ioremap() problem Gerhard Pircher
  2006-01-11 21:52 ` John W. Linville
@ 2006-01-12  4:44 ` Benjamin Herrenschmidt
  2006-01-12  8:15   ` Gerhard Pircher
  2006-01-12 19:15   ` Gerhard Pircher
  1 sibling, 2 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-12  4:44 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Wed, 2006-01-11 at 22:00 +0100, Gerhard Pircher wrote:
> Hi,
> 
> David Bentam and I are trying to get a AGPGART driver working for the
> AmigaOne and the Pegasos1. The driver detects the aperture size of the
> ArticiaS AGP bridge, but fails at the ioremap() function in the generic GATT
> table create function. Does the PowerPC platform behaves differently for the
> mapping of address location for AGP operation than the x86 platform? Is it
> possible to use a mask to relocate the AGP address space to a specific
> location?

Well, what value are you passing to ioremap ?

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-12  4:44 ` Benjamin Herrenschmidt
@ 2006-01-12  8:15   ` Gerhard Pircher
  2006-01-15 21:48     ` Benjamin Herrenschmidt
  2006-01-12 19:15   ` Gerhard Pircher
  1 sibling, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-12  8:15 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

Hi,

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_stamer@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Thu, 12 Jan 2006 15:44:27 +1100
> 
> On Wed, 2006-01-11 at 22:00 +0100, Gerhard Pircher wrote:
> > Hi,
> > 
> > David Bentam and I are trying to get a AGPGART driver working for the
> > AmigaOne and the Pegasos1. The driver detects the aperture size of the
> > ArticiaS AGP bridge, but fails at the ioremap() function in the generic
> > GATT table create function. Does the PowerPC platform behaves
> > differently for the mapping of address location for AGP operation than
> > the x86 platform? Is it possible to use a mask to relocate the AGP
> > address space to a specific location?
> 
> Well, what value are you passing to ioremap ?
> 
> Ben.
>
Please take a look at the end of my previous mail, where I included the
debug messages of the driver and the driver code itself. The log shows that
the physical address is mapped (IMHO) to the PCI memory range (>
0x0c0000000). Is this correct? Shouldn't it be mapped to the system memory
address range?

The aperture size is 4MB, page_order should be 1 and num_entries = 1024.

Hope this helps!? :-)

Thanks!

Regards,

Gerhard

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-12  4:44 ` Benjamin Herrenschmidt
  2006-01-12  8:15   ` Gerhard Pircher
@ 2006-01-12 19:15   ` Gerhard Pircher
  1 sibling, 0 replies; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-12 19:15 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

Hi,

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_stamer@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Thu, 12 Jan 2006 15:44:27 +1100
> 
> On Wed, 2006-01-11 at 22:00 +0100, Gerhard Pircher wrote:
> > Hi,
> > 
> > David Bentam and I are trying to get a AGPGART driver working for the  >
> AmigaOne and the Pegasos1. The driver detects the aperture size of the
> > ArticiaS AGP bridge, but fails at the ioremap() function in the generic
> > GATT table create function. Does the PowerPC platform behaves
> > differently for the mapping of address location for AGP operation than >
> the x86 platform? Is it possible to use a mask to relocate the AGP
> > address space to a specific location?
> 
> Well, what value are you passing to ioremap ?
> 
> Ben.

I added some debug code to the agp_generic_create_gatt_table() function.
This is the debug output of it (function renamed to
articias_create_gatt_table()):

 agpgart: [ARTICIAS] articias_fetch_size()
agpgart: [ARTICIAS] * non masked temp = 0x1
agpgart: [ARTICIAS] * aperature size loop index #0
agpgart: [ARTICIAS] * values[0].size_value = 1
agpgart: [ARTICIAS] * masked temp = 0x1
agpgart: [ARTICIAS] * values[0].size = 4
agpgart: [ARTICIAS] * current_size->size = 4
agpgart: [ARTICIAS] * current_size->page_order = 1
agpgart: [ARTICIAS] * current_size->num_entries = 1024
agpgart: [ARTICIAS] * current_size->size_value = 1
agpgart: [ARTICIAS] articias_create_gatt_table()
agpgart: [ARTICIAS] * table address = 0xdfad2000
agpgart: [ARTICIAS] * table end address = 0xdfad3fff
agpgart: [ARTICIAS] * page = 0xc08f9a80
agpgart: [ARTICIAS] * gatt_table_real = 0xdfad2000
agpgart: [ARTICIAS] * agp_gatt_table = 0xdfad2000
agpgart: [ARTICIAS] * virt_to_gart(table) = 0x1fad2000
__ioremap(): phys addr 1fad2000 is RAM lr c000ec3c
agpgart: [ARTICIAS] * gatt_table_real = 0x0
agpgart: unable to get memory for graphics translation table.
agpgart: agp_backend_initialize() failed.
agpgart-articias: probe of 0000:00:00.0 failed with error -12

As far as I can see, the physical address of the table is in the PCI memory
range, right?

Any ideas?

Thanks!

Regards,

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-12  8:15   ` Gerhard Pircher
@ 2006-01-15 21:48     ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-15 21:48 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc


> Please take a look at the end of my previous mail, where I included the
> debug messages of the driver and the driver code itself. The log shows that
> the physical address is mapped (IMHO) to the PCI memory range (>
> 0x0c0000000). Is this correct? Shouldn't it be mapped to the system memory
> address range?

I don't understand. I would need to now more about what the bridge
actually does to get any sense out of that.

> The aperture size is 4MB, page_order should be 1 and num_entries = 1024.
> 
> Hope this helps!? :-)
> 
> Thanks!
> 
> Regards,
> 
> Gerhard
> 
> -- 
> DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
> GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
> 
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
@ 2006-01-15 23:10 Gerhard Pircher
  2006-01-15 23:25 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-15 23:10 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

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

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Mon, 16 Jan 2006 08:48:28 +1100
> 
> I don't understand. I would need to now more about what
> the bridge actually does to get any sense out of that.

Thanks for answering! It's hard to explain for me what the code does, but I
will try.

I included a cleaned-up version of the AGPGART driver code for the ArticiaS
(AmigaOne/Pegasos1). As mentioned, the driver is based on the VIA AGPGART
driver and uses the agp_generic_create_gatt_table() and
agp_generic_free_gatt_table() functions (well, I copied and renamed this
functions to insert debug code).

Actually at least the bridge does everthing right until now (IMHO :-). The
bridge is detected and also the aperture size is read out correctly from the
registers. After that, the agp_backend_initialize() function in
drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
driver (articias_create_gatt_table). Based on the detected aperture size and
its definitions, this function allocates pages for the GATT table
(alloc_gatt_pages). The function then tries to map this pages with
ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))). But
ioremap_nocache() cannot remap the pages, because the following code snipped
in __ioremap (arch/ppc/mm/pgtable.c) is trigged:

/*
 * Don't allow anybody to remap normal RAM that we're using.
 * mem_init() sets high_memory so only do the check after that.
 */
if ( mem_init_done && (p < virt_to_phys(high_memory)) )
{
	printk("__ioremap(): phys addr "PHYS_FMT" is RAM lr %p\n", p,
	       __builtin_return_address(0));
	return NULL;
}

As it can be seen in the following log, the table address (0xde200000 ->
virt_to_gart(table) = 0x1e200000) is lower than the maximum amount of memory
0x20000000 (512MB) and therefore __ioremap() does not remap the pages.

Debuglog:

agpgart: [ARTICIAS] articias_fetch_size()
agpgart: [ARTICIAS] * non masked temp = 0x6
agpgart: [ARTICIAS] * aperature size loop index #0
agpgart: [ARTICIAS] * values[0].size_value = 1
agpgart: [ARTICIAS] * aperature size loop index #1
agpgart: [ARTICIAS] * values[1].size_value = 2
agpgart: [ARTICIAS] * aperature size loop index #2
agpgart: [ARTICIAS] * values[2].size_value = 3
agpgart: [ARTICIAS] * aperature size loop index #3
agpgart: [ARTICIAS] * values[3].size_value = 4
agpgart: [ARTICIAS] * aperature size loop index #4
agpgart: [ARTICIAS] * values[4].size_value = 5
agpgart: [ARTICIAS] * aperature size loop index #5
agpgart: [ARTICIAS] * values[5].size_value = 6
agpgart: [ARTICIAS] * masked temp = 0x6
agpgart: [ARTICIAS] * values[5].size = 128  (128MB aperture size)
agpgart: [ARTICIAS] * current_size->size = 128
agpgart: [ARTICIAS] * current_size->page_order = 5
agpgart: [ARTICIAS] * current_size->num_entries = 32768
agpgart: [ARTICIAS] * current_size->size_value = 6
agpgart: [ARTICIAS] articias_create_gatt_table()
agpgart: [ARTICIAS] * table address = 0xde200000
agpgart: [ARTICIAS] * table end address = 0xde21ffff
agpgart: [ARTICIAS] * page = 0xc09c4400
agpgart: [ARTICIAS] * gatt_table_real = 0xde200000
agpgart: [ARTICIAS] * agp_gatt_table = 0xde200000
agpgart: [ARTICIAS] * virt_to_gart(table) = 0x1e200000
__ioremap() debug: addr = 0x1e200000
__ioremap() debug: phys addr = 0x1e200000
__ioremap() debug: size = 0x20000
__ioremap() debug: Highmem check
__ioremap() debug: high_memory = 0xe0000000
__ioremap() debug: virt_to_phys(high_memory) = 0x20000000
__ioremap(): phys addr 1e200000 is RAM lr c000f210
agpgart: [ARTICIAS] * gatt_table_real = 0x0
agpgart: unable to get memory for graphics translation table.
agpgart: agp_backend_initialize() failed.
agpgart-articias: probe of 0000:00:00.0 failed with error -12

How can I achieve it that ioremap_nocache() can map the pages or that
alloc_gatt_pages() returns valid pages for the GATT table?

Thanks again!

Regards,

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: articias-agp.c --]
[-- Type: text/x-csrc; name="articias-agp.c", Size: 11419 bytes --]

/*
 * ArticiaS AGPGART routines.
 */

#include <linux/types.h>
#include <linux/module.h>
#include <linux/pagemap.h>
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <linux/init.h>
#include <linux/agp_backend.h>
#include "agp.h"

static struct pci_device_id agp_articias_pci_table[];

__u32 *agp_gatt_table;

#define ARTICIAS_AGP_EN		0x49	/* bit 0 -> AGP enable */
#define ARTICIAS_GART_EN	0x58	/* bit 6 -> GART enable */
#define ARTICIAS_APSIZE		0x59	/* bits 2:0 set size */
#define ARTICIAS_APBASE		0x59	/* TLB address Base [31:12]*/
#define ARTICIAS_GATTBASE	0x10	/* GART base address register */
#define ARTICIAS_TLB_BASE	0x5A	/* bits 16:31 of TLB base address */
#define ARTICIAS_GATT_MASK	0xFFFFF000
#define ARTICIAS_SIZE_MASK	0x07	/* Mask aperture size bits. */

static int articias_fetch_size(void)
{
	int i;
	u8 temp;
	struct aper_size_info_8 *values;

	values = A_SIZE_8(agp_bridge->driver->aperture_sizes);
	pci_read_config_byte(agp_bridge->dev, ARTICIAS_APSIZE, &temp);

	/* Mask the GART/Aperture size selection bits. */
	temp = temp & ARTICIAS_SIZE_MASK;

	for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {

		if (temp == values[i].size_value) {
			agp_bridge->previous_size =
			    agp_bridge->current_size = (void *) (values + i);
			/* Geri: Was <(void *) (values)> before, but that
			 * didn't make sense to me!? Otherwise it would always
			 * point to the same value!
			 */
			agp_bridge->aperture_size_idx = i;

			return values[i].size;
		}
	}

	printk(KERN_ERR PFX "Unknown aperture size from AGP bridge (0x%x)\n", temp);

	return 0;
}

static int articias_configure(void)
{
	u32 temp = 0;
	u16 shift16 = 0;
	u8 shift8 = 0;
	struct aper_size_info_8 *current_size;

	/* Get current aperture size */
	current_size = A_SIZE_8(agp_bridge->current_size);

	temp = (u32) agp_bridge->gatt_table_real;
	/* Get upper word from dword. Note that the ArticiaS should have 20
	 * bits for the TLB base address. Otherwise the PCI write config code
	 * for the aperture size below doesn't make sense!?
	 */
	shift16 = (u16) (temp>>16);

	pci_write_config_word(agp_bridge->dev, ARTICIAS_TLB_BASE, shift16);

	/* Get the byte 1 from dword and mask it out with the aperture size. */
	shift8 = (u8) (temp>>8);
	shift8 &= ~(ARTICIAS_SIZE_MASK);
	shift8 |= current_size->size_value;
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_APBASE, shift8);

	/* Get address to map too */
	pci_read_config_dword(agp_bridge->dev, ARTICIAS_GATTBASE, (void *)&temp);
	temp = temp & ARTICIAS_GATT_MASK;

	agp_bridge->gart_bus_addr = temp;

	/* GART control register */
	/* Enable GART and bus concurrency */
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, 0x41);
	/* Enable AGP operation */
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_AGP_EN, 0x01);

	return 0;
}

int articias_create_gatt_table(struct agp_bridge_data *bridge)
{
	char *table;
	char *table_end;
	int size;
	int page_order;
	int num_entries;
	int i;
	void *temp;
	struct page *page;

	/* The generic routines can't handle 2 level gatt's */
	if (bridge->driver->size_type == LVL2_APER_SIZE)
		return -EINVAL;

	table = NULL;
	i = bridge->aperture_size_idx;
	temp = bridge->current_size;
	size = page_order = num_entries = 0;

	if (bridge->driver->size_type != FIXED_APER_SIZE) {
		do {
			switch (bridge->driver->size_type) {
			case U8_APER_SIZE:
				size = A_SIZE_8(temp)->size;
				page_order =
				    A_SIZE_8(temp)->page_order;
				num_entries =
				    A_SIZE_8(temp)->num_entries;
				break;
			case U16_APER_SIZE:
				size = A_SIZE_16(temp)->size;
				page_order = A_SIZE_16(temp)->page_order;
				num_entries = A_SIZE_16(temp)->num_entries;
				break;
			case U32_APER_SIZE:
				size = A_SIZE_32(temp)->size;
				page_order = A_SIZE_32(temp)->page_order;
				num_entries = A_SIZE_32(temp)->num_entries;
				break;
				/* This case will never really happen. */
			case FIXED_APER_SIZE:
			case LVL2_APER_SIZE:
			default:
				size = page_order = num_entries = 0;
				break;
			}

			table = alloc_gatt_pages(page_order);

			if (table == NULL) {
				i++;
				switch (bridge->driver->size_type) {
				case U8_APER_SIZE:
					bridge->current_size = A_IDX8(bridge);
					break;
				case U16_APER_SIZE:
					bridge->current_size = A_IDX16(bridge);
					break;
				case U32_APER_SIZE:
					bridge->current_size = A_IDX32(bridge);
					break;
					/* This case will never really happen. */
				case FIXED_APER_SIZE:
				case LVL2_APER_SIZE:
				default:
					bridge->current_size =
					    bridge->current_size;
					break;
				}
				temp = bridge->current_size;
			} else {
				bridge->aperture_size_idx = i;
			}
		} while (!table && (i < bridge->driver->num_aperture_sizes));
	} else {
		size = ((struct aper_size_info_fixed *) temp)->size;
		page_order = ((struct aper_size_info_fixed *) temp)->page_order;
		num_entries = ((struct aper_size_info_fixed *) temp)->num_entries;
		table = alloc_gatt_pages(page_order);
	}

	if (table == NULL)
		return -ENOMEM;

	table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);

	for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
		SetPageReserved(page);

	bridge->gatt_table_real = (u32 *) table;
	agp_gatt_table = (void *) table;

	bridge->driver->cache_flush();
	bridge->gatt_table = ioremap_nocache(virt_to_gart(table),
					(PAGE_SIZE * (1 << page_order)));
	bridge->driver->cache_flush();

	if (bridge->gatt_table == NULL) {
		for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
			ClearPageReserved(page);

		free_gatt_pages(table, page_order);

		return -ENOMEM;
	}
	bridge->gatt_bus_addr = virt_to_gart(bridge->gatt_table_real);

	/* AK: bogus, should encode addresses > 4GB */
	for (i = 0; i < num_entries; i++) {
		writel(bridge->scratch_page, bridge->gatt_table+i);
		readl(bridge->gatt_table+i);	/* PCI Posting. */
	}

	return 0;
}

int articias_free_gatt_table(struct agp_bridge_data *bridge)
{
	int page_order;
	char *table, *table_end;
	void *temp;
	struct page *page;

	temp = bridge->current_size;

	switch (bridge->driver->size_type) {
	case U8_APER_SIZE:
		page_order = A_SIZE_8(temp)->page_order;
		break;
	case U16_APER_SIZE:
		page_order = A_SIZE_16(temp)->page_order;
		break;
	case U32_APER_SIZE:
		page_order = A_SIZE_32(temp)->page_order;
		break;
	case FIXED_APER_SIZE:
		page_order = A_SIZE_FIX(temp)->page_order;
		break;
	case LVL2_APER_SIZE:
		/* The generic routines can't deal with 2 level gatt's */
		return -EINVAL;
		break;
	default:
		page_order = 0;
		break;
	}

	/* Do not worry about freeing memory, because if this is
	 * called, then all agp memory is deallocated and removed
	 * from the table. */

	iounmap(bridge->gatt_table);
	table = (char *) bridge->gatt_table_real;
	table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);

	for (page = virt_to_page(table); page <= virt_to_page(table_end); page++)
		ClearPageReserved(page);

	free_gatt_pages(bridge->gatt_table_real, page_order);

	agp_gatt_table = NULL;
	bridge->gatt_table = NULL;
	bridge->gatt_table_real = NULL;
	bridge->gatt_bus_addr = 0;

	return 0;
}

#endif

static void articias_cleanup(void)
{
	struct aper_size_info_8 *previous_size;

	previous_size = A_SIZE_8(agp_bridge->previous_size);
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_APSIZE,
			      previous_size->size_value);
}

static void articias_tlbflush(struct agp_memory *mem)
{
	u8 temp;

	pci_read_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, &temp);
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, (temp | 0x80));
	pci_write_config_byte(agp_bridge->dev, ARTICIAS_GART_EN, (temp & 0x7F));

	return;
}

static struct aper_size_info_8 articias_generic_sizes[7] =
{
	/* size, num_entries, page_order, size_value */
	{4, 1024, 1, 1},
	{8, 2048, 1, 2},
	{16, 4096, 2, 3},
	{32, 8192, 3, 4},
	{64, 16384, 4, 5},
	{128, 32768, 5, 6},
	{256, 65536, 6, 7},
};

static struct agp_bridge_driver articias_driver = {
	.owner			= THIS_MODULE,
	.aperture_sizes		= articias_generic_sizes,
	.size_type		= U8_APER_SIZE,
	.num_aperture_sizes	= 7,
	.configure		= articias_configure,
	.fetch_size		= articias_fetch_size,
	.cleanup		= articias_cleanup,
	.tlb_flush		= articias_tlbflush,
	.mask_memory		= agp_generic_mask_memory,
	.masks			= NULL,
	.agp_enable		= agp_generic_enable,
	.cache_flush		= global_cache_flush,
	.create_gatt_table	= articias_create_gatt_table,
	.free_gatt_table	= articias_free_gatt_table,
	.insert_memory		= agp_generic_insert_memory,
	.remove_memory		= agp_generic_remove_memory,
	.alloc_by_type		= agp_generic_alloc_by_type,
	.free_by_type		= agp_generic_free_by_type,
	.agp_alloc_page		= agp_generic_alloc_page,
	.agp_destroy_page	= agp_generic_destroy_page,
};

static struct agp_device_ids articias_agp_device_ids[] __devinitdata =
{
	{
		.device_id	= PCI_DEVICE_ID_MAI_ARTICIAS,
		.chipset_name	= "ArticiaS",
	},

	{ }, /* dummy final entry, always present */
};

static int __devinit agp_articias_probe(struct pci_dev *pdev,
				   const struct pci_device_id *ent)
{
	struct agp_device_ids *devs = articias_agp_device_ids;
	struct agp_bridge_data *bridge;
	int j = 0;
	u8 cap_ptr;

	cap_ptr = pci_find_capability(pdev, PCI_CAP_ID_AGP);
	if (!cap_ptr)
		return -ENODEV;

	j = ent - agp_articias_pci_table;
	printk (KERN_INFO PFX "Detected MAI %s chipset\n", devs[j].chipset_name);

	bridge = agp_alloc_bridge();
	if (!bridge)
		return -ENOMEM;

#ifdef  ARTICIAS_DEBUG
	/* Geri: Print all AGP relevant registers of the ArticiaS. */
	articias_print_agp_register(pdev);
#endif

	bridge->dev = pdev;
	bridge->capndx = cap_ptr;
	bridge->driver = &articias_driver;

	/* Set a higher aperture size! Now it should be 128MB. */
	pci_write_config_byte(pdev, ARTICIAS_APSIZE, 0x06);

	return agp_add_bridge(bridge);
}

static void __devexit agp_articias_remove(struct pci_dev *pdev)
{
	struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

	agp_remove_bridge(bridge);
	agp_put_bridge(bridge);
}

#ifdef CONFIG_PM

static int agp_articias_suspend(struct pci_dev *pdev, pm_message_t state)
{
	pci_save_state (pdev);
	pci_set_power_state (pdev, PCI_D3hot);

	return 0;
}

static int agp_articias_resume(struct pci_dev *pdev)
{
	struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

	pci_set_power_state (pdev, PCI_D0);
	pci_restore_state(pdev);

	if (bridge->driver == &articias_driver)
		return articias_configure();

	return 0;
}

#endif /* CONFIG_PM */

/* must be the same order as name table above */
static struct pci_device_id agp_articias_pci_table[] = {
#define ID(x) \
	{						\
	.class		= (PCI_CLASS_BRIDGE_HOST << 8),	\
	.class_mask	= ~0,				\
	.vendor		= PCI_VENDOR_ID_MAI,		\
	.device		= x,				\
	.subvendor	= PCI_ANY_ID,			\
	.subdevice	= PCI_ANY_ID,			\
	}
	ID(PCI_DEVICE_ID_MAI_ARTICIAS),
	{ }
};

MODULE_DEVICE_TABLE(pci, agp_articias_pci_table);

static struct pci_driver agp_articias_pci_driver = {
	.name		= "agpgart-articias",
	.id_table	= agp_articias_pci_table,
	.probe		= agp_articias_probe,
	.remove		= agp_articias_remove,
#ifdef CONFIG_PM
	.suspend	= agp_articias_suspend,
	.resume		= agp_articias_resume,
#endif
};

static int __init agp_articias_init(void)
{
	if (agp_off)
	{
		return -EINVAL;
	}

	return pci_register_driver(&agp_articias_pci_driver);
}

static void __exit agp_articias_cleanup(void)
{
	pci_unregister_driver(&agp_articias_pci_driver);
}

module_init(agp_articias_init);
module_exit(agp_articias_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Dave Jones <davej@codemonkey.org.uk>");

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-15 23:10 Gerhard Pircher
@ 2006-01-15 23:25 ` Benjamin Herrenschmidt
  2006-01-16  8:11   ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-15 23:25 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc


> Actually at least the bridge does everthing right until now (IMHO :-). The
> bridge is detected and also the aperture size is read out correctly from the
> registers. After that, the agp_backend_initialize() function in
> drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
> driver (articias_create_gatt_table). Based on the detected aperture size and
> its definitions, this function allocates pages for the GATT table
> (alloc_gatt_pages). The function then tries to map this pages with
> ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))). But
> ioremap_nocache() cannot remap the pages, because the following code snipped
> in __ioremap (arch/ppc/mm/pgtable.c) is trigged:

Yes, you are not allowed to ioremap RAM on ppc at least not with
CONFIG_6xx. You should leave it cacheable and use explicit cache flush
like the UniNorth driver.

> As it can be seen in the following log, the table address (0xde200000 ->
> virt_to_gart(table) = 0x1e200000) is lower than the maximum amount of memory
> 0x20000000 (512MB) and therefore __ioremap() does not remap the pages.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-15 23:25 ` Benjamin Herrenschmidt
@ 2006-01-16  8:11   ` Gerhard Pircher
  2006-01-16 23:18     ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-16  8:11 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Mon, 16 Jan 2006 10:25:31 +1100
> 
> >Actually at least the bridge does everthing right until now (IMHO :-).
> >The bridge is detected and also the aperture size is read out correctly
> >from the registers. After that, the agp_backend_initialize() function in
> >drivers/cahr/agp/backend.c calls the create_gatt_table() function of the
> >driver (articias_create_gatt_table). Based on the detected aperture size 
> >and its definitions, this function allocates pages for the GATT table
> >(alloc_gatt_pages). The function then tries to map this pages with
> >ioremap_nocache(virt_to_gatt(table, (PAGE_SIZE * (1 << page_order))).
> >But ioremap_nocache() cannot remap the pages, because the following code 
> >snipped in __ioremap (arch/ppc/mm/pgtable.c) is trigged:
> 
> Yes, you are not allowed to ioremap RAM on ppc at least not with
> CONFIG_6xx. You should leave it cacheable and use explicit cache flush
> like the UniNorth driver.

Ah, okay. So at least the approach to use the Uninorth code was a step in
the right direction. But that requires changes in the DRI and X server code,
right?

Thanks!

regards,

Gerhard

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-16  8:11   ` Gerhard Pircher
@ 2006-01-16 23:18     ` Benjamin Herrenschmidt
  2006-01-17  8:37       ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-16 23:18 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc


> Ah, okay. So at least the approach to use the Uninorth code was a step in
> the right direction. But that requires changes in the DRI and X server code,
> right?

Not you shouldn't... there are 2 different things here. One is how you
access the GART table itself. One is how you access the AGP memory (the
memory that is bound to the GART).

I'm not 100% sure what of the 2 above cases triggered an error with
ioremap, I'm not sure what approach should be used, because i don't know
what your chipset does. I would need more infos about the hw there. But
the basic idea is:

 - For the GART table, you don't need to ioremap it (which is generally
a way to have it non-cacheable I suppose). You can just flush cache
entries after populating them (see uninorth_insert_memory(), it flushes
first the pages that are being inserted in the GART as AGP memory is not
cacheable neither, and at the end of the function, flushes the GART
entry proper).

 - The AGP aperture itself. The main issue there is wether your chipset
makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
doesn't for example, it;'s only visible to the graphic chip. That is why
the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
generate AGP mappings by using the real memory pages and putting them
together into a virtual mapping instead of doing a direct mapping of the
AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
remapping of pages is enough.

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-16 23:18     ` Benjamin Herrenschmidt
@ 2006-01-17  8:37       ` Gerhard Pircher
  2006-01-17 21:24         ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-17  8:37 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Tue, 17 Jan 2006 10:18:15 +1100
> 
> > Ah, okay. So at least the approach to use the Uninorth code was a step
> > in the right direction. But that requires changes in the DRI and X
> > server code, right?
> 
> Not you shouldn't... there are 2 different things here. One is how you
> access the GART table itself. One is how you access the AGP memory (the
> memory that is bound to the GART).
> 
> I'm not 100% sure what of the 2 above cases triggered an error with
> ioremap, I'm not sure what approach should be used, because i don't know
> what your chipset does.
That's the problem: we don't have the datasheet for the ArticiaS. :-( 
But the driver initializes correctly with the Uninorth code now and with the
DRI/DRM code changed. (The code in drm_vm.c checks for Apple's PCI vendor
ID. Therefore I just added a check for MAI's PCI vendor ID.) But the X
server freezes after the login screen is displayed (IIRC the mouse still
works, but the keyboard is dead!?).

BTW: A "agp_special_page" is reserved in init.c. Is this page necessary for
the DRI/DRM drivers to work with the Uninorth driver? I enabled this code
snipped for the AmigaONE too to be on the safe side. :-)

> I would need more infos about the hw there. But the basic idea is:
> 
>  - For the GART table, you don't need to ioremap it (which is generally
> a way to have it non-cacheable I suppose). You can just flush cache
> entries after populating them (see uninorth_insert_memory(), it flushes
> first the pages that are being inserted in the GART as AGP memory is not
> cacheable neither, and at the end of the function, flushes the GART
> entry proper).
There may be another problem: it seems that it is not possible to flush the 
TLB cache of the ArticiaS with a specific register setting. At least MAI
didn't specify a bit for this purpose in the code. I have to do some reverse
engineering here. :-)

>  - The AGP aperture itself. The main issue there is wether your chipset
> makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
> doesn't for example, it;'s only visible to the graphic chip. That is why
> the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
> generate AGP mappings by using the real memory pages and putting them
> together into a virtual mapping instead of doing a direct mapping of the
> AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
> remapping of pages is enough.
Good question! How would I have to modify the Uninorth driver to use a
direct mapping of the AGP aperture on the bus?

Thanks!

Gerhard

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-17  8:37       ` Gerhard Pircher
@ 2006-01-17 21:24         ` Benjamin Herrenschmidt
  2006-01-18 19:40           ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-17 21:24 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc


> That's the problem: we don't have the datasheet for the ArticiaS. :-( 
> But the driver initializes correctly with the Uninorth code now and with the
> DRI/DRM code changed. (The code in drm_vm.c checks for Apple's PCI vendor
> ID. Therefore I just added a check for MAI's PCI vendor ID.) But the X
> server freezes after the login screen is displayed (IIRC the mouse still
> works, but the keyboard is dead!?).

That check is only necessary because Apple bridge puts the AGP aperture
at bus address 0. This is probably not the case for you. You may not
have that right. Check what you put in agp_bridge->gart_bus_addr

> BTW: A "agp_special_page" is reserved in init.c. Is this page necessary for
> the DRI/DRM drivers to work with the Uninorth driver? I enabled this code
> snipped for the AmigaONE too to be on the safe side. :-)

It's, I think, still used by the r128 one, but it's not a very good
workaround.

> There may be another problem: it seems that it is not possible to flush the 
> TLB cache of the ArticiaS with a specific register setting. At least MAI
> didn't specify a bit for this purpose in the code. I have to do some reverse
> engineering here. :-)

Hrm... You definitely need a way to flush it

> >  - The AGP aperture itself. The main issue there is wether your chipset
> > makes the AGP aperture visible to the CPU or not. The Apple UniNorth one
> > doesn't for example, it;'s only visible to the graphic chip. That is why
> > the uninorth driver sets cant_use_aperture to 1. That forces the DRM to
> > generate AGP mappings by using the real memory pages and putting them
> > together into a virtual mapping instead of doing a direct mapping of the
> > AGP aperture on the bus. Most x86 chipsets however _can_, thus a simple
> > remapping of pages is enough.

> Good question! How would I have to modify the Uninorth driver to use a
> direct mapping of the AGP aperture on the bus?

Don't set cant_use_aperture to 1 :)

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-17 21:24         ` Benjamin Herrenschmidt
@ 2006-01-18 19:40           ` Gerhard Pircher
  2006-01-18 23:09             ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-18 19:40 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2009 bytes --]

> > That's the problem: we don't have the datasheet for the ArticiaS. :-( 
> > But the driver initializes correctly with the Uninorth code now and
> > with the DRI/DRM code changed. (The code in drm_vm.c checks for Apple's
> > PCI vendor ID. Therefore I just added a check for MAI's PCI vendor ID.)
> > But the X server freezes after the login screen is displayed (IIRC the
> > mouse still works, but the keyboard is dead!?).
> 
> That check is only necessary because Apple bridge puts the AGP aperture
> at bus address 0. This is probably not the case for you. You may not
> have that right. Check what you put in agp_bridge->gart_bus_addr
Hmm, I'm not sure what value agp_bridge->gart_bus_addr should have. The BIOS
doesn't setup it and the VIA AGPGART driver even reads it out from the
northbridge's registers! Where does the value for agp_bridge->gart_bus_addr
come from? For now it is set to 0x0, which would require the modification in
drm_vm.c!?

> > >  - The AGP aperture itself. The main issue there is wether your
> > > chipset makes the AGP aperture visible to the CPU or not. The Apple
> > > UniNorth one doesn't for example, it;'s only visible to the graphic
> > > chip. That is why the uninorth driver sets cant_use_aperture to 1.
> > > That forces the DRM to generate AGP mappings by using the real memory 
> > > pages and putting them together into a virtual mapping instead of
> > > doing a direct mapping of the AGP aperture on the bus. Most x86
> > > chipsets however _can_, thus a simple remapping of pages is enough.
> 
> > Good question! How would I have to modify the Uninorth driver to use a
> > direct mapping of the AGP aperture on the bus?
> 
> Don't set cant_use_aperture to 1 :)
:) The driver seems to work better with cant_use_aperture set to 1, so I
leave it as it is. BTW: What's the meaning of needs_scratch_page?

Thanks for your support!

Gerhard

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-18 19:40           ` Gerhard Pircher
@ 2006-01-18 23:09             ` Benjamin Herrenschmidt
  2006-01-19  8:50               ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-18 23:09 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Wed, 2006-01-18 at 20:40 +0100, Gerhard Pircher wrote:
> > > That's the problem: we don't have the datasheet for the ArticiaS. :-( 
> > > But the driver initializes correctly with the Uninorth code now and
> > > with the DRI/DRM code changed. (The code in drm_vm.c checks for Apple's
> > > PCI vendor ID. Therefore I just added a check for MAI's PCI vendor ID.)
> > > But the X server freezes after the login screen is displayed (IIRC the
> > > mouse still works, but the keyboard is dead!?).
> > 
> > That check is only necessary because Apple bridge puts the AGP aperture
> > at bus address 0. This is probably not the case for you. You may not
> > have that right. Check what you put in agp_bridge->gart_bus_addr

> Hmm, I'm not sure what value agp_bridge->gart_bus_addr should have. The BIOS
> doesn't setup it and the VIA AGPGART driver even reads it out from the
> northbridge's registers! Where does the value for agp_bridge->gart_bus_addr
> come from? For now it is set to 0x0, which would require the modification in
> drm_vm.c!?

Well... this is where you AGP aperture will be in bus space.. you'd
rather know what to do with it to do a driver...

> :) The driver seems to work better with cant_use_aperture set to 1, so I
> leave it as it is. BTW: What's the meaning of needs_scratch_page?

Well, set to 1 would mean the aperture isn't accessible on the CPU
space. It might seem to work better either because indeed that is the
case... or simply because you put it in a wrong place (ie 0 !) There
must be a chipset register somewhere that tells you where the aperture
is no ?

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-18 23:09             ` Benjamin Herrenschmidt
@ 2006-01-19  8:50               ` Gerhard Pircher
  2006-01-19  9:59                 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-19  8:50 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1496 bytes --]

> > Hmm, I'm not sure what value agp_bridge->gart_bus_addr should have. The
> > BIOS doesn't setup it and the VIA AGPGART driver even reads it out from
> > the northbridge's registers! Where does the value for
> > agp_bridge->gart_bus_addr come from? For now it is set to 0x0, which
> > would require the modification in drm_vm.c!?
> 
> Well... this is where you AGP aperture will be in bus space.. you'd
> rather know what to do with it to do a driver...
I'm afraid so. :)

> > :) The driver seems to work better with cant_use_aperture set to 1, so
> > I leave it as it is. BTW: What's the meaning of needs_scratch_page?
> 
> Well, set to 1 would mean the aperture isn't accessible on the CPU
> space. It might seem to work better either because indeed that is the
> case... or simply because you put it in a wrong place (ie 0 !) There
> must be a chipset register somewhere that tells you where the aperture
> is no ?
I set the AGP aperture base register and agp_bridge->gart_bus_addr to
0x01000000 (>=16MB) (trial and error :-) and it seems to work with
cant_use_aperture=1 (and without the modification in drm_vm.c). Even the X
server maps all the data to this address and displays a login screen.
Unfortunately it always freezes in. I guess this is due to the missing GART
flush functionality. So I have to get this working first.

Thanks!

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-19  8:50               ` Gerhard Pircher
@ 2006-01-19  9:59                 ` Benjamin Herrenschmidt
  2006-01-19 10:52                   ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-19  9:59 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Thu, 2006-01-19 at 09:50 +0100, Gerhard Pircher wrote:
> > > Hmm, I'm not sure what value agp_bridge->gart_bus_addr should have. The
> > > BIOS doesn't setup it and the VIA AGPGART driver even reads it out from
> > > the northbridge's registers! Where does the value for
> > > agp_bridge->gart_bus_addr come from? For now it is set to 0x0, which
> > > would require the modification in drm_vm.c!?
> > 
> > Well... this is where you AGP aperture will be in bus space.. you'd
> > rather know what to do with it to do a driver...
> I'm afraid so. :)
> 
> > > :) The driver seems to work better with cant_use_aperture set to 1, so
> > > I leave it as it is. BTW: What's the meaning of needs_scratch_page?
> > 
> > Well, set to 1 would mean the aperture isn't accessible on the CPU
> > space. It might seem to work better either because indeed that is the
> > case... or simply because you put it in a wrong place (ie 0 !) There
> > must be a chipset register somewhere that tells you where the aperture
> > is no ?
> I set the AGP aperture base register and agp_bridge->gart_bus_addr to
> 0x01000000 (>=16MB) (trial and error :-) and it seems to work with
> cant_use_aperture=1 

Makes sense, since this value is right in the middle of your RAM :) What
does the firmware sets the base register too ? Can't you try to allocate
some resource in the PCI area that isn't already occupied instead ?

> (and without the modification in drm_vm.c). Even the X
> server maps all the data to this address and displays a login screen.
> Unfortunately it always freezes in. I guess this is due to the missing GART
> flush functionality. So I have to get this working first.

Yah, that would be pretty bad...

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-19  9:59                 ` Benjamin Herrenschmidt
@ 2006-01-19 10:52                   ` Gerhard Pircher
  2006-01-19 22:09                     ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-19 10:52 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1234 bytes --]

> > I set the AGP aperture base register and agp_bridge->gart_bus_addr to
> > 0x01000000 (>=16MB) (trial and error :-) and it seems to work with
> > cant_use_aperture=1 
> 
> Makes sense, since this value is right in the middle of your RAM :) What
> does the firmware sets the base register too ?
I did a readout of all AGP related registers and the base register was set
to 0x0, so the firmware doesn't set it up at all.

> Can't you try to allocate some resource in the PCI area that isn't
> already occupied instead ?
I though the GART base address should be in memory space!?
Sorry for this dumb question: how can I allocate a resource in the PCI area?
I'm not yet familiar with the whole Linux PCI/MM API. :) With something like
pci_alloc_consistent()?

> > (and without the modification in drm_vm.c). Even the X
> > server maps all the data to this address and displays a login screen.
> > Unfortunately it always freezes in. I guess this is due to the missing
> > GART flush functionality. So I have to get this working first.
> 
> Yah, that would be pretty bad...
Indeed! :)

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-19 10:52                   ` Gerhard Pircher
@ 2006-01-19 22:09                     ` Benjamin Herrenschmidt
  2006-01-20 11:16                       ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-19 22:09 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Thu, 2006-01-19 at 11:52 +0100, Gerhard Pircher wrote:
> > > I set the AGP aperture base register and agp_bridge->gart_bus_addr to
> > > 0x01000000 (>=16MB) (trial and error :-) and it seems to work with
> > > cant_use_aperture=1 
> > 
> > Makes sense, since this value is right in the middle of your RAM :) What
> > does the firmware sets the base register too ?
> I did a readout of all AGP related registers and the base register was set
> to 0x0, so the firmware doesn't set it up at all.
> 
> > Can't you try to allocate some resource in the PCI area that isn't
> > already occupied instead ?
> I though the GART base address should be in memory space!?

Euh... I was talking about the aperture base, not the GART base... (One
is the address one the bus where the AGP area will be visible, the other
is where the GART will be in memory, that is the table that contains the
mapping between AGP pages and memory pages).

> Sorry for this dumb question: how can I allocate a resource in the PCI area?
> I'm not yet familiar with the whole Linux PCI/MM API. :) With something like
> pci_alloc_consistent()?

Nope... look at drivers/pci/setup-res.c how it does for allocating new
resources for PCI devices.

> > (and without the modification in drm_vm.c). Even the X
> > > server maps all the data to this address and displays a login screen.
> > > Unfortunately it always freezes in. I guess this is due to the missing
> > > GART flush functionality. So I have to get this working first.
> > 
> > Yah, that would be pretty bad...
> Indeed! :)
> 
> Gerhard
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-19 22:09                     ` Benjamin Herrenschmidt
@ 2006-01-20 11:16                       ` Gerhard Pircher
  2006-01-20 23:00                         ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-20 11:16 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Fri, 20 Jan 2006 09:09:13 +1100
> 
> > > Makes sense, since this value is right in the middle of your RAM :)
> > > What does the firmware sets the base register too ?
> > I did a readout of all AGP related registers and the base register was
> > set to 0x0, so the firmware doesn't set it up at all.
> > 
> > > Can't you try to allocate some resource in the PCI area that isn't
> > > already occupied instead ?
> > I though the GART base address should be in memory space!?
> 
> Euh... I was talking about the aperture base, not the GART base... (One
> is the address one the bus where the AGP area will be visible, the other
> is where the GART will be in memory, that is the table that contains the
> mapping between AGP pages and memory pages).
Doh! :) Actually I meant the aperture base. That was a communication error
between brain and hands. :) 

> > Sorry for this dumb question: how can I allocate a resource in the PCI
> > area? I'm not yet familiar with the whole Linux PCI/MM API. :) With
> > something like pci_alloc_consistent()?
> 
> Nope... look at drivers/pci/setup-res.c how it does for allocating new
> resources for PCI devices.
I guess you mean something like this code snipped from the efficeon-agp.c
source code (with pci_assign_resource()):

---

/*
 * The following fixes the case where the BIOS has "forgotten" to
 * provide an address range for the GART.
 * 20030610 - hamish@zot.org
 */
r = &pdev->resource[0];
if (!r->start && r->end) {
   if(pci_assign_resource(pdev, 0)) {
      printk(KERN_ERR PFX "could not assign resource 0\n");
      return -ENODEV;
   }
}

/*
 * If the device has not been properly setup, the following will catch
 * the problem and should stop the system from crashing.
 * 20030610 - hamish@zot.org
 */
if (pci_enable_device(pdev)) {
   printk(KERN_ERR PFX "Unable to Enable PCI device\n");
   return -ENODEV;
}

/* Fill in the mode register */
if (cap_ptr) {
   pci_read_config_dword(pdev,
   bridge->capndx+PCI_AGP_STATUS, &bridge->mode);
}

pci_set_drvdata(pdev, bridge);

----

BTW: I took a look at the PCI resources list of the AmigaOne and found out
that the resources of the AGP graphic card are allocated to bus 0 (PCI
only). IMHO their allocation should be assigned to bus 1 (AGP) (at least
this is the case on x86!?), so I think this should be fixed. Is my
assumption correct?

Thanks!

Gerhard

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-20 11:16                       ` Gerhard Pircher
@ 2006-01-20 23:00                         ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-20 23:00 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Fri, 2006-01-20 at 12:16 +0100, Gerhard Pircher wrote:

> > Nope... look at drivers/pci/setup-res.c how it does for allocating new
> > resources for PCI devices.
> I guess you mean something like this code snipped from the efficeon-agp.c
> source code (with pci_assign_resource()):

Something around those lines... you will probably need to use lower
level routines, not pci_* as the AGP aperture isn't generally a BAR.

> BTW: I took a look at the PCI resources list of the AmigaOne and found out
> that the resources of the AGP graphic card are allocated to bus 0 (PCI
> only). IMHO their allocation should be assigned to bus 1 (AGP) (at least
> this is the case on x86!?), so I think this should be fixed. Is my
> assumption correct?

Hrm... sounds weird, can you send me the output of lspci -vv,
cat /proc/iomem and cat /prop/ioports ?

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
@ 2006-01-21  1:59 Gerhard Pircher
  2006-01-21 22:48 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-21  1:59 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

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

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Sat, 21 Jan 2006 10:00:16 +1100
> 
> On Fri, 2006-01-20 at 12:16 +0100, Gerhard Pircher wrote:
> 
> > > Nope... look at drivers/pci/setup-res.c how it does for allocating
> > > new resources for PCI devices.
> > I guess you mean something like this code snipped from the
> > efficeon-agp.c source code (with pci_assign_resource()):
> 
> Something around those lines... you will probably need to use lower
> level routines, not pci_* as the AGP aperture isn't generally a BAR.
Yes, I see. :( The code mostly allocates the resources for the AGPGART
driver beyond the real memory space, thus preventing the X server to work.
Sometimes the resource is also mapped to where the resource of the graphic
card resides (address 0x88000000, compare with the included iomem file).

> > BTW: I took a look at the PCI resources list of the AmigaOne and found
> > out that the resources of the AGP graphic card are allocated to bus 0
> > (PCI only). IMHO their allocation should be assigned to bus 1 (AGP) (at 
> > least this is the case on x86!?), so I think this should be fixed. Is
> > my assumption correct?
> 
> Hrm... sounds weird, can you send me the output of lspci -vv,
> cat /proc/iomem and cat /prop/ioports ?
Please take a look to the attachments. But the allocation seems to be
different now! Strange!? At least the AGPGART driver is not allocated to bus
1.

Thanks!

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

[-- Attachment #2: lspci_output.txt --]
[-- Type: text/plain, Size: 6802 bytes --]

0000:00:00.0 Host bridge: Mai Logic Incorporated Articia S Host Bridge (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 32
	Interrupt: pin A routed to IRQ 0
	Region 0: Memory at <unassigned> (32-bit, prefetchable)
	Capabilities: <available only to root>

0000:00:01.0 PCI bridge: Mai Logic Incorporated Articia S PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	!!! Unknown I/O range types 21/20
	Memory behind bridge: 88000000-880fffff
	Prefetchable memory behind bridge: 80000000-87ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

0000:00:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
	Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 7
	Region 0: I/O ports at fe802000 [size=128]
	Region 1: Memory at 98100000 (32-bit, non-prefetchable) [size=128]
	Capabilities: <available only to root>

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: <available only to root>

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 16
	Region 4: I/O ports at fe00cc00 [size=16]
	Capabilities: <available only to root>

0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 31, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 5
	Region 4: I/O ports at fe802080 [size=32]
	Capabilities: <available only to root>

0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 31, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 5
	Region 4: I/O ports at fe8020a0 [size=32]
	Capabilities: <available only to root>

0000:00:07.4 Non-VGA unclassified device: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Capabilities: <available only to root>

0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 11
	Region 0: I/O ports at fe802100 [size=256]
	Region 1: I/O ports at fe802200 [size=4]
	Region 2: I/O ports at fe802204 [size=4]
	Capabilities: <available only to root>

0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 30)
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 11
	Region 0: I/O ports at fe802300 [size=256]
	Capabilities: <available only to root>

0000:00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
	Subsystem: Creative Labs: Unknown device 8067
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128 (500ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at fe802400 [size=32]
	Capabilities: <available only to root>

0000:00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
	Subsystem: Creative Labs Gameport Joystick
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128
	Region 0: I/O ports at fe802420 [size=8]
	Capabilities: <available only to root>

0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA])
	Subsystem: PC Partner Limited: Unknown device 7c13
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (2000ns min)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 80000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at fe002000 [size=256]
	Region 2: Memory at 88000000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at 88020000 [disabled] [size=128K]
	Capabilities: <available only to root>

0000:01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
	Subsystem: PC Partner Limited: Unknown device 7c12
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128 (2000ns min), Cache Line Size: 0x08 (32 bytes)
	Region 0: Memory at 88000000 (32-bit, prefetchable)
	Region 1: Memory at 88010000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: <available only to root>


[-- Attachment #3: iomem_output.txt --]
[-- Type: text/plain, Size: 374 bytes --]

80000000-efffffff : PCI host bridge
  80000000-87ffffff : PCI Bus #01
    80000000-87ffffff : 0000:01:00.0
      80000000-87ffffff : radeonfb framebuffer
  88000000-880fffff : PCI Bus #01
    88000000-8800ffff : 0000:01:00.0
      88000000-8800ffff : radeonfb mmio
    88010000-8801ffff : 0000:01:00.1
    88020000-8803ffff : 0000:01:00.0
  98100000-9810007f : 0000:00:06.0

[-- Attachment #4: ioports_output.txt --]
[-- Type: text/plain, Size: 1287 bytes --]

00000000-00bfffff : PCI host bridge
  00000000-0000001f : dma1
  00000020-00000021 : 8259 (master)
  00000040-0000005f : timer
  00000060-0000006f : i8042
  00000080-0000008f : dma page reg
  000000a0-000000a1 : 8259 (slave)
  000000c0-000000df : dma2
  00000170-00000177 : ide1
  000001f0-000001f7 : ide0
  00000278-0000027a : parport2
  0000027b-0000027f : parport2
  000002f8-000002ff : serial
  00000376-00000376 : ide1
  00000378-0000037a : parport0
  000003bc-000003be : parport1
  000003c0-000003df : vga+
  000003e8-000003ef : serial
  000003f6-000003f6 : ide0
  000003f8-000003ff : serial
  000004d0-000004d1 : 8259 edge control
  00002000-00002fff : PCI Bus #01
    00002000-000020ff : 0000:01:00.0
  0000cc00-0000cc0f : 0000:00:07.1
    0000cc00-0000cc07 : ide0
    0000cc08-0000cc0f : ide1
  00802000-0080207f : 0000:00:06.0
    00802000-0080207f : 0000:00:06.0
  00802080-0080209f : 0000:00:07.2
    00802080-0080209f : uhci_hcd
  008020a0-008020bf : 0000:00:07.3
    008020a0-008020bf : uhci_hcd
  00802100-008021ff : 0000:00:07.5
  00802200-00802203 : 0000:00:07.5
  00802204-00802207 : 0000:00:07.5
  00802300-008023ff : 0000:00:07.6
  00802400-0080241f : 0000:00:09.0
    00802400-0080241f : EMU10K1
  00802420-00802427 : 0000:00:09.1
    00802420-00802427 : emu10k1-gp

[-- Attachment #5: sys_devices_pci0000.00.txt --]
[-- Type: text/plain, Size: 23292 bytes --]

.:
total 0
drwxr-xr-x  14 root root 0 Jan 21  2006 .
drwxr-xr-x   5 root root 0 Jan 21  2006 ..
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:00.0
drwxr-xr-x   4 root root 0 Jan 21 02:18 0000:00:01.0
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:06.0
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:07.0
drwxr-xr-x   4 root root 0 Jan 21 02:18 0000:00:07.1
drwxr-xr-x   3 root root 0 Jan 21 02:18 0000:00:07.2
drwxr-xr-x   3 root root 0 Jan 21 02:18 0000:00:07.3
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:07.4
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:07.5
drwxr-xr-x   2 root root 0 Jan 21 02:18 0000:00:07.6
drwxr-xr-x   3 root root 0 Jan 21 02:18 0000:00:09.0
drwxr-xr-x   3 root root 0 Jan 21 02:18 0000:00:09.1

./0000:00:00.0:
total 0
drwxr-xr-x   2 root root         0 Jan 21 02:18 .
drwxr-xr-x  14 root root         0 Jan 21  2006 ..
lrwxrwxrwx   1 root root         0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root      4096 Jan 21  2006 class
-rw-r--r--   1 root root       256 Jan 21 02:18 config
-r--r--r--   1 root root      4096 Jan 21  2006 device
lrwxrwxrwx   1 root root         0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/agpgart-articias
-r--r--r--   1 root root      4096 Jan 21 02:18 irq
-r--r--r--   1 root root      4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root      4096 Jan 21 02:18 modalias
-r--r--r--   1 root root      4096 Jan 21 02:18 resource
-rw-------   1 root root 134217728 Jan 21 02:18 resource0
-r--r--r--   1 root root      4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root      4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root      4096 Jan 21  2006 vendor

./0000:00:01.0:
total 0
drwxr-xr-x   4 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
drwxr-xr-x   6 root root    0 Jan 21 02:18 0000:01:00.0
drwxr-xr-x   2 root root    0 Jan 21 02:18 0000:01:00.1
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:01.0/0000:01:00.0:
total 0
drwxr-xr-x  6 root root         0 Jan 21 02:18 .
drwxr-xr-x  4 root root         0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root         0 Jan 21  2006 bus -> ../../../../bus/pci
-r--r--r--  1 root root      4096 Jan 21  2006 class
-rw-r--r--  1 root root       256 Jan 21 02:18 config
-r--r--r--  1 root root      4096 Jan 21  2006 device
lrwxrwxrwx  1 root root         0 Jan 21  2006 driver -> ../../../../bus/pci/drivers/radeonfb
-r--r--r--  1 root root       128 Jan 21 02:18 edid1
lrwxrwxrwx  1 root root         0 Jan 21 02:18 graphics:fb0 -> ../../../../class/graphics/fb0
drwxr-xr-x  2 root root         0 Jan 21 02:18 i2c-0
drwxr-xr-x  2 root root         0 Jan 21 02:18 i2c-1
drwxr-xr-x  2 root root         0 Jan 21 02:18 i2c-2
drwxr-xr-x  2 root root         0 Jan 21 02:18 i2c-3
lrwxrwxrwx  1 root root         0 Jan 21 02:18 i2c-dev:i2c-0 -> ../../../../class/i2c-dev/i2c-0
lrwxrwxrwx  1 root root         0 Jan 21 02:18 i2c-dev:i2c-1 -> ../../../../class/i2c-dev/i2c-1
lrwxrwxrwx  1 root root         0 Jan 21 02:18 i2c-dev:i2c-2 -> ../../../../class/i2c-dev/i2c-2
lrwxrwxrwx  1 root root         0 Jan 21 02:18 i2c-dev:i2c-3 -> ../../../../class/i2c-dev/i2c-3
-r--r--r--  1 root root      4096 Jan 21 02:18 irq
-r--r--r--  1 root root      4096 Jan 21 02:18 local_cpus
-r--r--r--  1 root root      4096 Jan 21 02:18 modalias
-r--r--r--  1 root root      4096 Jan 21 02:18 resource
-rw-------  1 root root 134217728 Jan 21 02:18 resource0
-rw-------  1 root root       256 Jan 21 02:18 resource1
-rw-------  1 root root     65536 Jan 21 02:18 resource2
-r--------  1 root root    131072 Jan 21 02:18 rom
-r--r--r--  1 root root      4096 Jan 21  2006 subsystem_device
-r--r--r--  1 root root      4096 Jan 21  2006 subsystem_vendor
-r--r--r--  1 root root      4096 Jan 21  2006 vendor

./0000:00:01.0/0000:01:00.0/i2c-0:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  6 root root    0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root    0 Jan 21 02:18 i2c-adapter:i2c-0 -> ../../../../../class/i2c-adapter/i2c-0
-r--r--r--  1 root root 4096 Jan 21 02:18 name

./0000:00:01.0/0000:01:00.0/i2c-1:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  6 root root    0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root    0 Jan 21 02:18 i2c-adapter:i2c-1 -> ../../../../../class/i2c-adapter/i2c-1
-r--r--r--  1 root root 4096 Jan 21 02:18 name

./0000:00:01.0/0000:01:00.0/i2c-2:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  6 root root    0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root    0 Jan 21 02:18 i2c-adapter:i2c-2 -> ../../../../../class/i2c-adapter/i2c-2
-r--r--r--  1 root root 4096 Jan 21 02:18 name

./0000:00:01.0/0000:01:00.0/i2c-3:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  6 root root    0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root    0 Jan 21 02:18 i2c-adapter:i2c-3 -> ../../../../../class/i2c-adapter/i2c-3
-r--r--r--  1 root root 4096 Jan 21 02:18 name

./0000:00:01.0/0000:01:00.1:
total 0
drwxr-xr-x  2 root root     0 Jan 21 02:18 .
drwxr-xr-x  4 root root     0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root     0 Jan 21 02:18 bus -> ../../../../bus/pci
-r--r--r--  1 root root  4096 Jan 21  2006 class
-rw-r--r--  1 root root   256 Jan 21 02:18 config
-r--r--r--  1 root root  4096 Jan 21  2006 device
-r--r--r--  1 root root  4096 Jan 21 02:18 irq
-r--r--r--  1 root root  4096 Jan 21 02:18 local_cpus
-r--r--r--  1 root root  4096 Jan 21 02:18 modalias
-r--r--r--  1 root root  4096 Jan 21 02:18 resource
-rw-------  1 root root 65536 Jan 21 02:18 resource1
-r--r--r--  1 root root  4096 Jan 21  2006 subsystem_device
-r--r--r--  1 root root  4096 Jan 21  2006 subsystem_vendor
-r--r--r--  1 root root  4096 Jan 21  2006 vendor

./0000:00:06.0:
total 0
drwxr-xr-x   2 root root      0 Jan 21 02:18 .
drwxr-xr-x  14 root root      0 Jan 21  2006 ..
lrwxrwxrwx   1 root root      0 Jan 21  2006 bus -> ../../../bus/pci
-r--r--r--   1 root root   4096 Jan 21  2006 class
-rw-r--r--   1 root root    256 Jan 21 02:18 config
-r--r--r--   1 root root   4096 Jan 21  2006 device
lrwxrwxrwx   1 root root      0 Jan 21  2006 driver -> ../../../bus/pci/drivers/3c59x
-r--r--r--   1 root root   4096 Jan 21 02:18 irq
-r--r--r--   1 root root   4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root   4096 Jan 21 02:18 modalias
lrwxrwxrwx   1 root root      0 Jan 21 02:18 net:eth0 -> ../../../class/net/eth0
-r--r--r--   1 root root   4096 Jan 21 02:18 resource
-rw-------   1 root root    128 Jan 21 02:18 resource0
-rw-------   1 root root    128 Jan 21 02:18 resource1
-r--------   1 root root 131072 Jan 21 02:18 rom
-r--r--r--   1 root root   4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root   4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root   4096 Jan 21  2006 vendor

./0000:00:07.0:
total 0
drwxr-xr-x   2 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/parport_pc
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.1:
total 0
drwxr-xr-x   4 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/VIA_IDE
drwxr-xr-x   3 root root    0 Jan 21  2006 ide0
drwxr-xr-x   4 root root    0 Jan 21  2006 ide1
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root   16 Jan 21 02:18 resource4
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.1/ide0:
total 0
drwxr-xr-x  3 root root 0 Jan 21  2006 .
drwxr-xr-x  4 root root 0 Jan 21 02:18 ..
drwxr-xr-x  2 root root 0 Jan 21 02:18 0.0

./0000:00:07.1/ide0/0.0:
total 0
drwxr-xr-x  2 root root 0 Jan 21 02:18 .
drwxr-xr-x  3 root root 0 Jan 21  2006 ..
lrwxrwxrwx  1 root root 0 Jan 21 02:18 block -> ../../../../../block/hda
lrwxrwxrwx  1 root root 0 Jan 21  2006 bus -> ../../../../../bus/ide
lrwxrwxrwx  1 root root 0 Jan 21  2006 driver -> ../../../../../bus/ide/drivers/ide-disk

./0000:00:07.1/ide1:
total 0
drwxr-xr-x  4 root root 0 Jan 21  2006 .
drwxr-xr-x  4 root root 0 Jan 21 02:18 ..
drwxr-xr-x  2 root root 0 Jan 21 02:18 1.0
drwxr-xr-x  2 root root 0 Jan 21 02:18 1.1

./0000:00:07.1/ide1/1.0:
total 0
drwxr-xr-x  2 root root 0 Jan 21 02:18 .
drwxr-xr-x  4 root root 0 Jan 21  2006 ..
lrwxrwxrwx  1 root root 0 Jan 21 02:18 block -> ../../../../../block/hdc
lrwxrwxrwx  1 root root 0 Jan 21  2006 bus -> ../../../../../bus/ide
lrwxrwxrwx  1 root root 0 Jan 21  2006 driver -> ../../../../../bus/ide/drivers/ide-cdrom

./0000:00:07.1/ide1/1.1:
total 0
drwxr-xr-x  2 root root 0 Jan 21 02:18 .
drwxr-xr-x  4 root root 0 Jan 21  2006 ..
lrwxrwxrwx  1 root root 0 Jan 21 02:18 block -> ../../../../../block/hdd
lrwxrwxrwx  1 root root 0 Jan 21  2006 bus -> ../../../../../bus/ide
lrwxrwxrwx  1 root root 0 Jan 21  2006 driver -> ../../../../../bus/ide/drivers/ide-cdrom

./0000:00:07.2:
total 0
drwxr-xr-x   3 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/uhci_hcd
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 pools
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root   32 Jan 21 02:18 resource4
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
drwxr-xr-x   3 root root    0 Jan 21 02:18 usb1
lrwxrwxrwx   1 root root    0 Jan 21 02:18 usb_host:usb_host1 -> ../../../class/usb_host/usb_host1
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.2/usb1:
total 0
drwxr-xr-x  3 root root    0 Jan 21 02:18 .
drwxr-xr-x  3 root root    0 Jan 21 02:18 ..
drwxr-xr-x  2 root root    0 Jan 21 02:18 1-0:1.0
-rw-r--r--  1 root root 4096 Jan 21 02:18 bConfigurationValue
-r--r--r--  1 root root 4096 Jan 21  2006 bDeviceClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bDeviceProtocol
-r--r--r--  1 root root 4096 Jan 21 02:18 bDeviceSubClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bMaxPacketSize0
-r--r--r--  1 root root 4096 Jan 21 02:18 bMaxPower
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumConfigurations
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumInterfaces
-r--r--r--  1 root root 4096 Jan 21 02:18 bcdDevice
-r--r--r--  1 root root 4096 Jan 21 02:18 bmAttributes
lrwxrwxrwx  1 root root    0 Jan 21  2006 bus -> ../../../../bus/usb
-r--r--r--  1 root root 4096 Jan 21 02:18 configuration
-r--r--r--  1 root root 4096 Jan 21 02:18 devnum
lrwxrwxrwx  1 root root    0 Jan 21  2006 driver -> ../../../../bus/usb/drivers/usb
-r--r--r--  1 root root 4096 Jan 21 02:18 idProduct
-r--r--r--  1 root root 4096 Jan 21 02:18 idVendor
-r--r--r--  1 root root 4096 Jan 21 02:18 manufacturer
-r--r--r--  1 root root 4096 Jan 21 02:18 maxchild
-r--r--r--  1 root root 4096 Jan 21 02:18 product
-r--r--r--  1 root root 4096 Jan 21 02:18 serial
-r--r--r--  1 root root 4096 Jan 21 02:18 speed
lrwxrwxrwx  1 root root    0 Jan 21 02:18 usb_device:usbdev1.1 -> ../../../../class/usb_device/usbdev1.1
-r--r--r--  1 root root 4096 Jan 21 02:18 version

./0000:00:07.2/usb1/1-0:1.0:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  3 root root    0 Jan 21 02:18 ..
-r--r--r--  1 root root 4096 Jan 21 02:18 bAlternateSetting
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceNumber
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceProtocol
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceSubClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumEndpoints
lrwxrwxrwx  1 root root    0 Jan 21 02:18 bus -> ../../../../../bus/usb
lrwxrwxrwx  1 root root    0 Jan 21 02:18 driver -> ../../../../../bus/usb/drivers/hub
-r--r--r--  1 root root 4096 Jan 21 02:18 modalias

./0000:00:07.3:
total 0
drwxr-xr-x   3 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/uhci_hcd
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 pools
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root   32 Jan 21 02:18 resource4
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
drwxr-xr-x   3 root root    0 Jan 21 02:18 usb2
lrwxrwxrwx   1 root root    0 Jan 21 02:18 usb_host:usb_host2 -> ../../../class/usb_host/usb_host2
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.3/usb2:
total 0
drwxr-xr-x  3 root root    0 Jan 21 02:18 .
drwxr-xr-x  3 root root    0 Jan 21 02:18 ..
drwxr-xr-x  2 root root    0 Jan 21 02:18 2-0:1.0
-rw-r--r--  1 root root 4096 Jan 21 02:18 bConfigurationValue
-r--r--r--  1 root root 4096 Jan 21  2006 bDeviceClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bDeviceProtocol
-r--r--r--  1 root root 4096 Jan 21 02:18 bDeviceSubClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bMaxPacketSize0
-r--r--r--  1 root root 4096 Jan 21 02:18 bMaxPower
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumConfigurations
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumInterfaces
-r--r--r--  1 root root 4096 Jan 21 02:18 bcdDevice
-r--r--r--  1 root root 4096 Jan 21 02:18 bmAttributes
lrwxrwxrwx  1 root root    0 Jan 21  2006 bus -> ../../../../bus/usb
-r--r--r--  1 root root 4096 Jan 21 02:18 configuration
-r--r--r--  1 root root 4096 Jan 21 02:18 devnum
lrwxrwxrwx  1 root root    0 Jan 21  2006 driver -> ../../../../bus/usb/drivers/usb
-r--r--r--  1 root root 4096 Jan 21 02:18 idProduct
-r--r--r--  1 root root 4096 Jan 21 02:18 idVendor
-r--r--r--  1 root root 4096 Jan 21 02:18 manufacturer
-r--r--r--  1 root root 4096 Jan 21 02:18 maxchild
-r--r--r--  1 root root 4096 Jan 21 02:18 product
-r--r--r--  1 root root 4096 Jan 21 02:18 serial
-r--r--r--  1 root root 4096 Jan 21 02:18 speed
lrwxrwxrwx  1 root root    0 Jan 21 02:18 usb_device:usbdev2.1 -> ../../../../class/usb_device/usbdev2.1
-r--r--r--  1 root root 4096 Jan 21 02:18 version

./0000:00:07.3/usb2/2-0:1.0:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  3 root root    0 Jan 21 02:18 ..
-r--r--r--  1 root root 4096 Jan 21 02:18 bAlternateSetting
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceNumber
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceProtocol
-r--r--r--  1 root root 4096 Jan 21 02:18 bInterfaceSubClass
-r--r--r--  1 root root 4096 Jan 21 02:18 bNumEndpoints
lrwxrwxrwx  1 root root    0 Jan 21 02:18 bus -> ../../../../../bus/usb
lrwxrwxrwx  1 root root    0 Jan 21 02:18 driver -> ../../../../../bus/usb/drivers/hub
-r--r--r--  1 root root 4096 Jan 21 02:18 modalias

./0000:00:07.4:
total 0
drwxr-xr-x   2 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.5:
total 0
drwxr-xr-x   2 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root  256 Jan 21 02:18 resource0
-rw-------   1 root root    4 Jan 21 02:18 resource1
-rw-------   1 root root    4 Jan 21 02:18 resource2
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:07.6:
total 0
drwxr-xr-x   2 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root  256 Jan 21 02:18 resource0
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:09.0:
total 0
drwxr-xr-x   3 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21  2006 bus -> ../../../bus/pci
drwxr-xr-x   2 root root    0 Jan 21  2006 card0-0
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21  2006 driver -> ../../../bus/pci/drivers/EMU10K1_Audigy
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root   32 Jan 21 02:18 resource0
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:admmidi -> ../../../class/sound/admmidi
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:adsp -> ../../../class/sound/adsp
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:amidi -> ../../../class/sound/amidi
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:audio -> ../../../class/sound/audio
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:controlC0 -> ../../../class/sound/controlC0
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:dmmidi -> ../../../class/sound/dmmidi
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:dsp -> ../../../class/sound/dsp
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:hwC0D0 -> ../../../class/sound/hwC0D0
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:hwC0D2 -> ../../../class/sound/hwC0D2
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:midi -> ../../../class/sound/midi
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:midiC0D0 -> ../../../class/sound/midiC0D0
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:midiC0D1 -> ../../../class/sound/midiC0D1
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:midiC0D2 -> ../../../class/sound/midiC0D2
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:mixer -> ../../../class/sound/mixer
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D0c -> ../../../class/sound/pcmC0D0c
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D0p -> ../../../class/sound/pcmC0D0p
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D1c -> ../../../class/sound/pcmC0D1c
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D2c -> ../../../class/sound/pcmC0D2c
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D2p -> ../../../class/sound/pcmC0D2p
lrwxrwxrwx   1 root root    0 Jan 21 02:18 sound:pcmC0D3p -> ../../../class/sound/pcmC0D3p
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:09.0/card0-0:
total 0
drwxr-xr-x  2 root root 0 Jan 21  2006 .
drwxr-xr-x  3 root root 0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root 0 Jan 21  2006 bus -> ../../../../bus/ac97

./0000:00:09.1:
total 0
drwxr-xr-x   3 root root    0 Jan 21 02:18 .
drwxr-xr-x  14 root root    0 Jan 21  2006 ..
lrwxrwxrwx   1 root root    0 Jan 21 02:18 bus -> ../../../bus/pci
-r--r--r--   1 root root 4096 Jan 21  2006 class
-rw-r--r--   1 root root  256 Jan 21 02:18 config
-r--r--r--   1 root root 4096 Jan 21  2006 device
lrwxrwxrwx   1 root root    0 Jan 21 02:18 driver -> ../../../bus/pci/drivers/Emu10k1_gameport
drwxr-xr-x   2 root root    0 Jan 21 02:18 gameport0
-r--r--r--   1 root root 4096 Jan 21 02:18 irq
-r--r--r--   1 root root 4096 Jan 21 02:18 local_cpus
-r--r--r--   1 root root 4096 Jan 21 02:18 modalias
-r--r--r--   1 root root 4096 Jan 21 02:18 resource
-rw-------   1 root root    8 Jan 21 02:18 resource0
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_device
-r--r--r--   1 root root 4096 Jan 21  2006 subsystem_vendor
-r--r--r--   1 root root 4096 Jan 21  2006 vendor

./0000:00:09.1/gameport0:
total 0
drwxr-xr-x  2 root root    0 Jan 21 02:18 .
drwxr-xr-x  3 root root    0 Jan 21 02:18 ..
lrwxrwxrwx  1 root root    0 Jan 21  2006 bus -> ../../../../bus/gameport
-r--r--r--  1 root root 4096 Jan 21 02:18 description
--w-------  1 root root 4096 Jan 21 02:18 drvctl

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-21  1:59 Gerhard Pircher
@ 2006-01-21 22:48 ` Benjamin Herrenschmidt
  2006-01-23 22:12   ` Gerhard Pircher
  0 siblings, 1 reply; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-21 22:48 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:

> Yes, I see. :( The code mostly allocates the resources for the AGPGART
> driver beyond the real memory space, thus preventing the X server to work.
> Sometimes the resource is also mapped to where the resource of the graphic
> card resides (address 0x88000000, compare with the included iomem file).

The AGP aperture should generally be located "outside" of those spaces.
That is above RAM and in some place where no device already resides...
It can be made to overlap RAM but that isn't a good idea (that's what
happens on Macs though due to a bug in the Apple chipset).

> Please take a look to the attachments. But the allocation seems to be
> different now! Strange!? At least the AGPGART driver is not allocated to bus
> 1.

I don't see anything related to AGP in your output... you didn't post
the lspci as root thus it's missing all the useful infos ;) Also, the
AGP base isn't generally a PCI BAR of the bridge... it is one in your
case ?

Ben.
 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-21 22:48 ` Benjamin Herrenschmidt
@ 2006-01-23 22:12   ` Gerhard Pircher
  2006-01-23 23:15     ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-23 22:12 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Sun, 22 Jan 2006 09:48:44 +1100
> 
> On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:
> 
> > Yes, I see. :( The code mostly allocates the resources for the AGPGART
> > driver beyond the real memory space, thus preventing the X server to
> > work. Sometimes the resource is also mapped to where the resource of
> > the graphic card resides (address 0x88000000, compare with the included 
> > iomem file).
> 
> The AGP aperture should generally be located "outside" of those spaces.
> That is above RAM and in some place where no device already resides...
> It can be made to overlap RAM but that isn't a good idea (that's what
> happens on Macs though due to a bug in the Apple chipset).
Ahh, so the AGP aperture should not be within the memory space and any other
PCI/IO address range. Slowly but surely I become confused. ;-)

> I don't see anything related to AGP in your output... you didn't post
> the lspci as root thus it's missing all the useful infos ;)
I included a new lspci output log. :-) (now done as root)

> Also, the AGP base isn't generally a PCI BAR of the bridge... it is one
> in your case ?
I'm afraid I can't answer this question (you know, we have no datasheet for
the ArticiaS yet). From what I can see in the log, there is an unassigned
memory region (type 0, should be <4GB I guess). Could this affect AGP
operation? 

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
@ 2006-01-23 22:15 Gerhard Pircher
  0 siblings, 0 replies; 26+ messages in thread
From: Gerhard Pircher @ 2006-01-23 22:15 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 209 bytes --]

Forgot to include the lspci log. So here it comes. Sorry! 

Gerhard

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lspci.log --]
[-- Type: text/x-log; name="lspci.log", Size: 10385 bytes --]

0000:00:00.0 Host bridge: Mai Logic Incorporated Articia S Host Bridge (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 32
	Interrupt: pin A routed to IRQ 0
	Region 0: Memory at <unassigned> (32-bit, prefetchable)
	Capabilities: [40] AGP version 1.0
		Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

0000:00:01.0 PCI bridge: Mai Logic Incorporated Articia S PCI Bridge (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	!!! Unknown I/O range types 21/20
	Memory behind bridge: 88000000-880fffff
	Prefetchable memory behind bridge: 80000000-87ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

0000:00:06.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
	Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 8 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 7
	Region 0: I/O ports at fe802000 [size=128]
	Region 1: Memory at 98100000 (32-bit, non-prefetchable) [size=128]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 16
	Region 4: I/O ports at fe00cc00 [size=16]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 31, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 5
	Region 4: I/O ports at fe802080 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 31, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 5
	Region 4: I/O ports at fe8020a0 [size=32]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.4 Non-VGA unclassified device: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Capabilities: [68] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 11
	Region 0: I/O ports at fe802100 [size=256]
	Region 1: I/O ports at fe802200 [size=4]
	Region 2: I/O ports at fe802204 [size=4]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 30)
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 11
	Region 0: I/O ports at fe802300 [size=256]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
	Subsystem: Creative Labs: Unknown device 8067
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128 (500ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at fe802400 [size=32]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
	Subsystem: Creative Labs Gameport Joystick
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128
	Region 0: I/O ports at fe802420 [size=8]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA])
	Subsystem: PC Partner Limited: Unknown device 7c13
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (2000ns min)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 80000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at fe002000 [size=256]
	Region 2: Memory at 88000000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at 88020000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01)
	Subsystem: PC Partner Limited: Unknown device 7c12
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 128 (2000ns min), Cache Line Size: 0x08 (32 bytes)
	Region 0: Memory at 88000000 (32-bit, prefetchable)
	Region 1: Memory at 88010000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

80000000-efffffff : PCI host bridge
  80000000-87ffffff : PCI Bus #01
    80000000-87ffffff : 0000:01:00.0
      80000000-87ffffff : radeonfb framebuffer
  88000000-880fffff : PCI Bus #01
    88000000-8800ffff : 0000:01:00.0
      88000000-8800ffff : radeonfb mmio
    88010000-8801ffff : 0000:01:00.1
    88020000-8803ffff : 0000:01:00.0
  98100000-9810007f : 0000:00:06.0

00000000-00bfffff : PCI host bridge
  00000000-0000001f : dma1
  00000020-00000021 : 8259 (master)
  00000040-0000005f : timer
  00000060-0000006f : i8042
  00000080-0000008f : dma page reg
  000000a0-000000a1 : 8259 (slave)
  000000c0-000000df : dma2
  00000170-00000177 : ide1
  000001f0-000001f7 : ide0
  00000278-0000027a : parport2
  0000027b-0000027f : parport2
  000002f8-000002ff : serial
  00000376-00000376 : ide1
  00000378-0000037a : parport0
  000003bc-000003be : parport1
  000003c0-000003df : vga+
  000003e8-000003ef : serial
  000003f6-000003f6 : ide0
  000003f8-000003ff : serial
  000004d0-000004d1 : 8259 edge control
  00002000-00002fff : PCI Bus #01
    00002000-000020ff : 0000:01:00.0
  0000cc00-0000cc0f : 0000:00:07.1
    0000cc00-0000cc07 : ide0
    0000cc08-0000cc0f : ide1
  00802000-0080207f : 0000:00:06.0
    00802000-0080207f : 0000:00:06.0
  00802080-0080209f : 0000:00:07.2
    00802080-0080209f : uhci_hcd
  008020a0-008020bf : 0000:00:07.3
    008020a0-008020bf : uhci_hcd
  00802100-008021ff : 0000:00:07.5
  00802200-00802203 : 0000:00:07.5
  00802204-00802207 : 0000:00:07.5
  00802300-008023ff : 0000:00:07.6
  00802400-0080241f : 0000:00:09.0
    00802400-0080241f : EMU10K1
  00802420-00802427 : 0000:00:09.1
    00802420-00802427 : emu10k1-gp

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: AGPGART driver for ArticiaS - ioremap() problem
  2006-01-23 22:12   ` Gerhard Pircher
@ 2006-01-23 23:15     ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 26+ messages in thread
From: Benjamin Herrenschmidt @ 2006-01-23 23:15 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc

On Mon, 2006-01-23 at 23:12 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> > Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> > Datum: Sun, 22 Jan 2006 09:48:44 +1100
> > 
> > On Sat, 2006-01-21 at 02:59 +0100, Gerhard Pircher wrote:
> > 
> > > Yes, I see. :( The code mostly allocates the resources for the AGPGART
> > > driver beyond the real memory space, thus preventing the X server to
> > > work. Sometimes the resource is also mapped to where the resource of
> > > the graphic card resides (address 0x88000000, compare with the included 
> > > iomem file).
> > 
> > The AGP aperture should generally be located "outside" of those spaces.
> > That is above RAM and in some place where no device already resides...
> > It can be made to overlap RAM but that isn't a good idea (that's what
> > happens on Macs though due to a bug in the Apple chipset).
> Ahh, so the AGP aperture should not be within the memory space and any other
> PCI/IO address range. Slowly but surely I become confused. ;-)
> 
> > I don't see anything related to AGP in your output... you didn't post
> > the lspci as root thus it's missing all the useful infos ;)
> I included a new lspci output log. :-) (now done as root)
> 
> > Also, the AGP base isn't generally a PCI BAR of the bridge... it is one
> > in your case ?
> I'm afraid I can't answer this question (you know, we have no datasheet for
> the ArticiaS yet). From what I can see in the log, there is an unassigned
> memory region (type 0, should be <4GB I guess). Could this affect AGP
> operation? 

No idea... memory BARs on host bridges can be anything... It might just
be the normal PCI DMA region.

Ben.

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2006-01-23 23:15 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-11 21:00 AGPGART driver for ArticiaS - ioremap() problem Gerhard Pircher
2006-01-11 21:52 ` John W. Linville
2006-01-11 22:18   ` Gerhard Pircher
2006-01-12  4:44 ` Benjamin Herrenschmidt
2006-01-12  8:15   ` Gerhard Pircher
2006-01-15 21:48     ` Benjamin Herrenschmidt
2006-01-12 19:15   ` Gerhard Pircher
  -- strict thread matches above, loose matches on Subject: below --
2006-01-15 23:10 Gerhard Pircher
2006-01-15 23:25 ` Benjamin Herrenschmidt
2006-01-16  8:11   ` Gerhard Pircher
2006-01-16 23:18     ` Benjamin Herrenschmidt
2006-01-17  8:37       ` Gerhard Pircher
2006-01-17 21:24         ` Benjamin Herrenschmidt
2006-01-18 19:40           ` Gerhard Pircher
2006-01-18 23:09             ` Benjamin Herrenschmidt
2006-01-19  8:50               ` Gerhard Pircher
2006-01-19  9:59                 ` Benjamin Herrenschmidt
2006-01-19 10:52                   ` Gerhard Pircher
2006-01-19 22:09                     ` Benjamin Herrenschmidt
2006-01-20 11:16                       ` Gerhard Pircher
2006-01-20 23:00                         ` Benjamin Herrenschmidt
2006-01-21  1:59 Gerhard Pircher
2006-01-21 22:48 ` Benjamin Herrenschmidt
2006-01-23 22:12   ` Gerhard Pircher
2006-01-23 23:15     ` Benjamin Herrenschmidt
2006-01-23 22:15 Gerhard Pircher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).