#qi-hardware IRC log for Sunday, 2012-09-16

mthlarsc: the battery driver uses its parent's (mfd) platform data as its own platform data02:11
mthhowever, that approach becomes problematic if more than one subdriver needs platform data02:11
larscmth: yes07:13
Aylamorning larsc 07:13
larschi Ayla 07:14
AylaI'm back from night club, I'm going to sleep now ;)07:14
Aylaciao07:14
larschehe07:14
larscmth: And to be honest I don't like that approach of using the parents platform_data anymore, because it does not allow you to reuse a mfd cell for different mfd devices07:16
qi-botThe build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120916-0654 11:48
LunaVoraxhi!12:25
mthlarsc: is there a way though to provide platform_data directly to an mfd subdevice?13:23
larscshould be possible13:24
mthI wouldn't know where to attach it13:24
larscwell you'd have to split the platform data up in the mfd driver and pass it to the child devies13:24
mthwhat would be a clean way of doing that? as in, without having the mfd driver know which child devices exist13:25
mthI've got an analog joystick connected to the touch screen pins13:25
mthso that demonstrates that there can be more than one driver for the same cell13:26
mth(since there could be an ordinary touch screen driver as well)13:26
larscyea that case it is a bit tricky13:26
larschow does the analog joystick driver work?13:27
mthI'm not sure if driver selection should be done at configure time (one driver per cell for each board) or even at runtime (loading and unloading modules)13:27
mththe x and y axis both provide a voltage, which is read from the touch screen regs in the SADC13:27
mththe driver doesn't work yet, I'm still writing it ;)13:28
mthI think I'll just have to poll it at a fixed interval to start a read and when the read completes, inject the input events13:28
larscI wrote a TS driver back than. Take a look at commit d21ad639b3d42a2124432fa1ea7e7ea2b38e0a8d13:29
larscI think you can program the core to report new values when they change13:29
larscgenerate an interrupt, when the values cahnge13:29
mthlarsc: thanks; the probe looks very similar to what I have so far, the rest might be useful when adding the actual reading13:38
mthI'll add is_open to my driver as well, since it's useful for doing suspend properly13:39
larscmth: Have you seen commit 95ceafd46 ("cpufreq: Add a generic cpufreq-cpu0 driver")14:51
larscbasically a cpufreq driver which uses the clk API14:52
larsccould replace the jz4740 cpufreq driver14:52
Aylaawesome14:53
larscat least I think it could14:54
mthlarsc: I haven't seen it yet15:46
mthreplacing the driver would be good if possible15:46
mththe most problematic part though is that derived clocks have to be shut down during the PLL reconfiguration15:46
Aylait's not a problem15:47
mthno?15:47
Aylajust move the code that reinits the PLL to the clock driver15:47
mthit's already there15:47
Aylano, it's on the cpufreq driver15:47
mthit's not; the cpufreq driver calls the clock driver15:48
mthyou can't just disable the other clocks at an arbitrary moment, you have to give the respective drivers a chance to stop their work at a point where that is possible15:48
larscthe current approach is to use the cpufreq notifiers, isn't it?16:04
Aylareadl / writel are deprecated?16:08
mthlarsc: yes, but it's only implemented for mmc at the moment16:10
larscAyla: sort of, but nobody cares16:10
AylaI'll just use iowrite32/ioread3216:13
AylaI don't know what header to include for readl/writel :)16:14
larscio.h16:14
--- Mon Sep 17 201200:00

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