The sitara and/or bb-view patches are causing problems for my LCD4 based 4D Systems LCD cape. http://www.4dsystems.com.au/product/4DCAPE_43/
The image is squished to the left, with blank space on the right, and the colors are messed up. When I remove the patch in the most recent kernel (bone62), the problem with the screen goes away. Do you know what the problem might be? I've spent two days trying to find and fix this issue. At this point, I'm planning to run our system with a kernel sans your patch, but I wouldn't be surprised if there are others out there with the same issue. On Thursday, May 29, 2014 5:58:51 PM UTC-4, Scott Michel wrote: > > Wow. That was fast. My e-mail is in the patches, so... I'm sure the bug > reports will trickle in... > > > -scooter > > On Thursday, May 29, 2014 1:58:05 PM UTC-7, RobertCNelson wrote: >> >> On Thu, May 29, 2014 at 2:32 PM, Scott Michel <scoot...@gmail.com> >> wrote: >> > I've attached three patches for consideration in the Robert Nelson's >> > 3.8.13-bone5x update, all of which are independent of each other (i.e., >> you >> > can patch your kernel with any one of them, separate from the others): >> > >> > 0001-am335x-features >> > >> > Detect AM335x-specific features and CPU version. Doesn't do anything >> > significant, other than accurately report the CPU and SGX, L2 cache >> presence >> > in the bootup dmesg output. >> > >> > >> > 0002-element14-bb-view-lcd-capes >> > >> > Add Element14's "BB-VIEW" LCD cape device trees to firmware/capes. >> > >> > >> > 0003-sitara_rb_swap_workaround >> > >> > Create a workaround to the TI Sitara red/blue swap erratum through >> device >> > tree properties, 'bgrx_16bpp' and 'bgrx_24bpp'. The 'bgrx_16bpp' >> property >> > swaps red and blue if 16bpp color depth is used and the LCD cape itself >> > swaps red and blue at higher color depths (i.e., the cape designer >> "fixed" >> > the problem by swapping signals). The 'bgrx_24bpp' property swaps red >> and >> > blue at the 24bpp color depth, which addresses TI's erratum. >> > >> > >> > Also, the tilcdc LCD driver queries the panel's panel-info/bpp device >> tree >> > property to find the preferred BPP when initializing the console >> > framebuffer. This was originally hardcoded into the driver at 16bpp. If >> the >> > panel says that it wants 32bpp, the framebuffer initializes to a >> preferred >> > 32bpp. >> > >> > >> > I've been testing these changes relative to Robert's linux-dev >> 3.8.15-bone53 >> > tag. They may apply cleanly against earlier tags, but I can't guarantee >> they >> > will. >> > >> > I'm sure I have canonical kernel source formatting issues; comments, >> testing >> > and suggestions are welcome (and advocacy for inclusion in Robert's >> > linux-dev git repo also helpful.) >> >> Thanks! They are all queue'd up: >> >> >> https://github.com/RobertCNelson/bb-kernel/commit/5e50ae5c219b52bf70193bffdef7c07c8b26b90f >> >> >> Just have to run a few checks on the lcd3/lcd7 as this did revert the >> custom touchscreen filtering. >> >> I'm "pretty" sure we fixed the adc issue in: >> >> https://github.com/RobertCNelson/bb-kernel/commit/3a66618d3bbd86a4e7655e07bc48838fb967d5ed >> >> >> So it shouldn't be needed anymore now.. >> >> Regards, >> >> -- >> Robert Nelson >> http://www.rcn-ee.com/ >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
