| 01:34 | _rmk_ | if you want to measure your 32kHz - http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-measure-32kHz.c |
| 01:34 | _rmk_ | uses the EPIT to clock a counter for 30 sec |
| 01:35 | _rmk_ | mine currently says: |
| 01:35 | _rmk_ | 32768Hz clock is running at 35175Hz |
| 10:45 | dv_ | _rmk_: then I do not understand how freescale can claim they support CEC |
| 10:45 | dv_ | or is some nonstandard code involved for cec in linux-imx ? |
| 10:45 | dv_ | some hack that could never get mainlined |
| 10:58 | _rmk_ | dv_: to support CEC, you need to provide an external crystal and not use the internal ring oscillator |
| 10:59 | dv_ | and I thought CEC was trivial.. |
| 10:59 | dv_ | but anyway, is this something that can be retrofitted easily? |
| 11:05 | _rmk_ | that's something we need Rabeeh to comment on |
| 11:26 | warped-rudi | Is that the same crystal that is used for the RTC ? |
| 11:26 | rabeeh | _rmk_: the 32khz is internally generated or can be provided by external crystal |
| 11:27 | rabeeh | i'v missed last days discussion; does the cec core use the same 32khz rtc crystal? |
| 11:29 | rabeeh | once it's internally generated it's not accurate (i.e. i'v seen 39khz too) |
| 11:33 | _rmk_ | rabeeh: correct, the internal ring oscillator has no kind of accuracy about it - it can be any frequency over 4.5 octaves. |
| 11:33 | _rmk_ | and yes, the CEC core runs off the 32kHz clock |
| 11:33 | rabeeh | ok. |
| 11:33 | rabeeh | that's ok; since the production board will have the 32.768khz crystal assembled |
| 11:34 | rabeeh | we use that for wifi clock in too |
| 11:34 | _rmk_ | there's pads for it on our boards? |
| 11:34 | rabeeh | i.e. the same crystal is regenrated by the imx6 and sent to the wifi brcm chip |
| 11:34 | rabeeh | yes. |
| 11:34 | rabeeh | do you have a 32.768 crystal? |
| 11:34 | rabeeh | it's the same one used in first CuBox |
| 11:35 | _rmk_ | not to hand - I desperately need to add stuff to my farnell order though :) |
| 11:37 | rabeeh | _rmk_: where did you measure the rtc? |
| 11:37 | rabeeh | it's basically a 2 pads 32.768khz crystal with two 18pf capacitors |
| 11:37 | dv_ | rabeeh: I was using a 1 ampere power source before. I take it this can be insufficient. can this be the reason why I sometimes cannot boot the board after resetting? |
| 11:38 | rabeeh | in the production version we have that assembled |
| 11:38 | _rmk_ | rabeeh: I measured it by running the EPIT for 30 sec - http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-measure-32kHz.c |
| 11:38 | _rmk_ | rabeeh: letting the SoC settle, it shows the same deviation as I measure on the timings for the CEC |
| 11:38 | _rmk_ | between 7 to 8% too fast |
| 11:39 | rabeeh | oh; brilliant |
| 11:39 | _rmk_ | at the moment... |
| 11:39 | _rmk_ | 32768Hz clock is running at 35721Hz |
| 11:40 | rabeeh | so if there is no rtc crystal assembled it uses internally generated one |
| 11:40 | dv_ | so no crystal, no cec |
| 11:40 | _rmk_ | yep, "automatically" |
| 11:40 | rabeeh | probably RC circuit which depends on the fabrication itself and is not accurate |
| 11:40 | dv_ | rabeeh: perhaps add this to the product table in the "shop" section of the cubox-i page |
| 11:40 | rabeeh | dv_: why? |
| 11:41 | rabeeh | crystal? |
| 11:41 | _rmk_ | the spec says it can produce "approximately 10 to 45kHz depending on the voltages/temperature" etc |
| 11:41 | dv_ | oh it will be on all cubox-i ? |
| 11:41 | rabeeh | yes |
| 11:41 | rabeeh | i'm not sure about C1 since we want to make it cheapest |
| 11:41 | dv_ | I thought its also used for RTC |
| 11:41 | rabeeh | but then if CEC is dependent on this then we need to rethink |
| 11:42 | dv_ | well how much more would it cost with the crystal? |
| 11:42 | rabeeh | dv_: if you add this and that then it becomes major |
| 11:42 | rabeeh | remember that we are aiming really low, pricing wise |
| 11:42 | dv_ | one could argue that the c1 is a dev board, and that you can only develop cec stuff with the crystal |
| 11:42 | dv_ | yeah |
| 11:43 | rabeeh | dv_: cubox-i will have those crystals assembled for sure |
| 11:43 | dv_ | actually, i might be wrong about this. the c1 is a dev board _now_. in the future, its primarily an rpi clone. |
| 11:44 | dv_ | btw, naming: I like one suggestion on the page: solidone, solidtwo, solidfour |
| 11:47 | rabeeh | dv_: please add to the blog |
| 11:47 | rabeeh | the contest will be over in few hours :) |
| 11:47 | dv_ | well its there already..? |
| 11:47 | dv_ | http://cubox-i.com/carrier-one/ <- Andrew Berend |
| 11:48 | rabeeh | oh it's not your comment then |
| 11:48 | dv_ | no, I was referring to it. |
| 11:49 | rabeeh | i like it too |
| 11:49 | rabeeh | but maybe it's too engineering |
| 11:49 | rabeeh | we want people to bond with it not in an engineering way |
| 11:49 | rabeeh | i think this is the motivation why people name their boards after fruits |
| 11:50 | rabeeh | anyhow the contest will be over soon; 10 names will be gathered and voted |
| 11:52 | dv_ | engineers will come up with engineering-biased names most of the time :) |
| 11:52 | rabeeh | dv_: like carrier one :) |
| 11:52 | rabeeh | it's simply the first carrier that was design to the imx6 |
| 11:53 | rabeeh | i'm kind of bonded to that name; especially the c1 naming |
| 11:53 | rabeeh | but.. it is what it is |
| 11:54 | rabeeh | Dylan wrote - Cee I(V) |
| 11:55 | dv_ | I guess this is something that marketing guys are best at |
| 11:55 | jnettlet | 11:55 * jnettlet_ thinks all the names with fruit in them are just due to people not being very original. |
| 11:55 | jnettlet_ | Just like all the dessert references |
| 11:55 | dv_ | because choosing a good name involves knowledge about how people bond and associate with the names |
| 11:56 | jnettlet | 11:56 * jnettlet_ has a marketing degree |
| 11:56 | rabeeh | dv_: people bond with names, how it's used, why is it good etc... |
| 11:56 | rabeeh | jnettlet_ and other engineers bond with how much mgz, how many processor etc... |
| 11:56 | jnettlet | yep. gear heads |
| 11:56 | rabeeh | other engineers like me :) |
| 11:57 | dv_ | I read once that many people consider tux to be an ingenious idea for a mascot |
| 11:57 | jnettlet | my dog is named Tux |
| 11:57 | dv_ | easy to sell, cute image, can be placed anywhere, instantly associates something wih linux etc. |
| 11:57 | rabeeh | what is a moscot? |
| 11:58 | rabeeh | i'm still searching but found only NY branded product |
| 11:58 | dv_ | hm? |
| 11:58 | jnettlet | and yet I think the Android is better known than Tux |
| 11:58 | jnettlet | mascot |
| 11:58 | dv_ | http://en.wikipedia.org/wiki/Mascot |
| 11:59 | dv_ | jnettlet: yes, because google pushed it on millions of smartphones |
| 11:59 | dv_ | tux is tied with linux, which has always been a fringe OS on the desktop |
| 11:59 | jnettlet | dv_, yes, but those same smartphones all have a Linux kernel. It is mostly about product vs technology. |
| 12:00 | jnettlet | something that Sony did a really good job with, with Dolby |
| 12:00 | dv_ | a heavily modified kernel and rootfs. I think though that tux could have been used for products as well |
| 12:01 | jnettlet | The difference with the rootfs is Android vs Gnu. The kernel has some patches on top but I wouldn't call it heavily modified. |
| 12:02 | wgrant | Is the C-1 going to be sold separately once the C-i is out? It seems like the RPi form-factor has wider appeal than just early platform developers, due to the extra IO etc. |
| 12:03 | MikeSeth | http://blog.erratasec.com/2013/11/isowall-isolating-firewall.html |
| 12:31 | _rmk_ | rabeeh: yea, I think fruity names are too close to Raspberry |
| 12:31 | Bluerise | Please don't use a fruity name. Or Pi. |
| 12:31 | rabeeh | Bluerise: we won't decide |
| 12:31 | Bluerise | hehe. |
| 12:31 | rabeeh | voters will |
| 12:31 | rabeeh | :) |
| 12:32 | Bluerise | I hope they don't vote for something with Pi or a fruit... |
| 12:32 | Bluerise | Hey, I can vote, too! ;) |
| 12:32 | _rmk_ | I guess someone's already suggested More Pi. |
| 12:33 | bencoh | no more pie for me |
| 12:33 | bencoh | :) |
| 12:33 | Bluerise | heh |
| 12:37 | _rmk_ | rabeeh: what if the voters decode upon something which is problematical, eg, trademark wise? |
| 12:37 | rabeeh | _rmk_: we are filtering out the names first |
| 12:37 | rabeeh | we will provide a list of 10 out of ~1000 that were suggested |
| 12:39 | _rmk_ | as I've said before, I'm not entering because I've better chances of winning the national lottery than coming up with a halfway reasonable name. :p |
| 12:39 | Bluerise | Hehe. |
| 12:39 | Bluerise | I never win stuff. |
| 12:39 | Bluerise | The only stuff I win might be a parking ticket |
| 12:39 | _rmk_ | hmm, parking ticket... *hunts for an image* |
| 12:40 | rabeeh | _rmk_: i'v enhanced the test a bit; checking deviation when entering the number of seconds to wait; it becomes stable after 6 seconds |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 1 |
| 12:40 | rabeeh | 32768Hz clock is running at 32775Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 2 |
| 12:40 | rabeeh | 32768Hz clock is running at 32773Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 3 |
| 12:40 | rabeeh | 32768Hz clock is running at 32772Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 4 |
| 12:40 | rabeeh | 32768Hz clock is running at 32772Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 5 |
| 12:40 | rabeeh | 32768Hz clock is running at 32772Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 6 |
| 12:40 | rabeeh | 32768Hz clock is running at 32771Hz |
| 12:40 | rabeeh | # carrier-1-measure-32kHz 30 |
| 12:40 | rabeeh | 32768Hz clock is running at 32771Hz |
| 12:41 | _rmk_ | bluerise: parking ticket: http://www.home.arm.linux.org.uk/~rmk/misc/g/epsom-downs/IMG_0574.JPG |
| 12:41 | Bluerise | a plane? |
| 12:41 | Bluerise | haha |
| 12:42 | _rmk_ | rabeeh: yea, I could have made it run for a shorter period but I wanted to be absolutely certain |
| 12:42 | rabeeh | now those measurements are all relative to the 24mhz (system) clock |
| 12:42 | _rmk_ | bluerise: yep, and I had that photo published in the national gliding magazine |
| 12:42 | bencoh | :)) |
| 12:45 | _rmk_ | rabeeh: note that test is far from perfect because there'll be some overhead for the call into sleep(n).. though three ticks at 32.768kHz is a lot |
| 12:45 | rabeeh | it's a lot |
| 12:45 | rabeeh | and fixed |
| 12:46 | rabeeh | so i'm wondering if this is because of the 24mhz system time |
| 12:46 | _rmk_ | if you measure the regenerated 32768Hz, does that match? |
| 12:48 | _rmk_ | rabeeh: well, if the 24MHz provides the kernel's clocksource, it seems pretty good, NTP is happy with it. |
| 12:48 | rabeeh | for how long did you measure ntp deviations? |
| 12:49 | _rmk_ | ntpdc> peers |
| 12:49 | _rmk_ | remote local st poll reach delay offset disp |
| 12:49 | _rmk_ | ======================================================================= |
| 12:49 | _rmk_ | *caramon.arm.lin ff05::101 3 64 377 0.00148 -0.000006 0.03168 |
| 12:49 | _rmk_ | ntpdc> kerninfo |
| 12:49 | _rmk_ | pll offset: -1.9342e-05 s |
| 12:49 | _rmk_ | pll frequency: 68.645 ppm |
| 12:49 | _rmk_ | maximum error: 0.159804 s |
| 12:49 | _rmk_ | estimated error: 9.1e-05 s |
| 12:49 | _rmk_ | status: 2001 pll nano |
| 12:54 | rabeeh | _rmk_: i can't measure the regenerated 32768hz clock since it's burried inside internal layers and surface only on sink |
| 12:54 | rabeeh | (wifi chip) |
| 12:57 | _rmk_ | rabeeh: I guess a better way to measure it would be to run both EPIT timers, one on the high speed clock and one on the 32kHz clock |
| 12:57 | rabeeh | but this is still relative to each other |
| 12:57 | _rmk_ | remember that sleep(N) is just guaranteed to sleep for _at least_ Nsec |
| 12:58 | rabeeh | i have a board that i can get the generated 32.768khz out |
| 12:58 | _rmk_ | and generally will sleep for N sec plus one tick. |
| 12:58 | rabeeh | i need to solder few things and then can measure |
| 12:58 | rabeeh | yes. |
| 12:58 | rabeeh | context switch and a bunch of others things accumulate |
| 12:59 | rabeeh | don't forget the deep idle of the processors; voltage on/off; ddr low speed etc... |
| 12:59 | rabeeh | they all accumulate into something; maybe the missing 3hz deviation measured |
| 13:05 | _rmk_ | 32768Hz clock is running at 35720Hz |
| 13:05 | _rmk_ | HS clock is running at 65996968Hz |
| 13:08 | _rmk_ | strace -T shows... |
| 13:08 | _rmk_ | nanosleep({10, 0}, 0xbe82f638) = 0 <10.000217> |
| 13:08 | jnettlet | I don't think _rmk_ is running cpu_idle enabled. |
| 13:08 | _rmk_ | no, I'm not, because mainline doesn't have MX6 cpuidle support |
| 13:09 | _rmk_ | not cpufreq support |
| 13:09 | _rmk_ | nor |
| 13:09 | jnettlet | and mainline still lacks DVFS I beleive. |
| 13:09 | jnettlet | believe |
| 13:10 | jnettlet | _rmk_, have you tried out an ultra-light or do you just stick with gliders? |
| 13:10 | _rmk_ | I'm also running with HZ=250, NO_HZ and HIGH_RES_TIMERS |
| 13:12 | jnettlet | I am running HZ=100 NO_HZ NO_HZ_IDLE NO_HZ_COMMON RCU_FAST_NO_HZ and HIGH_RES_TIMERS. |
| 13:12 | jnettlet | too many clock options |
| 13:16 | _rmk_ | jnettlet: I've been in a microlight - http://www.home.arm.linux.org.uk/~rmk/misc/IMG_0921.jpg |
| 13:17 | _rmk_ | and flown it for most of the one hour flight... only bits I didn't do were the take off and landing. |
| 13:20 | _rmk_ | jnettlet: yea, NO_HZ_IDLE is the best that can be done with 32bit atm |
| 13:20 | rabee | 13:20 * rabeeh boots his brand new used Agilent scope |
| 13:22 | _rmk_ | no frequency counter with an OXCO? |
| 13:23 | _rmk | 13:23 * _rmk_ has two here... one which goes up to 860MHz or so. |
| 13:24 | _rmk_ | both complete with olde nixie tubes :) |
| 13:24 | jnettle | 13:24 * jnettlet needs to get a new scope in DK eventually |
| 13:24 | jnettlet | for now I rely on the kindness of strangers with the same hardware and time to burn |
| 13:25 | _rmk_ | actually, I need to get one of those counters (preferably the UHF one) recalibrated |
| 13:27 | _rmk_ | with that one done, I can then recalibrate the other myself... its fairly simple - you compare the reference frequencies on a scope and watch for drift between the two waveforms... adjust to minimise. a lot more accurate than trying to measure one reference frequency on the other counter. |
| 13:30 | _rmk_ | I did the last calibration on them against a rubidium lamp frequency standard. |
| 15:18 | rabeeh | _rmk_: the generated clock is quite jiotter |
| 15:19 | rabeeh | i'm measuring between 32.764 to 32.769; i'm trying to figure out why |
| 15:21 | _rmk_ | rabeeh: could it have something to do with the 32768Hz going through an ipg clock synchronizer (66MHz iirc)? |
| 15:38 | MikeSeth | you guys dug out a hardware problem? |
| 15:41 | rabeeh | MikeSeth: _rmk_ found out that CEC clock is related to RTC clock which means 32.768khz crystal must be assembled on the board. |
| 15:42 | MikeSet | 15:42 * MikeSeth scrolls up |
| 15:43 | _rmk_ | rabeeh: do you have any info on the crystal and two capacitors, such as case size/footprint info? |
| 15:43 | MikeSeth | so it's a problem on prototype boards only? |
| 15:43 | _rmk_ | MikeSeth: cubox-i will have the crystal fitted. |
| 15:43 | rabeeh | MikeSeth: yes |
| 15:44 | _rmk_ | MikeSeth: carrier-1 at the moment comes without for cost reduction. |
| 15:44 | rabeeh | _rmk_ two capacitors are 18pF 0402 in size |
| 15:44 | MikeSeth | I'm no hardware wizard, but I have this gut wretching feeling at the mention of automagic fallback to internal clock |
| 15:45 | _rmk_ | rabeeh: C0G grade? |
| 15:46 | rabeeh | _rmk_: whatever |
| 15:46 | _rmk_ | I like that answer even better :) |
| 15:47 | rabeeh | https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CC8QFjAB&url=http%3A%2F%2Fmedia.digikey.com%2Fpdf%2FData%2520Sheets%2FNDK%2520PDFs%2FNX3215SA-32.768K-STD-MUA-8.pdf&ei=5u2AUtGzG4PYtAaD6oCABw&usg=AFQjCNE-fxaUUP55_9DmcwaSEr7czMakkg&bvm=bv.56146854,d.d2k&cad=rja |
| 15:49 | rabeeh | _rmk_: besides that i doubt you can buy non COG / NPO from Digikey on those values |
| 15:49 | rabeeh | anyhow for your question; we use COG |
| 15:49 | rabeeh | the link is the exact crystal we use for the 32.768khz |
| 15:50 | _rmk_ | ok, thanks |
| 15:50 | _rmk_ | COG is the most sensible ceramic for this application |
| 15:50 | rabeeh | _rmk_ even if the rtc clock is sampled in 66MHz you don't get -+2hz deviation in the 32.768khz measurement |
| 15:51 | _rmk_ | just checked previous projects... just in case I had any 18p SMT caps but no... lowest I have is 100p. |
| 15:52 | rabeeh | _rmk_: if i get murata sample caps (100 different types of their 0402 capacitors) i will send you one |
| 15:53 | rabeeh | you get 100 x 20 samples |
| 15:53 | rabeeh | it's really good for prototyping |
| 15:54 | MikeSeth | I just realised my new LCD is CEC compliant and I can use its remote |
| 15:56 | MikeSeth | ooh, fuzzable vendor commands |
| 16:05 | _rmk_ | rabeeh: farnell have a suitable crystal at ?0.95 at small quantities, and ?0.10 for 10 of the 18p caps... again, small quantities... |
| 16:06 | _rmk_ | that brings my order with them up to ?12.09 which is ?7.91 below the point I can actually press the "order" button. :( |
| 16:08 | rabeeh | _rmk_: i can send you whatever you want |
| 16:08 | rabeeh | �0.95 for a crystal? |
| 16:08 | rabeeh | it's a diamond not crystal |
| 16:09 | _rmk_ | heh. if I want 1500+ of them, they'll drop it to ?0.43 |
| 16:10 | _rmk_ | that's for an Abracon ABS07-32.768KHZ-T one |
| 16:13 | _rmk_ | rabeeh: remember, I live in rip-off britian, where prices tend to be inflated... currency conversion from stuff in the US... you just replace the $ with a ? symbol and don't bother with hard math. :) |
| 16:14 | rabeeh | _rmk_: have an LVDS display by a chance? |
| 16:15 | rabeeh | _rmk_: btw - even for replacing �0.43 wit $0.43; it's still too much |
| 16:15 | rabeeh | (yes - for 1500 units) |
| 16:16 | rabeeh | dv_: what is the issue with your psu? |
| 16:16 | rabeeh | 'reboot' doesn't work? |
| 16:18 | _rmk_ | rabeeh: I don't have a LVDS display... unless I dismantle an old TV |
| 16:54 | jnettlet | I have a 10" lvds panel from my netbook |
| 17:07 | neofob | rabeeh: so do other Marvell chips, not 510, support hardware tcp checksum for mtu > 1600, or this is only 510? |
| 17:18 | rabeeh | neofob: part of them do and part does'nt |
| 17:18 | rabeeh | i can't recall which; but you can see it in the public specs |
| 17:24 | neofob | rabeeh: thanks. so the patch that works for cubox (marvell 510) will impact other marvell chips :-/ |
| 17:24 | rabeeh | yes |
| 17:28 | neofob | i just wonder how convincing it could be to have shesselba to merge it upstream |
| 20:21 | shesselba | neofob: is there any noticeable impact in speed? dove ethernet is cpu limited, i.e. everything that reduces amount of packet mangling should improve overall speed |
| 20:21 | shesselba | although, IIRC jumbo-frames are not that wide-spread, are they? |
| 20:29 | rabeeh | shesselba: they are not that widespread; but you can get huge boost if used |
| 20:32 | shesselba | rabeeh: but is it still routeable with jumbo frames? |
| 20:33 | rabeeh | you need switches for LAN that supports jumbo frames |
| 20:33 | _rmk_ | shesselba: it's routable, and it obeys the standard rules concerning the DF bit and MTUs |
| 20:33 | shesselba | ok |
| 20:34 | _rmk_ | IOW, if you send a jumbo packet and it hits a router, and it won't fit in the destination's MTU, you'll get an ICMP response back telling you... |
| 20:34 | shesselba | neofob: if you stich a patch and provide some performance results, there is no way around that patch ;) |
| 20:35 | _rmk_ | otherwise people with networks behind ADSL wouldn't work... ethernet MTU = 1500, ADSL tends to be below that, esp. here. |
| 20:45 | shesselba | neofob: dove does chksum for all packets, kirkwood (and possibly older SoC IP too) are limited to TX HW chksum < 1600 - so be careful not to break them |
| 21:35 | neofob | shesselba: iperf w/o the the patch is around 70MB/s |
| 21:35 | neofob | with the patch is over 100MB/s |
| 21:36 | _rmk_ | worth having then |
| 21:36 | shesselba | yep |
| 21:39 | neofob | I took a screenshot awhile ago: http://bit.ly/HJz0jd |
| 21:40 | neofob | this one with my comment on it: https://plus.google.com/u/0/photos/+TuanTPham/albums/5788604886267483777 |
| 21:41 | lioka | _rmk_: is xf86-video-armada supports XVideo on c1 ? |
| 21:42 | _rmk_ | I've not tested it yet, but it should do |
| 21:42 | _rmk_ | I only checked that the XVideo extension initialised, not that it was functional |
| 21:42 | _rmk_ | if the DRM plane support is properly implemented, it should work. |
| 21:42 | lioka | as far i'm getting 'no adaptors present' from xvinfo |
| 21:43 | neofob | shesselba: the patch is here, https://gist.github.com/neofob/3158055 |
| 21:47 | _rmk_ | lioka: you're using my xorg.conf ? |
| 21:47 | neofob | right now, you cannot set mtu over 1600 on cubox because it doesn't support hardware TX checksum |
| 21:47 | neofob | as i understand, this patch will disable the hardware checksum when mtu is > 1600; it only effect GigE and router that supports jumbo frame though |
| 21:47 | lioka | _rmk_: yep |
| 21:48 | shesselba | neofob: as long as it doesn't break any other SoC, I am fine with it |
| 21:49 | shesselba | would you mind sending the patch to LKML and netdev ML referencing original author? |
| 21:49 | _rmk_ | ah, the carrier-1-v3.12-all.diff doesn't have DRM plane support in it... hang on a moment and I'll give you a new kernel patch |
| 21:50 | lioka | _rmk_: imx-drm-Enable-DRM-PRIME-support.patch |
| 21:50 | neofob | shesselba: sure, do i need to format it to email form and that fancy kernel standard? |
| 21:50 | neofob | that is the diff from my git diff |
| 21:50 | _rmk_ | prime != plane :) |
| 21:51 | lioka | right. where my eyes |
| 21:51 | _rmk_ | prime was the easy one to grab off the archive site, because it was a small patch |
| 21:52 | _rmk_ | plane support was a much larger patch which I wasn't going to fix up the inherent whitespace damage with that method |
| 21:52 | _rmk_ | however, since then, Linus has merged those changes into mainline, so I was able to grab them from there. |
| 21:53 | lioka | _rmk_: sha1 then would be enough, i have linus' tree around |
| 21:54 | _rmk_ | its part of a larger patch series, and I suspect there may be dependencies on preceding patches |
| 21:54 | shesselba | neofob: sure, Documentation/SubmittingPatches |
| 21:54 | shesselba | or wait until I find some time (then I need your Name and Email to correctly name you as the original author) |
| 21:55 | lioka | _rmk_: it is basically b8d181e staging: drm/imx: add drm plane support |
| 21:55 | lioka | right ? |
| 21:55 | _rmk_ | yea, you can try just cherry picking that but I suspect it'll conflict |
| 21:56 | neofob | shesselba: also, i only have Cubox with Marvell chip so I need others to review and test out on other Marvell chips |
| 21:56 | lioka | i guess i manage, thanks |
| 22:00 | shesselba | neofob: I'll test on Kirkwood, others on list can too. ppc would be difficult, haven't seen anyone with one recently. |
| 22:00 | shesselba | but we can make it safe for ppc, not a big deal |
| 22:04 | _rmk_ | lioka: if you get into trouble... http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-v3.12-all-20131111.diff |
| 22:05 | neofob | shesselba: thanks for the info; folks who run Plug computer can test this also, i think |
| 22:13 | lioka | _rmk_: thanks |
| 22:27 | _rmk_ | lioka: the answer is... segfault |
| 22:28 | _rmk | 22:28 * _rmk_ debugs |
| 22:29 | _rmk_ | ah... fixes. |
| 22:34 | _rmk_ | but you don't have the changes which caused that. :) |
| 22:45 | _rmk | 22:45 * _rmk_ rotfls. |
| 22:54 | _rmk_ | looks like there's something up with imx-drm plane support |
| 22:54 | _rmk_ | has a tendency to return -EINVAL... |
| 22:59 | _rmk_ | (a) they mistake the src parameters as being in pixels, they're in 16:16 fixed point format. |
| 22:59 | _rmk_ | (b) there is no support for scaling at all in the driver... maybe there's no support for it in hardware either. |
| 23:07 | _rmk_ | oh my. this isn't going to work very well. |
| 23:07 | _rmk_ | so it looks like the iMX can only render an overlay at the original image size |
| 23:08 | _rmk_ | it can't scale it in any way |
| 23:08 | _rmk_ | so we're going to need a special Xorg driver to have this knowledge, and going to have to use the GPU to scale the image every time. |
| 23:09 | _rmk_ | so... basic overlay support is going to be a non-starter atm :( |
| 23:30 | lioka | well, w/o scale there's no point in it |
| 23:31 | liok | 23:31 * lioka will switch to original cubox then |
| 23:37 | _rmk_ | indeed. crap hardware. |
| 23:42 | _rmk_ | ah yes it can |
| 23:44 | dv_ | are you using the IPU overlays |
| 23:46 | _rmk_ | that's the idea of the DRM plane support |
| 23:47 | _rmk_ | what's implemented in drivers/staging is buggy atm |
| 23:48 | _rmk_ | let's get the author to fix one of these bugs first... |
| 23:51 | dv_ | I havent used the overlays yet. but the IPU can definitely scale. |
| 23:51 | _rmk_ | mail sent, also asking about getting scaling support done. |
| 23:51 | dv_ | I think I have seen them in action in the ipu examples package. or in the imx-test one. |