After this fixing building patch, xtensa can pass allmodconfig.
- There are still several warnings for it (I sent several patches for
them, but not for all).
- Xtensa gcc5 cross compiler has issues:
it causes more than 10 broken areas with allmodconfig (but no issues
with defconfig).
opefully a solution isn't that difficult now. Any
thoughts please?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments
me the modesetting driver from current xserver has proper
DRI3 and Present support.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b81226a9/attachment.html>
On 01/27/2015 03:01 PM, Shobhit Kumar wrote:
> For scenarios where OF is not available, we can use panel identification by
> name.
Any body had a look at this ?
Regards
Shobhit
>
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/drm_panel.c | 18 ++
> include/drm/drm_pane
Hi,
On 02/02/2015 11:26 PM, Gustavo Padovan wrote:
> From: Prathyush K
>
> When VPLL clock of less than 140 MHz was used and all the three clocks -
> hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs during S2R when
> HDMI is connected. Since we want to use a vpll clock of 70.5 MHz, we
> c
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b0a9ff8e/attachment.html>
ves/dri-devel/attachments/20150203/36a5114b/attachment.html>
ves/dri-devel/attachments/20150203/f6270517/attachment.html>
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/7f13d45e/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b494272f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/94a7329b/attachment.html>
7600211
I get error 403 for that.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/c94dcdfb/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b4b839c0/attachment.html>
On Mon, Feb 02, 2015 at 09:46:16PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> > >> My initial thought is for dma-buf to not try to prevent something than
> > >> an exporter can actu
On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> >> My initial thought is for dma-buf to not try to prevent something than
> >> an exporter can actually do.. I think the scenario you describe could
> >> be handled by two sg-lists,
On Mon, Feb 02, 2015 at 05:36:10PM -0500, Rob Clark wrote:
> well, I guess anyways when it comes to sharing buffers, it won't be
> the vram placement of the bo that gets shared ;-)
Actually that's pretty much what I'd like to be able to do for i915.
Except that vram is just a specially protected c
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/22596b3e/attachment.html>
On Mon, Feb 02, 2015 at 12:56:26PM -0500, Alex Deucher wrote:
> On Mon, Feb 2, 2015 at 12:13 PM, wrote:
> > From: Ville Syrjälä
> >
> > Currently when a mode is rejected the reason is printed as a raw number.
> > Having to manually decode that to a enum drm_mode_status value is
> > tiresome. H
On 28/01/15 12:54, Sumit Semwal wrote:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_exp
Hi Chen,
Thank you for the patch.
On Sunday 01 February 2015 22:08:33 Chen Gang S wrote:
> DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
> building. The related error (with allmodconfig under xtensa):
>
> CC [M] drivers/gpu/drm/drm_gem_cma_helper.o
> drivers/gpu/drm
At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.
Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
in
With Ville's rework to use drm_crtc_vblank_on/off the core will take
care of rejecting drm_vblank_get calls when the pipe is off. Also the
core won't call the get_vblank_counter hooks in that case either. And
since we've dropped ums support recently we can now remove these
hacks, yay!
Noticed whil
UMS is no more!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 36 +++-
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 80f35dcffea4..37189a25ca82 100644
--
Where possible right now. Just a small step towards nirvana ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
3 files changed, 8 insertions(+), 7 deletions(-)
diff
Hi Daniel,
Thank you for the patch.
On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
>
> Thus far i915 used drm_vblank_off,
chives/dri-devel/attachments/20150203/7fbb2968/attachment-0001.html>
Hi Dave,
Two more fixes for 3.20 amdkfd code:
- Fixing accounting of active queues
- Preserving a register internal state
Thanks,
Oded
The following changes since commit e4bf44b3b558742fb7c58b4d34e206c8942f07e6:
drm/modes: Print the mode status in human readable form (2015-02-03 11:
On Tue, Feb 03, 2015 at 01:31:34PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday 03 February 2015 11:30:11 Daniel Vetter wrote:
> > At driver load we need to tell the vblank code about the state of the
> > pipes, so that the logic around reject vblank_get
des them that needs to free them (in ->remove()).
It's not a completely perfect solution yet, but with the registry patch
that I proposed a while back all the remaining issues should go away.
Now if I could get anybody to look at that patch...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/443d0324/attachment.sig>
On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> > >> My initial thought is for dma-buf to not try to prevent something than
> > >> an exporter can actually do.. I
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/cb99ce00/attachment-0001.html>
're
supposed to wait for the display driver to tell you to turn it on via
->prepare() and ->enable().
> +
> + drm_panel_init(&ctx->panel);
> + ctx->panel.dev = dev;
> + ctx->panel.funcs = &s6e3ha2_drm_funcs;
I don't see a use for the _drm in here.
> +static struct of_device_id s6e3ha2_of_match[] = {
static const, please.
> + { .compatible = "samsung,s6e3ha2" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
> +
> +static struct mipi_dsi_driver s6e3ha2_driver = {
> + .probe = s6e3ha2_probe,
> + .remove = s6e3ha2_remove,
> + .driver = {
> + .name = "panel_s6e3ha2",
Please use a - instead of an _ here, for consistency with other drivers.
> + .owner = THIS_MODULE,
No need for this anymore.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/e5c8aa2f/attachment.sig>
On Tue, Feb 03, 2015 at 12:28:14PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> > > >> My initial thought is for d
a static one.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/91aced16/attachment.sig>
d...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/ae9ddb19/attachment-0001.sig>
move = crystalcove_panel_remove,
> + .driver = {
> + .name = "crystal_cove_panel",
> + },
> +};
> +
> +module_platform_driver(crystalcove_panel_driver);
What's also weird here is that you claim this to be a DSI panel, yet you
use a platform driver. The right thing to do would be to instantiate the
device as mipi_dsi_device, with the DSI controller being the parent.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/b3b71794/attachment.sig>
2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux :
> On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
>> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
>> > >> My initial thought is for dma-buf to not try to pr
Hi Joonyoung,
2015-01-29 Joonyoung Shim :
> The exynos_update_plane functions can be called from set_plane as well
> as set_crtc and pageflip. Currently the plane displayed by set_plane
> isn't called exynos_plane_on function and if plane is disabled, it calls
> exynos_plane_off, so it causes dis
nt was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/23f05c0b/attachment.sig>
From: Gustavo Padovan
This issue was caused by the latest exynos_update_plane() clean up
that unified plane operations. After those changes the plane failed
to go the On state. This patch fix this problem by doing correct account
of exynos_crtc->enabled.
Signed-off-by: Gustavo Padovan
---
driv
l driver
that I reviewed earlier.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/d0edcc9d/attachment-0001.sig>
On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter wrote:
> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
>> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
>> >> My initial thought is for dma-buf to not try to prevent something than
>> >> an exporter can actually do.. I think the s
2015-02-02 Joonyoung Shim :
> Hi,
>
> On 01/30/2015 11:44 PM, Gustavo Padovan wrote:
> > Hi Joonyoung,
> >
> > 2015-01-30 Joonyoung Shim :
> >
> >> Hi,
> >>
> >> On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
> >>> From: Daniel Kurtz
> >>>
> >>> The 'mode' is the modeline information which spe
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> >> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> >> >> My initial thought is for dma-buf to not try to prevent so
On Tue, Feb 3, 2015 at 7:28 AM, Russell King - ARM Linux
wrote:
> On Tue, Feb 03, 2015 at 08:48:56AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
>> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
>> > >> My initial thought is for dma-buf to no
On Tue, Feb 03, 2015 at 02:28:26PM +0100, Christian Gmeiner wrote:
> 2015-02-03 13:28 GMT+01:00 Russell King - ARM Linux arm.linux.org.uk>:
> > What I've found with *my* etnaviv drm implementation (not Christian's - I
> > found it impossible to work with Christian, especially with the endless
> >
On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
> Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> drop use of dma-mapping entirely (incl the current call to dma_map_sg,
> which I just need until we can use drm_cflush on arm), and
> attach/detach iommu domains direc
On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> > drop use of dma-mapping entirely (incl the current call to dma_map_sg,
> > which I just need until we c
On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
wrote:
> On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
>> Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
>> drop use of dma-mapping entirely (incl the current call to dma_map_sg,
>> which I just need until
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> > > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> > > drop use of dma-mapping en
On Tue, Feb 03, 2015 at 09:44:57AM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 9:37 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Feb 03, 2015 at 09:04:03AM -0500, Rob Clark wrote:
> >> Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> >> drop use of dma-mapping entir
On Tue, Feb 3, 2015 at 9:41 AM, Russell King - ARM Linux
wrote:
> On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
>> On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
>> > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
>> > drop use of dma-mapping entirely
On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> > I'd go as far as saying that the "DMA API on top of IOMMU" is more
> > intended to be for a system IOMMU for the bus in question, rather
> > than a device-level
On Tue, Feb 3, 2015 at 9:52 AM, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
>> On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
>> > On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
>> > > Since I'm stuck w/ an iommu, instead of bu
On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> > > I'd go as far as saying that the "DMA API on top of IOMMU" is more
> > > intended to b
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/cbbe19b7/attachment.html>
ed
> + * below. The lower 56 bits are assigned as vendor sees fit.
> + */
> +
> +/* Vendor Ids: */
> +#define DRM_FORMAT_MOD_NONE 0
> +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
> +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
> +#define DRM_FORMAT_MOD_VENDOR_NV 0x03
This commits breaks a working configuration here - reverting it let both
version 3.18.4 and 3.18.5 working fine again at a hardened Gentoo Linux
commit ddf6f9a4c9fb1c72ea2e8d196c9a580a8e914dbd
Author: Dave Airlie
Date: Mon Dec 8 13:23:37 2014 +1000
drm/i915: resume MST after reading back
So this has been merged originally in
commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
Author: Seung-Woo Kim
Date: Thu Dec 15 15:40:55 2011 +0900
drm: Add multi buffer plane pixel formats
which hasn't seen a lot of review really. The problem is that it's not
a real pixel format, but just a
On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> > Don't we already have those in the DMA API? dma_sync_*() ?
> >
> > dma_map_sg() - sets up the system MMU and deals with initial cache
> > coherency handling. D
olved.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/79effc58/attachment.html>
dri-devel/attachments/20150203/ae3a0df0/attachment.html>
On Tuesday 03 February 2015 15:54:04 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> > The dma_map_* interfaces assign the virtual addresses internally,
> > using typically either a global address space for all devices, or one
> > address space per
2015-02-03 Daniel Vetter :
> So this has been merged originally in
>
> commit 83052d4d5cd518332440bb4ee63d68bb5f744e0f
> Author: Seung-Woo Kim
> Date: Thu Dec 15 15:40:55 2011 +0900
>
> drm: Add multi buffer plane pixel formats
>
> which hasn't seen a lot of review really. The problem is
On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> I agree for the case you are describing here. From what I understood
> from Rob was that he is looking at something more like:
>
> Fig 3
> CPU--L1cache--L2cache--Memory--IOMMU-device
>
> where the IOMMU controls one or more contexts per d
On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > I agree for the case you are describing here. From what I understood
> > from Rob was that he is looking at something more like:
> >
> > Fig 3
> > CPU--L1cache--L2cache--Memory--IOMMU-
The commit [8975626ea35a: drm/cirrus: allow 32bpp framebuffers for
cirrus drm] broke X modesetting driver because cirrus driver still
provides the full list of modes up to 1280x1024 while the 32bpp can
support only up to 800x600.
We might be able to filter out the invalid modes in mode_valid
callb
Hi Thierry,
Am Dienstag, den 03.02.2015, 14:30 +0100 schrieb Thierry Reding:
> On Thu, Dec 11, 2014 at 06:32:44PM +0100, Philipp Zabel wrote:
> > Many panel data sheets additionally to typical values list allowed ranges
> > for
> > timings such as hsync/vsync lengths, porches, and the pixel clock
On Tue, Feb 03, 2015 at 05:12:40PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 15:54:04 Russell King - ARM Linux wrote:
> > On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> > > The dma_map_* interfaces assign the virtual addresses internally,
> > > using typically eith
On Tue, Feb 03, 2015 at 11:22:01AM -0500, Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > I agree for the case you are describing here. From what I understood
> > from Rob was that he is looking at something more like:
> >
> > Fig 3
> > CPU--L1cache--L2cache--Memory--I
usty/+bug/1355562
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150203/f77155e2/attachment.html>
On Tue, Feb 3, 2015 at 11:58 AM, Russell King - ARM Linux
wrote:
>
> Okay, but switching contexts is not something which the DMA API has
> any knowledge of (so it can't know which context to associate with
> which mapping.) While it knows which device, it has no knowledge
> (nor is there any way
imx-drm internally misused the V4L2_PIX_FMT constants, which are supposed to
describe the pixel format of frame buffers in memory, to describe the pixel
format on the bus between the display controller and the encoder hardware
instead. Now that MEDIA_BUS_FMT constants are available to drm drivers,
Commit 9e74d2926a28 ("staging: imx-drm: add LVDS666 support for parallel
display") describes a 24-bit bus format where three 6-bit components each
take the lower part of 8 bits with the two high bits zero padded. Add a
component-wise padded media bus format RGB666_1X24_CPADHI to support this
connec
From: Boris Brezillion
Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.
Signed-off-by: Boris Brezillon
Acked-by: Mauro Carvalho Chehab
Acked-by: Sakari Ailus
Acked-by: Laurent Pinchart
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Fixed constant value
Sorry about the noise, this time sent to the correct list:
Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe the
pixel format on the parallel bus between display controllers and encoders. Now
that MEDIA_BUS_FMT is available, use that instead.
I'd like to get the V4L2 mai
This patch allows to optionally attach the lvds-channel to a panel
supported by a drm_panel driver using of-graph bindings, instead of
supplying the modes via display-timings in the device tree.
This depends on of_graph_get_port_by_id and uses the OF graph to
link the optional DRM panel to the LDB
This patch adds three new RGB media bus formats that describe
18-bit or 24-bit samples transferred over an LVDS bus with three
or four differential data pairs, serialized into 7 time slots,
using standard SPWG/PSWG/VESA or JEIDA data ordering.
Signed-off-by: Philipp Zabel
Acked-by: Sakari Ailus
The LDB driver changes the attached display interface's input clock mux
to the LDB_DI clock reference. Change it back again when disabling the
LVDS display. Changing back to the PLL5 for example allows to configure
the same DI for HDMI output later.
Signed-off-by: Philipp Zabel
---
drivers/gpu/d
This patch makes the fsl,data-width and fsl,data-mapping device tree
properties optional if a panel is connected to the ldb output port
via the of_graph bindings. The data mapping is determined from the
display_info.bus_format field provided by the panel.
Signed-off-by: Philipp Zabel
---
drivers
This patch adds the media bus format for a 24-bit bus format with three
8-bit YUV components.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/subdev-formats.xml | 37 ++
include/uapi/linux/media-bus-format.h | 3 +-
2
This patch consolidates the different interface_pix_fmt, pixel_fmt, pix_fmt,
and pixfmt variables to a common name "bus_format" wherever they describe the
pixel format on the bus between display controller and encoder hardware.
At the same time, it renames imx_drm_panel_format to imx_drm_set_bus_fo
This patch adds two more 24-bit RGB formats. BGR888 is more or less common,
GBR888 is used on the internal connection between the IPU display interface
and the TVE (VGA DAC) on i.MX53 SoCs.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/subdev-format
From: Gustavo Padovan
Hi,
This series clean ups a few more paths from exynos-drm with the most important
being the removal of the global page flip queue and the removal in driver
internal data (struct *_win_data) that was replicating plane data.
Following these patches comes the first step torw
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
From: Gustavo Padovan
exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
from the underlying layer. However neither one of these layers implement
win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
is pointless.
Signed-off-by: Gustavo Padovan
---
driver
From: Gustavo Padovan
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan
Acked-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/e
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off
From: Daniel Kurtz
The 'mode' is the modeline information which specifies the ideal mode
requested by the mode set initiator (usually userspace).
The 'adjusted_mode' is the actual hardware mode after all the crtcs
and encoders have had a chance to "fix it up".
The adjusted_mode starts as a dupli
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos
From: Gustavo Padovan
Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
unprotect the windows before the commit and protects it after based on
a plane mask tha store which plane will be updated.
For that we create two new exynos_crtc callbacks: .win_protect() and
.win_unprotect(
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_crtc.c
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 55 +++
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c | 4
drivers/gpu/drm/
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos
From: Gustavo Padovan
It is not used outside of the plane scope anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_plane.h | 5 -
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/
From: Gustavo Padovan
Use the pipe var received instead of using always -1 as pipe value.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/
From: Gustavo Padovan
exynos_disable_plane() is used only once now thus remove it and call
exynos_plane_dpms() directly.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exyn
On Tue, Feb 03, 2015 at 05:36:59PM +0100, Arnd Bergmann wrote:
> On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> > On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > > I agree for the case you are describing here. From what I understood
> > > from Rob was that he is looking at somet
1 - 100 of 152 matches
Mail list logo
