Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Robert Hancock]

Rafał Bilski wrote:
>> It needs there to be no bus mastering occuring at the time
>> of a CPU speed transition. Though I'm unable to find the part that me
> ntions
>> this in the specs I have right now.
> 
>> Dave
> 
> "Once this is set, the processor will switch to the
> value in [26:23] on the next AUTOHALT transition. The duration of the A
> UTOHALT
> should be >=1ms to ensure the CPU's internal PLL is resynchronized. F
> or AUTOHALT, this means interrupts must be disabled except for the time ti
> ck, which should be reset to >=1ms. Care must be taken to avoid other sys
> tem events that could interfere with this operation. A few examples are 
> snooping, NMI, INIT, SMI and FLUSH."
> 
> For CPU's with Longhaul MSR this time is equal to 200us.

That really is a rather horrible design on their part. Who the hell at 
VIA thought this was a good idea?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

> 
> That really is a rather horrible design on their part. Who the hell at
> VIA thought this was a good idea?
> 

I have asked them. Answer is: support is in north/south bridge.
This code works fine (of course "clear BM bit for each device" removed):
[...]
	cx = &pr->power.states[ACPI_STATE_C3];
	printk("Begin..\n"); /* Just to be sure */
	preempt_disable();
	local_irq_save(flags);
[...]
	safe_halt();	/* Sync */

	ACPI_FLUSH_CPU_CACHE();

	wrmsrl(MSR_VIA_LONGHAUL, longhaul->val);
	/* Invoke C3 */
	inb(cx->address);
	/* Dummy op - must do something useless after P_LVL3 read */
	t2 = inl(acpi_fadt.xpm_tmr_blk.address);

	local_irq_disable();
[...]
	printk("..End\n");

30 min "hdparm -t", frequency changes at 1s interval.
CPU temperature is changing too.
Checked in Bashmark.

THIS IS WORKING.


------------------------------------------------------------------------
Najkrótsza trasa na wakacje: http://map24.interia.pl

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Bart Hartgers]

Rafał Bilski wrote:
> I'm using this for L2 cache:
> 	preempt_disable();
> 	local_irq_save(flags);
> 	rdmsr(MSR_VIA_FCR, lo, hi);
> 	flush_cache_all();
> 	wrmsr(MSR_VIA_FCR, lo | 1 << 8, hi);
> and this doesn't stop the processor, but when I'm adding
> 1 << 13 or 1 << 14 CPU stops. I have tried
> 	flush_cache_all();
> 	wrmsr(MSR_VIA_FCR, lo | 1 << 8, hi);
> 	flush_cache_all();
> 	wrmsr(MSR_VIA_FCR, lo | 1 << 8 | 1 << 13, hi);
> and
> 	flush_cache_all();
> 	wrmsr(MSR_VIA_FCR, lo | 1 << 8 | 1 << 13, hi);
> and more, but result was always the same.
> 
> I will be very gratefull if You tell me what I'm doing wrong.
> 
> Rafał

Sorry, I have no idea. The code looks fine.


-- 
Bart Hartgers - TUE Eindhoven - http://plasimo.phys.tue.nl/bart/contact/

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

> Maybe you need to do something with the cache bits in CR0 as well. It
> could be something like that. Hardware can be stuborn. I remember the
> old Winchips (C3 predecessors) hanging when trying to disable caching of
> plain ram via MCR's for instance.
> 

I did it like in chapter 10.5.3. Result is exacly the same - processor 
stops. If I set NW flag CPU is still going, but I have "exception in 
interrupt" message.
I'm starting thinking that this will not work for "Nehemiah" core.

Thanks
Rafał


----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Alan Cox]

Ar Iau, 2006-06-29 am 17:16 +0200, ysgrifennodd Bart Hartgers:
> Rafał Bilski wrote:
> > CPU is VIA C3 in EBGA "Nehemiah" core 6.9.8.
> > I'm using flush_cache_all(). Is there anything more powerfull?
> > I'm using MSR_VIA_FCR.
> > I can disable L2 cache (or at least I think so) - this doesn't help.
> > I can't disable L1 cache - processor stops when I'm trying to set 
> > I-cache or D-cache disable bit.

