留言板

路过的蜗牛们，在这里留个脚印吧～

蜗窝欢迎各种言论，谈天说地、技术交流、问题求救、跳槽招聘、牢骚抱怨……哈哈。

评论：

wowo
2016-06-17 10:25
mobz兄，一早看到您的留言，非常感激，能用心向蜗窝提意见的人，是真心关心蜗窝的人，多谢了。
我觉得，这个意见，很好、很尖锐、也很矛盾。我需要小心的回答，也欢迎更多的人留言讨论（为了方便，我把它转移到留言板了），讨论的结果，我会更新到“关于蜗窝”页面。
有一点需要更正一下，蜗窝不仅仅是“一个主要针对linux内核和驱动深入研究的地方”。因为技术是相通的，不应该有界限。无论是linux kernel、还是RTOS、还是应用软件，无论是软件设计、还是硬件设计、还是产品设计，其背后的指导思想都是相同的。
从表面看，蜗窝为大家分享了很多技术文章，有些文章可能帮到了某些人，但这并不是蜗窝的直接目的（因此CSDN不是蜗窝的榜样）。
蜗窝的直接目的，是通过整理、分享一些文章，以便加深自己的理解，提升自己的能力。
在这个基础上，如果我们整理、分享出来的这些文章，条理和逻辑足够清晰，以至于可以启发、帮助到他人，就再好不过了，就当是利己利人吧。
隐藏在这背后的，就是蜗窝的理念，以及一直没敢说出来的目标（太宏大、太困难、太不切实际，因此怕被笑话），就是改变国内的技术氛围，改变从业者对待技术、对待自己所从事的工作以及对待自己的态度。
怎么改变呢？从对待技术和工作的态度做起：沉得住气，细致、认真，善于总结，善于刨根问底，能够认同所从事的工作，并从中获得愉悦感和充实感。
这就是蜗窝一直鼓励大家分享的原因所在，分享是到达这个目的的第一步，从不假思索的索取模式，转换为思考模式，哪怕思考的过程只有自己能懂，也足够了（达者兼济天下 穷者独善其身）。
最后，就是分享的质量了，说实话，我也很矛盾。正如您所说，linuxer和我写的一些文章，虽然不是特别好，但也不算差，在百度和谷歌的搜索排名，基本上都是第一页，这是蜗窝的荣幸，但我们不应满足于此。
因此，对于其他同学的分享，我们的要求很简单，原创+有自己的思考，至少能把自己写明白，最好能坚持、有进步。当然，有些可能对蜗窝有影响，希望大家宽容对待。
也希望迈出第一步和大家分享的同学，把压力转化为动力，精益求精，像对待知己、恋人、孩子一样，对待自己的文字。
回复
electrlife
2016-08-25 12:48
@wowo：Hi，我很好奇版主是从事什么行业的，具体的工作职责是什么，如何练就这样的胸怀与思想？
真的很是佩服！每每想到我何时在linux 方面也能有这样的造诣！就感觉很渺茫！因为不懂所以觉得Linux 真的很神奇，程序的结构真的很值得学习！但最近找工作确又给我泼冷水，做Linux 驱动的公司一般开的工资都在2万以内，感觉和Linux 的高大上完全不符！或者是说确实自己的水平太低了！
回复
electrlife
2016-08-25 12:51
@wowo：或者说版主在Linux 驱动开发这个职位给点建议！或者说在驱动这方面的职业规划是什么样的？
回复
wowo
2016-08-26 09:53
@electrlife：大家的工作都差不多。我能建议的就是，开心就好~~
回复
electrlife
2016-08-26 17:46
@wowo：版主，不可以这样，给点具体建议吧！^_^
回复
electrlife
2016-08-26 17:46
@wowo：版主，不可以这样，给点具体建议吧！^_^
回复
wowo
2016-08-26 19:44
@electrlife：哈哈，话说这个问题太不好回答了，你可以去讨论区看看：
http://www.wowotech.net/forum/viewtopic.php?id=18
http://www.wowotech.net/forum/viewtopic.php?id=5
回复
wowo
2016-06-15 18:50
@linglongqion, @callme_friend,已经把两位发表文章的权限放开了（不需要审核了），希望多分享哈~~
回复
linglongqion
2016-06-17 15:35
@wowo：道路且长
回复
wowo
2016-06-17 15:55
@linglongqion：且长且坚，同志仍需努力~~~
回复
Tao
2016-06-06 17:30
有对input子系统了解比较好的么，来一份技术文档吧~
回复
wowo
2016-06-06 22:25
@Tao：多谢关注，暂时还没有时间写，后面有时间了一定会写~~
回复
saber_ice
2016-06-01 00:04
偶然发现这里，感觉很不错。这里还想请教一下，作为一个初学者，想往linux驱动方向发展，从哪入手呢。
回复
wowo
2016-06-01 08:55
@saber_ice：论坛上有一个讨论这个事情的帖子，你可以看看：http://www.wowotech.net/forum/viewtopic.php?id=5
回复
saber_ice
2016-06-02 21:00
@wowo：谢谢wowo，也谢谢linuxer分享，给我们这些菜鸟指了条明路啊
回复
wpch315
2016-03-28 09:24
找到原因了，arch idle时系统会进入low power模式，会对外设power gating，dma控制器唤醒延迟较长导致问题，把低功耗等级降下一个就好了
回复
wowo
2016-03-28 09:46
@wpch315：恭喜恭喜，也多谢和大家分享出来~~~
回复
bigchris
2016-10-13 18:52
@wpch315：如果是wfi 做clk gating的情况，是us的反应，power gating的反应时间一般都是100us级，如果power gating的范围比较大的话，时间会更长，这个与clk与power上电的稳定时间相关，还有就是如果有cache flush的话，其时间占比也非常大。
回复
wpch315
2016-03-22 14:23
@wowo
请教一个问题，最近调串口驱动时发现使用dma的方式接收数据有问题，目前的现象是：

