#qi-hardware IRC log for Sunday, 2014-09-07

DocScrutinizer05awesome (about systemd) http://ewontfix.com/15/00:33
whitequarkoh good, udev was forked11:11
eintopfglibc also11:12
whitequarkhuh? eglibc was merged ages ago11:16
whitequarkeudev is udev without systemd11:16
eintopfah, okay :-)11:17
eintopfI thought eglibc is used by debian11:17
eintopfbut when it's merged now11:17
eintopfwhy they did the fork11:18
whitequarkglibc was mismanaged11:25
larscno more drepper, no more need to fork ;)11:25
apeletelarsc: there's an issue with mmc regulator on jz-3.1611:27
apeleteline 108: platform jz4740-mmc.0: Driver jz4740-mmc requests probe deferral11:28
apeleteline 118: MMC power: incomplete constraints, leaving on11:28
larscis CONFIG_REGULATOR enabled?11:28
apeletegot read of the former log message with this: http://paste.debian.net/119694/11:30
apeletebut I can't figure out why the mmc driver is requesting probe deferral11:30
larscbecause it can't find one off its resources11:31
larsctry to figure out where exactly the probe function returns11:33
apeleteboth CONFIG_REGULATOR and CONFIG_REGULATOR_FIXED_VOLTAGE are defined though11:33
apeletelarsc: okay, will try that11:33
larschm, mayvb11:42
larschm, maybe it's the vqmmc regulator11:43
larscapelete: we should call regulator_has_full_constraints() from the qi_lb60 board file11:54
larscI think that will fix it11:54
apeletelarsc fixed indeed, driver was failing to get vmmc and vqmmc resources -> http://paste.debian.net/119698/ (line 172 & 175)12:19
larscit should get vmmc, but not vqmmc12:19
larscwhich is not an error12:19
larscbut is treated as an error if we do not call regulator_has_full_constraints12:20
apeletelarsc: hare's the fix -> http://paste.debian.net/119700/12:20
apeletelooks good to you ?12:20
larscyea, just merge it into the mmc regulator patch12:20
apeletelarsc: pushed out jz-3.16 on the the server13:04
apeletelarsc: I was wondering, is there anything preventing us from sending the remaining patches for ben nanonote upstream ?13:05
apeletewe only have ~30 patches left out of tree, shouldn't be too hard to get them upstream and have full upstream support for nanonote13:09
apeleteand now may be a good time, with imgtec preparing to send patches for ci20 support too13:10
apeletelarsc: what do you thnk about it ?13:10
larscmost patches are mth's patches I think13:27
larscthanks for preparing jz-3.1613:27
apeletenp for jz-3.1613:33
apeleteI'm going to check with mth and pcercuei too for the remaining patches13:34
apeleteif everyone is ok I'm willing to clean them up (if needed) and send them on behalf of the authors13:37
apeletewould be great to reach "0 patch out of tree" status :)13:38
ysionneau13:11 < whitequark> oh good, udev was forked < yes, it has been done in late 2012 approx15:18
ysionneauit's a work started by gentoo guys15:19
ysionneauthen archlinux guys seem to use it as well15:19
kyakthat's strange to see it in arch linux, because the only supported init system in arch is systemd15:30
kyakperhaps eudev support in arch linux is broken or outdated15:30
ysionneauit seems you can at least use archlinux with OpenRC instead of systemd15:52
kyakysionneau: 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 yourself16:03
kyakbeing the arch linux user for several years now i'm convinced that i want to stay as close to arch upstream as possible16:07
kyakotherwise strange things can happen :)16:07
ysionneausure it seems you are right: the officially supported stuff is systemd16:11
mthapelete: I'm not sure 0 patches is achievable, but we should certainly try to get it as low as possible17:20
mthlarsc: something we'd need to get 4740 and 4770 closer is pinctrl for 474017:21
mthto merge with 4780, devicetree support would be required17:21
larscI did add devicetree support to most drivers a while ago, never pushed it though17:21
mthwe 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 design17:22
mthbut it is working at least, so it could be used as a starting point perhaps17:22
larscI think the driver will probably be the same for most jz47xx chips17:23
larscjust the pinctrl tables will be different17:23
mthshould those tables be in the driver, in the platform code or in devicetree?17:23
mthImgTec put them in devicetree, but me and pcercuei were wondering if that is the right place17:24
mthsince it's SoC specific, not board specific17:24
mthon the other hand, it might save memory if only the dt tables for the active SoC has to be loaded17:25
larscits ok to have SoC specific stuff in the dt17:25
apeletemth: great, let's talk with pcercuei tomorrow to see how he feels about it17:29
apeleteif everyone is ok we'll choose which patches to start with17:29
mthone 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 free17:30
mthbut I wouldn't know whether that is the right way to do it17:30
mthand what surprised me is that a pin can have a gpio owner separate from a mux owner17:32
mthwhile that works fine for reading, it would cause problems if you'd change direction to output17:33
larscI never really understood pinctrl either17:40
DocScrutinizer05I 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 it19:05
whitequarkI suppose the idea is to pick low-hanging fruit. 80% of easily configurable stuff19:06
DocScrutinizer05DT would only work when it was the parameter set of a complete physical emulation of the hardware19:06
whitequarkand handle the rest with hardcoded quirks and such19:06
whitequarkthere's some merit to that idea imo.19:07
DocScrutinizer05intention is good, I however doubt it ever will rach a convenient "maturity"19:15
DocScrutinizer05and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one19:16
whitequarkDT solves the need of running the same kernel on differing hw19:16
whitequarkwhich is even more relevant with ARM laptops and similar hardware19:17
DocScrutinizer05err, is DT a build-time thing or a run time thing?19:17
whitequarkas I understand you can select different trees based on board ID19:17
whitequarkso you only need one kernel per microarch, rather than one kernel per board19:18
DocScrutinizer05drivers adapt during boot  time, according to DT19:18
whitequarkit would suck to ship debian with eight thousand different kernels for every ARM laptop out there :p19:18
whitequarkDT doesn't solve some abstract goal of removing the need to write C or something, it's mainly this19:19
DocScrutinizer05>>and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one<<19:19
whitequarkwell, see above.19:19
whitequarkit doesn't scale19:19
DocScrutinizer05it does, when you build a OS / distro for your hw19:20
larscDT gets rid of boilerplate code, that's all it does...19:20
larscprevioulsy you'd have one C file which has doeszen of lines of device_register(...)19:21
larscthis is now in the DT19:21
DocScrutinizer05DT 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 etc19:22
whitequarkon x86 you don't need DT at all19:22
whitequarksince it's by and large plug and play19:22
DocScrutinizer05my 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 it19:24
larscnobody wants to write the same driver 10 times19:24
DocScrutinizer05yes, I know19:25
DocScrutinizer05nobody wants to create a new hw platform 10 times either19:25
DocScrutinizer05but in the end that's exactly what EE does19:26
whitequarka hw platform is released once however source has to be maintained essentially forever19:26
whitequarkso you need a different approach to manage complexity here19:26
DocScrutinizer05yes, I know19:26
DocScrutinizer05and there's hardly a universal approach19:27
DocScrutinizer05it'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 dualcore19:29
whitequarkyou mean they don't do this with 3/4 of android phones? :]19:29
DocScrutinizer05or maybe let's put it this way: the changes you face in new hw platforms are kinda 'analog', not a discrete number of alternative options19:30
whitequarkno one says the changes should be *only* to DT. you modify drivers as well, but the combo allows you to keep modifications to the minimum19:31
DocScrutinizer05so a) you need patches to the drivers anyway. And b) your drivers supporting other alternative hw platforms as well is mere cruft19:31
whitequarkit's not a magic universal configuration interface, just a handy abstraction for common tasks19:31
DocScrutinizer05I 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 bus19:38
DocScrutinizer05sure you could write a driver that allows stuff like a mux in cam bus, but do you want to upstream that?19:39
DocScrutinizer05or take the fingerprint sensor that same time can act like a "trackball". Do you integrate fingerprint functions into all mouse drivers?19:41
DocScrutinizer05or mouse function into the generic fingerprint reader driver?19:42
DocScrutinizer05and how makes that sense on all other devices that don't offer using fingerprint reader as trackball/pointer19:43
whitequarkthe answer is "same as without DT", really19:45
DocScrutinizer05I'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 platforms19:46
--- Mon Sep 8 201400:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!