To try and detect potential interrupt storms that
have been occurring with tpm_tis devices it was suggested
to use kstat_irqs() to get the number of interrupts.
Since tpm_tis can be built as a module it needs kstat_irqs
exported.
Reported-by: kernel test robot
Cc: Thomas Gleixner
Cc: Jarkko Sakk
The interrupt storm detection code detects the issue on the ThinkPad
T490s, but the L490 still hangs at initialization. So swap out the
T490s for the L490 in the dmi check.
Cc: Jarkko Sakkinen
Cc: Jason Gunthorpe
Cc: Peter Huewe
Cc: James Bottomley
Cc: Matthew Garrett
Cc: Hans de Goede
Signe
Now that kstat_irqs is exported, get rid of count_interrupts in
i915_pmu.c
Cc: Thomas Gleixner
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jarkko Sakkinen
Cc: Jason Gunthorpe
Cc: Peter Huewe
When enabling the interrupt code for the tpm_tis driver we have
noticed some systems have a bios issue causing an interrupt storm to
occur. The issue isn't limited to a single tpm or system manufacturer
so keeping a denylist of systems with the issue isn't optimal. Instead
try to detect the problem
This patchset is an attempt to try and catch tpm_tis devices that have
interrupt storm issues, disable the interrupt, and use polling. In
2016 the tpm_tis interrupt code was accidently disabled, and polling
was just being used. When we initially tried to enable interrupts
again there were some repo
Hi Tomi,
Thank you for the patch.
On Thu, Dec 03, 2020 at 01:48:45PM +0200, Tomi Valkeinen wrote:
> To support legacy gamma ioctls the drivers need to set
> drm_crtc_funcs.gamma_set either to a custom implementation or to
> drm_atomic_helper_legacy_gamma_set. Most of the atomic drivers do the
> l
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting sup
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simp
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that w
No functional changes yet, this just adds definitions for all of the
known DPCD registers used by Intel's HDR backlight interface. Since
we'll only ever use this in i915, we just define them in
intel_dp_aux_backlight.c
Reviewed-by: Rodrigo Vivi
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Since we're about to add support for a second type of backlight control
interface over DP AUX (specifically, Intel's proprietary HDR backlight
controls) let's rename all of the current backlight hooks we have for
vesa to make it clear that they're specific to the VESA interface and
not Intel's.
v3
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
Instead of using intel_panel->backlight.level, have the caller provide us
with the current panel backlight value. We'll need this for when we
separate PWM-related backlight callbacks from other means of backlight
control (like DPCD backlight controls), as the caller of each PWM callback
will be res
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight fu
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.
We also take care not to reprogram the source OUI i
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-sp
Hi Tomi,
Thank you for the patch.
On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAM
Hi James,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6
next-20201204]
[If your patch is applied to the
The rcar-du driver skips registration of the encoder for the LVDS1
output when LVDS is used in dual-link mode, as the LVDS0 and LVDS1 links
are bundled and handled through the LVDS0 output. It however still
allocates the encoder and immediately destroys it, which is pointless.
Skip allocation of th
The local encoder variable is an alias for &renc->base, and is only use
twice. It doesn't help much, drop it, along with the
rcar_encoder_to_drm_encoder() macro that is then unused.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 6 ++
drivers/gpu/drm/rcar-du/
Embedding drm_device in rcar_du_device allows usage of the DRM managed
API to allocate both structures in one go, simplifying error handling.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 33 +---
Now that drm_device is embedded in rcar_du_device, we can use
container_of to get the rcar_du_device pointer from the drm_device,
instead of using the drm_device.dev_private field.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
drivers/gpu/drm/rcar-du/rcar_du
devm_kzalloc() is the wrong API to allocate encoders, as the lifetime of
the encoders is tied to the DRM device, not the device to driver
binding. drmm_kzalloc() isn't a good option either, as it would result
in the encoder being freed before being unregistered during the managed
cleanup of the DRM
devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
the planes is tied to the DRM device, not the device to driver
binding. drmm_kcalloc() isn't a good option either, as it would result
in the planes being freed before being unregistered during the managed
cleanup of the DRM obje
Use drmm_add_action_or_reset() instead of drmm_add_action() to ensure
the vsp device reference is released in case the function call fails.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
The encoder->name field can never be non-null in the error path, as that
can only be possible after a successful call to
drm_simple_encoder_init(). Drop the cleanup.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +
1 file changed, 1 insertion(+), 4 deletio
Hello,
This patch series fixes a crash in the LVDS encoder on D3 and E3 SoCs.
See patch 1/9 for details. The next patches are additional cleanups.
Patches 4/9 to 6/9 fix incorrect usage of the devm_* API. They could be
made simpler by using the proposed drmm_* allocators for encoders and
planes (
On D3 and E3 platforms, the LVDS encoder includes a PLL that can
generate a clock for the corresponding CRTC, used even when the CRTC
output to a non-LVDS port. This mechanism is supported by the driver,
but the implementation is broken in dual-link LVDS mode. In that case,
the LVDS1 drm_encoder is
On Fri, Dec 4, 2020 at 11:51 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Without debugfs, the compiler notices one function that is not used at
> all:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused
> function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wu
On Fri, Dec 4, 2020 at 1:17 AM Zhou1, Tao wrote:
>
> [AMD Public Use]
>
> Reviewed-by: Tao Zhou
Applied. Thanks!
Alex
>
> > -Original Message-
> > From: Arnd Bergmann
> > Sent: Friday, December 4, 2020 7:07 AM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; David Airlie ; Daniel
On Friday, December 4th, 2020 at 9:02 PM, Daniel Vetter
wrote:
> I wanted to look up something and noticed the hyperlink doesn't work.
> While fixing that also noticed a trivial kerneldoc comment typo in the
> same section, fix that too.
Reviewed-by: Simon Ser
_
I wanted to look up something and noticed the hyperlink doesn't work.
While fixing that also noticed a trivial kerneldoc comment typo in the
same section, fix that too.
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/dma-buf.rst | 2 +-
include/linux/dma-buf-map.h | 2 +-
2 fi
On 04/12/2020 15:54, Boris Brezillon wrote:
> On Fri, 4 Dec 2020 13:47:05 +0200
> Tomi Valkeinen wrote:
>
>> On 04/12/2020 13:12, Boris Brezillon wrote:
>>
> That'd be even better if you implement the bridge interface instead of
> the encoder one so we can get rid of the encoder_{helper}_
On Fri, 2020-12-04 at 18:03 +0100, laniel_fran...@privacyrequired.com
wrote:
> In this patch set, I replaced all calls to strstarts() by calls to
> str_has_prefix(). Indeed, the kernel has two functions to test if a
> string begins with an other:
> 1. strstarts() which returns a bool, so 1 if the s
On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote:
> All warnings are related only to "wrong indentation", except one:
> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \
> [error] missing document start "---" (document-start)
It would make life easier (and be more normal pra
The pull request you sent on Fri, 4 Dec 2020 12:25:35 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-12-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e87297fa080a7ed6b431873c771b3801cab573f5
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
From: Arnd Bergmann
ttm_pool_type_count() is not used when debugfs is disabled:
drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
Move the definition into the #ifdef
From: Arnd Bergmann
Without debugfs, the compiler notices one function that is not used at
all:
drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:123:12: error: unused
function 'amdgpu_is_fw_attestation_supported' [-Werror,-Wunused-function]
In fact the static const amdgpu_fw_attestation_debu
On Thu, Dec 03, 2020 at 10:24:33PM +0300, Dmitry Osipenko wrote:
> Add modularization support to the Tegra124 EMC driver, which now can be
> compiled as a loadable kernel module.
>
> Note that EMC clock must be registered at clk-init time, otherwise PLLM
> will be disabled as unused clock at boot
On Thu, Dec 03, 2020 at 10:24:32PM +0300, Dmitry Osipenko wrote:
> Now Internal and External memory controllers are memory interconnection
> providers. This allows us to use interconnect API for tuning of memory
> configuration. EMC driver now supports OPPs and DVFS. MC driver now
> supports tuning
On Thu, Dec 03, 2020 at 10:24:31PM +0300, Dmitry Osipenko wrote:
> Support hardware versioning, which is now required for Tegra20 EMC OPP.
> Clean up OPP table initialization by using a error code returned by OPP
> API for judging about the OPP table presence in a device-tree and remove
> OPP regul
On Fri, Dec 4, 2020 at 4:11 PM Maxime Ripard wrote:
>
> Private objects storing a state shared across all CRTCs need to be
> carefully handled to avoid a use-after-free issue.
>
> The proper way to do this to track all the commits using that shared
> state and wait for the previous commits to be d
On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen wrote:
>
> On Thu, 3 Dec 2020 21:45:14 +0100
> Daniel Vetter wrote:
>
> > On Thu, Dec 3, 2020 at 7:55 PM James Park
> > wrote:
> > >
> > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't
> > > intentional, right? Should I put all the integ
On Tue, Dec 01, 2020 at 01:57:44AM +0300, Dmitry Osipenko wrote:
> 01.12.2020 00:17, Jon Hunter пишет:
> > Hi Dmitry,
> >
> > On 23/11/2020 00:27, Dmitry Osipenko wrote:
> >> Add EMC OPP DVFS tables and update board device-trees by removing
> >> unsupported OPPs.
> >>
> >> Signed-off-by: Dmitry Os
On 04/12/2020 13:12, Boris Brezillon wrote:
>>> That'd be even better if you implement the bridge interface instead of
>>> the encoder one so we can get rid of the encoder_{helper}_funcs and use
>>> drm_simple_encoder_init().
>>
>> I'm a bit confused here. What should be the design here...
>>
>>
On Thu, Dec 03, 2020 at 10:24:30PM +0300, Dmitry Osipenko wrote:
> Document opp-supported-hw property, which is not strictly necessary to
> have on Tegra20, but it's very convenient to have because all other SoC
> core devices will use hardware versioning, and thus, it's good to maintain
> the cons
On Thu, Dec 03, 2020 at 08:53:17PM -0700, Jim Cromie wrote:
> drm's debug system uses distinct categories of debug messages, mapped
> to bits in drm.debug. Currently, code does a lot of unlikely bit-mask
> checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
> instead, and get all
Hi Maxime
On Thu, 3 Dec 2020 at 07:46, Maxime Ripard wrote:
>
> The infoframes are sent at a regular interval as a data island packet,
> so we don't need to wait for them to be sent when we're setting them up.
>
> However, we do need to poll when we're enabling since the we can't
> update the pac
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole approach here
isn't correct.
See even when the job has been completed or canceled we still want to restart
the timer.
The reason for this is that the timer is then not restarted for t
Hi Boris,
On 04/12/2020 12:50, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:28 +0530
> Nikhil Devshatwar wrote:
>
>> Remove the old code to iterate over the bridge chain, as this is
>> already done by the framework.
>> The bridge state should have the negotiated bus format and flags.
>> Use
Hi James,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm/drm-next
v5.10-rc6 next-20201204]
[If your patch is
On Fri, 4 Dec 2020 13:47:05 +0200
Tomi Valkeinen wrote:
> On 04/12/2020 13:12, Boris Brezillon wrote:
>
> >>> That'd be even better if you implement the bridge interface instead of
> >>> the encoder one so we can get rid of the encoder_{helper}_funcs and use
> >>> drm_simple_encoder_init().
https://bugzilla.kernel.org/show_bug.cgi?id=209123
Stuart Foster (smf-li...@virginmedia.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi Sumera,
Thanks for the doc improvements.
Please see some complimentary comments below.
On 12/03, Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 8:13 PM Sumera Priyadarsini
> wrote:
> >
> > Update the vkms documentation to contain steps to:
> >
> > - setup the vkms driver
> > - run tests usin
On Fri, 4 Dec 2020 12:56:27 +0200
Tomi Valkeinen wrote:
> Hi Boris,
>
> On 04/12/2020 12:50, Boris Brezillon wrote:
> > On Tue, 1 Dec 2020 17:48:28 +0530
> > Nikhil Devshatwar wrote:
> >
> >> Remove the old code to iterate over the bridge chain, as this is
> >> already done by the framework.
On Tue, 1 Dec 2020 17:48:28 +0530
Nikhil Devshatwar wrote:
> Remove the old code to iterate over the bridge chain, as this is
> already done by the framework.
> The bridge state should have the negotiated bus format and flags.
> Use these from the bridge's state.
> If the bridge does not support
On Tue, 1 Dec 2020 17:48:27 +0530
Nikhil Devshatwar wrote:
> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
>
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from a
On Tue, 1 Dec 2020 17:48:26 +0530
Nikhil Devshatwar wrote:
> With new connector model, mhdp bridge will not create the connector and
> SoC driver will rely on format negotiation to setup the encoder format.
>
> Support minimal format negotiations hooks in the drm_bridge_funcs.
> Complete format
On Tue, 1 Dec 2020 17:48:27 +0530
Nikhil Devshatwar wrote:
> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
>
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from a
On Thu, 3 Dec 2020 18:20:48 +0530
Nikhil Devshatwar wrote:
> input_bus_flags are specified in drm_bridge_timings (legacy) as well
> as drm_bridge_state->input_bus_cfg.flags
>
> The flags from the timings will be deprecated. Bridges are supposed
> to validate and set the bridge state flags from a
Hi Laurent,
On Fri, 2020-12-04 at 11:19 +0200, Laurent Pinchart wrote:
> Hi Philipp,
>
> Thank you for the patch.
>
> On Fri, Sep 11, 2020 at 03:57:19PM +0200, Philipp Zabel wrote:
> > Add an alternative to drm_simple_encoder_init() that allocates and
> > initializes a simple encoder and registe
Hi Laurent,
On Fri, 2020-12-04 at 11:17 +0200, Laurent Pinchart wrote:
> Hi Philipp,
>
> Thank you for the patch.
Thank you for the review.
> On Fri, Sep 11, 2020 at 03:57:18PM +0200, Philipp Zabel wrote:
> > Add an alternative to drm_encoder_init() that allocates and initializes
> > an encoder
Am 04.12.20 um 10:29 schrieb Laurent Pinchart:
The drmm_add_final_kfree() function is declared in the
include/drm/drm_managed.h public header, but has become an internal API
not exposed to drivers. Drop it from drm_managed.h as it's already
declared in drm_internal.h.
Signed-off-by: Laurent Pi
The drmm_add_final_kfree() function is declared in the
include/drm/drm_managed.h public header, but has become an internal API
not exposed to drivers. Drop it from drm_managed.h as it's already
declared in drm_internal.h.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_managed.h | 2 --
1 fi
Hi Philipp,
Thank you for the patch.
On Fri, Sep 11, 2020 at 03:57:21PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_crtc_init_with_planes() that allocates
> and initializes a crtc and registers drm_crtc_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
>
Hi Philipp,
Thank you for the patch.
On Fri, Sep 11, 2020 at 03:57:20PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_universal_plane_init() that allocates
> and initializes a plane and registers drm_plane_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
>
Hi Philipp,
Thank you for the patch.
On Fri, Sep 11, 2020 at 03:57:19PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_simple_encoder_init() that allocates and
> initializes a simple encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philip
Hi Linus,
On Thu, Nov 19, 2020 at 09:35:17AM +0100, Linus Walleij wrote:
> On Wed, Nov 18, 2020 at 9:29 AM Guido Günther wrote:
>
> > This adds new panel type to the mantix driver as found on the Librem 5 and
> > fixes a glitch in the init sequence (affecting both panels). The fix is at
> > the
Hi Philipp,
Thank you for the patch.
On Fri, Sep 11, 2020 at 03:57:18PM +0200, Philipp Zabel wrote:
> Add an alternative to drm_encoder_init() that allocates and initializes
> an encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
>
> Signed-off-by: Philipp Zabel
> --
On 2020-12-04 at 14:32:16 +0530, Ramalingam C wrote:
> On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> > There can be situation when DP MST connector is created without
> > mst modeset being done, in those cases connector->encoder will be
> > NULL. MST connector->encoder initializes after
On 2020-11-26 at 13:07:08 +0530, Anshuman Gupta wrote:
> There can be situation when DP MST connector is created without
> mst modeset being done, in those cases connector->encoder will be
> NULL. MST connector->encoder initializes after modeset.
This patch is to reject the HDCP request on MST con
On Friday, December 4, 2020 5:53 AM, James Park
wrote:
> +#ifdef DRM_FOURCC_STANDALONE
> +#include
>
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +#else
> #include "drm.h"
> +#endif
C11 allows duplicate typedefs, but older versions of the standard
don't AFAIK. If this is a concern,
Am 04.12.20 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 03.12.20 um 21:41 schrieb Daniel Vetter:
On Thu, Dec 03, 2020 at 07:59:04PM +0100, Thomas Zimmermann wrote:
Hi
Am 03.12.20 um 16:26 schrieb Daniel Vetter:
On Thu, Dec 03, 2020 at 03:02:59PM +0100, Thomas Zimmermann wrote:
Dma-buf's vmap
On 12/3/20 7:01 PM, Dave Stevenson wrote:
Hi Marek
Hi,
[...]
+additionalProperties: false
+
+examples:
+ - |
+i2c1 {
Minor point.
I've just come to use this and noticed that this example puts the
device under i2c1. Seeing as it's a DSI driver with no I2C
interaction, shouldn't it be u
Hi,
This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the
Freescale i.MX8qxp SoC.
The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp
SCU firmware. The PHY driver would call a SCU funct
linux/rational.h is included more than once, Remove the one that isn't
necessary.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b15b4ce..105fa65 1
This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.
The parameters added here are based on common LVDS PHY
implementation practices. The set of parameters
should cover all potential users.
Cc: Kishon Vijay Abraham
The code has been in a irq-disabled context since it is hard IRQ. There
is no necessity to do it again.
Signed-off-by: Tian Tao
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
b/drivers/gp
From: Mikhail Durnev
MRB2801 display module [1] is an example of ILI9341 display that connects to
Intel 8080 parallel bus. Its connector is compatible with the ALIENTEK STM32
development board.
It can be used with the drm/mipi-dbi bus driver if the bus is emulated with
GPIO.
[1] http://www.lcdw
fixed the following warnings
drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ‘dev’
set but not used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
drivers/g
This series brings initial support for memory interconnect to Tegra20,
Tegra30 and Tegra124 SoCs.
For the starter only display controllers and devfreq devices are getting
interconnect API support, others could be supported later on. The display
controllers have the biggest demand for interconnect
Add DRM_FOURCC_STANDALONE guard to skip drm.h dependency.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
---
include/uapi/drm/drm_fourcc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
That pointer isn't used anywhere, so there's no point in keeping it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vc4/vc4_dsi.c | 9 -
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
ind
EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.
Signed-o
setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
add the missed unlocks with goto to fix it.
Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic
and legacy paths")
Signed-off-by: Chuhong Yuan
---
drivers/gpu/drm/drm_fb_helper.c | 15 ++--
The DSI clocks setup function has been using an array to store the clock
name of either the DSI0 or DSI1 blocks, using the port ID to choose the
proper one.
Let's switch to an snprintf call to do the same thing and simplify the
array a bit.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/v
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.
Tested-by: Nicolas Chauvet
Acked-by: Georgi Djakov
Signed-off-by: Dmitry Osipenko
---
drivers/mem
Previously we were using count-weight of the T124 for T30 in order to
get EMC clock rate that was reasonable for T30. In fact the count-weight
should be x2 times smaller on T30, but then devfreq was producing a bit
too low EMC clock rate for ISO memory clients, like display controller
for example.
From: Dave Stevenson
DSI0 was partially supported, but didn't register with the main
driver, and the code was inconsistent as to whether it checked
port == 0 or port == 1.
Add compatible string and other support to make it consistent.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
drm's debug system uses distinct categories of debug messages, mapped
to bits in drm.debug. Currently, code does a lot of unlikely bit-mask
checks on drm.debug (in drm_debug_enabled), we can use dynamic debug
instead, and get all that jump_label goodness.
RFC: dynamic debug has no concept of cate
This patch series add bus format negotiation support for Cadence MHDP8546
bridge driver.
The patch series has four patches in the below sequence:
1. drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge
function.
Return all the input formats supported.
2. drm: bridge: cdns-mhd
Get the pixel format and bpc based on the output bus format
negotiated instead of hardcoding the values.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 82 +++
1 file changed, 64 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/
Most of the differences between DSI0 and DSI1 are handled through the
ID. However, the BCM2711 DSI is going to introduce one more variable to
the mix and will break some expectations of the earlier, simpler, test.
Let's add a variant structure that will address most of the differences
between thos
Modify atomic_get_input_bus_format function to return input formats
supported instead of using hardcoded value.
Signed-off-by: Yuti Amonkar
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 83 +--
1 file changed, 74 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/b
On 18/11/2020 13:03, Lukasz Luba wrote:
> The Energy Model (EM) framework supports devices such as Devfreq. Create
> new registration functions which automatically register EM for the thermal
> devfreq_cooling devices. This patch prepares the code for coming changes
> which are going to replace old
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale data
and get more up-to-date values of the load.
Devfreq framework ca
deletted unused variable ‘priv’.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 04fee18..8
Delete the entire file hibmc_ttm.c. drmm_vram_helper_init() can be
called directly from hibmc_load(). hibmc_dumb_create() and
hibmc_mode_funcs can go to hibmc_drm_drv.c
v2:
change Deletted to Delete
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Make
i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
either a MIPI DSI display or a LVDS display. The PHY mode is controlled
by SCU firmware and the driver would call a SCU firmware function to
configure the PHY mode. The single LVDS PHY has 4 data lanes to support
a LVDS display
Add DRM_FOURCC_STANDALONE guard to skip drm.h dependency.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
James Park (1):
drm: Allow drm_fourcc.h without including drm.h
include/uapi/drm/drm_fourcc.h | 6 ++
1 file changed, 6 insertions(+)
--
2.7.4
1 - 100 of 150 matches
Mail list logo