在系统的线程都处于休眠状态的时候，dma接收有问题，我建立了一个线程一直进行while循环，这时dma接收就是OK的

分析后发现可能是dma驱动中中断里调度一个tasklet时，在系统的线程都处于休眠状态的时候会有较大的延迟，我想请问一下：
1.是否还有其他可能性较大的原因
2.如果确实是tasklet调度的问题，什么地方的问题会导致这种情况？

谢谢！
回复
wpch315
2016-03-22 17:30
@wpch315：我把tasklet里的事放到中断里做，发现现象一样，所以排除之前的推测，现在看上去就是线程的状态会影响dma的硬件行为，搞不清楚为什么会这样，请教各位
回复
wowo
2016-03-22 18:28
@wpch315：DMA接收有问题？具体什么表现呢？中断没有产生？还是产生了没有被响应？
系统是不是进低功耗状态了？而DMA中断无法唤醒？
回复
wpch315
2016-03-23 10:15
@wowo：中断产生并响应了，中断调度的tasklet里有打印错误信息，而且串口的中断方式接收是没有问题的
回复
wowo
2016-03-23 13:59
@wpch315：中断产生了，那在中断里面可以接收到数据吗？你说数据不对，怎么个不对法呢？我还是怀疑是因为系统进低功耗了，没有来得及接收串口数据，而你的串口没有流控，所以数据丢了。
回复
wpch315
2016-03-23 15:16
@wowo：中断里可以接收部分数据，同时报错，有两个错误，一个是dma传输错误，检测出这错误后读串口的状态寄存器报了第二个错误，rxfifo overrun，我也怀疑是系统进入低功耗状态后中断的响应不及时。
为了验证，我把电源管理相关的选项都关闭了，比如CPUidle，dvfs，包括底层的实现也都关了，但现象一样，不确定这样做是不是可以阻止系统进入低功耗状态？我用的imx53平台，单核A8，内核是2.6
回复
wowo
2016-03-23 15:38
@wpch315：我觉得的可以从如下的思路去查找原因：
1）打开系统电源管理有关的日志输出，确认出错的这段时间内，系统的状态到底如何，是否进行了低功耗状态的切换，是哪个低功耗状态？
2）根据你描述的现象，直接使用UART中断Okay，但DMA不Okay，则说明UART中断可以使系统从“这个低功耗状态”返回，而DMA中断不可以。看看CPU那些低功耗状态有可能这样做。
3）试试打开uart的流控功能，应该就可以解决。
jordonwu
2016-03-14 19:49
@wowo & all，

