From: Ilia Mirkin <imirkin@alum.mit.edu>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Pekka Paalanen" <ppaalanen@gmail.com>,
"Michel Dänzer" <michel@daenzer.net>,
"Alex Deucher" <alexdeucher@gmail.com>,
amd-gfx@lists.freedesktop.org,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Sean Paul" <seanpaul@chromium.org>,
"David Airlie" <airlied@linux.ie>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Date: Sat, 22 Apr 2017 09:48:21 -0400 [thread overview]
Message-ID: <CAKb7Uvig0J2rg=yJT4g8OuqR9RW4x2TzK-DA_zs_Qc_up4dACQ@mail.gmail.com> (raw)
In-Reply-To: <CAKb7UviirFVnut-6k6nO2-dspyzdu0AdZQ1CV8sAKAJkqAc3oA@mail.gmail.com>
On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>>> <ville.syrjala@linux.intel.com> wrote:
>>> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>>> >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>> >> > While working on graphics support for virtual machines on ppc64 (which
>>> >> > exists in both little and big endian variants) I've figured the comments
>>> >> > for various drm fourcc formats in the header file don't match reality.
>>> >> >
>>> >> > Comments says the RGB formats are little endian, but in practice they
>>> >> > are native endian. Look at the drm_mode_legacy_fb_format() helper. It
>>> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB8888, no matter
>>> >> > whenever the machine is little endian or big endian. The users of this
>>> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>>> >> > is native endian, not little endian. Most userspace also operates on
>>> >> > native endian only.
>>> >> >
>>> >> > So, go update the comments for all 16+24+32 bpp RGB formats.
>>> >> >
>>> >> > Leaving the yuv formats as-is. I have no idea if and how those are used
>>> >> > on bigendian machines.
>>> >>
>>> >> I think this is premature. The current situation is that I can't get
>>> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>>> >> the colors displayed are wrong). I believe that currently it packs
>>> >> things in "cpu native endian". I've tried futzing with that without
>>> >> much success, although I didn't spend too much time on it. I have a
>>> >> NV34 plugged into my LE setup as well although I haven't tested to
>>> >> double-check that it all works there. However I'm quite sure it used
>>> >> to, as I used modetest to help develop the YUV overlay support for
>>> >> those GPUs.
>>> >
>>> > I just took a quick stab at fixing modetest to respect the current
>>> > wording in drm_fourcc.h:
>>> >
>>> > git://github.com/vsyrjala/libdrm.git modetest_endian
>>>
>>> Looks like there was some careless testing on my part :( So ... it
>>> looks like the current modetest without those changes does, in fact,
>>> work on NV34/BE. With the changes, it breaks (and the handling of the
>>> b* modes is a little broken in those patches -- they're not selectable
>>> from the cmdline.) Which means that, as Michel & co predicted, it
>>> appears to be taking BE input not LE input. This is very surprising to
>>> me, but it is what it is. As I mentioned before, the details of how
>>> the "BE" mode works on the GPUs is largely unknown to us beyond a few
>>> basics. Note that only XR24 works, AR24 ends up with all black
>>> displayed. This also happens on LE.
>>
>> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
>> enabled some magic byte swapper in the hardware it will only for
>> a specific pixel size.
>
> Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
> although that doesn't appear functional). Yes, it's likely that
> there's a byteswap happening somewhere. In fact the copy engines have
> parameters somewhere to tell how the swap should be done (basically
> what the element size is). I don't quite know how to set that though
> on this generation. I should poke at VRAM via the mmio peephole and
> see what's actually being stored. Although of course MMIO accesses are
> also auto-byteswapped. It's all just one big massive headache.
Or it could just be the obvious:
static void nv_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
nouveau_hw_load_state(dev, nv_crtc->index,
&nv04_display(dev)->mode_reg);
nv04_crtc_mode_set_base(crtc, crtc->x, crtc->y, NULL);
#ifdef __BIG_ENDIAN
/* turn on LFB swapping */
{
uint8_t tmp = NVReadVgaCrtc(dev, nv_crtc->index,
NV_CIO_CRE_RCR);
tmp |= MASK(NV_CIO_CRE_RCR_ENDIAN_BIG);
NVWriteVgaCrtc(dev, nv_crtc->index, NV_CIO_CRE_RCR, tmp);
}
#endif
funcs->dpms(crtc, DRM_MODE_DPMS_ON);
drm_crtc_vblank_on(crtc);
}
So presumably instead of that __BIG_ENDIAN thing, it should instead be
if crtc->primary->fb->fourcc & BIG_ENDIAN. (Although that's probably
going to break the universe.) There's also some questionable support
for 16-bit modes in the code, I'm going to see how easy it is to flip
on.
-ilia
next prev parent reply other threads:[~2017-04-22 13:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 7:58 [PATCH] drm: fourcc byteorder: brings header file comments in line with reality Gerd Hoffmann
2017-04-21 8:06 ` Pekka Paalanen
2017-04-21 9:38 ` Gerd Hoffmann
2017-04-21 9:44 ` Ville Syrjälä
2017-04-21 9:25 ` Ville Syrjälä
2017-04-21 9:50 ` Gerd Hoffmann
2017-04-21 11:05 ` Ville Syrjälä
2017-04-21 11:08 ` Ville Syrjälä
2017-04-21 11:40 ` Pekka Paalanen
2017-04-21 11:49 ` Ville Syrjälä
2017-04-21 12:02 ` Christian König
2017-04-21 11:41 ` Gerd Hoffmann
2017-04-21 11:42 ` Christian König
2017-04-21 13:12 ` Gerd Hoffmann
2017-04-21 13:21 ` Christian König
2017-04-21 13:27 ` Christian König
2017-04-21 15:21 ` Harry Wentland
2017-04-21 16:14 ` Gerd Hoffmann
2017-04-22 10:05 ` Ville Syrjälä
2017-04-22 21:59 ` Gerd Hoffmann
2017-04-24 6:57 ` Michel Dänzer
2017-04-24 13:03 ` Ville Syrjälä
2017-04-25 1:12 ` Michel Dänzer
2017-04-25 3:08 ` Michel Dänzer
2017-04-25 10:26 ` Ville Syrjälä
2017-04-26 2:10 ` Michel Dänzer
2017-05-11 21:23 ` Pavel Machek
2017-05-12 9:10 ` Ville Syrjälä
2017-04-21 14:49 ` Ilia Mirkin
2017-04-21 16:59 ` Ville Syrjälä
2017-04-22 5:07 ` Ilia Mirkin
2017-04-22 9:50 ` Ville Syrjälä
2017-04-22 13:40 ` Ilia Mirkin
2017-04-22 13:48 ` Ilia Mirkin [this message]
2017-04-22 19:24 ` Ilia Mirkin
2017-04-24 6:33 ` Michel Dänzer
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='CAKb7Uvig0J2rg=yJT4g8OuqR9RW4x2TzK-DA_zs_Qc_up4dACQ@mail.gmail.com' \
--to=imirkin@alum.mit.edu \
--cc=airlied@linux.ie \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=ppaalanen@gmail.com \
--cc=seanpaul@chromium.org \
--cc=ville.syrjala@linux.intel.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;
as well as URLs for NNTP newsgroup(s).