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
>
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
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 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
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: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
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: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
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
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
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
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 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;
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:
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
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
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
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
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 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
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 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
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
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
Hallo Philipp,
On Fri, Dec 16, 2022 at 07:05:13PM +0100, Philipp Zabel wrote:
> On Fr, 2022-12-16 at 18:50 +0100, Uwe Kleine-König wrote:
> > From: Marian Cichy
> >
> > Add support for the LCD Controller found on i.MX21 and i.MX25.
> >
> > It targets to be a drop in replacement for the imx-fb d
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
These blocks on CTL V1 support setting a PINGPONG idx to send pixel
output to.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 23 ++-
1 file changed, 17 insertions
On 12/13/2022 3:22 PM, Marijn Suijten wrote:
All V1 CTL blocks (active CTLs) explicitly bind the pixel output from a
DSC block to a PINGPONG block by setting the PINGPONG idx in a DSC
hardware register.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dis
On 16/12/2022 21:11, Kuogee Hsieh wrote:
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 an
On 16/12/2022 21:11, Kuogee Hsieh wrote:
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:
Krzysztof, there is a bunch of DTS code below. If you can comment on it
(and on my understanding of the existing schemas) that would be great.
On 16/12/2022 04:16, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-12-15 13:12:49)
On 15/12/2022 02:38, Stephen Boyd wrote:
Quoting Kuogee Hsieh
Ast hardware scans out the primary plane from video memory, which
is in I/O-memory space. Hence init the damage handler's iosys_map
pointer as I/O memory.
Not all platforms support accessing I/O memory as system memory,
although it's usually not a problem in ast's x86-based systems.
The error rep
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
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:
--
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:
By default, HBR2 (5.4G) is the max link link 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
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
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
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
On 12/15/2022 6:16 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-12-15 13:12:49)
On 15/12/2022 02:38, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-12-14 14:56:23)
Once link training start, then there are no any interactions between
controller and phy during link training session.
On Fri, Dec 16, 2022 at 1:11 PM Uwe Kleine-König
wrote:
>
> On Mon, Nov 28, 2022 at 07:16:11PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 12.09.22 um 11:15 schrieb Uwe Kleine-König:
> > > While working on a drm driver that doesn't need the i2c algobit stuff I
> > > noticed that DRM selects
On Thu, Dec 15, 2022 at 2:46 PM Christophe JAILLET
wrote:
>
> Le 15/12/2022 à 17:36, Arnd Bergmann a écrit :
> > From: Arnd Bergmann
> >
> > The activity_monitor_external[] array is too big to fit on the
> > kernel stack, resulting in this warning with clang:
> >
> > drivers/gpu/drm/amd/amdgpu/..
Hi Tomi,
Thank you for the patch.
On Fri, Sep 16, 2022 at 11:22:06AM +0300, Tomi Valkeinen wrote:
> Fix doc related warnings seen with W=1: the function names have changed
> but the docs have not been changed accordingly.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
On Mon, Nov 28, 2022 at 07:16:11PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 12.09.22 um 11:15 schrieb Uwe Kleine-König:
> > While working on a drm driver that doesn't need the i2c algobit stuff I
> > noticed that DRM selects this code even tough only 8 drivers actually use
> > it. While also on
On Mi, 2022-07-20 at 23:22 +0800, Liang He wrote:
> In ipu_add_client_devices(), we need to call of_node_put() for
> reference returned by of_graph_get_port_by_id() in fail path.
>
> Fixes: 17e052175039 ("gpu: ipu-v3: Do not bail out on missing optional port
> nodes")
> Signed-off-by: Liang He
On Fr, 2022-12-02 at 16:43 +0100, Lucas Stach wrote:
> Am Dienstag, dem 08.11.2022 um 15:14 +0100 schrieb Philipp Zabel:
> > ipu_src_rect_width() was introduced to support odd screen resolutions
> > such as 1366x768 by internally rounding up primary plane width to a
> > multiple of 8 and compensati
On Fr, 2022-11-25 at 12:25 +0100, Lucas Stach wrote:
> The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
> one of them live in the drivers/gpu/drm/imx toplevel directory and the
> other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
> into its own subdirector
On Fr, 2022-12-16 at 18:50 +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_err ins
Hi Uwe,
On Fr, 2022-12-16 at 18:50 +0100, Uwe Kleine-König wrote:
> From: Marian Cichy
>
> Add support for the LCD Controller found on i.MX21 and i.MX25.
>
> It targets to be a drop in replacement for the imx-fb driver.
>
> Signed-off-by: Marian Cichy
> [ukl: Rebase to v6.1, various smaller f
Modify the existing (fb-like) binding to support the drm-like binding in
parallel.
Signed-off-by: Uwe Kleine-König
---
.../bindings/display/imx/fsl,imx-lcdc.yaml| 46 ++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/i
From: Marian Cichy
Add support for the LCD Controller found on i.MX21 and i.MX25.
It targets to be a drop in replacement for the imx-fb driver.
Signed-off-by: Marian Cichy
[ukl: Rebase to v6.1, various smaller fixes]
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/imx/Kconfig |
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_err instead of DRM_ERROR, inlined
imx_lcdc_check_mode_change, make use of dev_err
On Fri, Dec 16, 2022 at 3:20 AM Jeremi Piotrowski
wrote:
>
> On Tue, Dec 13, 2022 at 04:40:27PM +0530, Rijo Thomas wrote:
> > For AMD Secure Processor (ASP) to map and access TEE ring buffer, the
> > ring buffer address sent by host to ASP must be a real physical
> > address and the pages must be
Change struct fb_ops.release and its implementations to not return
a value. Returing an error is not necessary and callers of the
function ignore it. It is also good practice to make clean-up code
unable ot fail, as such failure cannot be handled.
In several places drivers tested for the correctne
Remove the return type from struct fb_ops.fb_release. It is never
handled, it is never locked at. Originaly done for further updates
under DRM, but the majority of changes is within fbdev drivers.
Also fix trailing whitespaces before modifying hgafb.c.
v2:
* update omapfb2 (kernel test ro
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/hgafb.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
index bd3d07aa4f0e..40879
On 2022-12-16 17:08, Sean Anderson wrote:
On 11/3/22 14:22, Sean Anderson wrote:
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
drm_of_component_match_a
On Fr, 2022-12-16 at 13:03 +0100, Uwe Kleine-König wrote:
> On Fri, Nov 25, 2022 at 12:25:19PM +0100, Lucas Stach wrote:
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index b644deffe948..909622864716 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++ b/drivers/
On Fr, 2022-11-25 at 12:25 +0100, Lucas Stach wrote:
> The IPUv3 and DCSS driver are two totally separate DRM drivers. Having
> one of them live in the drivers/gpu/drm/imx toplevel directory and the
> other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver
> into its own subdirector
On Mi, 2022-07-20 at 23:22 +0800, Liang He wrote:
> In ipu_add_client_devices(), we need to call of_node_put() for
> reference returned by of_graph_get_port_by_id() in fail path.
>
> Fixes: 17e052175039 ("gpu: ipu-v3: Do not bail out on missing optional port
> nodes")
> Signed-off-by: Liang He
On 11/3/22 14:22, Sean Anderson wrote:
> This series adds a new function component_match_add_of to simplify the
> common case of calling component_match_add_release with
> component_release_of and component_compare_of. There is already
> drm_of_component_match_add, which allows for a custom compare
As per the downstream driver, gx gbif halt is required only during
recovery sequence. So lets avoid it during regular rpm suspend.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +++
drivers/gpu/drm/ms
On Fri, 16 Dec 2022, Imre Deak wrote:
> On Fri, Dec 16, 2022 at 06:10:39PM +0200, Jani Nikula wrote:
>> On Fri, 16 Dec 2022, Imre Deak wrote:
>> > On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
>> >> For the whole series:
>> >>
>> >> Reviewed-by: Lyude Paul
>> >
>> > Thanks for the
On Fri, Dec 16, 2022 at 06:10:39PM +0200, Jani Nikula wrote:
> On Fri, 16 Dec 2022, Imre Deak wrote:
> > On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
> >> For the whole series:
> >>
> >> Reviewed-by: Lyude Paul
> >
> > Thanks for the review, pushed it to drm-misc-next.
>
> Hmm, w
On Fri, 16 Dec 2022, Imre Deak wrote:
> On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
>> For the whole series:
>>
>> Reviewed-by: Lyude Paul
>
> Thanks for the review, pushed it to drm-misc-next.
Hmm, with the drm-misc *not* cherry-picking patches from drm-misc-next
to drm-misc-fi
Quoting Akhil P Oommen (2022-12-15 07:10:58)
> Add support for the newly added 'synced_poweroff' genpd flag. This allows
> some clients (like adreno gpu driver) to request gdsc driver to ensure
> a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.
>
> Signed-off-by: Akhil P Oommen
> --
The DEFINE_DEBUGFS_ATTRIBUTE macro has implementation for protecting the
read/write file operations from removal race conditions. This further
enables using debugfs_create_file_unsafe() function since there is no need
for a proxy file operations struct for protection. Hence replace the
DEFINE_SIMPL
It's a bit confusing to have two cached EDIDs in struct intel_connector
with slightly different purposes. Make the distinction a bit clearer by
moving the EDID cached for eDP and LVDS panels at connector init time to
struct intel_panel, and name it fixed_edid. That's what it is, a fixed
EDID for th
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 ---
drivers/gpu/drm/i91
On Thu, 15 Dec 2022 12:52:09 -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for Samsung AMS495QA01 panel (with Magnachip
> D53E6EA8966 controller IC).
>
> Signed-off-by: Chris Morgan
> Signed-off-by: Maya Matuszczyk
> ---
> .../display/panel/samsung,ams495qa01.yaml
Simplify validation and use by converting to drm_edid.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++-
drivers/gpu/drm/i915/display/intel_opregion.c | 29 +++
drivers/gpu/drm/i915/display/intel_opregion.
The original goal with drm_edid_connector_update() was to have a single
call for updating the connector and adding probed modes, in this order,
but that turned out to be problematic. Drivers that need to update the
connector in the .detect() callback would end up updating the probed
modes as well.
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Es
By moving update_display_info() out of _drm_edid_connector_update() we
make the function purely about adding modes. Rename accordingly.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 -
1 file changed, 12 insertions(+), 13
Realize that drm_edid_connector_update() and
_drm_connector_update_edid_property() are now the same thing. Drop the
latter.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
dif
Simplify display info update by merging ELD handling as well as clearing
of the data in update_display_info().
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --
The BPC quirks are closer to home in update_display_info().
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/dr
Rename the local variable to info for consistency.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d3ce559e0dfa..f
Now that quirks are stored in display info, we can just look them up
using the connector instead of having to pass them around.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +++---
1 file changed, 15 insertions(+), 1
Although the quirks are internal to EDID parsing, it'll be helpful to
store them in display info to avoid having to pass them around.
This will also help separate adding probed modes (which needs the
quirks) from updating display info.
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
The drm_edid handling still needed some plumbing in drm_edid.c before we
could convert i915 over to use it. Specifically
drm_edid_connector_update() needed to be split to two, with separate
drm_edid_connector_add_modes(). This is better explained in patch 7
commit message.
With that in patches 1-8
On Fri, Dec 16, 2022 at 3:03 PM Tetsuo Handa
wrote:
>
> On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> > The next line is:
> >
> > scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
> >
> > So how can this turn out to be uninitialized later below?
> >
> > scr_memcpyw
On Fri, Dec 16, 2022, 12:21 Krzysztof Kozlowski <
krzysztof.kozlow...@linaro.org> wrote:
> On 16/12/2022 11:46, Paul Cercueil wrote:
>
> >>> properties:
> >>>compatible:
> >>> -const: ite,it66121
> >>> +enum:
> >>> + - ite,it66121
> >>> + - ite,it6610
>
> These should be ord
On Wed, Dec 14, 2022 at 04:41:42PM -0500, Lyude Paul wrote:
> For the whole series:
>
> Reviewed-by: Lyude Paul
Thanks for the review, pushed it to drm-misc-next.
> Thanks!
>
> On Wed, 2022-12-14 at 20:42 +0200, Imre Deak wrote:
> > If the sink gets disconnected during receiving a multi-packet
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> The next line is:
>
> scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
>
> So how can this turn out to be uninitialized later below?
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>
> What am I miss
Hi Marek,
Am Freitag, 16. Dezember 2022, 13:58:13 CET schrieb Marek Vasut:
> On 12/16/22 13:41, Alexander Stein wrote:
> > Hi,
>
> Hi,
>
> > thanks for the new update.
> >
> > Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
> >> This series supports common bridge support for Sa
On 16/12/2022 13:21, Paul Cercueil wrote:
> Hi Krzysztof,
>
> Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a
> écrit :
>> On 16/12/2022 11:46, Paul Cercueil wrote:
>>
> properties:
> compatible:
> - const: ite,it66121
> + enum:
> + - ite,it6612
Hi Arnd,
On Thu, Dec 15, 2022 at 6:05 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The dsi_irq_stats structure is a little too big to fit on the
> stack of a 32-bit task, depending on the specific gcc options:
>
> fbdev/omap2/omapfb/dss/dsi.c: In function 'dsi_dump_dsidev_irqs':
> fbdev/oma
On 11/28/22 19:16, Thomas Zimmermann wrote:
> Hi
>
> Am 12.09.22 um 11:15 schrieb Uwe Kleine-König:
>> While working on a drm driver that doesn't need the i2c algobit stuff I
>> noticed that DRM selects this code even tough only 8 drivers actually use
>> it. While also only some drivers use i2c, k
Am Freitag, dem 16.12.2022 um 13:03 +0100 schrieb Uwe Kleine-König:
> On Fri, Nov 25, 2022 at 12:25:19PM +0100, Lucas Stach wrote:
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index b644deffe948..909622864716 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++
On 12/16/22 13:41, Alexander Stein wrote:
Hi,
Hi,
thanks for the new update.
Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
The final bridge supports both the Exyno
Hi
Am 16.12.22 um 04:05 schrieb Ma Jun:
Add the missing declaration of struct drm_atomic_state to fix the
compile error below:
error: 'struct drm_atomic_state' declared inside parameter
list will not be visible outside of this definition or declaration [-Werror]
Signed-off-by: Ma Jun
Thanks
Hi,
thanks for the new update.
Am Mittwoch, 14. Dezember 2022, 13:58:49 CET schrieb Jagan Teki:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus.
>
> Patch 0001
Applied patches 2,3,4,5
The rest will go through the DRM driver tree.
Thanks!
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
This patch is to add first version mt8188 vdosys0 driver
Modify and add new files include:
1. bindings documents
2. mtk mmsys
3. mtk mutex
4. mtk drm driver
Cha
On Thu, Dec 15, 2022, at 18:56, Michel Dänzer wrote:
> On 12/15/22 17:37, Arnd Bergmann wrote:
/amd/display/dc/core/dc_link_dp.c
>> index af9411ee3c74..95dbfa4e996a 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> @@ -5095
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
add driver data of mt8188 vdosys0 to mediatek-drm and the sub driver.
Signed-off-by: amy zhang
Signed-off-by: Nathan Lu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_drm
On 06/12/2022 03:00, nathan.lu wrote:
From: Nathan Lu
modify VDOSYS0 display device tree Documentations for MT8188.
Signed-off-by: Nathan Lu
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
.../devicetree/bindings/display/
Den 16.12.2022 12.54, skrev Fabio Estevam:
> Hi,
>
> Does anyone know if the Crystalfontz CFAF240320X0-020T display is
> supported in Linux?
>
> https://www.crystalfontz.com/product/cfaf240320x0020t-2inch-240x320-color-tft
>
> It uses a Sitronix ST7789V controller.
>
> For the ST7789V, there
Hi Krzysztof,
Le vendredi 16 décembre 2022 à 12:21 +0100, Krzysztof Kozlowski a
écrit :
> On 16/12/2022 11:46, Paul Cercueil wrote:
>
> > > > properties:
> > > > compatible:
> > > > - const: ite,it66121
> > > > + enum:
> > > > + - ite,it66121
> > > > + - ite,it6610
>
> These
1 - 100 of 127 matches
Mail list logo
