Let's use the newly-added nvmem_cell_read_variable_le_u32() to future
proof ourselves a little bit.
Signed-off-by: Douglas Anderson
---
This is based on my previous patch ("drm/msm: Fix speed-bin support
not to access outside valid memory") which has already landed in
msm-next. In case it's not
On Mon, Mar 1, 2021 at 2:44 AM Christoph Hellwig wrote:
>
> Hi all,
>
> there are a bunch of IOMMU APIs that are entirely unused, or only used as
> a private communication channel between the FSL PAMU driver and it's only
> consumer, the qbman portal driver.
>
> So this series drops a huge chunk
On 3/5/21 5:45 PM, Dmitry Baryshkov wrote:
On 15/02/2021 19:27, Jonathan Marek wrote:
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
Other that few comments
On 15/02/2021 19:27, Jonathan Marek wrote:
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
Other that few comments bellow:
Reviewed-by: Dmitry Baryshkov
On 3/5/21 4:48 PM, Rob Herring wrote:
On Mon, Feb 15, 2021 at 11:27:44AM -0500, Jonathan Marek wrote:
Add the required changes to support 7nm pll/phy in CPHY mode.
This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
the CPHY mode.
Signed-off-by: Jonathan Marek
---
On Mon, Feb 15, 2021 at 11:27:44AM -0500, Jonathan Marek wrote:
> Add the required changes to support 7nm pll/phy in CPHY mode.
>
> This adds a "qcom,dsi-phy-cphy-mode" property for the PHY node to enable
> the CPHY mode.
>
> Signed-off-by: Jonathan Marek
> ---
>
On Mon, 15 Feb 2021 11:26:04 -0500, Jonathan Marek wrote:
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Also inverse the non-mdp4 condition in add_display_components() to avoid
> having to check every new compatible in the condition.
>
>
Currently the error checking logic in the dp_debug module could
pass zero to PTR_ERR and it causes the below kbot warnings:
drivers/gpu/drm/msm/dp/dp_debug.c:378 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:387 dp_debug_init()
warn: passing zero to 'PTR_ERR'
Fix a couple of indentation warnings reported by
kbot across MSM DP driver:
New smatch warnings:
drivers/gpu/drm/msm/dp/dp_debug.c:229 dp_test_data_show()
warn: inconsistent indenting
drivers/gpu/drm/msm/dp/dp_power.c:203 dp_power_clk_enable()
warn: inconsistent indenting
Reported-by: kernel
Fix an incorrect NULL check reported by kbot in the MSM DP driver
smatch warnings:
drivers/gpu/drm/msm/dp/dp_hpd.c:37 dp_hpd_connect()
error: we previously assumed 'hpd_priv->dp_cb' could be null
(see line 37)
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Abhinav
Hi Stephen
Thanks for the review.
I will break this up into patches according to the class of warning to
show the warning in the commit text
and resend the patches.
Abhinav
On 2021-03-04 23:23, Dan Carpenter wrote:
On Thu, Mar 04, 2021 at 10:55:58PM -0800, Stephen Boyd wrote:
> @@ -368,44
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
On 05/03/2021 14:45, Doug Anderson wrote:
Hi,
On Fri, Mar 5, 2021 at 2:28 AM Srinivas Kandagatla
wrote:
On 27/02/2021 00:26, Douglas Anderson wrote:
When running the latest kernel on an sc7180 with KASAN I got this
splat:
BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
The vmwgfx ones look all good to me, so for
23-53: Reviewed-by: Roland Scheidegger
That said, they were already signed off by Zack, so not sure what
happened here.
Roland
On 03.03.21 14:42, Lee Jones wrote:
> This is a resend. All of these patches have been sent before.
>
> The vmwgfx ones
Hi,
On Fri, Mar 5, 2021 at 2:28 AM Srinivas Kandagatla
wrote:
>
>
>
> On 27/02/2021 00:26, Douglas Anderson wrote:
> > When running the latest kernel on an sc7180 with KASAN I got this
> > splat:
> >BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
> >Read of size 4 at addr
On Thu, Mar 04, 2021 at 10:55:58PM -0800, Stephen Boyd wrote:
> > @@ -368,44 +368,21 @@ static int dp_debug_init(struct dp_debug *dp_debug,
> > struct drm_minor *minor)
> > int rc = 0;
> > struct dp_debug_private *debug = container_of(dp_debug,
> > struct
On 27/02/2021 00:26, Douglas Anderson wrote:
When running the latest kernel on an sc7180 with KASAN I got this
splat:
BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
Read of size 4 at addr ff8088f36100 by task kworker/7:1/58
CPU: 7 PID: 58 Comm: kworker/7:1 Not
On Thu, Mar 04, 2021 at 03:11:08PM -0800, Rob Clark wrote:
> On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy wrote:
> >
> > On 2021-03-01 08:42, Christoph Hellwig wrote:
> > > Signed-off-by: Christoph Hellwig
> >
> > Moreso than the previous patch, where the feature is at least relatively
> >
On 05/03/2021 09:12, Steven Price wrote:
> On 04/03/2021 12:50, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no so many and actually it makes more sense to register the
>>
19 matches
Mail list logo
