From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Pawel Osciak <p.osciak@samsung.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"'Hans Verkuil'" <hverkuil@xs4all.nl>,
"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>
Subject: Re: Magic in videobuf
Date: Mon, 15 Mar 2010 08:25:37 -0300 [thread overview]
Message-ID: <4B9E1931.8060006@redhat.com> (raw)
In-Reply-To: <E4D3F24EA6C9E54F817833EAE0D912AC09C7FCA3BF@bssrvexch01.BS.local>
Hi Pawel,
Pawel Osciak wrote:
> Hello,
>
> is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
> besides driver debugging? I intend to remove them, as we weren't able
> to find any particular use for them when we were discussing this at
> the memory handling meeting in Norway...
It is a sort of paranoid check to avoid the risk of mass memory corruption
if something goes deadly wrong with the video buffers.
The original videobuf, written back in 2001/2002 had this code, and I've
kept it on the redesign I did in 2007, since I know that DMA is very badly
implemented on some chipsets. There are several reports of the video driver
to corrupt the system memory and damaging the disk data when a PCI transfer
to disk happens at the same time that a PCI2PCI data transfer happens (This
basically affects overlay mode, where the hardware is programmed to transfer
data from the video board to the video adapter board).
The DMA bug is present on several VIA and SYS old chipsets. It happened again
in some newer chips (2007?), and the fix were to add a quirk blocking overlay
mode on the reported broken hardware. It seems that newer BIOSes for those
newer hardware fixed this issue.
That's said, I never got any report from anyone explicitly saying that they
hit the MAGIC_CHECK() logic.
I prefer to keep this logic, but maybe we can add a CONFIG option to disable it.
Something like:
#ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
#define MAGIC_CHECK() ...
#else
#define MAGIC_CHECK()
#endif
Cheers,
Mauro
next prev parent reply other threads:[~2010-03-15 11:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-15 8:07 Magic in videobuf Pawel Osciak
2010-03-15 11:25 ` Mauro Carvalho Chehab [this message]
2010-03-15 13:27 ` Hans Verkuil
2010-03-15 16:23 ` Mauro Carvalho Chehab
2010-03-15 16:40 ` Hans Verkuil
2010-03-15 17:26 ` Mauro Carvalho Chehab
2010-03-15 23:30 ` Andy Walls
2010-03-16 10:13 ` Pawel Osciak
2010-03-16 16:35 ` Hans Verkuil
2010-03-16 16:45 ` Devin Heitmueller
2010-03-17 6:50 ` Pawel Osciak
2010-03-17 7:59 ` Hans Verkuil
2010-03-16 14:58 ` Pawel Osciak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B9E1931.8060006@redhat.com \
--to=mchehab@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=kyungmin.park@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=p.osciak@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox