lutianqian
    看了楼主的三篇文章,对设备树有更深刻的理解。不过本人还在学习中。还望楼主有空的时候能不能讲一些,设备树最终演化为平台设备端的时候,它的那些属性是plat_device下的res或者dev.platform_data,他们对应关系如何的呢?
    Device Tree(三):代码分析  发表时间:2015-12-05 22:07
    linuxer
    @descent:上面的回答稍显敷衍,主要是快下班了,着急着回家,现在老婆孩子睡了,可以安安静静的针对这个问题胡思乱考了,呵呵~~~ /dev/mem这个设备节点可以让用户空间建立页表并mapping到任意的系统中的物理地址上去,如果这个设备节点提供O_SYNC这种接口来控制映射的cache属性,那么这个接口是否是一个好的接口呢? 对于普通的memory而言,可以映射为non cached(例如DMA buffer,framebuffer等),也可以映射为cached(大部分的普通的data和heap上的memory都是cached),因此,通过O_SYNC来控制映射的cache属性是OK的,但是,对于IO memory而言,设置为cached真的适合吗?这可能会引入很多不必要的麻烦,因此,这种情况下,通过O_SYNC来控制映射的cache属性是徒增user的烦恼。而且,一旦提供了这样的接口,实际上用户空间的进程可以把多个虚拟地址映射到一个物理地址上去(建立多个页表,把不同的虚拟地址映射到同一个物理地址),并且指定不同的属性。软件这么任性,有没有和硬件商量呢? 这个问题转换成了cpu设计的问题了,即硬件如何处理同一个物理地址不同属性的访问,对于ARM64处理器而言,一个物理地址有memory type的设定(体现在页表中的描述符中的某些bit),要么是device,要么是memory。如果virtual_A地址被mapping到physical_A并通过页表设定为device,同时virtual_B地址也被mapping到physical_A并通过页表设定为memory,那么估计ARM处理的内心是崩溃的。ARM64处理器不愿意浪费多余的晶体管来处理这些破事,因此规定软件符合一定的规则,如果打破这个规则,那么cpu的执行逻辑是未知的。不同的cpu有不同的设计理念,因此phys_mem_access_prot是architecture specific的。ARM64的phys_mem_access_prot函数会根据硬件的要求,对页表进行的设定,确保符合处理器的要求。
    linuxer
    @descent:首先声明:我的回答是基于linux 4.1.10下的ARM64代码的,其他的情况我没有去看代码,估计类似。 对"/dev/mem"这个设备的使用一般包括两步: (1)open并获取一个fd (2)通过mmap将该fd mapping到该进程的一段虚拟地址空间上去,当程序实际访问这段虚拟地址空间的时候,就象访问了fd指向的那个对象。对于"/dev/mem"的fd而言,其指向了系统中的物理地址空间 如何建立进程虚拟地址空间(vma)和"/dev/mem"设备fd之间的mapping是通过其驱动file operations数据结构中的mmap成员函数来完成的,在该函数中会建立页表,从而控制cache write buffer等的设定。该函数的代码如下: static int mmap_mem(struct file *file, struct vm_area_struct *vma) { size_t size = vma->vm_end - vma->vm_start; if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size)) return -EINVAL; if (!private_mapping_ok(vma)) return -ENOSYS; if (!range_is_allowed(vma->vm_pgoff, size)) return -EPERM; if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size, &vma->vm_page_prot)) return -EINVAL; vma->vm_page_prot = phys_mem_access_prot(file, vma->vm_pgoff, size, vma->vm_page_prot); vma->vm_ops = &mmap_mem_ops; /* Remap-pfn-range will mark the range VM_IO */ if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, size, vma->vm_page_prot)) { return -EAGAIN; } return 0; } 其中,phys_mem_access_prot函数定义了页表中的memory attribute以及memory type的信息,代码如下: pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, unsigned long size, pgprot_t vma_prot) { if (!pfn_valid(pfn)) return pgprot_noncached(vma_prot); else if (file->f_flags & O_SYNC) return pgprot_writecombine(vma_prot); return vma_prot; } 对于ARM64的处理器而言,其物理地址空间有两种: (1)memory (2)device 从上面的代码可以看到,实际上O_SYNC这个flag只会在你要mapping的物理地址是memroy的时候才是有效的,如果你要mapping的物理地址本身就是IO(这也是/dev/mem的大多数的应用场合),那么页表项中的内容是pgprot_noncached,即: #define pgprot_noncached(prot) \ __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN) 这时候,无论是否有O_SYNC,页表的属性都是device类型的,而对于memory type是device类型的地址影响,uncache是必须的。
    descent
    請問 open("/dev/mem", O_RDWR | O_SYNC)) 需要使用 O_SYNC, 是為了不要有 cache 的干擾嗎?
    blessed
    博主分享的小技巧简单又实用
    vim使用技巧摘录  发表时间:2015-12-03 23:30
    linuxer
    @randy:这份文档是我准备废弃的文章之一,写的太凌乱了,很容易让人误解,你可以稍微等等,后续我们重写这一篇的。
    Linux内核同步机制之(三):memory barrier  发表时间:2015-12-03 08:41
    blessed
    @paul_chen:paul_chen,能把资料分享一下吗,最近也在搞alsa但是不知道怎么入手啊 369979505@163.com ths!
    留言板  发表时间:2015-12-02 18:16
    linglongqion
    应该是busybox版本的事儿,可能过于太老???换了一个比较新的版本就可以了
    Linux 3.18U盘无法正确使用  发表时间:2015-12-02 15:46
    randy
    说的围绕多个cpu对cache一致性的维护,是否可以说明下单核下mb的实现是怎么样的?
    Linux内核同步机制之(三):memory barrier  发表时间:2015-12-02 11:45
    wowo
    @zozowit:确实,idle作为一个单独的schedule class了, const struct sched_class idle_sched_class 至于schedule class的含义,我就不了解了。
    Linux cpuidle framework(1)_概述和软件架构  发表时间:2015-12-02 11:42

共7115条444/712上一页 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 下一页
Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog