On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> > We need to make sure implementations don't cheat and don't have a
> > possible schedule/blocking point deeply burried where review can't
> > catch it.
> >
> > I'm n
On Wed, Aug 14, 2019 at 09:09:59PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:26PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and
On Wed, Aug 14, 2019 at 09:11:37PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:27PM +0200, Daniel Vetter wrote:
> > Similar to the warning in the mmu notifer, warning if an hmm mirror
> > callback gets it's blocking vs. nonblocking handling wrong, or if it
> > fails with anything
From: Thomas Hellstrom (VMware)
Dave, Daniel
A couple of independent patches extracted from the 5.3 pull request, fixed for
merge conflicts and a single unused variable warning.
And the drmP.h removal from Sam.
/Thomas
The following changes since commit e7f7287bf5f746d29f3607178851246a005dd39
Am 14.08.19 um 20:26 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 19:24:01)
>> This reverts
>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
>> 0e1d8083bddb ("dma-buf: further relax reservation_objec
Hi Dave & Daniel -
One use after free fix for GVT.
It doesn't have a Link: tag because dim doesn't check that while
applying the pull, and, for some reason, it was also not checked when I
pushed out the branch. Possibly because it's in a merge? Anyway, I only
got the complaint when making the pu
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add support for the analogix,anx7808, analogix,anx7812, and
> analogix,anx7818 variants.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add support for the 7808 variant. While we're here, the of match table
> was missing support for the 7812 and 7818 variants, so add them as well.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
_
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> The i2c_new_dummy() function is deprecated since it returns NULL on
> error. Change this to use the recommended replacement
> i2c_new_dummy_device() that returns an error code that can be read with
> PTR_ERR() and friends.
>
> Signed-off-by: B
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add support for the avdd33 regulator to the analogix-anx78xx driver.
> Note that the regulator is currently enabled during driver probe and
> disabled when the driver is removed. This is currently how the
> downstream MSM kernel sources do thi
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add CONFIG_DRM_ANALOGIX_ANX78XX as a module so that the external display
> can be used on the Nexus 5 phones.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
d
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> error. The downstream MSM kernel sources [1] shows that the proper value
> for TX_P0 is 0x78, not 0x7
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add HDMI tx and phy nodes to support an external display that can be
> connected over the SlimPort. This is based on work from Jonathan Marek.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
radeon is using a device global hash table to track what mmu_notifiers
have been registered on struct mm. This is better served with the new
get/put scheme instead.
radeon has a bug where it was not blocking notifier release()
We recently added a kfree() after the end of the loop:
if (retries == RETRIES) {
kfree(reply);
return -EINVAL;
}
There are two problems. First the test is wrong and because retries
equals RETRIES if we succeed on the last iteration through the loop
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Add HDMI nodes and other supporting infrastructure in order to support
> the external display. This is based on work from Jonathan Marek.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
_
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only
when it is passed to drm_gem_fb_create_with_funcs() as its last
argument. drm_gem_fb_create_with_funcs does not modify its lst argument
(fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs
constant to protect
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Silence two warning messages that occur due to -EPROBE_DEFER errors to
> help cleanup the system boot log.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> pm8941 is missing the 5vs2 regulator node so let's add it since its
> needed to get the external display working. This regulator was already
> configured in the interrupts property on the parent node.
>
> Note that this regulator is referred t
This macro doesn't work because the right shift has higher precedence
than bitwise AND.
Fixes: 9749a5b6c09f ("drm/i915/tgl: Fix the read of the DDI that transcoder is
attached to")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Pass the connector info to the CEC adapter. This makes it possible
to associate the CEC adapter with the corresponding drm connector.
Signed-off-by: Dariusz Marcinkiewicz
Signed-off-by: Hans Verkuil
Tested-by: Hans Verkuil
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/
Hi,
amd64 based Huawei servers have problems where the display output of their iBMC
chips is broken, resulting in a "blurry" screen when viewed from their in house
remote kvm-like console.
Example:
https://launchpadlibrarian.net/365907668/creen_picture_for_blur.png
The issue is caused by the
Static structure dw_hdmi_i2s_ops, of type hdmi_codec_ops, is used only
when assigned as a value to field ops of variable pdata, which has type
hdmi_codec_pdata. Field ops of hdmi_codec_pdata is declared as a const;
hence make dw_hdmi_i2s_ops constant as well.
Issue found with Coccinelle.
Signed-of
The code was changed to call drm_connector_init_with_ddc() instead of
drm_connector_init(), but the corresponding error message was not
updated.
Fixes: cfb444552926989f ("drm/bridge: ti-tfp410: Provide ddc symlink in
connector sysfs directory")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/
The static structure tilcdc_plane_funcs, of type drm_plane_funcs, is
used only when passed the fourth argument to drm_plane_init(); however,
this fourth parameter is declared as const in the function definition.
Hence make tilcdc_plane_funcs constant as well.
Issue found with Coccinelle.
Signed-of
Am 15.08.19 um 09:27 schrieb Christoph Hellwig:
> radeon uses a need_dma32 flag to indicate to the drm core that some
> allocations need to be done using GFP_DMA32, but it only checks the
> device addressing capabilities to make that decision. Unfortunately
> PCIe root ports that have limited addr
Static structure micro_bl_props, having type backlight_properties, is
used only once, when it is passed as the last argument to function
devm_backlight_device_register(). devm_backlight_device_register() is
defined with its last parameter being declared constant. Hence make
micro_bl_props itself co
On Sat, Jun 29, 2019 at 02:59:27PM +0200, Linus Walleij wrote:
> This file is not using any symbols from so just
> drop this include.
>
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Linus Walleij
For the series:
Rev
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs,
is used only when it is passed as the third argument to
drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it
constant to protect it from unintended modifications.
Issue found with Coccinelle.
Signed-off-by: Nis
On 09/08/2019 22:09, Alyssa Rosenzweig wrote:
> While newer kbase include only the numbers of errata, older kbase
> releases included one-line descriptions for each errata, which is useful
> for those working on the driver. Import these descriptions. Most are
> from kbase verbatim; a few I edited f
The purpose of this patchset is to improve the support of the i2s
interface of the synopsys hdmi controller.
Once applied, the interface should support all the usual i2s bus formats,
8 channels playback and properly setup the channel number and allocation
in the infoframes.
Also, the dw-hdmi i2s
The static structure aspeed_gfx_funcs, of type
drm_simple_display_pipe_funcs, is used only as an argument to
drm_simple_display_pipe_init(), which does not modify it. Hence make it
constant to protect it from unintended modification.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
On 13/08/2019 16:01, Rob Herring wrote:
> Up until now, a single shared GPU address space was used. This is not
> ideal as there's no protection between processes and doesn't work for
> supporting the same GPU/CPU VA feature. Most importantly, this will
> hopefully mitigate Alyssa's fear of WebGL,
On Mon 12 Aug 2019 at 14:19, Neil Armstrong wrote:
> Hi,
>
> On 12/08/2019 14:07, Jerome Brunet wrote:
>> The purpose of this patchset is to improve the support of the i2s
>> interface of the synopsys hdmi controller.
>>
>> Once applied, the interface should support all the usual i2s bus formats
Hi Emil:
These changes are not due to previous bugs.
The init code changes for a couple of reasons:
During the development of the project,
1: Suppliers of LCDS keep changing the process, optimizing the
circuitry, and changing the values of certain registers.
2: Changing display effects, such as co
Thanks for the series of fixes. I will check whether these fixes work
on the original intended systems.
On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
>
> This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
>
> The original commit message didn't even make sense. AMD _does_ support
On Tue, Aug 06, 2019 at 08:15:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> radeon is using a device global hash table to track what mmu_notifiers
> have been registered on struct mm. This is better served with the new
> get/put scheme instead.
>
> radeon has a bug where it was
On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig
Dimitri, are you OK with this patch?
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop
When changing the audio hw params, reset the audio fifo to make sure
any old remaining data is flushed.
The databook mentions that such reset should be followed by a reset of
the i2s block to make sure the samples stay aligned
Reviewed-by: Jonas Karlman
Signed-off-by: Jerome Brunet
---
drivers
On Wed, Aug 14, 2019 at 3:31 PM Karol Herbst wrote:
>
> This reverts commit 9251a71db62ca9cc7e7cf364218610b0f018c291.
>
> This was never discussed with anybody Nouveau related and we would have NACKed
> this change immediately.
>
> We have a better workaround, which makes it actually work with Nou
Acked-by: Alyssa Rosenzweig
On Tue, Aug 13, 2019 at 09:01:15AM -0600, Rob Herring wrote:
> Up until now, a single shared GPU address space was used. This is not
> ideal as there's no protection between processes and doesn't work for
> supporting the same GPU/CPU VA feature. Most importantly, this
This series updates DRM drivers to use new CEC notifier API.
Changes since v6:
Made CEC notifiers' registration and de-registration symmetric
in tda998x and dw-hdmi drivers. Also, accidentally dropped one
patch in v6 (change to drm_dp_cec), brought it back now.
Changes sinc
After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven
series (v2)"), some Raven Ridge systems start to have rendering
corruption in browser [1].
Chip specific flags like cg_flags and pg_flags are applied in
amdgpu_device_ip_early_init(). For Raven Ridge, the flags may depend on
pp_f
On Wed, Aug 14, 2019 at 02:20:31PM -0700, Ralph Campbell wrote:
>
> On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Many places in the kernel have a flow where userspace will create some
> > object and that object will need to connect to the subsystem's
> > mmu_notifi
On Thu, Aug 15, 2019 at 2:49 AM Brian Masney wrote:
> Silence a warning message due to an -EPROBE_DEFER error to help cleanup
> the system boot log.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailin
On Wed, Aug 14, 2019 at 03:58:34PM +, Jason Gunthorpe wrote:
> On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> > Looks good,
> >
> > Reviewed-by: Christoph Hellwig
>
> Dimitri, are you OK with this patch?
>
I think this looks OK.
Reviewed-by: Dimitri Sivanich
On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> > Section alignment constraints somewhat save us here. The only example
> > I can think of a PMD not containing a uniform pgmap association for
> > each pte is the ca
Hi Artur.
The patch1-4 in this series depend on other patches[1] on mainline.
On next v2 version, please make some patches based on patches[1]
in order to prevent the merge conflict.
[1] [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
- https://lkml.org/lkml/2019/8/8/217
Also,
Hisilicon developed hibmc_drm for their arm64 based soc and did not
intend for this driver to be used on any other architecture than arm64.
Using it on amd64 leads to incorrect video modes being used, making
the screen unreadable, forcing users to manually blacklist the module
on the kernel comman
On 15/08/2019 09:30, Dan Carpenter wrote:
> We recently added a kfree() after the end of the loop:
>
> if (retries == RETRIES) {
> kfree(reply);
> return -EINVAL;
> }
>
> There are two problems. First the test is wrong and because retries
> equals RETRIES
setup the channel allocation provided by the generic hdmi-codec driver
Reviewed-by: Jonas Karlman
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
b/drive
On Sat, 16 Feb 2019, Ramalingam C via dri-devel
wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
> wait for cp_irq is merged with this patch. Rebased.
> v3:
On Wed 14-08-19 13:45:58, Andrew Morton wrote:
> On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter
> wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a
Hi Marco,
On Thu, 2019-08-15 at 08:36 +0200, Marco Felsch wrote:
> Hi Philipp,
>
> On 19-08-14 17:10, Philipp Zabel wrote:
> > Support is already implemented for the corresponding DRM formats,
> > just hook up the remaining V4L2 pixel formats.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > d
Am Mittwoch, den 14.08.2019, 11:59 +0200 schrieb Guido Günther:
> Hi,
> On Fri, Aug 09, 2019 at 02:04:23PM +0200, Lucas Stach wrote:
> > In preparation to having a context per process, etnaviv_gem_mapping_get
> > should not use the current GPU context, but needs to be told which
> > context to use.
On Thu, 15 Aug 2019, Dan Carpenter wrote:
> This macro doesn't work because the right shift has higher precedence
> than bitwise AND.
>
> Fixes: 9749a5b6c09f ("drm/i915/tgl: Fix the read of the DDI that transcoder
> is attached to")
> Signed-off-by: Dan Carpenter
Thanks, already fixed by 1cdd87
https://bugs.freedesktop.org/show_bug.cgi?id=22
Brian Schott changed:
What|Removed |Added
CC||briancsch...@gmail.com
--- Comment #17 f
Am 14.08.19 um 22:07 schrieb Daniel Vetter:
> On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
>> Quoting Chris Wilson (2019-08-14 19:24:01)
>>> This reverts
>>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fence
Am Mittwoch, den 14.08.2019, 14:29 +0200 schrieb Guido Günther:
> Hi,
> nOn Fri, Aug 09, 2019 at 02:05:14PM +0200, Lucas Stach wrote:
> > With softpin we allow the userspace to take control over the GPU virtual
> > address space. The new capability is relected by a bump of the minor DRM
> > version
Dear All,
this series adds support for dual-LVDS panel IDK-2121WR
from Advantech:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Dual link support is very recent for R-Car Gen3, and I couldn't
find much on dual link panels in the kernel either, the
The information represented by drm_bridge_timings is also
needed by panels, therefore rename drm_bridge_timings to
drm_timings.
Signed-off-by: Fabrizio Castro
Link: https://www.spinics.net/lists/linux-renesas-soc/msg43271.html
---
v1->v2:
* new patch
I have copied the license from include/drm/d
This panel is handled through the generic lvds-panel bindings,
so only needs its additional compatible specified.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm
Signed-off-by: Fabrizio Castro
The companion encoder needs to be told to use the same
mode as the primary encoder.
Fixes: e9e8798ab7b8 ("drm: rcar-du: lvds: Add support for dual-link mode")
Signed-off-by: Fabrizio Castro
---
v1->v2:
* reworked according to Laurent's feedback
drivers/gpu/drm/rcar-du/rcar_lvds.c | 5 +
1
This patch adds support for dual-LVDS panels.
It's very important that we coordinate the efforts of both the
primary encoder and the companion encoder to get the right
picture on the panel, therefore this patch adds some code
to work out if even and odd pixels need swapping.
When the encoders are
We need to know if the panel supports dual-link, similarly
to bridges, therefore add a reference to drm_timings in
drm_panel.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* new patch
include/drm/drm_panel.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/
Dual-link LVDS displays have two ports, therefore document this
with the bindings.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* Reworked the description of the ports property
* lvds0_panel_in in the example has been renamed to panel_in0
* lvds1_panel_in in the example has been renamed to panel_i
We need more information to describe dual-LVDS links, therefore
introduce link_flags.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* new patch
include/drm/drm_timings.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/drm/drm_timings.h b/include/drm/drm_tim
The IDK-2121WR from Advantech is a dual-LVDS display.
Signed-off-by: Fabrizio Castro
---
v1->v2:
* new patch
drivers/gpu/drm/panel/panel-lvds.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index 1ec57d0..2c
> -Original Message-
> From: Liviu Dudau
> Sent: 2019年7月22日 17:33
> To: Wen He
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
>
> Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS in
On Thu, Aug 15, 2019 at 9:42 AM Jani Nikula wrote:
>
>
> Hi Dave & Daniel -
>
> One use after free fix for GVT.
>
> It doesn't have a Link: tag because dim doesn't check that while
> applying the pull, and, for some reason, it was also not checked when I
> pushed out the branch. Possibly because i
Hi Fabrizio,
On Thu, Aug 15, 2019 at 12:04:25PM +0100, Fabrizio Castro wrote:
> Dual-link LVDS displays have two ports, therefore document this
> with the bindings.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v1->v2:
> * Reworked the description of the ports property
> * lvds0_panel_in in the
Hi Fabrizio,
On Thu, Aug 15, 2019 at 12:04:26PM +0100, Fabrizio Castro wrote:
> This panel is handled through the generic lvds-panel bindings,
> so only needs its additional compatible specified.
>
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 15, 2019 at 12:04:30PM +0100, Fabrizio Castro wrote:
> The companion encoder needs to be told to use the same
> mode as the primary encoder.
>
> Fixes: e9e8798ab7b8 ("drm: rcar-du: lvds: Add support for dual-link mode")
> Signed-off-by: Fabrizio
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 15, 2019 at 12:04:28PM +0100, Fabrizio Castro wrote:
> We need more information to describe dual-LVDS links, therefore
> introduce link_flags.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v1->v2:
> * new patch
>
> include/drm/drm_timings.h |
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 15, 2019 at 12:04:29PM +0100, Fabrizio Castro wrote:
> We need to know if the panel supports dual-link, similarly
> to bridges, therefore add a reference to drm_timings in
> drm_panel.
Panels may also need to report setup/hold time, so it's not a
On Mon, 2019-07-22 at 13:08 -0300, Ezequiel Garcia wrote:
> When a mode is set with just a connector "-s foo",
> we get a nasty segmentation fault. Fix it.
>
> Signed-off-by: Ezequiel Garcia
There's no rush, but still, here goes a reminder
of this and the next patch. :-)
> ---
> tests/modetest
On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> > > In some special cases we must not block, but there's not a
> > > spinlock, preempt-off, irqs-off
Hi Maxime
On Tue, Aug 13, 2019 at 8:05 AM Maxime Ripard wrote:
>
> On Mon, Jul 29, 2019 at 08:59:04AM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> >
> > On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > > >
On Thu, Aug 15, 2019 at 09:02:49AM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote:
> > > We need to make sure implementations don't cheat and don't have a
> > > possible schedule/blocki
On Thu, Aug 15, 2019 at 09:10:14AM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 09:09:59PM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 14, 2019 at 10:20:26PM +0200, Daniel Vetter wrote:
> > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > > fairly easy to provoke a
On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote:
> As the oom reaper is the primary guarantee of the oom handling forward
> progress it cannot be blocked on anything that might depend on blockable
> memory allocations. These are not really easy to track because they
> might be indirec
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 15, 2019 at 12:04:31PM +0100, Fabrizio Castro wrote:
> This patch adds support for dual-LVDS panels.
>
> It's very important that we coordinate the efforts of both the
> primary encoder and the companion encoder to get the right
> picture on the
On Thu, Aug 15, 2019 at 3:04 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote:
>
> > As the oom reaper is the primary guarantee of the oom handling forward
> > progress it cannot be blocked on anything that might depend on blockable
> > memory allocations.
Hi Fabrizio,
(CC'ing Greg as the architect of the SPDX move)
On Thu, Aug 15, 2019 at 12:04:27PM +0100, Fabrizio Castro wrote:
> The information represented by drm_bridge_timings is also
> needed by panels, therefore rename drm_bridge_timings to
> drm_timings.
>
> Signed-off-by: Fabrizio Castro
On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> > > > In some special cases we must not block
On Thu 15-08-19 10:04:15, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote:
>
> > As the oom reaper is the primary guarantee of the oom handling forward
> > progress it cannot be blocked on anything that might depend on blockable
> > memory allocations. These a
Hi Laurent,
Thank you for your feedback!
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 15 August 2019 12:45
> Subject: Re: [PATCH v2 1/9] dt-bindings: panel: lvds: Add dual-link LVDS
> display support
>
> Hi Fabrizio,
>
> On Thu, Aug 15, 2019 at 12:04:25P
Hi Laurent,
Thank you for your feedback!
> From: Laurent Pinchart
> Sent: 15 August 2019 12:47
> Subject: Re: [PATCH v2 2/9] dt-bindings: display: Add bindings for Advantech
> IDK-2121WR
>
> Hi Fabrizio,
>
> On Thu, Aug 15, 2019 at 12:04:26PM +0100, Fabrizio Castro wrote:
> > This panel is ha
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 15 August 2019 12:55
> Subject: Re: [PATCH v2 6/9] drm: rcar-du: lvds: Fix companion's mode
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Aug 15, 2019
Hello Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 15 August 2019 13:03
> Subject: Re: [PATCH v2 5/9] drm/panel: Add timings field to drm_panel
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Thu, Aug 15, 2
Hello Laurent,
Thank you for your feedback!
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 15 August 2019 14:19
> Subject: Re: [PATCH v2 3/9] drm: Rename drm_bridge_timings to drm_timings
>
> Hi Fabrizio,
>
> (CC'ing Greg as the architect of the SPDX move)
On 15/08/2019 14:35, Christoph Hellwig wrote:
On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote:
On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
Hello
Since lot of release (at least since 4.19), I hit the following error message:
DMA-API: cacheline tracking ENOMEM,
On Thu, Aug 15, 2019 at 04:18:38PM +0300, Laurent Pinchart wrote:
> Hi Fabrizio,
>
> (CC'ing Greg as the architect of the SPDX move)
_one of_, not the one that did the most of he work, that would be Thomas :)
> On Thu, Aug 15, 2019 at 12:04:27PM +0100, Fabrizio Castro wrote:
> > The information
On Thu, Aug 15, 2019 at 3:56 PM wrote:
>
> > -Original Message-
> > From: linux-acpi-ow...@vger.kernel.org On
> > Behalf Of Dave Airlie
> > Sent: Wednesday, August 14, 2019 5:48 PM
> > To: Karol Herbst
> > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung; Ben
> > Sk
On Thu, Aug 15, 2019 at 12:47 AM Dave Airlie wrote:
>
> On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote:
> >
> > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c.
> >
> > The original commit message didn't even make sense. AMD _does_ support it
> > and
> > it works with Nouveau as w
On Thu, Aug 15, 2019 at 03:21:27PM +0200, Michal Hocko wrote:
> On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> > > > On Wed, Aug 14, 2019 at 10:20:24PM +0200
Hi Fabrizio
On Thu, Aug 15, 2019 at 12:04:29PM +0100, Fabrizio Castro wrote:
> We need to know if the panel supports dual-link, similarly
> to bridges, therefore add a reference to drm_timings in
> drm_panel.
Why do we need to know this?
Why is it needed in drm_panel and not in some driver specif
On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote:
>
> On Thu, Aug 15, 2019 at 3:56 PM wrote:
> >
> > > -Original Message-
> > > From: linux-acpi-ow...@vger.kernel.org
> > > On
> > > Behalf Of Dave Airlie
> > > Sent: Wednesday, August 14, 2019 5:48 PM
> > > To: Karol Herbst
> > > Cc:
Hi Greg,
On Thu, Aug 15, 2019 at 04:04:00PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 15, 2019 at 04:18:38PM +0300, Laurent Pinchart wrote:
> > Hi Fabrizio,
> >
> > (CC'ing Greg as the architect of the SPDX move)
>
> _one of_, not the one that did the most of he work, that would be Thomas :
On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher wrote:
>
> On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst wrote:
> >
> > On Thu, Aug 15, 2019 at 3:56 PM wrote:
> > >
> > > > -Original Message-
> > > > From: linux-acpi-ow...@vger.kernel.org
> > > > On
> > > > Behalf Of Dave Airlie
> > > > S
1 - 100 of 191 matches
Mail list logo