Arnd Bergmann writes:
> Coming back to the specific pxa25x_udc case: using __raw_* accessors
> in the driver would possibly end up breaking the PXA25x machines in
> the (very unlikely) case that someone wants to make it work with
> big-endian kernels, assuming it does not have the same hardware
>
Arnd Bergmann writes:
> Ok, so I guess what this means is that ixp4xx (or xscale in general)
> implements its big-endian mode by adding a byteswap on its DRAM
> and PCI interfaces in be32 mode, rather than by changing the behavior of
> the load/store operations (as be8 mode does) or by having the
On Wednesday 17 February 2016 09:36:37 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > ixp4xx is really special in that it performs hardware swapping for
> > internal devices based on CPU endianess but not on PCI devices.
>
> Again, IXP4xx does not perform hardware (nor any other) swapping
Arnd Bergmann writes:
> ixp4xx is really special in that it performs hardware swapping for
> internal devices based on CPU endianess but not on PCI devices.
Again, IXP4xx does not perform hardware (nor any other) swapping for
registers of on-chip devices. The registers are connected 1:1,
bit 0 t
On Tuesday 16 February 2016 14:24:10 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > Both writes leave the CPU core within the spinlock but are not serialized
> > with anything else, so there is no ordering between the CPUs when they
> > enter the shared bus, other than having address befor
Arnd Bergmann writes:
> Both writes leave the CPU core within the spinlock but are not serialized
> with anything else, so there is no ordering between the CPUs when they
> enter the shared bus, other than having address before data. You'd
> expect to see address0, data0, address1, data1, but it
On Tuesday 16 February 2016 10:26:14 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > The barriers on a spinlock synchronize between CPUs but not an external
> > bus, so (on some architectures) a spinlock protecting an MMIO register
> > does not guarantee that two CPUs doing
> >
> > sp
Arnd Bergmann writes:
> The barriers on a spinlock synchronize between CPUs but not an external
> bus, so (on some architectures) a spinlock protecting an MMIO register
> does not guarantee that two CPUs doing
>
> spin_lock();
> __raw_writel(address);
> __raw_writel(data);
>
On Monday 15 February 2016 14:51:13 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > I consider the use of __raw_* accessors a bug, I don't think we should
> > ever do that because it hides how the hardware actually works, it doesn't
> > work with spinlocks, and it can lead to the compiler s
Arnd Bergmann writes:
> I consider the use of __raw_* accessors a bug, I don't think we should
> ever do that because it hides how the hardware actually works, it doesn't
> work with spinlocks, and it can lead to the compiler splitting up accesses
> into byte sized ones (not on ARM with the curre
On Monday 15 February 2016 08:33:37 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> >> Anyway, I think readl()/writel() do the right thing: in BE mode they
> >> swap PCI accesses and don't swap normal registers, in LE mode nothing is
> >> swapped.
> >
> > This seems to be true when CONFIG_IXP
Arnd Bergmann writes:
>> Anyway, I think readl()/writel() do the right thing: in BE mode they
>> swap PCI accesses and don't swap normal registers, in LE mode nothing is
>> swapped.
>
> This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> not otherwise. For the indirect variant, wr
On Friday 29 January 2016 21:03:40 Sergei Shtylyov wrote:
> On 01/29/2016 07:18 PM, Krzysztof Hałasa wrote:
>
> >> The unclear part here is for IXP4xx, which supports both big-endian
> >> and little-endian configurations. So far, the driver has done
> >> no byteswap in either case. I suspect that
Hello.
On 01/29/2016 07:18 PM, Krzysztof Hałasa wrote:
The unclear part here is for IXP4xx, which supports both big-endian
and little-endian configurations. So far, the driver has done
no byteswap in either case. I suspect that is wrong and it would
actually need to swap in one or the other cas
On Friday 29 January 2016 17:18:09 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > The unclear part here is for IXP4xx, which supports both big-endian
> > and little-endian configurations. So far, the driver has done
> > no byteswap in either case. I suspect that is wrong and it would
> > a
Arnd Bergmann writes:
> The unclear part here is for IXP4xx, which supports both big-endian
> and little-endian configurations. So far, the driver has done
> no byteswap in either case. I suspect that is wrong and it would
> actually need to swap in one or the other case, but I don't know
> which
Arnd Bergmann writes:
> This converts the pxa25x udc driver to use readl/writel as normal
> driver should do, rather than dereferencing __iomem pointers
> themselves.
>
> Based on the earlier preparation work, we can now also pass
> the register start in the device pointer so we no longer need
>
This converts the pxa25x udc driver to use readl/writel as normal
driver should do, rather than dereferencing __iomem pointers
themselves.
Based on the earlier preparation work, we can now also pass
the register start in the device pointer so we no longer need
the global variable.
The unclear par
18 matches
Mail list logo
