When I tried to test patches applied to v5.15-rc3, I hit this bug (and
hence can not test my code), on 32 bit x86.
[ cut here ]
kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!
invalid opcode: [#1] SMP PTI
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc1-tes
applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Lucas-De-Marchi/drm-i915-remove-IS_ACTIVE/20211001-154226
b
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On Fri, Sep 24, 2021 at 08:43:07AM
On 2021-10-01 18:08, Dmitry Baryshkov wrote:
The DSI host might be left in some state by the bootloader. If this
state generates an IRQ, it might hang the system by holding the
interrupt line before the driver sets up the DSI host to the known
state.
Move the request_irq into msm_dsi_host_init a
Use clk_bulk_* API instead of hand-coding them. Note, this drops support
for legacy clk naming (e.g. "iface_clk" instead of just "iface"),
however all in-kernel device trees were converted long long ago. The
warning is present there since 2017.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm
On 28/09/2021 04:40, Dmitry Baryshkov wrote:
On 28/09/2021 04:33, abhin...@codeaurora.org wrote:
On 2021-09-27 18:29, Dmitry Baryshkov wrote:
On 28/09/2021 04:19, abhin...@codeaurora.org wrote:
On 2021-09-27 18:06, Dmitry Baryshkov wrote:
On Tue, 28 Sept 2021 at 03:22, wrote:
On 2021-09-25
On 02/10/2021 04:08, Dmitry Baryshkov wrote:
PM8xxx PMIC family uses GPIO as parent IRQ. Using it together with the
irq_set_chained_handler_and_data() results in warnings from the GPIOLIB
as in this path the IRQ resources are not allocated (and thus the
corresponding GPIO is not marked as used fo
The DSI host might be left in some state by the bootloader. If this
state generates an IRQ, it might hang the system by holding the
interrupt line before the driver sets up the DSI host to the known
state.
Move the request_irq into msm_dsi_host_init and pass IRQF_NO_AUTOEN to
it. Call enable/disab
PM8xxx PMIC family uses GPIO as parent IRQ. Using it together with the
irq_set_chained_handler_and_data() results in warnings from the GPIOLIB
as in this path the IRQ resources are not allocated (and thus the
corresponding GPIO is not marked as used for the IRQ. Use request_irq so
that the IRQ reso
On 01/10/2021 15:36, Dan Carpenter wrote:
The "msg->tx_len" variable is type size_t so if dsi_cmds2buf_tx()
returns a negative error code that it type promoted to a high positive
value and treat as a success. The second problem with this code is
that it can return meaningless positive values on
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixe
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
w
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed,
When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us d
On 01/10/2021 15:34, Dan Carpenter wrote:
This disables a lock which wasn't enabled and it does not disable
the first lock in the array.
Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter
Reviewed-by: Dmitry Baryshkov
We should probably switch thi
On 01/10/2021 15:33, Dan Carpenter wrote:
Return an error code if msm_dsi_manager_validate_current_config().
Don't return success.
Fixes: 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode")
Signed-off-by: Dan Carpenter
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
On 29/09/2021 20:51, Tim Gardner wrote:
Coverity warns of an unintentional integer overflow
CID 120715 (#1 of 1): Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)
overflow_before_widen: Potentially overflowing expression ref_clk * sdm_byp_div
with type unsigned int (32 bits, unsigned) i
On 29/09/2021 19:25, Tim Gardner wrote:
Coverity complains of a possible NULL dereference:
CID 120718 (#1 of 1): Dereference null return value (NULL_RETURNS)
23. dereference: Dereferencing a pointer that might be NULL state->bos when
calling msm_gpu_crashstate_get_bo. [show details]
301
On 26/08/2021 05:23, zhaoxiao wrote:
Use a more common logging style.
Signed-off-by: zhaoxiao
Your subject tells about pr_fmt(), while the patch itself changs
printk()s to pr_info(). Could you please fix the commit subject and
expand/correct commit message?
---
v2:Remove the line: #defin
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote:
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always
checking if the relative CTL is started by waiting for an interrupt
to fire: it is fine to do that, but then sometimes we call this
function while the CTL is up and has never
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > > Hi all,
> > > >
> > > > One of th
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get the panel and PM state right before trying to talk AUX.
Fixes: 0d97ad03f422 ("drm/br
On 29/09/2021 14:53, Colin King wrote:
From: Colin Ian King
In the case where clock is 2147485 or greater the 32 bit multiplication
by 1000 will cause an integer overflow. Fix this by making the constant
1000 an unsigned long to ensure a long multiply occurs to avoid the
You are talking about
01.10.2021 17:06, Ulf Hansson пишет:
> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>> Add runtime power management and support generic power domains.
>>
>> Tested-by: Peter Geis # Ouya T30
>> Tested-by: Paul Fertser # PAZ00 T20
>> Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1 T124
>>
On Fri, Oct 1, 2021 at 1:37 PM Sean Paul wrote:
> On Wed, Sep 29, 2021 at 02:41:03PM -0700, Brian Norris wrote:
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -1632,8 +1632,23 @@ static ssize_t analogix_dpaux_transfe
On 28/09/2021 16:19, Sireesh Kodali wrote:
From: Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant
difference being presence of second DSI interface. MDP v1.16 is found on
SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506).
Signed-off-by: Vladimir Lypa
On Fri 27 Aug 13:52 PDT 2021, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 26, 2021 at 4:15 PM Bjorn Andersson
> wrote:
> >
> > +static int dp_parser_find_panel(struct dp_parser *parser)
> > +{
> > + struct device_node *np = parser->pdev->dev.of_node;
> > + int rc;
> > +
> > + rc
On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > Hi all,
> > >
> > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was
> > >
On Wed, Sep 29, 2021 at 02:41:03PM -0700, Brian Norris wrote:
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get the panel and
On Wed, Sep 29, 2021 at 03:39:25PM -0400, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, whi
On Wed, Sep 29, 2021 at 03:39:26PM -0400, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> drm_atomic_helper_check_crtc now verifies both legacy and non-legacy LUT
> sizes. There is no need to check it within amdgpu_dm_atomic_check.
>
> [How]
> Remove the local call to verify LUT sizes and use
01.10.2021 15:32, Ulf Hansson пишет:
>> +static int tegra_clock_sync_pd_state(struct tegra_clk_device *clk_dev)
>> +{
>> + unsigned long rate;
>> + int ret = 0;
>> +
>> + mutex_lock(&clk_dev->lock);
>> +
>> + if (!pm_runtime_status_suspended(clk_dev->dev)) {
>> +
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6
drivers/gpu/drm/msm/adreno/a6xx
01.10.2021 15:50, Ulf Hansson пишет:
> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>>
>> Only couple drivers need to get the -ENODEV error code and majority of
>> drivers need to explicitly initialize the performance state. Add new
>> common helper which sets up OPP table for these drive
Hey Dan,
Thanks for the heads up, will take care of it.
On 2021-10-01 05:28, Dan Carpenter wrote:
Hello Jeykumar Sankaran,
The patch 25fdd5933e4c: "drm/msm: Add SDM845 DPU support" from Jun
27, 2018, leads to the following
Smatch static checker warning:
drivers/gpu/drm/msm/disp/dpu1/d
Hey Dan,
Thanks for the report, will take care of it.
On 2021-10-01 06:50, Dan Carpenter wrote:
On Fri, Oct 01, 2021 at 04:49:12PM +0300, Dan Carpenter wrote:
Hello Jeykumar Sankaran,
This is a semi-automatic email about new static checker warnings.
The patch 25fdd5933e4c: "drm/msm: Add SDM8
On Fri, 01 Oct 2021 11:11:41 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > Hi all,
> >
> > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> > "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's wha
Hey Dan,
Thanks for the heads up, will take care of it.
On 2021-10-01 06:59, Dan Carpenter wrote:
Hello Abhinav Kumar,
The patch d11a93690df7: "drm/msm/dp: add debugfs support to DP
driver" from Sep 12, 2020, leads to the following
Smatch static checker warning:
drivers/gpu/drm/msm/dp
01.10.2021 17:55, Ulf Hansson пишет:
> On Fri, 1 Oct 2021 at 16:29, Dmitry Osipenko wrote:
>>
>> 01.10.2021 16:39, Ulf Hansson пишет:
>>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
Add runtime power management and support generic power domains.
Tested-by: Peter Geis
Hey Dan,
Thanks for the report, will take care of it.
On 2021-10-01 05:31, Dan Carpenter wrote:
Hello Sean Paul,
The patch a6bcddbc2ee1: "drm/msm: dsi: Handle dual-channel for 6G as
well" from Jul 25, 2018, leads to the following
Smatch static checker warning:
drivers/gpu/drm/msm/dsi/
On 10/1/21 12:09 AM, Stephen Rothwell wrote:
Hi all,
News: there will be no linux-next release on Monday.
Changes since 20210930:
on i386:
ERROR: modpost: "dm_ip_block" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Full randconfig file is attached.
--
~Randy
config-r5146.gz
Descript
On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> Hi all,
>
> One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
> "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
> patch series is about.
>
> You will find two types of chang
On 29/09/2021 15:18, Colin King wrote:
From: Colin Ian King
The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.
Addresses-Coverity: ("Der
On Thu, Sep 30, 2021 at 03:01:19PM -0700, Matt Roper wrote:
> On Sun, Sep 26, 2021 at 10:10:05PM +0200, Michal Wajdeczko wrote:
> > We assumed that for all modern GENs the PTEs and register space are
> > split in the GTTMMADR BAR, but while it is true, we should rather use
> > fixed offset as it is
Hi,
On Thu, Sep 23, 2021 at 7:26 PM Laurent Pinchart
wrote:
>
> > > > err_conn_init:
> > > > drm_dp_aux_unregister(&pdata->aux);
> > > > return ret;
> > > > @@ -792,9 +790,30 @@ static void ti_sn_bridge_set_dsi_rate(struct
> > > > ti_sn65dsi86 *pdata)
> > > > regmap_write(pdat
On 01/10/2021 21:05, Rob Clark wrote:
On Fri, Oct 1, 2021 at 10:39 AM Dmitry Baryshkov
wrote:
On 27/09/2021 21:03, Rob Clark wrote:
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
a
Hi,
On Wed, Sep 22, 2021 at 5:31 PM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Sep 20, 2021 at 03:57:59PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > For the brave new world of bridges not creating their own connectors, we
> > need to implement the max c
On Fri, Oct 1, 2021 at 10:39 AM Dmitry Baryshkov
wrote:
>
> On 27/09/2021 21:03, Rob Clark wrote:
> > From: Rob Clark
> >
> > I've seen some crashes in our crash reporting that *look* like multiple
> > threads stomping on each other while communicating with GMU. So wrap
> > all those paths in a
Functions in the DisplayPort code that relates to individual instances
(encoders) are passed both the struct msm_dp and the struct drm_encoder. But
in a situation where multiple DP instances would exist this means that
the caller need to resolve which struct msm_dp relates to the struct
drm_encoder
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM driver, introduce a
per-compatible list of base addresses which is used to resolve the
"instance id" for
The sc8180x has 2 DP and 1 eDP controllers, add support for these to the
DP driver.
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
drivers/gpu/drm/msm/dp/dp_display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_di
The Qualcomm SC8180x has 2 DP controllers and 1 eDP controller, add
compatibles for these to the msm/dp binding.
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
.../devicetree/bindings/display/msm/dp-controller.yaml | 2 ++
1 file changed, 2 inse
As the Qualcomm DisplayPort driver only supports a single instance of
the driver the commonly used struct dp_display is kept in a global
variable. As we introduce additional instances this obviously doesn't
work.
Replace this with a combination of existing references to adjacent
objects and drvdat
The current implementation supports a single DP instance and the DPU code will
only match it against INTF_DP instance 0. These patches extends this to allow
multiple DP instances and support for matching against DP instances beyond 0.
With that in place add SC8180x DP and eDP controllers.
Bjorn A
On Fri, Oct 1, 2021 at 10:28 AM Dmitry Baryshkov
wrote:
>
> On 21/09/2021 01:57, Rob Clark wrote:
> > From: Rob Clark
> >
> > For now, since we have a mix of bridges which support this flag, which
> > which do *not* support this flag, or work both ways, try it once with
> > NO_CONNECTOR and then
From: Rob Clark
Some userspace apps make assumptions that rendering against multiple
contexts within the same process (from the same thread, with appropriate
MakeCurrent() calls) provides sufficient synchronization without any
external synchronization (ie. glFenceSync()/glWaitSync()). Since a
su
From: Rob Clark
msm_file_private is more gpu related, and in the next commit it will
need access to other GPU specific #defines. While we're at it, add
some comments.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.h | 44 --
drivers/gpu/drm/msm/msm_gpu.h | 58
From: Rob Clark
Userspace is expecting that a single thread doing rendering against
multiple contexts does not need additional synchronization between those
contexts beyond ensuring work is flushed to the kernel in the correct
order. But if we have a sched-entity per-context, and are not using
i
vfio_ccw will need it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 3 ++-
include/linux/vfio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 08b27b64f0f935..44adf112e3b5dd 100644
--- a/drivers/vfio/vfio.c
+++ b/
The css_driver's main purpose is to create/destroy the mdev and relay the
shutdown, irq, sch_event, and chp_event css_driver ops to the single
created vfio_device, if it exists.
Reframe the boundary where the css_driver domain switches to the vfio
domain by using rcu to read and refcount the vfio_
Every driver just emits a static string, simply feed it through the ops
and provide a standard sysfs show function.
Signed-off-by: Jason Gunthorpe
---
.../driver-api/vfio-mediated-device.rst | 4 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +--
drivers/s390/cio/vfio_ccw_ops
Many of the mdev drivers use a simple counter for keeping track of the
available instances. Move this code to the core code and store the counter
in the mdev_type. Implement it using correct locking, fixing mdpy.
Drivers provide a get_available() callback to set the number of available
instances f
mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Reviewed-by: Christoph Hellwig
Reviewed-by: Cornelia Huck
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthor
The subchannel should be left in a quiescent state unless the VFIO device
FD is opened. When the FD is opened bring the chanel to active and allow
the VFIO device to operate. When the device FD is closed then quiesce the
channel.
To make this work the FSM needs to handle the transitions to/from op
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Reviewed-by: Eric Farman
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 137 ++--
1 file changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/s390/
Having a mdev pointer floating about in addition to a struct vfio_device
is confusing. It is only used for three things:
- Getting the mdev 'struct device *' - this is the same as
private->vdev.dev
- Printing the uuid of the mdev in logging. The uuid is also the dev_name
of the mdev so thi
This is a more complicated conversion because vfio_ccw is sharing the
vfio_device between both the mdev_device, its vfio_device and the
css_driver.
The mdev is a singleton, and the reason for this sharing is so the extra
css_driver function callbacks to be delivered to the vfio_device
implementati
This addresses Cornelia's remark on the earlier patch that ccw has a
confusing lifecycle. While it doesn't seem like the original attempt was
functionally wrong, the result can be made better with a lot of further
work.
Reorganize the driver so that the mdev owns the private memory and
controls th
Since the ccw_io_region was split out of the private the allocation no
longer needs the GFP_DMA. Remove it.
Reported-by: Christoph Hellwig
Fixes: c98e16b2fa12 ("s390/cio: Convert ccw_io_region to pointer")
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 2 +-
1 file changed
The pull request you sent on Fri, 1 Oct 2021 18:57:06 +0200:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-10-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/24f67d82c43c9c594821ee1bc4367a23d89d9f8b
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On 29/09/2021 13:54, Colin King wrote:
From: Colin Ian King
The variable bpp is being initialized with a value that is never
read, it is being updated later on in both paths of an if statement.
The assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by:
Not all platforms has P0 at an offset of 0x1000 from the base address,
so add support for specifying each sub-region in DT. The code falls back
to the predefined offsets in the case that only a single reg is
specified, in order to support existing DT.
Reviewed-by: Stephen Boyd
Reviewed-by: Abhina
In order to deal with multiple memory ranges in the following commit
change the ioremap wrapper to not poke directly into the dss_io_data
struct.
While at it, devm_ioremap_resource() already prints useful error
messages on failure, so omit the unnecessary prints from the caller.
Signed-off-by: Bj
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the
DP block. So split the dss_io_data memory region into a set of
sub-regions, to make it possible in the next patch to specify each of
the sub-regions individually.
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
reg was defined as one region covering the entire DP block, but the
memory map is actually split in 4 regions and obviously the size of
these regions differs between platforms.
Switch the reg to require that all four regions are specified instead.
It is expected that the implementation will handle
The non-devres version of ioremap is used, which requires manual
cleanup. But the code paths leading here is mixed with other devres
users, so rely on this for ioremap as well to simplify the code.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
Changes
It turns out that sc8180x (among others) doesn't have the same internal
layout of the 4 subblocks. This series therefor modifies the binding to
require all four regions to be described individually and then extends
the driver to read these four regions. The driver will fall back to read
the old sin
On 27/09/2021 21:03, Rob Clark wrote:
From: Rob Clark
I've seen some crashes in our crash reporting that *look* like multiple
threads stomping on each other while communicating with GMU. So wrap
all those paths in a lock.
Signed-off-by: Rob Clark
---
Are we allowed to use c99/gnu99 yet?
d
> The IOMMU_DEVONLY flag allows the caller to flag a mappings backed by
> device-private buffers. That means other devices or CPUs are not
> expected to access the physical memory region pointed by the mapping,
> and the MMU driver can safely restrict the shareability domain to the
> device itself.
> > This seems reasonable to me - it matches the kbase
> > BASE_MEM_COHERENT_SYSTEM (only backwards obviously) and it worked
> > reasonably well for the blob.
Oh, is that what that was for? I remember seeing it set on Midgard for
varyings. Good to go full circle now.
> > But I'm wondering if we n
On 21/09/2021 01:57, Rob Clark wrote:
From: Rob Clark
For now, since we have a mix of bridges which support this flag, which
which do *not* support this flag, or work both ways, try it once with
NO_CONNECTOR and then fall back to the old way if that doesn't work.
Eventually we can drop the fall
On 21/09/2021 00:20, Rikard Falkeborn wrote:
The only usage of hdmi_8996_pll_ops is to assign its address to the ops
field in the clk_init_data struct, and the only usage of pll_init is to
assign its address to the init field in the clk_hw struct, both which
are pointers to const. Make them const
On 17/09/2021 03:59, Marek Vasut wrote:
The return type of ktime_divns() is s64. The timeout_to_jiffies() currently
assigns the result of this ktime_divns() to unsigned long, which on 32 bit
systems may overflow. Furthermore, the result of this function is sometimes
also passed to functions which
On 06/09/2021 23:25, Marijn Suijten wrote:
The downstream driver models this PLL lock check as an if-elseif-else.
The only way to reach the else case where pll_locked=true [1] is by
succeeding both readl_poll_timeout_atomic calls (which return zero on
success) in the if _and_ elseif condition. H
On Fri 01 Oct 09:50 PDT 2021, Dmitry Baryshkov wrote:
> MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC
> families. However since addition back in 2015 this driver received only
> generic fixes. No actual devices with these SoCs supported upstream (or
> by the community) seem
Hi Linus,
Dave is out on a long w/e, should be back next week. Nothing nefarious,
just a bunch of driver fixes.
Cheers, Daniel
drm-fixes-2021-10-01:
drm fixes for -rc4:
amdgpu, i915, tegra, and one exynos driver fix
Cheers, Daniel
The following changes since commit 5816b3e6577eaa676ceb00a848f
On Tue, Sep 28, 2021 at 04:41:58PM +0900, Inki Dae wrote:
> Hi Dave,
>
>Just one clean up to use helper function.
>
> Please kindly let me know if there is any problem.
>
> Thanks,
> Inki Dae
>
> The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:
>
> Linux 5.15-
MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC
families. However since addition back in 2015 this driver received only
generic fixes. No actual devices with these SoCs supported upstream (or
by the community) seem to support eDP panels. Judging from downstream
kernels the eDP
eDP driver is being removed, so drop bindings description.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/edp.txt | 56 ---
1 file changed, 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/edp.txt
diff --git a/Documenta
Prepare for removing old eDP support present in 8x74/8x84 SoC families.
No devices present in mainline support eDP ports.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu
MSM DRM driver has support for eDP block present on MSM 8x74/8x84 SoC
families. However since addition back in 2015 this driver received only
generic fixes. No actual devices with these SoCs supported upstream (or
by the community) seem to support eDP panels. Judging from downstream
kernels the eDP
On Wednesday, September 22nd, 2021 at 11:21, Hans de Goede
wrote:
> I would be happy to work on the plymouth side of this, so that we
> have at least one consumer of such a flag lined up for merging.
Do you have plans to work on the kernel side part of this? If so, feel free to
CC me for a revi
On Fri, Oct 01, 2021 at 12:57:13PM +0300, Jani Nikula wrote:
On Fri, 01 Oct 2021, Chris Wilson wrote:
Quoting Lucas De Marchi (2021-10-01 08:40:41)
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
a
On Fri, 1 Oct 2021 16:13:42 +0100
Steven Price wrote:
> On 01/10/2021 15:34, Boris Brezillon wrote:
> > This lets the driver reduce shareability domain of the MMU mapping,
> > which can in turn reduce access time and save power on cache-coherent
> > systems.
> >
> > Signed-off-by: Boris Brezillo
Hi, Markus:
Markus Schneider-Pargmann 於 2021年10月1日 週五 下午5:44寫道：
>
> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC and a
> according phy driver mediatek-dp-phy.
>
> It supports both functional units on the mt8195, the embedded
> DisplayPort as well as the external DisplayPort un
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
v3:
(Checkpatch / Tvrtko)
- Remove
On Fri, Oct 01, 2021 at 09:40:19AM +0100, Tvrtko Ursulin wrote:
>
> + Daniel as reviewer and maybe merge, avoid falling through cracks at least.
>
Ty, working on push rights myself.
> On 22/09/2021 20:43, Matthew Brost wrote:
> > Set number of engines before attempting to create contexts so the
Hi, Enric:
Enric Balletbo Serra 於 2021年9月30日 週四 下午9:48寫道：
>
> Hi Chun-Kuang,
>
> Missatge de Chun-Kuang Hu del dia dj., 30 de
> set. 2021 a les 15:11:
> >
> > Hi, Enric:
> >
> > Enric Balletbo Serra 於 2021年9月30日 週四 下午3:12寫道：
> > >
> > > Hi Jason,
> > >
> > >
> > > Missatge de jason-jh.lin del
1 - 100 of 235 matches
Mail list logo
