summaryrefslogtreecommitdiff
path: root/tests/modedemo/demo.c
diff options
context:
space:
mode:
authorMaarten Maathuis <madman2003@gmail.com>2008-06-23 22:59:17 +0200
committerMaarten Maathuis <madman2003@gmail.com>2008-06-23 22:59:17 +0200
commit246b41fea462a3b1669c0e3f9fe7f6077a479832 (patch)
treecc3e47873db2b3be7b4636c55510d590975ac228 /tests/modedemo/demo.c
parentf9dad8cc22994e0e4671d14b3ee721e4b5777a68 (diff)
[modesetting-101] update mode count after fill_modes.
- This avoids returning with a mode count of 0, thus not allocating space for the 2nd ioctl.
Diffstat (limited to 'tests/modedemo/demo.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-17 22:23:12 +0000
would say its possible if there it is high priority 09:36 < horms> i plan to make a start on my non-tasks for the current period sooner than later as I already know what the tasks are even if they are in a no-paperwork state at this time 09:36 < horms> that should give me a bit more time to play with next Q 09:36 < wsa_> cool 09:37 -!- shimoda [~shimoda@relprex2.renesas.com] has joined #periperi-io 09:37 < wsa_> geertu: this task 09:37 < wsa_> SCIF,v4.10,public,geert,difference in behavior between hardware-assisted flow control and GPIO flow control 09:37 < wsa_> is it fixed with 09:38 < wsa_> e8de8e1c28560795 serial: sh-sci: Fix early deassertion of dedicated RTS 09:38 < wsa_> ? 09:38 < wsa_> hi shimoda-san 09:39 < geertu> wsa_: Yes, but Laurent wanted me to fix the pin initialization at the same time, so the maintainer hasn't picked up that patch, and I need to implement his comment first :-( 09:39 < wsa_> neg: did i get this right. Since Hans asked you to drop some patches of the VIN series, this effectively means that the IP core switcher series is postponed until some heavy restructuring in the V4L2 core? 09:39 < wsa_> geertu: 09:39 < wsa_> geertu: i see 09:40 < shimoda> hi wolfram-san! 09:40 < wsa_> geertu: so, this is v4.12 now? 09:40 < geertu> probably 09:41 < wsa_> ok 09:41 < dammsan> wsa_: will you have time for IP core switch development for I2C? 09:41 < neg> wsa_: yes and no, the over all problem needs V4L2 work for the problem we have in VIN i have a new patch I hope he will accept and plan to post as part of my current multimedia additonal task 09:41 < dammsan> wsa_: in the next quarter regarding additional tasks i mean 09:42 < wsa_> dammsan: there is a dependency on parts of the VIN series, so unclear for now 09:43 < dammsan> wsa_: ok thanks 09:44 < wsa_> it wouldn't like to schedule an add. task which only causes regressions everywhere :) 09:46 < wsa_> neg: please keep me CCed on the VIN patches that might be relevant for me 09:46 * morimoto back from happy paper work 09:46 < wsa_> morimoto: paperwork makes you happy? 09:47 < neg> wsa_: will do 09:48 -!- Irssi: #periperi-io: Total of 8 nicks [1 ops, 0 halfops, 0 voices, 7 normal] 09:48 < wsa_> jmondi: are you all good? 09:49 < jmondi> wsa_: yes I am 09:50 < jmondi> I would like to discuss briefly about the max9611 driver progress 09:50 < wsa_> sure 09:51 < jmondi> well, basically Jonathan has reviewed the driver, some comments here and there, but we'll get there 09:51 < jmondi> what I would like to have clarified is the usage model of the userspace interface 09:52 < jmondi> because it makes a great difference knowing what would ideally be the polling frequency, to decide if driver should implement buffered reads or just chrdev interface is enough 09:52 <@morimoto> wsa: I'm supper happy now :) 09:53 < jmondi> that chip will be used to implement DVFS policies, right? 09:56 < wsa_> what would be the effort to implement caching? 09:56 < wsa_> i'd think let's wait with caching until we know we need it? 09:57 < jmondi> ok, I know we don't have to reason for just one specific use case, but given the many functions of that chip, I feel like we should define a use case for that on Renesas platforms 09:59 < jmondi> also, there are some constraints due to the HW design (eg. driver does not support some functions like op-amp and comparator, because they're not wired on Salvator-X design) 10:00 < wsa_> i see 10:00 < wsa_> is that documented somewhere? 10:01 < wsa_> i think this is fairly standard linux driver evolution, but it is always helpful to document what is implemented and what not 10:02 < jmondi> yes, in the driver there are many comments about non-supported functionalities... 10:02 < jmondi> but that's not big deal, last question about Jonathan was more about what polling frequency should the driver support 10:03 < jmondi> that makes implementation quite different 10:03 < jmondi> we can take that privately later, if I'm flooding the channel and the meeting with this, sorry 10:03 < wsa_> geert may correct me, but as I see it we are currently missing the details like this? 10:04 < wsa_> jmondi: all fine, this is one place to discuss such things 10:04 < geertu> The MAX9611 is used to monitor power consumption on the DVFS and VDD0.8 rails 10:04 < jmondi> ok then, I won't feel bad talking too much then 10:04 < geertu> I don't know what's the typical timing granularity needed for that 10:05 < wsa_> maybe jonathan has an idea? 10:05 < jmondi> seems like he's undecided as well... The real issue here is auto-gain configuration 10:05 < wsa_> is there a "most flexible" solution? 10:06 < jmondi> eh, I wish I know what that would be... supporting most uses cases implies creating a quite sluggish interface in sysfs, where userspace is required to take care of auto-gain settings 10:07 < jmondi> a sort of calibration process 10:08 < jmondi> on the other side, we can present the "processed" values from a single attribute, performing auto-gain setting in kernel space, but that would not support buffered reads, and will make complex implementing it in future 10:09 < jmondi> and that's where my question come from: Do we have any idea what would be a plausible sampling frequency on that device (if we do have defined use-cases for that chip specific to our platforms) 10:09 < wsa_> i see 10:10 < geertu> jmondi: You could ask BayLibre (Neil Armstrong) what sampling frequency they find useful for ACME with their tools 10:10 < wsa_> things I can think of: 10:10 < wsa_> a) ask on linux-pm if they have an idea what frequency is needed 10:11 < wsa_> or BayLibre ;) 10:11 < wsa_> and b) I don't think implementing complex userspace configuration without a clear use-case is benefitial 10:11 < geertu> jmondi: I never use the GUI tools that draw graphs 10:12 < geertu> w.r.t. b) yes, KISS 10:12 < wsa_> exactly 10:13 < jmondi> geertu: I didn't even know it existed. Mostly, I don't know what tools are out there that polls on a device like this, that's why I don't have idea about typical use cases 10:13 < wsa_> which would lead to chosing the "simpler" method unless we can create the use case 10:14 < wsa_> jmondi: does it help you a little? 10:14 < jmondi> geertu: wsa_: Ok, I'll ask a bit around, if I'm not pointed to any monitoring tool with strict time requriements out there, I'll go for the simple solution 10:15 < jmondi> wsa_: yes, thank. Sometimes is easy for me to get lost, and need some directions to find out where to ask informations or where to look at :) 10:15 < wsa_> sounds good to me for now 10:15 < geertu> jmondi: http://baylibre.com/acme/ shows some screenshots. One of them says "100 S/s" 10:15 < wsa_> jmondi: this is true for all of us 10:16 < wsa_> and where working in a team is really benefitial :) 10:16 < jmondi> wsa_: it's a big world out there :) 10:16 < jmondi> geertu: thanks 10:16 < wsa_> please post your findings to renesas-soc or periperi, I think we are all interested in the outcome 10:16 < geertu> wsa: And esp. with FLOSS, the team (and its knowledge) is big 10:17 < wsa_> yes :D 10:17 < wsa_> so, I'd like to close the meeting soon 10:17 < wsa_> so, if there is anything unsaid left, now would be the time 10:18 <@morimoto> OK, thanks boys & girls !! 10:19 < shimoda> thanks! bye! 10:19 < geertu> Thx, bye! 10:19 < jmondi> thank you all, bye! 10:20 < horms> bye 10:20 < wsa_> Good then, have a great week all! 10:20 < neg> thanks all 10:21 < wsa_> neg: I'll try to review your thermal patches later today 10:21 < wsa_> bye 10:22 < neg> wsa_: thanks 10:24 -!- shimoda [~shimoda@relprex2.renesas.com] has quit Quit: WeeChat 0.4.2 --- Log closed Tue Mar 07 10:25:27 2017