https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #29 from notsyncing (song...@gmail.com) ---
I just upgraded to mesa 18.1.3 and kernel 4.17.3. I ran firefox with
GALLIUM_DDEBUG after reboot. It produces these after I opened some tabs and
firefox stopped responsing.
---
Gallium
https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #27 from notsyncing (song...@gmail.com) ---
After 3 days, I managed to reproduce it again with 2 android compilation and
firefox with kernel parameter mem=4096m (I have 16GB memory). I found that it's
easier to reproduce when the
https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #28 from notsyncing (song...@gmail.com) ---
btw, these umr commands are executed after reboot.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #27 from Alexander Mezin (mezin.alexan...@gmail.com) ---
So the patch will only land in 4.19.
Are you going to fix the regression (in amdgpu) for 4.15-4.18 somehow?
--
You are receiving this mail because:
You are watching the
On Sat, Jun 30, 2018 at 3:09 AM, Jernej Škrabec wrote:
> Dne četrtek, 28. junij 2018 ob 03:47:20 CEST je Chen-Yu Tsai napisal(a):
>> Hi,
>>
>> So I'm late to the party, but...
>>
>> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> wrote:
>> > As already described in DT binding, TCON TOP is
On Sat, Jun 30, 2018 at 3:19 AM, Jernej Škrabec wrote:
> Dne četrtek, 28. junij 2018 ob 04:22:36 CEST je Chen-Yu Tsai napisal(a):
>> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> wrote:
>> > Current DW HDMI PHY code never prepares and enables PHY clock after it is
>> > created. It's just
On Sat, Jun 30, 2018 at 3:15 AM, Jernej Škrabec wrote:
> Dne četrtek, 28. junij 2018 ob 03:53:36 CEST je Chen-Yu Tsai napisal(a):
>> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> wrote:
>> > sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
>> > when remote is equal to
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #20 from taij...@posteo.de ---
Yeah, screw this.
I tried again, but because there are several different bugs interacting and
screwing up the boot process, I really can't seem to be able to figure out
which one exactly is borking up
https://bugs.freedesktop.org/show_bug.cgi?id=107045
--- Comment #14 from taij...@posteo.de ---
Yeah, screw this.
I tried again, but because there are several different bugs interacting and
screwing up the boot process, I really can't seem to be able to figure out
which one exactly is borking up
If a encoder name isn't specified for drm_encoder_init() it will try
to construct one based on the incoming encoder_type identifier. If the
caller passes an invalid encoder_type value the lookup could walk right
past the end of the table.
[v2: Use a WARN() at the top of the function as suggested
On Fri, Jun 29, 2018 at 11:48:18AM -0700, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches to using a kasprintf()ed buffer. Return paths are updated
> to free the allocation.
>
> [1]
>
On Fri, Jun 29, 2018 at 10:47:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 29, 2018 at 8:48 PM, Kees Cook wrote:
> > In the quest to remove all stack VLA usage from the kernel[1], this
> > switches to using a kasprintf()ed buffer. Return paths are updated
> > to free the allocation.
> >
> > [1]
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #17 from Roland Scheidegger ---
(In reply to ubizjak from comment #15)
> (In reply to Dave Airlie from comment #14)
> > I think Roland's first patch is correct, just call fold_alu_op2 if we get
> > back 2 sources from fold_assoc.
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.18-rc2 next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Fri, Jun 29, 2018 at 8:48 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> switches to using a kasprintf()ed buffer. Return paths are updated
> to free the allocation.
>
> [1]
>
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #16 from Roland Scheidegger ---
(In reply to Dave Airlie from comment #14)
> I think Roland's first patch is correct, just call fold_alu_op2 if we get
> back 2 sources from fold_assoc. return true is for when we've finished all
>
Eric Anholt writes:
> This has been useful for debugging the window movement lag in X11, and
> I have patches to sysprof that watch these to produce nice
> visualizations.
>
> Signed-off-by: Eric Anholt
I'd love an ack from someone for this.
signature.asc
Description: PGP signature
Boris Brezillon writes:
> From: Boris Brezillon
>
> The transposer block is providing support for mem-to-mem composition,
> which is exposed as a drm_writeback connector in DRM.
>
> Add a driver to support this feature.
>
> Signed-off-by: Boris Brezillon
> +static void
On Fri, Jun 29, 2018 at 3:46 PM, Dirk Hohndel wrote:
> On Fri, Jun 29, 2018 at 03:39:19PM -0400, Alex Deucher wrote:
>> >>
>> >> Did these ever get merged? Do you still need someone to commit them?
>> >
>> > A single one of them got merged :-)
>> >
>> > commit
Boris Brezillon writes:
> From: Boris Brezillon
>
> The transposer block is allowing one to write the result of the VC4
> composition back to memory instead of displaying it on a screen.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
Boris Brezillon writes:
> Mimic what is done in drm_atomic_commit_tail() and call
> drm_atomic_helper_fake_vblank() so that VBLANK events are faked
> when the drm_crtc_state.no_vblank is true. Will be needed when we'll
> add support for the transposer block.
Reviewed-by: Eric Anholt
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #15 from ubiz...@gmail.com ---
(In reply to Dave Airlie from comment #14)
> I think Roland's first patch is correct, just call fold_alu_op2 if we get
> back 2 sources from fold_assoc. return true is for when we've finished all
>
Boris Brezillon writes:
> drm_atomic_helper_wait_for_vblanks() assumes the CRTC will continuously
> generate VBLANK events and the vblank counter will keep increasing.
> While this work for a regular pipeline, it doesn't when you have the
> CRTC is feeding the transposer block, because this
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #5 from Alex Deucher ---
What mode are you trying to run on your monitor? Can you attach your xorg log
if you are using X? Might be related to bug 106959.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #14 from Dave Airlie ---
I think Roland's first patch is correct, just call fold_alu_op2 if we get back
2 sources from fold_assoc. return true is for when we've finished all folding
on that instruction, so I don't think that's
https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #26 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Created attachment 277061
--> https://bugzilla.kernel.org/attachment.cgi?id=277061=edit
Trace process 2
Attached 2 patches if applied to your kernel should tell which
https://bugzilla.kernel.org/show_bug.cgi?id=199749
--- Comment #25 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Created attachment 277059
--> https://bugzilla.kernel.org/attachment.cgi?id=277059=edit
Trace process
--
You are receiving this mail because:
You are watching the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #4 from Clemens Eisserer ---
I am using amdgpu after a rather severe performance regression was introduced
with commit8b3a257851905ff444d981e52938cbf2b36ba830 which hits glamor for
certain workloads pretty hard.
AMDGPU didn't
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #3 from Clemens Eisserer ---
Created attachment 140392
--> https://bugs.freedesktop.org/attachment.cgi?id=140392=edit
dmesg-log + strack traces
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #2 from Clemens Eisserer ---
please find attached the dmesg output including some stack-traces.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=107072
--- Comment #1 from Clemens Eisserer ---
correction: the FHD monitor is not connected via HDMI, but DVI
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=107072
Bug ID: 107072
Summary: 4k hdmi monitor stays black on kaveri [regression]
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
On 26 June 2018 at 07:06, Alex Deucher wrote:
> These functions duplicated functionality which was ultimately added
> to the pci core.
>
> All users of these functions have been ported to using the newly
> exposed pci functionality. These functions are no longer used,
> so drop them.
>
>
On Fri, Jun 29, 2018 at 3:36 PM, Dirk Hohndel wrote:
> On Fri, Jun 29, 2018 at 03:32:23PM -0400, Alex Deucher wrote:
>> On Tue, May 15, 2018 at 3:53 PM, Alex Deucher wrote:
>> > On Mon, May 14, 2018 at 12:31 PM, Daniel Vetter wrote:
>> >> On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel
On Tue, May 15, 2018 at 3:53 PM, Alex Deucher wrote:
> On Mon, May 14, 2018 at 12:31 PM, Daniel Vetter wrote:
>> On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote:
>>> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote:
>>> > > I haven't seen any comments in the week
Hi Jordan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on robclark/msm-next]
[also build test WARNING on v4.18-rc2 next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On Thu, Jun 28, 2018 at 10:10 AM, Thomas Zimmermann
wrote:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Applied. thanks
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #9 from Andrey Grodzovsky ---
(In reply to Andrey Grodzovsky from comment #8)
> (In reply to dwagner from comment #7)
> > (In reply to Andrey Grodzovsky from comment #6)
> > > So with Arch Linux kernel it happens only during S3 but
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #8 from Andrey Grodzovsky ---
(In reply to dwagner from comment #7)
> (In reply to Andrey Grodzovsky from comment #6)
> > So with Arch Linux kernel it happens only during S3 but with
> > amd-staging-drm-next it happens once you
https://bugs.freedesktop.org/show_bug.cgi?id=107065
dwagner changed:
What|Removed |Added
Summary|"BUG: unable to handle |"BUG: unable to handle
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #7 from dwagner ---
(In reply to Andrey Grodzovsky from comment #6)
> So with Arch Linux kernel it happens only during S3 but with
> amd-staging-drm-next it happens once you start X ?
Yes. I know it sounds strange, but it's
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #13 from ubiz...@gmail.com ---
(In reply to Roland Scheidegger from comment #12)
> (In reply to ubizjak from comment #11)
> > The (effectively the same patch as yours) proposed patch would be:
> >
> > diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #19 from Thomas Martitz ---
I tried https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.19-wip but
the issue remains
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #7 from Christian Lanig ---
(In reply to Alexander Tsoy from comment #5)
> (In reply to Christian Lanig from comment #4)
> There are native linux binaries in the linux subfolder.
Yes. You are right. I renamed Northgard.exe and the
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #6 from Eric Engestrom ---
>From a quick search, Haxe can be found on github [1] and its website [2] has
some explanations as well, including how it uses a bytecode VM [3] to work
cross-platform (essentially the same way java does
We currently assumed that an overlay has the same width and height as
the overlay manager. This assumption is incorrect. On some variant the
overlay manager is twice the width that the overlay can handle. We need
to add the appropriate data per variant as well as export a helper
function to
This patch series adds virtual wide plane support to omapdrm driver to
allow the use of display wider than 2048 pixels. This is achieve by
adding replacing the static omapdrm plane to hardware overlay static
mapping with a dynamic allocation method.
This replaces an original early series which
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #5 from Alexander Tsoy ---
(In reply to Christian Lanig from comment #4)
There are native linux binaries in the linux subfolder.
--
You are receiving this mail because:
You are the assignee for the
In the case where we need to support wide-display using more than one
overlay to achieve the needed display resolution, we need to be able to
dynamically assign overlays to planes instead of having the overlays
being statically mapped to planes.
This also means that on occasion where the number
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to check if a fourcc is supported on a given
overlay.
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=105532
Christian Lanig changed:
What|Removed |Added
CC||freedesktop@lanig.email
--- Comment
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture. Add
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 5 +++
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 46
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping
For hangs, dump copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 7 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 58
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be
Add the infrastructure to capture the current state of the GPU and
store it in memory so that it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this should
be extended to capture a much larger set of
Add support for drm_puts() to use seq_puts() to help speed up
up print time for constant strings.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c
Add a put function for the coredump printer to bypass printf()
for constant strings for a speed boost.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 42 +
include/drm/drm_print.h | 2 ++
2 files changed, 44 insertions(+)
diff --git
Add a drm printer suitable for use with the read callback for
devcoredump or other suitable buffer based output format that
isn't otherwise covered by seq_file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 74 +
include/drm/drm_print.h |
Add drm_puts() for a much faster path to print constant strings
into a drm_printer object with memcpy and friends. This can
shave seconds off of really large outputs such as GPU dumps.
If the drm_printer object supports a custom puts function then
use that otherwise fall back to the slower legacy
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be
This is revision 6 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). This patchset fixes a
few bugs and adds a drm_puts() function to print constant strings faster.
The object of this code is to store and provide enough information to debug
software and
On Fri, Jun 29, 2018 at 06:27:28PM +0200, Michel Dänzer wrote:
> On 2018-06-29 06:12 PM, Ville Syrjälä wrote:
> > On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote:
> >> From: Michel Dänzer
> >>
> >> The property size may be controlled by userspace, can be large (I've
> >> seen
On 2018-06-29 06:12 PM, Ville Syrjälä wrote:
> On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> The property size may be controlled by userspace, can be large (I've
>> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
>> physically
https://bugs.freedesktop.org/show_bug.cgi?id=107065
--- Comment #6 from Andrey Grodzovsky ---
(In reply to dwagner from comment #5)
> Interesting: With amd-staging-drm-next, I see the same crash at
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/amdgpu/
>
On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The property size may be controlled by userspace, can be large (I've
> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
> physically contiguous.
I wonder if we should enforce some
https://bugs.freedesktop.org/show_bug.cgi?id=107045
--- Comment #13 from taij...@posteo.de ---
Aaaand I figured out what I did wrong this time... So hopefully third time IS
the charm...
--
You are receiving this mail because:
You are the assignee for the
LGTM
On 2018-06-29 17:20, Emil Velikov wrote:
From: Emil Velikov
Currently we dynamically allocate 16 pointers and reallocate more as
needed.
Instead, allocate the maximum number (256) on stack - the number is
small enough and is unlikely to change in the foreseeable future.
This allows us
From: Emil Velikov
Making the output a little bit easier to parse by human beings.
v2: Add extra whitespace (Eric)
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
Tested-by: Robert Foss (v1)
Reviewed-by: Robert Foss (v1)
Reviewed-by: Eric Engestrom (v1)
---
tests/drmdevice.c | 77
From: Emil Velikov
Introduce a helper which gets the real sysfs path for the given pci
device.
In other words, instead opening the /sys/dev/char/*/device symlink, we
opt for the actual /sys/devices/pci*/*/
It folds three (nearly identical) snprintf's and paves the way of adding
extra devices
From: Emil Velikov
Currently we dynamically allocate 16 pointers and reallocate more as
needed.
Instead, allocate the maximum number (256) on stack - the number is
small enough and is unlikely to change in the foreseeable future.
This allows us to simplify the error handling and even shed a
https://bugs.freedesktop.org/show_bug.cgi?id=107045
--- Comment #12 from taij...@posteo.de ---
OK, so I tried again, and again the result was kinda non-sensical. I think the
problem is that there are more than one problem here - while bisecting, bug
105760 went away at some point, but instead
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #12 from Roland Scheidegger ---
(In reply to ubizjak from comment #11)
> The (effectively the same patch as yours) proposed patch would be:
>
> diff --git a/src/gallium/drivers/r600/sb/sb_expr.cpp
>
Ping on the drm and amdgpu patches.
Alex
On Mon, Jun 25, 2018 at 5:06 PM, Alex Deucher wrote:
> This series exports some pcie helper functions for use by drivers and
> fixes up the amdgpu and radeon drivers to use this core functionality
> rather than the duplicated functionality in the drm.
On Fri, Jun 29, 2018 at 10:27 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The property size may be controlled by userspace, can be large (I've
> seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
> physically contiguous.
>
> Signed-off-by: Michel Dänzer
From: Michel Dänzer
The property size may be controlled by userspace, can be large (I've
seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
physically contiguous.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/drm_property.c | 6 +++---
1 file changed, 3 insertions(+),
Gentle ping on this serie,
Thanks
Benjamin
2018-06-05 15:54 GMT+02:00 Benjamin Gaignard :
> Thanks to the various atomic_print_state hooks in drm structure all
> custom debugfs code could be remove from sti driver (~ -330 lines).
>
> This patchset does two addtion in drm core:
> - printing
Hardware allow to read the position in scanout buffer so
we can use this information to make wait of vblank more accurate.
Active area bounds (start, end, total height) have already been
computed and written in ltdc registers, read them and get the
current line position to compute vpos value.
On Fri, 2018-06-29 at 12:08 +0200, Bartlomiej Zolnierkiewicz wrote:
> Hi Gustavo,
>
> On Thursday, June 28, 2018 07:44:38 PM Gustavo Padovan wrote:
> > Hi Bartlomiej,
> >
> > On Thu, 2018-06-28 at 15:50 +0200, Bartlomiej Zolnierkiewicz wrote:
> > > On Thursday, June 28, 2018 11:03:48 AM Hans de
Hi,
On 29-06-18 14:10, Ville Syrjälä wrote:
On Fri, Jun 29, 2018 at 02:05:58PM +0200, Hans de Goede wrote:
Hi,
On 29-06-18 13:51, Ville Syrjälä wrote:
On Fri, Jun 29, 2018 at 01:32:58PM +0200, Hans de Goede wrote:
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
Remove the modes timings tables for DMT modes and calculate the HW
paremeters from the modes timings.
Switch the DMT modes pixel clock calculation out of the static frequency
list to a generic calculation from a range of possible PLL dividers.
This setup permits setting non-CEA modes like :
-
On 21.06.2018 14:32, Sandeep Panda wrote:
> Innolux TV123WAM is a 12.3" eDP display panel with
> 2160x1440 resolution, which can be supported by simple
> panel driver.
Are you sure this is Innolux? Quick grep on Internet finds only BOE
panel with this TV123WAM[1].
[1]:
On Fri, Jun 29, 2018 at 02:05:58PM +0200, Hans de Goede wrote:
> Hi,
>
> On 29-06-18 13:51, Ville Syrjälä wrote:
> > On Fri, Jun 29, 2018 at 01:32:58PM +0200, Hans de Goede wrote:
> >> Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
> >> error: "Failed to own gpio for
Hi,
On 29-06-18 13:51, Ville Syrjälä wrote:
On Fri, Jun 29, 2018 at 01:32:58PM +0200, Hans de Goede wrote:
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch
On 27.06.2018 11:57, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
>bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed by corresponding
On Fri, Jun 29, 2018 at 01:32:58PM +0200, Hans de Goede wrote:
> Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
> error: "Failed to own gpio for panel control" on BYT/CHT devices where
> pwm_blc == PPS_BLC_PMIC.
>
> Note this patch is untested as I don't have hardware
On Fri, Jun 29, 2018 at 01:17:22PM +0200, Boris Brezillon wrote:
> Hello,
>
> This is the second version of this series adding writeback support
> to the VC4 display engine.
>
> This version is based on drm-misc-next and include a bunch of
> modifications to core that I had to add to make it
On Fri, Jun 29, 2018 at 01:17:18PM +0200, Boris Brezillon wrote:
> Now that we have a way to fake VBLANK events when requested by the CRTC
> hook it up to the generic commit_tail() helpers.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
> ---
>
On Fri, Jun 29, 2018 at 01:17:17PM +0200, Boris Brezillon wrote:
> In some cases CRTCs are active but are not able to generating events, at
> least not at every frame at it's expected to.
> This is typically the case when the CRTC is feeding a writeback connector
> that has no job queued. In this
On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> Other atomic hooks are passed state objects, let's change this one to
> be consistent.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> include/drm/drm_modeset_helper_vtables.h | 4
Hi,
On 19-06-18 22:18, Hans de Goede wrote:
Hi All,
This patch-set is the result of the work I've been doing recently to
give people a smooth "flickerfree" boot experience where the display
keeps displaying the logo put there by the firmware until it smoothly
fades into the Linux GUI (e.g.
Reset must be properly assert before deassert.
This is important if there is an early boot splash screen
before the kernel start up.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c
On Fri, Jun 29, 2018 at 01:17:15PM +0200, Boris Brezillon wrote:
> Other atomic hooks are passed state objects, let's change this one to
> be consistent.
>
> Signed-off-by: Boris Brezillon
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
>
Filter the requested mode pixel clock frequency according
to the pad maximum supported frequency.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 16
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git
Other atomic hooks are passed state objects, let's change this one to
be consistent.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
include/drm/drm_modeset_helper_vtables.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
Hello,
This is the second version of this series adding writeback support
to the VC4 display engine.
This version is based on drm-misc-next and include a bunch of
modifications to core that I had to add to make it work on VC4.
Feel free to comment on those modifications.
On the driver side, no
Mimic what is done in drm_atomic_commit_tail() and call
drm_atomic_helper_fake_vblank() so that VBLANK events are faked
when the drm_crtc_state.no_vblank is true. Will be needed when we'll
add support for the transposer block.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_kms.c | 2
1 - 100 of 144 matches
Mail list logo