请教一个遇到的问题，一个lvds屏接imx6，这个lvds除了要配置timing之外，在工作之前需要通过spi接口执行一段初始化code，搜索了下参考代码，在imx_linux-3.0.35及之前的版本里有类似spi初始化lvds/lcd屏的代码（如http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/video/mxc/mxcfb_epson_vga.c?h=imx_3.0.35_4.1.0）
static int __init epson_lcd_init(void)
{
    int ret;
    ret = platform_driver_register(&lcd_plat_driver);
    if (ret)
        return ret;
    return spi_register_driver(&lcd_spi_dev_driver);
}

但是在新版本的kernel中，这些代码都被移除掉了，我想请问下：在引入device tree之后，如果要执行spi初始化lvds panel的代码，这个是在lvds的dts部分配置还是在spi的dts部分配置？ 另外kernel中是否已经存在有类似的code？ 谢谢
回复
wowo
2016-03-15 08:47
@jordonwu：我觉得，只要需要SPI操作，注册一个spi driver是不可少的啊。你这里说代码被移除了，无外乎两种可能：
1）放到其它位置了。
2）不再需要SPI初始化操作了。
你再看看代码，spi的操作方式没有改变。
回复
fancy
2016-03-11 14:58
WoWo你好，
请教一个问题， 我目前碰到系统在刚唤醒的时候，通过get_monotonic_boottime获取的时间没有包含系统sleep的时间，如果等待大约300ms左右，此时通过get_monotonic_boottime就能获取到包含了系统sleep的时间。
请问在系统刚被唤醒的时候，通过什么接口能够获取到包含了睡眠的时间？不甚感激！
回复
wowo
2016-03-11 16:48
@fancy：我对这个应用场景也不是很熟悉，不过可以提供一些思路，供你参考：
首先你用的这个接口应该是对的，问题是为什么会delay了300ms？
从timekeeping的resume流程来看（timekeeping_resume），有两个方法更新suspend的时间：
1）你所使用的clocksource支持suspend nonstop（CLOCK_SOURCE_SUSPEND_NONSTOP）。
2）rtc_resume的时候调用timekeeping_inject_sleeptime更新。
那么问题来了，你的平台使用的是什么方法？你在什么时机调用get_monotonic_boottime获取boot time呢？
回复
fancy
2016-03-14 15:33
@wowo：谢谢wowo的回复。

我是nexus5的开发平台（高通），在系统休眠后，mcu触发中断唤醒系统，在第一次中断处理函数中去获取boot time的。但是看log， 在“timekeeping_resume”中得到的timekeeping_suspend_time是0。 但是在第二次或第三次中断处理函数中再用get_monotonic_boottime去获取AP time, 这个时间就包含了系统suspend的时间。貌似timekeeping_resume获取到的suspend时间无法及时更新。

