History log of /haiku/src/add-ons/kernel/drivers/dvb/cx23882/util.c
Revision Date Author Comments
# 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