If you can flush any cached writes to RAM before you do the changeover
and after you disabled interrupts then it ought to be sufficient to
invalidate the cache just before re-enabling everything.

The reason I make that claim is that you know nobody will be DMAing over
the pages of memory you use for the speed change itself. Might need a
little care with the stack that is all.


Alan

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Alan Cox]

Ar Iau, 2006-06-29 am 14:03 +0200, ysgrifennodd Bart Hartgers:
> > "snooping". So we do need the cache sorting out.
> >
> 
> If I understand correctly, trouble occurs when the processor tries to
> snoop? Would disabling (via MSR) and flushing the caches before changing
> the frequency help in that case?

I would think so. Some other processors have similar requirements for
deep sleeping.

Alan

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

> Hi Rafał,
> 
> Any code to show? Just in case... ;-)
> 
> Groeten,
> Bart
> 

I'm using this for L2 cache:
	preempt_disable();
	local_irq_save(flags);
	rdmsr(MSR_VIA_FCR, lo, hi);
	flush_cache_all();
	wrmsr(MSR_VIA_FCR, lo | 1 << 8, hi);
and this doesn't stop the processor, but when I'm adding
1 << 13 or 1 << 14 CPU stops. I have tried
	flush_cache_all();
	wrmsr(MSR_VIA_FCR, lo | 1 << 8, hi);
	flush_cache_all();
	wrmsr(MSR_VIA_FCR, lo | 1 << 8 | 1 << 13, hi);
and
	flush_cache_all();
	wrmsr(MSR_VIA_FCR, lo | 1 << 8 | 1 << 13, hi);
and more, but result was always the same.

I will be very gratefull if You tell me what I'm doing wrong.

Rafał


----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Bart Hartgers]

Rafał Bilski wrote:
>> If I understand correctly, trouble occurs when the processor tries to
>> snoop? Would disabling (via MSR) and flushing the caches before changing
>> the frequency help in that case?
>>
>> Groeten,
>> Bart
>>
> 
> CPU is VIA C3 in EBGA "Nehemiah" core 6.9.8.
> I'm using flush_cache_all(). Is there anything more powerfull?
> I'm using MSR_VIA_FCR.
> I can disable L2 cache (or at least I think so) - this doesn't help.
> I can't disable L1 cache - processor stops when I'm trying to set 
> I-cache or D-cache disable bit.

Maybe you need to do something with the cache bits in CR0 as well. It
could be something like that. Hardware can be stuborn. I remember the
old Winchips (C3 predecessors) hanging when trying to disable caching of
plain ram via MCR's for instance.

-- 
Bart Hartgers - TUE Eindhoven - http://plasimo.phys.tue.nl/bart/contact/

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Bart Hartgers]

Rafał Bilski wrote:
> CPU is VIA C3 in EBGA "Nehemiah" core 6.9.8.
> I'm using flush_cache_all(). Is there anything more powerfull?
> I'm using MSR_VIA_FCR.
> I can disable L2 cache (or at least I think so) - this doesn't help.
> I can't disable L1 cache - processor stops when I'm trying to set 
> I-cache or D-cache disable bit.
> 
> Thanks
> Rafał
> 

Hi Rafał,

Any code to show? Just in case... ;-)

Groeten,
Bart

-- 
Bart Hartgers - TUE Eindhoven - http://plasimo.phys.tue.nl/bart/contact/

[PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

> If I understand correctly, trouble occurs when the processor tries to
> snoop? Would disabling (via MSR) and flushing the caches before changing
> the frequency help in that case?
> 
> Groeten,
> Bart
> 

CPU is VIA C3 in EBGA "Nehemiah" core 6.9.8.
I'm using flush_cache_all(). Is there anything more powerfull?
I'm using MSR_VIA_FCR.
I can disable L2 cache (or at least I think so) - this doesn't help.
I can't disable L1 cache - processor stops when I'm trying to set 
I-cache or D-cache disable bit.

Thanks
Rafał


----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

Bart Hartgers napisał(a):
> Alan Cox wrote:
>> Ar Mer, 2006-06-28 am 20:25 +0200, ysgrifennodd Rafał Bilski:
>>> AUTOHALT, this means interrupts must be disabled except for the time tick, 
>>> which should be reset to >=1ms. Care must be taken to avoid other system events 
>>> that could interfere with this operation. A few examples are snooping, NMI, 
>>> INIT, SMI and FLUSH."
>> "snooping". So we do need the cache sorting out.
>>
> 
> If I understand correctly, trouble occurs when the processor tries to
> snoop? Would disabling (via MSR) and flushing the caches before changing
> the frequency help in that case?
> 
> Groeten,
> Bart
> 

I will check that. If this was so simple all this time...
I hope this "few examples" aren't many more.

Rafał


----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Bart Hartgers]

Alan Cox wrote:
> Ar Mer, 2006-06-28 am 20:25 +0200, ysgrifennodd Rafał Bilski:
>> AUTOHALT, this means interrupts must be disabled except for the time tick, 
>> which should be reset to >=1ms. Care must be taken to avoid other system events 
>> that could interfere with this operation. A few examples are snooping, NMI, 
>> INIT, SMI and FLUSH."
> 
> "snooping". So we do need the cache sorting out.
>

If I understand correctly, trouble occurs when the processor tries to
snoop? Would disabling (via MSR) and flushing the caches before changing
the frequency help in that case?

Groeten,
Bart

-- 
Bart Hartgers - TUE Eindhoven - http://plasimo.phys.tue.nl/bart/contact/

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Alan Cox]

Ar Mer, 2006-06-28 am 20:25 +0200, ysgrifennodd Rafał Bilski:
> AUTOHALT, this means interrupts must be disabled except for the time tick, 
> which should be reset to >=1ms. Care must be taken to avoid other system events 
> that could interfere with this operation. A few examples are snooping, NMI, 
> INIT, SMI and FLUSH."

"snooping". So we do need the cache sorting out.

[PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

> You mean the longhaul driver can change the frequency of the PCI
> bus?  Oh, that's a recipe for disaster... 

No. Sorry. My English is bad. I mean changing CPU frequency.

> No, it's a hack :)

Again :-)

> No, this is not acceptable.  What exactly do you want to do here?  Make
> sure the PCI drivers are not doing DMA when the longhaul driver wants to
> change the pci bus speed? 

I'm trying not to break DMA. Current version of longhaul (marked broken 
in 2.6.16.2) simply clears bus master bit on every device.

> Does it really save battery?

Yes. And CPU temperature is lower.

> And what about PCI devices that always do DMA?  (think USB controllers,
> they can easily saturate the PCI bus all the time). 

This is worst for SATA. USB (this is strange) seems to work correcly.
I know that this is 10% coverage, but it is better then nothing.
It is always possible to add support for longhaul to driver.

> Why not just suspend all PCI devices make the bus change, and then
> resume them?  That would require no PCI core, or driver changes.

This was my first idea. But trust me in current kernel this is simply
worst idea.

> greg k-h

> Though currently in the driver, voltage scaling is missing,
> so we never save any power, and just run at the maximum voltage 
> the whole time.

I added this to longhaul, but it only works on non EBGA CPU's.
EBGA CPU's (at least Nehemiah) seem to have voltage scaling
disabled.

> It needs there to be no bus mastering occuring at the time
> of a CPU speed transition. Though I'm unable to find the part that mentions
> this in the specs I have right now.

> Dave

"Once this is set, the processor will switch to the
value in [26:23] on the next AUTOHALT transition. The duration of the AUTOHALT
should be >=1ms to ensure the CPU's internal PLL is resynchronized. For 
AUTOHALT, this means interrupts must be disabled except for the time tick, 
which should be reset to >=1ms. Care must be taken to avoid other system events 
that could interfere with this operation. A few examples are snooping, NMI, 
INIT, SMI and FLUSH."

For CPU's with Longhaul MSR this time is equal to 200us.

Rafał


----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Dave Jones]

