On Tuesday 11 March 2014 09:46:41 Liviu Dudau wrote:
> On Tue, Mar 11, 2014 at 06:50:24AM +, Arnd Bergmann wrote:
> > On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
> > >
> > > PCI_IOBASE is always defined. See the discussion with Russell on this
> > > subject.
> > >
> > >
On Tue, Mar 11, 2014 at 06:50:24AM +, Arnd Bergmann wrote:
> On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
> >
> > PCI_IOBASE is always defined. See the discussion with Russell on this
> > subject.
> >
> > include/asm-generic/io.h has at line 118:
> >
> > #ifndef PCI_IOBASE
> >
On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
>
> PCI_IOBASE is always defined. See the discussion with Russell on this subject.
>
> include/asm-generic/io.h has at line 118:
>
> #ifndef PCI_IOBASE
> #define PCI_IOBASE ((void __iomem *) 0)
> #endif
That is only defined for those that use
On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
PCI_IOBASE is always defined. See the discussion with Russell on this subject.
include/asm-generic/io.h has at line 118:
#ifndef PCI_IOBASE
#define PCI_IOBASE ((void __iomem *) 0)
#endif
That is only defined for those that use
On Tue, Mar 11, 2014 at 06:50:24AM +, Arnd Bergmann wrote:
On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
PCI_IOBASE is always defined. See the discussion with Russell on this
subject.
include/asm-generic/io.h has at line 118:
#ifndef PCI_IOBASE
#define PCI_IOBASE
On Tuesday 11 March 2014 09:46:41 Liviu Dudau wrote:
On Tue, Mar 11, 2014 at 06:50:24AM +, Arnd Bergmann wrote:
On Monday 10 March 2014 21:56:00 Liviu Dudau wrote:
PCI_IOBASE is always defined. See the discussion with Russell on this
subject.
include/asm-generic/io.h has
On Mon, Mar 10, 2014 at 07:59:59PM +0100, Arnd Bergmann wrote:
> On Monday 10 March 2014 16:33:44 Liviu Dudau wrote:
> > On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
> > > On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> > > > I will try to improve the error handling in the
On Monday 10 March 2014 20:16:25 Geert Uytterhoeven wrote:
> On Mon, Mar 10, 2014 at 7:59 PM, Arnd Bergmann wrote:
> >> arch/avr32/include/asm/io.h:#define IO_SPACE_LIMIT0x
> >> arch/frv/include/asm/io.h:#define IO_SPACE_LIMIT 0x
> >
> > They have no MMU, and the code
On Mon, Mar 10, 2014 at 7:59 PM, Arnd Bergmann wrote:
>> arch/avr32/include/asm/io.h:#define IO_SPACE_LIMIT0x
>> arch/frv/include/asm/io.h:#define IO_SPACE_LIMIT 0x
>
> They have no MMU, and the code relies on the port number to match
> both the virtual and the physical
On Monday 10 March 2014 16:33:44 Liviu Dudau wrote:
> On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
> > On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> > > I will try to improve the error handling in the next patchset version.
> > > However I am still confused about the
On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
> On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> > I will try to improve the error handling in the next patchset version.
> > However I am still confused about the earlier discussion on
> > pci_register_io_range(). Your
On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
> I will try to improve the error handling in the next patchset version.
> However I am still confused about the earlier discussion on
> pci_register_io_range(). Your suggestion initially was to return an
> error in the default weak
On Sat, Mar 08, 2014 at 05:15:08PM +, Arnd Bergmann wrote:
> On Wednesday 05 March 2014, Liviu Dudau wrote:
> > +
> > + pr_debug("Parsing ranges property...\n");
> > + for_each_of_pci_range(, ) {
> > + /* Read next ranges element */
> > + pr_debug("pci_space: 0x%08x
On Sat, Mar 08, 2014 at 05:15:08PM +, Arnd Bergmann wrote:
On Wednesday 05 March 2014, Liviu Dudau wrote:
+
+ pr_debug(Parsing ranges property...\n);
+ for_each_of_pci_range(parser, range) {
+ /* Read next ranges element */
+ pr_debug(pci_space: 0x%08x
On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
I will try to improve the error handling in the next patchset version.
However I am still confused about the earlier discussion on
pci_register_io_range(). Your suggestion initially was to return an
error in the default weak implementation,
On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
I will try to improve the error handling in the next patchset version.
However I am still confused about the earlier discussion on
pci_register_io_range(). Your suggestion
On Monday 10 March 2014 16:33:44 Liviu Dudau wrote:
On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
I will try to improve the error handling in the next patchset version.
However I am still confused about the earlier
On Mon, Mar 10, 2014 at 7:59 PM, Arnd Bergmann a...@arndb.de wrote:
arch/avr32/include/asm/io.h:#define IO_SPACE_LIMIT0x
arch/frv/include/asm/io.h:#define IO_SPACE_LIMIT 0x
They have no MMU, and the code relies on the port number to match
both the virtual and the
On Monday 10 March 2014 20:16:25 Geert Uytterhoeven wrote:
On Mon, Mar 10, 2014 at 7:59 PM, Arnd Bergmann a...@arndb.de wrote:
arch/avr32/include/asm/io.h:#define IO_SPACE_LIMIT0x
arch/frv/include/asm/io.h:#define IO_SPACE_LIMIT 0x
They have no MMU, and the code
On Mon, Mar 10, 2014 at 07:59:59PM +0100, Arnd Bergmann wrote:
On Monday 10 March 2014 16:33:44 Liviu Dudau wrote:
On Mon, Mar 10, 2014 at 03:21:01PM +, Arnd Bergmann wrote:
On Monday 10 March 2014 14:44:14 Liviu Dudau wrote:
I will try to improve the error handling in the next
On Wednesday 05 March 2014, Liviu Dudau wrote:
> +
> + pr_debug("Parsing ranges property...\n");
> + for_each_of_pci_range(, ) {
> + /* Read next ranges element */
> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> + range.pci_space,
On Fri, Mar 07, 2014 at 09:14:27PM +, Grant Likely wrote:
> On Wed, 5 Mar 2014 11:48:57 +, Liviu Dudau wrote:
> > Several platforms use a rather generic version of parsing
> > the device tree to find the host bridge ranges. Move the common code
> > into the generic PCI code and use it to
On Fri, Mar 07, 2014 at 09:14:27PM +, Grant Likely wrote:
On Wed, 5 Mar 2014 11:48:57 +, Liviu Dudau liviu.du...@arm.com wrote:
Several platforms use a rather generic version of parsing
the device tree to find the host bridge ranges. Move the common code
into the generic PCI code
On Wednesday 05 March 2014, Liviu Dudau wrote:
+
+ pr_debug(Parsing ranges property...\n);
+ for_each_of_pci_range(parser, range) {
+ /* Read next ranges element */
+ pr_debug(pci_space: 0x%08x pci_addr:0x%016llx ,
+
On Wed, 5 Mar 2014 11:48:57 +, Liviu Dudau wrote:
> Several platforms use a rather generic version of parsing
> the device tree to find the host bridge ranges. Move the common code
> into the generic PCI code and use it to create a pci_host_bridge
> structure that can be used by arch code.
>
On Wed, 5 Mar 2014 11:48:57 +, Liviu Dudau liviu.du...@arm.com wrote:
Several platforms use a rather generic version of parsing
the device tree to find the host bridge ranges. Move the common code
into the generic PCI code and use it to create a pci_host_bridge
structure that can be used
Several platforms use a rather generic version of parsing
the device tree to find the host bridge ranges. Move the common code
into the generic PCI code and use it to create a pci_host_bridge
structure that can be used by arch code.
Based on early attempts by Andrew Murray to unify the code.
Used
Several platforms use a rather generic version of parsing
the device tree to find the host bridge ranges. Move the common code
into the generic PCI code and use it to create a pci_host_bridge
structure that can be used by arch code.
Based on early attempts by Andrew Murray to unify the code.
Used
28 matches
Mail list logo
