1. 09 Jan, 2020 1 commit
  2. 06 Dec, 2019 1 commit
  3. 11 May, 2019 1 commit
    • Douglas Anderson's avatar
      veyron: Handle 3.14 vs 4.19 cpufreq differences · ca2baf86
      Douglas Anderson authored
      
      
      On Chrome OS 3.14 we use the (downstream) interactive governor.  On
      Chrome OS 4.19 we are planning to use the schedutil governor.  We'll
      use USE flags to tell which one we're building for.
      
      NOTE: the 'init.cpusets.rc' and 'platform-cpusets.conf' files were
      copied from other people using the schedutil governor, but since we're
      symmetric (all 4 processors are A17) I killed some parts of it, just
      keeping the schedtune stuff.
      
      BUG=chromium:950960
      TEST=Set USE flags, emerge, and cros deploy; look at sysfs files
      Cq-Depend: chromium:1595334
      
      Change-Id: I44f5db58bf4022ad8bc5d1df6173944843e8cb73
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/1597953
      
      
      Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
      Reviewed-by: default avatarSonny Rao <sonnyrao@chromium.org>
      ca2baf86
  4. 14 Apr, 2019 1 commit
  5. 17 Oct, 2018 1 commit
  6. 02 Feb, 2018 1 commit
  7. 30 Oct, 2017 1 commit
    • Douglas Anderson's avatar
      veyron: Disable dwc2 USB autosuspend on boxes · d1fdd5a8
      Douglas Anderson authored
      Autosuspend sorta works on dwc2 but sometimes causes the device to be
      reset.  In some cases this is intentional due to the "remote wakeup"
      problem on the dwc2 host-only port (see the
      "snps,need-phy-full-reset-on-wake" property) but in other cases it
      looks like something about the suspend sequence in dwc2 and/or the PHY
      isn't quite right.
      
      In general Chrome OS doesn't use autosuspend much and it's turned off
      for almost all USB devices.  Notably the only devices that have
      autosuspend enabled are:
      - webcams
      - security keys
      - usb peripherals that are expected to be connected internally
      See power manager's "udev/gen_autosuspend_rules.py"
      
      If we disable autosuspend then the main downside is that security keys
      will take up more power.  That's not so good for laptops, but it's
      unlikely to be a big negative for Chromeboxes.
      
      We'll include this udev rule on any "ac_only" devices.  That will make
      them work a little better with webcams in particular (one of the few
      things you might plug in that had autosuspend turned on).  It's
      unfortunate that we can't do something that would fix everyone with no
      compromises, but this is better than nothing.  If nothing else it's
      not really expected that someone would plug a webcam into their
      laptop.
      
      BUG=b:67983206
      TEST=Logitech webcam enumerates more reliably
      
      Change-Id: I0c29976ab8741003e936b23828fea6dc06e9cc11
      Reviewed-on: https://chromium-review.googlesource.com/740579
      
      
      Commit-Ready: Douglas Anderson <dianders@chromium.org>
      Tested-by: default avatarHeng-ruey Hsu <henryhsu@chromium.org>
      Reviewed-by: default avatarJulius Werner <jwerner@chromium.org>
      d1fdd5a8
  8. 08 Mar, 2017 1 commit
  9. 24 Sep, 2016 1 commit
  10. 20 Jul, 2015 1 commit
  11. 07 Jul, 2015 1 commit
  12. 02 Jul, 2015 1 commit
  13. 15 Apr, 2015 1 commit
  14. 08 Apr, 2015 1 commit
  15. 19 Mar, 2015 1 commit
  16. 14 Mar, 2015 1 commit
  17. 04 Mar, 2015 1 commit
  18. 02 Mar, 2015 1 commit
  19. 30 Jan, 2015 1 commit
  20. 23 Jan, 2015 1 commit
    • Tomasz Figa's avatar
      veyron: Use more general rule for USB camera persist enable · 6a016624
      Tomasz Figa authored
      
      
      The problem with USB on veyron is not related directly to USB camera,
      but rather to one of the USB controllers not handling resume from
      autosuspend correctly. Current workaround enables persist only for
      one particular USB camera recognized by USB vendor and device IDs.
      However it does not take into account potential changes in built-in
      hardware list on the platform, e.g. camera module change or addition of
      extra USB device.
      
      To fix this issue, this patch replaces current udev rule with a more
      general one, which enables persist for all devices on usb3 bus, by
      checking the value of busnum attribute.
      
      BUG=chrome-os-partner:34217
      TEST=cat /sys/devices/ff500000.usb/usb3/3-1/power/persist; camera tested on apprtc
      
      Change-Id: I07a99317b973b053331c71e5a4e880d197c04521
      Signed-off-by: default avatarTomasz Figa <tfiga@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/242210
      
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Commit-Queue: Douglas Anderson <dianders@chromium.org>
      Trybot-Ready: Douglas Anderson <dianders@chromium.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      6a016624
  21. 17 Jan, 2015 1 commit
  22. 05 Dec, 2014 1 commit
  23. 27 Nov, 2014 1 commit
  24. 21 Nov, 2014 1 commit
  25. 04 Sep, 2014 1 commit
  26. 02 Sep, 2014 1 commit
  27. 20 Jun, 2014 1 commit
  28. 19 May, 2014 1 commit
  29. 07 May, 2014 1 commit
  30. 30 Apr, 2014 1 commit
  31. 27 Feb, 2014 1 commit
  32. 20 Dec, 2013 1 commit
  33. 24 Oct, 2013 1 commit