On Wed, Jun 28, 2006 at 10:34:48AM -0700, Greg KH wrote:
 > On Wed, Jun 28, 2006 at 03:56:50PM +0200, Rafa? Bilski wrote:
 > > 	This patch will allow Longhaul cpufreq driver to change frequency
 > > without breaking BMDMA. In order to work properly it needs:
 > > - adding rw_semaphore to pci_device and bus structures - this is
 > > patch below,
 > > - Longhaul should find host bridge and lock write on bus before
 > > frequency change,
 > 
 > Eeek!  You mean the longhaul driver can change the frequency of the PCI
 > bus?  Oh, that's a recipe for disaster...

It *can* scale the FSB on some CPUs, but the Linux driver doesn't do that
as there a lot of systems that it just doesn't work on.  (Probably any
that have FSB+PCI speed tied together).  So we just scale the multiplier
and the voltage (Though currently in the driver, voltage scaling is missing,
so we never save any power, and just run at the maximum voltage the whole time).

The situation is : It needs there to be no bus mastering occuring at the time
of a CPU speed transition. Though I'm unable to find the part that mentions
this in the specs I have right now.

The really bizarre thing is that all this was working once.  Circa 2.5.late/2.6.reallyearly
I had reliable scaling of both voltage and speed on a C3.  Over time the
driver just seemed to fall apart. Perhaps we just got lucky before, and some
change occured that results changed behaviour of pci bus mastering for
some devices.

 > No, this is not acceptable.  What exactly do you want to do here?  Make
 > sure the PCI drivers are not doing DMA when the longhaul driver wants to
 > change the pci bus speed?
 > 
 > How often will this bus change happen?
 >
 > Does it really save battery?

99% of C3s aren't in battery powered devices, but it can save a considerable
amount of power (~75% on some of the earlier chips iirc).

Thankfully their newer cpu's aren't affected by this brain damage,
but there's a _lot_ of the older CPUs out there (all those EPIA boards etc).

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Alan Cox]

Ar Mer, 2006-06-28 am 10:34 -0700, ysgrifennodd Greg KH:
> Eeek!  You mean the longhaul driver can change the frequency of the PCI
> bus?  Oh, that's a recipe for disaster...

Not as I understand the docs, and that would be unfixable. Some C3
setups do however appear to "fall off the bus" during transitions which
means if BMDMA is active things get confused.

I am still not clear if this is just cache corruption through us not
listening or whether we genuinely need to halt. In the former case
flushing and disabling the CPU caches ought to be sufficient.

Alan

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Jeremy Fitzhardinge]

Alan Cox wrote:
> I am still not clear if this is just cache corruption through us not
> listening or whether we genuinely need to halt.
Especially buggy steppings of C3s would stop snooping while in 'hlt', so 
it wouldn't surprise me if they stopped while doing a speed transition.

>  In the former case
> flushing and disabling the CPU caches ought to be sufficient.
>   
Sounds reasonable, unless that causes problems of its own.  (My general 
experience with Via CPUs is that doing anything even slightly unusual 
will result in strange behaviour or outright buggyness.)

    J

Re: [PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Greg KH]

On Wed, Jun 28, 2006 at 03:56:50PM +0200, Rafa? Bilski wrote:
> 	This patch will allow Longhaul cpufreq driver to change frequency
> without breaking BMDMA. In order to work properly it needs:
> - adding rw_semaphore to pci_device and bus structures - this is
> patch below,
> - Longhaul should find host bridge and lock write on bus before
> frequency change,

Eeek!  You mean the longhaul driver can change the frequency of the PCI
bus?  Oh, that's a recipe for disaster...

> - device driver support - device should lock read its bus before
> starting DMA transfer. I have curently implemented this for ide
> layer (tested with via82cxxx), libata (not tested, but this is similar
> code to ide) and VIA Rhine network card driver.
> 	I don't know if this is acceptable infrastructure, but I hope it is
> less horrible then last. Is this infrastructure at all?

No, it's a hack :)

No, this is not acceptable.  What exactly do you want to do here?  Make
sure the PCI drivers are not doing DMA when the longhaul driver wants to
change the pci bus speed?

How often will this bus change happen?

