search for: chromeos

...f being probed using the BIOS (which Tegra does not have). >> >> The last patch adds the GK20A clock device. Arguably the clock can be seen as a >> stripped-down version of what is seen on NVE0, however instead of using NVE0 >> support has been written from scratch using the ChromeOS kernel as a basis. >> There are several reasons for this: >> >> - The ChromeOS driver uses a lookup table for the P coefficient which I could >> not find in the NVE0 driver, >> - Some registers that NVE0 expects to find are not present on GK20A (e.g. >> 0x1...

...uld read _nouveau_clock_fini and not _nouveau_clock_init. >> >> The last patch adds the GK20A clock device. Arguably the clock can be seen as a >> stripped-down version of what is seen on NVE0, however instead of using NVE0 >> support has been written from scratch using the ChromeOS kernel as a basis. >> There are several reasons for this: >> >> - The ChromeOS driver uses a lookup table for the P coefficient which I could >> not find in the NVE0 driver, > Interesting. Can you give more details on how "PL" works exactly, > we'd be...

...here really thinks it needs to remain in the tree? Can we hold on a tiny bit so that I can verify we haven't regressed crosvm all the way into mainline? Daniel, is there any chance you could test with kvmtool as well on your setup? You can easily compile it as a static binary and run it from ChromeOS with: lkvm-static run -c 1 -p "earlycon=uart,mmio,0x3f8" -l Image which should start a UP guest and drop you to a shell. In the meantime, I'm starting to build crosvm on my kevin running mainline. Thanks, M. -- Jazz is not dead, it just smell funny.

...here really thinks it needs to remain in the tree? Can we hold on a tiny bit so that I can verify we haven't regressed crosvm all the way into mainline? Daniel, is there any chance you could test with kvmtool as well on your setup? You can easily compile it as a static binary and run it from ChromeOS with: lkvm-static run -c 1 -p "earlycon=uart,mmio,0x3f8" -l Image which should start a UP guest and drop you to a shell. In the meantime, I'm starting to build crosvm on my kevin running mainline. Thanks, M. -- Jazz is not dead, it just smell funny.

...ectly instead of being probed using the BIOS (which Tegra does not have). > > The last patch adds the GK20A clock device. Arguably the clock can be seen as a > stripped-down version of what is seen on NVE0, however instead of using NVE0 > support has been written from scratch using the ChromeOS kernel as a basis. > There are several reasons for this: > > - The ChromeOS driver uses a lookup table for the P coefficient which I could > not find in the NVE0 driver, > - Some registers that NVE0 expects to find are not present on GK20A (e.g. > 0x137120 and 0x137140), >...

...the BIOS (which Tegra does not have). > >> > >> The last patch adds the GK20A clock device. Arguably the clock can be seen as a > >> stripped-down version of what is seen on NVE0, however instead of using NVE0 > >> support has been written from scratch using the ChromeOS kernel as a basis. > >> There are several reasons for this: > >> > >> - The ChromeOS driver uses a lookup table for the P coefficient which I could > >> not find in the NVE0 driver, > >> - Some registers that NVE0 expects to find are not present on GK...

...s to be provided directly instead of being probed using the BIOS (which Tegra does not have). The last patch adds the GK20A clock device. Arguably the clock can be seen as a stripped-down version of what is seen on NVE0, however instead of using NVE0 support has been written from scratch using the ChromeOS kernel as a basis. There are several reasons for this: - The ChromeOS driver uses a lookup table for the P coefficient which I could not find in the NVE0 driver, - Some registers that NVE0 expects to find are not present on GK20A (e.g. 0x137120 and 0x137140), - Calculation of MNP is done diffe...

...;>> have). >>> >>> The last patch adds the GK20A clock device. Arguably the clock can be >>> seen as a >>> stripped-down version of what is seen on NVE0, however instead of using >>> NVE0 >>> support has been written from scratch using the ChromeOS kernel as a >>> basis. >>> There are several reasons for this: >>> >>> - The ChromeOS driver uses a lookup table for the P coefficient which I >>> could >>> not find in the NVE0 driver, >>> - Some registers that NVE0 expects to find...

...rectly instead of being probed using the BIOS (which Tegra does not have). > > The last patch adds the GK20A clock device. Arguably the clock can be seen as a > stripped-down version of what is seen on NVE0, however instead of using NVE0 > support has been written from scratch using the ChromeOS kernel as a basis. > There are several reasons for this: > > - The ChromeOS driver uses a lookup table for the P coefficient which I could > not find in the NVE0 driver, > - Some registers that NVE0 expects to find are not present on GK20A (e.g. > 0x137120 and 0x137140), &gt...

