https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #64 from Tamás Tóth ---
(In reply to poggif from comment #63)
> (In reply to poggif from comment #62)
> > Don't know how and why but I'm trying now the latest CentOS 7.3 (installed
> > with kde + development tools) and no random black
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #63 from pog...@hotmail.it ---
(In reply to poggif from comment #62)
> Don't know how and why but I'm trying now the latest CentOS 7.3 (installed
> with kde + development tools) and no random black screen, no low resolution,
> no false
https://bugzilla.kernel.org/show_bug.cgi?id=102401
Maxqia (pub...@maxqia.com) changed:
What|Removed |Added
Attachment #238501|0 |1
is obsolete|
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
Ch
https://bugs.freedesktop.org/show_bug.cgi?id=98513
Shawn Starr changed:
What|Removed |Added
Summary|[AMDGPU][CIK] Unable to |[AMDGPU][CIK] Unable to
https://bugs.freedesktop.org/show_bug.cgi?id=98513
Shawn Starr changed:
What|Removed |Added
Summary|[REGRESSION][drm-next-4.10- |[AMDGPU][CIK] Unable to
https://bugs.freedesktop.org/show_bug.cgi?id=97861
--- Comment #6 from Thomas Hume ---
Forgot the information.
Linux 4.9.11-1-ARCH, X Server 1.19.1 over a R9 280X using amdgpu
Xorg.0.log: http://pastebin.com/9PMrcKba
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97861
--- Comment #5 from Thomas Hume ---
Same problem here with my HDMI screen. Everything works fine (GNOME Wayland
session and all) until I start an X server (not XWayland, actual X server from
a "GNOME on Xorg" session) at which point the screen go
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #62 from pog...@hotmail.it ---
Don't know how and why but I'm trying now the latest CentOS 7.3 (installed with
kde + development tools) and no random black screen, no low resolution, no
false start, no proprietary Crimson driver instal
Hi Laurent,
On Fri, Mar 3, 2017 at 8:17 PM, Laurent Pinchart
wrote:
> On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
>> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
>> > What's in the reset specifier ?
>>
>> That depends on the reset provider.
>>
>> See "[v2,1/4] dt-bindings:
Hi Geert,
On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> >> Document the optional properties for describing module resets, to
> >> support resetting display channels a
On 03/03/2017 08:45 AM, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
>>> Hi,
>>>
>>> There's been some recent discussions[1] about Ion-like frameworks. There's
>>> apparently interest i
On 03/03/2017 08:25 AM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patches.
>
> On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works rea
Hi Geert,
On Friday 03 Mar 2017 20:04:26 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven wrote:
> >>> +Optional properties:
> >>> + - resets: A list of phandles + reset-specifier pairs, one for each
> >>> entry in
> >>
> >> s/phandlers/phandle/
> >
> > You're seei
On 03/03/2017 02:33 AM, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
>>
>> Currently, all heaps are compiled in all the time. In switching to
>> a better platform model, let's allow these to be compiled out for good
>> measure.
>>
>> Signed-off-by: Laura Abbo
On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven wrote:
>>> +Optional properties:
>>> + - resets: A list of phandles + reset-specifier pairs, one for each entry
>>> in
>>
>> s/phandlers/phandle/
>
> You're seeing typos that do not exist ;-)
Ah, you mean plural vs. singular?
You're right, but I
Hi Laurent,
On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart
wrote:
> On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
>> Document the optional properties for describing module resets, to
>> support resetting display channels and LVDS encoders on R-Car Gen2 and
>> Gen3.
>>
>> Signed-off-b
On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>>
On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>>> Now that we call dma_map in the dma_buf API callbacks there is no need
>>> to use the existing cache APIs. Remov
On 03/03/2017 12:18 AM, Hillf Danton wrote:
>
> On March 03, 2017 5:45 AM Laura Abbott wrote:
>>
>> +static struct sg_table *dup_sg_table(struct sg_table *table)
>> +{
>> +struct sg_table *new_table;
>> +int ret, i;
>> +struct scatterlist *sg, *new_sg;
>> +
>> +new_table = kzalloc
On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
>> ensure
Am Montag, den 20.02.2017, 16:20 +0100 schrieb Philipp Zabel:
> On Fri, 2017-02-17 at 19:28 +0100, Lucas Stach wrote:
> > This adds support for the i.MX6 QuadPlus PRE units. Currently only
> > linear prefetch into SRAM is supported, other modes of operation
> > like the tiled-to-linear conversion w
On Fri, Mar 03, 2017 at 05:48:19PM +, Alexey Brodkin wrote:
> Hi Liviu,
>
> On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > >
> > > - /* find the encoder node and initialize it */
> > > - encoder_node = of_parse_pha
On 03/03/2017 05:29 AM, Michal Hocko wrote:
> On Thu 02-03-17 13:44:32, Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works reasonablly well.
>> This series does what should be the fina
From: Kieran Bingham
The interface to configure the LIF in the VSP1 requires adapting the
function prototype for any changes. This makes extending the interface
difficult.
Change the function prototype to pass a structure which can be easily
extended.
This changes the means of disabling the pip
From: Kieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
---
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.
Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was origina
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
Ch
From: Neil Armstrong
The Synopsys Designware HDMI TX Controller does not enforce register
access on platforms instanciating it. The current driver supports two
different types of memory-mapped flat register access, but in order to
support the Amlogic Meson SoCs integration, and provide a more gen
Hello,
This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.
The series starts with a few cleanups and small fixes. Patch 01/10 just
removes unused code, patch 02/10 moves the color converter code out of the PHY
configure
When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the
From: Neil Armstrong
If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.
Reviewed-by: Jose Abreu
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
Tested-by: Neil
The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.
The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY
Most of the hdmi_phy_test_*() functions are unused. Remove them.
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
Tested-by: Nickey Yang
---
drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers
The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited
The color space converter isn't part of the PHY, move its configuration
out of PHY code.
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
dif
Hi Jose,
On Friday 03 Mar 2017 16:59:51 Jose Abreu wrote:
> On 03-03-2017 16:50, Laurent Pinchart wrote:
> > The driver is already made of 5 separate source files. Move it to a
> > newly created directory named synopsys where more Synopsys bridge
> > drivers can be added later (for the DisplayPort
Hi Jose,
(CC'ing Archit)
On Friday 03 Mar 2017 15:57:57 Jose Abreu wrote:
> On 02-03-2017 15:38, Laurent Pinchart wrote:
> > On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
> >> On 02-03-2017 13:41, Laurent Pinchart wrote:
> Hmm, this is kind of confusing. Why do you need a phy_ops and
>
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kco
Hi Daniel,
On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> >
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
>
On 03/03/2017 05:39 PM, Jose Abreu wrote:
> Hi Neil,
>
>
> On 03-03-2017 11:31, Neil Armstrong wrote:
>>
>> Sure, but I was struggling about finding an equivalence.
>>
>> How should I replace these ?
>>
>> DW_HDMI_ENC_FMT_RGB
>> DW_HDMI_ENC_FMT_YCBCR444
>> DW_HDMI_ENC_FMT_YCBCR422_16BITS
>> DW_HD
Hi Laura,
Thank you for the patch.
On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device stru
Hi Daniel,
On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> > Now that we call dma_map in the dma_buf API callbacks there is no need
> > to use the existing cache APIs. Remove the sync ioctl and the existing
> > bad dma_sync call
Hi Laura,
Thank you for the patch.
On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
> Technically, calling dma_buf_map_attachment should return a buffer
> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
> ensure this happens. As a side effect, this lets Ion buffers take
>
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> We used to use "encoder-slave" property in PGU's
> Device Tree node to refer to the encoder, but since there's
> a way to find it with some code smarts we get rid of
> obviously extra complication in PGU node.
>
> Again inspired by
Hi Laura,
Thank you for the patches.
On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote:
> Hi,
>
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final cl
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
R
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by:
On Fri, Mar 03, 2017 at 03:30:35PM +0300, Alexey Brodkin wrote:
> This change adopts debugfs usage for outputting useful data.
> As of today we print:
> * Mode and real HW clock values
> * Standard FB info
>
> Code is heavily borrowed from ARM's HDLCD thus adding Liviu in Cc.
FWIW: Reviewed-by:
Regards
Shashank
On 3/3/2017 6:31 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-03-03 at 17:33 +0530, Sharma, Shashank wrote:
Thanks for the review Ander. My comments inline.
Shashank
On 3/3/2017 3:22 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-03-03 at 11:59 +0530, Shashank
On Fri, Mar 3, 2017 at 2:07 AM, Julia Lawall wrote:
> The if on line 1327 only exists to allow the comment in the else case.
> Perhaps check on whether it is really useful.
>
> The lines also look quite long. Perhaps this could be cleaned up as well.
This file is machine generated by the hardwar
Hi Geert,
Thank you for the patch.
On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> Document the optional properties for describing module resets, to
> support resetting display channels and LVDS encoders on R-Car Gen2 and
> Gen3.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documen
Hi Jacopo,
Thank you for the patch.
On Friday 03 Mar 2017 13:58:56 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp initialization stub routine is
> called. Return an error from that stub to fail expl
Hi Jacopo,
On Friday 03 Mar 2017 13:37:56 jacopo mondi wrote:
> On 03/03/2017 12:26, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> >> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> >> DRM/KMS. If VSP support is not compiled in, vsp1 ini
Convert if-statements to switch statement. Removes
duplicated code.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/
The output stage of the mixer uses YCbCr for the internal
computations, which is the reason that some registers take
YCbCr related data as input. In particular this applies
to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
Document the formatting of the data which we write to
these registers.
Wh
Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.
v2: Reuse drm_crtc_wait_one_vblank
Update l
Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.
This is only done if this CRTC is currently using the eDP connector.
v3: Remove superfluous check on rockchip_crtc_state->output_type
v6: Remove superfluous variable
Signed-off-by: Tomeu
Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.
v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul)
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 22 +++
Hi,
this series builds up on the API for exposing captured CRCs through
debugfs.
It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.
With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.
In this v6, the back
This backpointer allows DP helpers to access the crtc it's currently
being used for.
v6: Have the backpointer be to drm_crtc (Sean Paul)
Signed-off-by: Tomeu Vizoso
---
include/drm/drm_dp_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/d
On Fri, 2017-03-03 at 17:33 +0530, Sharma, Shashank wrote:
> Thanks for the review Ander. My comments inline.
>
> Shashank
>
> On 3/3/2017 3:22 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote:
> > > Geminilake platform sports a native HDMI 2.0 c
2017-03-03 11:27 GMT+01:00 Daniel Vetter :
> On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
>> > Hi,
>> >
>> > There's been some recent discussions[1] about Ion-like frameworks. There's
>> > apparently interest in just
Hi Jose,
On Friday 03 Mar 2017 10:05:36 Jose Abreu wrote:
> On 03-03-2017 09:07, Neil Armstrong wrote:
> > The problem is that the HPD/RxSense is tied to this phy_mask and glued
> > into the dw-hdmi driver.
> >
> > The *real* solution would be to completely separate the HPD/RxSense irq
> > handli
Thanks for the review Ander. My comments inline.
Shashank
On 3/3/2017 3:22 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
On Friday, 2017-03-03 14:04:26 +0300, Dan Carpenter wrote:
> On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
> > static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
> > *attachment,
> > enum dma_data_direction direction)
> > {
> >
This reset is required in order to fully reset the internal state of the
MIPI controller.
Signed-off-by: John Keeping
---
On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote:
> On Fri, Feb 24, 2017 at 12:55:06PM +, John Keeping wrote:
> > + /*
> > +* Note that the reset was not define
On 03/02/2017 04:45 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 16:29:31 Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if
Hi Jacopo,
Thank you for the patch.
On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp1 initialization stub routine is
> called, leading to invalid memory accesses later o
On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
> static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
> *attachment,
> enum dma_data_direction direction)
> {
> struct dma_buf *dmabuf = attachment->dmabuf;
> struct ion_
On Thu, Mar 02, 2017 at 01:44:44PM -0800, Laura Abbott wrote:
>
> Practiaclly speaking, most Ion heaps are either going to be available
> all the time (system heaps) or found based off of the reserved-memory
> node. Parse the CMA and reserved-memory nodes to assign the heaps.
>
> Signed-off-by: L
On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
>
> Currently, all heaps are compiled in all the time. In switching to
> a better platform model, let's allow these to be compiled out for good
> measure.
>
> Signed-off-by: Laura Abbott
I'm not the biggest fan of making everything K
On Thu, Mar 02, 2017 at 01:44:39PM -0800, Laura Abbott wrote:
>
> Device specific platform support has been haphazard for Ion. There have
> been several independent attempts and there are still objections to
> what bindings exist right now. Just remove everything for a fresh start.
>
> Signed-off
On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> >
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
> >
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_canvas.c | 4 +++-
drivers/gpu/drm/meson/meson_drv.c | 5 +++--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 25 +
drivers/gpu/drm/meson/meson_vclk.c| 22 +++---
drivers/gpu/drm/meson/meson
To be aligned with the other DRM drivers, this patchset converts the
actual drivers documentation to RST format, adds a top RTS meson file
and adds an entry in the gpu/index.rst file.
This patchser depends on the HDMI patchset at [1]
Sample output can be found at [2]
[2] http://people.freedeskto
Signed-off-by: Neil Armstrong
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/meson.rst | 61 +
2 files changed, 62 insertions(+)
create mode 100644 Documentation/gpu/meson.rst
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/ind
On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> Hi,
>
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>
>
> Now that we call dma_map in the dma_buf API callbacks there is no need
> to use the existing cache APIs. Remove the sync ioctl and the existing
> bad dma_sync calls. Explicit caching can be handled with the dma_buf
> sync API.
>
On Fri, 2017-03-03 at 11:59 +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor sup
On Thu, 2017-03-02 at 08:25 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 3/1/2017 8:41 PM, Ville Syrjälä wrote:
> > On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> > > Geminilake platform sports a native HDMI 2.0 controller, and is
> > > capable of driving pi
On 03/02/2017 05:18 PM, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 16:29:32 Neil Armstrong wrote:
>> The HDMI TX controller support HPD and RXSENSE signaling from the PHY
>> via it's STAT0 PHY interface, but some vendor PHYs can manage these
>> sig
On Thu, Mar 2, 2017 at 10:36 PM, Mauro Carvalho Chehab
wrote:
> Em Thu, 2 Mar 2017 18:29:39 -0300
> Mauro Carvalho Chehab escreveu:
>
>> Em Thu, 2 Mar 2017 16:40:02 +0100
>> Daniel Vetter escreveu:
>>
>> > From: Markus Heiser
>> >
>> > This patch brings scalable figure, image handling and a co
88 matches
Mail list logo
