On Tuesday 11 December 2012, Russell King - ARM Linux wrote:
>
> On Tue, Dec 11, 2012 at 04:15:02PM +, Arnd Bergmann wrote:
> > On Tuesday 11 December 2012, Thomas Petazzoni wrote:
> > > On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
> > > > On Friday 07 December 2012, Thomas
On Tuesday 11 December 2012, Alan Cox wrote:
> > Plus, if you have IO space support, you must have some MMIO region for
> > them to target - doing what many platforms have done to date and targetted
> > ISA IO address 0 at virtual address 0 is just not on because as soon as
> > you build a device
On Tuesday 11 December 2012, Alan Cox wrote:
> The "no I/O space" case really applies to things like the S/390 mainframe
> which simply have no such concept on the system or the devices. In the
> ARM case the bus has an I/O space and the bridge glues the processors
> simpler model to the bridge
On Tue, Dec 11, 2012 at 05:45:09PM +, Alan Cox wrote:
> > The problem comes when you end up trying to deal with stuff which
> > uses ioread{8,16} on ioport_map() cookies where it's assumed that
> > adding N to the cookie is the same as adding N to the port address.
>
> It's a cookie - this
> The problem comes when you end up trying to deal with stuff which
> uses ioread{8,16} on ioport_map() cookies where it's assumed that
> adding N to the cookie is the same as adding N to the port address.
It's a cookie - this isn't a problem, you can support it via the mapping
approah. Whether
On Tue, Dec 11, 2012 at 05:16:10PM +, Alan Cox wrote:
> > Correct. If HAS_IOPORT is not selected then we are potentially missing
> > the dependent functions (because the platform has no IOPORT support) _or_
> > it does have ISA/PCI IO spaces _but_ they're not mappable via the
> > ioport_map()
> with it. It's very simple. The IO port space is for ISA/PCMCIA and
> PCI IO port regions. It is nothing more than that.
And on a lot of devices the LPC bus.
> Plus, if you _have_ IO space support, you must have some MMIO region for
> them to target - doing what many platforms have done to
> Could you enlighten my very naive understanding of things about PCI/ISA
> IO space? On x86, I seem to understand this is the separate address
> space accessed by the special in/out CPU instructions. Are there ARM
> platforms with the same sort of things?
An x86 processor has two address spaces
> Correct. If HAS_IOPORT is not selected then we are potentially missing
> the dependent functions (because the platform has no IOPORT support) _or_
> it does have ISA/PCI IO spaces _but_ they're not mappable via the
> ioport_map() mechanism due to some non-linearity involved in the
>
On Tue, Dec 11, 2012 at 05:30:13PM +0100, Thomas Petazzoni wrote:
> arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
> in this file, ioport_map() and ioport_unmap() are implement as soon as
> __io is defined. And basically, in arch/arm/include/asm/io.h, __io is
> defined for
On Tue, Dec 11, 2012 at 05:38:19PM +0100, Thomas Petazzoni wrote:
> Russell,
>
> On Tue, 11 Dec 2012 16:23:25 +, Russell King - ARM Linux wrote:
>
> > > * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
> > > to select this in combination with ARCH_MULTIPLATFORM, when some
On Tue, Dec 11, 2012 at 05:30:13PM +0100, Thomas Petazzoni wrote:
> arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
> in this file, ioport_map() and ioport_unmap() are implement as soon as
> __io is defined. And basically, in arch/arm/include/asm/io.h, __io is
> defined for
Russell,
On Tue, 11 Dec 2012 16:23:25 +, Russell King - ARM Linux wrote:
> > * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
> > to select this in combination with ARCH_MULTIPLATFORM, when some
> > of the other platforms you may enable actually have IOPORT mapping
> >
Dear Arnd Bergmann,
On Tue, 11 Dec 2012 16:15:02 +, Arnd Bergmann wrote:
> What you describe here are probable two bugs, and we should fix both:
>
> * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
> to select this in combination with ARCH_MULTIPLATFORM, when some
> of
On Tue, Dec 11, 2012 at 10:43:49AM +, Arnd Bergmann wrote:
> On Friday 07 December 2012, Thomas Petazzoni wrote:
> > The pcim_*() functions are used by the libata-sff subsystem, and this
> > subsystem is used for many SATA drivers on ARM platforms that do not
> > necessarily have I/O ports.
>
On Tue, Dec 11, 2012 at 04:15:02PM +, Arnd Bergmann wrote:
> On Tuesday 11 December 2012, Thomas Petazzoni wrote:
> > On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
> > > On Friday 07 December 2012, Thomas Petazzoni wrote:
> > > > The pcim_*() functions are used by the libata-sff
On Tuesday 11 December 2012, Thomas Petazzoni wrote:
> On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
> > On Friday 07 December 2012, Thomas Petazzoni wrote:
> > > The pcim_*() functions are used by the libata-sff subsystem, and this
> > > subsystem is used for many SATA drivers on ARM
Dear Arnd Bergmann,
On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
> On Friday 07 December 2012, Thomas Petazzoni wrote:
> > The pcim_*() functions are used by the libata-sff subsystem, and this
> > subsystem is used for many SATA drivers on ARM platforms that do not
> > necessarily
On Friday 07 December 2012, Thomas Petazzoni wrote:
> The pcim_*() functions are used by the libata-sff subsystem, and this
> subsystem is used for many SATA drivers on ARM platforms that do not
> necessarily have I/O ports.
I think this one is wrong as the CONFIG_HAS_IOPORT does not refer to the
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
I think this one is wrong as the CONFIG_HAS_IOPORT does not refer to the
Dear Arnd Bergmann,
On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O
On Tuesday 11 December 2012, Thomas Petazzoni wrote:
On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms
On Tue, Dec 11, 2012 at 04:15:02PM +, Arnd Bergmann wrote:
On Tuesday 11 December 2012, Thomas Petazzoni wrote:
On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem,
On Tue, Dec 11, 2012 at 10:43:49AM +, Arnd Bergmann wrote:
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
I
Dear Arnd Bergmann,
On Tue, 11 Dec 2012 16:15:02 +, Arnd Bergmann wrote:
What you describe here are probable two bugs, and we should fix both:
* ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
to select this in combination with ARCH_MULTIPLATFORM, when some
of the
Russell,
On Tue, 11 Dec 2012 16:23:25 +, Russell King - ARM Linux wrote:
* ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
to select this in combination with ARCH_MULTIPLATFORM, when some
of the other platforms you may enable actually have IOPORT mapping
On Tue, Dec 11, 2012 at 05:30:13PM +0100, Thomas Petazzoni wrote:
arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
in this file, ioport_map() and ioport_unmap() are implement as soon as
__io is defined. And basically, in arch/arm/include/asm/io.h, __io is
defined for all
On Tue, Dec 11, 2012 at 05:38:19PM +0100, Thomas Petazzoni wrote:
Russell,
On Tue, 11 Dec 2012 16:23:25 +, Russell King - ARM Linux wrote:
* ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
to select this in combination with ARCH_MULTIPLATFORM, when some
of
On Tue, Dec 11, 2012 at 05:30:13PM +0100, Thomas Petazzoni wrote:
arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
in this file, ioport_map() and ioport_unmap() are implement as soon as
__io is defined. And basically, in arch/arm/include/asm/io.h, __io is
defined for all
Correct. If HAS_IOPORT is not selected then we are potentially missing
the dependent functions (because the platform has no IOPORT support) _or_
it does have ISA/PCI IO spaces _but_ they're not mappable via the
ioport_map() mechanism due to some non-linearity involved in the
translation.
Could you enlighten my very naive understanding of things about PCI/ISA
IO space? On x86, I seem to understand this is the separate address
space accessed by the special in/out CPU instructions. Are there ARM
platforms with the same sort of things?
An x86 processor has two address spaces
A
with it. It's very simple. The IO port space is for ISA/PCMCIA and
PCI IO port regions. It is nothing more than that.
And on a lot of devices the LPC bus.
Plus, if you _have_ IO space support, you must have some MMIO region for
them to target - doing what many platforms have done to date
On Tue, Dec 11, 2012 at 05:16:10PM +, Alan Cox wrote:
Correct. If HAS_IOPORT is not selected then we are potentially missing
the dependent functions (because the platform has no IOPORT support) _or_
it does have ISA/PCI IO spaces _but_ they're not mappable via the
ioport_map()
The problem comes when you end up trying to deal with stuff which
uses ioread{8,16} on ioport_map() cookies where it's assumed that
adding N to the cookie is the same as adding N to the port address.
It's a cookie - this isn't a problem, you can support it via the mapping
approah. Whether you
On Tue, Dec 11, 2012 at 05:45:09PM +, Alan Cox wrote:
The problem comes when you end up trying to deal with stuff which
uses ioread{8,16} on ioport_map() cookies where it's assumed that
adding N to the cookie is the same as adding N to the port address.
It's a cookie - this isn't a
On Tuesday 11 December 2012, Alan Cox wrote:
The no I/O space case really applies to things like the S/390 mainframe
which simply have no such concept on the system or the devices. In the
ARM case the bus has an I/O space and the bridge glues the processors
simpler model to the bridge model.
On Tuesday 11 December 2012, Alan Cox wrote:
Plus, if you have IO space support, you must have some MMIO region for
them to target - doing what many platforms have done to date and targetted
ISA IO address 0 at virtual address 0 is just not on because as soon as
you build a device driver
On Tuesday 11 December 2012, Russell King - ARM Linux wrote:
On Tue, Dec 11, 2012 at 04:15:02PM +, Arnd Bergmann wrote:
On Tuesday 11 December 2012, Thomas Petazzoni wrote:
On Tue, 11 Dec 2012 10:43:49 +, Arnd Bergmann wrote:
On Friday 07 December 2012, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni
Cc: Paul Gortmaker
Cc: Jesse Barnes
Cc: Yinghai Lu
Cc: linux-kernel@vger.kernel.org
---
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: Jesse
40 matches
Mail list logo
