On Fri, May 6, 2016 at 11:26 AM, Bjorn Helgaas wrote:
>> v3, that have more change to pass *res to make powerpc prot setting simple.
>
> This looks corrupted. On v4.6-rc2:
>
> $ stg import -M m/yh3
> Checking for changes in the working directory ... done
> Importing
On Fri, May 6, 2016 at 11:26 AM, Bjorn Helgaas wrote:
>> v3, that have more change to pass *res to make powerpc prot setting simple.
>
> This looks corrupted. On v4.6-rc2:
>
> $ stg import -M m/yh3
> Checking for changes in the working directory ... done
> Importing patch
On Thu, May 05, 2016 at 08:53:14AM -0700, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 5:25 PM, Yinghai Lu wrote:
> > On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
> >> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
> >>> My
On Thu, May 05, 2016 at 08:53:14AM -0700, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 5:25 PM, Yinghai Lu wrote:
> > On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
> >> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
> >>> My goal is to make pci_mmap_resource() and proc_bus_pci_mmap()
On Thu, May 5, 2016 at 5:56 PM, Yinghai Lu wrote:
> On Thu, May 5, 2016 at 3:02 PM, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
>>> For powerpc io port, we still need extra offset from resource address
>>>
On Thu, May 5, 2016 at 5:56 PM, Yinghai Lu wrote:
> On Thu, May 5, 2016 at 3:02 PM, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
>>> For powerpc io port, we still need extra offset from resource address
>>> to final address.
>>>
>>> resource_size_t
On Thu, May 5, 2016 at 3:02 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
>> For powerpc io port, we still need extra offset from resource address
>> to final address.
>>
>> resource_size_t offset =
>>
On Thu, May 5, 2016 at 3:02 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
>> For powerpc io port, we still need extra offset from resource address
>> to final address.
>>
>> resource_size_t offset =
>> ((resource_size_t)vma->vm_pgoff) <<
On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
> For powerpc io port, we still need extra offset from resource address
> to final address.
>
> resource_size_t offset =
> ((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
>
> + if (mmap_state == pci_mmap_io) {
> +
On Thu, 2016-05-05 at 08:53 -0700, Yinghai Lu wrote:
> For powerpc io port, we still need extra offset from resource address
> to final address.
>
> resource_size_t offset =
> ((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
>
> + if (mmap_state == pci_mmap_io) {
> +
On Wed, May 4, 2016 at 5:25 PM, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
>> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>>> My goal is to make pci_mmap_resource() and proc_bus_pci_mmap() look
>>>
On Wed, May 4, 2016 at 5:25 PM, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
>> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>>> My goal is to make pci_mmap_resource() and proc_bus_pci_mmap() look
>>> very similar, e.g.,
>>>
>>> /* locate resource */
>>>
On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>> My goal is to make pci_mmap_resource() and proc_bus_pci_mmap() look
>> very similar, e.g.,
>>
>> /* locate resource */
>>
On Wed, May 4, 2016 at 11:46 AM, Yinghai Lu wrote:
> On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>> My goal is to make pci_mmap_resource() and proc_bus_pci_mmap() look
>> very similar, e.g.,
>>
>> /* locate resource */
>> pci_user_to_resource()# only in
On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>
> What mess do you mean? The fact that you could only use
> pcibios_bus_to_resource() for MEM, and something else for IO? Even
> if we could only use pcibios_bus_to_resource() for MEM, that sounds
> like an improvement,
On Wed, May 4, 2016 at 8:17 AM, Bjorn Helgaas wrote:
>
> What mess do you mean? The fact that you could only use
> pcibios_bus_to_resource() for MEM, and something else for IO? Even
> if we could only use pcibios_bus_to_resource() for MEM, that sounds
> like an improvement, not a mess.
I means
On Tue, May 03, 2016 at 10:52:33PM -0700, Yinghai Lu wrote:
> On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu wrote:
> > On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
> >> I did not propose changing any user-visible ABI. To recap what I did
> >>
On Tue, May 03, 2016 at 10:52:33PM -0700, Yinghai Lu wrote:
> On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu wrote:
> > On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
> >> I did not propose changing any user-visible ABI. To recap what I did
> >> propose:
> >
> > I want to avoid introduce one
On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu wrote:
> On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
>> I did not propose changing any user-visible ABI. To recap what I did
>> propose:
>
> I want to avoid introduce one strange pci_user_to_resource.
>
On Tue, May 3, 2016 at 10:08 PM, Yinghai Lu wrote:
> On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
>> I did not propose changing any user-visible ABI. To recap what I did
>> propose:
>
> I want to avoid introduce one strange pci_user_to_resource.
>
>>
>> - The sysfs path uses offsets
On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
> On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
>>
>> The problem tends to be old Xserver expectations...
>>
>> That stuff has been a can of worms over the years and we did things in
>> the kernel
On Tue, May 3, 2016 at 6:25 PM, Bjorn Helgaas wrote:
> On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
>>
>> The problem tends to be old Xserver expectations...
>>
>> That stuff has been a can of worms over the years and we did things in
>> the kernel to work around X
From: Benjamin Herrenschmidt
Date: Wed, 04 May 2016 10:37:40 +1000
> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
>> BenH and DavidM,
>> Are you ok to let /proc/bus/pci/devices to expose resource value
>> instead of
>> BAR value?
>> powerpc already expose MMIO
From: Benjamin Herrenschmidt
Date: Wed, 04 May 2016 10:37:40 +1000
> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
>> BenH and DavidM,
>> Are you ok to let /proc/bus/pci/devices to expose resource value
>> instead of
>> BAR value?
>> powerpc already expose MMIO as resource value, but
On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
> > BenH and DavidM,
> > Are you ok to let /proc/bus/pci/devices to expose resource value
> > instead of
> > BAR value?
> > powerpc already expose MMIO as resource value,
On Wed, May 04, 2016 at 10:37:40AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
> > BenH and DavidM,
> > Are you ok to let /proc/bus/pci/devices to expose resource value
> > instead of
> > BAR value?
> > powerpc already expose MMIO as resource value,
On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
> BenH and DavidM,
> Are you ok to let /proc/bus/pci/devices to expose resource value
> instead of
> BAR value?
> powerpc already expose MMIO as resource value, but still keep IO as
> BAR value?
>
> Or can we just dump /proc/bus/pci support
On Tue, 2016-05-03 at 15:52 -0700, Yinghai Lu wrote:
> BenH and DavidM,
> Are you ok to let /proc/bus/pci/devices to expose resource value
> instead of
> BAR value?
> powerpc already expose MMIO as resource value, but still keep IO as
> BAR value?
>
> Or can we just dump /proc/bus/pci support
On Fri, Apr 29, 2016 at 12:19 AM, Yinghai Lu wrote:
> On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote:
>>
>> 1) The sysfs path uses offsets between 0 and BAR size. This path
>> should work identically on all arches. "User" addresses are not
>>
On Fri, Apr 29, 2016 at 12:19 AM, Yinghai Lu wrote:
> On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote:
>>
>> 1) The sysfs path uses offsets between 0 and BAR size. This path
>> should work identically on all arches. "User" addresses are not
>> involved, so it doesn't make sense that this
On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote:
> On Wed, Apr 27, 2016 at 09:55:45PM -0700, Yinghai Lu wrote:
>> On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
>> > [+cc Ben, Michael]
>> > I'm kind of confused here. There are two ways to mmap
On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas wrote:
> On Wed, Apr 27, 2016 at 09:55:45PM -0700, Yinghai Lu wrote:
>> On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
>> > [+cc Ben, Michael]
>> > I'm kind of confused here. There are two ways to mmap PCI BARs:
>> >
>> >
On Wed, Apr 27, 2016 at 09:55:45PM -0700, Yinghai Lu wrote:
> On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
> > [+cc Ben, Michael]
> > I'm kind of confused here. There are two ways to mmap PCI BARs:
> >
> > /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()):
> > all
On Wed, Apr 27, 2016 at 09:55:45PM -0700, Yinghai Lu wrote:
> On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
> > [+cc Ben, Michael]
> > I'm kind of confused here. There are two ways to mmap PCI BARs:
> >
> > /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()):
> > all BARs in one file;
On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
> [+cc Ben, Michael]
> I'm kind of confused here. There are two ways to mmap PCI BARs:
>
> /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()):
> all BARs in one file; MEM/IO determined by ioctl()
> mmap offset is a CPU
On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote:
> [+cc Ben, Michael]
> I'm kind of confused here. There are two ways to mmap PCI BARs:
>
> /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()):
> all BARs in one file; MEM/IO determined by ioctl()
> mmap offset is a CPU physical address in
[+cc Ben, Michael]
On Thu, Apr 07, 2016 at 05:15:17PM -0700, Yinghai Lu wrote:
> After we added 64bit mmio parsing, we got some "no compatible bridge window"
> warning on anther new model that support 64bit resource.
>
> It turns out that we can not use mem_space.start as 64bit mem space
>
[+cc Ben, Michael]
On Thu, Apr 07, 2016 at 05:15:17PM -0700, Yinghai Lu wrote:
> After we added 64bit mmio parsing, we got some "no compatible bridge window"
> warning on anther new model that support 64bit resource.
>
> It turns out that we can not use mem_space.start as 64bit mem space
>
After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.
It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.
Use child_phys_addr to calculate exact offset
After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.
It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.
Use child_phys_addr to calculate exact offset
40 matches
Mail list logo