msaitoh@ wrote:
(2014/02/15 1:58), Izumi Tsutsui wrote:
I'd suggest to clarify what problems you are trying to solve
and consider how it should be solved, before updating your patch.
The problems you mentioned are:
(1) merge initialization of sparse register mappings (with 4 byte
Hi.
(2014/02/15 1:58), Izumi Tsutsui wrote:
I'd suggest to clarify what problems you are trying to solve
and consider how it should be solved, before updating your patch.
The problems you mentioned are:
(1) merge initialization of sparse register mappings (with 4 byte stride)
Right.
(2)
I'd suggest to clarify what problems you are trying to solve
and consider how it should be solved, before updating your patch.
The problems you mentioned are:
(1) merge initialization of sparse register mappings (with 4 byte stride)
(2) defer consinit() for puc com to use uvm_km_alloc() in it
Hi, Christos.
(2014/02/10 5:26), Christos Zoulas wrote:
In article 52f7c96e.6000...@execsw.org,
SAITOH Masanobu msai...@execsw.org wrote:
Hello, all.
I'm now working to support Intel Quark X1000.
This chip's internal com is MMIO(PCI_MAPREG_TYPE_MEM).
Our com and puc don't support such
Hello, Dennis, Tsutusi and others.
I'm sorry that I didn't reply quickly. While I was
absent, this thread became long :-)
I was unable to make a decision which mail I should reply to...
As I write below, adding byte order check for PCI devices
is my fault. So I'd reply to this mail to separate
On Tue, Feb 11, 2014 at 04:19:26PM +, Eduardo Horvath wrote:
We really should enhance the bus_dma framework to add bus_space-like
accessor routines so we can implement something like this. Using bswap is
a lousy way to implement byte swapping. Yes, on x86 you have byte swap
On Tue, 11 Feb 2014, David Laight wrote:
On Tue, Feb 11, 2014 at 04:19:26PM +, Eduardo Horvath wrote:
We really should enhance the bus_dma framework to add bus_space-like
accessor routines so we can implement something like this. Using bswap is
a lousy way to implement byte
On Tue, Feb 11, 2014 at 09:21:30PM +, Eduardo Horvath wrote:
What you don't want to have is an API that swaps data in memory
(unless that is really what you want to do).
IIRC modern gcc detects uses of its internal byteswap function
that are related to memory read/write and uses
On 11 Feb, 2014, at 13:21 , Eduardo Horvath e...@netbsd.org wrote:
When do you ever really want to byte swap the contents of one register to
another register? Byte swapping almost always involves I/O, which
means reading or writing memory or a device register. In this case we
are
msaitoh@ wrote:
Registers of Quark X1000's com are 4byte aligned.
Some other machines have such type of device, so
I modified COM_INIT_REGS() macro to support both
byte aligned and 4byte aligned. This change reduce
special modifications done in atheros, rmi and
marvell drivers.
Some
Such byte lane offset adjust ment is required only if
- byte registers are wired to LSByte in 32bit bus
- byte lane wiring are swapped by hardware (like osiop(4))
but most (all?) PCI bus_space(9) implementations swap
byteorder of PCI access by software (i.e. in MD bus_space(9)).
FYI: not
mrg@ wrote:
Such byte lane offset adjust ment is required only if
- byte registers are wired to LSByte in 32bit bus
- byte lane wiring are swapped by hardware (like osiop(4))
but most (all?) PCI bus_space(9) implementations swap
byteorder of PCI access by software (i.e. in MD
In article 52f7c96e.6000...@execsw.org,
SAITOH Masanobu msai...@execsw.org wrote:
Hello, all.
I'm now working to support Intel Quark X1000.
This chip's internal com is MMIO(PCI_MAPREG_TYPE_MEM).
Our com and puc don't support such type of device, yet.
To solve the problem, I wrote a patch.
13 matches
Mail list logo
