Hi Yunfei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on v5.18-rc1 next-20220408]
[cannot apply to remoteproc/rproc-next drm-tip/drm-tip]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Mon, Apr 04, 2022 at 12:52:14PM -0500, Rob Herring wrote:
> On Mon, Mar 28, 2022 at 08:09:54PM +0800, Xin Ji wrote:
> > Change bus-type define for DPI.
> >
> > Fixes: a43661e7e819 ("dt-bindings:drm/bridge:anx7625:add vendor define")
> >
> > Signed-off-by: Xin Ji
> > ---
> >
Hi--
On 4/8/22 21:23, James Hilliard wrote:
> Select the efi framebuffer if efi is enabled.
>
> This appears to be needed for video output to function correctly.
>
> Signed-off-by: James Hilliard
Acked-by: Randy Dunlap
> ---
> Changes v2 -> v3:
> - select EFI_FB instead of depending on it
Select the efi framebuffer if efi is enabled.
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
Changes v2 -> v3:
- select EFI_FB instead of depending on it
Changes v1 -> v2:
- use depends instead of select
---
On 4/8/22 20:44, James Hilliard wrote:
> This appears to be needed for video output to function correctly.
>
> Signed-off-by: James Hilliard
> ---
> Changes v1 -> v2:
> - use depends instead of select
Thanks.
> ---
> drivers/gpu/drm/gma500/Kconfig | 2 ++
> 1 file changed, 2
On 4/7/2022 4:12 PM, Rob Clark wrote:
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar wrote:
Hi Rob and Daniel
On 4/7/2022 3:51 PM, Rob Clark wrote:
On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang wrote:
On 3/31/2022 8:20 AM, Daniel Vetter wrote:
The stuff never really worked, and leads
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
Changes v1 -> v2:
- use depends instead of select
---
drivers/gpu/drm/gma500/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/Kconfig
Hi,
On 4/8/22 19:59, James Hilliard wrote:
> This appears to be needed for video output to function correctly.
More proof/justification?
> Signed-off-by: James Hilliard
> ---
> drivers/gpu/drm/gma500/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Thu 07 Apr 04:34 CDT 2022, Paul Kocialkowski wrote:
> With the previous rework of drm_of_find_panel_or_bridge only
> -EPROBE_DEFER is returned while previous behavior allowed -ENODEV
> to be returned when the port/endpoint is either missing or unavailable.
>
> Make the default return code of
ARM64 always has CONFIG_MMU=y but adding a dependency on
COMPILE_TEST allows an arch with MMU optional (riscv in this case)
to build the hibmc driver, leading to a kconfig warning and
build errors, so restore the MMU dependency.
WARNING: unmet direct dependencies detected for DRM_TTM
Depends on
This appears to be needed for video output to function correctly.
Signed-off-by: James Hilliard
---
drivers/gpu/drm/gma500/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..ff8c7b6e87f5 100644
---
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will let us take away the
waiting in the AUX transfer functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
---
.../gpu/drm/panel/panel-samsung-atna33xc20.c | 35
This implements the callback added by the patch ("drm/dp: Add
is_hpd_asserted() callback to struct drm_dp_aux").
With this change and all the two "DP AUX Endpoint" drivers changed to
use is_hpd_asserted(), we no longer need to have an long delay in the
AUX transfer function. It's up to the panel
Sometimes it's useful for users of the DP AUX bus (like panels) to be
able to poll HPD. Let's add a callback that allows DP AUX busses
drivers to provide this.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Douglas Anderson
---
include/drm/dp/drm_dp_helper.h | 14 ++
1 file
Let's add support for being able to read the HPD pin even if it's
hooked directly to the controller. This will allow us to get more
accurate delays also lets us take away the waiting in the AUX transfer
functions of the eDP controller drivers.
Signed-off-by: Douglas Anderson
---
While it works, for the most part, to assume that the panel has
finished probing when devm_of_dp_aux_populate_ep_devices() returns,
it's a bit fragile. This is talked about at length in commit
a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to
its own sub-dev").
When reviewing
As talked about in the kerneldoc for "struct dp_aux_ep_client" in this
patch and also in the past in commit a1e3667a9835 ("drm/bridge:
ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), to use the
DP AUX bus properly we really need two "struct device"s. One "struct
device" is in charge of
This patch addresses pre-existing issues that came up during the
review process of Sankeerth's series trying to add eDP for Qualcomm
SoCs [1].
It's really sorta two series but jammed into one. The first two
patches fix a problem with ps8640 when the panel doesn't finish
probing right away. The
On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> For some vendor driver implementations, display hardware can
> be shared between the encoder used for writeback and the physical
> display.
>
> In addition resources such as clocks and interrupts can
> also be shared between writeback and the
On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> For vendors drivers which pass an already allocated and
> initialized encoder especially for cases where the encoder
> hardware is shared OR the writeback encoder shares the resources
> with the rest of the display pipeline introduce a new
On Sat, 9 Apr 2022 at 03:54, Abhinav Kumar wrote:
>
> Clients of drm_writeback_connector_init() initialize the
> possible_crtcs and then invoke the call to this API.
>
> To simplify things, allow passing possible_crtcs as a parameter
> to drm_writeback_connector_init() and make changes to the
>
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware,
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Make vc4 driver use the new API so that the embedded encoder model
can be retained in the driver and there is no change in
functionality.
changes in v7:
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
On Fri, Apr 8, 2022 at 9:22 AM Jagan Teki wrote:
>
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> Previous RFC can be available here [1].
>
> The final bridge supports both the Exynos and i.MX8MM DSI devices.
>
> On, summary
Dear Richard,
Thank you for your patch.
Am 08.04.22 um 21:05 schrieb Richard Gong:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using
On Sat, 9 Apr 2022 at 00:05, Bjorn Andersson wrote:
>
> Add an optional reference to the MDSS_CORE reset, which when specified
> can be used by the implementation to reset the hardware blocks.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Dmitry Baryshkov
> ---
>
> Resending these two
On Sat, 9 Apr 2022 at 00:05, Bjorn Andersson wrote:
>
> It's typical for the bootloader to bring up the display for showing a
> boot splash or efi framebuffer. But in some cases the kernel driver ends
> up only partially configuring (in particular) the DPU, which might
> result in e.g. that two
On Sat, 9 Apr 2022 at 00:05, Kuogee Hsieh wrote:
>
> There is possible circular locking dependency detected on event_mutex
> (see below logs). This is due to set fail safe mode is done at
> dp_panel_read_sink_caps() within event_mutex scope. To break this
> possible circular locking, this patch
On Sat, 9 Apr 2022 at 00:12, Chia-I Wu wrote:
>
> In practice, trace_dma_fence_init is good enough and almost no driver
> calls trace_dma_fence_emit. But this is still more correct in theory.
Please mention in the commit message that the trace_dma_fence_init()
is called from dma_fence_init().
On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh wrote:
>
>
> On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
> > On 07/04/2022 00:28, Kuogee Hsieh wrote:
> >> dp_hpd_plug_handle() is responsible for setting up main link and send
> >> uevent to notify user space framework to start video stream. Similarly,
On Sat, Apr 09, 2022 at 01:47:21AM +0300, Almahallawy, Khaled wrote:
> On Fri, 2022-04-08 at 20:21 +0300, Imre Deak wrote:
> > Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
> > with a 1-byte read access. This will be needed by the next patch
> > doing a
> > read from an
On Fri, 2022-04-08 at 20:21 +0300, Imre Deak wrote:
> Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
> with a 1-byte read access. This will be needed by the next patch
> doing a
> read from an LTTPR address, which must happen without the preceding
> wake-up read in
In practice, trace_dma_fence_init is good enough and almost no driver
calls trace_dma_fence_emit. But this is still more correct in theory.
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
It's typical for the bootloader to bring up the display for showing a
boot splash or efi framebuffer. But in some cases the kernel driver ends
up only partially configuring (in particular) the DPU, which might
result in e.g. that two different data paths attempts to push data to
the interface -
Add an optional reference to the MDSS_CORE reset, which when specified
can be used by the implementation to reset the hardware blocks.
Signed-off-by: Bjorn Andersson
---
Resending these two patches again as I put "v2" in the subject, even though I
meant v3. Sorry about that.
Changes since v2:
There is possible circular locking dependency detected on event_mutex
(see below logs). This is due to set fail safe mode is done at
dp_panel_read_sink_caps() within event_mutex scope. To break this
possible circular locking, this patch move setting fail safe mode
out of event_mutex scope.
[
It's typical for the bootloader to bring up the display for showing a
boot splash or efi framebuffer. But in some cases the kernel driver ends
up only partially configuring (in particular) the DPU, which might
result in e.g. that two different data paths attempts to push data to
the interface -
Add an optional reference to the MDSS_CORE reset, which when specified
can be used by the implementation to reset the hardware blocks.
Signed-off-by: Bjorn Andersson
---
Changes since v2:
- None
.../devicetree/bindings/display/msm/dpu-qcm2290.yaml | 4
On 4/8/22 22:52, Rob Herring wrote:
On Thu, 07 Apr 2022 20:56:16 +0200, 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
On Thu, 07 Apr 2022 20:56:16 +0200, 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: Jagan Teki
> Cc:
Applied. Thanks!
On Fri, Apr 8, 2022 at 3:58 AM Grigory Vasilyev wrote:
>
> Instead of the 'amdgpu_ring_priority_level' type,
> the 'amdgpu_gfx_pipe_priority' type was used,
> which is an error when setting ring priority.
> This is a minor error, but may cause problems in the future.
>
>
On Thu, Apr 7, 2022 at 5:47 PM Tom Rix wrote:
>
> cayman_default_state and cayman_default_size are only
> used in ni.c. Single file symbols should be static.
> So move their definitions to cayman_blit_shaders.h
> and change their storage-class-specifier to static.
>
> Remove unneeded
Otherwise, ring names are marked [UNSAFE-MEMORY].
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
drivers/gpu/drm/scheduler/gpu_scheduler_trace.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
drm_sched_job and drm_run_job have the same prototype.
Signed-off-by: Chia-I Wu
Cc: Rob Clark
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 31 +--
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
Den 08.04.2022 19.55, skrev Marek Vasut:
> On 4/8/22 16:50, Noralf Trønnes wrote:
>> Hi Marek,
>
> Hi,
>
>> I see that you have commit rights so I assume you will be applying this
>> patch.
>
> It's already in drm-misc-fixes:
>
>
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:
dp_hpd_plug_handle() is responsible for setting up main link and send
uevent to notify user space framework to start video stream. Similarly,
dp_hdp_unplug_handle is responsible to send uevent to notify user
On 4/8/22 21:19, Javier Martinez Canillas wrote:
[snip]
>>
>> There's also no reason to put the bus interface into the compatible as
>> the same compatible will work on different buses. But since you want to
>> add SPI, just using the 'i2c' one will confuse people. For that reason
>> you
Hello Rob,
On 4/8/22 20:22, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 10:02:00PM +0200, Javier Martinez Canillas wrote:
>> The current compatible strings for SSD130x I2C controllers contain an -fb
>> suffix, this seems to indicate that are for a fbdev driver. But the DT is
>> supposed to
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Friday, April 8, 2022 14:09
> To: Gong, Richard
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; Dave Airlie
> ; Daniel Vetter ; Limonciello, Mario
> ; Maling list - DRI developers de...@lists.freedesktop.org>;
On Fri, Apr 8, 2022 at 3:05 PM Richard Gong wrote:
>
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
> used with Intel AlderLake based systems to enable ASPM. Using these GFX
> cards as
Hi Yunfei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on v5.18-rc1 next-20220408]
[cannot apply to remoteproc/rproc-next drm-tip/drm-tip]
[If your patch is applied to the wrong git tree, kindly drop us a note
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that cannot be
used with Intel AlderLake based systems to enable ASPM. Using these GFX
cards as video/display output, Intel Alder Lake based systems will hang
during
On Thu, Apr 07, 2022 at 10:02:00PM +0200, Javier Martinez Canillas wrote:
> The current compatible strings for SSD130x I2C controllers contain an -fb
> suffix, this seems to indicate that are for a fbdev driver. But the DT is
> supposed to describe the hardware and not Linux implementation
On Wed, Mar 23, 2022 at 09:06:18PM +0100, Max Krummenacher wrote:
> Am Mittwoch, den 23.03.2022, 16:58 +0100 schrieb Maxime Ripard:
> > On Wed, Mar 23, 2022 at 09:42:11AM +0100, Max Krummenacher wrote:
> > > Am Freitag, den 18.03.2022, 17:53 + schrieb Dave Stevenson:
> > > > On Fri, 18 Mar
On Fri, Apr 8, 2022 at 12:15 PM Gong, Richard wrote:
>
> Hi Alex,
>
> On 4/8/2022 10:54 AM, Alex Deucher wrote:
> > On Fri, Apr 8, 2022 at 11:47 AM Limonciello, Mario
> > wrote:
> >> [Public]
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Gong, Richard
> >>> Sent: Friday, April 8,
On Fri, 8 Apr 2022 at 20:38, Sankeerth Billakanti
wrote:
>
> > > > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > > > differently from DP
From: John Harrison
Update to the latest GuC firmware release.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
From: John Harrison
The latest GuC firmware drops the individual scheduling policy update
H2G commands in favour of a single KLV based H2G. So, change the
update wrappers accordingly.
Unfortunately, the API changes also mean losing the ability to set any
scheduling policy values during context
From: John Harrison
The latest GuC firmware drops the context descriptor pool in favour of
passing all creation data in the create H2G. It also greatly simplifies
the work queue and removes the process descriptor used for multi-LRC
submission. So, remove all mention of LRC and process
From: John Harrison
Update to the latest GuC firmware release.
Note that this includes some significant backwards breaking API
changes. One is about context registration - the descriptor pool is
gone, all parameters are passed via the CTB instead. The second is
about scheduling policy updates -
On Fri, 8 Apr 2022 at 20:12, Sankeerth Billakanti
wrote:
>
> > > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > > wrote:
> > >>
> > >> The aux_bus support with the dp_display driver will enable the dp
> > >> resources during msm_dp_modeset_init. The host_init has to return
> > >> early
On Thu, Mar 24, 2022 at 09:15:33AM +0100, Francesco Dolcini wrote:
> On Wed, Mar 23, 2022 at 09:06:18PM +0100, Max Krummenacher wrote:
> > Am Mittwoch, den 23.03.2022, 16:58 +0100 schrieb Maxime Ripard:
> > > On Wed, Mar 23, 2022 at 09:42:11AM +0100, Max Krummenacher wrote:
> > > > I would copy
On 4/8/22 16:50, Noralf Trønnes wrote:
Hi Marek,
Hi,
I see that you have commit rights so I assume you will be applying this
patch.
It's already in drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/log/?h=drm-misc-fixes
On 2022-04-07 18:51, Dmitry Osipenko wrote:
On 4/6/22 21:06, Robin Murphy wrote:
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device,
> > > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > > differently from DP because the link capabilities are
> > > > > > > > > > not available for
Hi Doug and Dmitry
On 4/8/2022 7:58 AM, Dmitry Baryshkov wrote:
On Fri, 8 Apr 2022 at 16:43, Doug Anderson wrote:
Hi,
On Fri, Apr 8, 2022 at 5:20 AM Dmitry Baryshkov
wrote:
I guess my thought was that in DP you could still create the AUX bus
at probe time. Then for DP you just return an
Factor out from drm_dp_dpcd_read() a function to probe a DPCD address
with a 1-byte read access. This will be needed by the next patch doing a
read from an LTTPR address, which must happen without the preceding
wake-up read in drm_dp_dpcd_read().
v2: Add a probe function instead of exporting
> > On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
> > wrote:
> >>
> >> The aux_bus support with the dp_display driver will enable the dp
> >> resources during msm_dp_modeset_init. The host_init has to return
> >> early if the core is already initialized to prevent putting an
> >>
On Fri, Apr 08, 2022 at 09:48:37AM -0700, Lucas De Marchi wrote:
> Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed
> accesses") tried to improve our report of unclaimed register access,
> however it unveiled cases that were not previously causing any harm.
>
> Downgrade the
Commit 4b276ed3c7ac ("drm/i915/uncore: Warn on previous unclaimed
accesses") tried to improve our report of unclaimed register access,
however it unveiled cases that were not previously causing any harm.
Downgrade the first message to debug so we can still see them and
eventually fix, but don't
On Fri, 8 Apr 2022 at 18:50, Sankeerth Billakanti
wrote:
>
> Hi Dmitry,
>
> > > > > > > > On Wed, 30 Mar 2022 at 19:04, Sankeerth Billakanti
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > The panel-edp driver modes needs to be validated
> > > > > > > > > differently from DP because
Samsung MIPI DSIM master can also be found in i.MX8MM SoC.
Add compatible and associated driver_data for it.
v1:
* none
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 34 +++
1 file changed, 34 insertions(+)
diff --git
[Public]
> -Original Message-
> From: Gong, Richard
> Sent: Friday, April 8, 2022 11:20
> To: Limonciello, Mario ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@linux.ie; dan...@ffwll.ch
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
Samsung MIPI DSIM bridge can also be found in i.MX8MM/i.MX8MN SoC.
Add dt-bingings for it.
v1:
* new patch
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
eLCDIF is expecting to have input_bus_flags as DE_LOW in order to
set active low during valid data transfer on each horizontal line.
Add DE_LOW flag via drm bridge timings.
v1:
* none
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 5 +
1 file changed, 5
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component
Fixing up the mode flags is required in order to correlate the
correct sync flags of the surrounding components in the chain
to make sure the whole pipeline can work properly.
So, handle the mode flags via bridge, atomic_check.
v1:
* fix mode flags in atomic_check instead of mode_fixup
Add module init and exit functions for the bridge to register
and unregister dsi_driver.
Exynos drm driver stack will register the platform_driver separately
in the common of it's exynos_drm_drv.c including dsi_driver.
Register again would return -EBUSY, so return 0 for such cases as
dsi_driver
The i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020
with 13.7.10.1 Master PLL PMS Value setting Register mentioned PMS_P offset
range from BIT[18-13] and the upstream driver is using the same offset.
However, offset 13 is not working on i.MX8M Mini platforms but downstream
Host transfer() in DSI master will invoke only when the DSI commands
are sent from DSI devices like DSI Panel or DSI bridges and this
host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
Handling DSI host initialization in transfer calls misses the
controller setup for I2C configured
In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit
to reset in order to activate the PHY and that can be done via
upstream i.MX8M blk-ctrl driver.
So, mark the phy get as optional.
v1:
* new patch
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
1 file
In order to make a common Samsung DSIM bridge driver some platform specific
glue code needs to maintain separately as it is hard to maintain platform
specific glue and conventional component_ops on the drm bridge drivers side.
This patch is trying to support that glue code initialization and
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs, the
ideal way to incorporate this in the drm stack is via the drm bridge driver.
This patch is trying to
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
Previous RFC can be available here [1].
The final bridge supports both the Exynos and i.MX8MM DSI devices.
On, summary this patch-set break the entire DSIM driver into
- platform specific
On 4/8/2022 10:47 AM, Limonciello, Mario wrote:
[Public]
-Original Message-
From: Gong, Richard
Sent: Friday, April 8, 2022 10:45
To: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ;
airl...@linux.ie; dan...@ffwll.ch
Cc: amd-...@lists.freedesktop.org;
Hi Alex,
On 4/8/2022 10:54 AM, Alex Deucher wrote:
On Fri, Apr 8, 2022 at 11:47 AM Limonciello, Mario
wrote:
[Public]
-Original Message-
From: Gong, Richard
Sent: Friday, April 8, 2022 10:45
To: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ;
airl...@linux.ie;
On 01/04/2022 02:23, Doug Anderson wrote:
Hi,
On Wed, Mar 30, 2022 at 9:04 AM Sankeerth Billakanti
wrote:
The aux_bus support with the dp_display driver will enable the dp
resources during msm_dp_modeset_init. The host_init has to return early
if the core is already initialized to prevent
binV13Y2gY6Jf.bin
Description: Binary data
The platform devices registered in sysfb match with a firmware-based fbdev
or DRM driver, that are used to have early graphics using framebuffers set
up by the system firmware.
Real DRM drivers later are probed and remove all conflicting framebuffers,
leading to these platform devices for generic
Drivers that want to remove registered conflicting framebuffers prior to
register their own framebuffer, calls remove_conflicting_framebuffers().
This function takes the registration_lock mutex, to prevent a races when
drivers register framebuffer devices. But if a conflicting framebuffer
device
This function just returned 0 on success or an errno code on error, but it
could be useful for sysfb_init() callers to have a pointer to the device.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v2:
- Rebase on top of latest drm-misc-next and fix conflicts
These can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.
Suggested-by: Daniel Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
---
Changes in v2:
- Add kernel-doc comments and
Hello,
The patches in this series are mostly changes suggested by Daniel Vetter
to fix some race conditions that exists between the fbdev core (fbmem)
and sysfb with regard to device registration and removal.
For example, it is currently possible for sysfb to register a platform
device after a
Hi Christian,
We seem to be hitting a new issue in ttm_bo_move_sync_cleanup(), due
to passing a NULL fence, and I guess with some recent changes this is
now blowing up in at least dma_resv_add_fence(). Question is how
should we handle this? Should we add a special case in
On Fri, Apr 8, 2022 at 11:54 AM Alex Deucher wrote:
>
> On Fri, Apr 8, 2022 at 11:47 AM Limonciello, Mario
> wrote:
> >
> > [Public]
> >
> >
> >
> > > -Original Message-
> > > From: Gong, Richard
> > > Sent: Friday, April 8, 2022 10:45
> > > To: Deucher, Alexander ; Koenig, Christian
>
> Wiadomość napisana przez Sascha Hauer w dniu
> 08.04.2022, o godz. 14:00:
>
>> That turned out to be simpler than I thought it would be. The zpos
>> values were never actually written to the hardware. Please try the
>> following fixup, it should fix this issue.
>
> Or better try v10 which
On Fri, Apr 8, 2022 at 11:47 AM Limonciello, Mario
wrote:
>
> [Public]
>
>
>
> > -Original Message-
> > From: Gong, Richard
> > Sent: Friday, April 8, 2022 10:45
> > To: Deucher, Alexander ; Koenig, Christian
> > ; Pan, Xinhui ;
> > airl...@linux.ie; dan...@ffwll.ch
> > Cc:
1 - 100 of 233 matches
Mail list logo
