* [PATCH] drm: hdlcd: Work properly in big-endian mode @ 2016-12-07 15:31 Robin Murphy 2016-12-07 15:57 ` Daniel Vetter 2016-12-07 16:11 ` liviu.dudau at arm.com 0 siblings, 2 replies; 9+ messages in thread From: Robin Murphy @ 2016-12-07 15:31 UTC (permalink / raw) To: linux-arm-kernel Under a big-endian kernel, colours on the framebuffer all come out a delightful shade of wrong, since we fail to take the reversed byte order into account. Fortunately, the HDLCD has a control bit to make it automatically byteswap big-endian data; let's use it as appropriate. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c index 28341b32067f..eceb7bed5dd0 100644 --- a/drivers/gpu/drm/arm/hdlcd_crtc.c +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) uint32_t pixel_format; struct simplefb_format *format = NULL; int i; + u32 reg; pixel_format = crtc->primary->state->fb->pixel_format; @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) /* HDLCD uses 'bytes per pixel', zero means 1 byte */ btpp = (format->bits_per_pixel + 7) / 8; - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); + reg = (btpp - 1) << 3; +#ifdef __BIG_ENDIAN + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; +#endif + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); /* * The format of the HDLCD_REG_<color>_SELECT register is: -- 2.10.2.dirty ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 15:31 [PATCH] drm: hdlcd: Work properly in big-endian mode Robin Murphy @ 2016-12-07 15:57 ` Daniel Vetter 2016-12-07 16:42 ` Robin Murphy 2016-12-07 16:43 ` Ville Syrjälä 2016-12-07 16:11 ` liviu.dudau at arm.com 1 sibling, 2 replies; 9+ messages in thread From: Daniel Vetter @ 2016-12-07 15:57 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: > Under a big-endian kernel, colours on the framebuffer all come out a > delightful shade of wrong, since we fail to take the reversed byte > order into account. Fortunately, the HDLCD has a control bit to make it > automatically byteswap big-endian data; let's use it as appropriate. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> fourcc codes (and the drm fourcc codes) are supposed to be little-endian. All of them. So either we fix up the drivers and userspace to set that flag correctly (which would mean hdlcd should expose twice as many formats, each one with the little and big endian mode). Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik are the only other ones who ever cared about big endian in drm. -Daniel > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 28341b32067f..eceb7bed5dd0 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > uint32_t pixel_format; > struct simplefb_format *format = NULL; > int i; > + u32 reg; > > pixel_format = crtc->primary->state->fb->pixel_format; > > @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > > /* HDLCD uses 'bytes per pixel', zero means 1 byte */ > btpp = (format->bits_per_pixel + 7) / 8; > - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); > + reg = (btpp - 1) << 3; > +#ifdef __BIG_ENDIAN > + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; > +#endif > + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); > > /* > * The format of the HDLCD_REG_<color>_SELECT register is: > -- > 2.10.2.dirty > > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 15:57 ` Daniel Vetter @ 2016-12-07 16:42 ` Robin Murphy 2016-12-07 16:50 ` Robin Murphy 2016-12-08 0:16 ` Ilia Mirkin 2016-12-07 16:43 ` Ville Syrjälä 1 sibling, 2 replies; 9+ messages in thread From: Robin Murphy @ 2016-12-07 16:42 UTC (permalink / raw) To: linux-arm-kernel On 07/12/16 15:57, Daniel Vetter wrote: > On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: >> Under a big-endian kernel, colours on the framebuffer all come out a >> delightful shade of wrong, since we fail to take the reversed byte >> order into account. Fortunately, the HDLCD has a control bit to make it >> automatically byteswap big-endian data; let's use it as appropriate. >> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > fourcc codes (and the drm fourcc codes) are supposed to be little-endian. > All of them. So either we fix up the drivers and userspace to set that > flag correctly (which would mean hdlcd should expose twice as many > formats, each one with the little and big endian mode). AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever sets it :/ My vague (and probably wrong) assumption was that the HDLCD is still expecting little-endian data, but the the CPU is writing framebuffer data as host-endian words, hence what the HDLCD thinks is xRGB is actually RGBx under a big-endian kernel - It's certainly consistent between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue is black, green is red and red is green. I don't know how to test "proper" DRM (I've failed to get X to work with the Arch Linux ARM distro I have on there at the moment). Once again I'm somewhat out of my depth here - I just found a thing that seemed appropriate and visibly resolved the immediate problem :) By comparison, the same use-cases (fbcon and fb-test) under the same big-endian kernel do *not* show the same problem with nouveau driving a PCIe 7600GT card, which led me to believe it was HDLCD-specific. Robin. [1]:https://github.com/prpplague/fb-test-app > Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik > are the only other ones who ever cared about big endian in drm. > -Daniel > >> --- >> drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c >> index 28341b32067f..eceb7bed5dd0 100644 >> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c >> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c >> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) >> uint32_t pixel_format; >> struct simplefb_format *format = NULL; >> int i; >> + u32 reg; >> >> pixel_format = crtc->primary->state->fb->pixel_format; >> >> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) >> >> /* HDLCD uses 'bytes per pixel', zero means 1 byte */ >> btpp = (format->bits_per_pixel + 7) / 8; >> - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); >> + reg = (btpp - 1) << 3; >> +#ifdef __BIG_ENDIAN >> + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; >> +#endif >> + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); >> >> /* >> * The format of the HDLCD_REG_<color>_SELECT register is: >> -- >> 2.10.2.dirty >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 16:42 ` Robin Murphy @ 2016-12-07 16:50 ` Robin Murphy 2016-12-07 23:59 ` Daniel Vetter 2016-12-08 0:16 ` Ilia Mirkin 1 sibling, 1 reply; 9+ messages in thread From: Robin Murphy @ 2016-12-07 16:50 UTC (permalink / raw) To: linux-arm-kernel On 07/12/16 16:42, Robin Murphy wrote: > On 07/12/16 15:57, Daniel Vetter wrote: >> On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: >>> Under a big-endian kernel, colours on the framebuffer all come out a >>> delightful shade of wrong, since we fail to take the reversed byte >>> order into account. Fortunately, the HDLCD has a control bit to make it >>> automatically byteswap big-endian data; let's use it as appropriate. >>> >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> >> fourcc codes (and the drm fourcc codes) are supposed to be little-endian. >> All of them. So either we fix up the drivers and userspace to set that >> flag correctly (which would mean hdlcd should expose twice as many >> formats, each one with the little and big endian mode). > > AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian > modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever > sets it :/ > > My vague (and probably wrong) assumption was that the HDLCD is still > expecting little-endian data, but the the CPU is writing framebuffer > data as host-endian words, hence what the HDLCD thinks is xRGB is > actually RGBx under a big-endian kernel - It's certainly consistent > between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue > is black, green is red and red is green. I don't know how to test > "proper" DRM (I've failed to get X to work with the Arch Linux ARM > distro I have on there at the moment). > > Once again I'm somewhat out of my depth here - I just found a thing that > seemed appropriate and visibly resolved the immediate problem :) > By comparison, the same use-cases (fbcon and fb-test) under the same > big-endian kernel do *not* show the same problem with nouveau driving a > PCIe 7600GT card, which led me to believe it was HDLCD-specific. Off the back of that, upon closer inspection, nv_crtc_commit() would appear to already be doing very much the equivalent thing to what I'm doing in this patch, so now I have no idea whether this is right or everything's wrong. Robin. > [1]:https://github.com/prpplague/fb-test-app > >> Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik >> are the only other ones who ever cared about big endian in drm. >> -Daniel >> >>> --- >>> drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c >>> index 28341b32067f..eceb7bed5dd0 100644 >>> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c >>> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c >>> @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) >>> uint32_t pixel_format; >>> struct simplefb_format *format = NULL; >>> int i; >>> + u32 reg; >>> >>> pixel_format = crtc->primary->state->fb->pixel_format; >>> >>> @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) >>> >>> /* HDLCD uses 'bytes per pixel', zero means 1 byte */ >>> btpp = (format->bits_per_pixel + 7) / 8; >>> - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); >>> + reg = (btpp - 1) << 3; >>> +#ifdef __BIG_ENDIAN >>> + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; >>> +#endif >>> + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); >>> >>> /* >>> * The format of the HDLCD_REG_<color>_SELECT register is: >>> -- >>> 2.10.2.dirty >>> >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 16:50 ` Robin Murphy @ 2016-12-07 23:59 ` Daniel Vetter 0 siblings, 0 replies; 9+ messages in thread From: Daniel Vetter @ 2016-12-07 23:59 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 07, 2016 at 04:50:31PM +0000, Robin Murphy wrote: > On 07/12/16 16:42, Robin Murphy wrote: > > On 07/12/16 15:57, Daniel Vetter wrote: > >> On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: > >>> Under a big-endian kernel, colours on the framebuffer all come out a > >>> delightful shade of wrong, since we fail to take the reversed byte > >>> order into account. Fortunately, the HDLCD has a control bit to make it > >>> automatically byteswap big-endian data; let's use it as appropriate. > >>> > >>> Signed-off-by: Robin Murphy <robin.murphy@arm.com> > >> > >> fourcc codes (and the drm fourcc codes) are supposed to be little-endian. > >> All of them. So either we fix up the drivers and userspace to set that > >> flag correctly (which would mean hdlcd should expose twice as many > >> formats, each one with the little and big endian mode). > > > > AFAICS, SIMPLEFB_FORMATS *is* supposed to be explicitly little-endian > > modes. I see that DRM_FORMAT_BIG_ENDIAN exists, but nothing in-tree ever > > sets it :/ > > > > My vague (and probably wrong) assumption was that the HDLCD is still > > expecting little-endian data, but the the CPU is writing framebuffer > > data as host-endian words, hence what the HDLCD thinks is xRGB is > > actually RGBx under a big-endian kernel - It's certainly consistent > > between kernel (fbcon) and userspace (fb-test[1]): white is yellow, blue > > is black, green is red and red is green. I don't know how to test > > "proper" DRM (I've failed to get X to work with the Arch Linux ARM > > distro I have on there at the moment). > > > > Once again I'm somewhat out of my depth here - I just found a thing that > > seemed appropriate and visibly resolved the immediate problem :) > > By comparison, the same use-cases (fbcon and fb-test) under the same > > big-endian kernel do *not* show the same problem with nouveau driving a > > PCIe 7600GT card, which led me to believe it was HDLCD-specific. > > Off the back of that, upon closer inspection, nv_crtc_commit() would > appear to already be doing very much the equivalent thing to what I'm > doing in this patch, so now I have no idea whether this is right or > everything's wrong. Congrats for finding a really big can of worms. Unfortunately I can't really help you with figuring out what's the right choice here :( Trying to fix up everything is probably going to be lots of work, but assuming that everything is broken for big endian is probably correct. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 16:42 ` Robin Murphy 2016-12-07 16:50 ` Robin Murphy @ 2016-12-08 0:16 ` Ilia Mirkin 2016-12-08 9:06 ` Daniel Vetter 1 sibling, 1 reply; 9+ messages in thread From: Ilia Mirkin @ 2016-12-08 0:16 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy <robin.murphy@arm.com> wrote: > By comparison, the same use-cases (fbcon and fb-test) under the same > big-endian kernel do *not* show the same problem with nouveau driving a > PCIe 7600GT card, which led me to believe it was HDLCD-specific. Just to randomly insert info here... NV11+ cards have a "big endian" mode, where you can do 32-bit mmio from a big-endian cpu, and the card will auto-swap those. There are similar additional bits that make operating and accelerating off a big-endian CPU tolerable. Some care has gone into the kernel to make sure that all that stuff works. (One of those bits is that data gets byteswapped on upload to VRAM by virtue of being uploaded by sticking data into a pushbuf, as I recall.) -ilia ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-08 0:16 ` Ilia Mirkin @ 2016-12-08 9:06 ` Daniel Vetter 0 siblings, 0 replies; 9+ messages in thread From: Daniel Vetter @ 2016-12-08 9:06 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 07, 2016 at 07:16:30PM -0500, Ilia Mirkin wrote: > On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy <robin.murphy@arm.com> wrote: > > By comparison, the same use-cases (fbcon and fb-test) under the same > > big-endian kernel do *not* show the same problem with nouveau driving a > > PCIe 7600GT card, which led me to believe it was HDLCD-specific. > > Just to randomly insert info here... NV11+ cards have a "big endian" > mode, where you can do 32-bit mmio from a big-endian cpu, and the card > will auto-swap those. There are similar additional bits that make > operating and accelerating off a big-endian CPU tolerable. Some care > has gone into the kernel to make sure that all that stuff works. (One > of those bits is that data gets byteswapped on upload to VRAM by > virtue of being uploaded by sticking data into a pushbuf, as I > recall.) But on the kms side nouveau.ko doesn't inform userspace that it's taking big-endian buffers? That seems to be the crux here - should we auto-endian gpus to the cpu's endianess (might not work everywhere, but probably bigger chance that it works on gpus which do have endian control). Or should we start enforcing the explicit DRM_FORMAT_BIG_ENDIAN flag? If we opt for the former I really think we should nuke the endianess indicator. Atm it seems entirely unused (at least in drivers), so that's probably the right choice. Plus updating docs ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 15:57 ` Daniel Vetter 2016-12-07 16:42 ` Robin Murphy @ 2016-12-07 16:43 ` Ville Syrjälä 1 sibling, 0 replies; 9+ messages in thread From: Ville Syrjälä @ 2016-12-07 16:43 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 07, 2016 at 04:57:14PM +0100, Daniel Vetter wrote: > On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: > > Under a big-endian kernel, colours on the framebuffer all come out a > > delightful shade of wrong, since we fail to take the reversed byte > > order into account. Fortunately, the HDLCD has a control bit to make it > > automatically byteswap big-endian data; let's use it as appropriate. > > > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > fourcc codes (and the drm fourcc codes) are supposed to be little-endian. > All of them. So either we fix up the drivers and userspace to set that > flag correctly (which would mean hdlcd should expose twice as many > formats, each one with the little and big endian mode). > > Or we nuke the big endian flag from drm fourcc. Adding AMD folks who afaik > are the only other ones who ever cared about big endian in drm. I don't like the idea of nuking the flag. If the fb endianness is defined by the CPU, how would userspace even know that it would have to byteswap the data when feeding it to the device if the device and CPU don't agree on the endianness? > -Daniel > > > --- > > drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > > index 28341b32067f..eceb7bed5dd0 100644 > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > > @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > > uint32_t pixel_format; > > struct simplefb_format *format = NULL; > > int i; > > + u32 reg; > > > > pixel_format = crtc->primary->state->fb->pixel_format; > > > > @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > > > > /* HDLCD uses 'bytes per pixel', zero means 1 byte */ > > btpp = (format->bits_per_pixel + 7) / 8; > > - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); > > + reg = (btpp - 1) << 3; > > +#ifdef __BIG_ENDIAN > > + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; > > +#endif > > + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); > > > > /* > > * The format of the HDLCD_REG_<color>_SELECT register is: > > -- > > 2.10.2.dirty > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel OTC ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] drm: hdlcd: Work properly in big-endian mode 2016-12-07 15:31 [PATCH] drm: hdlcd: Work properly in big-endian mode Robin Murphy 2016-12-07 15:57 ` Daniel Vetter @ 2016-12-07 16:11 ` liviu.dudau at arm.com 1 sibling, 0 replies; 9+ messages in thread From: liviu.dudau at arm.com @ 2016-12-07 16:11 UTC (permalink / raw) To: linux-arm-kernel On Wed, Dec 07, 2016 at 03:31:40PM +0000, Robin Murphy wrote: > Under a big-endian kernel, colours on the framebuffer all come out a > delightful shade of wrong, So you are saying that wrong is only a 1 bit value? > since we fail to take the reversed byte > order into account. Fortunately, the HDLCD has a control bit to make it > automatically byteswap big-endian data; let's use it as appropriate. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> Change looks good to me, but as Daniel has mentioned, we should have failed the modesetting as the buffer we are passed should be in the wrong fourcc format. Any way I can play with a big-endian filesystem that you can share? Best regards, Liviu > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > index 28341b32067f..eceb7bed5dd0 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -63,6 +63,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > uint32_t pixel_format; > struct simplefb_format *format = NULL; > int i; > + u32 reg; > > pixel_format = crtc->primary->state->fb->pixel_format; > > @@ -76,7 +77,11 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc) > > /* HDLCD uses 'bytes per pixel', zero means 1 byte */ > btpp = (format->bits_per_pixel + 7) / 8; > - hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, (btpp - 1) << 3); > + reg = (btpp - 1) << 3; > +#ifdef __BIG_ENDIAN > + reg |= HDLCD_PIXEL_FMT_BIG_ENDIAN; > +#endif > + hdlcd_write(hdlcd, HDLCD_REG_PIXEL_FORMAT, reg); > > /* > * The format of the HDLCD_REG_<color>_SELECT register is: > -- > 2.10.2.dirty > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ?\_(?)_/? ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-12-08 9:06 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-12-07 15:31 [PATCH] drm: hdlcd: Work properly in big-endian mode Robin Murphy 2016-12-07 15:57 ` Daniel Vetter 2016-12-07 16:42 ` Robin Murphy 2016-12-07 16:50 ` Robin Murphy 2016-12-07 23:59 ` Daniel Vetter 2016-12-08 0:16 ` Ilia Mirkin 2016-12-08 9:06 ` Daniel Vetter 2016-12-07 16:43 ` Ville Syrjälä 2016-12-07 16:11 ` liviu.dudau at arm.com
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).