On Sat, Aug 04, 2018 at 07:30:45PM -0500, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use true or false
> instead of an integer value.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Huang Rui
On Sat, Aug 04, 2018 at 07:27:02PM -0500, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use true or false
> instead of an integer value.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Looks good for me.
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch use layer_nr function to get layer number to init plane
>
> When plane init in crtc create,
> it use the number of OVL layer to init plane.
> That's OVL can read 4 memory address.
>
> For mt2712 third ddp, it use RDMA to
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add callback function to return RDMA layer number
>
> RDMA always has one layer.
>
> Signed-off-by: Stu Hsieh
I would like to remove the term 'callback' because this is just function
pointer rather than callback
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add callback function to return OVL layer number
>
> For now, MT8173, MT2712, MT2701 OVL all has 4 layer.
>
> Signed-off-by: Stu Hsieh
I would like to remove the term 'callback' because this is just function
pointer
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add function to get layer number for component
>
> Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add YUYV/UYVY color format support for RDMA
> and transform matrix for YUYV/UYVY.
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 15 +++
> 1 file changed, 15 insertions(+)
>
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add RGB color format support for RDMA,
> including RGB565, RGB888, RGBA and ARGB.
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 41
>
> 1 file
Hi, Stu:
On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> This patch add memory mode for RDMA and layer_config for RDMA
>
> If use RDMA to read data from memory, it should set memory mode to RDMA
>
> Layer config set the data address and pitch to RDMA from plane setting.
>
>
On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote:
> info.index can be indirectly controlled by user-space, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c:1232
Boris Brezillon writes:
> On Mon, 06 Aug 2018 13:02:48 -0700
> Eric Anholt wrote:
>
>> Boris Brezillon writes:
>>
>> > From: Eric Anholt
>> >
>> > Y_OFFSET field starts at bit 8 not 7.
>> >
>> > Signed-off-by: Eric Anholt
>> > Signed-off-by: Boris Brezillon
>>
>> Your changes in this
Hi Dave,
Initial fixes for 4.19. Starting by the one where gvt compilation gets
broken after a silent conflict between next and fixes.
Here goes drm-intel-next-fixes-2018-08-06:
- Fix gvt compilation broken on a silent conflict on fixes vs next merge
- Fix runtime PM for LPE audio
- Revert on
https://bugs.freedesktop.org/show_bug.cgi?id=100745
--- Comment #15 from Kimmo ---
(In reply to Kimmo from comment #14)
> Confirming still similar problem (Screen stays black while trying resume
> from suspend)
> 2x DELL u2415h + display port daisy chain + RX480 (amdgpu 18.0.1-2)
Actually need
The VENC encoder modifies the requested video mode to match the NTSC or
PAL timings (or reject the video mode completely) in the .set_timings()
operation. This should be performed in the .check_timings() operation
instead. Move the fixup.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian
The bus flags stored in omap_dss_device instances are used to fixup the
video mode before setting it, to honour constraints that can't be
expressed through drm_display_mode. The fixup occurs in the CRTC mode
set operation and the resulting video mode is stored internally in the
CRTC. It is then
The SDI encoder modifies the pixel clock of the requested video mode to
take the limitations of the PLL into account in the .enable() operation.
This should be performed in the .check_timings() operation instead. Move
the fixup.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
The DSI encoder modifies the passed videomode to take the requirements
of the internal DISPC-DSI bus into account in the .enable_video_output()
operation. This should be performed in the .check_timings() operation
instead. There is however no .check_timings() operation as the DSI
encoder uses a
The video timings are stored in the CRTC structure by the
omap_crtc_dss_set_timings() function, called by dss_mgr_set_timings()
from the .enable() operation of the internal encoders. This instead
belongs to the .set_timings() code paths. Move the
omap_crtc_dss_set_timings() calls accordingly.
The two functions implement the .set_timings() and .check_timings()
operations. Rename them to hdmi_disply_set_timings() and
hdmi_display_check_timings() respectively to match the operations names
and make searching the source code easier.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian
Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart
Panels drivers store their timings in a device data structure field that
is initialized at probe time, either from hardcoded values or from
firmware-supplied values. Those timings are then reported through the
.get_timings() operation to construct the panel display mode.
The panel timings are
Instead of determining the connector type from the type of the display's
omap_dss_device and passing it to the omap_connector_init() function,
move the type determination code to omap_connector.c and remove the type
argument to the connector init function. This moves code to a more
natural
The video mode is aleady fixed up by the .check_timings() operation,
there's no need to repeat that when enabling the DPI output.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 12 +---
1 file changed, 1 insertion(+), 11
The encoder enable operation currently performs mode fixup and mode
setting for all omap_dss_device instances in the display pipeline. There
are dedicated encoder operations for those operations (respectively
.atomic_check() and .mode_set()), but they are not used for this
purpose.
Move the mode
Constify many pointers to struct videomode, as well as pointers to
container structures, to ensure the video mode isn't modified after
the .check_timings() operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 8
Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings()
The .check_timings() operation is present in all panels and connectors.
The fallback that uses .get_timings() in the absence of .check_timings()
is thus unneeded.
While it could be argued that the fallback implements a useful check
that should be extended to cover all fixed-resolution panels, the
The .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
The drm_connector implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Refactoring of the timings operations
will require access to the output omap_dss_device. To prepare for that,
pass it to the
The analog TV, DVI and HDMI connectors all report timing information
through the .get_timings() information.
For analog TV outputs the information is queried from the encoder, so
the operation is unused. Remove it.
For HDMI outputs the display pipeline provides EDID capability, so the
operation
Hello,
This patch series reworks all the timing-related operations (.get_timings(),
.set_timings() and .check_timings()) as a step toward moving from
omap_dss_device to drm_bridge.
All timing-related operations are called by the omapdrm driver on the
omap_dss_device at the end of display
Timings for the TV output are currently reported by the analog TV
connector. This has the disadvantage of having to handle timing-related
operations in a connector omap_dss_device that has, at the hardware
level, no knowledge of any timing information.
Implement the .get_timings() operation in
Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.
Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to
The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
The omap_dss_device .set_timings() operations are called directly from
omap_encoder_update(), and indirectly from the omap_dss_device .enable()
operation. The latter is called from omap_encoder_enable(), right after
calling omap_encoder_update(). The .set_timings() operation it thus
called twice
The omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
On Fri, Aug 3, 2018 at 8:01 PM, Jia-Ju Bai wrote:
> radeon_test_ring_sync() and radeon_test_ring_sync2() are never
> called in atomic context.
> They call mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
>
> This is found by a static analysis tool named
On Fri, Aug 3, 2018 at 8:33 PM, Jia-Ju Bai wrote:
> si_pcie_gen3_enable() is never called in atomic context.
> It calls mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
>
> This is found by a static analysis tool named DCNS written by myself
>
>
Various functions that need to differentiate between omap_dss_device
instances corresponding to displays and to internal encoders use the
omap_dss_device.driver field, which is only set for display instances.
This gets in the way of the omap_dss_device operations refactoring.
Replace that with a
On Fri, Aug 3, 2018 at 8:25 PM, Jia-Ju Bai wrote:
> cik_pcie_gen3_enable() is never called in atomic context.
> It calls mdelay() to busily wait, which is not necessary.
> mdelay() can be replaced with msleep().
>
> This is found by a static analysis tool named DCNS written by myself.
>
>
The drm_encoder implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Clean up of the HDMI mode and infoframe
handling will require access to the output omap_dss_device. To prepare
for that, pass it
Instead of calling the EDID read operation (.read_edid()) recursively
from the display device back to the first device that provides EDID read
support, iterate over the devices manually in the DRM connector code.
This moves the complexity to a single central location and simplifies
the logic in
The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
operations are called recursively from the display device back to the
HDMI encoder. This isn't required, as all components other than the HDMI
encoder just forward the operation to the previous component in the
chain. Call the
On HDMI outputs, CEC support requires notification of HPD signal
deassertion. The HPD signal can be handled by various omap_dss_device
instances in the pipeline, and all of them forward HPD events to the
OMAP4 internal HDMI encoder.
Knowledge of the DSS internals need to be removed from the
The CRTC mode set implementation needs to access the omap_dss_device for
the pipeline display. To do so, it iterates over all pipelines to find
the one that contains an encoder corresponding to the CRTC, and request
the display device from the encoder. That's a very complicated dance
when the CRTC
The HPD-related omap_dss_device operations are now only called when the
device supports HPD. There's no need to duplicate that check in the
omap_dss_device drivers. The .register_hpd_cb() operation can as a
result be turned into a void operation.
Signed-off-by: Laurent Pinchart
Reviewed-by:
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 56 --
1 file changed, 21
The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
and disable hot-plug detection at omapdrm probe and remove time. This is
required to avoid reporting hot-plug detection events before the DRM
infrastructure is ready to accept them, as that could result in crashes
or other
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver. Rename the
nreset_gpio field to reset_gpio to
Instead of calling the hot-plug detection callback registration
operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
from the display device back to the first device that provides hot plug
detection support, iterate over the devices manually in the DRM
connector code. This moves
The omapdrm driver checks at suspend and resume time whether the
displays it operates on have their driver operations set. This check is
unneeded, as all display drivers set the driver operations field at
probe time and never touch it afterwards. This is furthermore proven by
the dereferencing of
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver.
Signed-off-by: Laurent Pinchart
Reviewed-by:
The driver doesn't use GPIOs and thus doesn't need to include the
linux/gpio.h header.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git
When an omap_dss_device operation can be implemented in multiple places
in a chain of devices, it is important to find out which device to
address to perfom the operation. This is currently done by calling the
operation on the display device at the end of the chain, and recursively
delagating the
Instead of calling the .detect() operation recursively from the display
device back to the first device that provides hot plug detection
support, iterate over the devices manually in the DRM connector
.detect() implementation. This moves the complexity to a single central
location and simplifies
Various functions that need to differentiate between omap_dss_device
instances corresponding to displays and to internal encoders use the
omap_dss_device.driver field, which is only set for display instances.
This gets in the way of the omap_dss_device operations refactoring.
Replace that with a
omap_dss_device instances have two ops structures, omap_dss_driver and
omap_dss_device_ops. The former is used for devices at the end of the
pipeline (a.k.a. display devices), and the latter for intermediate
devices.
Having two sets of operations isn't convenient as code that iterates
over
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
The reset GPIO is mandatory, so drop conditional tests through the
driver. The qvga GPIO is unused, so drop it completely.
Signed-off-by: Laurent Pinchart
Reviewed-by:
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 57 ---
1 file changed, 20
The .get_mirror() and .set_mirror() omap_dss_driver operations are
implemented by the panel-tpo-td043mtea1 driver but are never used.
Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 25 ++
Hello,
This patch series reworks all the HPD-related operations (detection, EDID
read, HPD callback (un)registration and HPD enable/disable) as a step toward
moving from omap_dss_device to drm_bridge.
All HPD-related operations are called by the omapdrm driver on the
omap_dss_device at the end
The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate()
omap_dss_driver operations are not used. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
On Wed 01-08-18 10:46:35, Dmitry Vyukov wrote:
> I guess it would be useful to have such extensive comment for each
> SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the
> tricky aspects are handled.
>
> For example, the one in jbd2 is interesting because it memsets the
> whole
On Mon, 06 Aug 2018 13:02:48 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > From: Eric Anholt
> >
> > Y_OFFSET field starts at bit 8 not 7.
> >
> > Signed-off-by: Eric Anholt
> > Signed-off-by: Boris Brezillon
>
> Your changes in this series have my r-b. Time to add your ack
Boris Brezillon writes:
> From: Eric Anholt
>
> Y_OFFSET field starts at bit 8 not 7.
>
> Signed-off-by: Eric Anholt
> Signed-off-by: Boris Brezillon
Your changes in this series have my r-b. Time to add your ack to my
changes in this series and push?
signature.asc
Description: PGP
Alexandru Gheorghe writes:
> A new helper function(__drm_atomic_helper_plane_reset) has been added
> for linking a plane with its state and resetting the core
> properties(alpha, rotation, etc.) to their default values.
> Use that instead of duplicating the logic.
>
>
On Mon, Aug 6, 2018 at 3:34 PM, Lukas Wunner wrote:
> On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
>> You did mention in the review of one of my other patches that we should avoid
>> disabling polling during runtime suspend, and you're definitely right. I feel
>> a bit silly for
On Mon, Aug 06, 2018 at 09:34:57PM +0200, Lukas Wunner wrote:
> On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
> > You did mention in the review of one of my other patches that we should
> > avoid
> > disabling polling during runtime suspend, and you're definitely right. I
> > feel
On Mon, Aug 06, 2018 at 03:15:31PM -0400, Lyude Paul wrote:
> You did mention in the review of one of my other patches that we should avoid
> disabling polling during runtime suspend, and you're definitely right. I feel
> a bit silly for not remembering that since I was the one who made it so that
On Mon, 2018-08-06 at 11:15 +0200, Daniel Vetter wrote:
> On Wed, Aug 01, 2018 at 05:14:57PM -0400, Lyude Paul wrote:
> > When we disable hotplugging on the GPU, we need to be able to
> > synchronize with each connector's hotplug interrupt handler before the
> > interrupt is finally disabled. This
On Mon, 2018-08-06 at 10:43 +0200, Daniel Vetter wrote:
> On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote:
> > I'm sure I don't need to tell you that fb_helper's locking is a mess.
> > That being said; fb_helper's locking mess can seriously complicate the
> > runtime suspend/resume
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #25 from Patrik Kullman ---
Any idea when this will go upstream?
Anywhere to track it?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Fri, Aug 3, 2018 at 1:50 PM Sean Paul wrote:
>
> On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote:
> > On 3 August 2018 at 16:06, Martin Fuzzey
> > wrote:
> > > Hi Emil,
> > >
> > > On 03/08/18 14:35, Emil Velikov wrote:
> > >>
> > >> Hi Martin,
> > >>
> > >> On 1 August 2018 at
https://bugs.freedesktop.org/show_bug.cgi?id=107493
--- Comment #3 from Sebastian Luncan ---
Created attachment 140985
--> https://bugs.freedesktop.org/attachment.cgi?id=140985=edit
dmesg
The mainboard has two video ports, DVI and HDMI. I use the DVI port. I can test
the HDMI port too if that
https://bugs.freedesktop.org/show_bug.cgi?id=107432
--- Comment #8 from Robert Strube ---
(In reply to Michel Dänzer from comment #6)
> Well, https://bugs.freedesktop.org/attachment.cgi?id=140903 definitely shows
> an amdgpu issue exacerbating the memory pressure situation — it tries to
>
https://bugs.freedesktop.org/show_bug.cgi?id=107493
--- Comment #2 from Sebastian Luncan ---
Created attachment 140984
--> https://bugs.freedesktop.org/attachment.cgi?id=140984=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the
On Mon, Aug 6, 2018 at 1:35 PM Jordan Crouse wrote:
>
> This is an initial version of support for the Adreno a6xx GPU family starting
> with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845
> code that would be needed to actually bring up a device and it is also in
> advance
This is an initial version of support for the Adreno a6xx GPU family starting
with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845
code that would be needed to actually bring up a device and it is also in
advance of any user side support for the a6xx GPU so this is mainly
Failure to load firmware is the primary reason to fail adreno_load_gpu().
Try to load it first before going into the hardware initialization code and
unwinding it. This is important for a6xx because the GMU gets loaded from
the runtime power code and it is more costly to fail in that path because
Add a helper function to parse the clock names and set up
the bulk data so we can take advantage of the bulk clock
functions instead of rolling our own. This is added
as a helper function so the upcoming a6xx GMU code can
also take advantage of it.
Signed-off-by: Jordan Crouse
---
Now that the IOMMU is the master of it's own power we don't need to bring
up the GPU to do IOMMU operations. This is good because bringing up a6xx
requires the GMU so calling pm_runtime_get_sync() too early in the process
gets us into some nasty circular dependency situations.
Signed-off-by:
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +
2 files changed, 2166
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the
Hi Kieran,
On Monday, 6 August 2018 18:49:12 EEST Kieran Bingham wrote:
> On 30/07/18 18:20, Jacopo Mondi wrote:
> > Rename the 'value' variable, only used to for writing to DMSR register to
> > a more precise 'dmsr' name.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > Signed-off-by: Jacopo
Acked-by: Sinclair Yeh
On Sat, Aug 04, 2018 at 05:15:30PM +0100, Alexandru Gheorghe wrote:
> A new helper function(__drm_atomic_helper_plane_reset) has been added
> for linking a plane with its state and resetting the core
> properties(alpha, rotation, etc.) to their default values.
> Use that
https://bugs.freedesktop.org/show_bug.cgi?id=107493
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output. What display connectors are on
your system and which are you using? Are you using DVI and HDMI at the same
time?
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=107498
Alex Deucher changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Alex
https://bugs.freedesktop.org/show_bug.cgi?id=106519
--- Comment #23 from mikhail.v.gavri...@gmail.com ---
Created attachment 140983
--> https://bugs.freedesktop.org/attachment.cgi?id=140983=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, etc. So this should not be done from an atomic context.
But the console-output trigger deferred console takeover may happen from an
atomic context, which leads to "BUG: sleeping function called from invalid
On Mon, Aug 06, 2018 at 03:28:06PM +0300, Laurent Pinchart wrote:
> Hi Alex,
>
> On Monday, 6 August 2018 15:20:38 EEST Alexandru-Cosmin Gheorghe wrote:
> > On Mon, Aug 06, 2018 at 02:45:42PM +0300, Laurent Pinchart wrote:
> > > On Monday, 6 August 2018 14:07:27 EEST Alexandru-Cosmin Gheorghe
Hi Jacopo,
Thankyou for the patch,
On 30/07/18 18:20, Jacopo Mondi wrote:
> Rename the 'value' variable, only used to for writing to DMSR register to a
> more precise 'dmsr' name.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c
From: Kieran Bingham
Add myself as a co-maintainer for the Renesas DRM drivers.
Signed-off-by: Kieran Bingham
---
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS
I forgot about this since we started discussing possible scenarios of
processes and threads.
In any case, this check is redundant. Acked-by: Nayan Deshmukh <
nayan26deshm...@gmail.com>
Nayan
On Mon, Aug 6, 2018 at 7:43 PM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Ping. Any
Ping. Any objections to that?
Christian.
Am 03.08.2018 um 13:08 schrieb Christian König:
That is superflous now.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
Am 06.08.2018 um 15:23 schrieb Nayan Deshmukh:
Hi Christian,
Good patch. But it might lead to bad performance when we reschedule
when the hardware queue of the engine on which the last job was pushed
is not full.
On Mon, Aug 6, 2018 at 5:49 PM Christian König
https://bugs.freedesktop.org/show_bug.cgi?id=107498
Bug ID: 107498
Summary: Southern Islands pp_od_clk_voltage is empty
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi Dave,
not much to de-stage this time. Changes from Philipp and Souptick to
use memset32 more and switch the fault handler to the new vm_fault_t
and two small fixes for issues that can be hit in rare corner cases
from me.
Regards,
Lucas
The following changes since commit
Hi Christian,
Good patch. But it might lead to bad performance when we reschedule when
the hardware queue of the engine on which the last job was pushed is not
full.
On Mon, Aug 6, 2018 at 5:49 PM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> This fixes accessing the
On Mon, Aug 6, 2018 at 6:45 PM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 06.08.2018 um 15:11 schrieb Nayan Deshmukh:
>
> Hi Christian,
>
> On Mon, Aug 6, 2018 at 5:49 PM Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> Update job earlier with the scheduler
Am Montag, den 06.08.2018, 10:12 +0200 schrieb Christian König:
> Am 03.08.2018 um 19:31 schrieb Lucas Stach:
> > Am Montag, den 06.08.2018, 14:57 +0200 schrieb Christian König:
> > > Am 03.08.2018 um 16:29 schrieb Lucas Stach:
> > > > drm_sched_job_finish() is a work item scheduled for each
1 - 100 of 214 matches
Mail list logo
