On Tuesday 29 January 2008 05:19:55 am Greg KH wrote:
> Hahahaha, oh, that's a good one...
>
> But what about the thousands of implementations out there that are
> buggy?
>
> I'm with Arjan here, I'm very skeptical.
Ugg, let's look at the actual data (again); I'm really not sure why people
are
On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote:
> Xorg doesn't do pci express ..
Xorg core provides a set of PCI config access functions (via sysfs) for
the graphics drivers. These functions do work correctly with offsets > 256
bytes. Can you guarantee that none of PCI-E video
On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote:
> On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> > Matthew, with Arjan's patch, is anything that currently works now
> > broken? Why do you feel it is somehow "wrong"?
>
> lspci is broken. It used to be able to access
On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote:
On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
Matthew, with Arjan's patch, is anything that currently works now
broken? Why do you feel it is somehow wrong?
lspci is broken. It used to be able to access extended
On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote:
Xorg doesn't do pci express ..
Xorg core provides a set of PCI config access functions (via sysfs) for
the graphics drivers. These functions do work correctly with offsets 256
bytes. Can you guarantee that none of PCI-E video
On Tuesday 29 January 2008 05:19:55 am Greg KH wrote:
Hahahaha, oh, that's a good one...
But what about the thousands of implementations out there that are
buggy?
I'm with Arjan here, I'm very skeptical.
Ugg, let's look at the actual data (again); I'm really not sure why people
are jumping
On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> > I'm more optimistic because we've so severely restricted the use of
> > mmconf after these patches that it's unlikely to cause problems. I also
> > hear Vista is now
Matthew Wilcox wrote:
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
Right now, that isn't a lot of people in x86 land, but your patch
encumbers drivers for non-x86 archs with an additional call to access
space that they've never had a problem with.
lets say s/x86/x86, IA64
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
> > Right now, that isn't a lot of people in x86 land, but your patch
> > encumbers drivers for non-x86 archs with an additional call to access
> > space that they've never had a problem with.
>
> lets say s/x86/x86, IA64 and
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
specific to legacy x86 hardware is, IMNSHO, a kludge.
in addition to pci_enable(), pci_enable_msi(), pci_enable_busmaster() they
already need to do
to enable various features?
These calls
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Tue, 29 Jan 2008 09:15:02 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >> Greg,
> >>
> >> The problem with Arjan's patch, if I understand it correctly, is
> >> that it requires
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
Greg,
The problem with Arjan's patch, if I understand it correctly, is that
it requires drivers to make a call to access extended PCI config
space.
And, IIRC, Arjan's patch encumbers drivers for
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Greg KH wrote:
> > On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> >> I'm more optimistic because we've so severely restricted the use of
> >> mmconf after these patches that it's unlikely to cause
Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems. I also
hear Vista is now using mmconf, so fewer implementations are going to
be
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
> On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
> > I think there's only one fundamental disagreement; and that is:
> > do we think that things are now totally fixed and no new major issues
> > will arrive after
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems.
I
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
specific to legacy x86 hardware is, IMNSHO, a kludge.
in addition to pci_enable(), pci_enable_msi(), pci_enable_busmaster() they
already need to do
to enable various features?
These calls
On Tue, 29 Jan 2008 10:15:45 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Greg,
The problem with Arjan's patch, if I understand it correctly, is
that it requires drivers to make a call to
Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems. I also
hear Vista is now using mmconf, so fewer implementations are going to
be
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
I think there's only one fundamental disagreement; and that is:
do we think that things are now totally fixed and no new major issues
will arrive after the fix
Arjan van de Ven wrote:
On Tue, 29 Jan 2008 09:15:02 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Greg,
The problem with Arjan's patch, if I understand it correctly, is that
it requires drivers to make a call to access extended PCI config
space.
And, IIRC, Arjan's patch encumbers drivers for
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
Right now, that isn't a lot of people in x86 land, but your patch
encumbers drivers for non-x86 archs with an additional call to access
space that they've never had a problem with.
lets say s/x86/x86, IA64 and architectures
Matthew Wilcox wrote:
On Tue, Jan 29, 2008 at 07:29:51AM -0800, Arjan van de Ven wrote:
Right now, that isn't a lot of people in x86 land, but your patch
encumbers drivers for non-x86 archs with an additional call to access
space that they've never had a problem with.
lets say s/x86/x86, IA64
On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote:
On Mon, Jan 28, 2008 at 08:18:04PM -0700, Matthew Wilcox wrote:
I'm more optimistic because we've so severely restricted the use of
mmconf after these patches that it's unlikely to cause problems. I also
hear Vista is now using
On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
> I think there's only one fundamental disagreement; and that is:
> do we think that things are now totally fixed and no new major issues
> will arrive after the "fix yet another mmconfig thing" patches are merged.
>
> If the
On Mon, 28 Jan 2008 12:44:31 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given Grant's suggestion any further consideration?
> >
> > I'd like to know how the MMCONFIG issues discussed in this thread
> > are
On Mon, Jan 28, 2008 at 02:53:34PM -0800, Greg KH wrote:
> Please send me patches, in a form that can be merged, along with a
> proper changelog entry, in the order in which you wish them to be
> applied, so I know exactly what changes you are referring to.
I'll send each patch as a reply to this
On Mon, Jan 28, 2008 at 03:31:42PM -0700, Matthew Wilcox wrote:
> On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> > On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > > Greg,
> > >
> > > Have you given Grant's suggestion any further consideration?
> > >
> > > I'd like to
On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
> On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> > Greg,
> >
> > Have you given Grant's suggestion any further consideration?
> >
> > I'd like to know how the MMCONFIG issues discussed in this thread are going
> > to be
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
> Greg,
>
> Have you given Grant's suggestion any further consideration?
>
> I'd like to know how the MMCONFIG issues discussed in this thread are going
> to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
>
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
rather have the upstream patch implemented, whatever it is.
Grant Grundler
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
rather have
On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream.
On Mon, Jan 28, 2008 at 03:31:42PM -0700, Matthew Wilcox wrote:
On Mon, Jan 28, 2008 at 12:44:31PM -0800, Greg KH wrote:
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the
On Mon, Jan 28, 2008 at 02:53:34PM -0800, Greg KH wrote:
Please send me patches, in a form that can be merged, along with a
proper changelog entry, in the order in which you wish them to be
applied, so I know exactly what changes you are referring to.
I'll send each patch as a reply to this
On Mon, 28 Jan 2008 12:44:31 -0800
Greg KH [EMAIL PROTECTED] wrote:
On Mon, Jan 28, 2008 at 01:32:06PM -0500, Tony Camuso wrote:
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread
are going to be
On Mon, Jan 28, 2008 at 07:05:05PM -0800, Arjan van de Ven wrote:
I think there's only one fundamental disagreement; and that is:
do we think that things are now totally fixed and no new major issues
will arrive after the fix yet another mmconfig thing patches are merged.
If the answer is
Greg,
Have you given Grant's suggestion any further consideration?
I'd like to know how the MMCONFIG issues discussed in this thread are going
to be handled upstream. I have a patch implemented in RHEL 5.2, but I would
rather have the upstream patch implemented, whatever it is.
Grant Grundler
On Tue, Jan 15, 2008 at 10:56:41AM -0700, Matthew Wilcox wrote:
> On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
> > But so far, we have a zillion patches floating around, claiming
> > different things, some with signed-off-bys and others without, so for
> > now, I'll just stick with
On Tue, Jan 15, 2008 at 10:56:41AM -0700, Matthew Wilcox wrote:
On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
But so far, we have a zillion patches floating around, claiming
different things, some with signed-off-bys and others without, so for
now, I'll just stick with Arjan's
On 1/15/2008 2:38 PM, Linus Torvalds wrote:
On Tue, 15 Jan 2008, Tony Camuso wrote:
Linus is confident that conf1 is not going away for at least the
next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have
On Tue, Jan 15, 2008 at 11:38:42AM -0800, Linus Torvalds wrote:
> On Tue, 15 Jan 2008, Tony Camuso wrote:
> > Linus is confident that conf1 is not going away for at least the
> > next five years.
>
> Not on PC's. Small birds tell me that there can be all these non-PC x86
> subarchitectures that
On Tue, 15 Jan 2008, Tony Camuso wrote:
>
> Linus is confident that conf1 is not going away for at least the
> next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have conf1.
Linus
--
To unsubscribe
I agree with Matthew.
My preference is Ivan's patch using Loic's proposal.
My patch would have tested MMCONFIG before using it, but it didn't
fix the problem where the decode of large displacement devices can
overlap the MMCONFIG region.
Ivan's patch fixes that, and the problem of Northbridges
On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
> But so far, we have a zillion patches floating around, claiming
> different things, some with signed-off-bys and others without, so for
> now, I'll just stick with Arjan's patch in -mm and see if anyone
> complains about those releases...
On Tue, Jan 15, 2008 at 11:00:37AM -0500, Loic Prylli wrote:
>
>
> On 1/14/2008 6:04 PM, Adrian Bunk wrote:
>>> I thought so, but due to the way that things are initialised, mmconfig
>>> happens before conf1. conf1 is known to be usable, but hasn't set
>>> raw_pci_ops at this point. Confusing,
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not ideal, but fixing this
isn't in scope for 2.6.24.
...
*ahem*
I just thought this might be interesting to the discussion.
I recently bought another 2 GB memory for my computer.
My hardware is as following:
Asus Commando (Intel P965 chipset)
Intel Core2 Q6600
4x1 GB Geil PC6400 memory
nVidia 8800 gts (old g80 core, 640 mb mem)
Without booting with
I just thought this might be interesting to the discussion.
I recently bought another 2 GB memory for my computer.
My hardware is as following:
Asus Commando (Intel P965 chipset)
Intel Core2 Q6600
4x1 GB Geil PC6400 memory
nVidia 8800 gts (old g80 core, 640 mb mem)
Without booting with
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not ideal, but fixing this
isn't in scope for 2.6.24.
...
*ahem*
On Tue, Jan 15, 2008 at 11:00:37AM -0500, Loic Prylli wrote:
On 1/14/2008 6:04 PM, Adrian Bunk wrote:
I thought so, but due to the way that things are initialised, mmconfig
happens before conf1. conf1 is known to be usable, but hasn't set
raw_pci_ops at this point. Confusing, and not
On Tue, Jan 15, 2008 at 09:46:43AM -0800, Greg KH wrote:
But so far, we have a zillion patches floating around, claiming
different things, some with signed-off-bys and others without, so for
now, I'll just stick with Arjan's patch in -mm and see if anyone
complains about those releases...
I
I agree with Matthew.
My preference is Ivan's patch using Loic's proposal.
My patch would have tested MMCONFIG before using it, but it didn't
fix the problem where the decode of large displacement devices can
overlap the MMCONFIG region.
Ivan's patch fixes that, and the problem of Northbridges
On Tue, Jan 15, 2008 at 11:38:42AM -0800, Linus Torvalds wrote:
On Tue, 15 Jan 2008, Tony Camuso wrote:
Linus is confident that conf1 is not going away for at least the
next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or
On Tue, 15 Jan 2008, Tony Camuso wrote:
Linus is confident that conf1 is not going away for at least the
next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have conf1.
Linus
--
To unsubscribe from
On 1/15/2008 2:38 PM, Linus Torvalds wrote:
On Tue, 15 Jan 2008, Tony Camuso wrote:
Linus is confident that conf1 is not going away for at least the
next five years.
Not on PC's. Small birds tell me that there can be all these non-PC x86
subarchitectures that may or may not have
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the
On Mon, Jan 14, 2008 at 03:52:26PM -0700, Matthew Wilcox wrote:
> On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
>...
> > > - pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0xce, 2, );
> > > + pci_direct_conf1.read(0, 0, PCI_DEVFN(0,0), 0xce, 2, );
> >
> > couldn't this (at least in
On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
> would be nice the "reg > 256 && raw_pci_Ext_ops==NULL" case would just
> call the raw_pci_ops-> pointer, to give that a chance of refusal
> (but I guess that shouldn't really happen)
We don't have a situation where that can
Arjan van de Ven wrote:
it's not pci_enable_mmconf(), it's pci_enable_extended_config_space... it's
independent of the mechanism!
Arjan, you would be foisting this call on device drivers running on
arches that don't need any such distinction between extended config
space and < 256 bytes.
I
On Mon, 14 Jan 2008 10:23:14 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Mon, 14 Jan 2008 08:01:01 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >>
> >> If we're going to differentiate MMCONFIG from
> >> some other access mechanism, it only needs to be done
Arjan van de Ven wrote:
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
>>
If we're going to differentiate MMCONFIG from
some other access mechanism, it only needs to be done at the
Northbridge level. Devices are electrically ignorant of the protocol
used between CPU
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sun, 13 Jan 2008 22:29:23 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >> . There is no need to provide different PCI config access
> >>mechanisms at device granularity, since
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the
> > even when designed for Redmond products.
>
> I find it hard to believe that even they have their drivers do PCI config
> access via ports directly from the drivers,
> and especially in driver reference code...
Microsoft may not but the standard of Taiwanese driver code (and by
reference I
even when designed for Redmond products.
I find it hard to believe that even they have their drivers do PCI config
access via ports directly from the drivers,
and especially in driver reference code...
Microsoft may not but the standard of Taiwanese driver code (and by
reference I mean
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config
Arjan van de Ven wrote:
it's not pci_enable_mmconf(), it's pci_enable_extended_config_space... it's
independent of the mechanism!
Arjan, you would be foisting this call on device drivers running on
arches that don't need any such distinction between extended config
space and 256 bytes.
I
On Mon, 14 Jan 2008 10:23:14 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Mon, 14 Jan 2008 08:01:01 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
If we're going to differentiate MMCONFIG from
some other access mechanism, it only needs to be done at the
On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
would be nice the reg 256 raw_pci_Ext_ops==NULL case would just
call the raw_pci_ops- pointer, to give that a chance of refusal
(but I guess that shouldn't really happen)
We don't have a situation where that can happen -- all
On Mon, Jan 14, 2008 at 03:52:26PM -0700, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 09:01:08AM -0800, Arjan van de Ven wrote:
...
- pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0xce, 2, win);
+ pci_direct_conf1.read(0, 0, PCI_DEVFN(0,0), 0xce, 2, win);
couldn't this (at least in some
Arjan van de Ven wrote:
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the
On Mon, 14 Jan 2008, Alan Cox wrote:
> >
> > As someone gently pointed out to me, you are in a position to know this,
> > so I probably am wrong.
>
> I suspect Arjan is wrong. It might be some Intel agenda but I still see
> fairly new driver reference code that is hardcoding port accesses even
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> . There is no need to provide different PCI config access
>mechanisms at device granularity, since the PCI config access
>mechanism between the CPU and the Northbridge is opaque to
>the devices. PCI config
To all ...
Well, here is what I perceive we've got so far.
. Some PCI Northbridges do not work with MMCONFIG.
. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can
On Mon, 14 Jan 2008 00:54:34 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 13 Jan 2008 16:28:08 -0500
> Tony Camuso <[EMAIL PROTECTED]> wrote:
>
> > Arjan van de Ven wrote:
> >
> > >> The PCI spec provides for conf1 as an architected solution. It's
> > >> not going away, and especially
On Sun, 13 Jan 2008 16:28:08 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
>
> >> The PCI spec provides for conf1 as an architected solution. It's not
> >> going away, and especially not in x86 land where Port IO is built-in
> >> to the CPU.
> >
> > again sadly you're
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As someone gently pointed out to me, you are in a position to know this,
so I probably am
On 1/13/2008 3:43 PM, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between "need" and "will not be used in
the patches that use legacy for < 256". In the other patches posted,
extended config space will be used
On 1/13/2008 1:41 PM, Arjan van de Ven wrote:
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
> Note: There is not a 100% overlap between "need" and "will not be used in
> the patches that use legacy for < 256". In the other patches posted,
> extended config space will be used in cases where it won't be with my
> patch.
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli <[EMAIL PROTECTED]> wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
>
> 2) the pci_enable_ext_config() function and dev->ext_cfg_space field,
> sysfs interface should be
On 1/12/2008 12:45 PM, Arjan van de Ven wrote:
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky <[EMAIL PROTECTED]> wrote:
+ if (reg < 256)
+ return pci_conf1_read(seg,bus,devfn,reg,len,value);
+
btw this is my main objection to your patch; it intertwines the
On Sun, 13 Jan 2008 07:43:11 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven wrote:
> > On Sat, 12 Jan 2008 20:36:59 -0500
> > Tony Camuso <[EMAIL PROTECTED]> wrote:
> >
> >
> > Just about NOBODY has devices that need the extended config space.
> > At all.
>
> The PCI express
as a general thing I like where this patch is going
On Sun, 13 Jan 2008 00:24:15 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> +
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int
> devfn,
> + int reg, int len,
> u32 *val) +{
>
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso <[EMAIL PROTECTED]> wrote:
Just about NOBODY has devices that need the extended config space. At all.
The PCI express spec requires the platform to provide access to this space
for express-compliance. More devices will be
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Just about NOBODY has devices that need the extended config space. At all.
The PCI express spec requires the platform to provide access to this space
for express-compliance. More devices will be
as a general thing I like where this patch is going
On Sun, 13 Jan 2008 00:24:15 -0700
Matthew Wilcox [EMAIL PROTECTED] wrote:
+
+int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int
devfn,
+ int reg, int len,
u32 *val) +{
+ if
On Sun, 13 Jan 2008 07:43:11 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Sat, 12 Jan 2008 20:36:59 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Just about NOBODY has devices that need the extended config space.
At all.
The PCI express spec requires the
On 1/12/2008 12:45 PM, Arjan van de Ven wrote:
On Sat, 12 Jan 2008 17:40:30 +0300
Ivan Kokshaysky [EMAIL PROTECTED] wrote:
+ if (reg 256)
+ return pci_conf1_read(seg,bus,devfn,reg,len,value);
+
btw this is my main objection to your patch; it intertwines the conf1
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli [EMAIL PROTECTED] wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and dev-ext_cfg_space field,
sysfs interface should be removed from
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between need and will not be used in
the patches that use legacy for 256. In the other patches posted,
extended config space will be used in cases where it won't be with my
patch. (Most
On 1/13/2008 1:41 PM, Arjan van de Ven wrote:
On Sun, 13 Jan 2008 13:23:35 -0500
Loic Prylli [EMAIL PROTECTED] wrote:
Matthew pointed a patch that basically does what you suggested; only one
comment on your mail left after that:
2) the pci_enable_ext_config() function and
On 1/13/2008 3:43 PM, Matthew Wilcox wrote:
On Sun, Jan 13, 2008 at 10:41:24AM -0800, Arjan van de Ven wrote:
Note: There is not a 100% overlap between need and will not be used in
the patches that use legacy for 256. In the other patches posted,
extended config space will be used in
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As someone gently pointed out to me, you are in a position to know this,
so I probably am
On Sun, 13 Jan 2008 16:28:08 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's not
going away, and especially not in x86 land where Port IO is built-in
to the CPU.
again sadly you're wrong.
As
On Mon, 14 Jan 2008 00:54:34 +
Alan Cox [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 16:28:08 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
The PCI spec provides for conf1 as an architected solution. It's
not going away, and especially not in x86 land where
To all ...
Well, here is what I perceive we've got so far.
. Some PCI Northbridges do not work with MMCONFIG.
. Some PCI BARs can overlap the MMCONFIG area during bus sizing.
It is hoped that new BIOSes will locate MMCONFIG in an area
safely out of the way of bus sizing code, but there can
On Sun, 13 Jan 2008 22:29:23 -0500
Tony Camuso [EMAIL PROTECTED] wrote:
. There is no need to provide different PCI config access
mechanisms at device granularity, since the PCI config access
mechanism between the CPU and the Northbridge is opaque to
the devices. PCI config
1 - 100 of 240 matches
Mail list logo
