On 1/18/2023 5:00 AM, Dmitry Baryshkov wrote:
Move a call to dsi_calc_pclk() out of calc_clk_rate directly towards
msm_dsi_host_get_phy_clk_req(). It is called for both 6g and v2 hosts.
Also, while we are at it, replace another dsi_get_pclk_rate() invocation
with using the stored value at msm
On 1/24/2023 10:46 PM, Dmitry Baryshkov wrote:
Hi,
On Wed, 25 Jan 2023 at 02:22, Abhinav Kumar wrote:
On 1/24/2023 12:22 AM, Dmitry Baryshkov wrote:
On 24/01/2023 03:32, Abhinav Kumar wrote:
On 1/22/2023 11:11 PM, Dmitry Baryshkov wrote:
QCM2290 doesn't seem to support reg-dma, smart-dma
On 1/25/2023 10:21 AM, Doug Anderson wrote:
Hi,
On Wed, Jan 25, 2023 at 9:22 AM Kuogee Hsieh wrote:
-void dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
+irqreturn_t dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
u32 isr;
+ irqreturn_t ret = IRQ_NONE;
'memory-region' is a common property and already has a type.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/devicetre
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
vm_fl
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> >
On Wed, Jan 25, 2023 at 10:37 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > > + /*
> > > > + * Flags, see mm.h.
> > > > + * WARNING! Do not modify directly.
> > > > +
On Wed, Jan 25, 2023 at 10:33 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > +static inline void init_vm_flags(struct vm_area_struct *vma,
> > +
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thom
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
>
For uninitialized framebuffers, only release the DRM client and
free the fbdev memory. Do not attempt to clean up the framebuffer.
DRM fbdev clients have a two-step initialization: first create
the DRM client; then create the framebuffer device on the first
successful hotplug event. In cases where
The generic fbdev emulation names variables of type struct fb_info
both 'fbi' and 'info'. The latter seems to be more common in fbdev
code, so name fbi accordingly.
Also replace the duplicate variable in drm_fbdev_fb_destroy().
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canill
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_gene
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper, which prevents us from initializing these pointers
early after allo
Call drm_fb_helper_fini() in the generic-fbdev hotplug helper
to revert the effects of drm_fb_helper_init(). No full cleanup
is required.
v3:
* fix error in commit message (Javier)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_gene
Initialize the fb-helper's preferred_bpp field early from within
drm_fb_helper_prepare(); instead of the later client hot-plugging
callback. This simplifies the generic fbdev setup function.
No real changes, but all drivers' fbdev code has to be adapted.
v3:
* build with CONFIG_DRM_FBDEV_
The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 17 ++---
1
Store the console's preferred BPP value in struct drm_fb_helper
and remove the respective function parameters from the internal
fbdev code.
The BPP value is only required as a fallback and will now always
be available in the fb-helper instance.
No functional changes.
Signed-off-by: Thomas Zimmer
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
v2:
* declare as static inline (kernel test robot)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fb_helper.c | 14 +-
include/drm/drm_fb_
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
Add various cleanups and changes to DRM's fbdev helpers and the
generic fbdev emulation. There's no clear theme here, just lots
of small things that need to be updated.
In the end, the code will better reflect which parts are in the
DRM client, which is fbdev emulation, and which are shared fbde
On 1/24/2023 11:29 PM, Dmitry Baryshkov wrote:
On Wed, 25 Jan 2023 at 04:14, Abhinav Kumar wrote:
On 6/17/2022 4:33 PM, Dmitry Baryshkov wrote:
The array of CRTC in the struct msm_drm_private duplicates a list of
CRTCs in the drm_device. Drop it and use the existing list for CRTC
enumera
,
Reviewed-by: Abhinav Kumar
---
Changes since v1:
- Rebase on next-20230125 to solve conflicts with 43e3293fc614
("drm/msm/dpu: add support for MDP_TOP blackhole").
v1:
https://lore.kernel.org/linux-arm-msm/20230125091315.133283-1-marijn.suij...@somainline.org/T/#u
drivers/gpu/drm/msm
On 1/25/2023 1:13 AM, Marijn Suijten wrote:
Add missing DSC hardware block register ranges to the snapshot utility
to include them in dmesg (on MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE) and the
kms debugfs file.
Signed-off-by: Marijn Suijten
Huge ack from me,
Reviewed-by: Abhinav Kumar
---
On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > Replace indirect modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness. Add a BUG
On Wed, Jan 25, 2023 at 9:08 AM Michal Hocko wrote:
>
> On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > > Replace indirect modifications to vma->
On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
>
> On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
>
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2d6d790d9bed..6c7c70bf50dd 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linu
On Wed, Jan 25, 2023 at 1:42 AM Michal Hocko wrote:
>
> On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> > In cases when VMA flags are modified after VMA was isolated and mmap_lock
> > was downgraded, flags modifications would result in an assertion because
> > mmap write lock is not held.
>
On Wed, Jan 25, 2023 at 1:30 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> > Replace direct modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> > correctness.
>
> Is this
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> > > Replace indirect modifications to vma->vm_flags with calls to modifier
> > > functions to be able to track
Hi,
On Wed, Jan 25, 2023 at 9:22 AM Kuogee Hsieh wrote:
>
> > -void dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
> > +irqreturn_t dp_ctrl_isr(struct dp_ctrl *dp_ctrl)
> > {
> > struct dp_ctrl_private *ctrl;
> > u32 isr;
> > + irqreturn_t ret = IRQ_NONE;
> >
> > if (!dp_ctrl)
> > -
On 1/19/2023 2:53 PM, Douglas Anderson wrote:
If our interrupt handler gets called and we don't really handle the
interrupt then we should return IRQ_NONE. The current interrupt
handler didn't do this, so let's fix it.
NOTE: for some of the cases it's clear that we should return IRQ_NONE
and s
On 1/19/2023 2:53 PM, Douglas Anderson wrote:
The DP AUX interrupt handling was a bit of a mess.
* There were two functions (one for "native" transfers and one for
"i2c" transfers) that were quite similar. It was hard to say how
many of the differences between the two functions were on pu
Hi
Am 25.01.23 um 10:18 schrieb Javier Martinez Canillas:
On 1/24/23 14:40, Thomas Zimmermann wrote:
Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
functional changes.
v2:
* declare as static inline (kernel test robot)
Signed-off-by: Thomas Zimmermann
---
drive
Hi
Am 25.01.23 um 09:30 schrieb Javier Martinez Canillas:
Hello Thomas,
On 1/24/23 14:40, Thomas Zimmermann wrote:
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Sig
On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
Is this a manual (git grep) based work or have you used Coccinele for
the patch generation?
Replace direct modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness.
Signed-off-by: Suren Baghdasaryan
---
arch/arm/kernel/process.c | 2 +-
arch/ia64/mm/init.c
On Wed 25-01-23 00:38:51, Suren Baghdasaryan wrote:
> mmap_assert_write_locked() is used in vm_flags modifiers. Because
> mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
> modified from from inside a module, it's necessary to export
> dump_mm() function.
>
> Signed-off-by: Sur
On Wed 25-01-23 00:38:47, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 4 ++--
> kernel/fo
On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags modification attempts.
T
On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> In cases when VMA flags are modified after VMA was isolated and mmap_lock
> was downgraded, flags modifications would result in an assertion because
> mmap write lock is not held.
> Introduce mod_vm_flags_nolock to be used in such situation.
> P
To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
replace it with VM_LOCKED_MASK bitmask and convert all users.
Signed-off-by: Suren Baghdasaryan
---
include/linux/mm.h | 4 ++--
kernel/fork.c | 2 +-
mm/hugetlb.c | 4 ++--
mm/mlock.c | 6 +++---
mm/mmap.c
This patchset was originally published as a part of per-VMA locking [1] and
was split after suggestion that it's viable on its own and to facilitate
the review process. It is now a preprequisite for the next version of per-VMA
lock patchset, which reuses vm_flags modifier functions to lock the VMA
>On Tue, Jan 24, 2023 at 8:04 PM MyungJoo Ham wrote:
>>
>> >Sender : Rob Clark
>> >Date : 2023-01-24 00:37 (GMT+9)
>> >Title : [PATCH] PM / devfreq: Fix build issues with devfreq disabled
>> >
>> >From: Rob Clark
>> >
>> >The existing no-op shims for when PM_DEVFREQ (or an individual governor)
>
>Sender : Rob Clark
>Date : 2023-01-24 00:37 (GMT+9)
>Title : [PATCH] PM / devfreq: Fix build issues with devfreq disabled
>
>From: Rob Clark
>
>The existing no-op shims for when PM_DEVFREQ (or an individual governor)
>only do half the job. The governor specific config/tuning structs need
>to b
On Wed 25-01-23 00:38:46, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
> operations. Introduce
Replace indirect modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
vm_flags modification attempts.
Signed-off-by: Suren Baghdasaryan
---
arch/powerpc/kvm/book
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>
In cases when VMA flags are modified after VMA was isolated and mmap_lock
was downgraded, flags modifications would result in an assertion because
mmap write lock is not held.
Introduce mod_vm_flags_nolock to be used in such situation.
Pass a hint to untrack_pfn to conditionally use mod_vm_flags_no
vm_flags are among VMA attributes which affect decisions like VMA merging
and splitting. Therefore all vm_flags modifications are performed after
taking exclusive mmap_lock to prevent vm_flags updates racing with such
operations. Introduce modifier functions for vm_flags to be used whenever
flags a
mmap_assert_write_locked() is used in vm_flags modifiers. Because
mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes
modified from from inside a module, it's necessary to export
dump_mm() function.
Signed-off-by: Suren Baghdasaryan
---
mm/debug.c | 1 +
1 file changed, 1 insert
1.org/0day-ci/archive/20230125/202301252016.vm7ksfra-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.
Add missing DSC hardware block register ranges to the snapshot utility
to include them in dmesg (on MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE) and the
kms debugfs file.
Signed-off-by: Marijn Suijten
Reviewed-by: Neil Armstrong
---
Changes since v1:
- Rebase on next-20230125 to solve conflicts with
On 1/24/23 14:40, Thomas Zimmermann wrote:
> The generic fbdev emulation names variables of type struct fb_info
> both 'fbi' and 'info'. The latter seems to be more common in fbdev
> code, so name fbi accordingly.
>
> Also replace the duplicate variable in drm_fbdev_fb_destroy().
>
> Signed-off-b
On 1/24/23 14:40, Thomas Zimmermann wrote:
> For uninitialized framebuffers, only release the DRM client and
> free the fbdev memory. Do not attempt to clean up the framebuffer.
>
> DRM fbdev clients have a two-step initialization: first create
> the DRM client; then create the framebuffer device
On 1/24/23 14:40, Thomas Zimmermann wrote:
> The fbdev framebuffer cleanup in drm_fbdev_fb_destroy() calls
> drm_fbdev_release() and drm_fbdev_cleanup(). Inline both into the
> caller. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
B
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Call drm_fb_helper_init() in the generic-fbdev hotplug helper
drm_fb_helper_fini()
> to revert the effects of drm_fb_helper_init(). No full cleanup
> is required.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Initialize the fb-helper's preferred_bpp field early from within
> drm_fb_helper_prepare(); instead of the later client hot-plugging
> callback. This simplifies the generic fbdev setup function.
>
> No real changes, but all drivers' fbdev code has to be
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Store the console's preferred BPP value in struct drm_fb_helper
> and remove the respective function parameters from the internal
> fbdev code.
>
> The BPP value is only required as a fallback and will now always
> be available in the fb-helper instance
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Initialize the fb-helper structure immediately after its allocation
> in drm_fbdev_generic_setup(). That will make it easier to fill it with
> driver-specific values, such as the preferred BPP.
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
> @@ -4
Hi,
On 24/01/2023 11:45, Dmitry Baryshkov wrote:
There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Move the fb-helper clean-up code into drm_fb_helper_unprepare(). No
> functional changes.
>
> v2:
> * declare as static inline (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 14 +-
On 25/01/2023 10:13, Marijn Suijten wrote:
Add missing DSC hardware block register ranges to the snapshot utility
to include them in dmesg (on MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE) and the
kms debugfs file.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 f
Add missing DSC hardware block register ranges to the snapshot utility
to include them in dmesg (on MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE) and the
kms debugfs file.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/driv
On 25/01/2023 00:36, Marijn Suijten wrote:
On 2023-01-24 09:55:24, Kuogee Hsieh wrote:
This timing engine code is derived from our downstream code directly and
it has been used at many mobile devices by many vendors for many years
already.
On the other words, it had been tested very thorough
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Signal failed hotplugging with a flag in struct drm_client_dev. If set,
> the client helpers will not further try to set up the fbdev display.
>
> This used to be signalled with a combination of cleared pointers in
> struct drm_fb_helper, which prevents
On 23/01/2023 19:24, Kuogee Hsieh wrote:
Since display Port is an external peripheral, runtime compression
detection is added to handle plug in and unplugged events. Currently
only DSC compression supported. Once DSC compression detected, topology
is static added and used to allocate system resou
Hello Thomas,
On 1/24/23 14:40, Thomas Zimmermann wrote:
> Test for connectors in the client code and remove a similar test
> from the generic fbdev emulation. Do nothing if the test fails.
> Not having connectors indicates a driver bug.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: J
69 matches
Mail list logo
