On 12/12/2022 17:52, Umesh Nerlige Ramappa wrote:
On Tue, Nov 29, 2022 at 01:12:52PM -0800, john.c.harri...@intel.com
wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context not
The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
core with a little bit of SoC integration around it.
Signed-off-by: Lucas Stach
---
.../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/de
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
---
.../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
di
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals
Add a simple wrapper driver for the DWC HDMI bridge driver that
implements the few bits that are necessary to abstract the i.MX8MP
SoC integration.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Tested-by: Marek Vasut
---
drivers/gpu/drm/bridge/imx/Kconfig | 9 ++
drivers/gpu
Add DP both data-lanes and link-frequencies property to dp_out endpoint and
support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parse dat
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
-- separate parser link-frequencies out of data-lanes
Changes in v10:
-- add dp_parser_link_frequencies()
Changes in v
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add &dp_out
By default, HBR2 (5.4G) is the max link rate be supported. This patch
uses the actual limit specified by DT and removes the artificial
limitation to 5.4 Gbps. Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp
To increase the flexibility of supporting different DP main link configuration
at different platform, add both data-lanes and link-frequencies property
into endpoint so that different platform can specify its own main link
combination of both data lanes and max supported link rate.
Changes in v7:
On 12/14/2022 5:08 PM, Dmitry Baryshkov wrote:
On 14/12/2022 21:30, Marijn Suijten wrote:
On 2022-12-14 20:43:29, Dmitry Baryshkov wrote:
On 14/12/2022 01:22, Marijn Suijten wrote:
Active CTLs have to configure what DSC block(s) have to be enabled, and
what DSC block(s) have to be flushed;
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
According to downstream the value to use for WORD_COUNT is
bytes_per_pkt, which denotes the number of bytes in a packet based on
how many slices have been configured by the panel driver times the
width of a slice times the number of bytes per pixel.
On Thu, Dec 15, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The check_reserve_boundaries function uses a lot of kernel stack,
> and it gets inlined by clang, which makes __drm_test_mm_reserve
> use even more of it, to the point of hitting the warning limit:
>
> drive
From: Rob Clark
Relying on an unreturned handle to hold a reference to an object we
dereference is not safe. Userspace can guess the handle and race us
by closing the handle from another thread. The _create_with_handle()
that returns an object ptr is pretty much a pattern to avoid. And
ideally
From: Rob Clark
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done derefere
On Fri, Dec 16, 2022 at 3:33 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Userspace can guess the handle value and try to race GEM object creation
> with handle close, resulting in a use-after-free if we dereference the
> object after dropping the handle's reference. For that reason, dropping
> t
On Fri, Dec 16, 2022 at 06:50:04PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> Changes since v2:
>
> - added allOf as Krzysztof requested
> - reworked driver based on Philipp's comments
>(improved error handling, different selects, moved driver to a
> subdirectory,
>header sorting, drm
On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Relying on an unreturned handle to hold a reference to an object we
> dereference is not safe. Userspace can guess the handle and race us
> by closing the handle from another thread. The _create_with_handle()
> that return
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventu
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventu
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventu
From: "Guilherme G. Piccoli"
[ Upstream commit 1d044ca035dc22df0d3b39e56f2881071d9118bd ]
The Hyper-V framebuffer code registers a panic notifier in order
to try updating its fbdev if the kernel crashed. The notifier
callback is straightforward, but it calls the vmbus_sendpacket()
routine eventu
On Fri, Dec 16, 2022 at 3:59 PM Chia-I Wu wrote:
>
> On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Relying on an unreturned handle to hold a reference to an object we
> > dereference is not safe. Userspace can guess the handle and race us
> > by closing the ha
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
According to downstream /and the comment copied from it/ this comparison
should be the other way around. In other words, when the panel driver
requests to use more slices per packet than what could be sent over this
interface, it is bumped down to
On Fri, Dec 16, 2022 at 4:20 PM Rob Clark wrote:
>
> On Fri, Dec 16, 2022 at 3:59 PM Chia-I Wu wrote:
> >
> > On Fri, Dec 16, 2022 at 3:34 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > Relying on an unreturned handle to hold a reference to an object we
> > > dereference is not saf
Hi Lucas,
On Fri, 2022-12-16 at 22:07 +0100, Lucas Stach wrote:
> The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> core with a little bit of SoC integration around it.
>
> Signed-off-by: Lucas Stach
> ---
> .../bindings/display/imx/fsl,imx8mp-hdmi.yaml | 69
>
101 - 127 of 127 matches
Mail list logo
