蜗窝科技

同意楼上

我发现在pinctrl_register的时候会把自身也创建一个struct pinctrl结构，由struct pinctrl_dev 内部指针p指向该结构。pinctrl自身申请者个struct pinctrl结构的目的是什么。 /** * pinctrl_register() - register a pin controller device * @pctldesc: descriptor for this pin controller * @dev: parent device for this pin controller * @driver_data: private pin controller data for this pin controller */ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc, struct device *dev, void *driver_data) { struct pinctrl_dev *pctldev; int ret; if (!pctldesc) return NULL; if (!pctldesc->name) return NULL; pctldev = kzalloc(sizeof(*pctldev), GFP_KERNEL); if (pctldev == NULL) { dev_err(dev, "failed to alloc struct pinctrl_dev\n"); return NULL; } /* Initialize pin control device struct */ pctldev->owner = pctldesc->owner; pctldev->desc = pctldesc; pctldev->driver_data = driver_data; INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL); INIT_LIST_HEAD(&pctldev->gpio_ranges); pctldev->dev = dev; mutex_init(&pctldev->mutex); /* check core ops for sanity */ if (pinctrl_check_ops(pctldev)) { dev_err(dev, "pinctrl ops lacks necessary functions\n"); goto out_err; } /* If we're implementing pinmuxing, check the ops for sanity */ if (pctldesc->pmxops) { if (pinmux_check_ops(pctldev)) goto out_err; } /* If we're implementing pinconfig, check the ops for sanity */ if (pctldesc->confops) { if (pinconf_check_ops(pctldev)) goto out_err; } /* Register all the pins */ dev_dbg(dev, "try to register %d pins ...\n", pctldesc->npins); ret = pinctrl_register_pins(pctldev, pctldesc->pins, pctldesc->npins); if (ret) { dev_err(dev, "error during pin registration\n"); pinctrl_free_pindescs(pctldev, pctldesc->pins, pctldesc->npins); goto out_err; } mutex_lock(&pinctrldev_list_mutex); list_add_tail(&pctldev->node, &pinctrldev_list); mutex_unlock(&pinctrldev_list_mutex); pctldev->p = pinctrl_get(pctldev->dev);

@linuxer：本想完整看懂tty驱动再回复，但遇到问题多多。 突然有个建议提给博主： 能否仿照侯捷的《深入浅出MFC》来阐述linux内核？ 去掉旁支，留下主干，然后用非常精简的一个示例代码展示内核；对于理解内核来说，这应该是最容易的。

再次来读这篇文章，感觉就像看小说一样精彩，佩服博主。

@tigger：这个听起来很高端啊！我也没有搞过。让我现在立刻考虑的话我有两个方向： 1、enable cache之后很难直接访问它，cache中的内容对软件是透明的，软件只能是lock住某些cacheline，或者flush某些cache line等等类似操作。也许可以在disable cache之后，通过普通访问ram的方式进行，这时候，那些cache的地址会 mapping 到cpu的某段地址上 2、看看有没有什么特殊的寄存器可以dump出cache的内容

老大，我最近在考虑一个比较难搞的问题。想请教一下。 我怎么样才能看到cache里面的东西呢。我现在有仿真器比如trace32等等，在某种情况下，我想把cache里面的东西搞出来，然后看一下实际上arm是跑的什么代码。但是我对cache里面数据的格式，或者怎么对应memory里面的代码，暂时没有很好的想法。 现在还在构思阶段，没有实际动手操作。

@linuxer：好的，thank you

@wowo：感谢回复！！ 我会改变学习方法的，实践，实践，do it,do it,do it......

@tianhello：好像也没有直接的关系，不过系统中的HW timer也不会太多，可以根据具体情况具体分配rating。

@twenty：抱歉！开头那句话，我表达的不清晰，所谓的“好理解”，是指devm_xxx接口和之前的接口的区别，以及使用这些接口的好处。 当然，device resource意义及实现，确实很难理解。但这又如何呢？对一个驱动工程师来说，为什么一定需要理解device resource呢？只要会使用这些devm_xxx接口，就足够了啊！ 所以不用纠结，这也正是我给你的建议： 学习的过程是一个螺旋式上升的过程，同样的一个事物，你今天看，和你5年后看，肯定是不一样的。这不是能力问题，而是经验问题。因此看不懂又如何呢？先放放，总有一天回过头来就懂了。 立志搞linux底层，就找一份相关的工作，做就行了。复杂驱动不会，就先做简单的。简单的也不会？那就从别处抄嘛！总有一天什么都会了。 因此重要的不是看了多少文档、书籍，而是有没有行动起来，去做就是了！