Hi, > > The kernel came up and userspace got to the login prompt, but then > > some issues appeared: > > Okay, that's pretty good given that we haven't had testers for a few > years now. I had some hopes because I saw that NVIDIA still tests new kernel releases on T124 Jetson, although I don't know how much is tested. The kernel seems to be in pretty good shape, save for those issues. I found that graphics are a bigger problem: X is dog slow, and I get black glxgears window and some 150fps, which doesn't look great. Do you know if it's supposed to be like that or if it's a regression or some screwup on my side? I have enabled Nouveau in the kernel and installed X11 Nouveau driver and xorg.log shows that it loads. Are there any other options besides Nouveau? Perhaps some newer L4T release which would work with mainline host1x driver and Kepler? I suppose anything that works on Jetson will work on Nyan too. Currently this machine runs Ubuntu 14.04 L4T and 3.10 CrOS kernel, so practically anything would be an improvement :) >> SPI > > I'm not sure what the right way is to fix this. The values in DT are > clearly required to be nanoseconds, so either the driver needs to > learn about those or the core would need to convert somehow. The core > doesn't know about what the driver supports, so it can't do a really > good job. Maybe a good compromise would be to have the core expose a > helper that can convert to clock cycles (the reverse is already done > in spi_delay_to_ns()), which drivers can then use if they only support > clock cycles. I see that a few other drivers which bother to implement this callback convert ns to clocks, so options would be to copy-paste their code or put that stuff in SPI core. I have never looked at SPI before... > I think LPAE cannot be enabled by default because it would break on > Tegra20 and Tegra30 which both don't support LPAE. Fair enough, it's not a huge deal. > > 3. Some more warnings about bypassed regulators and missing touchpad > > supply (but the touchpad is enabled and works, per evtest at > > least). > > Not sure how much can be done about this. Unless you can find the > schematics we'd probably have to do this on a best effort basis. I actually have the schematic from some shady laptop repair website. IIRC the touchpad runs from some major 3.3V rail which is always on, so I didn't bother fixing this yet. I also learned something new, that platform drivers can ask for their probe to be deferred, which was responsible for some other warnings. At this point I'm not sure if anything serious remains, but regulators are another subsystem I know practically nothing about. > My first step when debugging suspend/resume issues is usually to pass > no_console_suspend on the kernel command-line. That's really only > useful for debugging consoles and it probably doesn't work well if > you've only got the framebuffer console. I made zero progress on this, and frankly didn't even try. Serial ports are only accessible by soldering to the board. I suppose I could try a USB dongle, but it will go dark as soon as xhci is suspended. > > 5. USB is power-cycled on boot, which is a bit annoying as I'm > > booting from a USB connected disk. IIRC CrOS kernel 3.10 wasn't > > doing it. Any suggestions where to look? > > Is this really the power going away and coming back up? In that case > it might be a regulator that's being temporarily disabled during boot > and then brought back up. Yep, this exactly. I have fixed it already. Thanks, Michal
