| 00:28.14 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 00:28.14 | *** mode/#qi-hardware [+o ChanServ] by lindbohm.freenode.net |
| 00:52.40 | *** join/#qi-hardware kristianpaul (~kristianp@2607:f878:ff00:31::2) |
| 00:52.40 | *** join/#qi-hardware kristianpaul (~kristianp@unaffiliated/kristianpaul) |
| 01:34.32 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 01:56.54 | *** part/#qi-hardware emeb (~ericb@ip72-201-79-123.ph.ph.cox.net) |
| 02:02.17 | *** join/#qi-hardware nikescar (~nikescar@114.199.131.108) |
| 02:11.33 | mth | larsc: the battery driver uses its parent's (mfd) platform data as its own platform data |
| 02:11.47 | mth | however, that approach becomes problematic if more than one subdriver needs platform data |
| 02:29.21 | *** join/#qi-hardware jow_laptop (~jow@ffx.subsignal.org) |
| 02:41.26 | *** join/#qi-hardware xdpirate (~xdpirate@213.138.174.137) |
| 02:43.01 | *** join/#qi-hardware xdpirate (~xdpirate@213.138.174.137) |
| 03:38.22 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:21.39 | *** join/#qi-hardware scientes (~scientes@unaffiliated/scientes) |
| 06:15.47 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 07:10.58 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 07:10.58 | *** join/#qi-hardware uwe_ (~uwe_@dslb-088-064-209-125.pools.arcor-ip.net) |
| 07:11.43 | *** join/#qi-hardware newcup (newcup@peruna.fi) |
| 07:11.53 | *** join/#qi-hardware pabs3 (~pabs@122.111.244.120) |
| 07:11.53 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 07:13.36 | larsc | mth: yes |
| 07:13.55 | Ayla | morning larsc |
| 07:14.06 | larsc | hi Ayla |
| 07:14.27 | Ayla | I'm back from night club, I'm going to sleep now ;) |
| 07:14.51 | Ayla | ciao |
| 07:14.52 | larsc | hehe |
| 07:16.26 | larsc | mth: 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 devices |
| 07:24.23 | *** join/#qi-hardware kristoffer (~kristoffe@c-9ed8e555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 07:42.13 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 09:35.23 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 10:08.08 | *** join/#qi-hardware ChanServ (ChanServ@services.) |
| 10:08.08 | *** mode/#qi-hardware [+o ChanServ] by lindbohm.freenode.net |
| 10:54.37 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 11:47.33 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 11:48.32 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120916-0654 |
| 11:54.31 | *** join/#qi-hardware urandom__ (~user@p54B0E92A.dip.t-dialin.net) |
| 12:25.03 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 12:25.24 | LunaVorax | hi! |
| 12:55.50 | *** join/#qi-hardware freakazoid0223 (~matt@pool-71-246-26-142.phlapa.fios.verizon.net) |
| 13:23.28 | mth | larsc: is there a way though to provide platform_data directly to an mfd subdevice? |
| 13:24.10 | larsc | should be possible |
| 13:24.33 | mth | I wouldn't know where to attach it |
| 13:24.34 | larsc | well you'd have to split the platform data up in the mfd driver and pass it to the child devies |
| 13:25.30 | mth | what would be a clean way of doing that? as in, without having the mfd driver know which child devices exist |
| 13:25.50 | mth | I've got an analog joystick connected to the touch screen pins |
| 13:26.10 | mth | so that demonstrates that there can be more than one driver for the same cell |
| 13:26.26 | mth | (since there could be an ordinary touch screen driver as well) |
| 13:26.56 | larsc | yea that case it is a bit tricky |
| 13:27.05 | larsc | how does the analog joystick driver work? |
| 13:27.24 | mth | I'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.55 | mth | the x and y axis both provide a voltage, which is read from the touch screen regs in the SADC |
| 13:28.19 | mth | the driver doesn't work yet, I'm still writing it ;) |
| 13:28.50 | mth | I think I'll just have to poll it at a fixed interval to start a read and when the read completes, inject the input events |
| 13:29.08 | larsc | I wrote a TS driver back than. Take a look at commit d21ad639b3d42a2124432fa1ea7e7ea2b38e0a8d |
| 13:29.41 | larsc | I think you can program the core to report new values when they change |
| 13:29.50 | larsc | generate an interrupt, when the values cahnge |
| 13:33.18 | *** join/#qi-hardware Aylax (~Aylax@pc-144-230-164-190.cm.vtr.net) |
| 13:38.57 | mth | larsc: thanks; the probe looks very similar to what I have so far, the rest might be useful when adding the actual reading |
| 13:39.44 | mth | I'll add is_open to my driver as well, since it's useful for doing suspend properly |
| 13:53.38 | *** join/#qi-hardware Ayla (~paul@pc-144-230-164-190.cm.vtr.net) |
| 14:12.34 | *** join/#qi-hardware guanucoluis1 (~luis@200.127.180.65) |
| 14:51.52 | larsc | mth: Have you seen commit 95ceafd46 ("cpufreq: Add a generic cpufreq-cpu0 driver") |
| 14:52.05 | larsc | basically a cpufreq driver which uses the clk API |
| 14:52.13 | larsc | could replace the jz4740 cpufreq driver |
| 14:53.24 | Ayla | awesome |
| 14:54.09 | larsc | at least I think it could |
| 15:07.35 | *** join/#qi-hardware porchao (~hato@eatkyo312007.adsl.ppp.infoweb.ne.jp) |
| 15:46.22 | mth | larsc: I haven't seen it yet |
| 15:46.32 | mth | replacing the driver would be good if possible |
| 15:46.54 | mth | the most problematic part though is that derived clocks have to be shut down during the PLL reconfiguration |
| 15:47.11 | Ayla | it's not a problem |
| 15:47.22 | mth | no? |
| 15:47.23 | Ayla | just move the code that reinits the PLL to the clock driver |
| 15:47.30 | mth | it's already there |
| 15:47.39 | Ayla | no, it's on the cpufreq driver |
| 15:48.01 | mth | it's not; the cpufreq driver calls the clock driver |
| 15:48.42 | mth | you 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 possible |
| 16:04.09 | larsc | the current approach is to use the cpufreq notifiers, isn't it? |
| 16:08.27 | Ayla | readl / writel are deprecated? |
| 16:10.14 | mth | larsc: yes, but it's only implemented for mmc at the moment |
| 16:10.24 | larsc | Ayla: sort of, but nobody cares |
| 16:13.52 | Ayla | I'll just use iowrite32/ioread32 |
| 16:14.02 | Ayla | I don't know what header to include for readl/writel :) |
| 16:14.16 | larsc | io.h |
| 16:36.39 | *** join/#qi-hardware emeb (~ericb@ip72-201-79-123.ph.ph.cox.net) |
| 17:36.01 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-83.telecom.by) |
| 17:36.53 | *** join/#qi-hardware heberth (~heberth@186.116.55.7) |
| 17:59.23 | *** join/#qi-hardware porchao (~hato@eatkyo312007.adsl.ppp.infoweb.ne.jp) |
| 18:16.07 | *** join/#qi-hardware dandon (~dandon@88.151.74.140) |
| 18:42.37 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 18:45.17 | *** join/#qi-hardware xdpirate (~xdpirate@213.138.174.137) |
| 18:48.59 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 18:57.45 | *** join/#qi-hardware heberth (~heberth@186.116.55.7) |
| 18:58.35 | *** join/#qi-hardware guanucoluis1 (~luis@200.127.180.65) |
| 19:37.54 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-4-189.ozonline.com.au) |
| 20:03.39 | *** join/#qi-hardware LunaVorax (~LunaVorax@cau33-2-82-227-183-10.fbx.proxad.net) |
| 20:24.51 | *** join/#qi-hardware kuribas (~user@94-227-88-230.access.telenet.be) |
| 20:31.54 | *** join/#qi-hardware GNUtoo|laptop (~gnutoo@50.118-226-89.dsl.completel.net) |
| 21:49.42 | *** join/#qi-hardware guanucoluis1 (~luis@200.127.180.65) |
| 22:49.59 | *** part/#qi-hardware emeb (~ericb@ip72-201-79-123.ph.ph.cox.net) |