Each of hdmi and edp are already attached in msm_*_bridge_init. A second
attachment returns -EBUSY, failing the driver load.
Tested with HDMI on IFC6410 (APQ8064 / MDP4), but eDP case should be
analogous.
Fixes: 3ef2f119bd3ed (drm/msm: Use drm_attach_bridge() to attach a bridge to an
encoder)
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit 513dc792d6060d5ef572e43852683097a8420f56:
vgacon: Fix a UAF in vgacon_invert_region (2020-03-06 21:06:34 +0100)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Currently if a special PTE is encountered hmm_range_fault() immediately
returns EFAULT and sets the HMM_PFN_SPECIAL error output (which nothing
uses).
EFAULT should only be returned after testing with hmm_pte_need_fault().
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
hmm_range_fault() should never return 0 if the caller requested a valid
page, but the pfns output for that page would be HMM_PFN_ERROR.
hmm_pte_need_fault() must always be called before setting HMM_PFN_ERROR to
detect if the
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
The intention with this code is to determine if the caller required the
pages to be valid, and if so, then take some action to make them valid.
The action varies depending on the page type.
In all cases, if the caller doesn't
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
All return paths that do EFAULT must call hmm_range_need_fault() to
determine if the user requires this page to be valid.
If the page cannot be made valid if the user later requires it, due to vma
flags in this case, then the
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
All success exit paths from the walker functions must set the pfns array.
A migration entry with no required fault is a HMM_PFN_NONE return, just
like the pte case.
Fixes: d08faca018c4 ("mm/hmm: properly handle migration
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This eventually calls into handle_mm_fault() which is a sleeping function.
Release the lock first.
hmm_vma_walk_hole() does not touch the contents of the PUD, so it does not
need the lock.
Fixes: 3afc423632a1 ("mm: pagewalk:
On 3/11/20 11:35 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
The pgmap is held in the hmm_vma_walk variable in hope of speeding up
future get_dev_pagemap() calls by hitting the same pointer. The algorithm
doesn't actually care about how long the pgmap is held for.
Move the put of the
On 3/11/20 11:34 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Many of the direct returns of error skipped doing the pte_unmap(). All non
zero exit paths must unmap the pte.
The pte_unmap() is split unnaturally like this because some of the error
exit paths trigger a sleep and must
Hi Andy,
On Wed, Mar 11, 2020 at 03:55:35PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 11, 2020 at 01:51:34PM +0100, Phong LE wrote:
> > This commit is a simple driver for bridge HMDI it66121.
> > The input format is RBG and there is no color conversion.
> > Audio, HDCP and CEC are not supported
On Wed, Mar 11, 2020 at 4:36 PM Gurchetan Singh
wrote:
>
>
>
> On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann wrote:
>>
>> Hi,
>>
>> > I should've been more clear -- this is an internal cleanup/preparation and
>> > the per-context changes are invisible to host userspace.
>>
>> Ok, it wasn't
https://bugzilla.kernel.org/show_bug.cgi?id=206725
mombelli.ma...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann wrote:
> Hi,
>
> > I should've been more clear -- this is an internal cleanup/preparation
> and
> > the per-context changes are invisible to host userspace.
>
> Ok, it wasn't clear that you don't flip the switch yet. In general the
> commit
On Wed, Mar 11, 2020 at 05:54:46PM +0300, Wambui Karuga wrote:
> Hey Thierry,
>
> On Wed, 11 Mar 2020, Thierry Reding wrote:
>
> > On Thu, Feb 27, 2020 at 03:02:21PM +0300, Wambui Karuga wrote:
> > > Since 987d65d01356 (drm: debugfs: make
> > > drm_debugfs_create_files() never fail) there is no
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote:
> - X11: With present, it has these "explicit" fence objects but
> they're always a shmfence which lets the X server and client do a
> userspace CPU-side hand-off without going over the socket (and
> round-tripping through the kernel).
Hi Yuti,
Thank you for the patch.
On Wed, Feb 26, 2020 at 11:22:58AM +0100, Yuti Amonkar wrote:
> This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e SoC.
s/DRM driver/DRM bridge driver.
> MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
> embedded
On Wed, 2020-03-11 at 17:50 -0400, Felix Kuehling wrote:
> On 2020-03-11 12:51 a.m., Joe Perches wrote:
> > Convert the various uses of fallthrough comments to fallthrough;
> >
> > Done via script
> > Link:
> >
On 2020-03-11 12:51 a.m., Joe Perches wrote:
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
The link seems to be broken. This one works:
On Wed, Mar 11, 2020 at 04:00:01PM -0500, Rob Herring wrote:
> Extra dtc warnings (roughly what W=1 enables) are now enabled by default
> when building the binding examples. These were fixed treewide in
> 5.6-rc5, but some new display bindings have been added with new
> warnings:
>
>
Hi,
thanks for re-spinning!
One more comment inline.
On Wed, Mar 11, 2020 at 02:28:07PM +0530, Harigovindan P wrote:
> diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> new file mode 100644
> index ..b226723a7543
> ---
Extra dtc warnings (roughly what W=1 enables) are now enabled by default
when building the binding examples. These were fixed treewide in
5.6-rc5, but some new display bindings have been added with new
warnings:
Hi Yuti,
Thank you for the patch.
On Wed, Feb 26, 2020 at 11:22:59AM +0100, Yuti Amonkar wrote:
> Add j721e wrapper for mhdp, which sets up the clock and data muxes.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Jyri Sarha
> Reviewed-by: Tomi Valkeinen
> ---
>
Hi all,
I've been working on adding VRR support to Sway [1] (a Wayland
compositor). The compositor just sets the VRR_ENABLED property.
This works fine for some screens, but causes flcikering for other
screens as expected [2]. Fixing the flickering is something we've
talked about last XDC [3].
On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote:
>
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will get at least one mailing list rejection. However, this
> is an issue that affects a LOT of components and that's why it's
> thorny to begin
On Mon, 9 Mar 2020 at 20:27, Lyude Paul wrote:
>
> On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> > amongst every driver and don't do anything other than calling
> > drm_connector_register().
> >
On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > I should've been more clear -- this is an internal cleanup/preparation and
> > the per-context changes are invisible to host userspace.
>
> Ok, it wasn't clear that you don't flip the switch yet. In general the
> commit
All,
Sorry for casting such a broad net with this one. I'm sure most people
who reply will get at least one mailing list rejection. However, this
is an issue that affects a LOT of components and that's why it's
thorny to begin with. Please pardon the length of this e-mail as
well; I promise
From: Thomas Hellstrom
When we refuse DMA from system pages for whatever reason, we don't
handle that correctly when guest-backed objects was enabled.
Since guest-backed objects by definition require DMA to and from
system pages, disable all functionality that relies on them.
That basically
From: Thomas Hellstrom
TTM doesn't yet fully support mapping of DMA memory when SEV is active,
so in that case, refuse DMA operation. For guest-backed object operation
this means 3D acceleration will be disabled. For host-backed, VRAM will be
used for data transfer between the guest and the
tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head: 4e1b4dc4172af081c1feb211ed48b77a008aa054
commit: 4e1b4dc4172af081c1feb211ed48b77a008aa054 [1/1] drm/tegra: Remove checks
for debugfs functions return value
config: arm64-allmodconfig (attached as .config)
compiler:
On Di, 2020-03-10 at 16:31 +0300, Wambui Karuga wrote:
> Since commit 987d65d01356 (drm: debugfs: make
> drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
> fails and only returns 0. Therefore, remove the unnecessary check of its
> return value and error handling in
On Wed, Mar 11, 2020 at 9:52 AM Christian König
wrote:
>
> We should be able to do this now after checking all the prerequisites.
>
> v2: fix entrie count in the sgt
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 56 ---
>
Hi Ville,
On Mon, Mar 2, 2020 at 5:36 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
Use available afbc helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 44 +++-
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index
Prepare for using generic afbc helpers.
Use an existing helper which allows allocating a struct drm_framebuffer
in the driver.
afbc-specific checks should go after drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 50
Consolidating framebuffer creation into one function will make it easier
to transition to generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 157 +--
1 file changed, 66 insertions(+), 91 deletions(-)
diff --git
Allow allocating a specialized version of struct drm_framebuffer
by moving the actual fb allocation out of drm_gem_fb_create_with_funcs();
the respective functions names are adjusted to reflect that fact.
Please note, though, that standard size checks are performed on buffers,
so the
The new struct contains afbc-specific data.
The new function can be used by drivers which support afbc to complete
the preparation of struct drm_afbc_framebuffer. It must be called after
allocating the said struct and calling drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
This series adds AFBC support for Rockchip. It is inspired by:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
This is the seventh iteration of the afbc series, which addresses
comments
On Mon, Mar 09, 2020 at 04:33:56PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The listed dotclocks are two orders of mangnitude out.
> > Fix them.
> >
> > v2: Just divide everything by 100 (Linus)
> >
> > Cc: Linus
On Mon, Mar 09, 2020 at 04:33:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The dotclock is three orders of magnitude out. Fix it.
> >
> > v2: Just set it to 20MHz (Linus)
> >
> > Cc: Linus Walleij
> > Cc: Sam
On Tue, Mar 03, 2020 at 06:24:25AM +0100, Heiko Schocher wrote:
> Hello Ville Syrjala,
>
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the
On Tue, Mar 03, 2020 at 07:00:12AM -0600, Adam Ford wrote:
> On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone
On Sat, Mar 07, 2020 at 03:40:11PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> >
Am 11.03.20 um 15:38 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 03:33:01PM +0100, Christian König wrote:
Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian
On Thu, Feb 27, 2020 at 03:02:21PM +0300, Wambui Karuga wrote:
> Since 987d65d01356 (drm: debugfs: make
> drm_debugfs_create_files() never fail) there is no need to check the
> return value of drm_debugfs_create_files(). Therefore, remove the
> return checks and error handling of the
Am 11.03.20 um 15:04 schrieb Jason Gunthorpe:
On Wed, Mar 11, 2020 at 02:51:56PM +0100, Christian König wrote:
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4
1 file changed, 4 insertions(+)
diff --git
Am 11.03.20 um 09:24 schrieb Takashi Iwai:
> On Wed, 11 Mar 2020 09:10:56 +0100,
> Thomas Zimmermann wrote:
>>
>> Hi Takashi
>>
>> Am 11.03.20 um 08:35 schrieb Takashi Iwai:
>>> Since snprintf() returns the would-be-output size instead of the
>>> actual output size, the succeeding calls may go
On 11/03/2020 08:18, Jitao Shi wrote:
> DPI can sample on falling, rising or both edge.
> When DPI sample the data both rising and falling edge.
> It can reduce half data io pins.
>
> Reviewed-by: CK Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 27
Hi,
On 11/03/2020 08:18, Jitao Shi wrote:
> Some chips's sample mode are rising, falling and dual edge (both
> falling and rising edge).
> Extern the pclk-sample property to support dual edge.
>
> Acked-by: Rob Herring
> Reviewed-by: CK Hu
> Signed-off-by: Jitao Shi
> ---
>
We should be able to do this now after checking all the prerequisites.
v2: fix entrie count in the sgt
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 56 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 12 ++-
Note if a buffer was imported using peer2peer.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index
Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 2 ++
include/linux/dma-buf.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c
Check if we can do peer2peer on the PCIe bus.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index
This can be used by drivers to setup P2P DMA between device
memory which is not backed by struct pages.
The drivers of the involved devices are responsible for
setting up and tearing down DMA addresses as necessary
using dma_map_resource().
The page pointer is set to NULL and only the DMA
Importing should work out of the box.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index ffeb20f11c07..aef12ee2f1e3
This is the third and final part of my series to start supporting P2P with
DMA-buf.
The implementation is straight forward, apart from a helper to aid constructing
scatterlists without having struct pages we only add a new flag indicating that
an DMA-buf importer can handle peer2peer.
The
Jitao Shi 於 2020年3月11日 週三 下午3:18寫道：
> Add property "pinctrl-names" to swap pin mode between gpio and dpi mode.
> Set
> the dpi pins to gpio mode and output-low to avoid leakage current when dpi
> disabled.
>
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Jitao Shi
> ---
>
Jitao Shi 於 2020年3月11日 週三 下午3:19寫道：
> Config dpi pins mode to output and pull low when dpi is disabled.
> Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
>
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 31
On Wed, 2020-03-11 at 14:26 +0100, Matthias Brugger wrote:
>
> On 11/03/2020 12:56, Enric Balletbo i Serra wrote:
> > In the actual implementation the same compatible string
> > "mediatek,-mmsys" is used to bind the clock drivers
> > (drivers/soc/mediatek) as well as to the gpu driver
> >
On Wed, 2020-03-11 at 14:25 +0100, Matthias Brugger wrote:
>
> On 11/03/2020 14:07, CK Hu wrote:
> > Hi, Enric:
> >
> > On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote:
> >> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> >> replace
On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote:
> Filter out interlaced modes as they are not supported by ARC PGU
> hardware.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
Filter out interlaced modes as they are not supported by ARC PGU
hardware.
Signed-off-by: Eugeniy Paltsev
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index
Am 11.03.20 um 04:43 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with
Hi, Enric:
On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote:
> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
> Those functions will allow DRM driver and others to control the data
Hi, Enric:
On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote:
> From: Matthias Brugger
>
> There is no strong reason for this to use CLK_OF_DECLARE instead of
> being a platform driver. Plus, MMSYS provides clocks but also a shared
> register space for the mediatek-drm and the
Hi, Enric:
I'm confused this is v11 or v12.
For v12, you've lost some 'Acked-by' and 'Reviewed-by' tag.
Regards,
CK
On Wed, 2020-03-11 at 12:56 +0100, Enric Balletbo i Serra wrote:
> Dear all,
>
> These patches are intended to solve an old standing issue on some
> Mediatek devices (mt8173,
On Mon, 9 Mar 2020 at 18:36, Emil Velikov wrote:
>
> On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote:
>
> > > OTOH, if applications exist that rely on drop-master failing in this
> > > specific case, making drop-master succeed would break them. That might
> > > include a buggy set-master path
On Sat, Feb 15, 2020 at 01:56:27AM +0800, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945]
On Tue, Mar 10, 2020 at 09:51:33PM -0700, Joe Perches wrote:
> Convert the various uses of fallthrough comments to fallthrough;
>
> Done via script
> Link:
> https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
>
> Signed-off-by: Joe Perches
Hi,
> I should've been more clear -- this is an internal cleanup/preparation and
> the per-context changes are invisible to host userspace.
Ok, it wasn't clear that you don't flip the switch yet. In general the
commit messages could be a bit more verbose ...
I'm wondering though why we need
On Wed, Mar 11, 2020 at 12:11:00PM +0530, kgu...@codeaurora.org wrote:
> On 2020-03-10 20:57, Daniel Thompson wrote:
> > On Mon, Mar 09, 2020 at 06:56:00PM +0530, Kiran Gunda wrote:
> > > Add cabc_config, sync_toggle, wled_ovp_fault_status and wled_ovp_delay
> > > callback functions to prepare the
Hi
Am 11.03.20 um 09:24 schrieb Takashi Iwai:
> On Wed, 11 Mar 2020 09:10:56 +0100,
> Thomas Zimmermann wrote:
>>
>> Hi Takashi
>>
>> Am 11.03.20 um 08:35 schrieb Takashi Iwai:
>>> Since snprintf() returns the would-be-output size instead of the
>>> actual output size, the succeeding calls may go
Hi Lad,
On Tue, Mar 10, 2020 at 9:42 PM Lad Prabhakar
wrote:
> From: Fabrizio Castro
>
> The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
> from Advantech, however the panel isn't sold alongside the board.
> A new dts, adding everything that's required to get the panel to
>
On Tue, Mar 10, 2020 at 06:41:20PM -0700, Guru Das Srinagesh wrote:
> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
>
> Cc: Lee Jones
> Cc:
Hi
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
>
> The kdev
Hi Marek,
On Mon, 2020-03-09 at 21:18 +0100, Marek Vasut wrote:
> The bus_flags handling logic does not seem to cover all potential
> usecases. Specifically, this seems to fail with an "edt,etm0700g0edh6"
> display attached to an 24bit display interface, with interface-pix-fmt
> = "rgb24" set in
Am 11.03.20 um 10:07 schrieb Thomas Zimmermann:
> Hi Daniel
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
>> We have lots of these. And the cleanup code tends to be of dubious
>> quality. The biggest wrong pattern is that developers use devm_, which
>> ties the release action to the
Hi
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> Well for the simple stuff at least, vblank, gem and minor cleanup I
> want to further split up as a demonstration.
>
> v2: We need to clear drm_device->dev otherwise the debug drm printing
> after our cleanup hook (e.g. in drm_manged_release) will
Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> We need to add a drmm_kstrdup for this, but let's start somewhere.
>
> This is not exactly perfect onion unwinding, but it's jsut a kfree so
> doesn't really matter at all.
>
> Signed-off-by: Daniel Vetter
Acked-by: Thomas Zimmermann
> ---
>
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
>
>
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
<...>
> +
> +int __drmm_add_action(struct drm_device *dev,
> + drmres_release_t action,
> + void *data, const char *name)
> +{
> + struct drmres *dr;
> + void **void_ptr;
> +
> + dr = alloc_dr(action,
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> v2: We need drm_dev_put to unroll the driver creation (once
> drm_dev_init and drmm_add_final_kfree suceeded), otherwise
> the drmm_ magic doesn't happen.
>
> v3: Actually squash
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> I also did a full review of all callers, and only the xen driver
> forgot to call drm_dev_put in the failure path. Fix that up too.
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_dev_alloc(). We need to remove the kfree
Hi Daniel
Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the userspace visible stuff
Am Dienstag, 21. Januar 2020, 23:48:28 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner
>
> rockchip_drm_endpoint_is_subdriver() may also return error codes.
> For example if the target-node is in the disabled state, so no
> platform-device is getting created for it.
>
> In that case current
syzbot has bisected this bug to:
commit 5b3709793d151e6e12eb6a38a5da3f7fc2923d3a
Author: Thomas Zimmermann
Date: Wed May 8 08:26:19 2019 +
drm/ast: Convert AST driver to |struct drm_gem_vram_object|
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15a66fb5e0
start
On 2020-03-10 20:57, Daniel Thompson wrote:
On Mon, Mar 09, 2020 at 06:56:00PM +0530, Kiran Gunda wrote:
Add cabc_config, sync_toggle, wled_ovp_fault_status and wled_ovp_delay
callback functions to prepare the driver for adding WLED5 support.
Signed-off-by: Kiran Gunda
Overall this code
On 3/10/20 6:34 PM, Marek Szyprowski wrote:
Analogix_dp driver acquires all its resources in the ->bind() callback,
what is a bit against the component driver based approach, where the
driver initialization is split into a probe(), where all resources are
gathered, and a bind(), where all
Fix checkpatch errors:
"ERROR: space prohibited before that close parenthesis ')'"
in fbtft-bus.c:65 and fbtft-bus.c:67.
Signed-off-by: Marcio Albano
---
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
On 2020-03-11 00:01, Rob Herring wrote:
On Mon, 9 Mar 2020 18:55:59 +0530, Kiran Gunda wrote:
Convert the qcom-wled bindings from .txt to .yaml format.
Signed-off-by: Kiran Gunda
---
.../bindings/leds/backlight/qcom-wled.txt | 154
-
Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like,
> On Feb 15, 2020, at 01:56, Kai-Heng Feng wrote:
>
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945]
On 2020-03-10 21:15, Daniel Thompson wrote:
On Mon, Mar 09, 2020 at 06:56:01PM +0530, Kiran Gunda wrote:
Add support for WLED5 peripheral that is present on PM8150L PMICs.
PM8150L WLED supports the following:
- Two modulators and each sink can use any of the modulator
- Multiple CABC
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc:
Hi Joe,
Joe Perches wrote on Tue, 10 Mar 2020 21:51:27 -0700:
> Convert the various uses of fallthrough comments to fallthrough;
>
> Done via script
> Link:
> https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
>
> Signed-off-by: Joe Perches
> ---
>
There is a new fallthrough pseudo-keyword macro that can be used
to replace the various /* fallthrough */ style comments that are
used to indicate a case label code block is intended to fallthrough
to the next case label block.
See commit 294f69e662d1 ("compiler_attributes.h: Add 'fallthrough'
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: "Ville Syrjälä"
Cc:
1 - 100 of 122 matches
Mail list logo
