| + darth-cheney (~user@2603-7000-8d00-1f72-0000-0000-0000-1c80.res6.spectrum.com) | 00:04 | |
| mntmn | ephase: cool i am looking forward to it!! | 00:04 |
|---|---|---|
| chartreuse | I'll probably write a review at some point, but want to have some more time with it first. I'm already starting to get used to the keyboard layout, so I stop hitting alt instead of the spacebar and missing the offset A key and homerow | 00:06 |
| chartreuse | Also the purple glow seems to have gone away since loosening the screws. So I'll either have to find some 0.5mm m2 washers or just put some blue threadlocker on the screws in their current tightness | 00:07 |
| chartreuse | Though the stuck pixel still exists, but seems to go away after maybe 10m of use | 00:07 |
| technomancy | the A key was really difficult for me; I ended up removing ctrl and remapping the key between ctrl and A to be the new ctrl | 00:07 |
| technomancy | same with shift and Z | 00:08 |
| chartreuse | A's been the hard one, that 1/4 of a key offset is a bit hard to overcome years of muscle memory. Probably similar to going to an ortholinear board | 00:09 |
| - wagga (QUIT: Ping timeout: 246 seconds) (~wagga@node-1w7jra22ildhv2z6kvjy41v6r.ipv6.telus.net) | 00:10 | |
| technomancy | yeah but at least an ortho board follows the direction of your fingers | 00:10 |
| chartreuse | Z hasn't been quite as bad, though yeah the non-standard layout is a bit of work. The key to the left of Z isn't terrible as ISO layout keyboards have a key there and I've used a few laptops with that before | 00:10 |
| technomancy | I think the bottom row stagger might be my least favorite feature of this machine | 00:11 |
| mntmn | hm! | 00:12 |
| technomancy | I guess that sounds worse than it really is | 00:12 |
| technomancy | because I love everything else about it, haha | 00:12 |
| mntmn | well, one could try to make a more traditional keyboard, but it would require more keyshapes... at least one more i think | 00:12 |
| technomancy | well, more traditional isn't really what I personally want. =) | 00:13 |
| mntmn | i can say i myself am a touch typist and i totally got used to it, but obvs i am at an advantage in terms of how much time i had to adapt to it | 00:13 |
| mntmn | also i use our standalone usb keyboard on my desktop machine in the office, so i don't really have any more traditional keyboards around... | 00:14 |
| technomancy | but if you're going to make the bottom row be 1/4u off of a conventional layout, you might as well put it directly below the middle row and have no offset at all | 00:14 |
| mntmn | hm! | 00:14 |
| mntmn | you mean Z under A? | 00:14 |
| technomancy | in either case you're 1/4u away from what people expect, and one direction has lots of stagger and the other is straight for your fingers | 00:14 |
| technomancy | yeah | 00:14 |
| mntmn | interesting | 00:14 |
| mntmn | that wouldn't be too hard to prototype, but idk how that feels. | 00:15 |
| mntmn | i did this in part because the SX-64 did it | 00:15 |
| mntmn | (maybe the plus 4 too?) | 00:15 |
| mntmn | and nobody ever complained about it | 00:15 |
| technomancy | well, I probably would have, haha | 00:15 |
| technomancy | ACTION is annoying like that | 00:15 |
| mntmn | here: https://www.nightfallcrew.com/wp-content/gallery/commodore-sx-64-keyboard-repair-cleaning/20181209_125925.jpg | 00:16 |
| technomancy | not sure you can trust the judgement whoever made this; it has a caps lock key =) | 00:17 |
| + wagga (~wagga@node-1w7jra22ildhv9tkri23jpmvy.ipv6.telus.net) | 00:17 | |
| chartreuse | At that point maybe just go with an ortholinear | 00:17 |
| chartreuse | Which someone is already making | 00:17 |
| technomancy | chartreuse: I mean, yes, but I didn't want to push too hard on that =) I understand there are already so many hurdles for people who are considering buying a reform. | 00:18 |
| technomancy | one other consideration; do other folks find the 1u keys right above the trackball easy to hit? I feel like the metal frame gets in the way when I try to hit them with a straight thumb. | 00:19 |
| chartreuse | I find them a little hard to hit, both the spacebar and alt, but I've adjusted my hand resting position to not lay so flat against the laptop. I think the spacebar and alt could benefit with some convex caps on it | 00:21 |
| technomancy | it's funny; the 1.5u keys I have no trouble with. maybe because I have to bend my thumbs to hit them anyway. | 00:22 |
| chartreuse | I've only got a FDM printer so I'd be a bit worried printing my own and having the small mounts break off, but might be worth a test | 00:22 |
| technomancy | I'm kinda tempted to just remove the outer frame | 00:22 |
| chartreuse | I feel not having it would allow way more dirt into the case than already happens | 00:23 |
| technomancy | but it's so easy to get it out again, haha | 00:24 |
| chartreuse | I'm thinking of making some blocking pieces to stop dirt from going down into the bottom, as I have a dog and hair tends to get in | 00:24 |
| chartreuse | True | 00:24 |
| chartreuse | Though it's very visible on the acrylic what with the bright white leds under | 00:24 |
| mntmn | i am also thinking about redesigning the frame | 00:24 |
| mntmn | i would like the part between alt/space and trackball to be lower/deeper and not be such a barrier there. but this works only with the trackball, not with the trackpad. | 00:25 |
| mntmn | so it could be an alternative frame. | 00:25 |
| technomancy | oh yeah, that makes sense | 00:25 |
| chartreuse | Perhaps if you add a depression about the trackball, tapering from the sides of the spacebars | 00:25 |
| mntmn | so, this i def. understand | 00:25 |
| mntmn | yeah, something like that | 00:26 |
| technomancy | also I want to emphasize that I'm nit-picking and this is the best machine I've used by a significant margin =) | 00:26 |
| technomancy | and I love that we can discuss potential improvements | 00:26 |
| chartreuse | Ordered some 1.5mm chrome steel ball bearings from China, so I'll probably try that trackball mod out. Right now it sometimes sticks when scrolling upward, so more smoothness would be nice | 00:27 |
| chartreuse | I do like the accuracy of it though, seems to be very responsive | 00:27 |
| mntmn | chartreuse: cool, looking forward to your experience | 00:27 |
| mntmn | yes the sensor is really really good | 00:27 |
| mntmn | technomancy: haha ok! i also appreciate this honest feedback, it is good to know where pain points are. | 00:28 |
| chartreuse | I imagine there'll be some differences in the mod since the person who did it before had the trackball with the SLA printed shell but I have a FDM shell. | 00:28 |
| chartreuse | Which is fine, I could even print my own replacements for it if I mess up | 00:28 |
| mntmn | chartreuse: ah, i see. in general i think the FDM shell is actually better | 00:28 |
| mntmn | with the SLA the ball gets stuck more | 00:29 |
| chartreuse | Is the FDM shell printed in PLA or ABS or something else? | 00:29 |
| mntmn | PLA | 00:29 |
| chartreuse | I'm really only set up to do PLA so that's perfect. I can see about modifying it to take the bearing directly rather than drilling it | 00:29 |
| chartreuse | Maybe make it in some bright colour or such :P | 00:29 |
| technomancy | I've been rocking a kailh choc white switch on my trackball button for like a week now and it's great; highly recommended if you're looking for a mod to do | 00:30 |
| mntmn | chartreuse: yes, agreed | 00:30 |
| mntmn | chartreuse: i would also modify the model | 00:30 |
| mntmn | technomancy: ah yeah cool | 00:30 |
| chartreuse | I quite like the browns on the trackball. Though on the keyboard they feel more like linears/reds to me than tactile | 00:30 |
| - ephase (QUIT: Read error: Connection reset by peer) (~ephase@2a01:e0a:168:1211::885) | 00:31 | |
| chartreuse | I guess even on the trackball they do as well, I was honestly expecting more tactility. But I quite like linear switches as well, my desktop keyboard uses Cherry Red's | 00:31 |
| mntmn | we will probably do more switch variations on keyboards once the standalone keyboard takes off | 00:32 |
| mntmn | right now there's not enough budget to make too many versions | 00:32 |
| chartreuse | And it's nice in that it's not too loud, so I wouldn't really be disturbing anyone that much with heavy trying in a public quiet space | 00:32 |
| technomancy | glad to hear it. the whites are amazing but I understand the logistical difficulties. | 00:32 |
| mntmn | haha yes that was a consideration as well | 00:32 |
| mntmn | yeah i like the whites too | 00:32 |
| chartreuse | Oh no worries, I understand that financials are probably tight with this project. Especially if the chip shortage starts effecting future boards | 00:33 |
| technomancy | I know from experience that the more options you have the more things that can go wrong. I'm impressed just getting blank caps was offered. | 00:33 |
| mntmn | yeah, all about this project is extremely tight | 00:33 |
| mntmn | we even wanted to do an ortholinear keyboard option in the beginning. was scrapped because of complexity | 00:34 |
| technomancy | sad but understandable | 00:34 |
| chartreuse | I'm just impressed that the kit could be made with all these custom boards and milled aluminum and fit in the budget. | 00:34 |
| technomancy | plus like ... that's the whole point that you can replace it later! | 00:34 |
| mntmn | yeah! | 00:34 |
| chartreuse | I'm just wanting to get somewhat comforatble with how it is right now before diving into modding | 00:35 |
| mntmn | makes perfect sense | 00:35 |
| technomancy | mntmn: what's the relative scale of the reform 1 sales to reform 2? did you have a campaign for the first one? | 00:35 |
| mntmn | hehe | 00:35 |
| mntmn | 10 vs 450 | 00:36 |
| chartreuse | There was a few beta units sold directly on the website. I was tempted but decided it'd be better if I waited | 00:36 |
| mntmn | ah wait sales not really, we sold a bit more than 300 yet i think | 00:36 |
| technomancy | haha wow | 00:36 |
| mntmn | yeah i think 13 beta units of 2 were built | 00:36 |
| mntmn | we have/had inventory for ~450 units of reform 2. | 00:36 |
| chartreuse | Though those had the slower processor in them | 00:36 |
| mntmn | the betas had the same cpu | 00:37 |
| mntmn | we had basically 3 runs. 10 reform 1.0 which was totally different with imx6, 13 reform 2.0 beta, very similar to the final one | 00:37 |
| chartreuse | Oh I must have been thinking about an earlier one, maybe alphas? There were two different cpu options, and I think it was the imx6 | 00:37 |
| mntmn | yes, we call them 1.0 internally, the imx6 one | 00:37 |
| mntmn | imx6qp | 00:37 |
| chartreuse | Ah okay, yeah those were the ones I saw first, and had to wait a year for the crowdsupply to finally start :) | 00:38 |
| mntmn | yeah ^^ the prep took forever | 00:38 |
| chartreuse | Glad I waited, this 2.0 version is much more polished | 00:38 |
| chartreuse | The speakers also sound great, though a downside is they're not very loud and can clip/vibrate quite easily near and above 0db volume (79%) | 00:41 |
| chartreuse | Might look into what options I could fit into the screen area | 00:41 |
| mntmn | yeah... another options would be to put bigger speakers in the lower case | 00:43 |
| mntmn | option | 00:43 |
| mntmn | the 1.0 didn't have any speakers ^^ | 00:44 |
| technomancy | honestly I respect that | 00:45 |
| technomancy | just like the microphone; if you need it, you use a headset | 00:45 |
| chartreuse | Yeah, I'm tempted to add a "subwoofer" to the base. | 00:48 |
| chartreuse | True, but I like to have some videos or music playing with the laptop sitting around at home, yeah I've got an external speaker I can connect it to, but sometimes I'm just lazy in bed or such | 00:48 |
| swivel | the small Creative Pebble usb-powered speakers have impressed me for what they area, I tend to use them more than my proper stereo and they're cheap+compact enough to leave laying around on a counter or night stand, no internal laptop speakres would ever compare | 00:52 |
| swivel | $19.99 right now apparently https://us.creative.com/p/speakers/creative-pebble | 00:54 |
| chartreuse | I'm also impressed with the batteries. Seems to be fairly good battery life even with the screen at full brightness, and charges super fast | 00:58 |
| chartreuse | It's not super long compared with some modern laptops at the moment but still quite good. Right now I'm drawing 0.3 so up to 6hr at the moment. Probably some optimizations with the nvme ssd I could do and other such | 01:00 |
| technomancy | it's a step up from my thinkpad x301 | 01:01 |
| - chartreuse (QUIT: Ping timeout: 258 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 01:18 | |
| - darth-cheney (QUIT: Remote host closed the connection) (~user@2603-7000-8d00-1f72-0000-0000-0000-1c80.res6.spectrum.com) | 01:29 | |
| - mjw (QUIT: Quit: Leaving) (~mark@herd.wildebeest.org) | 02:04 | |
| bluerise | [*]-Video Link 0probe video device failed, ret -38 | 02:34 |
| bluerise | [0] display-controller@32e00000, video | 02:34 |
| bluerise | [1] mipi-dsi@30a00000, dsi_host | 02:34 |
| bluerise | [2] sn65dsi86@2c, video_bridge | 02:34 |
| bluerise | [3] panel, panel | 02:34 |
| bluerise | slooowly | 02:34 |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 03:32 | |
| chartreuse | Did a tiny mod. Took some rubylith tape I had and covered all the leds on the mainboard. Gives a much nicer deep red glow and not so bright | 03:45 |
| - chartreuse (QUIT: Ping timeout: 272 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:03 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:03 | |
| - chartreuse (QUIT: Client Quit) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:07 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:08 | |
| - chartreuse (QUIT: Client Quit) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:09 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:10 | |
| - chartreuse (QUIT: Client Quit) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:12 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 05:15 | |
| jackhill | chartreuse: neat, that's a clever idea, I might try it. | 05:21 |
| jackhill | thanks for sharing | 05:22 |
| chartreuse | Rubylith tape is probably a bit expensive, but really any deep tinted tape would help to cut down the leds | 05:22 |
| chartreuse | I had it because I was using it to filter some red led strips to work as a darkroom safelight | 05:22 |
| jackhill | chartreuse: yeah, I'm thinking of trying for a nice green anyway. | 05:26 |
| jackhill | I'm not a sticker person, but would like to personalize my reform a little too | 05:27 |
| chartreuse | It's an easy way without desoldering the leds and changing the resitors since they're tiny 0603 parts | 05:28 |
| jackhill | yeah :) | 05:29 |
| ex-parrot | A thing I still have been too lazy to work out is whether the red “charging” LED is intended to go out at any point | 06:07 |
| ex-parrot | I always wanted to get some real rubylith, interesting to hear it still exists | 06:07 |
| chartreuse | I think it's just always on while a charger is connected. It doesn't go off when the display reads 0A | 06:09 |
| chartreuse | Presumably when fully charged the laptop is running off the external supply instead of the batteries as the current meter is showing 0.00A | 06:10 |
| chartreuse | You can still get the sheets of rubylith, and 3M makes ruby tape for doing litho masks and such | 06:10 |
| chartreuse | I got my roll of the tape from Digikey | 06:10 |
| ex-parrot | Neat | 06:53 |
| ex-parrot | Yeah I observed the 0 amps charging current and I figured it must be “done” | 06:53 |
| ex-parrot | I kind of like the malevolent underglow | 06:53 |
| - chartreuse (QUIT: Ping timeout: 258 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 07:48 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 07:57 | |
| + chartreu1e (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 07:59 | |
| ex-parrot | Anyone have a pointer to any recent OpenBSD porting status? | 08:13 |
| ex-parrot | looks like bluerise is the person to ask | 08:16 |
| - chartreuse (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:45 | |
| - chartreu1e (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:45 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:46 | |
| - chartreuse (QUIT: Remote host closed the connection) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 09:33 | |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 09:33 | |
| - chartreuse (QUIT: Ping timeout: 252 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 10:06 | |
| - kklimonda (QUIT: Ping timeout: 245 seconds) (sid72883@user/kklimonda) | 11:45 | |
| + kklimonda (sid72883@user/kklimonda) | 11:46 | |
| - ex-parrot (QUIT: Ping timeout: 245 seconds) (~fincham@user/ex-parrot) | 11:48 | |
| + ex-parrot (~fincham@user/ex-parrot) | 11:48 | |
| - verx_ (QUIT: Read error: Connection reset by peer) (~verx@asm.16bit.dev) | 11:49 | |
| - ggoes (QUIT: Ping timeout: 256 seconds) (~gregf@fsf/staff/ggoes) | 11:49 | |
| + verx (~verx@asm.16bit.dev) | 11:50 | |
| - jnerula (QUIT: Ping timeout: 272 seconds) (~jnerula@li1009-93.members.linode.com) | 11:53 | |
| - mntmn (QUIT: Ping timeout: 252 seconds) (~mntirc@softboy.mntmn.com) | 11:58 | |
| - blast007 (QUIT: Remote host closed the connection) (~blast@user/blast007) | 12:00 | |
| - frank2 (QUIT: Ping timeout: 256 seconds) (~frank@91.229.143.153) | 12:00 | |
| + frank2 (~frank@91.229.143.153) | 12:01 | |
| + blast007 (~blast@user/blast007) | 12:05 | |
| + mntmn (~mntirc@softboy.mntmn.com) | 12:05 | |
| - frank2 (QUIT: Ping timeout: 256 seconds) (~frank@91.229.143.153) | 12:06 | |
| + frank2 (~frank@91.229.143.153) | 12:06 | |
| + jnerula (~jnerula@li1009-93.members.linode.com) | 12:08 | |
| + ggoes (~gregf@fsf/staff/ggoes) | 12:11 | |
| bluerise | ex-parrot: sup | 13:15 |
| + erlehmann (~erle@dynamic-046-114-034-077.46.114.pool.telefonica.de) | 13:23 | |
| - adjtm (QUIT: Read error: Connection reset by peer) (~adjtm@13.red-88-1-141.dynamicip.rima-tde.net) | 14:24 | |
| + adjtm (~adjtm@13.red-88-1-141.dynamicip.rima-tde.net) | 14:26 | |
| mntmn | bluerise: that log output was openbsd? | 15:14 |
| - qbit (QUIT: Quit: WeeChat 3.2) (~qbit@foof.suah.dev) | 15:58 | |
| + qbit (~qbit@foof.suah.dev) | 16:20 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 16:53 | |
| - Kooda (QUIT: Ping timeout: 276 seconds) (~kooda@natsu.upyum.com) | 17:10 | |
| bluerise | mntmn: u-boot | 17:32 |
| bluerise | u-boot mainline + patches | 17:33 |
| bluerise | still not there yet | 17:33 |
| bluerise | hdmi would be easier, but the output pipeline for the reform + boundary devices code doesn't work easily | 17:33 |
| mntmn | ah! how is it going? | 17:33 |
| bluerise | so I'm debugging as I go | 17:33 |
| mntmn | internal display is 10x more interesting though!! | 17:33 |
| bluerise | yeah, fuck HDMI ;) | 17:34 |
| bluerise | nw_dsi_imx mipi-dsi-bridge: failed to enable mipi dsi host | 17:34 |
| bluerise | imx8m_dcss display-controller@32e00000: fail to set backlight | 17:34 |
| bluerise | device_probe:590 | 17:34 |
| bluerise | device_probe:611: failed display-controller@32e00000 | 17:34 |
| bluerise | probe video device failed, ret -22 | 17:35 |
| bluerise | that's where I'm currently at | 17:35 |
| bluerise | getting closer and closer | 17:35 |
| bluerise | mntmn: how many lanes to the sn65dsi86? 4 lanes? | 17:40 |
| bluerise | yes yes, I can probably check in kicad... | 17:40 |
| bluerise | patrick@lx2k:~$ doas pkg_add kicad | 17:41 |
| mntmn | bluerise: why does backlight fail? | 17:45 |
| mntmn | bluerise: that should be just 1 pwm output + 1 enable gpio | 17:46 |
| mntmn | bluerise: 4 DSI lanes. | 17:46 |
| bluerise | because the code that does the backlight seems to also turn DSI host on | 17:46 |
| bluerise | layers of layers of bullcrap ;) | 17:47 |
| mntmn | ah. | 17:47 |
| bluerise | so it thinks backlight on failed, but it was something else | 17:47 |
| mntmn | oof | 17:47 |
| bluerise | device_probe:611: failed usb_kbd | 17:48 |
| bluerise | also that | 17:48 |
| + alex4nder (~alexander@74.51.16.139) | 17:49 | |
| mntmn | bluerise: eek | 17:49 |
| mntmn | i remember i could not get usbkbd to work in u-boot but it worked in RISCOS ;) | 17:50 |
| mntmn | and in genode of course | 17:50 |
| - alex4nder (QUIT: Ping timeout: 240 seconds) (~alexander@74.51.16.139) | 17:53 | |
| + alex4nder (~alexander@74.51.16.139) | 17:54 | |
| + Kooda (~kooda@natsu.upyum.com) | 18:03 | |
| bluerise | now it hangs somewhere, maybe the PWM stuff | 18:05 |
| bluerise | because the u-boot imx driver is not really built with clock device model in mind, lala | 18:06 |
| - alex4nder (QUIT: Ping timeout: 250 seconds) (~alexander@74.51.16.139) | 18:06 | |
| + alex4nder (~alexander@172.56.42.189) | 18:08 | |
| bluerise | ah yeah | 18:09 |
| mntmn | FYI everyone whose speakers are too quiet: https://community.mnt.re/t/speakers-too-quiet-try-this/375 | 18:10 |
| bluerise | ah nice | 18:11 |
| bluerise | panel is on | 18:11 |
| bluerise | I mean, backlight | 18:11 |
| mntmn | bluerise: yeah!! | 18:12 |
| bluerise | ok, let's try to add that stuff from theat community thread | 18:12 |
| bluerise | looks like I have link to the panel? | 18:31 |
| bluerise | but I don't see a color bar | 18:31 |
| bluerise | I think I found the knob for usb... | 18:33 |
| bluerise | ok, USB keyboard works | 18:36 |
| bluerise | nice | 18:36 |
| bluerise | + "stdin=serial,usbkbd\0" \ | 18:36 |
| bluerise | this helps. | 18:36 |
| bluerise | mntmn: didn't you say there's a know that changed where mipi sources stuff from? | 18:37 |
| mntmn | bluerise: yes | 18:41 |
| mntmn | bluerise: but you don't need that for color bars | 18:41 |
| mntmn | i think. did you give the "run" or something command after enabling the color bars? | 18:42 |
| bluerise | yeah | 18:44 |
| mntmn | mux-reg-masks = <0x34 0x00000004>; /* MIPI_MUX_SEL */ | 18:47 |
| mntmn | reg = <0x30340000 0x10000>; | 18:47 |
| mntmn | so that should be 0x30340034 | 18:47 |
| mntmn | ah yeah that is in the manual under 8.2.4.14 GPR13 General Purpose Register (IOMUXC_GPR_GPR13) | 18:48 |
| mntmn | a bit hidden. | 18:48 |
| mntmn | it's bit 2 in that register | 18:49 |
| mntmn | bluerise: bit 2 set (1) means DCSS, bit 2 unset (0) means LCDIF | 18:50 |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 18:53 | |
| bluerise | clock-frequency = <162000000>; | 18:53 |
| bluerise | hactive = <1920>; | 18:53 |
| bluerise | vactive = <1080>; | 18:53 |
| bluerise | hback-porch = <40>; | 18:53 |
| bluerise | hfront-porch = <40>; | 18:53 |
| bluerise | vback-porch = <4>; | 18:53 |
| bluerise | vfront-porch = <4>; | 18:53 |
| bluerise | hsync-len = <80>; | 18:53 |
| bluerise | vsync-len = <24>; | 18:54 |
| bluerise | that correct for the panel? | 18:54 |
| bluerise | mostly concerend about hsync/vsync-len | 18:54 |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 18:54 | |
| bluerise | front/back porch seem to be right (compared to the i2c commands that were in the forum thread) | 18:54 |
| bluerise | "Using DCSS as input source | 18:54 |
| bluerise | mux should be set correctly, ok | 18:55 |
| mntmn | one second | 18:55 |
| mntmn | +static const struct drm_display_mode innolux_n125hce_gn1_mode = { | 18:55 |
| mntmn | +.clock = 162000, | 18:55 |
| mntmn | +.hdisplay = 1920, | 18:55 |
| mntmn | +.hsync_start = 1920 + 40, | 18:56 |
| mntmn | +.hsync_end = 1920 + 40 + 40, | 18:56 |
| mntmn | +.htotal = 1920 + 40 + 40 + 80, | 18:56 |
| mntmn | +.vdisplay = 1080, | 18:56 |
| mntmn | +.vsync_start = 1080 + 4, | 18:56 |
| mntmn | +.vsync_end = 1080 + 4 + 4, | 18:56 |
| mntmn | +.vtotal = 1080 + 4 + 4 + 24, | 18:56 |
| mntmn | +}; | 18:56 |
| bluerise | yup. so that htotal/vtotal thing is active + back + front + len? | 18:56 |
| mntmn | i would think so yes | 18:57 |
| mntmn | do you get a DP link to the display? | 18:57 |
| bluerise | yeah, I think so | 19:00 |
| bluerise | otherwise I'd see an error message like I did before, heh | 19:00 |
| mntmn | hm yeah | 19:00 |
| bluerise | anything special like hsync/vsync active high/low? | 19:01 |
| mntmn | there is a weird hack about that in the nwl-dsi driver, one moment | 19:01 |
| bluerise | ah | 19:03 |
| bluerise | reform2-imx8mq/template-kernel/patches/0001-nwl-dsi-fixup-mode-only-for-LCDIF-input-not-DCSS.patch | 19:03 |
| bluerise | that? | 19:03 |
| mntmn | yeah, the linux nwl-dsi driver by default inverts hsync/vsync | 19:03 |
| mntmn | and i had to turn that hack off for it to work with dcss | 19:04 |
| mntmn | i don't know if the u-boot driver also has this hack | 19:04 |
| bluerise | /* | 19:04 |
| bluerise | * Adjusting input polarity based on the video mode results in | 19:04 |
| bluerise | * a black screen so always pick active low: | 19:04 |
| bluerise | * (and polarity active high in LCDIF) | 19:04 |
| bluerise | */ | 19:04 |
| bluerise | nwl_dsi_write(dsi, NWL_DSI_VSYNC_POLARITY, | 19:04 |
| bluerise | NWL_DSI_VSYNC_POLARITY_ACTIVE_LOW); | 19:04 |
| bluerise | /* | 19:04 |
| bluerise | * Our dsi-rgb converter needs 0 regardless of input polarity | 19:04 |
| bluerise | */ | 19:04 |
| bluerise | nwl_dsi_write(dsi, NWL_DSI_HSYNC_POLARITY, | 19:04 |
| mntmn | tehe | 19:04 |
| bluerise | NWL_DSI_HSYNC_POLARITY_ACTIVE_LOW); | 19:04 |
| mntmn | well. | 19:05 |
| mntmn | you could try turning that around, i lost track of who likes the polarity how | 19:06 |
| mntmn | i'd say try active high | 19:06 |
| mntmn | for both | 19:06 |
| bluerise | will try. thought active low is the default | 19:06 |
| mntmn | ok | 19:07 |
| mntmn | ah yeah active low is probably right | 19:07 |
| bluerise | hmhmhm | 19:11 |
| bluerise | I'm surprised the color bars don't work | 19:11 |
| mntmn | yeah, strange. is your pixel clock working? | 19:11 |
| bluerise | how would I know? | 19:12 |
| mntmn | haha. good Q. but actually not a lot of input to the converter chip should be needed to get the bars to appear | 19:13 |
| mntmn | mostly display timing, edp pll lock, and run | 19:14 |
| bluerise | 25000000 1 | `-- video_pll1_ref_sel | 19:15 |
| bluerise | 5000000 0 | |-- video_pll1_ref_div | 19:15 |
| bluerise | 650000000 0 | | `-- video_pll1 | 19:15 |
| bluerise | seems a bit off, didn't you want that at 594? | 19:15 |
| bluerise | 25000000 0 | |-- dc_pixel | 19:16 |
| bluerise | 25000000 2 | `-- dsi_phy_ref | 19:16 |
| mntmn | yes video_pll1 1 1 0 593999998 0 0 50000 Y | 19:16 |
| bluerise | get_pixclock: 648000000 = 162000000 * 4 | 19:17 |
| bluerise | Enabled core clk @266666666 Hz | 19:17 |
| bluerise | Enabled tx_esc clk @20000000 Hz | 19:17 |
| bluerise | clock = 162000000 kHz | 19:17 |
| bluerise | kHz? :D | 19:17 |
| bluerise | maybe the print is wrong | 19:17 |
| mntmn | haha | 19:17 |
| mntmn | 162 ghz... | 19:17 |
| mntmn | video_pll1_out 3 3 0 593999998 0 0 50000 Y | 19:18 |
| mntmn | dsi_phy_ref 1 1 0 23760000 0 0 50000 Y | 19:18 |
| mntmn | lcdif_pixel 1 1 0 593999998 0 0 50000 Y | 19:18 |
| mntmn | dc_pixel 1 1 0 118800000 0 0 50000 Y | 19:18 |
| bluerise | does lcdif need to be the same for dcss? | 19:18 |
| bluerise | / LCDIF is not used, but has to be active or DCSS won't work | 19:18 |
| bluerise | hmhm | 19:19 |
| mntmn | oh yeah! | 19:19 |
| mntmn | there was some weirdness that lcdif cannot be powered down i think | 19:19 |
| mntmn | maybe same power domain or something weird | 19:19 |
| mntmn | bluerise: oh yeah i remember why my numbers are off. | 19:23 |
| mntmn | bluerise: because i throttle the pixel clock with a factor to work around some DSI glitch. this shouldn't affect you though | 19:24 |
| mntmn | bluerise: i do clk_set_rate(dcss->pix_clk, (vm->pixelclock * 700)/1000); | 19:26 |
| mntmn | bluerise: but you don't need to do that. | 19:26 |
| mntmn | bluerise: so if you type in these i2c commands, it doesn't work? https://community.mnt.re/t/u-boot-and-internal-screen/295/10 | 19:29 |
| bluerise | I'm doing these programmatically already | 19:29 |
| mntmn | and you're doing the same stuff, and you got pll confirmation and link training confirmation? | 19:30 |
| mntmn | you can probably get some more status information out of the converter and the display | 19:31 |
| bluerise | oh | 19:32 |
| bluerise | now I see colours | 19:32 |
| mntmn | ha! | 19:32 |
| mntmn | how? | 19:32 |
| bluerise | I typed them in manually again | 19:32 |
| mntmn | aha! | 19:32 |
| mntmn | maybe some delays are missing in the code or something? | 19:33 |
| mntmn | or it is done too early? | 19:33 |
| bluerise | well at what point should it be initialized? | 19:34 |
| bluerise | last? | 19:34 |
| mntmn | hmm yeah. | 19:35 |
| bluerise | maybe it lost link inbetween | 19:38 |
| bluerise | very weird | 19:38 |
| mntmn | but now you know it almost works! | 19:39 |
| bluerise | not sure, if I disable colour bars, it's still black ;) | 19:40 |
| mntmn | well, what else should be there? do you have anything in the framebuffer? | 19:41 |
| bluerise | ah, probably need a delay there, 1s | 19:42 |
| bluerise | there should be u-boot printfs | 19:42 |
| mntmn | can you monitor somehow that dcss is still runnin? i.e. its IRQ | 19:43 |
| bluerise | If | 19:43 |
| mntmn | it has this kick/load irq that needs to run every frame | 19:43 |
| bluerise | * the panel isn't ready quite it might respond NAK here which means | 19:43 |
| bluerise | * we need to try again. | 19:43 |
| bluerise | ahhh. | 19:43 |
| mntmn | :O | 19:43 |
| bluerise | huh, really? | 19:44 |
| mntmn | really what? | 19:45 |
| mntmn | about the irq? yes | 19:45 |
| mntmn | the engine works like that, an irq is fired every frame and it triggers the loading of the next frame | 19:45 |
| mntmn | it's called context loader i think | 19:45 |
| bluerise | ok, now I can reproducibly turn it on | 19:50 |
| mntmn | that's good! | 19:50 |
| mntmn | do you have a repo with this state somewhere? | 19:50 |
| bluerise | github.com/bluerise/u-boot branch mntre-disp2 | 19:53 |
| bluerise | I need to clean up the last 5-10 commits | 19:53 |
| bluerise | lots of debugging | 19:53 |
| mntmn | that's fine | 19:55 |
| bluerise | cleaning that up isn't hard, I just want something working... | 19:56 |
| bluerise | and I'm trying to have reasonable cherry-pick + some fixes and 'okayish' commits on top | 19:56 |
| bluerise | anyway, with that I get colour bars | 19:56 |
| mntmn | yes, cool | 19:59 |
| mntmn | dumb question but you have stdout=vga,serial yeah? | 19:59 |
| bluerise | stdout=serial,vidconsole | 20:00 |
| bluerise | hm, let me try vga then? | 20:00 |
| mntmn | hmm i had to use vga with hdmi | 20:00 |
| mntmn | which is also dcss | 20:00 |
| mntmn | can you printf the framebuffer address? | 20:01 |
| mntmn | then you could read and write pixels with memory commands | 20:01 |
| bluerise | vga is legacy btw | 20:03 |
| bluerise | This is a work-around for boards which have 'lcd' or 'vga' in their | 20:03 |
| bluerise | stdout environment variable, but have moved to use driver model for | 20:03 |
| bluerise | video. In this case the console will no-longer work. While it is | 20:03 |
| bluerise | possible to update the environment, the breakage may be confusing for | 20:03 |
| bluerise | users. This option will be removed around the end of 2020. | 20:03 |
| mntmn | yeah | 20:07 |
| bluerise | hm, nothing shows | 20:09 |
| bluerise | and u-boot is definitely using the framebuffer | 20:10 |
| mntmn | do you have the address? | 20:14 |
| mntmn | ok | 20:14 |
| bluerise | yes | 20:15 |
| bluerise | writing three changes nothing | 20:15 |
| bluerise | but when I type something in u-boot, it gets overwritten back | 20:15 |
| bluerise | so scrolling seems to work ;) | 20:16 |
| mntmn | nice | 20:17 |
| mntmn | can you confirm that bit 2 is set in 0x30340034 ? | 20:17 |
| mntmn | via md | 20:17 |
| mntmn | also, hsync/vsync still active low? ;) | 20:18 |
| mntmn | and next thing i would check if dcss's interrupt is running... | 20:18 |
| bluerise | there's no interrupt in u-boot | 20:19 |
| bluerise | u-boot=> md.l 0x30340034 1 | 20:19 |
| bluerise | 30340034: 00000004 .... | 20:19 |
| mntmn | ok, that's good... but how can dcss work without an interrupt | 20:20 |
| mntmn | let me check the driver | 20:20 |
| mntmn | hm no first i should check if there's any status info available in sn65dsi86 about the validity of the mipi dsi input | 20:22 |
| mntmn | bluerise: error registers 0xf0, 0xf1 look valuable | 20:24 |
| mntmn | actually 0xf0-0xf8 | 20:25 |
| bluerise | u-boot=> i2c md 2c f0 8 | 20:25 |
| bluerise | 00f0: 00 00 00 00 41 02 00 01 ....A... | 20:25 |
| mntmn | ok lets see | 20:25 |
| bluerise | hmu-boot=> i2c md 2c f0 9 | 20:26 |
| bluerise | 00f0: 00 00 00 00 41 02 00 01 03 ....A.... | 20:26 |
| bluerise | forgot f8 in the last one | 20:26 |
| mntmn | ah yeah | 20:26 |
| mntmn | 0xf4 is irrelevant i think, aux channel stuff | 20:27 |
| mntmn | 0x2 in 0xf5 says HPD_INSERTION | 20:27 |
| mntmn | so, display is plugged in ;) | 20:27 |
| mntmn | 0x1 in 0xf7 says DPTL_DATA_UNDERRUN_ERR | 20:28 |
| mntmn | > This field is set whenever no data was received when data should | 20:28 |
| mntmn | have been ready | 20:28 |
| mntmn | 03 in 0xf8 shouldn't be possible, it means both LT_FAIL and LT_PASS | 20:29 |
| mntmn | but that's about display link training | 20:29 |
| mntmn | i think the main interesting bit here is that you don't seem to be getting MIPI DSI packets. | 20:29 |
| bluerise | DP sounds like display port | 20:29 |
| mntmn | hmm no i don't think so | 20:30 |
| mntmn | DPTL is not explained but there is for example > DPTL_UNEXPECTED_DATA_ERR. This field is set whenever a data token at in the video stream from | 20:30 |
| mntmn | DSI was found at an invalid time syntactically. | 20:30 |
| mntmn | so, this is about DSI | 20:30 |
| mntmn | we should check if mixel dphy has any status things | 20:31 |
| mntmn | bluerise: dphy is on yes? | 20:32 |
| - alex4nder (QUIT: Ping timeout: 256 seconds) (~alexander@172.56.42.189) | 20:35 | |
| bluerise | ich hab ne bloede Idee | 20:39 |
| mntmn | bluerise: i would maybe check if nwl_dsi_host_transfer is called | 20:39 |
| bluerise | maybe it's the lcdif clock that isn't running | 20:39 |
| mntmn | hmm yeah! | 20:39 |
| bluerise | because I'm using dcss and there's no driver attaching to lcdif | 20:40 |
| bluerise | patching the dcss block to also reference the lcdif clock | 20:40 |
| bluerise | ah nah, it's there, but maybe not assigned, let's try | 20:40 |
| mntmn | bluerise: are you getting all those debug prints from dphy and nwl-dsi? | 20:44 |
| - rasmus (PART: Disconnected: timeout during receiving) (~rasmus@c80-217-132-63.bredband.tele2.se) | 20:53 | |
| + rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 20:54 | |
| bluerise | 650000000 0 | |-- dc_pixel | 21:05 |
| bluerise | 650000000 2 | |-- lcdif_pixel | 21:05 |
| bluerise | 40625000 2 | `-- dsi_phy_ref | 21:05 |
| bluerise | hmm | 21:05 |
| bluerise | dsi_phy_ref 1 1 0 23760000 0 0 50000 Y | 21:05 |
| bluerise | lcdif_pixel 1 1 0 593999998 0 0 50000 Y | 21:06 |
| bluerise | dc_pixel 1 1 0 118800000 0 0 50000 Y | 21:06 |
| bluerise | surprising diff | 21:06 |
| bluerise | how's your dc pixel only at 118? | 21:07 |
| bluerise | drivers/video/imx/nwl-drv.c: clk_set_rate(dsi->phy_ref_clk, rate); | 21:09 |
| bluerise | it's also weird that it sets a rate | 21:09 |
| mntmn | bluerise: i told you a while ago. i multiply it by 0.7x. but you don't need to do that | 21:12 |
| mntmn | bluerise: it's only a workaround for an image wrap glitch (underrun) that happens from time to time with dsi | 21:12 |
| bluerise | yeah, then it should still be at 166 or so | 21:12 |
| bluerise | not 400 | 21:12 |
| mntmn | i meant the dc_pixel clock | 21:13 |
| mntmn | that's why it is 118 and not 162 | 21:13 |
| mntmn | but your phy ref is 40.625mhz instead of 23.76 | 21:14 |
| mntmn | not sure if that's good? | 21:14 |
| bluerise | probably not | 21:17 |
| mntmn | oh btw i think dcss needs another phy ref clk depending on hdmi / mipi | 21:19 |
| - XgF (QUIT: Remote host closed the connection) (~quassel@2001:19f0:5001:1174:c87c:b331:3fed:5187) | 21:22 | |
| mntmn | bluerise: are you using IMX8MQ_CLK_DC_PIXEL also for the dcss pix clock? because you have to | 21:22 |
| mntmn | bluerise: whereas HDMI uses IMX8MQ_VIDEO2_PLL_OUT for the dcss pix clock | 21:22 |
| mntmn | bluerise: and the parent of IMX8MQ_CLK_DC_PIXEL has to be IMX8MQ_VIDEO_PLL1_OUT | 21:23 |
| + XgF (~quassel@2001:19f0:5001:1174:dbf:47a1:9a3f:787d) | 21:23 | |
| mntmn | bluerise: IMX8MQ_CLK_DC_PIXEL rate should be 594000000 | 21:24 |
| mntmn | bluerise: ok i see what you mean now | 21:24 |
| bluerise | but yours is 118 (which is 166, the panel pixelclock, * 0.7) | 21:26 |
| mntmn | yeah, it is probably wrong in my dts | 21:26 |
| mntmn | and then gets overwritten by the driver | 21:26 |
| mntmn | bluerise: anyway, can you confirm the input clock for your dcss is dc_pixel? | 21:26 |
| mntmn | maybe not and that's why it is left at the default | 21:27 |
| mntmn | sorry i mean not input clock, but "pix" clock. | 21:27 |
| bluerise | yes, it is | 21:29 |
| mntmn | ah yeah i see now in your dts | 21:29 |
| mntmn | what if you change the 594000000 in your dts to 162000000 ? | 21:30 |
| mntmn | maybe the u-boot dcss driver doesn't configure the pixel clock? | 21:30 |
| mntmn | yeah it doesn't | 21:31 |
| mntmn | __weak int imx8m_dcss_clock_init(u32 pixclk) | 21:32 |
| mntmn | { | 21:32 |
| mntmn | return 0; | 21:32 |
| mntmn | } | 21:32 |
| mntmn | that's kinda weird? | 21:32 |
| mntmn | but how did it work with hdmi... | 21:33 |
| bluerise | it's implemented here arch/arm/mach-imx/imx8m/clock_imx8mq.c | 21:35 |
| bluerise | in their repo | 21:35 |
| mntmn | ah | 21:36 |
| mntmn | but who sets the rate | 21:36 |
| mntmn | only the dts? | 21:36 |
| mntmn | maybe the hdmi driver | 21:36 |
| ex-parrot | morning bluerise. I have nothing useful to add currently other than to register my interest in OpenBSD on the reform also | 21:37 |
| mntmn | bluerise: hey uhm nwl_dsi_bridge_mode_fixup exists in the driver in your u-boot repo? | 21:37 |
| ex-parrot | ACTION -> to the office | 21:38 |
| mntmn | ah ok weird that sets the sync flags active low in case of dcss | 21:38 |
| mntmn | but that also sets the "crtc_clock" | 21:39 |
| mntmn | "Update the crtc_clock to be used by display controller" | 21:39 |
| bluerise | 25000000 1 | `-- video_pll1_ref_sel | 21:43 |
| bluerise | 5000000 1 | `-- video_pll1_ref_div | 21:43 |
| bluerise | 650000000 1 | `-- video_pll1 | 21:44 |
| bluerise | 650000000 1 | `-- video_pll1_bypass | 21:44 |
| bluerise | 650000000 4 | `-- video_pll1_out | 21:44 |
| bluerise | 162500000 0 | |-- dc_pixel | 21:44 |
| bluerise | 650000000 2 | |-- lcdif_pixel | 21:44 |
| bluerise | 24074075 2 | `-- dsi_phy_ref | 21:44 |
| bluerise | that looks better, right? | 21:44 |
| mntmn | yes, what did you do? | 21:49 |
| bluerise | changed the dcss driver so set its clock | 21:50 |
| mntmn | but | 21:50 |
| mntmn | nwl-drv.c:354, in nwl_dsi_bridge_mode_fixup() | 21:51 |
| mntmn | it sets some clock there | 21:51 |
| bluerise | yeah, but not the dc_pixel | 21:52 |
| mntmn | i'm trying to understand what crtc_clock is | 21:54 |
| mntmn | also, i'm trying to understand your dts node for mipi_dsi | 21:54 |
| + alex4nder (~alexander@172.56.42.59) | 21:55 | |
| mntmn | is mipi_dsi_bridge the dphy? it doesn't exist in linux | 21:55 |
| mntmn | ah it is video/imx/nw_dsi_imx.c | 21:56 |
| mntmn | ah that is the weird glue code to panel and backlight | 21:57 |
| mntmn | ok | 21:57 |
| mntmn | the field crtc_clock of mode_config struct is never set anywhere | 22:02 |
| + chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 22:03 | |
| mntmn | bluerise: what is the number in the second column of your clock dump? | 22:03 |
| mntmn | bluerise: some kind of refcount maybe? | 22:03 |
| bluerise | yes | 22:03 |
| mntmn | so the one of dc_pixel is 0? | 22:04 |
| mntmn | is it ever enabled? | 22:05 |
| bluerise | surprisingly though, because I do call clk_prepare_enable(priv->pix_clk); | 22:06 |
| bluerise | might have been the dump I did before I added that | 22:06 |
| mntmn | ok | 22:06 |
| bluerise | /* DCSS clock selection */ | 22:07 |
| bluerise | reg32_write(priv->addr + 0x2f010, 0x1); | 22:07 |
| bluerise | temp = reg32_read(priv->addr + 0x2f010); | 22:07 |
| bluerise | wonder which clock that is | 22:07 |
| mntmn | ugh | 22:07 |
| mntmn | is that from the dcss driver? | 22:07 |
| bluerise | if (blkctl->dcss->hdmi_output) | 22:08 |
| bluerise | dcss_writel(0, blkctl->base_reg + DCSS_BLKCTL_CONTROL0); | 22:08 |
| bluerise | else | 22:08 |
| bluerise | dcss_writel(DISPMIX_PIXCLK_SEL, | 22:08 |
| bluerise | blkctl->base_reg + DCSS_BLKCTL_CONTROL0); | 22:08 |
| bluerise | dcss_set(B_CLK_RESETN | APB_CLK_RESETN | P_CLK_RESETN | RTR_CLK_RESETN, | 22:08 |
| bluerise | blkctl->base_reg + DCSS_BLKCTL_RESET_CTRL); | 22:08 |
| bluerise | that's linux | 22:08 |
| mntmn | ah very interesting | 22:09 |
| bluerise | #define DCSS_BLKCTL_CONTROL0 0x10 | 22:09 |
| bluerise | #define DISPMIX_PIXCLK_SEL BIT(8) | 22:09 |
| bluerise | #define HDMI_MIPI_CLK_SEL BIT(0) | 22:09 |
| bluerise | aha | 22:09 |
| mntmn | ok that is the solution i think | 22:09 |
| mntmn | my god what a convoluted design | 22:09 |
| bluerise | there is no final solution | 22:09 |
| mntmn | so you wanna poke 0x100 there i guess | 22:09 |
| mntmn | wait what | 22:10 |
| mntmn | HDMI_MIPI ?? | 22:10 |
| mntmn | lol | 22:10 |
| mntmn | i hope that's just a wrong label | 22:11 |
| mntmn | the manual is a bit different | 22:13 |
| mntmn | > 15.2.2.1.7 Control (CONTROL0_SET) | 22:13 |
| mntmn | wait that is offset 0x14 | 22:13 |
| mntmn | > 15.2.2.1.6 Control (CONTROL0) | 22:14 |
| mntmn | 0x10 | 22:14 |
| bluerise | _SET is the same as non-_SET, it just doesn't clear 0 bits | 22:14 |
| mntmn | bit 8: Pixel Clock source selection. 0x0 = Video PLL2 Clock | 22:14 |
| mntmn | 0x1 = CCM DC Pixel Clock | 22:14 |
| mntmn | bluerise: yep, sorry | 22:14 |
| mntmn | bit 5:4: Reference clock source selection. | 22:15 |
| mntmn | 0x0 = 27 MHz Oscillator Reference Clock | 22:15 |
| mntmn | 0x1 = Video PLL2 Clock | 22:15 |
| mntmn | 0x2 = CCM DC Pixel Clock | 22:15 |
| bluerise | huh | 22:15 |
| mntmn | yeah interesting huh | 22:15 |
| mntmn | one sec... | 22:16 |
| mntmn | it is not touched in linux | 22:17 |
| mntmn | they have an unused define for it | 22:17 |
| mntmn | someone had this question before ;) https://community.nxp.com/t5/i-MX-Processors/imx8m-non-cea-video-modes/m-p/798575/highlight/true | 22:18 |
| chartreuse | Is this for messing with the HDMI output? Or are you changing the screen or something? Missed the context of what's being done | 22:20 |
| mntmn | chartreuse: openbsd | 22:21 |
| mntmn | chartreuse: or actually u-boot | 22:21 |
| bluerise | Well, actually | 22:21 |
| chartreuse | Ah okay! | 22:21 |
| bluerise | U-Boot + LCD display | 22:21 |
| mntmn | yeah | 22:21 |
| mntmn | the HDMI_MIPI_CLK_SEL (bit 0) is missing in the manual | 22:21 |
| mntmn | but 0 is "MIPI clock source" | 22:21 |
| bluerise | is there no dcss driver in NXP's upstream linux git? | 22:22 |
| bluerise | I'd be surprised | 22:22 |
| bluerise | Also,your Linux kernel is mainline? | 22:23 |
| mntmn | mainline plus patches | 22:23 |
| mntmn | the dcss driver is not mainlined | 22:24 |
| mntmn | i import it here https://source.mnt.re/reform/reform-system-image/-/blob/main/reform2-imx8mq/template-kernel/patches/mnt5000-imx8mq-import-HDMI-driver-and-make-DCSS-compatible.patch | 22:24 |
| mntmn | wait no it is mainlined | 22:24 |
| mntmn | but i patched it a bit | 22:24 |
| mntmn | i added hdmi support to it | 22:25 |
| bluerise | Maybe I forgot something in the SN65DSI86 setup? | 22:26 |
| mntmn | bluerise: so, no change after setting 0x2f010 to 0x100? | 22:28 |
| bluerise | no change | 22:29 |
| + ephase (~ephase@2a01:e0a:168:1211::885) | 22:29 | |
| ephase | Hello | 22:29 |
| chartreuse | Hi | 22:31 |
| mntmn | bluerise: can you confirm that priv->hpol and priv->vpol are false in dcss? | 22:31 |
| mntmn | also it's a mystery to me that they can run dcss without the ctxld | 22:35 |
| mntmn | ah maybe that is only required for double buffering / page flip stuff that is needed in linux | 22:37 |
| bluerise | bla 0 0 | 22:38 |
| bluerise | yes, hpol/vpol are false | 22:38 |
| mntmn | ok thanks | 22:40 |
| mntmn | i don't see where they turn the timing controller on in the dcss driver | 22:41 |
| mntmn | that should be bit 8 (TC_GO) of dcss + 0x20000 | 22:42 |
| mntmn | ah i see | 22:43 |
| mntmn | here lol | 22:44 |
| mntmn | /* disable local alpha */ | 22:44 |
| mntmn | reg32_write(priv->addr + 0x20000, 0xff005184); | 22:44 |
| mntmn | there is the 0x100 | 22:44 |
| - rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 22:50 | |
| mntmn | bluerise: i couldn't find any dcss status registers but mipi has a few we could check for activity | 22:53 |
| mntmn | MIPI_DSI_HOST_DSI_HOST_CFG_STATUS_OUT (0x30a0002c) | 22:55 |
| mntmn | this should be zero if no errors | 22:55 |
| mntmn | MIPI_DSI_HOST_DSI_HOST_RX_ERROR_STATUS (0x30a00030) | 22:55 |
| mntmn | should also be zero | 22:56 |
| bluerise | u-boot=> md.l 0x30a0002c 1 | 22:56 |
| bluerise | 30a0002c: 00000000 .... | 22:57 |
| bluerise | u-boot=> md.l 0x30a00030 1 | 22:57 |
| bluerise | 30a00030: 00000000 .... | 22:57 |
| mntmn | cool | 22:59 |
| mntmn | MIPI_DSI_HOST_APB_PKT_IF_DSI_HOST_PKT_STATUS 0x30a0028c | 22:59 |
| mntmn | MIPI_DSI_HOST_APB_PKT_IF_DSI_HOST_PKT_FIFO_WR_LEVEL 0x30a00290 | 22:59 |
| mntmn | (these should change over time i guess) | 23:01 |
| mntmn | well, feierabend for me | 23:03 |
| bluerise | hm, both 0 | 23:04 |
| mntmn | hmm | 23:04 |
| mntmn | sounds like it's not transmitting then maybe? | 23:04 |
| mntmn | i will check on a live device if those registers should be non-zero | 23:05 |
| mntmn | bluerise: red herring, they are also zero on a live system. | 23:08 |
| - chartreuse (QUIT: Ping timeout: 258 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 23:50 | |
| + chartreuse (~chartreus@199-7-158-226.eng.wind.ca) | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
