From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org, Harald Welte <laforge@gnumonks.org>,
JosephChan@via.com.tw, ScottFang@viatech.com.cn,
Deepak Saxena <dsaxena@laptop.org>,
linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [PATCH 04/16] viafb: Retain GEMODE reserved bits
Date: Fri, 09 Apr 2010 22:23:06 +0200 [thread overview]
Message-ID: <4BBF8CAA.3090506@gmx.de> (raw)
In-Reply-To: <20100409135959.381d819a@bike.lwn.net>
Hi Jon,
Jonathan Corbet schrieb:
> On Fri, 09 Apr 2010 05:07:34 +0200
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>
>> in your later patch "[PATCH 06/16] viafb: complete support for
>> VX800/VX855 accelerated framebuffer" you reintroduce initializing those
>> bits to 0. That's fine but I can't see a reason for preserving this bits
>> here as it adds useless overhead unless the hardware itself changed some
>> of those bits and behaves differently according to those bits.
>
> Somehow the cost of an additional MMIO read at mode setting time is
> just not going to keep me up at night.
Well it's not only mode setting its for each hardware accelerated
operation, but...
> I will admit that I've learned to be rather superstitious when it comes
> to messing with reserved bits. Hardware designers like to hide
> functionality like "bring down the wrath of the gods" behind such
> bits. The old code preserved them and worked, so I did the same. I
> don't see any real reason not to keep it.
...if you insist on it its okay with me. I still disagree but its
nothing I can't live with.
>> Additionally the first 2 bits are not reserved but provide a rotation
>> where 00 is what we want (no rotation).
>
> That much is true, yes. My mistake, will fix.
>
>> And if you rip code off hw_bitblt_2 it would be better to do the same
>> with hw_bitblt_1. A quick look reveals that the same function can be
>> used there (the error message would need to be adjusted but that's minor).
>
> That had crossed my mind; there is quite a bit of duplicated code
> between those two very long functions. At the time I was focused on
> making things work, and I didn't want to mess with code that I couldn't
> actually test. So further cleanup is on my list, but I would prefer to
> defer it for a little bit.
The code (and the spec regarding the reserved bits also) is obviously
identical so please don't ignore it. If you decide to put it in a
separate function please do so for both blit engines especially if they
really do the same as in this case. As you say they are mostly identical
and that's by design. Please keep them in sync if possible. They exist
that way to be a stateless and to avoid cluttering if's around.
(no need to say that I'll test those patches on my CLE266 and VX800 as
soon as they apply cleanly to mainline)
Thanks,
Florian Tobias Schandinat
next prev parent reply other threads:[~2010-04-09 20:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 17:15 [RFC] Initial OLPC Viafb merge Jonathan Corbet
2010-04-08 17:15 ` [PATCH 01/16] [FB] viafb: Fix various resource leaks during module_init() Jonathan Corbet
2010-04-08 18:22 ` Florian Tobias Schandinat
2010-04-09 19:31 ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 02/16] viafb: use proper pci config API Jonathan Corbet
2010-04-08 18:42 ` Florian Tobias Schandinat
2010-04-09 19:46 ` Jonathan Corbet
2010-04-10 6:41 ` Harald Welte
2010-04-08 17:15 ` [PATCH 03/16] viafb: Unmap the frame buffer on initialization error Jonathan Corbet
2010-04-08 18:55 ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 04/16] viafb: Retain GEMODE reserved bits Jonathan Corbet
2010-04-09 3:07 ` Florian Tobias Schandinat
2010-04-09 19:59 ` Jonathan Corbet
2010-04-09 20:23 ` Florian Tobias Schandinat [this message]
2010-04-09 20:30 ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 05/16] viafb: Determine type of 2D engine and store it in chip_info Jonathan Corbet
2010-04-09 3:20 ` Florian Tobias Schandinat
2010-04-09 20:11 ` Jonathan Corbet
2010-04-09 20:34 ` Florian Tobias Schandinat
2010-04-18 17:34 ` Jonathan Corbet
2010-04-18 18:00 ` Harald Welte
2010-04-18 18:05 ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 06/16] viafb: complete support for VX800/VX855 accelerated framebuffer Jonathan Corbet
2010-04-09 4:21 ` Florian Tobias Schandinat
2010-04-09 20:18 ` Jonathan Corbet
2010-04-08 17:15 ` [PATCH 07/16] viafb: Add 1200x900 DCON/LCD panel modes for OLPC XO-1.5 Jonathan Corbet
2010-04-09 21:27 ` Florian Tobias Schandinat
2010-04-18 17:39 ` Jonathan Corbet
2010-04-18 18:24 ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 08/16] viafb: Do not probe for LVDS/TMDS on " Jonathan Corbet
2010-04-09 21:40 ` Florian Tobias Schandinat
2010-04-10 0:19 ` Jonathan Corbet
2010-04-10 0:42 ` Florian Tobias Schandinat
2010-04-10 0:55 ` Jonathan Corbet
2010-04-10 6:34 ` Harald Welte
2010-04-08 17:15 ` [PATCH 09/16] viafb: rework the I2C support in the VIA framebuffer driver Jonathan Corbet
2010-04-09 22:07 ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 10/16] suppress verbose debug messages: change printk() to DEBUG_MSG() Jonathan Corbet
2010-04-09 22:09 ` Florian Tobias Schandinat
2010-04-08 17:15 ` [PATCH 11/16] Minimal support for viafb suspend/resume Jonathan Corbet
2010-04-08 17:15 ` [PATCH 12/16] fix register save count, so it matches the restore count Jonathan Corbet
2010-04-08 17:15 ` [PATCH 13/16] VIAFB: Update suspend/resume to selectively restore registers Jonathan Corbet
2010-04-08 17:15 ` [PATCH 14/16] Remove cursor restore hack in viafb Jonathan Corbet
2010-04-08 17:15 ` [PATCH 15/16] viafb: rework suspend/resume Jonathan Corbet
2010-04-08 17:15 ` [PATCH 16/16] viafb: Only suspend/resume on VX855 Jonathan Corbet
2010-04-09 5:43 ` [RFC] Initial OLPC Viafb merge Florian Tobias Schandinat
2010-04-09 18:46 ` Jonathan Corbet
2010-04-09 23:32 ` Florian Tobias Schandinat
2010-04-10 0:27 ` Jonathan Corbet
2010-04-10 1:02 ` Florian Tobias Schandinat
2010-04-10 8:52 ` Bruno Prémont
2010-04-13 3:03 ` Florian Tobias Schandinat
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=4BBF8CAA.3090506@gmx.de \
--to=florianschandinat@gmx.de \
--cc=JosephChan@via.com.tw \
--cc=ScottFang@viatech.com.cn \
--cc=corbet@lwn.net \
--cc=dsaxena@laptop.org \
--cc=laforge@gnumonks.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).