00:25.21 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
01:08.22 | *** join/#qi-hardware Jay7x (jay@128-73-32-59.broadband.corbina.ru) |
01:11.12 | *** join/#qi-hardware larsc_ (~lars@eisbaer.ursus-maritimus.org) |
01:11.25 | *** join/#qi-hardware wolfspra1l (~wolfsprau@221.220.179.126) |
01:46.59 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
02:10.04 | *** join/#qi-hardware wolfspraul (~wolfsprau@221.220.179.126) |
02:45.20 | qi-bot | [commit] Adam Wang: sot.fpd: added package of SO-235 also for TI DBV(R-PDSO-G5) (master) http://qi-hw.com/p/kicad-libs/445734e |
03:23.10 | qi-bot | [commit] Adam Wang: generic header through hole type (master) http://qi-hw.com/p/kicad-libs/f5392ae |
03:24.34 | qi-bot | [commit] Adam Wang: added header.fpd: copied from Werner Almesberger (master) http://qi-hw.com/p/kicad-libs/045e848 |
03:25.33 | wpwrak | good. you found it :) |
03:27.11 | wpwrak | that's another 80 footprints |
03:30.28 | cladamw | yes, but too bad that i just did another 2*row header weeks ago. :( |
03:30.37 | cladamw | but still okay. :-) |
03:31.15 | wpwrak | well, it's a relatively simple one :) |
03:31.16 | cladamw | i forgot to make test points module. seems you also didn't make before. :) |
03:31.52 | cladamw | TP is the last work for links. else all are done. :-) |
03:32.38 | wpwrak | i use things from pads.fpd for TP |
03:32.39 | cladamw | Test Points could be many types, round, square, circle, with suitable cut-out area. |
03:32.57 | cladamw | oh ... that one i see. :-) |
03:33.19 | cladamw | but not enough to meet future work and m1. :-) |
03:33.44 | wpwrak | you can add more ;-) |
03:34.04 | wpwrak | btw, there's another place to consider for scavenging: http://svn.openmoko.org/trunk/gta02-core/modules/ |
03:34.34 | wpwrak | these things are ancient and often with bugs, but some may still be useful |
03:34.43 | cladamw | aha ... nice, the server comes back. :-) |
03:35.17 | wpwrak | a catalog is here: http://people.openmoko.org/werner/gta02-core/gta02-core-modules.pdf |
03:40.10 | cladamw | good seems the diode's marker is better than ours now |
03:40.27 | cladamw | and there's TST module. :-) |
03:40.52 | wpwrak | well, tst is a precursor of pads :) |
03:41.18 | cladamw | yeah .... |
03:41.36 | cladamw | well... i need to make new one. :) |
03:43.55 | wpwrak | why not just add one in pads ? |
03:45.40 | cladamw | sure, i meant to add more variants in pads. :-) |
03:51.32 | *** join/#qi-hardware pabs3 (~pabs@d122-109-113-185.per801.wa.optusnet.com.au) |
04:32.51 | *** join/#qi-hardware emeb (~ericb@12.68.180.146) |
05:25.40 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
05:33.12 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
05:39.19 | *** join/#qi-hardware kristoffer (~kristoffe@c-6ddae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
06:28.51 | qi-bot | [commit] Adam Wang: pads.fpd: added variant sets of C(circle), R(oround) and S(square) pads. (master) http://qi-hw.com/p/kicad-libs/3b35416 |
07:02.03 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
07:05.08 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
07:34.09 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
07:57.32 | DocScrutinizer05 | wpwrak: I strongly suggest you simulate your idea of limiting inrush current with a choke, in spice |
07:57.56 | DocScrutinizer05 | you'll notice quite differnet effects than what you hoped for |
07:59.16 | DocScrutinizer05 | it *could* even fry your USB plug |
08:06.23 | DocScrutinizer05 | as in an ideal circuit the sinuoidal half wave of current will reach maximum when input and output of choke are both at 5V. Then current decays until it reaches 0 when input=5V and output=10V |
08:14.48 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
08:32.41 | *** join/#qi-hardware jurting (~jommpa90_@ip-63-15-72-178.dialup.ice.net) |
09:08.16 | *** join/#qi-hardware wej (~j@95.211.13.35) |
09:38.44 | *** join/#qi-hardware jivs (~jiva@cpc17-haye18-2-0-cust235.17-4.cable.virginmedia.com) |
09:40.48 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
10:38.18 | *** join/#qi-hardware jivs_ (~jivs@cpc17-haye18-2-0-cust235.17-4.cable.virginmedia.com) |
10:48.07 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
11:30.44 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-107-213.netcologne.de) |
12:00.27 | *** join/#qi-hardware Artyom (~chatzilla@195.19.58.6) |
12:01.16 | wpwrak | DocScrutinizer: don't worry, suitable chokes are all too big anyway. i'm just solving this with procedure :) besides, i have OTA updates working now. farewell, programming cable :) |
12:03.06 | Artyom | Have anyone seen/tested this toy: http://www.zedboard.org/node/8 ? |
12:06.47 | whitequark | did they, hm, take a xilinx devboard and replace the fpga with cortex-a9? |
12:07.31 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
12:13.47 | Artyom | whitequark: which devboard do you mean? |
12:22.05 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
12:40.56 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-222-82.w86-215.abo.wanadoo.fr) |
12:41.04 | rzk | whitequark: its on xilinx zynq, probably shares same design as other "default xinix devkit"-ish stuff. even digilent logo is there. |
12:41.19 | rzk | s/xinix/xilinx |
12:41.21 | qi-bot | rzk meant: "whitequark: its on xilinx zynq, probably shares same design as other "default xilinx devkit"-ish stuff. even digilent logo is there." |
12:49.02 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
12:49.18 | *** join/#qi-hardware jivs (~jivs@nat-sta-slph1.tvu.ac.uk) |
12:53.33 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
12:53.44 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
13:18.55 | whitequark | Artyom: nexys |
13:28.03 | Artyom | looks similar but not exactly the same... |
14:02.53 | *** join/#qi-hardware Hoolxi (~Openfree@58.34.248.69) |
14:45.16 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
14:56.16 | *** join/#qi-hardware emeb (~ericb@12.68.180.146) |
15:02.06 | *** join/#qi-hardware rzk (~rzk@2002:5f1c:a83d:1:222:4dff:fe7c:450f) |
15:31.47 | *** join/#qi-hardware jluis_ (~jluis@32.Red-79-152-171.dynamicIP.rima-tde.net) |
15:43.50 | *** join/#qi-hardware zear_ (~zear@2001:0:5ef5:79fd:34a8:3df1:2abe:b43b) |
15:52.37 | *** join/#qi-hardware zear- (~zear@h196n1-g-kt-a31.ias.bredband.telia.com) |
15:59.12 | *** join/#qi-hardware antoniodariuh_ (~antonioda@nat-sta-slph1.tvu.ac.uk) |
16:16.43 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
16:16.46 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
16:18.20 | *** join/#qi-hardware urandom__ (~user@ip-88-152-210-163.unitymediagroup.de) |
16:40.01 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
16:40.04 | kristianpaul | Artyom, thanks for license update about kicad project ! |
16:40.12 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
16:59.15 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
16:59.48 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
17:20.11 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
17:20.27 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
17:34.31 | Ayla | mth: hi, what's the name of the upcoming feature on the kernel that stops the periodic IRQ when there's only one task running? |
17:41.40 | DocScrutinizer51 | sth pretty unlikely to ever happen |
17:42.34 | DocScrutinizer51 | well |
17:42.57 | DocScrutinizer51 | no task running might be a more likely case |
17:49.21 | viric | why? |
17:49.34 | viric | what should the kernel do periodically, for one task running? |
17:54.28 | DocScrutinizer51 | I hardly can see one task running solitary |
17:55.11 | roh | DocScrutinizer51: ;) |
17:55.15 | whitequark | hm |
17:55.21 | whitequark | wasn't that "tickless kernel"? |
17:55.21 | viric | non-sleeping |
17:55.31 | whitequark | and isn't it implemented eons ago? |
17:55.40 | DocScrutinizer51 | thought so |
17:55.41 | viric | whitequark: yes, I also thought of NO_HZ, but I don't know what's this about then |
17:55.41 | roh | just checked and has >200 tasks running somewhat. most sleeping till their next wakeup |
17:56.19 | whitequark | viric: link? |
17:56.30 | viric | whitequark: Ayla mentioned it, not me |
18:04.36 | whitequark | oops |
18:15.02 | qi-bot | Yann Sionneau (RT Qi Hardware(1)): RT @qihardware: New pictures of the Milkymist1 #video Synth in action with http://t.co/GEZqm38T at Blip Festival http://t.co/nL1xk4RF #vj #music ( 215145515539644417@qihardware - 39s ago via Echofon ) |
18:46.52 | DocScrutinizer06 | >>"The tickless kernel feature (CONFIG_NO_HZ) enables 'on-demand' timer interrupts: if there is no timer to be expired for say 1.5 seconds when the system goes idle, then the system will stay totally idle for 1.5 seconds. This should bring cooler CPUs and power savings: on our (x86) testboxes we have measured the effective IRQ rate to go from HZ to 1-2 timer interrupts per second.<< |
18:49.00 | DocScrutinizer06 | so AIUI this means there shouldn't be any such thing like a periodic IRQ since ~2006 |
18:55.01 | qi-bot | Fabricatorz: RT @qihardware: New pictures of the Milkymist1 #video Synth in action with http://t.co/gjPTem0S at Blip Festival http://t.co/yMmaOIOn #vj ( 215155486163599363@fabricatorz - 1m, 2s ago via HootSuite ) |
19:28.55 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
20:20.41 | *** join/#qi-hardware heberth (~heberth@190.97.216.58) |
20:44.46 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
20:45.38 | *** join/#qi-hardware heberth (~heberth@190.97.216.58) |
21:00.33 | *** join/#qi-hardware losinggeneration (~quassel@75-170-149-191.desm.qwest.net) |
21:44.48 | Ayla | whitequark: I don't know how to explain it, mainly because I don't really understand what it is |
21:45.38 | Ayla | mth said that the "tickless" feature is not exactly what he thought it was, only a part of it |
22:00.59 | Ayla | ah, found it |
22:01.24 | Ayla | https://lkml.org/lkml/2011/8/15/245 |
22:11.52 | *** join/#qi-hardware kristianpaul (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:17.52 | *** join/#qi-hardware kristianpaul (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:24.44 | *** join/#qi-hardware user (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:30.38 | *** join/#qi-hardware user (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:31.42 | *** join/#qi-hardware user (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:34.14 | *** join/#qi-hardware kristian1aul (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:37.02 | *** join/#qi-hardware kristian1aul (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:39.56 | whitequark | Ayla: yeah, got it. an interesting idea |
22:40.07 | whitequark | https://github.com/fweisbec/linux-dynticks/wiki/TODO |
22:40.18 | whitequark | looks like it won't get to mainline any soon |
22:40.31 | Ayla | yes... but now I realize that it's probably not useful at all if you have only one CPU |
22:41.05 | whitequark | mobile devices start to explore the smp world |
22:41.24 | whitequark | and that's where power consumption matters |
22:49.01 | *** join/#qi-hardware kristianpaul (~kristianp@cl-498.udi-01.br.sixxs.net) |
22:49.01 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
23:09.11 | mth | whitequark: current tickless only disables the timer interrupt if the system is idle |
23:09.23 | mth | while it could also be disabled if there is only one task that wants to run |
23:09.37 | Ayla | but then how to count the jiffies? |
23:10.46 | mth | if you can read a timer register, you could use that |
23:10.54 | mth | so make it count, just don't make it fire often |
23:12.02 | Ayla | then it'd be specific to the hardware |
23:12.27 | Ayla | as a generic MIPS processor doesn't have a timer register (it does?) |
23:14.04 | mth | it would only work on certain hardware, but for embedded systems I don't see that as a problem |
23:14.16 | mth | if your hw supports it, you enable it, otherwise you don't |
23:14.40 | Ayla | ok |
23:15.03 | Ayla | and does the jz4740 have that? |
23:15.37 | mth | iirc you can read the timer as it's counting, but let me check |
23:16.36 | mth | it can be read, but it's only 16 bits |
23:17.48 | mth | you can set a divider for the clock input of the timer though |
23:20.47 | mth | RTC clock is 32768 Hz, so if you prescale that by a factor 64 you get 512 Hz and the timer overflows after more than 2 minutes |
23:21.21 | mth | maybe that's why HZ=256 is useful |
23:22.23 | mth | even at prescale 1 though, you've got 2 seconds until the timer overflows |
23:22.49 | mth | so if you set the timer interrupt to once per second and read the timer counter inbetween, you still save a huge number of interrupts |
23:23.02 | Ayla | RTC clock is fixed? |
23:23.12 | Ayla | it seems to depend on the PLL |
23:23.24 | mth | no, RTC clock does not |
23:23.46 | mth | it cannot, since it has to run even during sleep and the PLL is off then |
23:25.37 | Ayla | ok |
23:26.27 | mth | what I don't know is how much impact such a change would have on the kernel code |
23:26.32 | mth | but in theory it could work |
23:27.04 | mth | I guess jiffies would have to be read with a function rather than from a variable (it is a variable now, right?) |
23:27.30 | mth | but a function can be inlined if this feature is off in the config, so it's no extra overhead then |
23:28.28 | Ayla | it's a variable, yes |
23:43.48 | Ayla | I'm surprised, the ondemand governor works quite well now |
23:45.10 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
23:51.03 | DocScrutinizer06 | whitequark: (smp) http://www.stericsson.com/products/L8540.jsp |
23:51.15 | DocScrutinizer06 | my daily job ;-D |
23:52.34 | *** join/#qi-hardware zear (~zear@2001:0:5ef5:79fd:c84:3c5d:2abe:b43b) |
23:52.46 | DocScrutinizer06 | mth: the case when exactly one task is "R" is really rare |
23:53.47 | *** join/#qi-hardware phirsch_ (~phirsch@xdsl-89-0-165-146.netcologne.de) |
23:54.01 | Ayla | mth, larsc_: the USB driver really doesn't like CPU frequency changes |
23:54.26 | DocScrutinizer06 | lol, sure |
23:54.45 | DocScrutinizer06 | esp when it's changing master clock |
23:54.46 | Ayla | I can't keep a telnet session open for a long time with the ondemand governor |
23:55.01 | Ayla | no, that's a bug |
23:55.13 | Ayla | it doesn't crash on PC, it shouldn't crash on dingoo/nanonote |
23:55.17 | *** join/#qi-hardware wej (~j@95.211.13.35) |
23:56.01 | DocScrutinizer06 | the clock generator is definitely a special unique critter on every platform/SoC |
23:56.41 | DocScrutinizer06 | ideally you can change CPU clock without any impact on UART et al clocks |
23:56.54 | mth | why would there be more than one running task when a typical framebuffer application is running? |
23:56.59 | DocScrutinizer06 | on S3C2410 this wasn't the case |
23:57.16 | mth | if I run htop in the Dingoo while in the menu, I see only htop itself as running |
23:57.25 | mth | even the menu is sleeping until I press a key |
23:57.46 | DocScrutinizer06 | still I bet X is running too |
23:57.51 | mth | there is no X |
23:58.22 | mth | this is not a desktop, it's very much stripped down |
23:58.28 | DocScrutinizer06 | well, just saying one R task is relatively rare |
23:58.56 | DocScrutinizer06 | and then I fail to see why there's any IRQ firing in that case |
23:59.18 | DocScrutinizer06 | but probably I'm just too tired now |
23:59.34 | DocScrutinizer06 | inline with that: n8 fellas |
23:59.35 | mth | the IRQ fires because that's how the kernel is written |
23:59.41 | mth | it doesn't really have to, in theory |
23:59.54 | mth | nite |
23:59.57 | DocScrutinizer06 | it soesn't, since no-hz AIUI |