On Fri, 6 May 2011, Ramana Radhakrishnan wrote:
> On 6 May 2011 16:06, Ken Werner wrote:
> >
> > Currently the GCC ARM backend doesn't provide a pattern to inline 64bit
> > __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The
> > libgcc does not provide these symbols via t
Ken,
On 05/06/2011 10:25 AM, Richard Earnshaw wrote:
On Fri, 2011-05-06 at 17:06 +0200, Ken Werner wrote:
Hi,
We've been thinking about adding support for the built-in functions for 64bit
atomic memory access and I'd like to know if this is of any interest.
Currently the main use of these fun
On 6 May 2011 19:57, David Gilbert wrote:
> 2011/5/6 Christian Robottom Reis :
> I don't think there are that many things that are vastly useful for the
> kernel,
> but here is a summary (I intend to write a full report at some point but
> am still fighting SPEC for some benchmark stats and some
2011/5/6 Christian Robottom Reis :
> On Thu, May 05, 2011 at 04:08:01PM +0100, Måns Rullgård wrote:
>> >> Incidentally, this ties into the question sent earlier this week which
>> >> had to do with Nico's work item in:
>> >>
>> >> https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-
On 6 May 2011 16:06, Ken Werner wrote:
>
> Currently the GCC ARM backend doesn't provide a pattern to inline 64bit
> __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The
> libgcc does not provide these symbols via the usual thin wrapper around the
> kernel helper [2] becaus
On Friday, May 06, 2011 5:25:46 pm Richard Earnshaw wrote:
> On Fri, 2011-05-06 at 17:06 +0200, Ken Werner wrote:
> > Hi,
> >
> > We've been thinking about adding support for the built-in functions for
> > 64bit atomic memory access and I'd like to know if this is of any
> > interest. Currently th
On Fri, 2011-05-06 at 17:06 +0200, Ken Werner wrote:
> Hi,
>
> We've been thinking about adding support for the built-in functions for 64bit
> atomic memory access and I'd like to know if this is of any interest.
> Currently the main use of these functions seems to be to implement (SMP safe)
>
Hi,
We've been thinking about adding support for the built-in functions for 64bit
atomic memory access and I'd like to know if this is of any interest.
Currently the main use of these functions seems to be to implement (SMP safe)
locking mechanisms where the existent 32bit memory ops are suffic
On 5/6/2011 7:03 PM, Paolo Pisati wrote:
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
Something wrong in ID decoding. The actual PL310 version used
on OMAP4430 ES2.x is r2p0 and hence errata 753970 is NA for
OMAP4430 PANDA/BLAZE/SDP.
weird since it's just a pci read:
arm/mm/cache-l2x0.c
On 05/06/2011 03:12 PM, Santosh Shilimkar wrote:
>
> Something wrong in ID decoding. The actual PL310 version used
> on OMAP4430 ES2.x is r2p0 and hence errata 753970 is NA for
> OMAP4430 PANDA/BLAZE/SDP.
>
weird since it's just a pci read:
arm/mm/cache-l2x0.c::l2x0_init()
...
cache_id = readl_r
On 5/6/2011 2:22 PM, Paolo Pisati wrote:
flag@omap:~$ dmesg | grep -A 1 L310
[0.219024] L310 cache controller enabled
[0.219055] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47,
Cache size: 1048576 B
^^
according to [1], t
On 6 May 2011 15:33, Alexandros Frantzis wrote:
>
> Unless space is a severely limiting factor, I would rather spend that
> money on buying separate screens/mice/keyboards.
>
Well, for display I think a soln like KVM swith would do in this case.
For mice/screen, for ex, I install quicksynergy (o
W dniu 06.05.2011 12:12, James Tunnicliffe pisze:
Yes, it is two buttons to press instead of one, but having a real USB
switcher instead of a KVM solution where you can only switch a mouse
and keyboard (the set up I have) sounds great to me.
The KVM I mentioned has full selective switching sup
On Fri, May 06, 2011 at 11:12:55AM +0100, James Tunnicliffe wrote:
> Looks like switching isn't too expensive to me:
> http://www.amazon.co.uk/Duronic-Switch-input-output-Switcher/dp/B0020426AG/ref=tag_tdp_sv_edpp_i
> http://www.lindy.co.uk/usb-switch-4-port-usb-2-autoswitch/42784.html
I use somet
On Thu, May 05, 2011 at 04:08:01PM +0100, Måns Rullgård wrote:
> >> Incidentally, this ties into the question sent earlier this week which
> >> had to do with Nico's work item in:
> >>
> >> https://blueprints.launchpad.net/linux-linaro/+spec/other-kernel-thumb2
> >>
> >> Which IIRC Nico says pro
On Fri, May 06, 2011 at 07:26:05AM -0300, Christian Robottom Reis wrote:
> On Fri, May 06, 2011 at 11:12:55AM +0100, James Tunnicliffe wrote:
> > Looks like switching isn't too expensive to me:
> > http://www.amazon.co.uk/Duronic-Switch-input-output-Switcher/dp/B0020426AG/ref=tag_tdp_sv_edpp_i
> >
Hi,
On Thu, May 05, 2011 at 03:47:08PM +0100, David Gilbert wrote:
> Hi Kiko,
>
> On 5 May 2011 15:21, Christian Robottom Reis wrote:
> > Hey there,
> >
> > I was asked today in the board meeting about the use of NEON
> > routines in the kernel; I said we had looked into this but hadn't done
> I have always been put off by the ridiculous prices of HDMI/DVI KVM
> switches. What kind of circuitry could they possibly contain that costs
> that much?
>
> I believe they are just pushing the prices as high as the can get away
> with. They just need to keep the cost at less than buying 2/3/4 m
On Fri, May 06, 2011 at 11:23:26AM +0200, Zygmunt Krynicki wrote:
> W dniu 06.05.2011 10:27, Marcin Juszkiewicz pisze:
> >Hi
> >
> >I would like to ask about your display setups on work desks because
> >recent changes in pandaboard kernel moves me into 'lets buy another lcd'
> >direction...
>
> >S
W dniu 06.05.2011 10:27, Marcin Juszkiewicz pisze:
Hi
I would like to ask about your display setups on work desks because
recent changes in pandaboard kernel moves me into 'lets buy another lcd'
direction...
Switching ports on panda requires powering it off in order to not damage
it. Guessing
flag@omap:~$ dmesg | grep -A 1 L310
[0.219024] L310 cache controller enabled
[0.219055] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47,
Cache size: 1048576 B
^^
according to [1], that means Panda has a r3p0 L310 L2 controlle
Hi,
On Thu, May 05, 2011 at 06:35:53PM -0300, Christian Robottom Reis wrote:
> Last quasi-random question of the night: would reviving the kmemcheck
> ARM port (that IIRC was hacked up a while back) be something useful, or
> is it something that is too niche to be worth it? At the board's
> reques
Hi
I would like to ask about your display setups on work desks because
recent changes in pandaboard kernel moves me into 'lets buy another lcd'
direction...
Now I have two displays on my desk:
- 24" 1920x1080
- DVI port is main display of my desktop
- VGA port was used with some boards in p
23 matches
Mail list logo
