1. 09 Jan, 2020 1 commit
  2. 06 Dec, 2019 1 commit
  3. 21 Aug, 2019 1 commit
    • Francois Buergisser's avatar
      hantro: add decoder media device udev rule and hantro · 5544b87f
      Francois Buergisser authored
      The use of the request API with the decoder requires us to open the
      decoder media device in order to create and submit requests. However,
      media devices have the same shortcomings as video devices, in that they
      are just sequentially named media0, media1, ... without any indication
      about which is which.
      This CL identifies the decoder media devices and creates a media-dec0
      symlink to it, similarly to the way we already create a video-dec0
      symlink to the video decoder device. That way Chromium can open the
      correct media device without any hassle.
      This CL also adds the support for Hantro which is the new name for rk3288.
      TEST=Checked that /dev/media-dec0,video-dec,video-dec0 were visible in 4.19
        and checked /dev/video-dec,video-dec0 were visible in 3.14 upon boot.
      Change-Id: Ie6a711b8230f6a99031c87eb9f0a6bfb0b321ccb
      Signed-off-by: default avatarFrancois Buergisser <fbuergisser@chromium.org>
      Reviewed-on: https://chromium-review.googlesource.com/1762093
      Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
      Reviewed-by: default avatarTomasz Figa <tfiga@chromium.org>
  4. 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.
      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>
  5. 14 Apr, 2019 1 commit
  6. 01 Dec, 2018 1 commit
  7. 17 Oct, 2018 1 commit
  8. 02 Feb, 2018 1 commit
  9. 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
      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>
  10. 08 Mar, 2017 1 commit
  11. 24 Sep, 2016 1 commit
  12. 18 Nov, 2015 1 commit
  13. 20 Jul, 2015 1 commit
  14. 07 Jul, 2015 1 commit
  15. 02 Jul, 2015 1 commit
  16. 15 Apr, 2015 1 commit
  17. 11 Apr, 2015 1 commit
  18. 08 Apr, 2015 1 commit
  19. 31 Mar, 2015 1 commit
  20. 19 Mar, 2015 1 commit
  21. 14 Mar, 2015 1 commit
  22. 12 Mar, 2015 1 commit
  23. 10 Mar, 2015 1 commit
  24. 04 Mar, 2015 2 commits
  25. 02 Mar, 2015 1 commit
  26. 30 Jan, 2015 1 commit
  27. 28 Jan, 2015 1 commit
  28. 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.
      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>
  29. 17 Jan, 2015 1 commit
  30. 16 Dec, 2014 1 commit
  31. 05 Dec, 2014 1 commit
  32. 27 Nov, 2014 1 commit
  33. 21 Nov, 2014 1 commit
  34. 04 Sep, 2014 1 commit
  35. 02 Sep, 2014 1 commit
  36. 20 Jun, 2014 1 commit
  37. 19 May, 2014 1 commit