Does it really save battery?

Will all PCI devices work properly at different speeds from what they
originally thought they were running at?

And what about PCI devices that always do DMA?  (think USB controllers,
they can easily saturate the PCI bus all the time).

Why not just suspend all PCI devices make the bus change, and then
resume them?  That would require no PCI core, or driver changes.

thanks,

greg k-h

[PATCH] (Longhaul 1/5) PCI: Protect bus master DMA from Longhaul by rw semaphores

[Rafał Bilski]

	This patch will allow Longhaul cpufreq driver to change frequency
without breaking BMDMA. In order to work properly it needs:
- adding rw_semaphore to pci_device and bus structures - this is
patch below,
- Longhaul should find host bridge and lock write on bus before
frequency change,
- device driver support - device should lock read its bus before
starting DMA transfer. I have curently implemented this for ide
layer (tested with via82cxxx), libata (not tested, but this is similar
code to ide) and VIA Rhine network card driver.
	I don't know if this is acceptable infrastructure, but I hope it is
less horrible then last. Is this infrastructure at all?

	This patch is adding 2 functions to pci structures: "acquire" and
"release". Driver calls "acquire" before starting transfer, with
PCI_ACQUIRE_EXCLUSIVE if it needs exclusive access to device (bus is
always PCI_ACQUIRE_SHARED) or with PCI_ACQUIRE_SHARED if device have
own hardware queue. Ide and libata are using PCI_ACQUIRE_EXCLUSIVE.
VIA Rhine driver is using PCI_ACQUIRE_SHARED.
	Note: "acquire" may sleep. But in Linux 2.6 we can use
workqueues and I'm using them.

Signed-off-by: Rafał Bilski <rafalbilski@interia.pl>

---

diff -uprN -X linux-2.6.17-vanilla/Documentation/dontdiff linux-2.6.17-vanilla/drivers/pci/probe.c linux-2.6.17/drivers/pci/probe.c
--- linux-2.6.17-vanilla/drivers/pci/probe.c	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.17/drivers/pci/probe.c	2006-06-28 09:03:20.000000000 +0200
@@ -9,6 +9,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/cpumask.h>
+#include <linux/rwsem.h>
 #include "pci.h"
 
 #define CARDBUS_LATENCY_TIMER	176	/* secondary latency timer */
@@ -315,6 +316,34 @@ void __devinit pci_read_bridge_bases(str
 	}
 }
 
+/**
+ * Generic bus locking
+ */
+
+#ifdef CONFIG_X86_LONGHAUL
+static void pci_bus_acquire(struct pci_bus *bus, int flags)
+{
+	if (bus->parent && bus->parent->acquire)
+		bus->parent->acquire(bus->parent, PCI_ACQUIRE_SHARED);
+	if (flags & PCI_ACQUIRE_EXCLUSIVE) {
+		down_write(&bus->access_sem);
+	} else {
+		down_read(&bus->access_sem);
+	}
+}
+
+static void pci_bus_release(struct pci_bus *bus, int flags)
+{
+	if (flags & PCI_ACQUIRE_EXCLUSIVE) {
+		up_write(&bus->access_sem);
+	} else {
+		up_read(&bus->access_sem);
+	}
+	if (bus->parent && bus->parent->release)
+		bus->parent->release(bus->parent, PCI_ACQUIRE_SHARED);
+}
+#endif
+
 static struct pci_bus * __devinit pci_alloc_bus(void)
 {
 	struct pci_bus *b;
@@ -324,6 +353,12 @@ static struct pci_bus * __devinit pci_al
 		INIT_LIST_HEAD(&b->node);
 		INIT_LIST_HEAD(&b->children);
 		INIT_LIST_HEAD(&b->devices);
+
+#ifdef CONFIG_X86_LONGHAUL
+		init_rwsem(&b->access_sem);
+		b->acquire = &pci_bus_acquire;
+	    	b->release = &pci_bus_release;
+#endif
 	}
 	return b;
 }
