litmus-rt-tegra.git - LITMUS^RT and MC^2 V0 support for the NVIDIA Tegra 3 SoC

diff options

author	Ming Lei <tom.leiming@gmail.com>	2011-07-15 23:51:00 -0400
committer	Mauro Carvalho Chehab <mchehab@redhat.com>	2011-09-21 21:17:14 -0400
commit	dd182e5416e872e30d90cf071758eec1cf6340d5 (patch)
tree	3b98ba603165b3cfcbde70ee30a94a31e927c06f /drivers
parent	5ebbf72dc51bd3b481aa91fea37a7157da5fc548 (diff)

[media] uvcvideo: Set alternate setting 0 on resume if the bus has been reset

If the bus has been reset on resume, set the alternate setting to 0. This should be the default value, but some devices crash or otherwise misbehave if they don't receive a SET_INTERFACE request before any other video control request. Microdia's 0c45:6437 camera has been found to require this change or it will stop sending video data after resume. uvc_video.c] Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Diffstat (limited to 'drivers')

-rw-r--r--

drivers/media/video/uvc/uvc_driver.c

-rw-r--r--

drivers/media/video/uvc/uvc_video.c

-rw-r--r--

drivers/media/video/uvc/uvcvideo.h

3 files changed, 11 insertions, 3 deletions

         list_for_each_entry(stream, &dev->streams, list) {
                 if (stream->intf == intf)
-                        return uvc_video_resume(stream);
+                        return uvc_video_resume(stream, reset);
         }
         uvc_trace(UVC_TRACE_SUSPEND, "Resume: video streaming USB interface "
  * buffers, making sure userspace applications are notified of the problem
  * instead of waiting forever.
  */
-int uvc_video_resume(struct uvc_streaming *stream)
+int uvc_video_resume(struct uvc_streaming *stream, int reset)
 {
         int ret;
+        /* If the bus has been reset on resume, set the alternate setting to 0.
+         * This should be the default value, but some devices crash or otherwise
+         * misbehave if they don't receive a SET_INTERFACE request before any
+         * other video control request.
+         */
+        if (reset)
+                usb_set_interface(stream->dev->udev, stream->intfnum, 0);
         stream->frozen = 0;
         ret = uvc_commit_video(stream, &stream->ctrl);
 /* Video */
 extern int uvc_video_init(struct uvc_streaming *stream);
 extern int uvc_video_suspend(struct uvc_streaming *stream);
-extern int uvc_video_resume(struct uvc_streaming *stream);
+extern int uvc_video_resume(struct uvc_streaming *stream, int reset);
 extern int uvc_video_enable(struct uvc_streaming *stream, int enable);
 extern int uvc_probe_video(struct uvc_streaming *stream,
                 struct uvc_streaming_control *probe);

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 444 445 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

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 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737

# # Copyright (c) 2006 Steven Rostedt # Licensed under the GNU Free Documentation License, Version 1.2 # RT-mutex implementation design ------------------------------ This document tries to describe the design of the rtmutex.c implementation. It doesn't describe the reasons why rtmutex.c exists. For that please see Documentation/rt-mutex.txt. Although this document does explain problems that happen without this code, but that is in the concept to understand what the code actually is doing. The goal of this document is to help others understand the priority inheritance (PI) algorithm that is used, as well as reasons for the decisions that were made to implement PI in the manner that was done. Unbounded Priority Inversion ---------------------------- Priority inversion is when a lower priority process executes while a higher priority process wants to run. This happens for several reasons, and most of the time it can't be helped. Anytime a high priority process wants to use a resource that a lower priority process has (a mutex for example), the high priority process must wait until the lower priority process is done with the resource. This is a priority inversion. What we want to prevent is something called unbounded priority inversion. That is when the high priority process is prevented from running by a lower priority process for an undetermined amount of time. The classic example of unbounded priority inversion is were you have three processes, let's call them processes A, B, and C, where A is the highest priority process, C is the lowest, and B is in between. A tries to grab a lock that C owns and must wait and lets C run to release the lock. But in the meantime, B executes, and since B is of a higher priority than C, it preempts C, but by doing so, it is in fact preempting A which is a higher priority process. Now there's no way of knowing how long A will be sleeping waiting for C to release the lock, because for all we know, B is a CPU hog and will never give C a chance to release the lock. This is called unbounded priority inversion. Here's a little ASCII art to show the problem. grab lock L1 (owned by C) | A ---+ C preempted by B | C +----+ B +--------> B now keeps A from running. Priority Inheritance (PI) ------------------------- There are several ways to solve this issue, but other ways are out of scope for this document. Here we only discuss PI. PI is where a process inherits the priority of another process if the other process blocks on a lock owned by the current process. To make this easier to understand, let's use the previous example, with processes A, B, and C again. This time, when A blocks on the lock owned by C, C would inherit the priority of A. So now if B becomes runnable, it would not preempt C, since C now has the high priority of A. As soon as C releases the lock, it loses its inherited priority, and A then can continue with the resource that C had. Terminology ----------- Here I explain some terminology that is used in this document to help describe the design that is used to implement PI. PI chain - The PI chain is an ordered series of locks and processes that cause processes to inherit priorities from a previous process that is blocked on one of its locks. This is described in more detail later in this document. mutex - In this document, to differentiate from locks that implement PI and spin locks that are used in the PI code, from now on the PI locks will be called a mutex. lock - In this document from now on, I will use the term lock when referring to spin locks that are used to protect parts of the PI algorithm. These locks disable preemption for UP (when CONFIG_PREEMPT is enabled) and on SMP prevents multiple CPUs from entering critical sections simultaneously. spin lock - Same as lock above. waiter - A waiter is a struct that is stored on the stack of a blocked process. Since the scope of the waiter is within the code for a process being blocked on the mutex, it is fine to allocate the waiter on the process's stack (local variable). This structure holds a pointer to the task, as well as the mutex that the task is blocked on. It also has the plist node structures to place the task in the waiter_list of a mutex as well as the pi_list of a mutex owner task (described below). waiter is sometimes used in reference to the task that is waiting on a mutex. This is the same as waiter->task. waiters - A list of processes that are blocked on a mutex. top waiter - The highest priority process waiting on a specific mutex. top pi waiter - The highest priority process waiting on one of the mutexes that a specific process owns. Note: task and process are used interchangeably in this document, mostly to differentiate between two processes that are being described together. PI chain -------- The PI chain is a list of processes and mutexes that may cause priority inheritance to take place. Multiple chains may converge, but a chain would never diverge, since a process can't be blocked on more than one mutex at a time. Example: Process: A, B, C, D, E Mutexes: L1, L2, L3, L4 A owns: L1 B blocked on L1 B owns L2 C blocked on L2 C owns L3 D blocked on L3 D owns L4 E blocked on L4 The chain would be: E->L4->D->L3->C->L2->B->L1->A To show where two chains merge, we could add another process F and another mutex L5 where B owns L5 and F is blocked on mutex L5. The chain for F would be: F->L5->B->L1->A Since a process may own more than one mutex, but never be blocked on more than one, the chains merge. Here we show both chains: E->L4->D->L3->C->L2-+ | +->B->L1->A | F->L5-+ For PI to work, the processes at the right end of these chains (or we may also call it the Top of the chain) must be equal to or higher in priority than the processes to the left or below in the chain. Also since a mutex may have more than one process blocked on it, we can have multiple chains merge at mutexes. If we add another process G that is blocked on mutex L2: G->L2->B->L1->A And once again, to show how this can grow I will show the merging chains again. E->L4->D->L3->C-+ +->L2-+ | | G-+ +->B->L1->A | F->L5-+ Plist ----- Before I go further and talk about how the PI chain is stored through lists on both mutexes and processes, I'll explain the plist. This is similar to the struct list_head functionality that is already in the kernel. The implementation of plist is out of scope for this document, but it is very important to understand what it does. There are a few differences between plist and list, the most important one being that plist is a priority sorted linked list. This means that the priorities of the plist are sorted, such that it takes O(1) to retrieve the highest priority item in the list. Obviously this is useful to store processes based on their priorities. Another difference, which is important for implementation, is that, unlike list, the head of the list is a different element than the nodes of a list. So the head of the list is declared as struct plist_head and nodes that will be added to the list are declared as struct plist_node. Mutex Waiter List ----------------- Every mutex keeps track of all the waiters that are blocked on itself. The mutex has a plist to store these waiters by priority. This list is protected by a spin lock that is located in the struct of the mutex. This lock is called wait_lock. Since the modification of the waiter list is never done in interrupt context, the wait_lock can be taken without disabling interrupts. Task PI List ------------ To keep track of the PI chains, each process has its own PI list. This is a list of all top waiters of the mutexes that are owned by the process. Note that this list only holds the top waiters and not all waiters that are blocked on mutexes owned by the process. The top of the task's PI list is always the highest priority task that is waiting on a mutex that is owned by the task. So if the task has inherited a priority, it will always be the priority of the task that is at the top of this list. This list is stored in the task structure of a process as a plist called pi_list. This list is protected by a spin lock also in the task structure, called pi_lock. This lock may also be taken in interrupt context, so when locking the pi_lock, interrupts must be disabled. Depth of the PI Chain --------------------- The maximum depth of the PI chain is not dynamic, and could actually be defined. But is very complex to figure it out, since it depends on all the nesting of mutexes. Let's look at the example where we have 3 mutexes, L1, L2, and L3, and four separate functions func1, func2, func3 and func4. The following shows a locking order of L1->L2->L3, but may not actually be directly nested that way. void func1(void) { mutex_lock(L1); /* do anything */ mutex_unlock(L1); } void func2(void) { mutex_lock(L1); mutex_lock(L2); /* do something */ mutex_unlock(L2); mutex_unlock(L1); } void func3(void) { mutex_lock(L2); mutex_lock(L3); /* do something else */ mutex_unlock(L3); mutex_unlock(L2); } void func4(void) { mutex_lock(L3); /* do something again */ mutex_unlock(L3); } Now we add 4 processes that run each of these functions separately. Processes A, B, C, and D which run functions func1, func2, func3 and func4 respectively, and such that D runs first and A last. With D being preempted in func4 in the "do something again" area, we have a locking that follows: D owns L3 C blocked on L3 C owns L2 B blocked on L2 B owns L1 A blocked on L1


context:
space:
mode: