Russell King - ARM Linux writes:
> On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> >> This passes a data pointer specified in the
issed something that makes this a stupid idea, please tell.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; For those that don't, perhaps we handle the conversion between perceived and
> pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate
> the need for conversion?
Some LED controllers do the right thing in hardware, so any adjustment
done in the core needs
Will Deacon writes:
> Hi Mans,
>
> On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>> > As you point out, "bx lr" /may/ be treated specially (I've actually been
>>
>> Most, if not all, Cortex
Russell King - ARM Linux writes:
> On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
>> Russell King writes:
>>
>> > ARMv6 and greater introduced a new instruction ("bx") which can be used
>> > to return from function calls. Rece
g.
I would suggest either using a more neutral name than "ret" or adding an
alias to be used for non-return jumps so as to make the intent clearer.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob Landley writes:
> On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
>> Rob Landley writes:
>>
>> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> >> I'd strongly suggest you make your binutils compatible with newer
>> >> instruc
might break your precious assembler.
>
> I've got news for you. We're *not* going to listen to that argument.
>
> END OF DISCUSSION (everything else is just a waste of time.)
I fully agree.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "uns
depend on
> endless new gnuisms just because they're there and nobody else is
> regression testing against them, not because they actually add anything.
Since when is assembling the instructions correctly, as specified in the
arch ref, and not in some other random way a gnuism?
-
ce, binutils older than 2.19
or so rarely works properly for ARM.
What value is there in maintaining compatibility with a truly ancient
binutils version anyway?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a messa
2x0_set_debug() for example). I'm not sure
> they are documented.
The trouble with OMAP is that the secure ROM API only allows access to a
tiny subset of the registers we'd need. In part this can be explained
by the important OMAP customers all using the HS chips with full access
and this has only
16 D registers. The high D registers are present if (vfpv3 && !vfpv3d16).
Pre-calculating this to avoid doing it in the context save/restore code
is probably a good idea.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
initcall ip_auto_config+0x0/0xf70 returned -19 after
> 11809741 use
> cs
> [ 18.382141] calling initialize_hashrnd+0x0/0x1c @ 1
> [ 18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59
> usecs
> [ 18.397949] async_waiting @ 1
> [ 18.401184] async_continuing @ 1
"Mark A. Greer" writes:
> On Thu, Apr 19, 2012 at 04:04:42PM +0100, Måns Rullgård wrote:
>> Igor Grinberg writes:
>>
>> > On 04/19/12 05:07, Paul Walmsley wrote:
>> >>
>> >> Hi,
>> >>
>> >> just wanted to
Tony Lindgren writes:
> * Måns Rullgård [120419 08:31]:
>> Igor Grinberg writes:
>>
>> > On 04/19/12 05:07, Paul Walmsley wrote:
>> >>
>> >> Hi,
>> >>
>> >> just wanted to mention this on the list to see if anyone els
h "phy_clk". When davinci_emac_probe()
then does a clk_get(dev, NULL), this fails since there is no matching
con_id. Likewise for davinci_mdio_probe().
With a little hacking, I got the platform device registered and the
clocks matching as (I think) they should. It now detects the correct
PHY,
30% of the time. The rest is spent idling even though my
> program is non-blocking. How could that be possible? Power-saving?
In top, press 1 to see the statistics for the CPUs separately.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-o
Will Deacon writes:
> On Fri, Jan 27, 2012 at 01:47:01PM +0000, Måns Rullgård wrote:
>> Will Deacon writes:
>>
>> > Mans,
>> >
>> > On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote:
>> >> Will Deacon writes:
>> >>
Will Deacon writes:
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +0000, Måns Rullgård wrote:
>> Will Deacon writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a
>> > working
>> > setup but Stephane is unable to replicat
>
> Did this lead anywhere in the end? It seems as though Ming Lei has a working
> setup but Stephane is unable to replicate it, despite applying the necessary
> patches and trying an updated bootloader.
With the patches listed above plus the one in [1], I get PMU interrupts.
However
leared, and
u-boot messes with this bit.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
a real issue. There doesn't seem
>>> to be a MODULE_DEPENDS(), or anything like that.
>>
>> A MODULE_DEPENDS() would also be irrelevant here.
>
> Ok.
>
>>> snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through
>>> codec_dai_name, and codec_name, and
Måns Rullgård writes:
> Mark Brown writes:
>
>> On Thu, Dec 29, 2011 at 10:22:31PM +, M?ns Rullg?rd wrote:
>>> Mark Brown writes:
>>
>>> > The reason the driver is not loaded automatically is that the OMAP
>>> > machine drivers have not
ted patches doing the conversion a long time ago (September?). It
>> seems they got lost somewhere.
>
> Most of them have been converted,
In which tree? I haven't seen anything of the kind.
> but the rx51 wasn't.
RX51 was done in my patch...
--
Måns Rullgår
dering of module loading.
>
> The reason the driver is not loaded automatically is that the OMAP
> machine drivers have not been converted to platform devices.
I posted patches doing the conversion a long time ago (September?). It
seems they got lost somewhere.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar writes:
> On 4/30/2011 10:14 PM, Måns Rullgård wrote:
>> Sebastian Reichel writes:
>>
>
> [..]
>
>>>
>>> 32ecc: 9cd0ldr r4, [sp, #832] ; 0x340
>>> 32ece: fffe e92d vtbl.8 d30, {d14-d15}, d29
>>
ush {d8}
Your userland appears to be built with Thumb2. Make sure CONFIG_THUMB
is enabled in your kernel.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ideas about it?
The PMU interrupt is routed through the CTI, which needs to be properly
configured. Unfortunately, the CTI is not documented in the public TRM,
and nobody has seen fit to submit a patch suitable for upstream. Some
dirty hacks have been posted, though.
--
Måns Rullgård
m...@mansr
, not widely manufactured today)
> ... not impossibility.
The architecture being uncommon is not in my opinion cause to make
life harder than necessary for whomever might some day want to add
support for it.
Does the patch solve any real problem today?
--
Måns Rullgård
m...@mansr.com
--
To unsubsc
C ISR? Does it mean display controller use
> the config flushed to the real register from the VSYNC ?
The hardware latches the shadow registers to the active registers at
start of VFP.
> I don't know OMAP in detail. But as I know other SoCs also work like it.
>
> Can Go bit is clear
t vsync, so
the delay is higher up the stack. Is there any way it could be
eliminated? This would not only fix the "bug" under discussion here,
but also reduce the latency of page flipping.
> As far as WAITFORGO is concerned, I think GO bit concept is
> something OMAP notion/term and doesn't make sense to standardize
> it. Atleast I am not aware of any other architecture having GO bit.
Naming is minor detail. Feel free to suggest a better one.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Is this OMAP specific, or is this ARM generic?
The bit fields are generic PL310. It has to be set from OMAP code due
to the ROM call.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kerne
store buffer
> accepts the write address. This behavior is not compatible with
> the AXI protocol and is disabled by default. You enable this
> optimization by setting the Early BRESP Enable bit in the
> Auxiliary Control Register (bit [30]).
Did you measure the performance difference this
r
offset can be programmed in secure mode, but the TI ROM authors
neglected to include this.
Testing with FFmpeg showed a speedup of 10% with this patch in some
cases.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
have dramatic effects on memory throughput. For mainly sequential
accesses disabling it can be faster.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Russell King - ARM Linux writes:
> On Sat, Jan 31, 2009 at 03:39:07PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Sat, Jan 31, 2009 at 03:07:06PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> &
Russell King - ARM Linux writes:
> On Sat, Jan 31, 2009 at 03:07:06PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>> > Great, thanks. However, I'd forgotten that one of my patches completely
>> > removes clk_get_parent() since it's
>> Done; revised patch below.
>
> Great, thanks. However, I'd forgotten that one of my patches completely
> removes clk_get_parent() since it's unused by any code in OMAP at present.
>
> What was the reasoning behind making this work?
It is needed for the o
d test any patches
I'm getting the same error on Nokia 770. Anything I can do to help?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ks like Tomi's driver is shaping up nicely, so it's probably not
worthwhile spending any significant time on the current driver. If
anyone is interested, everything I have is in my git tree.
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
control over the dss1_alwon_fck rate.
>
> :100644 100644 161da12... 876eb13... M arch/arm/mach-omap2/clock34xx.h
I'll send the patches as replies to this mail for easier reference.
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t is the other way around:
> if the framebuffer (menu) has chromakey pixels, then those pixels are
> replaced by pixels from the video stream. That's what the current API
> does.
The OMAP3 hardware supports both type of keying, but not
simultaneously.
--
Måns Rullgård
[EMAIL PROTECTE
ev = (idcode >> 28) & 0xff;
>
> if (hawkeye == 0xb7ae)
> - system_rev = 0x34300034 | ((1 + rev) << 12);
> + system_rev = 0x34300034 | (rev << 12);
>
> out:
> switch (system_rev) {
Forget this. A fix was already in the tree,
usb_platform_set_mode(struct musb *musb, u8
> musb_mode)
>
> int __init musb_platform_init(struct musb *musb)
> {
> + struct otg_transceiver *xceiv = otg_get_transceiver();
> u32 l;
>
> #if defined(CONFIG_ARCH_OMAP2430)
> omap_cfg_reg(AE5_2430_
ys inherent in
>> writing code you *know* is unsuitable for merging to mainline?)
>
> Well, there are only a limited number of hours in a day. :)
In my experience, writing code properly to begin with takes less time
than writing it badly first, and cleaning it up later.
--
Måns Rullgår
Tomi Valkeinen <[EMAIL PROTECTED]> writes:
> On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote:
>> Tomi Valkeinen <[EMAIL PROTECTED]> writes:
>>
>> > On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote:
>> >> Koen Kooi <[EMA
Daniel Stone wrote:
> On Mon, Sep 08, 2008 at 09:02:56PM +0100, ext Måns Rullgård wrote:
>> "arun c" <[EMAIL PROTECTED]> writes:
>> > + while (dispc_read_reg(DISPC_CONTROL) & (1 << 5))
>> > + continue;
>> > + MOD_REG_FL
+ continue;
> + MOD_REG_FLD(DISPC_CONTROL, 1 << 5, 1 << 5);
> +
> return height * screen_width * bpp / 8;
> }
This looks good. However, the same thing is needed in
omap_dispc_enable_plane() as well. Placing the loop+set in a function
(go_lcd()?) would mak
"Steve Sakoman" <[EMAIL PROTECTED]> writes:
> On Sun, Sep 7, 2008 at 10:37 AM, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Sunday 07 September 2008, Måns Rullgård wrote:
>>> I've also had to revert the "usb: musb: p
.
>
> Missing that should probably make trouble, yes.
I've also had to revert the "usb: musb: pass configuration specifics
via pdata" commits:
ffd60d49c70b31d26430a1098edf0eef5e4dfac8 in linux-omap
ca6d1b1333bc2e61e37982de1f28d8604c232414 in mainline
I suspect t
7;t permit this - the '#' should always be in
> column 0, optionally followed by white space before the directive.
C99 allows whitespace before the # character. Older versions may have
had this restriction; I don't have a copy available.
--
Måns Rullgård
[EMAIL PROTECTED]
-
51 matches
Mail list logo
