蜗窝科技

期待后面的蓝牙文章

@wowo：linuxer同鞋在哪家公司啊？

@wowo：让你见笑了，sysfs_create_file我都没太注意。 我是在看sysfs那一章节的同时产生的疑问，具体是fill_read_buffer函数中的count = ops->show(kobj, attr_sd->s_attr.attr, buffer->page)这一句。这里ops->show就是ktype中sysfs_ops的show，跟进去以后发觉ktype的show和store其实没做具体的事情。kernel中所有的ktype的show及store无一例外的都是类似下面这样： static ssize_t xxx_attr_show(struct kobject *kobj, struct attribute *attr, char *buf) { struct xxx_attribute *yyy; ... yyy = container_of(attr, struct xxx_attribute, attr); if (yyy->show) ret = yyy->show(kobj, buf); ... } 基本上就是一个思想：通过container_of获取attr的上层struct，然后再调用上层的show方法，而attr的上层struct又总是象个样子： struct xxx_attribute { struct attribute attr; ssize_t (*show)(...); ssize_t (*store)(...); }; 例如 bus_attribute, device_attribute, kobj_attribute等等。 所以sysfs的read/write真正关联的是kobj_attribute、device_attribute这些。 关键的操作是在sysfs_add_file_mode()函数中sd->s_attr.attr = (void *)attr这一条语句(这里有些猜测的成分，因为只看到了s_attr.attr部分，wowo能帮助确认下？)，sysfs_create_file以及sysfs_create_group都会调用到sysfs_add_file_mode来建立关联。 但是我看到sysfs_create_file中对ktype的default_attrs进行判断，若为NULL则不会建立这种关联。 ps:kernel中有一个例子 kobject-example.c，里面很典型的使用了sysfs_create_group这种方式。

@pingchangxin：多谢，我们会加油的。

@linuxer：呵呵，这种事儿我也急不来啊~~~

wowo同学，华为已经出了64 bit的ARM处理器，你们要加快啊

很赞成作总比不做好，谢谢你们的分享！

@tigger：这里我没有说明清楚，这里有两个precharge的词语，用在两个不同的场景中，一个是描述在进行cell的读操作的时候，使用了precharge讲BL的电压升到Vs/2。另外一个场景描述SDRAM controller发送PRECHARGE的命令，这个操作仅仅是操作WL，将一个行中的所有cell的M1三极管处于截止状态。 为了不引起歧义，我还是把第一个场景中的precharge修改一下吧

@tigger：datasheet中的时序图非常多，我就没有贴上去，有空也可以补上

@tigger：cpu deep sleep之后不会跑着iram中的code，因为这时候CPU已经不会取指令运行了。好的CPU应该在deep sleep之后应该shutdown包括CPU核心电压在内的大部分供电，仅仅保留一个非常小的SOC 上的一个HW block的供电，这个供电域应该包括RTC，2~3个GPIO，从deep sleep唤醒的逻辑电路，至少有一个scratch寄存器，保护了sleep那一点的PC值。 如果你想suspend to RAM的话，DDR的供电一定要保持。如果是suspend to disk的话，当然也可以shutdown DDR chip的供电。 当resume的时候，由于cpu core是完全下电的，因此cpu通用寄存器的内容全部都保持不住了（iram是否能保持住数据是和SOC系统的电源管理设计相关的），这时候，PC一般会等于0，也就是说从0地址开始取指令执行，具体0地址是什么也是和SOC设计相关，可能是ROM代码，也可能是NOR flash代码（也就是bootloader的代码了），但无论如何，最终是从scratch寄存器中恢复PC至，跳转到DDR ram中执行 ddr training和ddr bitflip我没有接触过，你可否给讲一讲？