2014-09-07 00:33 awesome (about systemd) http://ewontfix.com/15/ 2014-09-07 03:55 xiangfu has joined #qi-hardware 2014-09-07 05:44 arhuaco has joined #qi-hardware 2014-09-07 06:02 xiangfu has quit [Remote host closed the connection] 2014-09-07 07:28 wej_ has joined #qi-hardware 2014-09-07 07:29 wej has quit [Ping timeout: 250 seconds] 2014-09-07 08:48 jivs has joined #qi-hardware 2014-09-07 08:50 jivs has left #qi-hardware [#qi-hardware] 2014-09-07 10:09 wej_ has quit [Ping timeout: 250 seconds] 2014-09-07 10:12 arhuaco has quit [Read error: Connection reset by peer] 2014-09-07 10:14 wej has joined #qi-hardware 2014-09-07 10:25 arhuaco has joined #qi-hardware 2014-09-07 10:37 arhuaco has quit [Ping timeout: 246 seconds] 2014-09-07 11:11 oh good, udev was forked 2014-09-07 11:11 https://wiki.archlinux.org/index.php/Eudev 2014-09-07 11:12 glibc also 2014-09-07 11:12 http://www.eglibc.org/home 2014-09-07 11:16 huh? eglibc was merged ages ago 2014-09-07 11:16 eudev is udev without systemd 2014-09-07 11:17 ah, okay :-) 2014-09-07 11:17 I thought eglibc is used by debian 2014-09-07 11:17 but when it's merged now 2014-09-07 11:18 why they did the fork 2014-09-07 11:25 glibc was mismanaged 2014-09-07 11:25 no more drepper, no more need to fork ;) 2014-09-07 11:27 larsc: there's an issue with mmc regulator on jz-3.16 2014-09-07 11:27 http://paste.debian.net/119693/ 2014-09-07 11:28 line 108: platform jz4740-mmc.0: Driver jz4740-mmc requests probe deferral 2014-09-07 11:28 line 118: MMC power: incomplete constraints, leaving on 2014-09-07 11:28 is CONFIG_REGULATOR enabled? 2014-09-07 11:29 yes 2014-09-07 11:30 got read of the former log message with this: http://paste.debian.net/119694/ 2014-09-07 11:30 but I can't figure out why the mmc driver is requesting probe deferral 2014-09-07 11:31 because it can't find one off its resources 2014-09-07 11:31 of 2014-09-07 11:33 try to figure out where exactly the probe function returns 2014-09-07 11:33 both CONFIG_REGULATOR and CONFIG_REGULATOR_FIXED_VOLTAGE are defined though 2014-09-07 11:33 larsc: okay, will try that 2014-09-07 11:42 hm, mayvb 2014-09-07 11:43 hm, maybe it's the vqmmc regulator 2014-09-07 11:54 apelete: we should call regulator_has_full_constraints() from the qi_lb60 board file 2014-09-07 11:54 I think that will fix it 2014-09-07 12:19 larsc fixed indeed, driver was failing to get vmmc and vqmmc resources -> http://paste.debian.net/119698/ (line 172 & 175) 2014-09-07 12:19 it should get vmmc, but not vqmmc 2014-09-07 12:19 which is not an error 2014-09-07 12:20 but is treated as an error if we do not call regulator_has_full_constraints 2014-09-07 12:20 larsc: hare's the fix -> http://paste.debian.net/119700/ 2014-09-07 12:20 looks good to you ? 2014-09-07 12:20 yea, just merge it into the mmc regulator patch 2014-09-07 12:20 okay 2014-09-07 13:04 larsc: pushed out jz-3.16 on the the server 2014-09-07 13:05 larsc: I was wondering, is there anything preventing us from sending the remaining patches for ben nanonote upstream ? 2014-09-07 13:09 we only have ~30 patches left out of tree, shouldn't be too hard to get them upstream and have full upstream support for nanonote 2014-09-07 13:10 and now may be a good time, with imgtec preparing to send patches for ci20 support too 2014-09-07 13:10 larsc: what do you thnk about it ? 2014-09-07 13:27 most patches are mth's patches I think 2014-09-07 13:27 thanks for preparing jz-3.16 2014-09-07 13:33 np for jz-3.16 2014-09-07 13:34 I'm going to check with mth and pcercuei too for the remaining patches 2014-09-07 13:37 if everyone is ok I'm willing to clean them up (if needed) and send them on behalf of the authors 2014-09-07 13:37 would be great to reach "0 patch out of tree" status :) 2014-09-07 13:38 yes 2014-09-07 15:02 xiangfu has joined #qi-hardware 2014-09-07 15:17 FrankBlues has joined #qi-hardware 2014-09-07 15:18 13:11 < whitequark> oh good, udev was forked < yes, it has been done in late 2012 approx 2014-09-07 15:19 it's a work started by gentoo guys 2014-09-07 15:19 then archlinux guys seem to use it as well 2014-09-07 15:30 that's strange to see it in arch linux, because the only supported init system in arch is systemd 2014-09-07 15:30 perhaps eudev support in arch linux is broken or outdated 2014-09-07 15:40 xiangfu has quit [Remote host closed the connection] 2014-09-07 15:52 it seems you can at least use archlinux with OpenRC instead of systemd 2014-09-07 15:52 https://wiki.archlinux.org/index.php/OpenRC 2014-09-07 16:03 ysionneau: well, that's good, but it's in AUR, so not really supported. You will have to worry about creating rc-files (or whatever is used in OpenRC) by yourself 2014-09-07 16:07 being the arch linux user for several years now i'm convinced that i want to stay as close to arch upstream as possible 2014-09-07 16:07 otherwise strange things can happen :) 2014-09-07 16:11 sure it seems you are right: the officially supported stuff is systemd 2014-09-07 17:12 FrankBlues has quit [Remote host closed the connection] 2014-09-07 17:20 apelete: I'm not sure 0 patches is achievable, but we should certainly try to get it as low as possible 2014-09-07 17:21 larsc: something we'd need to get 4740 and 4770 closer is pinctrl for 4740 2014-09-07 17:21 yes 2014-09-07 17:21 to merge with 4780, devicetree support would be required 2014-09-07 17:21 wej has quit [Ping timeout: 250 seconds] 2014-09-07 17:21 I did add devicetree support to most drivers a while ago, never pushed it though 2014-09-07 17:22 we have a pinctrl driver for 4770; I'm not sure it's entirely as it should be as I'm having trouble understanding part of the pinctrl design 2014-09-07 17:22 but it is working at least, so it could be used as a starting point perhaps 2014-09-07 17:23 I think the driver will probably be the same for most jz47xx chips 2014-09-07 17:23 just the pinctrl tables will be different 2014-09-07 17:23 should those tables be in the driver, in the platform code or in devicetree? 2014-09-07 17:24 ImgTec put them in devicetree, but me and pcercuei were wondering if that is the right place 2014-09-07 17:24 since it's SoC specific, not board specific 2014-09-07 17:25 on the other hand, it might save memory if only the dt tables for the active SoC has to be loaded 2014-09-07 17:25 its ok to have SoC specific stuff in the dt 2014-09-07 17:29 mth: great, let's talk with pcercuei tomorrow to see how he feels about it 2014-09-07 17:29 if everyone is ok we'll choose which patches to start with 2014-09-07 17:30 one thing I recently changed is that for PWM pins, we used to bind them to the PWM driver, but when binding them to the PWM-using driver (pwm-backlight, pwm-haptic) the power management came for free 2014-09-07 17:30 but I wouldn't know whether that is the right way to do it 2014-09-07 17:32 and what surprised me is that a pin can have a gpio owner separate from a mux owner 2014-09-07 17:33 while that works fine for reading, it would cause problems if you'd change direction to output 2014-09-07 17:40 I never really understood pinctrl either 2014-09-07 17:51 wej has joined #qi-hardware 2014-09-07 17:56 jivs has joined #qi-hardware 2014-09-07 19:05 I never understood DT concept. It's kinda flawed. In my book a hw design is simply too complex and individual to get formally described in anything less bloated than the drivers code itself. Even the drivers only describe how to handle certain aspects of it 2014-09-07 19:06 I suppose the idea is to pick low-hanging fruit. 80% of easily configurable stuff 2014-09-07 19:06 DT would only work when it was the parameter set of a complete physical emulation of the hardware 2014-09-07 19:06 and handle the rest with hardcoded quirks and such 2014-09-07 19:06 possibly 2014-09-07 19:07 there's some merit to that idea imo. 2014-09-07 19:09 porchao has joined #qi-hardware 2014-09-07 19:10 porchaso0 has quit [Ping timeout: 268 seconds] 2014-09-07 19:14 sure 2014-09-07 19:15 intention is good, I however doubt it ever will rach a convenient "maturity" 2014-09-07 19:15 reach* 2014-09-07 19:16 and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one 2014-09-07 19:16 one* 2014-09-07 19:16 DT solves the need of running the same kernel on differing hw 2014-09-07 19:17 which is even more relevant with ARM laptops and similar hardware 2014-09-07 19:17 err, is DT a build-time thing or a run time thing? 2014-09-07 19:17 as I understand you can select different trees based on board ID 2014-09-07 19:18 so you only need one kernel per microarch, rather than one kernel per board 2014-09-07 19:18 exactly 2014-09-07 19:18 drivers adapt during boot time, according to DT 2014-09-07 19:18 aiui 2014-09-07 19:18 it would suck to ship debian with eight thousand different kernels for every ARM laptop out there :p 2014-09-07 19:18 yes 2014-09-07 19:19 DT doesn't solve some abstract goal of removing the need to write C or something, it's mainly this 2014-09-07 19:19 >>and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one<< 2014-09-07 19:19 well, see above. 2014-09-07 19:19 it doesn't scale 2014-09-07 19:20 it does, when you build a OS / distro for your hw 2014-09-07 19:20 DT gets rid of boilerplate code, that's all it does... 2014-09-07 19:21 previoulsy you'd have one C file which has doeszen of lines of device_register(...) 2014-09-07 19:21 this is now in the DT 2014-09-07 19:22 DT might work for laptops and desktop PCs and servers, all based on 8086 ISA, with a peretty limited number of peripherals that all are connected via well defined busses like PCI etc 2014-09-07 19:22 on x86 you don't need DT at all 2014-09-07 19:22 since it's by and large plug and play 2014-09-07 19:24 my take on all that is that you need drivers tailored to fit your particular hardware platform, not a single chip in that platform. But then that's just my take on it 2014-09-07 19:24 nobody wants to write the same driver 10 times 2014-09-07 19:25 yes, I know 2014-09-07 19:25 nobody wants to create a new hw platform 10 times either 2014-09-07 19:26 but in the end that's exactly what EE does 2014-09-07 19:26 a hw platform is released once however source has to be maintained essentially forever 2014-09-07 19:26 so you need a different approach to manage complexity here 2014-09-07 19:26 yes, I know 2014-09-07 19:27 and there's hardly a universal approach 2014-09-07 19:29 it's not exactly like if a new embedded device was identical to the last one, just with 5 instead of 4 PCI slots and a quadcore instead of a dualcore 2014-09-07 19:29 you mean they don't do this with 3/4 of android phones? :] 2014-09-07 19:30 or maybe let's put it this way: the changes you face in new hw platforms are kinda 'analog', not a discrete number of alternative options 2014-09-07 19:31 no one says the changes should be *only* to DT. you modify drivers as well, but the combo allows you to keep modifications to the minimum 2014-09-07 19:31 so a) you need patches to the drivers anyway. And b) your drivers supporting other alternative hw platforms as well is mere cruft 2014-09-07 19:31 it's not a magic universal configuration interface, just a handy abstraction for common tasks 2014-09-07 19:33 exactly 2014-09-07 19:38 I simply don't see how you get handled by DT and universal drivers stuff like e.g. a mux in the camera interface that allows to connect 2 cam modules alternatively to the single SoC cam bus 2014-09-07 19:39 sure you could write a driver that allows stuff like a mux in cam bus, but do you want to upstream that? 2014-09-07 19:41 or take the fingerprint sensor that same time can act like a "trackball". Do you integrate fingerprint functions into all mouse drivers? 2014-09-07 19:42 or mouse function into the generic fingerprint reader driver? 2014-09-07 19:43 and how makes that sense on all other devices that don't offer using fingerprint reader as trackball/pointer 2014-09-07 19:45 the answer is "same as without DT", really 2014-09-07 19:46 I'm sure resp I even know there are solutions for the above two cases which do not automatically introduce layering conflicts and stuff. But maybe I made my point regarding universal drivers and highly proprietary resp unique embedded platforms 2014-09-07 20:03 jivs has quit [Ping timeout: 240 seconds] 2014-09-07 20:23 jivs has joined #qi-hardware 2014-09-07 20:36 jivs has quit [Quit: Leaving] 2014-09-07 21:18 woakas has quit [Ping timeout: 250 seconds] 2014-09-07 21:19 woakas has joined #qi-hardware 2014-09-07 21:37 kristianpaul has quit [Ping timeout: 240 seconds] 2014-09-07 21:39 kristianpaul has joined #qi-hardware 2014-09-07 21:39 kristianpaul has joined #qi-hardware 2014-09-07 21:44 arhuaco has joined #qi-hardware 2014-09-07 21:45 DocScrutinizer51 has quit [Ping timeout: 260 seconds] 2014-09-07 21:46 roh has quit [Ping timeout: 245 seconds] 2014-09-07 21:47 DocScrutinizer51 has joined #qi-hardware 2014-09-07 21:51 wej has quit [Ping timeout: 250 seconds] 2014-09-07 21:57 roh has joined #qi-hardware 2014-09-07 22:03 zear has quit [Ping timeout: 245 seconds] 2014-09-07 22:08 zear has joined #qi-hardware 2014-09-07 22:11 wej has joined #qi-hardware 2014-09-07 22:24 wej has quit [Ping timeout: 250 seconds] 2014-09-07 22:39 wej has joined #qi-hardware 2014-09-07 22:58 wej has quit [Ping timeout: 250 seconds] 2014-09-07 22:59 larsc has quit [Ping timeout: 250 seconds] 2014-09-07 23:15 wej has joined #qi-hardware 2014-09-07 23:48 hozer has quit [Quit: Leaving.] 2014-09-07 23:51 FDCX has quit [Ping timeout: 272 seconds]