> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> Instead of bouncing the function call to the driver op through a blocking
> notifier just have the iommu layer call it directly.
>
> Register each device that is being attached to the iommu with the lower
> driver which then
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> Instead of having drivers register the notifier with explicit code just
> have them provide a dma_unmap callback op in their driver ops and rely on
> the core code to wire it up.
>
> Suggested-by: Christoph Hellwig
>
Add panel identification entry for the Sharp LQ140M1JW48 eDP panel.
Due to lacking documentation, a delay similar to those for the
LQ140M1JW46 numbers are picked for now.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Magali Lemes
The bw_fixed library performs a lot of the mathematical operations
involving fixed-point arithmetic and the conversion of integers to
fixed-point representation.
As fixed-point representation is the base foundation of the DML calcs
operations, this unit tests intend to assure
The macros defined at bw_fixed are important mathematical definitions,
specifying masks to get the fractional part and the maximum and minimum
values of I64. In order to enable unit tests for bw_fixed, it is
relevant to have access to those macros. This commit moves the macros to
the header file,
KUnit unifies the test structure and provides helper tools that simplify
the development. Basic use case allows running tests as regular
processes, which makes easier to run unit tests on a development machine
and to integrate the tests in a CI system.
This commit introduce a basic unit test to
This RFC is a preview of the work being developed by Isabella Basso [1],
Maíra Canal [2], and Tales Lelo [3], as part of their Google Summer of Code
projects [4], and Magali Lemes [5], as part of her capstone project.
Our main goal is to bring unit testing to the AMDPGU driver; in particular,
A new PVC+DG2 workaround has appeared recently:
- Wa_16015675438
And a couple existing DG2 workarounds have been extended to PVC:
- Wa_14015795083
- Wa_18018781329
Note that Wa_16015675438 asks us to program a register that is in the
0x2xxx range typically associated with the RCS engine, even
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_rps.c
between commit:
56758cc45955 ("drm/i915/rps: Centralize computation of freq caps")
from Linus' tree and commit:
ee421bb4cb95 ("drm/i915/pcode: Extend pcode functions for
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_dmc_regs.h
between commit:
2518f226c60d ("Merge tag 'drm-next-2022-05-25' of
git://anongit.freedesktop.org/drm/drm")
from Linus' tree and commit:
21c47196aec3 ("drm/i915/dmc:
On 6/7/2022 15:29, Dixit, Ashutosh wrote:
On Sat, 14 May 2022 23:05:06 -0700, Vinay Belgaumkar wrote:
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing warnings and affecting CI.
This
From: Bjorn Helgaas
PCI-specific power management (pci_driver.suspend and pci_driver.resume) is
deprecated. If drivers implement power management, they should use the
generic power management framework, not the PCI-specific hooks.
Convert the sample code to use the generic power management
From: Bjorn Helgaas
PCI-specific power management (pci_driver.suspend and pci_driver.resume) is
deprecated. The cirrusfb driver has never implemented power management at
all, but if it ever does, it should use the generic power management
framework, not the PCI-specific hooks.
Remove the
From: Bjorn Helgaas
PCI-specific power management (pci_driver.suspend and pci_driver.resume) is
deprecated. If drivers implement power management, they should use the
generic power management framework, not the PCI-specific hooks.
No fbdev drivers actually implement PCI power management, but
On 6/7/2022 16:02, John Harrison wrote:
On 5/16/2022 00:59, Jani Nikula wrote:
On Sat, 14 May 2022, Vinay Belgaumkar wrote:
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing warnings
On 5/16/2022 00:59, Jani Nikula wrote:
On Sat, 14 May 2022, Vinay Belgaumkar wrote:
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing warnings and affecting CI.
This is seen when
Instead of having drivers register the notifier with explicit code just
have them provide a dma_unmap callback op in their driver ops and rely on
the core code to wire it up.
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
This is the last notifier toward the drivers, replace it with a simple op
callback in the vfio_device_ops.
v2:
- Declare and initialize variables in intel_vgpu_dma_unmap()
- Remove 'vendor' when touching comments
- Remove kdoc for vfio dma_unmap notifier
- Add WARN_ON to
Instead of bouncing the function call to the driver op through a blocking
notifier just have the iommu layer call it directly.
Register each device that is being attached to the iommu with the lower
driver which then threads them on a linked list and calls the appropriate
driver op at the right
On 6/7/2022 06:58, Tvrtko Ursulin wrote:
A blast from the past..
On 27/07/2021 01:23, Matthew Brost wrote:
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low
On Tue, Jun 07, 2022 at 08:57:52AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 07, 2022 at 07:39:55AM +0200, Christoph Hellwig wrote:
>
> > > +static int vfio_iommu_notifier(struct notifier_block *nb, unsigned long
> > > action,
> > > +void *data)
> > > +{
> > > + struct
On Sat, 14 May 2022 23:05:06 -0700, Vinay Belgaumkar wrote:
>
> SLPC min/max frequency updates require H2G calls. We are seeing
> timeouts when GuC channel is backed up and it is unable to respond
> in a timely fashion causing warnings and affecting CI.
>
> This is seen when waitboosting happens
On Tue, 07 Jun 2022 15:23:17 -0700, John Harrison wrote:
>
> On 6/7/2022 15:07, Dixit, Ashutosh wrote:
> > On Tue, 07 Jun 2022 14:51:03 -0700, john.c.harri...@intel.com wrote:
> >> From: John Harrison
> >>
> >> Don't use pr_err in places where we have access to a struct_drm.
> > Seem to be many
On 6/7/2022 15:07, Dixit, Ashutosh wrote:
On Tue, 07 Jun 2022 14:51:03 -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Don't use pr_err in places where we have access to a struct_drm.
Seem to be many more pr_err's in selftests. Is there a reason why drm_err's
cannot be used in
On Tue, 07 Jun 2022 14:51:03 -0700, john.c.harri...@intel.com wrote:
>
> From: John Harrison
>
> Don't use pr_err in places where we have access to a struct_drm.
Seem to be many more pr_err's in selftests. Is there a reason why drm_err's
cannot be used in selftests (especially those using an
From: John Harrison
Don't use pr_err in places where we have access to a struct_drm.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 10 ++---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 38 +--
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Lee Jones
Cc: Daniel
On Tue, Jun 07, 2022 at 11:18:11AM -0700, Niranjana Vishwanathapura wrote:
On Tue, Jun 07, 2022 at 12:12:03PM -0500, Jason Ekstrand wrote:
On Fri, Jun 3, 2022 at 6:52 PM Niranjana Vishwanathapura
wrote:
On Fri, Jun 03, 2022 at 10:20:25AM +0300, Lionel Landwerlin wrote:
> On
Commit 680532c50bca ("drm: adv7511: Add support for
i2c_new_secondary_device") allows a device tree node to override
the default addresses of the secondary i2c devices. This is useful
for solving address conflicts on the i2c bus.
In adv7511_init_cec_regmap() the new i2c address of cec device is
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
>
> On 9/27/2021 8:59 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > I've seen a few crashes like:
> >
> > Internal error: synchronous external abort: 9610 [#1] PREEMPT SMP
> > Modules linked in: snd_seq_dummy snd_seq
On Tue, Jun 07, 2022 at 11:42:08AM +0100, Tvrtko Ursulin wrote:
On 03/06/2022 07:53, Niranjana Vishwanathapura wrote:
On Wed, Jun 01, 2022 at 10:08:35PM -0700, Niranjana Vishwanathapura wrote:
On Wed, Jun 01, 2022 at 11:27:17AM +0200, Daniel Vetter wrote:
On Wed, 1 Jun 2022 at 11:03, Dave
On Tue, 7 Jun 2022 20:10:22 +0200, Stephen Kitt wrote:
> backlight_properties.fb_blank is deprecated. The states it represents
> are handled by other properties; but instead of accessing those
> properties directly, drivers should use the helpers provided by
> backlight.h.
Apologies for the
On Tue, 7 Jun 2022 20:31:32 +0200, Stephen Kitt wrote:
> backlight_properties.fb_blank is deprecated. The states it represents
> are handled by other properties; but instead of accessing those
> properties directly, drivers should use the helpers provided by
> backlight.h.
Apologies for the
On Tue, 7 Jun 2022 19:40:40 +0200
Javier Martinez Canillas wrote:
> Hello Alex,
>
> On 6/6/22 19:53, Alex Williamson wrote:
> > Users attempting to enable vfio PCI device assignment with a GPU will
> > often block the default PCI driver from the device to avoid conflicts
> > with the device
On 18.05.2022 13:54, Rob Clark wrote:
> On Tue, May 17, 2022 at 10:42 AM Adrián Larumbe
> wrote:
> >
> > In the event of a job timeout, debug dump information will be written into
> > /sys/class/devcoredump.
> >
> > Inspired by etnaviv's similar feature.
> >
> > Signed-off-by: Adrián Larumbe
> >
On Tue, Jun 7, 2022 at 3:39 PM Lyude Paul wrote:
>
> Right now, radeon is technically the only non-atomic driver still making
> use of the MST helpers - and thus the final user of all of the legacy MST
> helpers. Originally I was going to look into seeing if we could move legacy
> MST into the
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Antonino Daplas
Cc:
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Paul Mackerras
Cc:
On Tue, Jun 07, 2022 at 08:55:16PM +0200, Stephen Kitt wrote:
> backlight_properties.fb_blank is deprecated. The states it represents
> are handled by other properties; but instead of accessing those
> properties directly, drivers should use the helpers provided by
> backlight.h.
>
> Instead of
On Tue, Jun 07, 2022 at 11:27:14AM +0100, Tvrtko Ursulin wrote:
On 17/05/2022 19:32, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Ensure proper kernel-doc formatting with cross references.
Also add new uapi and documentation as per review comments
from
On Tue, Jun 07, 2022 at 02:14:54PM +0300, Jani Nikula wrote:
> On Thu, 02 Jun 2022, Ville Syrjälä wrote:
> > On Tue, May 24, 2022 at 01:39:28PM +0300, Jani Nikula wrote:
> >> Add default action when .get_modes() not set. This also defines what a
> >> .get_modes() hook should do.
> >>
> >> Cc:
This started with work on the removal of backlight_properties'
deprecated fb_blank field, much of which can be taken care of by using
helper functions provided by backlight.h instead of directly accessing
fields in backlight_properties. This patch series doesn't involve
fb_blank, but it still
Hi Marek,
On Wed, May 18, 2022 at 7:35 PM Marek Szyprowski
wrote:
>
> Hi Dave,
>
> On 11.05.2022 17:47, Dave Stevenson wrote:
> > On Wed, 11 May 2022 at 15:58, Marek Szyprowski
> > wrote:
> >> On 05.04.2022 13:43, Dave Stevenson wrote:
> >>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
> >>>
Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on,
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
*
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of
In the past, we've ran into strange issues regarding errors in response to
trying to destroy payloads after a port has been unplugged. We fixed this
back in:
This is intended to replace the workaround that was added here:
commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Instead of setting the power state by manually updating
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file changed, 1 insertion(+), 1
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc:
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
---
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
---
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Benjamin Herrenschmidt
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Helge Deller
Cc:
Ugh, thanks ./scripts/get_maintainers.pl for confusing and breaking
git-send email <<. Sorry for the resend everyone.
For quite a while we've been carrying around a lot of legacy modesetting
code in the MST helpers that has been rather annoying to keep around,
and very often gets in the way of
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Antonino Daplas
Cc:
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Helge Deller
Cc:
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Helge Deller
Cc:
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Lee Jones
Cc: Daniel
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc:
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
---
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
Hi Linus,
On Tue, Jun 7, 2022 at 8:15 PM Linus Torvalds
wrote:
> On Tue, Jun 7, 2022 at 3:23 AM Geert Uytterhoeven
> wrote:
> > These header files are heavy users of large constants lacking the "U"
> > suffix e.g.:
> >
> > #define NB_ADAPTER_ID__SUBSYSTEM_ID_MASK 0xL
>
> As Andreas
From: Pin-Yen Lin
Add the callback function when the driver receives state
changes of the Type-C port. The callback function configures the
crosspoint switch of the anx7625 bridge chip, which can change the
output pins of the signals according to the port state.
Signed-off-by: Pin-Yen Lin
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
---
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few
When the DT node has "switches" available, register a Type-C mode-switch
for each listed "switch". This allows the driver to receive state
information about what operating mode a Type-C port and its connected
peripherals are in, as well as status information (like VDOs) related to
that state.
The
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Lee Jones
Cc: Daniel
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: Stephen Kitt
Cc: Lee Jones
Cc: Daniel
Parse the "switches" node, if available, and count and store the number
of Type-C switches within it. Since we currently don't do anything with
this info, no functional changes are expected from this change.
This patch sets a foundation for the actual registering of Type-C
switches with the
For quite a while we've been carrying around a lot of legacy modesetting
code in the MST helpers that has been rather annoying to keep around,
and very often gets in the way of trying to implement additional
functionality in MST such as fallback link rate retraining, dynamic BPC
management and DSC
Another mistake during the conversion to DSS bitmaps: after retrieving
the DSS ID intel_sseu_find_first_xehp_dss() we forgot to modulo it down
to obtain which ID within the current gslice it is.
Fixes: b87d39019651 ("drm/i915/sseu: Disassociate internal subslice mask
representation from uapi")
backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.
Instead of retrieving the backlight brightness in struct
backlight_properties
Analogix 7625 can be used in systems to switch USB Type-C DisplayPort
alternate mode lane traffic between 2 Type-C ports.
Update the binding to accommodate this usage by introducing a switch
property.
Signed-off-by: Prashant Malani
---
.../display/bridge/analogix,anx7625.yaml | 56
Introduce a binding which represents a component that can control the
routing of USB Type-C data lines as well as address data line
orientation (based on CC lines' orientation).
Signed-off-by: Prashant Malani
---
.../devicetree/bindings/usb/typec-switch.yaml | 76 +++
1 file
There are some drivers that can use the Type C mux API, but don't have
to. Introduce CONFIG guards for the mux functions so that drivers can
include the header file and not run into compilation errors on systems
which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
the Type C
Loosen the typec_mux_match() requirements so that searches where an
alt mode is not specified, but the target mux device lists the
"mode-switch" property, return a success.
This is helpful in Type C port drivers which would like to get a pointer
to the mux switch associated with a Type C port,
backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.
Instead of manually checking the power state in struct
backlight_properties, use
This series introduces a binding for Type-C data lane switches. These
control the routing and operating modes of USB Type-C data lanes based
on the PD messaging from the Type-C port driver regarding connected peripherals.
The first patch introduces a change to the Type-C mux class mode-switch
Since there is no more difference between the HDMI platform data
between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a
single entry.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 27 +++
1 file changed, 3 insertions(+), 24
The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply
regulators that are to be enabled for HPD to work. Currently these
regulators contain the hpd_gdsc, which was replaced by the power-domains
support and hpd-5v/hpd-5v-en, which are not used by the chip itself.
They power up the ESD
From: Marek Vasut
[ Upstream commit c0ff7a649d62105a9308cc3ac36e52a4669d9cb4 ]
The HFP_HSW_HBP_HI register must be programmed with 2 LSbits of each
Horizontal Front Porch/Sync/Back Porch. Currently the driver programs
this register to 0, which breaks displays with either value above 255.
The
Several platform configs use empty 'none' regulator arrays. They are not
necessary, as the code will use corresponding _cnt field and skip the
array completely. Drop them now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 -
1 file changed, 5 deletions(-)
diff
Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Instead of manually checking the power state in struct
DB820c makes use of core-vcc-supply and core-vdda-supply, however the
driver code doesn't support these regulators. Enable them for HDMI on
8996 platform.
Fixes: 0afbe59edd3f ("drm/msm/hdmi: Add basic HDMI support for msm8996")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.
This will ultimately allow fb_blank to be removed.
Stephen Kitt (3):
drm/panel: Use
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm pltforms uses these properties, so it's
safe to drop them.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
From: Marek Vasut
[ Upstream commit 2dcec57b3734029cc1adc5cb872f61e21609eed4 ]
The chip register layout has nothing to do with MIPI DCS, the registers
incorrectly marked as MIPI DCS in the driver are regular chip registers
often with completely different function.
Fill in the actual register
1 - 100 of 222 matches
Mail list logo
