2012-09-02 00:15 compcube has joined #qi-hardware
2012-09-02 00:15 compcube has quit [Changing host]
2012-09-02 00:15 compcube has joined #qi-hardware
2012-09-02 01:05 LunaVorax has quit [Ping timeout: 246 seconds]
2012-09-02 01:18 urandom__ has quit [Remote host closed the connection]
2012-09-02 01:21 nikescar has quit [Ping timeout: 246 seconds]
2012-09-02 01:26 Hoolxi has joined #qi-hardware
2012-09-02 01:27 guanucoluis has joined #qi-hardware
2012-09-02 01:49 Hoolxi has quit [Remote host closed the connection]
2012-09-02 02:19 compcube has quit [Quit: Leaving]
2012-09-02 02:55 Ayla has quit [Quit: dodo]
2012-09-02 03:31 Jay7 has quit [Quit: Conversation terminated]
2012-09-02 03:32 Jay7 has joined #qi-hardware
2012-09-02 03:37 <DocScrutinizer05> and sometimes you hear in coding style lessons to use for ( stream = SNDRV_PCM_STREAM_LAST; stream >(=)0; stream-- ) for optimizing reasons (compare to 0 faster&shorter than compare to const)
2012-09-02 03:40 <DocScrutinizer05> anyway this form has the benefit of being to the point about how to interprete pragma-origin-0 and upper-limit
2012-09-02 03:41 <DocScrutinizer05> alternative:
2012-09-02 03:41 <DocScrutinizer05> for ( stream = --SNDRV_PCM_STREAM_AFTER_LAST; stream >(=)0; stream-- )
2012-09-02 03:42 <DocScrutinizer05> ooops
2012-09-02 03:42 <DocScrutinizer05> for ( stream = --SNDRV_PCM_STREAM_AFTER_LAST; stream >(=)0; --stream )
2012-09-02 03:43 <DocScrutinizer05> actually I learnt about pre- vs post-in/decrement as well, one is better than the other, alas I already forgot which is which
2012-09-02 03:43 <DocScrutinizer05> performance-wise
2012-09-02 03:44 <DocScrutinizer05> I guess pre-*crement is better since it doesn't require creating a temporary variable
2012-09-02 03:54 <DocScrutinizer05> unless your compiler is slightly smarter than any assembler and recognizes that there's no need for any such var
2012-09-02 04:01 <DocScrutinizer05> jr@halebop:~> time for (( i=0; i<300000; i++ )); do :; done      #->  real    0m1.807s        ###  jr@halebop:~> time for (( i=300000; i>0; i-- )); do :; done     #->  real    0m1.694s
2012-09-02 04:02 <DocScrutinizer05> sure, it's shellscript
2012-09-02 04:05 <DocScrutinizer05> and then there's been that one CPU that didn't know decrements ;-P
2012-09-02 04:06 <DocScrutinizer05> for (( i=-300000; i<0; i++ ))
2012-09-02 04:27 guanucoluis has quit [Remote host closed the connection]
2012-09-02 06:29 jekhor has joined #qi-hardware
2012-09-02 06:56 kristoffer has joined #qi-hardware
2012-09-02 08:02 nikescar has joined #qi-hardware
2012-09-02 08:04 Hoolxi has joined #qi-hardware
2012-09-02 09:02 rejon has joined #qi-hardware
2012-09-02 09:44 <wpwrak> since the invention of SSA, you can pretty much stop worrying about temporary variables :)
2012-09-02 09:45 <viric> ssa?
2012-09-02 09:45 <lindi-> static single assignment
2012-09-02 09:45 <wpwrak> yup :)
2012-09-02 09:45 <viric> what's that like?
2012-09-02 09:46 <lindi-> viric: you only assign each variable once in the IR
2012-09-02 09:46 <wpwrak> your compiler basically creates a new temporary variable for each basic operation
2012-09-02 09:46 <viric> ah.
2012-09-02 09:47 <viric> and that's any good?
2012-09-02 09:47 <wpwrak> afterwards, it clears that up and removes everything it doesn't actually need
2012-09-02 09:47 <wpwrak> yes, it gives you very nice semantics for optimization
2012-09-02 09:47 <viric> ok
2012-09-02 10:17 <larsc> DocScrutinizer05: your coding style lessons are from the 90ies ;)
2012-09-02 10:17 <DocScrutinizer05> sure
2012-09-02 10:17 <DocScrutinizer05> though held 6  months ago
2012-09-02 10:19 <larsc> e.g. there is performance wise no difference between i++; and ++i; with a modern compiler
2012-09-02 10:19 <mth> there can be a performance difference if you're using C++ iterators, but not for integers
2012-09-02 10:19 <DocScrutinizer05> I think I already mentioned that?
2012-09-02 10:20 <DocScrutinizer05> ooh yes, I forgot to recall to mention it is of course *very* depending on type of variable, and esp c vs c++
2012-09-02 10:21 <DocScrutinizer05> c++ you err compiler might even have to instanciate a new object
2012-09-02 10:22 <DocScrutinizer05> maybe not nowadays anymore, or more seldom nowadays
2012-09-02 10:22 <larsc> mth: yes, looks like a bug
2012-09-02 10:22 <DocScrutinizer05> but this ENEA guy told us that as well
2012-09-02 10:25 <DocScrutinizer05> and it took him like 2 sentences resp 10s to handle the whole topic
2012-09-02 10:26 <wpwrak> larsc: early 90es ;-)
2012-09-02 10:27 <DocScrutinizer05> c'mon guys, cpu still is faster to check register for 0 than against a constant
2012-09-02 10:27 <viric> ++ pre and post operators can be implemented completely different, for objects.
2012-09-02 10:28 <larsc> DocScrutinizer05: depends on your arch
2012-09-02 10:28 <DocScrutinizer05> and that's sth a compiler usually can't auto-optimize
2012-09-02 10:29 <mth> larsc: will you fix it or shall I fix it?
2012-09-02 10:29 <wpwrak> depends. most compiler don't see beyond function calls, that's true. so they don't know whether there are side effects lurking.
2012-09-02 10:29 <DocScrutinizer05> I don't know any arch that wouldn't set flags on arithmetic operations like inc or whatever
2012-09-02 10:30 <wpwrak> but if there are no calls or all the functions are inline (or maybe static), then there's a good chance the compiler can rearrange that check if it thinks it makes a difference
2012-09-02 10:30 <DocScrutinizer05> so comparing against 0 is basically for free
2012-09-02 10:30 <larsc> mth: I'm lazy today
2012-09-02 10:31 <mth> ok, I'll make a patch then; can I include your name in a header?
2012-09-02 10:31 <wpwrak> i'm lazy too. so i won't look up one that doesn't set flags on inc/dec ;-)
2012-09-02 10:31 <larsc> mth: sure
2012-09-02 10:31 <DocScrutinizer05> that for sure was too much for a lazy weekend
2012-09-02 10:31 <DocScrutinizer05> ;-D
2012-09-02 10:32 <wpwrak> but the point is that the compiler should be perfectly capable of changing the loop itself, provided the context isn't spread out too widely (in which case the optimization is irrelevant anyway)
2012-09-02 10:33 <DocScrutinizer05> compiler can't optimize a inc loop to a dec loop, since that's way beyond what compiler understands about code semantics
2012-09-02 10:33 <larsc> there are archs where you don't jump on flags, but the jmp or branch instruction does a compare
2012-09-02 10:33 <larsc> so it does not really matter whether inc/dec sets a flag or not
2012-09-02 10:33 <DocScrutinizer05> dbnz
2012-09-02 10:34 <DocScrutinizer05> yes, I know
2012-09-02 10:34 <DocScrutinizer05> I don't know a ibnz instruction
2012-09-02 10:34 <DocScrutinizer05> ibl
2012-09-02 10:34 <DocScrutinizer05> even
2012-09-02 10:35 <DocScrutinizer05> was it 8080 or z80 that invented decrement-and-branch-if-non-zero instruction?
2012-09-02 10:37 <DocScrutinizer05> this training lesson was targeted at embedded. The CPUs there are amazingly stupic little things sometimes. And still today you can find those
2012-09-02 10:38 <DocScrutinizer05> stupid*
2012-09-02 10:41 <DocScrutinizer05> I strongly suspect a compiler will rather create a second variable it increments, inside a djnz loop, rather than comparing this variable against a constant for loop termination
2012-09-02 10:42 <DocScrutinizer05> of course when you're using a dec loop terminating at zero, the compiler can use the djnz register
2012-09-02 10:44 <DocScrutinizer05> wpwrak: and I really wanna see the compiler smart enough to usually detect this case and convert for (i=0, i<10,i++) to for(i=9, i>=0, i--)
2012-09-02 10:44 <DocScrutinizer05> it needs thorough understanding of all that's done inside the loop with i, and the side effects
2012-09-02 10:45 <larsc> DocScrutinizer05: if i for example is not used inside the loop the compiler will do it
2012-09-02 10:45 <larsc> if it actually is faster
2012-09-02 10:45 <DocScrutinizer05> yep, then it's safe
2012-09-02 10:46 <DocScrutinizer05> and that's the only safe case the compiler is 'smart' enough to detect
2012-09-02 10:46 <DocScrutinizer05> I'd say
2012-09-02 10:48 <DocScrutinizer05> anyway even bashscript is faster on comparing to 0 ;-D
2012-09-02 10:48 <larsc> if it can be sure that the loop is side effect free, I'd say I can also optimize other cases. E.g. summing up a array
2012-09-02 10:48 <DocScrutinizer05> and while I've been aware of that since 1980, I tend to forget it in daily coding
2012-09-02 10:49 <DocScrutinizer05> securing side effect absence isn't trivial
2012-09-02 10:50 <DocScrutinizer05> it's possible 95% of cases, as long as you got 'clean' architecture
2012-09-02 10:50 <DocScrutinizer05> means no mem-mapped IO that the compiler doesn't know about, etc
2012-09-02 10:51 <DocScrutinizer05> even then in a multitasking environment there always might be differences
2012-09-02 10:51 <larsc> DocScrutinizer05: e.g. foo and bar generate the same code: http://pastie.org/4650248
2012-09-02 10:52 GNUtoo has joined #qi-hardware
2012-09-02 10:53 <wpwrak> and you didn't even enable optimization ;-)
2012-09-02 10:53 <DocScrutinizer05> larsc: sure, but in one of the cases your results may be bogus
2012-09-02 10:54 <wpwrak> DocScrutinizer05: how so ?
2012-09-02 10:54 <DocScrutinizer05> well, not in this very example
2012-09-02 10:54 <wpwrak> qed :)
2012-09-02 10:57 <DocScrutinizer05>  for (i = 0; i < 10; i++);  if (i=0 || i=1) {while x[i]==0 {usleep 1000} } else { tmp += x[i] };    return tmp;
2012-09-02 10:58 <DocScrutinizer05> ooops
2012-09-02 10:58 <DocScrutinizer05>  for (i = 0; i < 10; i++);  if (i==0 || i==1) {while x[i]==0 {usleep 1000} } else { tmp += x[i] };    return tmp;
2012-09-02 10:59 <wpwrak> luckily, the loop optimization should be very simple here ;-)
2012-09-02 11:00 <DocScrutinizer05> sure, you shouldn't do that inside the loop anyway
2012-09-02 11:00 <wpwrak> do what ? ;-)
2012-09-02 11:00 <wpwrak> your loop is empty
2012-09-02 11:00 <DocScrutinizer05> eh?
2012-09-02 11:01 <wpwrak> well, the for loop
2012-09-02 11:01 <DocScrutinizer05> meh
2012-09-02 11:01 <wpwrak> and the while loop won't compile, so .. :)
2012-09-02 11:01 <DocScrutinizer05> I can spam the chan with another 5 to 10 typo fixed verions
2012-09-02 11:02 <DocScrutinizer05> though it's a pita to edit in this IRC client
2012-09-02 11:03 <wpwrak> the main problem in your example is the usleep anyway, because there's no good way to tell the compiler that the side effect in question is a delay
2012-09-02 11:04 <DocScrutinizer05> err wut?
2012-09-02 11:04 <wpwrak> ah, it's an endless loop. i see.
2012-09-02 11:04 <DocScrutinizer05> the side effect in question is another process initializing the array with values and only _then_ set the semaphore in x[0] x[1]
2012-09-02 11:05 <wpwrak> there are a few "volatile" missing already for correctness ;-)
2012-09-02 11:06 <DocScrutinizer05> good point
2012-09-02 11:06 <wpwrak> and obviously, if you tell the compiler explicitly to avoid any optimizations, you shouldn't be too disappointed if it indeed doesn't optimize :)
2012-09-02 11:06 <DocScrutinizer05> though I'm not sure you need volatile for storage that can get changed by CPU only
2012-09-02 11:07 <wpwrak> you're confused :)
2012-09-02 11:07 <DocScrutinizer05> I'm just saying it mustn't optimize in that case
2012-09-02 11:09 <wpwrak> if you add the right volatiles, it won't optimize
2012-09-02 11:10 <DocScrutinizer05> since (it seems I should explain my code) when the loop reads the array from x[9] down to x[0], then the test for semaphore set and usleep will be done last, not first
2012-09-02 11:11 <DocScrutinizer05> hell, I'm not setting volatile for all global stroage that might get accessed by other processes
2012-09-02 11:11 <wpwrak> "volatile" tells the compiler that the access sequence must not be changed
2012-09-02 11:11 <wpwrak> then your code is broken :)
2012-09-02 11:12 <wpwrak> of course, since function calls are usually a barrier, too, you can get away with that in many cases. but the sooner or later, you'll run into trouble.
2012-09-02 11:14 <DocScrutinizer05> any static var already implies that there may be (possibly concurrent) access to the storage from other location in code, no?
2012-09-02 11:14 <DocScrutinizer05> I mean, that's one of the reasons you get static var
2012-09-02 11:15 <wpwrak> concurrency is never assumed unless you explicitly indicate it with "volatile"
2012-09-02 11:15 <wpwrak> what ?
2012-09-02 11:15 <DocScrutinizer05> err, yes I'm confused. Please wait until my coffe had time to kick in
2012-09-02 11:15 <wpwrak> in your coding class, they shouldn't waste time with prehistoric optimization techniques and instead teach some basics ;-)
2012-09-02 11:16 <DocScrutinizer05> meh
2012-09-02 11:16 <DocScrutinizer05> haha
2012-09-02 11:18 <DocScrutinizer05> a *global* var (scope beyond local function) usually is defined that way because other functions may want to access it as well
2012-09-02 11:18 <larsc> yes, but C assumes that no two functions run at the same time
2012-09-02 11:19 <DocScrutinizer05> in the example *x is "form outside"
2012-09-02 11:19 <wpwrak> larsc: ... unless one calls the other (possibly via intermediates)
2012-09-02 11:20 <DocScrutinizer05> larsc: C assumes what? No taskswitching allowed during execution of int foo(int *x) ?
2012-09-02 11:20 <larsc> DocScrutinizer05: exactly
2012-09-02 11:20 <wpwrak> anyway, gotta get things ready for today's barbecue. 24 C predicted for this chilly mid-winter day :)
2012-09-02 11:20 <DocScrutinizer05> now that sounds absolutely BS. How's preemptive multitasking going to work with that?
2012-09-02 11:21 cladamw has joined #qi-hardware
2012-09-02 11:21 <larsc> DocScrutinizer05: Well if you run two processes, your two processes run in different contexts and they'll never see each other
2012-09-02 11:22 <larsc> but if you have two processes which share memory you need to explicitly protect that memory against concurrent access
2012-09-02 11:22 <DocScrutinizer05> ummpf, what if I got a IRQ service callback function in same module like int foo(int *x)
2012-09-02 11:23 <larsc> if that IRQ service routine also accesses your x you need to explicitly write your code to handle that case
2012-09-02 11:24 <DocScrutinizer05> I did, by defining x[0] x[1] as semaphore
2012-09-02 11:24 <larsc> well, see as no native semaphores
2012-09-02 11:24 <larsc> s/see/C/
2012-09-02 11:24 <qi-bot> larsc meant: "well, C as no native semaphores"
2012-09-02 11:24 <DocScrutinizer05> and I assumed compiler better not comverts this loop to a decrement loop for optimization
2012-09-02 11:24 <larsc> s/as/has/
2012-09-02 11:24 <qi-bot> larsc meant: "well, C has no native semaphores"
2012-09-02 11:25 <larsc> it won't. but that's because it does not no what happens inside of usleep
2012-09-02 11:25 <larsc> s/not no/not know/
2012-09-02 11:25 <qi-bot> larsc meant: "it won't. but that's because it does not know what happens inside of usleep"
2012-09-02 11:25 <larsc> what the fuck is wrong with my typing today?
2012-09-02 11:27 <lindi-> yeah usleep does a syscall so it is quite hard to optimize
2012-09-02 11:28 <DocScrutinizer05> I *might* kick out the usleep (though that's for sure rogue)
2012-09-02 11:29 <lindi-> for library calls some optimizations are possible though, like converting printf with constant arguments to puts
2012-09-02 11:29 <lindi-> or printf("%c", c) to putchar(c)
2012-09-02 11:29 <DocScrutinizer05> replace that by a simple return(-ETOOFAST) when x[0]==0
2012-09-02 11:30 <DocScrutinizer05> still a pretty nice race when foo() sums up bogus values for x[2..9] and then finds meanwhile semaphore in x[0] got set so everything seems to be fine
2012-09-02 11:31 <larsc> gcc has extensions like __attribute__(("pure")) which tells the compiler that the function has no sideeffects
2012-09-02 11:32 <lindi-> larsc: llvm IR has readonly and readnone attributes that are similar
2012-09-02 11:32 <lindi-> http://llvm.org/docs/LangRef.html#fnattrs
2012-09-02 11:33 <DocScrutinizer05> the whole point of my reasoning been that compiler has a hard time to decide if there are side effects in a for-loop that might bite you when compiler optimizes loops from increment to decrement
2012-09-02 11:34 porchao has joined #qi-hardware
2012-09-02 11:35 porchaso0 has quit [Ping timeout: 276 seconds]
2012-09-02 11:35 <larsc> lindi-: I think llvm, well clang, should also support __attribute__(("pure"))
2012-09-02 11:35 <DocScrutinizer05> take a simple memmove shifting each byte down one position. Do you think compiler is smart enough to see it will fail miserably when you change sequence? like x[8]=x[9]; x[7]=x[8]...
2012-09-02 11:36 <lindi-> larsc: yeah, I was talking about how it is represented in the IR
2012-09-02 11:36 <larsc> DocScrutinizer05: it must see this
2012-09-02 11:36 <DocScrutinizer05> no sarcasm, really wondering if compilers might be smart enough for that
2012-09-02 11:38 <lindi-> DocScrutinizer05: just paste it to http://llvm.org/demo/
2012-09-02 11:38 <DocScrutinizer05> o.O ??
2012-09-02 11:39 <DocScrutinizer05> wow!
2012-09-02 12:03 <mth> larsc: I'm testing the pwm changes and there is one annoying effect: the numbering changes
2012-09-02 12:03 <mth> JZ_GPIO_PWM2 becomes pwm 0 etc
2012-09-02 12:04 <mth> should we just accept that? request that the pwm core can handle mappings that don't start at 0? or register JZ_GPIO_PWM0 and JZ_GPIO_PWM1 and return EBUSY if someone tries to use them?
2012-09-02 12:06 <mth> the hardware does have 8 PWMs, it's just that timer 0 and 1 are in use by the kernel and therefore not available as PWMs
2012-09-02 12:09 jluis has quit [Read error: Connection reset by peer]
2012-09-02 12:10 <larsc> mth: e.g. for jz4760 timer 0 and 1 are not used by the kernel, so I think it should be fine
2012-09-02 12:12 <larsc> I don't really get patch 1 of that series
2012-09-02 12:12 <larsc> but I might be missing someting
2012-09-02 12:13 <larsc> Btw. I met with Thierry last week, seems to be a nice guy
2012-09-02 12:14 <mth> patch 1 wants to get rid of a header named "irq.h" in the current directory (for 4740 arch) since it gets included instead of something from the header search path
2012-09-02 12:14 <mth> I don't know what that something is
2012-09-02 12:14 <mth> maybe the MIPS version of irq.h?
2012-09-02 12:15 <larsc> but we include irq.h with "" instead of <>
2012-09-02 12:16 <mth> hmm, so it's the one that is supposed to be included
2012-09-02 12:17 <mth> the MIPS version is called asm/irq.h, so unless the "asm" path is in a search path as well, it cannot be masked by just "irq.h"
2012-09-02 12:19 <mth> maybe it's shadowing arch/mips/include/asm/mach-generic/irq.h?
2012-09-02 12:19 <mth> that's the one that defines NR_IRQS
2012-09-02 12:21 <larsc> but we never do #include <irq.h> anyway
2012-09-02 12:24 <mth> I don't see the rest of the patches include <irq.h> either
2012-09-02 12:24 <mth> so I'm out of ideas
2012-09-02 12:24 <mth> I guess you should just ask Thierry
2012-09-02 12:25 jluis has joined #qi-hardware
2012-09-02 12:27 <larsc> I think the pwm_{enable,disable} in jz4740_pwm_config should be jz4740_pwm_{enable,disable}
2012-09-02 12:28 <mth> I get the pwm backlight driver to init now using the legacy api, but the screen goes dark
2012-09-02 12:30 <mth> the difference in the enable/disable is this: test_and_clear_bit(PWMF_ENABLED, &pwm->flags)
2012-09-02 12:30 <larsc> ah, I misunderstood you earlier, the new id's start with PWM2 = 0
2012-09-02 12:30 <larsc> that's indeed not so nice
2012-09-02 12:36 <mth> I think the numbering thing is even causing bugs
2012-09-02 12:37 <mth> pwm->hwpwm is 5 for PWM7, so it will conifgure timer 5
2012-09-02 12:37 <larsc> yea, just saw this as well
2012-09-02 12:37 urandom__ has joined #qi-hardware
2012-09-02 12:39 <mth> btw, I think the is_enabled check before pwm_disable in jz4740_pwm_config is redundant, since the pwm core checks this as well
2012-09-02 12:39 <mth> and the core checks it atomically, so that's a bit safer as well
2012-09-02 12:40 <mth> or jz4740_pwm_config is called with a lock held anyway?
2012-09-02 12:40 <larsc> I think we should set NUM_PWM to 8 and return -EBUSY for 0 and 1 for in request
2012-09-02 12:41 <mth> yes, I think that makes it much clearer since it corresponds better with the hardware
2012-09-02 12:41 kilae has joined #qi-hardware
2012-09-02 12:42 kristoffer has quit [Quit: This computer has gone to sleep]
2012-09-02 12:45 <mth> ok, with that change it works via the legacy API
2012-09-02 12:45 <mth> now I have to figure out how the new API works
2012-09-02 12:46 <larsc> the same, I think
2012-09-02 12:46 <mth> it seems some kind of registration to work
2012-09-02 12:47 <mth> see pwm_add_table()
2012-09-02 12:48 <larsc> ah, probably like the clk api
2012-09-02 12:48 <mth> there is nothing arch/ that uses 'struct pwm_lookup' though
2012-09-02 12:49 <mth> so it seems the new API is so new that it's not actually being used yet
2012-09-02 12:51 <mth> shall I send a diff to Thierry?
2012-09-02 12:52 <larsc> I think all you need for the PWM_LOOKUP("jz4740-pwm", 4, 0, 0)
2012-09-02 12:52 <larsc> or similar
2012-09-02 12:52 <mth> http://www.treewalker.org/temp/jz4740-pwm-all-8.diff
2012-09-02 12:52 <larsc> all you need for the pwm backlight
2012-09-02 12:54 <larsc> I'd just comment on the patch
2012-09-02 12:58 <mth> code is sometimes easier to understand than a description of code...
2012-09-02 12:59 <mth> PWM_LOOKUP("jz4740-pwm", 7, 0, 0) does not work
2012-09-02 12:59 <mth> pwm-backlight pwm-backlight: unable to request PWM, trying legacy API
2012-09-02 13:01 <larsc> hm, ok the first one seems to be the name of the device which requests the pwm
2012-09-02 13:01 <larsc> so pwm-backlight
2012-09-02 13:02 <mth> strange to call it "provider" then...
2012-09-02 13:02 <larsc> no
2012-09-02 13:02 <larsc> wait
2012-09-02 13:02 <larsc> yes
2012-09-02 13:02 <larsc> the 3rd argument is the requesting device
2012-09-02 13:03 <larsc> but it should also work if it is NULL
2012-09-02 13:04 woakas has quit [Ping timeout: 272 seconds]
2012-09-02 13:05 <mth> PWM_LOOKUP("jz4740-pwm", 7, "pwm-backlight", 0) does seems to work
2012-09-02 13:08 panda|x201 has joined #qi-hardware
2012-09-02 13:18 <larsc> about patch 2, I'd like to keep the timer functions as inline functions, do you agree?
2012-09-02 13:25 <mth> it would reduce the number of exported symbols significantly
2012-09-02 13:26 <mth> performance wise, I don't think it really matters, since we don't call those functions very often
2012-09-02 13:27 <larsc> well, they are used in the system clock code
2012-09-02 13:30 <mth> I sent my comments
2012-09-02 13:33 guanucoluis has joined #qi-hardware
2012-09-02 13:33 <mth> does the system clock change the timer configuration often though?
2012-09-02 13:33 <mth> maybe once adaptive tickless is in it will?
2012-09-02 13:34 <larsc> well it reads the counter quite often
2012-09-02 13:35 <mth> ok, then inline is better indeed
2012-09-02 13:58 guanucoluis has quit [Ping timeout: 246 seconds]
2012-09-02 13:59 <DocScrutinizer05> ((<larsc> I think we should set NUM_PWM to 8 and return -EBUSY for 0 and 1 for in request)) indeed
2012-09-02 14:21 kristoffer has joined #qi-hardware
2012-09-02 14:29 cladamw has quit [Ping timeout: 240 seconds]
2012-09-02 14:30 cladamw has joined #qi-hardware
2012-09-02 14:42 cladamw has quit [Read error: Connection reset by peer]
2012-09-02 14:50 Hoolxi has quit [Remote host closed the connection]
2012-09-02 14:54 jekhor has quit [Ping timeout: 244 seconds]
2012-09-02 14:59 <larsc> mth: I found out that the udc core used by the jz4740 ist the musb udc core and so we already have a driver for it in mainline
2012-09-02 14:59 <larsc> we just need to add some boilerplate code to hook e.g. clocks up
2012-09-02 15:07 DocScrutinizer05 has quit [Ping timeout: 268 seconds]
2012-09-02 15:08 DocScrutinizer05 has joined #qi-hardware
2012-09-02 15:09 DocScrutinizer05 has quit [Disconnected by services]
2012-09-02 15:09 DocScrutinizer05 has joined #qi-hardware
2012-09-02 15:21 guanucoluis has joined #qi-hardware
2012-09-02 15:40 kuribas has joined #qi-hardware
2012-09-02 15:44 <qi-bot> The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.minimal-20120901-1311
2012-09-02 15:47 guanucoluis has quit [Ping timeout: 276 seconds]
2012-09-02 16:12 emeb has joined #qi-hardware
2012-09-02 16:14 kilae_ has joined #qi-hardware
2012-09-02 16:16 kilae has quit [Ping timeout: 252 seconds]
2012-09-02 16:23 Ayla has joined #qi-hardware
2012-09-02 16:26 GNUtoo has quit [Quit: Program received signal SIGSEGV, Segmentation fault.]
2012-09-02 16:37 <mth> larsc: this is the glue code we're using for musb on the JZ4770: http://www.treewalker.org/temp/musb-jz4770.diff
2012-09-02 16:38 <mth> I migrated Ingenic's code from 2.6.31 to 3.5
2012-09-02 16:39 <mth> that was an awful lot of work since they backported a lot of future mainline commits to 2.6.31 and published it as part of a 500,000 line diff
2012-09-02 16:48 <larsc> we shouldn't need as much for jz4740
2012-09-02 16:49 <larsc> also there is a generic gpio driver for cable detection, iirc
2012-09-02 16:55 <mth> we probably don't need that much on 4770 either, but I haven't tried to cut it down further yet as it works in its current state
2012-09-02 16:55 jekhor has joined #qi-hardware
2012-09-02 17:44 Ayla has quit [Ping timeout: 272 seconds]
2012-09-02 17:54 Ayla has joined #qi-hardware
2012-09-02 18:20 Ayla has quit [Ping timeout: 276 seconds]
2012-09-02 18:56 Ayla has joined #qi-hardware
2012-09-02 19:03 newcup has quit [Ping timeout: 268 seconds]
2012-09-02 19:12 viric has quit [Ping timeout: 268 seconds]
2012-09-02 19:16 viric has joined #qi-hardware
2012-09-02 19:30 jluis has quit [Read error: Connection timed out]
2012-09-02 19:32 jluis has joined #qi-hardware
2012-09-02 19:35 kristoffer has quit [Quit: Leaving]
2012-09-02 19:38 newcup has joined #qi-hardware
2012-09-02 20:30 DocScrutinizer05 is now known as stephenelop
2012-09-02 20:31 stephenelop is now known as DocScrutinizer05
2012-09-02 20:50 porchao has quit [Ping timeout: 244 seconds]
2012-09-02 20:50 porchao has joined #qi-hardware
2012-09-02 21:40 kilae_ has quit [Quit: ChatZilla 0.9.88.2 [Firefox 15.0/20120824154833]]
2012-09-02 21:40 <Ayla> larsc: hi
2012-09-02 21:41 <Ayla> arch/mips/jz4740/clock.c:221-222
2012-09-02 21:41 <Ayla> do you remember what the '+ 2' is for?
2012-09-02 21:43 _whitelogger_ has joined #qi-hardware
2012-09-02 21:43 <mth> Ayla: if it's jz_clk_pll_get_rate you're talking about, I don't think larsc is responsible
2012-09-02 21:44 <mth> in the version I have here, there is no +2 at line 221-222
2012-09-02 21:44 <Ayla> ?
2012-09-02 21:45 <Ayla> there is, on the jz4770 tree
2012-09-02 21:46 whitequark has joined #qi-hardware
2012-09-02 21:47 <mth> ah, I just changed the names of those variables, not the expression
2012-09-02 21:48 <mth> I think the data sheet just says that the register value is 2 less than the actual value
2012-09-02 21:56 jluis has joined #qi-hardware
2012-09-02 22:03 wolfspra1l has joined #qi-hardware
2012-09-02 22:06 wolfspraul has quit [Ping timeout: 272 seconds]
2012-09-02 22:09 guanucoluis has joined #qi-hardware
2012-09-02 22:17 LunaVorax has joined #qi-hardware
2012-09-02 22:40 jekhor has quit [Ping timeout: 244 seconds]
2012-09-02 22:44 LunaVorax has quit [Ping timeout: 246 seconds]
2012-09-02 23:01 jluis has quit [Ping timeout: 245 seconds]
2012-09-02 23:02 guanucoluis has quit [Remote host closed the connection]
2012-09-02 23:08 LunaVorax has joined #qi-hardware
2012-09-02 23:15 jluis has joined #qi-hardware
2012-09-02 23:22 kuribas has quit [Remote host closed the connection]
2012-09-02 23:23 LunaVorax has quit [Read error: Connection reset by peer]