@@ -622,6 +657,34 @@ static void pci_read_irq(struct pci_dev 
 }
 
 /**
+ * Generic device locking
+ */
+
+#ifdef CONFIG_X86_LONGHAUL
+static void pci_generic_acquire(struct pci_dev *dev, int flags)
+{
+	if (dev->bus && dev->bus->acquire)
+		dev->bus->acquire(dev->bus, PCI_ACQUIRE_SHARED);
+	if (flags & PCI_ACQUIRE_EXCLUSIVE) {
+		down_write(&dev->access_sem);
+	} else {
+		down_read(&dev->access_sem);
+	}
+}
+
+static void pci_generic_release(struct pci_dev *dev, int flags)
+{
+	if (flags & PCI_ACQUIRE_EXCLUSIVE) {
+		up_write(&dev->access_sem);
+	} else {
+		up_read(&dev->access_sem);
+	}
+	if (dev->bus && dev->bus->release)
+		dev->bus->release(dev->bus, PCI_ACQUIRE_SHARED);
+}
+#endif
+
+/**
  * pci_setup_device - fill in class and map information of a device
  * @dev: the device structure to fill
  *
@@ -638,6 +701,11 @@ static int pci_setup_device(struct pci_d
 	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(dev->bus),
 		dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
 
+#ifdef CONFIG_X86_LONGHAUL
+	init_rwsem(&dev->access_sem);
+	dev->acquire = &pci_generic_acquire;
+	dev->release = &pci_generic_release;
+#endif
 	pci_read_config_dword(dev, PCI_CLASS_REVISION, &class);
 	class >>= 8;				    /* upper 3 bytes */
 	dev->class = class;
diff -uprN -X linux-2.6.17-vanilla/Documentation/dontdiff linux-2.6.17-vanilla/include/linux/pci.h linux-2.6.17/include/linux/pci.h
--- linux-2.6.17-vanilla/include/linux/pci.h	2006-06-18 03:49:35.000000000 +0200
+++ linux-2.6.17/include/linux/pci.h	2006-06-28 08:49:46.000000000 +0200
@@ -52,6 +52,7 @@
 #include <linux/list.h>
 #include <linux/errno.h>
 #include <linux/device.h>
+#include <linux/rwsem.h>
 
 /* File state for mmap()s on /proc/bus/pci/X/Y */
 enum pci_mmap_state {
@@ -169,6 +170,13 @@ struct pci_dev {
 	struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */
 	int rom_attr_enabled;		/* has display of the rom attribute been enabled? */
 	struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */
+#ifdef CONFIG_X86_LONGHAUL
+	struct rw_semaphore	access_sem;	/* Access control to device */
+	void (*acquire) (struct pci_dev *dev, int flags);
+	void (*release) (struct pci_dev *dev, int flags);
+#define PCI_ACQUIRE_SHARED		0
+#define PCI_ACQUIRE_EXCLUSIVE		(1 << 0)
+#endif
 };
 
 #define pci_dev_g(n) list_entry(n, struct pci_dev, global_list)
@@ -226,7 +234,6 @@ struct pci_bus {
 	struct pci_dev	*self;		/* bridge device as seen by parent */
 	struct resource	*resource[PCI_BUS_NUM_RESOURCES];
 					/* address space routed to this bus */
-
 	struct pci_ops	*ops;		/* configuration access functions */
 	void		*sysdata;	/* hook for sys-specific extension */
 	struct proc_dir_entry *procdir;	/* directory entry in /proc/bus/pci */
@@ -244,6 +251,11 @@ struct pci_bus {
 	struct class_device	class_dev;
 	struct bin_attribute	*legacy_io; /* legacy I/O for this bus */
 	struct bin_attribute	*legacy_mem; /* legacy mem */
+#ifdef CONFIG_X86_LONGHAUL
+	struct rw_semaphore	access_sem;	/* Access control to bus */
+	void (*acquire) (struct pci_bus *bus, int flags);
+	void (*release) (struct pci_bus *bus, int flags);
+#endif
 };
 
 #define pci_bus_b(n)	list_entry(n, struct pci_bus, node)




----------------------------------------------------------------------
PS. Fajny portal... >>> http://link.interia.pl/f196a