| 00:15.33 | *** join/#qi-hardware compcube (~compcube@c-76-112-242-32.hsd1.mi.comcast.net) |
| 00:15.34 | *** join/#qi-hardware compcube (~compcube@pdpc/supporter/student/compcube) |
| 01:26.58 | *** join/#qi-hardware Hoolxi (~Openfree@120.204.177.81) |
| 01:27.03 | *** join/#qi-hardware guanucoluis (~luis@200.127.180.65) |
| 03:32.50 | *** join/#qi-hardware Jay7 (jay@128-73-75-119.broadband.corbina.ru) |
| 03:37.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) |
| 03:40.21 | DocScrutinizer05 | anyway this form has the benefit of being to the point about how to interprete pragma-origin-0 and upper-limit |
| 03:41.09 | DocScrutinizer05 | alternative: |
| 03:41.40 | DocScrutinizer05 | for ( stream = --SNDRV_PCM_STREAM_AFTER_LAST; stream >(=)0; stream-- ) |
| 03:42.05 | DocScrutinizer05 | ooops |
| 03:42.13 | DocScrutinizer05 | for ( stream = --SNDRV_PCM_STREAM_AFTER_LAST; stream >(=)0; --stream ) |
| 03:43.37 | 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 |
| 03:43.47 | DocScrutinizer05 | performance-wise |
| 03:44.52 | DocScrutinizer05 | I guess pre-*crement is better since it doesn't require creating a temporary variable |
| 03:54.26 | DocScrutinizer05 | unless your compiler is slightly smarter than any assembler and recognizes that there's no need for any such var |
| 04:01.31 | 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 |
| 04:02.01 | DocScrutinizer05 | sure, it's shellscript |
| 04:05.35 | DocScrutinizer05 | and then there's been that one CPU that didn't know decrements ;-P |
| 04:06.17 | DocScrutinizer05 | for (( i=-300000; i<0; i++ )) |
| 06:29.37 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 06:56.24 | *** join/#qi-hardware kristoffer (~kristoffe@c-fadde555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 08:02.15 | *** join/#qi-hardware nikescar (~nikescar@114.199.131.108) |
| 08:04.15 | *** join/#qi-hardware Hoolxi (~Openfree@183.195.228.6) |
| 09:02.21 | *** join/#qi-hardware rejon (~rejon@123203086020.ctinets.com) |
| 09:44.22 | wpwrak | since the invention of SSA, you can pretty much stop worrying about temporary variables :) |
| 09:45.03 | viric | ssa? |
| 09:45.17 | lindi- | static single assignment |
| 09:45.47 | wpwrak | yup :) |
| 09:45.57 | viric | what's that like? |
| 09:46.33 | lindi- | viric: you only assign each variable once in the IR |
| 09:46.42 | wpwrak | your compiler basically creates a new temporary variable for each basic operation |
| 09:46.52 | viric | ah. |
| 09:47.03 | viric | and that's any good? |
| 09:47.04 | wpwrak | afterwards, it clears that up and removes everything it doesn't actually need |
| 09:47.19 | wpwrak | yes, it gives you very nice semantics for optimization |
| 09:47.27 | viric | ok |
| 10:17.22 | larsc | DocScrutinizer05: your coding style lessons are from the 90ies ;) |
| 10:17.30 | DocScrutinizer05 | sure |
| 10:17.47 | DocScrutinizer05 | though held 6 months ago |
| 10:19.00 | larsc | e.g. there is performance wise no difference between i++; and ++i; with a modern compiler |
| 10:19.37 | mth | there can be a performance difference if you're using C++ iterators, but not for integers |
| 10:19.39 | DocScrutinizer05 | I think I already mentioned that? |
| 10:20.50 | DocScrutinizer05 | ooh yes, I forgot to recall to mention it is of course *very* depending on type of variable, and esp c vs c++ |
| 10:21.54 | DocScrutinizer05 | c++ you err compiler might even have to instanciate a new object |
| 10:22.16 | DocScrutinizer05 | maybe not nowadays anymore, or more seldom nowadays |
| 10:22.24 | larsc | mth: yes, looks like a bug |
| 10:22.34 | DocScrutinizer05 | but this ENEA guy told us that as well |
| 10:25.07 | DocScrutinizer05 | and it took him like 2 sentences resp 10s to handle the whole topic |
| 10:26.19 | wpwrak | larsc: early 90es ;-) |
| 10:27.18 | DocScrutinizer05 | c'mon guys, cpu still is faster to check register for 0 than against a constant |
| 10:27.21 | viric | ++ pre and post operators can be implemented completely different, for objects. |
| 10:28.04 | larsc | DocScrutinizer05: depends on your arch |
| 10:28.18 | DocScrutinizer05 | and that's sth a compiler usually can't auto-optimize |
| 10:29.21 | mth | larsc: will you fix it or shall I fix it? |
| 10:29.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. |
| 10:29.59 | DocScrutinizer05 | I don't know any arch that wouldn't set flags on arithmetic operations like inc or whatever |
| 10:30.10 | 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 |
| 10:30.10 | DocScrutinizer05 | so comparing against 0 is basically for free |
| 10:30.34 | larsc | mth: I'm lazy today |
| 10:31.06 | mth | ok, I'll make a patch then; can I include your name in a header? |
| 10:31.06 | wpwrak | i'm lazy too. so i won't look up one that doesn't set flags on inc/dec ;-) |
| 10:31.27 | larsc | mth: sure |
| 10:31.54 | DocScrutinizer05 | that for sure was too much for a lazy weekend |
| 10:31.57 | DocScrutinizer05 | ;-D |
| 10:32.02 | 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) |
| 10:33.01 | DocScrutinizer05 | compiler can't optimize a inc loop to a dec loop, since that's way beyond what compiler understands about code semantics |
| 10:33.19 | larsc | there are archs where you don't jump on flags, but the jmp or branch instruction does a compare |
| 10:33.32 | larsc | so it does not really matter whether inc/dec sets a flag or not |
| 10:33.56 | DocScrutinizer05 | dbnz |
| 10:34.01 | DocScrutinizer05 | yes, I know |
| 10:34.15 | DocScrutinizer05 | I don't know a ibnz instruction |
| 10:34.30 | DocScrutinizer05 | ibl |
| 10:34.34 | DocScrutinizer05 | even |
| 10:35.25 | DocScrutinizer05 | was it 8080 or z80 that invented decrement-and-branch-if-non-zero instruction? |
| 10:37.43 | DocScrutinizer05 | this training lesson was targeted at embedded. The CPUs there are amazingly stupic little things sometimes. And still today you can find those |
| 10:38.15 | DocScrutinizer05 | stupid* |
| 10:41.09 | 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 |
| 10:42.38 | DocScrutinizer05 | of course when you're using a dec loop terminating at zero, the compiler can use the djnz register |
| 10:44.14 | 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--) |
| 10:44.52 | DocScrutinizer05 | it needs thorough understanding of all that's done inside the loop with i, and the side effects |
| 10:45.11 | larsc | DocScrutinizer05: if i for example is not used inside the loop the compiler will do it |
| 10:45.26 | larsc | if it actually is faster |
| 10:45.29 | DocScrutinizer05 | yep, then it's safe |
| 10:46.16 | DocScrutinizer05 | and that's the only safe case the compiler is 'smart' enough to detect |
| 10:46.19 | DocScrutinizer05 | I'd say |
| 10:48.10 | DocScrutinizer05 | anyway even bashscript is faster on comparing to 0 ;-D |
| 10:48.20 | 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 |
| 10:48.50 | DocScrutinizer05 | and while I've been aware of that since 1980, I tend to forget it in daily coding |
| 10:49.39 | DocScrutinizer05 | securing side effect absence isn't trivial |
| 10:50.22 | DocScrutinizer05 | it's possible 95% of cases, as long as you got 'clean' architecture |
| 10:50.49 | DocScrutinizer05 | means no mem-mapped IO that the compiler doesn't know about, etc |
| 10:51.16 | DocScrutinizer05 | even then in a multitasking environment there always might be differences |
| 10:51.53 | larsc | DocScrutinizer05: e.g. foo and bar generate the same code: http://pastie.org/4650248 |
| 10:52.20 | *** join/#qi-hardware GNUtoo (~gnutoo@ABordeaux-152-1-36-145.w83-193.abo.wanadoo.fr) |
| 10:53.47 | wpwrak | and you didn't even enable optimization ;-) |
| 10:53.50 | DocScrutinizer05 | larsc: sure, but in one of the cases your results may be bogus |
| 10:54.27 | wpwrak | DocScrutinizer05: how so ? |
| 10:54.30 | DocScrutinizer05 | well, not in this very example |
| 10:54.41 | wpwrak | qed :) |
| 10:57.14 | DocScrutinizer05 | <PROTECTED> |
| 10:58.12 | DocScrutinizer05 | ooops |
| 10:58.28 | DocScrutinizer05 | <PROTECTED> |
| 10:59.59 | wpwrak | luckily, the loop optimization should be very simple here ;-) |
| 11:00.22 | DocScrutinizer05 | sure, you shouldn't do that inside the loop anyway |
| 11:00.34 | wpwrak | do what ? ;-) |
| 11:00.46 | wpwrak | your loop is empty |
| 11:00.58 | DocScrutinizer05 | eh? |
| 11:01.02 | wpwrak | well, the for loop |
| 11:01.13 | DocScrutinizer05 | meh |
| 11:01.14 | wpwrak | and the while loop won't compile, so .. :) |
| 11:01.51 | DocScrutinizer05 | I can spam the chan with another 5 to 10 typo fixed verions |
| 11:02.14 | DocScrutinizer05 | though it's a pita to edit in this IRC client |
| 11:03.42 | 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 |
| 11:04.07 | DocScrutinizer05 | err wut? |
| 11:04.56 | wpwrak | ah, it's an endless loop. i see. |
| 11:04.57 | 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] |
| 11:05.55 | wpwrak | there are a few "volatile" missing already for correctness ;-) |
| 11:06.19 | DocScrutinizer05 | good point |
| 11:06.32 | 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 :) |
| 11:06.46 | DocScrutinizer05 | though I'm not sure you need volatile for storage that can get changed by CPU only |
| 11:07.21 | wpwrak | you're confused :) |
| 11:07.28 | DocScrutinizer05 | I'm just saying it mustn't optimize in that case |
| 11:09.17 | wpwrak | if you add the right volatiles, it won't optimize |
| 11:10.20 | 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 |
| 11:11.22 | DocScrutinizer05 | hell, I'm not setting volatile for all global stroage that might get accessed by other processes |
| 11:11.23 | wpwrak | "volatile" tells the compiler that the access sequence must not be changed |
| 11:11.38 | wpwrak | then your code is broken :) |
| 11:12.43 | 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. |
| 11:14.08 | DocScrutinizer05 | any static var already implies that there may be (possibly concurrent) access to the storage from other location in code, no? |
| 11:14.56 | DocScrutinizer05 | I mean, that's one of the reasons you get static var |
| 11:15.14 | wpwrak | concurrency is never assumed unless you explicitly indicate it with "volatile" |
| 11:15.18 | wpwrak | what ? |
| 11:15.48 | DocScrutinizer05 | err, yes I'm confused. Please wait until my coffe had time to kick in |
| 11:15.58 | wpwrak | in your coding class, they shouldn't waste time with prehistoric optimization techniques and instead teach some basics ;-) |
| 11:16.22 | DocScrutinizer05 | meh |
| 11:16.24 | DocScrutinizer05 | haha |
| 11:18.06 | DocScrutinizer05 | a *global* var (scope beyond local function) usually is defined that way because other functions may want to access it as well |
| 11:18.43 | larsc | yes, but C assumes that no two functions run at the same time |
| 11:19.02 | DocScrutinizer05 | in the example *x is "form outside" |
| 11:19.37 | wpwrak | larsc: ... unless one calls the other (possibly via intermediates) |
| 11:20.02 | DocScrutinizer05 | larsc: C assumes what? No taskswitching allowed during execution of int foo(int *x) ? |
| 11:20.15 | larsc | DocScrutinizer05: exactly |
| 11:20.42 | wpwrak | anyway, gotta get things ready for today's barbecue. 24 C predicted for this chilly mid-winter day :) |
| 11:20.45 | DocScrutinizer05 | now that sounds absolutely BS. How's preemptive multitasking going to work with that? |
| 11:21.07 | *** join/#qi-hardware cladamw (~adamwang@host-193.188-235-182.cable.dynamic.kbtelecom.net) |
| 11:21.47 | larsc | DocScrutinizer05: Well if you run two processes, your two processes run in different contexts and they'll never see each other |
| 11:22.22 | larsc | but if you have two processes which share memory you need to explicitly protect that memory against concurrent access |
| 11:22.39 | DocScrutinizer05 | ummpf, what if I got a IRQ service callback function in same module like int foo(int *x) |
| 11:23.29 | larsc | if that IRQ service routine also accesses your x you need to explicitly write your code to handle that case |
| 11:24.00 | DocScrutinizer05 | I did, by defining x[0] x[1] as semaphore |
| 11:24.29 | larsc | well, see as no native semaphores |
| 11:24.39 | larsc | s/see/C/ |
| 11:24.39 | qi-bot | larsc meant: "well, C as no native semaphores" |
| 11:24.42 | DocScrutinizer05 | and I assumed compiler better not comverts this loop to a decrement loop for optimization |
| 11:24.45 | larsc | s/as/has/ |
| 11:24.45 | qi-bot | larsc meant: "well, C has no native semaphores" |
| 11:25.20 | larsc | it won't. but that's because it does not no what happens inside of usleep |
| 11:25.31 | larsc | s/not no/not know/ |
| 11:25.32 | qi-bot | larsc meant: "it won't. but that's because it does not know what happens inside of usleep" |
| 11:25.41 | larsc | what the fuck is wrong with my typing today? |
| 11:27.36 | lindi- | yeah usleep does a syscall so it is quite hard to optimize |
| 11:28.12 | DocScrutinizer05 | I *might* kick out the usleep (though that's for sure rogue) |
| 11:29.01 | lindi- | for library calls some optimizations are possible though, like converting printf with constant arguments to puts |
| 11:29.17 | lindi- | or printf("%c", c) to putchar(c) |
| 11:29.37 | DocScrutinizer05 | replace that by a simple return(-ETOOFAST) when x[0]==0 |
| 11:30.58 | 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 |
| 11:31.13 | larsc | gcc has extensions like __attribute__(("pure")) which tells the compiler that the function has no sideeffects |
| 11:32.50 | lindi- | larsc: llvm IR has readonly and readnone attributes that are similar |
| 11:32.55 | lindi- | http://llvm.org/docs/LangRef.html#fnattrs |
| 11:33.01 | 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 |
| 11:34.13 | *** join/#qi-hardware porchao (~hato@eatkyo306082.adsl.ppp.infoweb.ne.jp) |
| 11:35.40 | larsc | lindi-: I think llvm, well clang, should also support __attribute__(("pure")) |
| 11:35.46 | 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]... |
| 11:36.03 | lindi- | larsc: yeah, I was talking about how it is represented in the IR |
| 11:36.47 | larsc | DocScrutinizer05: it must see this |
| 11:36.49 | DocScrutinizer05 | no sarcasm, really wondering if compilers might be smart enough for that |
| 11:38.21 | lindi- | DocScrutinizer05: just paste it to http://llvm.org/demo/ |
| 11:38.33 | DocScrutinizer05 | o.O ?? |
| 11:39.14 | DocScrutinizer05 | wow! |
| 12:03.19 | mth | larsc: I'm testing the pwm changes and there is one annoying effect: the numbering changes |
| 12:03.28 | mth | JZ_GPIO_PWM2 becomes pwm 0 etc |
| 12:04.37 | 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? |
| 12:06.38 | 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 |
| 12:10.51 | larsc | mth: e.g. for jz4760 timer 0 and 1 are not used by the kernel, so I think it should be fine |
| 12:12.35 | larsc | I don't really get patch 1 of that series |
| 12:12.41 | larsc | but I might be missing someting |
| 12:13.33 | larsc | Btw. I met with Thierry last week, seems to be a nice guy |
| 12:14.40 | 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 |
| 12:14.45 | mth | I don't know what that something is |
| 12:14.56 | mth | maybe the MIPS version of irq.h? |
| 12:15.23 | larsc | but we include irq.h with "" instead of <> |
| 12:16.12 | mth | hmm, so it's the one that is supposed to be included |
| 12:17.18 | 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" |
| 12:19.00 | mth | maybe it's shadowing arch/mips/include/asm/mach-generic/irq.h? |
| 12:19.08 | mth | that's the one that defines NR_IRQS |
| 12:21.11 | larsc | but we never do #include <irq.h> anyway |
| 12:24.43 | mth | I don't see the rest of the patches include <irq.h> either |
| 12:24.47 | mth | so I'm out of ideas |
| 12:24.58 | mth | I guess you should just ask Thierry |
| 12:25.22 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::1027) |
| 12:27.28 | larsc | I think the pwm_{enable,disable} in jz4740_pwm_config should be jz4740_pwm_{enable,disable} |
| 12:28.10 | mth | I get the pwm backlight driver to init now using the legacy api, but the screen goes dark |
| 12:30.16 | mth | the difference in the enable/disable is this: test_and_clear_bit(PWMF_ENABLED, &pwm->flags) |
| 12:30.39 | larsc | ah, I misunderstood you earlier, the new id's start with PWM2 = 0 |
| 12:30.57 | larsc | that's indeed not so nice |
| 12:36.42 | mth | I think the numbering thing is even causing bugs |
| 12:37.03 | mth | pwm->hwpwm is 5 for PWM7, so it will conifgure timer 5 |
| 12:37.29 | larsc | yea, just saw this as well |
| 12:37.41 | *** join/#qi-hardware urandom__ (~user@p548A20C3.dip.t-dialin.net) |
| 12:39.09 | 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 |
| 12:39.23 | mth | and the core checks it atomically, so that's a bit safer as well |
| 12:40.02 | mth | or jz4740_pwm_config is called with a lock held anyway? |
| 12:40.06 | larsc | I think we should set NUM_PWM to 8 and return -EBUSY for 0 and 1 for in request |
| 12:41.06 | mth | yes, I think that makes it much clearer since it corresponds better with the hardware |
| 12:41.16 | *** join/#qi-hardware kilae (~chatzilla@109.205.205.99) |
| 12:45.23 | mth | ok, with that change it works via the legacy API |
| 12:45.35 | mth | now I have to figure out how the new API works |
| 12:46.30 | larsc | the same, I think |
| 12:46.58 | mth | it seems some kind of registration to work |
| 12:47.05 | mth | see pwm_add_table() |
| 12:48.17 | larsc | ah, probably like the clk api |
| 12:48.40 | mth | there is nothing arch/ that uses 'struct pwm_lookup' though |
| 12:49.47 | mth | so it seems the new API is so new that it's not actually being used yet |
| 12:51.46 | mth | shall I send a diff to Thierry? |
| 12:52.39 | larsc | I think all you need for the PWM_LOOKUP("jz4740-pwm", 4, 0, 0) |
| 12:52.41 | larsc | or similar |
| 12:52.46 | mth | http://www.treewalker.org/temp/jz4740-pwm-all-8.diff |
| 12:52.59 | larsc | all you need for the pwm backlight |
| 12:54.28 | larsc | I'd just comment on the patch |
| 12:58.37 | mth | code is sometimes easier to understand than a description of code... |
| 12:59.36 | mth | PWM_LOOKUP("jz4740-pwm", 7, 0, 0) does not work |
| 12:59.49 | mth | pwm-backlight pwm-backlight: unable to request PWM, trying legacy API |
| 13:01.29 | larsc | hm, ok the first one seems to be the name of the device which requests the pwm |
| 13:01.32 | larsc | so pwm-backlight |
| 13:02.16 | mth | strange to call it "provider" then... |
| 13:02.18 | larsc | no |
| 13:02.19 | larsc | wait |
| 13:02.20 | larsc | yes |
| 13:02.37 | larsc | the 3rd argument is the requesting device |
| 13:03.31 | larsc | but it should also work if it is NULL |
| 13:05.25 | mth | PWM_LOOKUP("jz4740-pwm", 7, "pwm-backlight", 0) does seems to work |
| 13:08.23 | *** join/#qi-hardware panda|x201 (~hzhang@222.130.139.172) |
| 13:18.42 | larsc | about patch 2, I'd like to keep the timer functions as inline functions, do you agree? |
| 13:25.42 | mth | it would reduce the number of exported symbols significantly |
| 13:26.00 | mth | performance wise, I don't think it really matters, since we don't call those functions very often |
| 13:27.03 | larsc | well, they are used in the system clock code |
| 13:30.38 | mth | I sent my comments |
| 13:33.00 | *** join/#qi-hardware guanucoluis (~luis@200.127.180.65) |
| 13:33.16 | mth | does the system clock change the timer configuration often though? |
| 13:33.27 | mth | maybe once adaptive tickless is in it will? |
| 13:34.47 | larsc | well it reads the counter quite often |
| 13:35.12 | mth | ok, then inline is better indeed |
| 13:59.13 | DocScrutinizer05 | ((<larsc> I think we should set NUM_PWM to 8 and return -EBUSY for 0 and 1 for in request)) indeed |
| 14:21.24 | *** join/#qi-hardware kristoffer (~kristoffe@c-fadde555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 14:30.25 | *** join/#qi-hardware cladamw (~adamwang@host-193.188-235-182.cable.dynamic.kbtelecom.net) |
| 14:59.24 | 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 |
| 14:59.56 | larsc | we just need to add some boilerplate code to hook e.g. clocks up |
| 15:08.03 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 15:09.46 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 15:21.29 | *** join/#qi-hardware guanucoluis (~luis@200.127.180.65) |
| 15:40.51 | *** join/#qi-hardware kuribas (~user@d54C43503.access.telenet.be) |
| 15:44.44 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.minimal-20120901-1311 |
| 16:12.44 | *** join/#qi-hardware emeb (~ericb@ip72-201-79-123.ph.ph.cox.net) |
| 16:14.54 | *** join/#qi-hardware kilae_ (~chatzilla@109.205.205.99) |
| 16:23.40 | *** join/#qi-hardware Ayla (~paul@pc-144-230-164-190.cm.vtr.net) |
| 16:37.49 | mth | larsc: this is the glue code we're using for musb on the JZ4770: http://www.treewalker.org/temp/musb-jz4770.diff |
| 16:38.23 | mth | I migrated Ingenic's code from 2.6.31 to 3.5 |
| 16:39.21 | 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 |
| 16:48.51 | larsc | we shouldn't need as much for jz4740 |
| 16:49.56 | larsc | also there is a generic gpio driver for cable detection, iirc |
| 16:55.02 | 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 |
| 16:55.51 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 17:54.08 | *** join/#qi-hardware Ayla (~paul@pc-144-230-164-190.cm.vtr.net) |
| 18:56.06 | *** join/#qi-hardware Ayla (~paul@pc-144-230-164-190.cm.vtr.net) |
| 19:16.59 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 19:32.12 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::1027) |
| 19:38.33 | *** join/#qi-hardware newcup (newcup@peruna.fi) |
| 20:50.31 | *** join/#qi-hardware porchao (~hato@eatkyo306082.adsl.ppp.infoweb.ne.jp) |
| 21:40.48 | Ayla | larsc: hi |
| 21:41.13 | Ayla | arch/mips/jz4740/clock.c:221-222 |
| 21:41.21 | Ayla | do you remember what the '+ 2' is for? |
| 21:43.38 | *** join/#qi-hardware _whitelogger_ (whitelogge@fehu.whitequark.org) |
| 21:43.47 | mth | Ayla: if it's jz_clk_pll_get_rate you're talking about, I don't think larsc is responsible |
| 21:44.22 | mth | in the version I have here, there is no +2 at line 221-222 |
| 21:44.35 | Ayla | ? |
| 21:45.06 | Ayla | there is, on the jz4770 tree |
| 21:46.19 | *** join/#qi-hardware whitequark (whitequark@fehu.whitequark.org) |
| 21:47.30 | mth | ah, I just changed the names of those variables, not the expression |
| 21:48.11 | mth | I think the data sheet just says that the register value is 2 less than the actual value |
| 21:56.42 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::5f1) |
| 22:03.47 | *** join/#qi-hardware wolfspra1l (~wolfsprau@222.130.112.101) |
| 22:09.29 | *** join/#qi-hardware guanucoluis (~luis@200.127.180.65) |
| 22:17.02 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 23:08.09 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 23:15.32 | *** join/#qi-hardware jluis (~jluis@2001:5c0:1000:a::76b) |