Wolfgang,
On Mon, Jan 17, 2011 at 4:27 PM, Wolfgang Denk wrote:
> Dear Tom Warren,
>
> In message you
> wrote:
>>
>> 1) IO access functions - I pre-reviewed my patch series with Wolfgang
>> (to hopefully catch any blatant errors and smooth
>> the process) and he indicated that C structs and I/O
Dear Tom Warren,
In message you
wrote:
>
> So instead of, say uart->lcr = 0, you'd prefer writel(0, uart->lcr),
> where writel = __arch_putl(v, a) = (*(volatile unsigned int *)(a) =
> (v))?
Please see the thread "ARM: Avoid compiler optimization for usages of
readb, writeb and friends."
> Is t
Dear Tom Warren,
In message you
wrote:
>
> 1) IO access functions - I pre-reviewed my patch series with Wolfgang
> (to hopefully catch any blatant errors and smooth
> the process) and he indicated that C structs and I/O accessor funcs or
> macros were preferred to my base+offset original code.
Dear Peter Tyser,
In message <1295047406.29642.6729.camel@petert> you wrote:
>
> Agreed, I should have dug deeper. On PPC we use out_be32() or similar
> to access memory mapped registers, which does have an explicit barrier.
> I'm not familiar with ARM so don't know what the proper access functi
On Sat, 2011-01-15 at 00:00 +0100, Albert ARIBAUD wrote:
> Hello,
>
> Le 14/01/2011 23:39, Tom Warren a écrit :
>
> > So instead of, say uart->lcr = 0, you'd prefer writel(0, uart->lcr),
> > where writel = __arch_putl(v, a) = (*(volatile unsigned int *)(a) =
> > (v))?
> > Is that different enough
Hello,
Le 14/01/2011 23:39, Tom Warren a écrit :
> So instead of, say uart->lcr = 0, you'd prefer writel(0, uart->lcr),
> where writel = __arch_putl(v, a) = (*(volatile unsigned int *)(a) =
> (v))?
> Is that different enough from 'uart->lcr = 0' to warrant the change?
> Does it add some HW barrie
On Fri, Jan 14, 2011 at 2:36 PM, Peter Tyser wrote:
> On Fri, 2011-01-14 at 13:41 -0700, Tom Warren wrote:
>> On Fri, Jan 14, 2011 at 12:59 PM, Peter Tyser wrote:
>> > Hi Tom,
>> >
>> > On Fri, 2011-01-14 at 10:11 -0700, Tom Warren wrote:
>> >> This series of patches adds preliminary/baseline sup
On Fri, 2011-01-14 at 13:41 -0700, Tom Warren wrote:
> On Fri, Jan 14, 2011 at 12:59 PM, Peter Tyser wrote:
> > Hi Tom,
> >
> > On Fri, 2011-01-14 at 10:11 -0700, Tom Warren wrote:
> >> This series of patches adds preliminary/baseline support for NVIDIA's
> >> Tegra2 SoC. Basic CPU (AVP), RAM and
On Fri, Jan 14, 2011 at 12:59 PM, Peter Tyser wrote:
> Hi Tom,
>
> On Fri, 2011-01-14 at 10:11 -0700, Tom Warren wrote:
>> This series of patches adds preliminary/baseline support for NVIDIA's
>> Tegra2 SoC. Basic CPU (AVP), RAM and UART init are covered so that the
>> system (Harmony or Seaboard
Hi Tom,
On Fri, 2011-01-14 at 10:11 -0700, Tom Warren wrote:
> This series of patches adds preliminary/baseline support for NVIDIA's
> Tegra2 SoC. Basic CPU (AVP), RAM and UART init are covered so that the
> system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.
>
> Further suppo
This series of patches adds preliminary/baseline support for NVIDIA's
Tegra2 SoC. Basic CPU (AVP), RAM and UART init are covered so that the
system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.
Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow.
V2: Make change
11 matches
Mail list logo
