Searched +hist:5 +hist:af5259c (Results 1 - 3 of 3) sorted by path
/haiku/headers/private/graphics/intel_extreme/ | ||
H A D | intel_extreme.h | diff d60c7e01 Sat Dec 04 17:47:05 MST 2021 Rudolf Cornelissen <rudhaiku@gmail.com> intel_extreme: for gen9.5 added new portF to DDI scan. add ID dump in kerneldriver. diff 52d1e933 Tue Jun 05 19:07:59 MDT 2018 Augustin Cavalier <waddlesplash@gmail.com> Revert "intel_extreme: Broadwell is really Gen7(.5), not 8." This reverts commit 4f059c1fc51d17a2a592c5675a2f188b4bea2f69. From discussion on the mailing list, it seems I was correct the first time and Broadwell is Gen8. The confusion comes from the SER5/SOC distinction, which is not in the Linux driver, and I still don't know which one it really belongs in. diff 4f059c1f Tue Jun 05 11:27:45 MDT 2018 Augustin Cavalier <waddlesplash@gmail.com> intel_extreme: Broadwell is really Gen7(.5), not 8. diff 8fe50548 Sun May 08 14:39:22 MDT 2016 Alexander von Gluck IV <kallisti5@unixzen.com> intel_extreme: Extend DDI port probing to A-E * The Linux code made this a bit hard to figure out via complex define functions, however there can be up to 5 DDI ports (A-E) diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5da6291b Mon Apr 24 12:18:46 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Now using Thomas memory manager to manage the graphics memory; allocation of graphics memory is now possible. * Changed driver name to start with "intel_extreme" to have a nicer device name. * Renamed frame_buffer* stuff to graphics_memory* as the frame buffer just happens to be located somewhere in the graphics memory. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17224 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c38b8e63ab87a2bfb8d715ad2ea28d887 Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5da6291b99c3bd38505f6306dcb6398b9485783d Mon Apr 24 12:18:46 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Now using Thomas memory manager to manage the graphics memory; allocation of graphics memory is now possible. * Changed driver name to start with "intel_extreme" to have a nicer device name. * Renamed frame_buffer* stuff to graphics_memory* as the frame buffer just happens to be located somewhere in the graphics memory. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17224 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/accelerants/intel_extreme/ | ||
H A D | accelerant.cpp | diff d60c7e01 Sat Dec 04 17:47:05 MST 2021 Rudolf Cornelissen <rudhaiku@gmail.com> intel_extreme: for gen9.5 added new portF to DDI scan. add ID dump in kerneldriver. diff 5c178f3c Fri Jun 18 18:47:46 MDT 2021 Rudolf Cornelissen <rudhaiku@gmail.com> intel_extreme: fixed pipe-to-port assigning: no second screen yet.. diff 8fe50548 Sun May 08 14:39:22 MDT 2016 Alexander von Gluck IV <kallisti5@unixzen.com> intel_extreme: Extend DDI port probing to A-E * The Linux code made this a bit hard to figure out via complex define functions, however there can be up to 5 DDI ports (A-E) diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c38b8e63ab87a2bfb8d715ad2ea28d887 Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
/haiku/src/add-ons/kernel/drivers/graphics/intel_extreme/ | ||
H A D | intel_extreme.cpp | diff c2d37953 Sat Jul 28 14:52:37 MDT 2018 Adrien Destugues <pulkomandy@pulkomandy.tk> Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff c2d37953 Sat Jul 28 14:52:37 MDT 2018 Adrien Destugues <pulkomandy@pulkomandy.tk> Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff c2d37953 Sat Jul 28 14:52:37 MDT 2018 Adrien Destugues <pulkomandy@pulkomandy.tk> Rework PLL calculations for Iron Lake The limits were wrong in several places. Checked the sandy bridge, ivy brige and haswell docs, they all say mostly the same. - The value of p2 is either 7, 14, 5 or 10 depending on 1 bit in the config register and on the display type. We can guess which values are right according to the global P limit (5-80 when using 5/10, 28-something when using 14/7). The values are different because CRT need a precise, but rather low pixel clock, while modern display interface can accomodate being faster than required by a few MHz, but need a much higher speed (the bits are transferred serially, so they need to be at least 8 times faster than a DAC). - The limits for N were obviously wrong, as the register is written with N-2, so values less than 2 make no sense. Use 3-8 as specified in the datasheet. - The reference frequency (set by the driver) was wrong, too. It is 120MHz, not 96. It is 100MHz in some cases (FDI, etc), we should see when this happens and switch to the right reference for PLL computations. - There was an attempt to minimize the value of N (a powersaving effort, I guess?), but it would basically force the loop to stop at the first value of N tested, resulting in way off timings in some cases. - To ease testing and stop sending patches and syslogs back and forth with vidrep, extract the "test mode" from pll.cpp into a proper test executable, making it a little easier to experiment with the code and fix the problems. This should fix #13669 and possibly other cases of "out of range", black screen, bad timings, etc. Change-Id: Ic4c1c159701f352b7c1ef15a647f023c82ac26c Reviewed-on: https://review.haiku-os.org/360 Reviewed-by: Axel Dörfler <axeld@pinc-software.de> Reviewed-by: waddlesplash <waddlesplash@gmail.com> diff 5bd8cf13 Sun Jul 01 06:07:38 MDT 2018 Jérôme Duval <jerome.duval@gmail.com> intel_extreme: use user_memcpy to write to user mapped memory. * now boot successfully to desktop with SMAP enabled on intel_extreme. * enforced 80 chars/line on two occasions. diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5da6291b Mon Apr 24 12:18:46 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Now using Thomas memory manager to manage the graphics memory; allocation of graphics memory is now possible. * Changed driver name to start with "intel_extreme" to have a nicer device name. * Renamed frame_buffer* stuff to graphics_memory* as the frame buffer just happens to be located somewhere in the graphics memory. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17224 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5af5259c38b8e63ab87a2bfb8d715ad2ea28d887 Sat May 13 09:22:20 MDT 2006 Axel Dörfler <axeld@pinc-software.de> Implemented vblank interrupt and support for the retrace semaphore - not yet tested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17439 a95241bf-73f2-0310-859d-f6bbb57e9c96 diff 5da6291b99c3bd38505f6306dcb6398b9485783d Mon Apr 24 12:18:46 MDT 2006 Axel Dörfler <axeld@pinc-software.de> * Now using Thomas memory manager to manage the graphics memory; allocation of graphics memory is now possible. * Changed driver name to start with "intel_extreme" to have a nicer device name. * Renamed frame_buffer* stuff to graphics_memory* as the frame buffer just happens to be located somewhere in the graphics memory. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17224 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
Completed in 215 milliseconds