...ot;r" (the_function));  > > > > Other than that, I get the following errors with LLVM+Clang master, and > > my tree at > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb > > > I tried ToT clang with Linux upstream as well as chromeos-4.14, > with 'defconfig'. I don't see any errors when building x86_64. > Lots and lots of warnings, though. The defconfig doesn't build here either; it still includes the cpuidle bits which don't build. I'll update LLVM/clang and try again, in case it was fixed betwee...

...: : > [thunk_target] "r" (the_function)); > > Other than that, I get the following errors with LLVM+Clang master, and > my tree at > http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb > I tried ToT clang with Linux upstream as well as chromeos-4.14, with 'defconfig'. I don't see any errors when building x86_64. Lots and lots of warnings, though. When trying to build for ARCH=i386, I get arch/x86/events/intel/../perf_event.h:767:21: error: invalid output size for constraint '=q' and a clang crash when compiling dri...

...s-is (assuming no objections on reviews here) and rebase my stuff on top. > > The last patch adds the GK20A clock device. Arguably the clock can be seen as a > stripped-down version of what is seen on NVE0, however instead of using NVE0 > support has been written from scratch using the ChromeOS kernel as a basis. > There are several reasons for this: > > - The ChromeOS driver uses a lookup table for the P coefficient which I could > not find in the NVE0 driver, Interesting. Can you give more details on how "PL" works exactly, we'd been operating on the assumpt...

...ints rather than anything else. Besides some > inline comments, I was curious whether it is not necessary to pause PFIFO > and the engines like done with at least NVA3-NVAF? Or is the transition > smooth enough? AFAIK there is no need to pause the engines during a clock transition, as the ChromeOS driver does not do it. > > op 10-07-14 09:34, Alexandre Courbot schreef: > >> Add support for reclocking on GK20A, using a statically-defined pstates >> table. The algorithms for calculating the coefficients and setting the >> clocks are directly taken from the ChromeOS...

...'s the use case for this ? We haven't needed such an ioctl for so long > that it seemed to me that userspace doesn't really need it, but I could be > wrong. > > Sorry, I failed to reference the original email. Here it is: <snip> I am a recent addition to Google's ChromeOS gfx team. I am currently working on display testing and reporting. An important part of this is our screen capture tool, which works by querying drm for crtcs, planes, and fbs. Unfortunately, there is only limited information available via drmModeGetFB(), which often wrong information when drm...

> > this work is based on the virtio_wl driver in the ChromeOS kernel by > Zach Reizner, currently at: > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c > > There's two features missing in this patch when compared with virtio_wl: > > * Allow the guest access directly host memo...

We are trying to enable large file support for everything built for ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version for compatibility with open64. When looking into enabling the large file support flags, I noticed: `void start_progress_meter(const char *, off_t, off_t *);` in progressmeter.h which would have different ABIs with and without large file suppo...

On Wed, 22 Mar 2023, Allen Webb wrote: > We are trying to enable large file support for everything built for > ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version > for compatibility with open64. When looking into enabling the large > file support flags, I noticed: > > `void start_progress_meter(const char *, off_t, off_t *);` > > in progressmeter.h which would have different ABIs wit...

Hello, I have heard that Chrome OS is Linux based, so I am wondering if there is anyway to use R on a Google Chromebook using one of your Linux packages. If not, do you plan on making a version of R that is compatible with chromebooks or cloud based? [[alternative HTML version deleted]]

Chrome OS will soon be adding the chrome.fileSystemProvider[1] API, which would enable the development of a Samba Chrome OS app when used in conjunction with the chrome.sockets.* API or the networking APIs provided by NaCl. Is anyone on this list interested in porting or integrating Samba with Chrome OS? If so, there are two routes we can take: a full JavaScript port, or porting an existing C++

...ain in the tree? > > Can we hold on a tiny bit so that I can verify we haven't regressed > crosvm all the way into mainline? > > Daniel, is there any chance you could test with kvmtool as well on > your setup? You can easily compile it as a static binary and run it > from ChromeOS with: > > lkvm-static run -c 1 -p "earlycon=uart,mmio,0x3f8" -l Image > > which should start a UP guest and drop you to a shell. In the > meantime, I'm starting to build crosvm on my kevin running mainline. OK, that wasn't a fun experience. Some build instruction...