With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/Kconfig| 8
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
3
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs
needed for the HDMI port. Add the binding for these supplies.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
- Add Robs Ack
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
This patch adds "ref" as a new alternative clock name for "vpll"
Signed-off-by: Sascha Hauer
Acked-by: Rob
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
- Add Robs Ack
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
- Add Robs Ack
Changes since v3:
The VOP2 driver needs rockchip specific information for a drm_encoder.
This patch creates a struct rockchip_encoder with a struct drm_encoder
embedded in it. This is used throughout the rockchip driver instead of
struct drm_encoder directly.
The information the VOP2 drivers needs is the of_graph
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Signed-off-by: Michael Riesch
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Drop reg property from single endpoint node
Changes since v4:
- Sort nodes
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
Acked-by: Rob Herring
---
Notes:
Changes since v4:
-
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Signed-off-by: Sascha Hauer
Reviewed-by: Rob Herring
---
Notes:
Changes since v5:
- Add Robs Reviewed-by:
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
Current port description doesn't cover all possible cases. It currently
expects one single port with two endpoints.
When the HDMI connector is described in the device tree there can be two
ports, first one going to the VOP and the second one going to the connector.
Also on SoCs which only have a
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Signed-off-by: Sascha Hauer
---
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Use
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Drop reg property from single endpoint node
Changes since v4:
From: Douglas Anderson
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v5:
- Drop unnecessary #size-cells/#address-cells from nodes with only single
endpoint
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 32
1 file changed, 32
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a frequency range up to which the entry works, not as a frequency that
must match the pixel clock. The downstream Kernel also does not have
this check,
The VOP2 has an interface mux which decides to which encoder(s) a CRTC
is routed to. The encoders and CRTCs are connected via of_graphs in the
device tree. When given an encoder the VOP2 driver needs to know to
which internal register setting this encoder matches. For this the VOP2
binding offers
Here is v7 of adding RK356x VOP2 support. The one big notable change this
time is that I moved the of_graph parsing from runtime code into
initialization, see patch 2/24. Other than that there are some smaller
changes due to the review feedback to v6.
Sascha
Changes since v6:
- Move of_graph
From: Douglas Anderson
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient
The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1
From: Nickey Yang
add 594Mhz configuration parameters in rockchip_phy_config
Signed-off-by: Nickey Yang
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v3:
- new patch
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Useful for checking for dma-fence signalling annotations since they
don't quite nest as freely as we'd like to.
Cc: Matthew Brost
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
John Harrison writes:
> On 2/22/2022 02:36, Jordan Justen wrote:
>> From: John Harrison
>>
>> Implement support for fetching the hardware description table from the
>> GuC. The call is made twice - once without a destination buffer to
>> query the size and then a second time to fill in the
On 2/24/2022 8:22 PM, Dmitry Baryshkov wrote:
On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar wrote:
On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote:
On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar wrote:
On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote:
On 19/02/2022 02:56, Stephen Boyd wrote:
On Fri, 25 Feb 2022 at 05:01, Abhinav Kumar wrote:
>
>
>
> On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote:
> > On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote:
> >>> On 19/02/2022 02:56, Stephen Boyd wrote:
> Quoting
Hi,
I'm sending these again, as they still need fixing. They have been
rebased due to the drm_dp_helper code being moved into a subdirectory.
Can someone please apply these? :)
Thanks!
-Kees
v1: https://patchwork.freedesktop.org/patch/465200/
The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside
array
The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:
drivers/gpu/drm/drm_dp_helper.c: In function
'drm_dp_get_adjust_request_post_cursor':
Hi Martin,
22. 2. 25. 08:27에 Martin Jücker 이(가) 쓴 글:
> Hello Inki,
>
> On Thu, Feb 24, 2022 at 10:41:04AM +0900, Inki Dae wrote:
>> Hi Martin.
>>
>> I found that exynos4 and 5 data sheet include documented same register.
>> RGB_ORDER_E field of VIDCONx registers will do same thing.
>
> If I
When support for MT8192 was added, the DPI device was not added to the
list of components to look for. This causes the secondary display
pipeline to not be able to fully bind, and the DRM driver subsequently
defers probing.
Add the DPI device compatible to list of DPI components to fix this.
Replace all occurrence of cache_clflush_range with drm_clflush_virt_range.
This will prevent compile errors on non-x86 platforms.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
v2(Michael Cheng): Use sizeof(*addr) instead of sizeof(addr) to get the
actual size of the page. Thanks to Matt Roper for
pointing
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added
more patches to convert
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache. Thanks Tvrtko for the suggestion.
v3
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9
Hi Andrey,
Sorry for the misleading, I mean the whole patch series. We are depending on
this patch series to fix the concurrency issue within SRIOV TDR sequence.
On 2/25/22 1:26 AM, Andrey Grodzovsky wrote:
> No problem if so but before I do,
>
>
> JingWen - why you think this patch is needed
Hi Philipp,
On Fri, 2022-01-28 at 17:19 +0800, Liu Ying wrote:
> In dw_hdmi_imx_probe(), if error happens after dw_hdmi_probe() returns
> successfully, dw_hdmi_remove() should be called where necessary as
> bailout.
>
> Fixes: c805ec7eb210 ("drm/imx: dw_hdmi-imx: move initialization into probe")
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
The table is stored in the GT structure so that it can be fetched once
at
On 2/22/2022 02:36, Jordan Justen wrote:
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only
On 2/24/2022 12:41 PM, Dmitry Baryshkov wrote:
On Thu, 24 Feb 2022 at 21:25, Abhinav Kumar wrote:
On 2/18/2022 6:26 PM, Dmitry Baryshkov wrote:
On 19/02/2022 02:56, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-11 14:40:02)
In commit 8a3b4c17f863 ("drm/msm/dp: employ bridge
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets are happening even if they are being ignored).
v2: Better
Hi Dave and Daniel,
Just fixups series.
Ps. my previous git-pull request[1] isn't merged so I'm sending it again
after rebasing on top of drm-fixes.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
[1] https://www.spinics.net/lists/dri-devel/msg333237.html
The pull request you sent on Fri, 25 Feb 2022 09:01:30 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-25
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5ee3d0015a4cec798b44ceefc34245752104fc08
Thank you!
--
Deet-doot-dot, I am a bot.
VRR capable property is not attached by default to the connector
It is attached only if VRR is supported.
So if the driver tries to call drm core set prop function without
it being attached that causes NULL dereference.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with more
> > meaning.
> >
> >
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a
Hi Pekka,
On Thu, Feb 10, 2022 at 6:50 AM Pekka Paalanen wrote:
> On Fri, 21 Jan 2022 18:38:31 -0300
> Igor Torrente wrote:
>
> > Adds this common format to vkms.
> >
> > This commit also adds new helper macros to deal with fixed-point
> > arithmetic.
> >
> > It was done to improve the
On Wed, 23 Feb 2022 at 22:11, Rob Clark wrote:
>
> From: Rob Clark
>
> Someone on IRC once asked an innocent enough sounding question: Why
> with xf86-video-modesetting is es2gears limited at 120fps.
>
> So I broke out the perfetto tracing mesa MR and took a look. It turns
> out the problem
Hi Pekka,
On 2/10/22 06:37, Pekka Paalanen wrote:
> On Fri, 21 Jan 2022 18:38:29 -0300
> Igor Torrente wrote:
>
>> Currently the blend function only accepts XRGB_ and ARGB_
>> as a color input.
>>
>> This patch refactors all the functions related to the plane composition
>> to overcome
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).
Also, rename the set/clear/query helper functions for context id
mappings to better reflect
From: John Harrison
The LRC descriptor was being initialised early on in the context
registration sequence. It could then be determined that the actual
registration needs to be delayed and the descriptor would be wiped
out. This is inefficient, so move the setup to later in the process
after the
From: John Harrison
Some G2H handlers were reading the context id field from the payload
before checking the payload met the minimum length required.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check
for whether submission has been initialised or not.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as the limit
for how many context ids are available. Instead, size the pool
according to the number of contexts allowed. Note that this is just a
naming change, the actual limit is identical in value.
While at it, also
From: John Harrison
The CTB registration process changed significantly a while back using
a single KLV based H2G. So drop the original and now obsolete H2G
definitions.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2
From: John Harrison
The LRC descriptor pool is going away. So, stop naming context ids as
descriptor pool indecies.
While at it, add a bunch of missing line feeds to some error messages.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
From: John Harrison
The LRC descriptor pool is going away. Further, the function that was
populating it was also doing a bunch of logic about the context
registration sequence. So, split that code apart into separate state
setup and try to register functions. Note that some of those 'try to
From: John Harrison
The next GuC firmware release includes some significant backwards
breaking API changes. One such is that there is no longer an LRC
descriptor pool. A bunch of prep work for that change can be done in
advance - the descriptor pool was being used for things it shouldn't
really
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #66 from Randune (randyk...@gmail.com) ---
So I've been running for about 2.5 weeks now using the amdgpu.runpm=0 kernel
parameter and I've had no crashes or freezes so far. I'm cautiously optimistic
that for me at least this may have
Hey,
Regular drm fixes pull, i915, amdgpu and tegra mostly, all pretty small.
I'm in quarantine at home for next 7 days, shouldn't interrupt things,
but might be erratic if anyone is looking for me.
Dave.
drm-fixes-2022-02-25:
drm fixes for 5.17-rc6
core:
- edid: Always set RGB444
tegra:
-
Quoting Daniel Latypov (2022-02-23 14:50:59)
> On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripard wrote:
> >
> > Let's test various parts of the rate-related clock API with the kunit
> > testing framework.
> >
> > Cc: kunit-...@googlegroups.com
> > Suggested-by: Stephen Boyd
> > Signed-off-by: Maxime
Quoting Maxime Ripard (2022-02-23 02:55:53)
> The code in clk_set_rate_range() will, if the current rate is outside of
> the new range, will force it to the minimum or maximum.
s/will//
>
> Since it's running under the condition that the rate is either lower
> than the minimum, or higher than
This series updates a few maintainer entries for VMware-maintained
subsystems and cleans up references to VMware's private mailing lists
to make it clear that they are effectively email-aliases to reach out
to reviewers.
Changes from v4->v5:
- Add Alexey as reviewer for paravirt ops.
Changes
From: Srivatsa S. Bhat (VMware)
VMware mailing lists in the MAINTAINERS file are private lists meant
for VMware-internal review/notification for patches to the respective
subsystems. Anyone can post to these addresses, but there is no public
read access like open mailing lists, which makes them
From: Bjorn Helgaas
In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we
previously printed them with "%d", the signed decimal format. Print them
with the unsigned format "%u" instead.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 2 +-
1 file changed, 1
From: Bjorn Helgaas
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c
From: Huacai Chen
Move vga_arb_integrated_gpu() earlier in file to prepare for future patch.
No functional change intended.
[bhelgaas: pull #ifdefs inside function]
Link: https://lore.kernel.org/r/20211015061512.2941859-3-chenhua...@loongson.cn
Signed-off-by: Huacai Chen
---
From: Huacai Chen
Previously vga_arb_device_init() iterated through all VGA devices and
indicated whether legacy VGA routing to each could be controlled by an
upstream bridge.
But we determine that information in vga_arbiter_add_pci_device(), which we
call for every device, so we can log it
From: Bjorn Helgaas
vga_arb_device_card_gone() has always been empty. Remove it.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index
From: Huacai Chen
a37c0f48950b ("vgaarb: Select a default VGA device even if there's no
legacy VGA") extended the vga_arb_device_init() subsys_initcall so that if
there are no other eligible devices, it could select a disabled VGA device
as the default.
Move this detection from
From: Huacai Chen
Default VGA device selection fails when PCI devices are enumerated after
the vga_arb_device_init() subsys_initcall.
vga_arbiter_add_pci_device() selects the first fully enabled device to
which legacy VGA resources are routed as the default VGA device. This is
an ADD_DEVICE
From: Huacai Chen
Previously we selected the firmware default device, i.e., one that owns the
boot framebuffer, as the default device in vga_arb_select_default_device().
This was only done in the vga_arb_device_init() subsys_initcall, so devices
enumerated later, e.g., by pcibios_init(), were
From: Huacai Chen
a37c0f48950b ("vgaarb: Select a default VGA device even if there's no
legacy VGA") extended the vga_arb_device_init() subsys_initcall so it could
select a non-legacy VGA device as the default.
That failed to consider that PCI devices may be enumerated after
From: Bjorn Helgaas
On x86 and ia64, if a VGA device BARs include a framebuffer reported by
platform firmware, we select the device as the default VGA device. Factor
this code to a separate function. No functional change intended.
Signed-off-by: Bjorn Helgaas
Cc: Bruno Prémont
---
From: Bjorn Helgaas
The VGA arbiter is really PCI-specific and doesn't depend on any GPU
things. Move it to the PCI subsystem.
Note that misc_init() must be called before vga_arb_device_init(). These
are both subsys_initcalls, so this ordering depends on the link order,
which is determined by
From: Bjorn Helgaas
Current default VGA device selection fails in some cases because part of it
is done in the vga_arb_device_init() subsys_initcall, and some arches
enumerate PCI devices in pcibios_init(), which runs *after* that.
The big change from the v8 posting is that this moves vgaarb.c
Quoting Maxime Ripard (2022-02-21 08:30:01)
> On Fri, Feb 18, 2022 at 02:34:20PM -0800, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2022-01-25 06:15:42)
> > > The code in clk_set_rate_range() will, if the current rate is outside of
> > > the new range, will force it to the minimum or maximum.
Currently the call to function amdgpu_benchmark_move should be
assigning the return value to variable r as this is checked in
the next statement, however, this assignment is missing. Fix
this by adding in the missing assignment.
Addresses clang scan warning:
On Thu, 24 Feb 2022 20:58:07 +0100, Marek Vasut wrote:
> It is necessary to specify the number of connected/used DSI data lanes when
> using the DSI input port of this bridge. Document the 'data-lanes' property
> of the DSI input port.
>
> Signed-off-by: Marek Vasut
> Cc: Jonas Karlman
> Cc:
On Thu, 24 Feb 2022 20:58:06 +0100, Marek Vasut wrote:
> The TC358767/TC358867/TC9595 are all capable of operating in multiple
> modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the
> DPI output port, which can now be connected both as input and output.
>
> Signed-off-by: Marek
Quoting Maxime Ripard (2022-02-21 08:43:23)
> Hi again,
>
> On Mon, Feb 21, 2022 at 05:18:21PM +0100, Maxime Ripard wrote:
> > On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> > > Quoting Maxime Ripard (2022-01-25 06:15:41)
> > > > +/*
> > > > + * Test that if our clock has some
Quoting Maxime Ripard (2022-02-21 08:18:21)
> Hi,
>
> On Fri, Feb 18, 2022 at 03:15:06PM -0800, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2022-01-25 06:15:41)
> > > The current core while setting the min and max rate properly in the
> > > clk_request structure will not make sure that the
Quoting Maxime Ripard (2022-02-21 07:12:59)
> Hi Stephen,
>
> Thanks for your review
>
> On Fri, Feb 18, 2022 at 06:20:46PM -0800, Stephen Boyd wrote:
> > It would also be good to add a test that tries to set the clk rate with
> > clk_set_rate() after a range has been set that is outside the
From: Rob Clark
Add a way for userspace to specify the sequence number fence used to
track completion of the submit. As the seqno fence is simply an
incrementing counter which is local to the submitqueue, it is easy for
userspace to know the next value.
This is useful for native userspace
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
1 file changed, 2
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Reviewed-by: Macpaul Lin
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
As all drivers now look at the removable attribute, drop this function.
Signed-off-by: Mario Limonciello
---
include/linux/pci.h | 22 --
1 file changed, 22 deletions(-)
diff
Currently `pci_is_thunderbolt_attached` is used to indicate a device
is connected externally.
The PCI core now marks such devices as removable and downstream drivers
can use this instead.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
The `is_thunderbolt` check is currently used to indicate the lack of
command completed support for a number of older Thunderbolt devices.
This however is heavy handed and should have been done via a quirk. Move
the affected devices outlined in commit 493fb50e958c ("PCI: pciehp: Assume
NoCompl+
The `is_thunderbolt` attribute originally had a well defined list of
quirks that it existed for, but it has been overloaded with more
meaning.
Instead use the driver core removable attribute to indicate the
detail a device is attached to a thunderbolt or USB4 chain.
Signed-off-by: Mario
`pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
controller to indicate that D3 is possible.
This is used solely for older Apple systems, due to a variety of factors:
* Apple used SW connection manager from the beginning, other manufacturers
used a FW connection manager
Various drivers in the kernel use `is_thunderbolt` or
`pci_is_thunderbolt_attached` to designate behaving differently
from a device that is internally in the machine. This currently works
by an attribute in PCI core "is_thunderbolt" which makes those drivers
only apply differences when Intel
On 2/23/2022 18:03, Ceraolo Spurio, Daniele wrote:
On 2/23/2022 12:23 PM, John Harrison wrote:
On 2/22/2022 17:12, Ceraolo Spurio, Daniele wrote:
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor was being initialised early on in the context
On 2/24/2022 12:49 PM, Dmitry Baryshkov wrote:
On Thu, 24 Feb 2022 at 23:13, Abhinav Kumar wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
It is possible to supply display-connector (bridge) to the DP interface,
add support for parsing it too.
Signed-off-by: Dmitry Baryshkov
---
1 - 100 of 198 matches
Mail list logo
