| 00:20.34 | *** join/#arm-netbook tuliom (~tuliom@186.214.89.54) |
| 00:56.13 | *** join/#arm-netbook sspiff (~quassel@94.103.155.103) |
| 00:56.13 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 02:02.29 | *** join/#arm-netbook rvalles (~rvalles@unaffiliated/rvalles) |
| 02:37.01 | *** join/#arm-netbook mSquare (~selvan@122.167.227.160) |
| 02:37.45 | *** join/#arm-netbook itamarjp (~itamar@fedora/itamarjp) |
| 02:55.50 | *** join/#arm-netbook Quarx (~Quarx@94.137.56.132) |
| 02:55.53 | *** join/#arm-netbook mSquare (~selvan@122.167.227.160) |
| 03:50.56 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |
| 04:28.30 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |
| 04:28.30 | *** join/#arm-netbook techn_ (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 04:28.30 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 04:28.30 | *** join/#arm-netbook ccssnet (~ccssnet@c-98-216-141-157.hsd1.ma.comcast.net) |
| 04:28.30 | *** join/#arm-netbook CIA-15 (cia@cia.vc) |
| 04:35.05 | eflatun | techn are you there |
| 04:42.29 | *** join/#arm-netbook xxiao (~xxiao@ec2-50-112-57-59.us-west-2.compute.amazonaws.com) |
| 04:47.04 | eflatun | if you hear me i want a favor from you. i need you to help me for running linux on MiniX (mk805). |
| 05:14.28 | *** join/#arm-netbook lkcl (~lkcl@host217-43-149-27.range217-43.btcentralplus.com) |
| 06:03.27 | *** join/#arm-netbook eFfeM (~frans@dhcp-077-251-240-021.chello.nl) |
| 06:10.15 | *** join/#arm-netbook rellla (~Thunderbi@p5B078263.dip0.t-ipconnect.de) |
| 07:13.10 | *** join/#arm-netbook rvalles (~rvalles@unaffiliated/rvalles) |
| 07:32.50 | *** join/#arm-netbook rellla (~Thunderbi@p5B07810F.dip0.t-ipconnect.de) |
| 07:50.47 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 08:20.11 | *** join/#arm-netbook arokux (~arokux@merkur178.inf.uni-konstanz.de) |
| 08:28.13 | *** join/#arm-netbook arokux (~arokux@merkur178.inf.uni-konstanz.de) |
| 10:08.03 | *** join/#arm-netbook lkcl (~lkcl@host217-43-149-27.range217-43.btcentralplus.com) |
| 10:23.33 | *** join/#arm-netbook pawel5870 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 10:32.55 | *** join/#arm-netbook mSquare (~selvan@122.167.227.160) |
| 11:02.58 | *** join/#arm-netbook lkcl (~lkcl@host217-43-149-27.range217-43.btcentralplus.com) |
| 11:28.25 | *** join/#arm-netbook Almamuetya (~almamuety@186.134.25.153) |
| 12:15.55 | ManoftheSea | hmm, I just missed him. |
| 12:46.39 | *** join/#arm-netbook itamarjp (~itamar@fedora/itamarjp) |
| 13:14.22 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 13:14.57 | *** join/#arm-netbook eflatun (~eflatun@46.1.117.121) |
| 13:51.42 | *** join/#arm-netbook mnemoc (~amery@geeks.cl) |
| 13:53.16 | eflatun | techn hi you there? |
| 14:07.33 | *** join/#arm-netbook polto2010 (~polto2010@41.238.58.150) |
| 14:24.54 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 14:33.27 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 14:33.36 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 14:38.40 | hno | http://www.phoronix.com/scan.php?page=news_item&px=MTE5MDk |
| 14:41.01 | RaYmAn | they added a lot of 2d info to the trm like, months ago |
| 14:41.03 | RaYmAn | before they were hacked |
| 14:44.44 | hno | RaYmAn, available without NDA? |
| 14:45.03 | hno | was NVidia hacked? |
| 14:46.07 | RaYmAn | I'm not entirely sure whether their online agreement to get an account to download it counts as an NDA or not |
| 14:46.20 | RaYmAn | they developer site was - it's been mostly down since |
| 14:48.08 | *** part/#arm-netbook eFfeM (~frans@dhcp-077-251-240-021.chello.nl) |
| 15:05.50 | *** part/#arm-netbook mSquare (~selvan@122.167.227.160) |
| 15:24.12 | hno | SATA connected via Graphics Memory Interface? Feels kind of like they misnamed that memory bus. |
| 15:39.42 | *** join/#arm-netbook ZaEarl (~malmrose@173.11.125.162) |
| 15:46.36 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:8cdb:391d:9c47:53b7) |
| 16:06.38 | *** join/#arm-netbook cat1 (~cat_x301@a91-152-66-200.elisa-laajakaista.fi) |
| 16:15.56 | techn_ | eflatun: hi.. sure I can help :) |
| 16:16.13 | mnemoc | wb techn_ |
| 16:17.29 | techn_ | mnemoc: thanks.. I'll try to push initial edid support today |
| 16:17.48 | mnemoc | \o/ |
| 16:18.02 | techn_ | It's a bit hacky.. Whole disp needs refactoring to get it better |
| 16:24.01 | cat1 | techn_: any chance to send patch(es) to linux-sunxi@googlegroups.com ? at least it will be visible and somebody might want to give some comments if any. Also, one can test patch instantly by applying from mail. Sorry if I ask too much :) |
| 16:27.31 | cat1 | thinks that it generally would be good to send all upcoming patches to ml. really. |
| 16:27.44 | mnemoc | +1 |
| 16:27.47 | techn_ | cat1: you can comment on github.com/techn? I'm not much for doing extra work ;) |
| 16:28.16 | techn_ | or to github.com/amery if I'll do pull request? ;)* |
| 16:28.49 | cat1 | techn_: yeah, this will do too.. but.. |
| 16:29.04 | techn_ | but sure I can if it's decided and proofed better :) |
| 16:30.30 | cat1 | techn_: to me it is more trackable. e.g. one will know what patches are flying around and can pick them into own tree if needed. i am not sure if one e.g. can apply a single patch from github directly. |
| 16:31.36 | techn_ | cat1: so can you tell what's better on mailing list code review? (newer done that.. expect stypid excel/beyond compare reviews) |
| 16:32.44 | techn_ | cat1: you can take patches out from github |
| 16:32.45 | cat1 | techn_: hmm.. it is difficult to explain, but you can do inline comments and keep discussion in i would say more "natural" way :) |
| 16:32.46 | mnemoc | git even knows to send commits by email specially for that |
| 16:33.14 | mnemoc | techn_: it's not that. from git a hash can be deleted and lost |
| 16:33.19 | cat1 | techn_: check git send-email |
| 16:33.24 | mnemoc | techn_: or rebased and new hash assigned |
| 16:33.37 | mnemoc | on email the real history of the commit is preserved |
| 16:33.44 | mnemoc | including the whole discussion |
| 16:34.44 | cat1 | mnemoc: right, and then again, it is easy to check patch w/o getting it commited into mailline (amery/..) |
| 16:35.02 | mnemoc | cat1: fully agree. I'm all in favour of the ML |
| 16:35.02 | cat1 | s/mailline/mainline |
| 16:39.34 | *** join/#arm-netbook eflatun (~eflatun@46.1.121.129) |
| 16:41.34 | cat1 | techn_: btw, it is also good practise to get patch through ./scripts/checkpatch.pl before sending for review. |
| 16:41.48 | techn_ | cat1: ok I'll use ML now on :) |
| 16:42.27 | cat1 | techn_: thanks! |
| 16:44.30 | mnemoc | cat1: it's complicated consider all old lines don't honor the code style |
| 16:44.37 | mnemoc | considering* |
| 16:44.39 | cat1 | thinks that we are not yet in the stage to give proper review, but at least it would serve a good stimulus to have one in the future. |
| 16:44.55 | cat1 | mnemoc: yeah, but for simple patches it might help |
| 16:45.01 | cat1 | s/simple/small |
| 16:47.30 | cat1 | ..or at least it will give submitter the idea on how much work is ahead ;) |
| 16:47.45 | mnemoc | :) |
| 17:11.20 | *** join/#arm-netbook eflatun (~eflatun@109.228.213.239) |
| 17:12.00 | cat1 | mnemoc: do you happen to know what is soc inside e.g. this http://www.lava-tech.com/qpad_c0700111.html |
| 17:18.35 | *** join/#arm-netbook eflatun (~eflatun@46.1.121.157) |
| 17:27.06 | *** join/#arm-netbook eflatun (~eflatun@46.1.136.165) |
| 17:27.09 | mnemoc | cat1: how could I? :) |
| 17:27.27 | cat1 | mnemoc: dunno, just by chance? ;) |
| 17:28.24 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:29.10 | RaYmAn | cat1: contact them and ask for kernel source .P |
| 17:32.12 | cat1 | RaYmAn: actually it is not for me, one guy on #mer was asking if mali400 support is available for his laptop. I wanted to help, but failed :( |
| 17:32.27 | cat1 | s/laptop/tablet |
| 17:33.05 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 17:38.03 | cat1 | uh-oh, do not get it how connman works.. i cannot make wifi working with upstream rtl driver. it keeps whining about rfkill.. |
| 17:40.14 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
| 17:45.14 | cat1 | wow, magick happens, it is up now! :)) |
| 17:47.43 | mnemoc | kudos :) |
| 17:52.29 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.103) |
| 17:53.51 | cat1 | mnemoc: but does not take ip addr from dhcp for some reason.. i am not familiar with connmand yet. |
| 18:01.19 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 18:05.54 | *** join/#arm-netbook ceo16 (~asus@host50-182-dynamic.56-82-r.retail.telecomitalia.it) |
| 18:13.49 | *** join/#arm-netbook RITRedbeard_ (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 18:24.49 | NAiL | Can't the mele be flashed like "all" the other A10 devices, via USB? |
| 18:24.54 | NAiL | hr |
| 18:24.58 | NAiL | nm |
| 18:25.26 | mnemoc | NAiL: usb OTG port, which is in a header inside the case |
| 18:25.55 | NAiL | so the mele is also "unbrickable"? |
| 18:26.23 | mnemoc | right |
| 18:26.49 | hno | NAiL, all A10 is "unbrickable" by using SD or USB to recover. |
| 18:27.01 | hno | The normal method on mele is to boot from sd. |
| 18:27.28 | traeak | maybe nvidia opening up will make arm open up the mali (hehe, i think i'm just trolling!) |
| 18:27.54 | hno | nvidia is not opening up their 3d. Only the 2d part. |
| 18:28.09 | traeak | yup |
| 18:28.10 | RaYmAn | and primarily for tegra2. |
| 18:28.13 | traeak | mostly irrelevant |
| 18:28.39 | hno | we don't have detailed specifications for the 2d part, but at least have 100% GPL source code for it. |
| 18:29.35 | hno | Would be great if someone with a little X11 experience would take advantage of it. |
| 18:29.41 | mnemoc | obfuscated behind vmware_ named functions :p |
| 18:29.46 | traeak | lovely |
| 18:29.57 | traeak | tegra2 is abandoned mostly though |
| 18:30.00 | traeak | and ther's no neon part |
| 18:30.02 | traeak | so that's fun as well |
| 18:30.24 | mnemoc | f* nvidia |
| 18:30.33 | mnemoc | they should open source the stuff they deprecate |
| 18:30.36 | *** join/#arm-netbook eflatun (~eflatun@95.173.231.71) |
| 18:30.52 | RaYmAn | tbh, tegra3 is so close to tegra2 that the 2d code will probably be fairly universal |
| 18:32.31 | hno | Even on the 3D side many things should be similar. |
| 18:32.40 | RaYmAn | yeah |
| 18:33.32 | hno | mnemoc, whats obfuscated behind vmware_ named functions? |
| 18:39.13 | mnemoc | hno: directfb code |
| 18:39.57 | mnemoc | hno: they hacked in on top of vmware's driver, and honored the old naming scheme |
| 18:40.05 | *** join/#arm-netbook eflatun (~eflatun@46.1.28.101) |
| 18:40.09 | hno | do we have that in our tree? |
| 18:41.41 | mnemoc | https://github.com/allwinner-ics/lichee_buildroot/blob/master/package/directfb/directfb-1.4.11-vmware.patch |
| 18:42.02 | mnemoc | it comes from the A10 SDK |
| 18:42.12 | mnemoc | in buildroot |
| 18:43.09 | mnemoc | but it's pretty clean |
| 18:43.19 | techn_ | .. latest directfb supports gles2 rendering directly |
| 18:45.09 | *** join/#arm-netbook eflatun_ (~eflatun@95.173.232.168) |
| 18:47.12 | hno | mnemoc, that's all userspace, right? |
| 18:47.21 | mnemoc | hno: yes |
| 18:47.33 | mnemoc | hno: using the char device |
| 18:47.44 | hno | so someone needs to do the same for X11 EXA. |
| 18:48.09 | mnemoc | techn wanted to turn g2d into v4l2 |
| 18:49.27 | mnemoc | libv teased with getting someone from his company to do it in a couple of days |
| 18:49.41 | mnemoc | the exa driver I mean |
| 18:49.56 | hno | should be pretty straight forward. |
| 18:50.34 | hno | and also XVideo support should be easy. |
| 18:51.14 | hno | and hardware mouse pointer. |
| 18:52.31 | hno | hardware mouse pointer is done by disp however, not g2d. |
| 18:52.45 | *** join/#arm-netbook eflatun__ (~eflatun@46.1.27.4) |
| 18:55.41 | hno | XVideo is also disp, but can also be done by g2d. A bit of overlap there in the silicon. |
| 18:56.33 | mnemoc | I supose the disp driver should use the g2d driver |
| 18:57.00 | techn_ | yep.. it could be done |
| 18:58.20 | techn_ | during probe, check if g2d module available.. if it is use own blit, etc.. if not use kernels |
| 18:59.03 | techn_ | and own is just wrapper for g2d implementation |
| 18:59.17 | *** join/#arm-netbook zewelor (~x@89-78-93-36.dynamic.chello.pl) |
| 18:59.58 | techn_ | but then again.. how memory is mapped? |
| 19:02.53 | mnemoc | it's reserved in core.c |
| 19:03.12 | *** join/#arm-netbook eflatun__ (~eflatun@46.1.116.238) |
| 19:03.14 | mnemoc | before the MMU gets initialized |
| 19:03.54 | mnemoc | hates those reserves |
| 19:05.19 | RaYmAn | reserve only prevents linux from using it, nothing more (afaik) |
| 19:05.35 | RaYmAn | "using" - rather, allocating it for stuff |
| 19:06.00 | RaYmAn | what's wrong with the reserves though? |
| 19:06.09 | RaYmAn | It's a good thing to reserve stuff :P |
| 19:08.31 | mnemoc | happens before I change check if the stuff is enabled in script.bin :< |
| 19:08.45 | RaYmAn | ah, right |
| 19:08.53 | mnemoc | also before we can check the cpu-id |
| 19:09.23 | mnemoc | the ugliest reserving is for mali, which happens at fixup time. taking the chunk out of meminfo |
| 19:10.28 | *** join/#arm-netbook zewelor (~x@89-78-93-36.dynamic.chello.pl) |
| 19:18.40 | *** join/#arm-netbook eflatun__ (~eflatun@95.173.234.240) |
| 19:24.07 | hno | yes the mali reservation is ugly as hell. If MALI driver need to continue hiding it's memory like this then support needs to be added to u-boot. |
| 19:27.19 | cat1 | hno: DT? |
| 19:28.34 | mnemoc | *cough* |
| 19:29.04 | cat1 | hides away |
| 19:29.29 | mnemoc | cat1: beside the greediness in suggesting DT as a fix at this point, mali currently needs the 64M between 448 and 512 to be totally unknown to the kernel |
| 19:29.46 | mnemoc | reserving it doesn't work |
| 19:30.24 | cat1 | holly crap. |
| 19:30.27 | *** join/#arm-netbook eflatun__ (~eflatun@46.1.26.61) |
| 19:31.11 | hno | would love DT support. |
| 19:32.13 | hno | fact: it's not the kernels job to hide memory from the kernel. |
| 19:32.28 | mnemoc | +1 |
| 19:33.37 | mnemoc | BUT, how do we do to not-hide it when mail is not enabled? |
| 19:34.18 | mnemoc | it's not nice to cut 64M out for headless A10s |
| 19:34.28 | mnemoc | f* mali :< |
| 19:34.53 | *** join/#arm-netbook eflatun__ (~eflatun@109.228.222.14) |
| 19:35.07 | cat1 | i think is should be configurable |
| 19:36.11 | mnemoc | cat1: got homework for the weekend :) |
| 19:36.50 | cat1 | mnemoc: list of homeworks is growing exp..ly |
| 19:36.54 | cat1 | ;) |
| 19:36.58 | mnemoc | :) |
| 19:38.44 | cat1 | btw, does SPARSE memory option have anything to do with mem reservation? remember playing with that on octeon boards some years ago.. |
| 19:39.02 | hno | mnemoc, any idea how the memory reservation is handled on other mali implementatios? |
| 19:41.35 | hno | cat1, not really, unless the sparse memory I know if is something else than you think of. |
| 19:42.06 | mnemoc | hno: in drivers/gpu/mali/mali/arch/config.h they use OS_MEMORY instead of MEMORY |
| 19:42.24 | *** join/#arm-netbook eflatun__ (~eflatun@95.173.232.200) |
| 19:42.32 | hno | mnemoc, they are? |
| 19:42.48 | mnemoc | hno: but in our case the libs don't work with that :< |
| 19:44.08 | hno | reserved memory is more reliable when it comes to blob allocations. There is no guarantee you can allocate a contigous blob after the kernel have been running for a while. |
| 19:44.39 | hno | and 3D is a lot of blob allocations. |
| 19:45.23 | hno | OS memory ie easier to conifgue however. |
| 19:46.07 | techn_ | hmm.. could kernel even put mali's memory to swap? (dummy question?) |
| 19:46.50 | techn_ | or is it reserved directly from physical memory? |
| 19:47.48 | *** join/#arm-netbook eflatun__ (~eflatun@109.228.222.215) |
| 19:48.14 | techn_ | i suppose so.. so why there is possibility to get non linear allocation from physical memory? |
| 19:48.15 | hno | techn_, no. |
| 19:48.44 | *** join/#arm-netbook gimli_ (~gimli@xbmc/staff/gimli) |
| 19:48.45 | hno | it's a physical memory reservation. |
| 19:49.37 | hno | and MALI wan's blobs for to be allocated linearly. |
| 19:50.03 | mnemoc | a normal reserve should do the job |
| 19:50.17 | mnemoc | but when doing that the kernel driver fails to allocate it (obviusly) |
| 19:50.29 | mnemoc | couldn't find how to tell mali it was already reserved |
| 19:50.41 | techn_ | could it be done so that if mali is reserving memory.. kernel reduces/reorders it's own phy memory and gives mali memory it wants |
| 19:52.38 | techn_ | ah.. so mali reservers memory before kernel get's a change to reserve it's own |
| 19:53.24 | hno | techn_, kernel can not arbitrarily move it's memory around. The virtual<->physical mapping is linear for the kernel. |
| 19:53.57 | hno | not like processes where the address space is purely virtual with no relation to physical memory. |
| 19:54.26 | hno | and yes, mali memory reservation is even before the kernel actually starts for real. |
| 19:55.18 | hno | done in the early platform fixup code which prepares the system environment for running the kernel. |
| 19:55.34 | hno | early startup code in kernel image. |
| 19:57.42 | mnemoc | i think we "only" need to find how to tell drivers/gpu/mali/mali/arch/config.h the memory is already reserved |
| 19:58.08 | mnemoc | and reserve it in the same way we do for fb/ve/g2d |
| 20:00.19 | mnemoc | I suppose people from that arm forum can give us a hand on that |
| 20:00.31 | techn_ | http://www.mjmwired.net/kernel/Documentation/memory-hotplug.txt |
| 20:01.56 | mnemoc | iirc there others we use "resources" for that |
| 20:04.59 | cat1 | mnemoc: what do you how to tell the memory is reserved? would some exported function from some mali driver, something like mali_reserve_memory() do the magick? |
| 20:05.15 | cat1 | s/what do you/what do you mean |
| 20:05.37 | mnemoc | cat1: look at drivers/gpu/mali/mali/arch/config.h |
| 20:06.08 | mnemoc | cat1: the driver uses that to decide how to get the memory and how to use it |
| 20:06.09 | cat1 | mnemoc: i see some static declarations htere |
| 20:06.24 | mnemoc | that is what I mean by "tell" |
| 20:06.54 | cat1 | so it simply needs to pick up proper config, right? |
| 20:06.58 | mnemoc | what to write the so the mali driver uses a pre-reserved chunk without failing to try to allocate it |
| 20:07.07 | mnemoc | cat1: yes, that simple |
| 20:07.18 | *** join/#arm-netbook eflatun (~eflatun@95.173.232.86) |
| 20:07.31 | mnemoc | but "proper" implies the need of understanding how the driver works |
| 20:08.16 | mnemoc | neat. the arm-soc base for 3.7 is ready |
| 20:10.20 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 20:11.51 | cat1 | mnemoc: i know this is totally stupid to ask, but what is the current problem with mali we are trying to resolve? |
| 20:14.44 | mnemoc | cat1: the current discussion. to make it work reserving it's 64MB in a civilized way |
| 20:16.22 | cat1 | mnemoc: i mean, i haven't seen mali in action myself at all, so for me it all is still hypothetical :) |
| 20:16.45 | mnemoc | the other big issue with mali is proper drm/ump integration so mali/x11 actually gets hw acceleration |
| 20:17.14 | mnemoc | cat1: those are two completely separated problems |
| 20:17.26 | cat1 | mnemoc: and mali_drm is somewhat fully implemented? |
| 20:17.31 | mnemoc | no |
| 20:18.05 | mnemoc | that works in the the next_mali branch, still incomplete. x11/mali runs... but no acceleration |
| 20:18.54 | mnemoc | s/in the/is in/ |
| 20:19.45 | *** join/#arm-netbook eflatun (~eflatun@95.173.235.101) |
| 20:20.59 | cat1 | dammit, i am not yet that far with mer adaptation. need to speed it up a little bit :) |
| 20:22.06 | mnemoc | meh. I thought you wanted to help fixing the mali kernel driver :< |
| 20:25.47 | cat1 | mnemoc: i want and will do what i can, no worries. |
| 20:26.04 | mnemoc | :) |
| 20:26.08 | cat1 | hates to make promises though ;) |
| 20:32.35 | mnemoc | ^^ |
| 20:33.49 | ManoftheSea | mer? |
| 20:33.53 | ManoftheSea | On the Mali? |
| 20:34.07 | ManoftheSea | Cool. I don't even have mer on my n900 |
| 20:37.12 | *** join/#arm-netbook eflatun (~eflatun@46.1.159.236) |
| 20:37.18 | cat1 | ManoftheSea: actually up to console it works out of the box, the only problem was/is graphics.. err.. and connman ;) |
| 20:37.59 | cat1 | well, maybe usb and other things too, but i haven't even looked at this yet. |
| 20:43.19 | techn_ | cat1: what rendering engine it uses? |
| 20:43.39 | cat1 | xorg |
| 20:43.47 | techn_ | ah |
| 20:44.03 | cat1 | wayland in theory |
| 20:44.21 | cat1 | the work is going on wayland atm. |
| 20:44.24 | techn_ | wayland, directfb should work if gles2 is used directly |
| 20:44.57 | techn_ | or without gles2 ofcourse |
| 20:45.51 | cat1 | techn_: actually i saw xorg started and cursor was on display but that was it, no funcy stuff at all. |
| 20:47.46 | mnemoc | you usually need to start some apps (at least a wm) after running X :p |
| 20:47.51 | cat1 | pushed into Linus's tree by mistake, luckily got err 22 |
| 20:48.01 | cat1 | mnemoc: :)) |
| 20:48.36 | cat1 | mnemoc: it supposed to be done automgically! |
| 20:50.22 | cat1 | mnemoc: besides there is no wm in there, some composite-manager. |
| 21:11.57 | techn_ | hmm.. So I can read edid and pass it to kernel (a bit hackish).. but applying wanted timings is really painfull :( |
| 21:13.14 | RaYmAn | at least that proves it works in theory :) |
| 21:13.23 | mnemoc | :D |
| 21:15.44 | *** join/#arm-netbook eflatun (~eflatun@46.1.138.89) |
| 21:16.23 | techn_ | current resolution change sequence is that msg comes to disp-disp, which passes enum to de_bsp, which passes another enum to disp-hdmi, which reads timings from hardcoded table and passes to controller |
| 21:17.24 | mnemoc | i told you to try to flatten the driver before trying to add new features :p |
| 21:17.32 | rz2k | we_need_to_go_deeper.jpg |
| 21:18.37 | techn_ | mnemoc: that's a bit brave if allwinner gives us newer codes :/ |
| 21:18.44 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 21:19.33 | mnemoc | techn_: very true |
| 21:19.46 | mnemoc | but somehow i lost my hope on that |
| 21:20.13 | techn_ | but true.. best solution before new feature(our own feature) would be full refactoring |
| 21:20.50 | techn_ | but should we still merge wip/disp branch before that.. :/ |
| 21:21.12 | *** join/#arm-netbook eflatun (~eflatun@46.1.138.39) |
| 21:21.31 | techn_ | even if there is only features that we don't even need |
| 21:22.12 | mnemoc | +1 |
| 21:22.14 | mnemoc | +1 |
| 21:24.18 | mnemoc | maybe an soft refactoring first to be able to unift sun3i too? |
| 21:24.22 | mnemoc | unify* |
| 21:24.42 | mnemoc | damn... coffee or nap? that is the question |
| 21:25.07 | cat1 | nap is healthier.. |
| 21:25.27 | mnemoc | indeed |
| 21:26.17 | cat1 | techn_: will you start from scripts/Lindent ? ;) |
| 21:26.20 | ZaEarl | coffee then nap |
| 21:26.33 | cat1 | might not be compatible.. |
| 21:26.39 | mnemoc | cat1: that ruins history :< |
| 21:26.56 | *** join/#arm-netbook zowtar (zowtar@unaffiliated/zowtar) |
| 21:26.57 | ZaEarl | in the 15 min it takes the caffeine to hit your brain, you get a nice nap, and then pop up awake |
| 21:27.08 | mnemoc | style fixes need to be done only where there is code changes |
| 21:27.21 | ZaEarl | http://lifehacker.com/306029/reboot-your-brain-with-a-caffeine-nap |
| 21:27.25 | cat1 | mnemoc: partially agree |
| 21:27.37 | *** join/#arm-netbook eflatun (~eflatun@46.1.138.189) |
| 21:28.16 | mnemoc | ZaEarl: uh |
| 21:28.54 | cat1 | ZaEarl: scientists, scientists -- they will change mind next time ;) |
| 21:31.17 | techn_ | sun3i merge is also pretty hard with current design.. also without device with test cant do large refactorings, i'm only human :( |
| 21:32.06 | cat1 | techn_: but only the code you touch |
| 21:32.51 | rz2k | who needs sun3i now, really.. |
| 21:32.55 | techn_ | cat1: yeah.. but it isn't good to add every second line ifdef |
| 21:33.11 | cat1 | techn_: fully agree |
| 21:34.07 | techn_ | rz2k: i'm wondering same :) |
| 21:34.50 | techn_ | has anyone even tested that current codes work with that device? :p |
| 21:34.51 | cat1 | some philanthropists. |
| 21:42.01 | *** join/#arm-netbook eflatun (~eflatun@95.173.231.213) |
| 21:43.36 | techn_ | hmm.. propably best would be flatten disp/lcd/hdmi more.. leave de_bsp as is since there is all the stuff what can't be understood without datasheet + most of the allwinner patches will be there |
| 21:45.40 | techn_ | so should we combine those 3 binaries as one, or even combine modules |
| 21:46.58 | techn_ | and how should be dependecies go.. disp depends on lcd/hdmi(fb).. or lcd/hdmi depends disp(fb) |
| 21:47.39 | techn_ | äh.. disp(fb) |
| 21:48.21 | mnemoc | hdmi -> lcd -> disp |
| 21:49.00 | mnemoc | i wouldn't combine them yet |
| 21:49.15 | mnemoc | we probably need to turn them into drm drivers anyway |
| 21:50.44 | techn_ | ok.. so should we then just jump to drm? could you give me a link of drm fb? or was it that kms link? |
| 21:51.20 | mnemoc | techn_: do you feel you know enough about the drm to make that jump directly? |
| 21:51.31 | mnemoc | s/drm/disp/ |
| 21:51.45 | *** join/#arm-netbook tuliom (~tuliom@177.133.170.196) |
| 21:52.41 | *** join/#arm-netbook eflatun (~eflatun@46.1.158.158) |
| 21:55.44 | techn_ | mnemoc: implementing new features with current design is seems to be waste of time |
| 21:56.35 | techn_ | but not sure if I have time to get things running with drm.. (dunno yet what it needs) |
| 21:56.42 | mnemoc | techn_: well... i wouldn't call it a waste of time. but it's probably MUCH harder than it might be after cleaning the driver |
| 21:57.17 | mnemoc | first flatten/refactor what you can in the fbdev based driver |
| 21:57.27 | mnemoc | (baby steps) |
| 21:57.59 | mnemoc | deeper the changes, harder to find what broke :< |
| 21:59.13 | *** join/#arm-netbook eflatun (~eflatun@46.1.136.42) |
| 22:06.12 | techn_ | mnemoc: that's true.. maybe it's good to start by making module dependecies clean.. |
| 22:07.04 | mnemoc | yes, that too |
| 22:07.26 | techn_ | but I'm not sure about hdmi -> lcd -> disp dependecy |
| 22:07.36 | mnemoc | that dep already exists |
| 22:07.55 | mnemoc | hdmi init needs lcd to have init'ed first |
| 22:08.02 | mnemoc | or it dies painfully |
| 22:08.43 | mnemoc | {hdmi,lcd} -> disp will require heavy refactoring |
| 22:09.11 | techn_ | yep that kind dependency needs to removed.. I was thinkin that disp -> {hdmi,lcd} could be better |
| 22:09.48 | mnemoc | baby steps :) |
| 22:09.56 | techn_ | since atleast fex config allows to wrap output modes under one framebuffer |
| 22:10.06 | mnemoc | once you understand the interactions better, sure, turn it upside down |
| 22:10.44 | *** join/#arm-netbook L84Supper (~ly@unaffiliated/l84supper) |
| 22:11.02 | techn_ | so basicly framebuffer is dependand of outputs.. not otherway around |
| 22:11.31 | mnemoc | they didn't really care about the real driver is de_bsp anyway |
| 22:12.04 | mnemoc | s/the /that as / |
| 22:12.30 | techn_ | i think thas good.. since there is a lot of usefull stuff under enum ( we don't need to understand registers) |
| 22:12.37 | *** join/#arm-netbook eflatun (~eflatun@46.1.137.116) |
| 22:13.57 | techn_ | but still.. every wrapper layer causes bugs |
| 22:16.00 | mnemoc | techn_: fyi #ifdef CONFIG_ARCH_SUN?I became illegal now. machs now (since 3.7) shall be bool instead of choice, so code needs to use if (machine_is_sun4i()) instead |
| 22:16.41 | mnemoc | but well... not a problem for 3.0 :) |
| 22:18.20 | techn_ | but that's good for getting same binary for both :) |
| 22:18.28 | mnemoc | yup |
| 22:19.30 | techn_ | btw. I was wondering was that PPL fix good.. should DT or fex give correct clocks? |
| 22:19.32 | bsdfox | anyone got hints on booting mele a2000 from sata? |
| 22:20.12 | techn_ | sata PLL.. |
| 22:20.51 | bsdfox | phase lock loop? |
| 22:21.55 | mnemoc | techn_: there is a new common clock framework too, so I guess they can be configures using DT |
| 22:22.38 | mnemoc | bsdfox: boot a linux/kexec from nand/mmc and then jump to sata |
| 22:23.21 | hno | bsdfox, the boot rom do not know SATA. You need to boot something from nand/sd which then boots from sata. |
| 22:23.35 | hno | and he only something we have who knows he sata controller is Linux. |
| 22:27.20 | bsdfox | hmm looking at my sd build /etc/fstab has nothing and /boot is empty.. any advice? |
| 22:28.42 | bsdfox | I guess it might be booting something from the fat32 partition on the sd? |
| 22:43.52 | mnemoc | you can add the first partition of your sd card as /boot in your fstab |
| 22:43.58 | mnemoc | but it's not required |
| 22:45.58 | mnemoc | good night |
| 22:49.17 | bsdfox | thanks |
| 22:49.57 | bsdfox | if I want to backup all my nand would you guys do dd if=/dev/nand of=nand.img or would you do it per partition ie if=/dev/nanda of=nanda.img etc? |
| 23:10.23 | *** join/#arm-netbook akaizen (43b4563d@gateway/web/freenode/ip.67.180.86.61) |
| 23:11.37 | akaizen | So whats the current state of A10 / MALI400 ? Where is help needed the most? |
| 23:12.28 | akaizen | Looks like empat_zero did some nice work on the A10 VPU. |
| 23:44.40 | *** join/#arm-netbook DEAT_ (~heh@14-201-99-152.tpgi.com.au) |
| 23:47.03 | *** join/#arm-netbook msb_ (~msb@c-98-248-33-213.hsd1.ca.comcast.net) |
| 23:48.37 | *** part/#arm-netbook zowtar (zowtar@unaffiliated/zowtar) |
| 23:55.47 | *** join/#arm-netbook zowtar (zowtar@unaffiliated/zowtar) |