[  341.333599] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  341.424081] PM: suspend of devices complete after 79.244 msecs
[  341.430902] PM: late suspend of devices complete after 1.896 msecs
[  341.438512] PM: noirq suspend of devices complete after 2.369 msecs
[  341.444145] Disabling non-boot CPUs ...
[  341.454448] msm_pm_enter
[  341.454448] msm_pm_enter: power collapse
[  341.454448] msm_pm_enter collapsed=1
[  341.454465] timekeeping_resume() 0 0-----------------suspend tims is 0 (tv_sec and tv_nsec)
[  341.458198] Enabling non-boot CPUs ...
[  341.467805] CPU1 is up
[  341.471267] PM: noirq resume of devices complete after 1.804 msecs
[  341.477099] Resume caused by IRQ 301, qpnp_rtc_alarm
[  341.481485] Resume caused by IRQ 200, qcom,smd-rpm
[  341.487958] PM: early resume of devices complete after 1.509 msecs
回复
passerby
2016-03-14 18:00
@fancy：高通8939是用non stop sys counterd，不需要RTC做睡眠时间保存。不知道你这个的实现是怎么样的。
回复
wowo
2016-03-15 08:49
@passerby：是的，fancy同学并没有回答我提出的两个疑问。
回复
fancy
2016-03-15 17:10
@passerby：你好，谢谢回复，由于我对这块目前不太熟悉，能否稍微指导一下“non stop sys counterd”在哪部分代码里面实现的？我认真学习一下，我目前是msm8974.谢谢了。
回复
passerby
2016-03-15 17:26
@fancy：static struct clocksource clocksource_counter = {
    .name    = "arch_sys_counter",
    .rating    = 400,
    .read    = arch_counter_read,
    .mask    = CLOCKSOURCE_MASK(56),
    .flags    = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_SUSPEND_NONSTOP,
};
在 arm_arch_timer.c
回复
passerby
2016-03-15 17:30
@passerby：这个counter在suspend的时候不会睡眠，所以在timekeeping_resume()中检测到if ((clock->flags & CLOCK_SOURCE_SUSPEND_NONSTOP)就会通过counter中的计数来进行睡眠时间的更新。
fancy
2016-03-17 13:07
@passerby：谢谢，我看了msm8974这部分的代码，还是用的rtc去获取睡眠时间的，我遇到的问题原因是rtc_resume执行得太晚了。目前做了个规避，谢谢你的指导了。
fancy
2016-03-17 13:08
@passerby：你好，我找到问题的原因了，是rtc_resume执行太晚了引起的。谢谢了。
回复
fancy
2016-03-17 13:09
@fancy：你好，我找到问题的原因了，是rtc_resume执行太晚了引起的。谢谢了
回复
wowo
2016-03-17 17:29
@fancy：好消息:-)
回复
madang
2016-03-09 17:51
有没有计划讲讲smmu啊?
回复
wowo
2016-03-09 21:17
@madang：IOMMU用的地方越来越多，有空可以分析一下，不过暂时还没有计划呢。
回复
yun_2106118
2016-03-08 23:31
大家好，我现在遇到一个休眠问题，系统经常性遇到休眠不下去的问题，但是不是必然的，都是在frezz阶段失败，
Freezing of tasks aborted after 0.045 seconds，active wakeup source: alarm，请问下这个怎么去查。系统是5.1系统除此以外，系统没有其他wake_lock。睡眠不下去的时候，就一直重复上述frezz过程，不知道为什么alarm一直阻止，按理说，如果alarm没有执行完毕，不会再次启动睡眠流程啊。请各位帮忙指导下，谢谢
回复
wowo
2016-03-09 14:23
@yun_2106118：建议先检查一下这个wakeup source是kernel driver持有的，还是Android通过wakelock持有的，如果是driver持有的，可能是RTC相关的驱动有问题，如果是Android持有的，用dumpsys alarm，查一下系统是不是有异常的alarm设置。
回复
yun_2106118
2016-03-09 23:03
@wowo：谢谢wowo的回复，我看过wake_lock是没有任何锁的，而wakeup_souce中能够看到仅仅alarm是active状态，因此看起来时的确是kernel 锁，但是kernel里面是没有任何程序去使用rtc的，所以才有点纠结。我还是在查查kernel，如果有好的建议，还请多多指教。谢谢。
回复
wowo
2016-03-10 09:41
@yun_2106118：一般情况下，driver会在有事件要处理的时候，调用pm_wakeup_event等接口，上报wakeup事件。你检查一下RTC有关的driver，是不是有逻辑错误，上报event后没有清除。
回复

发表评论：

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog