| Message ID | 1493351107-7157-1-git-send-email-thuth@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
On Fri, 28 Apr 2017 05:45:07 +0200 Thomas Huth <thuth@redhat.com> wrote: > If the memory range exceeds the 32-bit boundary, we should generate > a 64-bit range property entry instead of a 32-bit entry. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > slof/fs/pci-properties.fs | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs > index d446473..3d14181 100644 > --- a/slof/fs/pci-properties.fs > +++ b/slof/fs/pci-properties.fs > @@ -411,8 +411,9 @@ > 4 pick 28 + rtas-config-l@ \ fetch upper Basebits ( addr paddr plen limit.31:0 base.31:0 base.63:32 ) > 20 lshift or swap \ and calc Base ( addr paddr plen base.63:0 limit.31:0 ) > 4 pick 2C + rtas-config-l@ \ fetch upper Limitbits ( addr paddr plen base.63:0 limit.31:0 limit.63:32 ) > - 20 lshift or \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 ) > - 42000000 pci-bridge-gen-range \ and generate it ( addr paddr plen ) > + dup -rot 20 lshift or swap \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 limit.63:32 ) > + IF 43000000 ELSE 42000000 THEN \ 64-bit or 32-bit? ( addr paddr plen base.63:0 limit.63:0 type ) > + pci-bridge-gen-range \ and generate it ( addr paddr plen ) > ; > > \ generate an io space to the ranges property This is for pci-bridge-gen-mem-range, should not we create both 32bit _and_ 64bit windows, as we do already for PHB (I think we should)? -- Alexey
On 28.04.2017 07:13, Alexey Kardashevskiy wrote: > On Fri, 28 Apr 2017 05:45:07 +0200 > Thomas Huth <thuth@redhat.com> wrote: > >> If the memory range exceeds the 32-bit boundary, we should generate >> a 64-bit range property entry instead of a 32-bit entry. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> >> --- >> slof/fs/pci-properties.fs | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs >> index d446473..3d14181 100644 >> --- a/slof/fs/pci-properties.fs >> +++ b/slof/fs/pci-properties.fs >> @@ -411,8 +411,9 @@ >> 4 pick 28 + rtas-config-l@ \ fetch upper Basebits ( addr paddr plen limit.31:0 base.31:0 base.63:32 ) >> 20 lshift or swap \ and calc Base ( addr paddr plen base.63:0 limit.31:0 ) >> 4 pick 2C + rtas-config-l@ \ fetch upper Limitbits ( addr paddr plen base.63:0 limit.31:0 limit.63:32 ) >> - 20 lshift or \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 ) >> - 42000000 pci-bridge-gen-range \ and generate it ( addr paddr plen ) >> + dup -rot 20 lshift or swap \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 limit.63:32 ) >> + IF 43000000 ELSE 42000000 THEN \ 64-bit or 32-bit? ( addr paddr plen base.63:0 limit.63:0 type ) >> + pci-bridge-gen-range \ and generate it ( addr paddr plen ) >> ; >> >> \ generate an io space to the ranges property > > This is for pci-bridge-gen-mem-range, should not we create both 32bit > _and_ 64bit windows, as we do already for PHB (I think we should)? PCI bridges only have two (well, three if you also count the I/O space) memory spaces: 1) 32-bit non-prefetchable (aka MMIO) memory 2) Either 32- or 64-bit prefetchable memory A PCI bridge can not have both, 32-bit and 64-bit prefetchable memory at the same time. So no, it does not make sense to create two range entries for prefetchable memory space here (and the non-prefetchable 32-bit memory range is already created by the pci-bridge-gen-mmio-range function). Thomas
On 28/04/17 16:25, Thomas Huth wrote: > On 28.04.2017 07:13, Alexey Kardashevskiy wrote: >> On Fri, 28 Apr 2017 05:45:07 +0200 >> Thomas Huth <thuth@redhat.com> wrote: >> >>> If the memory range exceeds the 32-bit boundary, we should generate >>> a 64-bit range property entry instead of a 32-bit entry. >>> >>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> --- >>> slof/fs/pci-properties.fs | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs >>> index d446473..3d14181 100644 >>> --- a/slof/fs/pci-properties.fs >>> +++ b/slof/fs/pci-properties.fs >>> @@ -411,8 +411,9 @@ >>> 4 pick 28 + rtas-config-l@ \ fetch upper Basebits ( addr paddr plen limit.31:0 base.31:0 base.63:32 ) >>> 20 lshift or swap \ and calc Base ( addr paddr plen base.63:0 limit.31:0 ) >>> 4 pick 2C + rtas-config-l@ \ fetch upper Limitbits ( addr paddr plen base.63:0 limit.31:0 limit.63:32 ) >>> - 20 lshift or \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 ) >>> - 42000000 pci-bridge-gen-range \ and generate it ( addr paddr plen ) >>> + dup -rot 20 lshift or swap \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 limit.63:32 ) >>> + IF 43000000 ELSE 42000000 THEN \ 64-bit or 32-bit? ( addr paddr plen base.63:0 limit.63:0 type ) >>> + pci-bridge-gen-range \ and generate it ( addr paddr plen ) >>> ; >>> >>> \ generate an io space to the ranges property >> >> This is for pci-bridge-gen-mem-range, should not we create both 32bit >> _and_ 64bit windows, as we do already for PHB (I think we should)? > > PCI bridges only have two (well, three if you also count the I/O space) > memory spaces: > 1) 32-bit non-prefetchable (aka MMIO) memory > 2) Either 32- or 64-bit prefetchable memory > A PCI bridge can not have both, 32-bit and 64-bit prefetchable memory at > the same time. So no, it does not make sense to create two range entries > for prefetchable memory space here (and the non-prefetchable 32-bit > memory range is already created by the pci-bridge-gen-mmio-range function). Ah, I missed (again) that there is "-mmio-" version of it. Ok. Then thanks, I'll apply this but I also wonder - why do not we just make the second window 64bit always?
On 28.04.2017 08:52, Alexey Kardashevskiy wrote: > On 28/04/17 16:25, Thomas Huth wrote: >> On 28.04.2017 07:13, Alexey Kardashevskiy wrote: >>> On Fri, 28 Apr 2017 05:45:07 +0200 >>> Thomas Huth <thuth@redhat.com> wrote: >>> >>>> If the memory range exceeds the 32-bit boundary, we should generate >>>> a 64-bit range property entry instead of a 32-bit entry. >>>> >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>>> --- >>>> slof/fs/pci-properties.fs | 5 +++-- >>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs >>>> index d446473..3d14181 100644 >>>> --- a/slof/fs/pci-properties.fs >>>> +++ b/slof/fs/pci-properties.fs >>>> @@ -411,8 +411,9 @@ >>>> 4 pick 28 + rtas-config-l@ \ fetch upper Basebits ( addr paddr plen limit.31:0 base.31:0 base.63:32 ) >>>> 20 lshift or swap \ and calc Base ( addr paddr plen base.63:0 limit.31:0 ) >>>> 4 pick 2C + rtas-config-l@ \ fetch upper Limitbits ( addr paddr plen base.63:0 limit.31:0 limit.63:32 ) >>>> - 20 lshift or \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 ) >>>> - 42000000 pci-bridge-gen-range \ and generate it ( addr paddr plen ) >>>> + dup -rot 20 lshift or swap \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 limit.63:32 ) >>>> + IF 43000000 ELSE 42000000 THEN \ 64-bit or 32-bit? ( addr paddr plen base.63:0 limit.63:0 type ) >>>> + pci-bridge-gen-range \ and generate it ( addr paddr plen ) >>>> ; >>>> >>>> \ generate an io space to the ranges property >>> >>> This is for pci-bridge-gen-mem-range, should not we create both 32bit >>> _and_ 64bit windows, as we do already for PHB (I think we should)? >> >> PCI bridges only have two (well, three if you also count the I/O space) >> memory spaces: >> 1) 32-bit non-prefetchable (aka MMIO) memory >> 2) Either 32- or 64-bit prefetchable memory >> A PCI bridge can not have both, 32-bit and 64-bit prefetchable memory at >> the same time. So no, it does not make sense to create two range entries >> for prefetchable memory space here (and the non-prefetchable 32-bit >> memory range is already created by the pci-bridge-gen-mmio-range function). > > Ah, I missed (again) that there is "-mmio-" version of it. Ok. Then thanks, > I'll apply this but I also wonder - why do not we just make the second > window 64bit always? There are also PCI bridges that can handle 32-bit only (the upper 32-bit of the base and limit registers are hard-wired to 0 here). Thomas
diff --git a/slof/fs/pci-properties.fs b/slof/fs/pci-properties.fs index d446473..3d14181 100644 --- a/slof/fs/pci-properties.fs +++ b/slof/fs/pci-properties.fs @@ -411,8 +411,9 @@ 4 pick 28 + rtas-config-l@ \ fetch upper Basebits ( addr paddr plen limit.31:0 base.31:0 base.63:32 ) 20 lshift or swap \ and calc Base ( addr paddr plen base.63:0 limit.31:0 ) 4 pick 2C + rtas-config-l@ \ fetch upper Limitbits ( addr paddr plen base.63:0 limit.31:0 limit.63:32 ) - 20 lshift or \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 ) - 42000000 pci-bridge-gen-range \ and generate it ( addr paddr plen ) + dup -rot 20 lshift or swap \ and calc Limit ( addr paddr plen base.63:0 limit.63:0 limit.63:32 ) + IF 43000000 ELSE 42000000 THEN \ 64-bit or 32-bit? ( addr paddr plen base.63:0 limit.63:0 type ) + pci-bridge-gen-range \ and generate it ( addr paddr plen ) ; \ generate an io space to the ranges property
If the memory range exceeds the 32-bit boundary, we should generate a 64-bit range property entry instead of a 32-bit entry. Signed-off-by: Thomas Huth <thuth@redhat.com> --- slof/fs/pci-properties.fs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)