#
6849e7cc |
|
09-May-2013 |
Jérôme Duval <jerome.duval@gmail.com> |
cx23882: fixes 64 bit warnings
|
#
eddec292 |
|
21-Jul-2010 |
Oliver Tappe <zooey@hirschkaefer.de> |
* applied patch by kaliber that fixes more than 100 warnings - thanks a lot! Closes #6349 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37670 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9fb2d737 |
|
23-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Replaced B_32_BIT_MEMORY by B_32_BIT_FULL_LOCK and B_32_BIT_CONTIGUOUS, so the constraint can be expressed more precisely. ATM B_32_BIT_FULL_LOCK is implemented as B_32_BIT_CONTIGUOUS when B_HAIKU_PHYSICAL_BITS > 32, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37226 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d108c419 |
|
21-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Force memory allocations to 32 bit physical addresses. The code using them has implicit limitations (probably because the devices/controllers/... do). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37213 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64d79eff |
|
27-May-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed map_physical_memory()'s physicalAddress parameter type from void* to phys_addr_t. This breaks source compatibility, but -- as long as phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with BeOS. * Adjusted all code using the affected interfaces (Oh what fun!). Added a few TODOs in places where the wrong types (e.g. void* for physical addresses are used). Looks like quite a few drivers aren't 64 bit safe and others will break with PAE. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b0884f0c |
|
07-Aug-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed a ton of wrong usages of B_CONTIGUOUS + B_FULL_LOCK. * The use of B_{READ|WRITE}_AREA throughout the drivers is surely alarming. Defining these flags means that *every user* application can access these buffers read/write, it becomes visible in userspace like any other memory (just shared among all apps). I would like to ask each driver maintainer to see if that is really wished here. If you only need one app to be able to access it, cloning the area would be more appropriate. * I came across the use of B_ANY_KERNEL_BLOCK_ADDRESS a number of times. This is almost completely useless for most usages, as it tries to align the virtual to a multiple of the size of the area. It just makes the allocation more likely to fail. Please only use where appropriate, and please review your code. * Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26858 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
083a11a3 |
|
13-Apr-2007 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Driver for DVB-T cards with cx23882 chipset, like WinTV NOVA-T PCI git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20678 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6849e7cc153e8f47c50cb031b3b7fec102facf2c |
|
09-May-2013 |
Jérôme Duval <jerome.duval@gmail.com> |
cx23882: fixes 64 bit warnings
|
#
eddec292d5dd8251a00851880e16e6a5c07c1e3f |
|
21-Jul-2010 |
Oliver Tappe <zooey@hirschkaefer.de> |
* applied patch by kaliber that fixes more than 100 warnings - thanks a lot! Closes #6349 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37670 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9fb2d73772382ea2ccfb62e912f9bfb9c39ac26d |
|
23-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Replaced B_32_BIT_MEMORY by B_32_BIT_FULL_LOCK and B_32_BIT_CONTIGUOUS, so the constraint can be expressed more precisely. ATM B_32_BIT_FULL_LOCK is implemented as B_32_BIT_CONTIGUOUS when B_HAIKU_PHYSICAL_BITS > 32, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37226 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d108c419982e771acfc124a6248a78cdbf3493e5 |
|
21-Jun-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Force memory allocations to 32 bit physical addresses. The code using them has implicit limitations (probably because the devices/controllers/... do). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37213 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64d79eff7290437d24b1a420537c3ed5c144ab96 |
|
27-May-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed map_physical_memory()'s physicalAddress parameter type from void* to phys_addr_t. This breaks source compatibility, but -- as long as phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with BeOS. * Adjusted all code using the affected interfaces (Oh what fun!). Added a few TODOs in places where the wrong types (e.g. void* for physical addresses are used). Looks like quite a few drivers aren't 64 bit safe and others will break with PAE. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b0884f0cb812cdaf8035e6028f69dcf0d7721953 |
|
07-Aug-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed a ton of wrong usages of B_CONTIGUOUS + B_FULL_LOCK. * The use of B_{READ|WRITE}_AREA throughout the drivers is surely alarming. Defining these flags means that *every user* application can access these buffers read/write, it becomes visible in userspace like any other memory (just shared among all apps). I would like to ask each driver maintainer to see if that is really wished here. If you only need one app to be able to access it, cloning the area would be more appropriate. * I came across the use of B_ANY_KERNEL_BLOCK_ADDRESS a number of times. This is almost completely useless for most usages, as it tries to align the virtual to a multiple of the size of the area. It just makes the allocation more likely to fail. Please only use where appropriate, and please review your code. * Minor cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26858 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
083a11a3f4b17abb0e5c8d97bb9886af54626abf |
|
13-Apr-2007 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
Driver for DVB-T cards with cx23882 chipset, like WinTV NOVA-T PCI git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20678 a95241bf-73f2-0310-859d-f6bbb57e9c96
|