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
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
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
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, 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
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 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
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 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
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 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,
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. :-)
> ---
>
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
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: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,
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:
>
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
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
> -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
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
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
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
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
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
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
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
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
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,
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
> >
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
https://bugs.freedesktop.org/show_bug.cgi?id=22
Brian Schott changed:
What|Removed |Added
CC||briancsch...@gmail.com
--- Comment #17
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
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
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
> > ---
> >
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
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:
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
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
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
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
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
> >
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
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
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
---
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
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,
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
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
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
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 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
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
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 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
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:
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.
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
---
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.
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
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:
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 +-
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
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
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
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
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
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:
> 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
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
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
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
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
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
___
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
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:
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:
> 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
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
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
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
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
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: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
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 or similar critical section already
> > that arms the might_sleep()
On Wed, Aug 14, 2019 at 01:45:58PM -0700, 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()
On Wed, Aug 14, 2019 at 09:46:41PM -0400, Sasha Levin wrote:
> On Wed, Aug 14, 2019 at 07:24:15PM +0200, Daniel Vetter wrote:
> > Hi Sasha,
> >
> > On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
> > > Hi,
> > >
> > > [This is an automated email]
> > >
> > > This commit has been
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
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 16 ++--
>
101 - 191 of 191 matches
Mail list logo
