On 12/26/2024, Marek Vasut wrote:
> On 12/24/24 5:21 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 24, 2024 at 02:46:14AM +0100, Marek Vasut wrote:
> >> The dw-hdmi output_port is set to 1 in order to look for a connector
> >> next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR
> working.
> >>
On 11/22/24, Marek Vasut wrote:
> On 11/20/24 7:38 AM, Ying Liu wrote:
>
> [...]
>
> >>> If the DP monitors support typical video modes like 1080p60 with
> >>> 148.5MHz pixel clock rate, I assume these typical video modes work
> >>> still ok wit
On 11/20/24, Marek Vasut wrote:
> On 11/19/24 9:18 AM, Ying Liu wrote:
>
> [...]
>
> >> The TC9595 can drive an DP output, for that the clock which have to be
> >> set on the LCDIF cannot be predicted, as that information comes from the
> >> monitor EDI
On 11/19/24, Marek Vasut wrote:
> On 11/18/24 4:54 AM, Ying Liu wrote:
> > Hi Marek,
>
> Hi,
>
> >>> media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
> >>> display controller, while media_disp2_pix clock is the pixel clock o
Hi Marek,
On 11/15/2024, Marek Vasut wrote:
> On 11/14/24 7:57 AM, Liu Ying wrote:
> > This reverts commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155.
> >
> > media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
> > display controller, while media_disp2_pix clock is the pixel clock
On Monday, February 26, 2024 3:28 PM, Marek Vasut wrote:
> 0, and would trigger a warning from clocks core about this condition.
s/clocks/clock/
Liu Ying
On Friday, January 19, 2024 2:39 AM, Marek Vasut wrote:
> In case the LCDIF is enabled in DT but unused, the clock used by the
Nit: s/clock/clocks/
> LCDIF are not enabled. Those clock may even have a use count of 0 in
Ditto.
> case there are no other users of those clock. This can happen e.g.
On Monday, November 27, 2023 5:32 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: "device_is_dependent"
> [drivers/gpu/drm/drm_kms_helper.ko] undefined!
I've sent a new patch
On Wednesday, November 22, 2023 9:59 PM, Linus Walleij
wrote:
> Hi Ying,
Hi Linus,
>
> On Mon, Nov 20, 2023 at 11:08 AM Ying Liu wrote:
>
> [Me]
> > > > v2->v3:
> > > > * Improve commit message s/swapped/reversed/.
> > >
> > > Th
Hi Linus,
On Wednesday, November 15, 2023 6:00 AM, Linus Walleij
wrote:
> On Mon, Aug 7, 2023 at 8:06 AM Liu Ying wrote:
>
> > Add the device link when panel bridge is attached and delete the link
> > when panel bridge is detached. The drm device is the consumer while
> > the panel device is t
On Tuesday, October 17, 2023 2:15 AM, Heiko Stübner wrote:
> Hi,
Hi,
>
> Am Montag, 17. Juli 2023, 08:18:27 CEST schrieb Liu Ying:
> > To get better accuration, use pixel clock rate to calculate lbcc instead of
> > lane_mbps since the pixel clock rate is in KHz while lane_mbps is in MHz.
> > Wit
On Thursday, September 28, 2023 7:36 PM, Lucas Stach
wrote:
> Otherwise the DMA enable races with the fetch start, which causes
> wrong or no data to be scanned out on the first frame. Also there
> is no point in waiting for the DMA disable when the controller is
> going to shut down. Simply disa
On Tuesday, September 5, 2023 4:37 PM, Maxime Ripard wrote:
> On Tue, Sep 05, 2023 at 03:32:47AM +0000, Ying Liu wrote:
> > > On Tue, Aug 22, 2023 at 04:59:48PM +0800, Liu Ying wrote:
> > > > +int dpu_cf_init(struct dpu_soc *dpu, unsigned int index,
> > > > +
On Friday, September 22, 2023 4:03 AM Lucas Stach
wrote:
> drm_atomic_helper_commit_tail_rpm makes it hard for drivers to follow
> the documented encoder/bridge enable flow, as it commits all CRTC enables
> before the planes are fully set up, so drivers that can't enable the
> display link withou
On Thursday, September 21, 2023 4:57 PM Lucas Stach
wrote:
> Am Donnerstag, dem 21.09.2023 um 08:18 + schrieb Ying Liu:
> > On Thursday, September 21, 2023 3:55 PM Lucas Stach
> wrote:
> > > Am Donnerstag, dem 21.09.2023 um 07:13 + schrieb Ying Liu:
> >
On Thursday, September 21, 2023 3:59 PM Lucas Stach
wrote:
> Am Donnerstag, dem 21.09.2023 um 07:34 + schrieb Ying Liu:
> > Hi,
> >
> > On Wednesday, September 20, 2023 6:31 PM Lucas Stach
> wrote:
> > > Force a modeset if the new FB has a different forma
On Thursday, September 21, 2023 3:55 PM Lucas Stach
wrote:
> Am Donnerstag, dem 21.09.2023 um 07:13 + schrieb Ying Liu:
> > Hi,
> >
> > On Wednesday, September 20, 2023 6:31 PM Lucas Stach
> wrote:
> > > Allow drm_atomic_helper_commit_tail_rpm to setup all
Hi,
On Wednesday, September 20, 2023 6:31 PM Lucas Stach
wrote:
> Force a modeset if the new FB has a different format than the
> currently active one. While it might be possible to change between
> compatible formats without a full modeset as the format control is
> also supposed to be double b
Hi,
On Wednesday, September 20, 2023 6:31 PM Lucas Stach
wrote:
> Allow drm_atomic_helper_commit_tail_rpm to setup all the plane
> state before the scanout is started.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 6 +-
> 1 file changed, 5 insertions(+), 1 del
Hi Lucas,
Thank you for the patch series.
On Wednesday, September 20, 2023 6:31 PM Lucas Stach
wrote:
> This changes the modeset flow in the imx-lcdif driver to work
> better with runtime PM and get rid of duplicate hardware setup.
I'm assuming the duplicate hardware setup is calling
lcdif_pla
On Wednesday, September 20, 2023 4:27 PM AngeloGioacchino Del Regno
wrote:
> When external bridges are attached with
> DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> the panel bridge may also get the same flag, but in the .attach()
> callback for the panel bridge a device link is added only when this
> flag i
Hi Angelo,
Thank you for the patch.
On Monday, September 18, 2023 11:01 PM, AngeloGioacchino Del Regno
wrote:
> When external bridges are attached with
> DRM_BRIDGE_ATTACH_NO_CONNECTOR,
> the panel bridge may also get the same flag, but in the .attach()
> callback for the panel bridge a device
On Thursday, August 24, 2023 5:48 PM, Maxime Ripard wrote:
> On Wed, Aug 23, 2023 at 08:47:51AM +0000, Ying Liu wrote:
> > > > This dt-binding just follows generic dt-binding rule to describe the DPU
> IP
> > > > hardware, not the software implementati
On Tuesday, August 22, 2023 8:59 PM, Maxime Ripard wrote:
>
> Hi,
Hi,
>
> Aside from the discussion on the binding and the general architecture, I
> have some comments there.
Thanks for your comments.
>
> On Tue, Aug 22, 2023 at 04:59:48PM +0800, Liu Ying wrote:
> > +int dpu_cf_init(struct
On Tuesday, August 29, 2023 2:38 AM Laurent Pinchart
wrote:
> On Tue, Aug 29, 2023 at 02:01:25AM +0800, Zhang Shurong wrote:
> > 在 2023年8月29日星期二 CST 上午1:28:22，Laurent Pinchart 写道：
> > > Hi Zhang,
> > >
> > > Thank you for the patch.
> > >
> > > On Tue, Aug 29, 2023 at 12:55:01AM +0800, Zhang Shur
On Wednesday, August 23, 2023 3:32 PM Maxime Ripard wrote:
>
> On Wed, Aug 23, 2023 at 02:45:53AM +, Ying Liu wrote:
> > On Tuesday, August 22, 2023 7:47 PM Maxime Ripard
> wrote:
> > >
> > > Hi,
> >
> > Hi Maxime,
> >
> > Thanks
On Tuesday, August 22, 2023 7:47 PM Maxime Ripard wrote:
>
> Hi,
Hi Maxime,
Thanks for your review.
>
> On Tue, Aug 22, 2023 at 04:59:44PM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu Yin
On Tuesday, August 22, 2023 4:06 PM Maxime wrote:
>
> Hi,
Hi,
>
> On Tue, Aug 22, 2023 at 05:36:14AM +0000, Ying Liu wrote:
> > Hi,
> >
> > > On Friday, January 6, 2023 1:50 PM Ying Liu wrote:
> > >
> > > Hi,
> > >
> &g
On Tuesday, August 22, 2023 3:20 PM Marcel Ziswiler
wrote:
>
> Hi Liu Ying
Hi Marcel,
>
> On Tue, 2023-08-22 at 05:36 +0000, Ying Liu wrote:
> > Hi,
> >
> > > On Friday, January 6, 2023 1:50 PM Ying Liu wrote:
> > >
> > > Hi,
> > >
Hi,
> On Friday, January 6, 2023 1:50 PM Ying Liu wrote:
>
> Hi,
>
>
> This is the v14 series to introduce i.MX8qm/qxp Display Processing Unit(DPU)
> DRM support.
>
> DPU is comprised of a blit engine for 2D graphics, a display controller
> and a command sequen
On Friday, August 11, 2023 3:30 AM Conor Dooley wrote:
>
> On Wed, Aug 02, 2023 at 11:51:17AM +0200, Guido Günther wrote:
> > Hi,
> > On Sun, Jul 30, 2023 at 09:41:20PM +0300, David Heidelberg wrote:
> > > i.MX8MQ uses as secondary compatible fsl,imx6sx-lcdif, which triggers
> > > requirement of
On Wednesday, August 9, 2023 9:54 PM Ulf Hansson wrote:
>
> On Mon, 7 Aug 2023 at 08:06, Liu Ying wrote:
> >
> > Add the device link when panel bridge is attached and delete the link
> > when panel bridge is detached. The drm device is the consumer while
> > the panel device is the supplier. Th
On Monday, July 31, 2023 2:44 AM Jagan Teki wrote:
>
> On Thu, Jul 20, 2023 at 12:40 PM Ying Liu wrote:
> >
> > Introduce ->get_input_bus_fmts() callback to struct dw_mipi_dsi_plat_data
> > so that vendor drivers can implement specific methods to get input bus
>
If GPIO pin is in input state but backlight is currently off due to
default pull downs, then initial power state is set to FB_BLANK_UNBLANK
in DT boot mode with phandle link and the backlight is effectively
turned on in gpio_backlight_probe(), which is undesirable according to
patch description of
If gpio pin is in input state but backlight is currently off due to
default pull downs, then initial power state is set to FB_BLANK_UNBLANK
in DT boot mode with phandle link and the backlight is effectively
turned on in gpio_backlight_probe(), which is undesirable according to
patch description of
If gpio pin is in input state but backlight is currently off due to
default pull downs, then initial power state is set to FB_BLANK_UNBLANK
in DT boot mode with phandle link and the backlight is effectively
turned on in gpio_backlight_probe(), which is undesirable according to
patch description of
Hi Daniel,
On Thursday, July 20, 2023 7:28 PM Daniel Thompson
wrote:
>
> On Thu, Jul 20, 2023 at 06:06:27AM +, Ying Liu wrote:
> > Bootloader may leave gpio direction as input and gpio value as logical low.
> > It hints that initial backlight power state should be
&g
Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
controller and a Synopsys Designware MIPI DPHY. Some configurations
and extensions to them are controlled by i.MX93 media blk-ctrl.
Add a DRM bridge for i.MX93 MIPI DSI by using existing DW MIPI DSI
bridge helpers and implementing i.
Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
controller and a Synopsys Designware MIPI DPHY. Some configurations
and extensions to them are controlled by i.MX93 media blk-ctrl.
Signed-off-by: Liu Ying
Reviewed-by: Rob Herring
---
v1->v2:
* Add Rob's R-b tag.
.../display/bri
According to Synopsys DW MIPI DSI host databook, HSTX and LPRX timeout
contention detections are measured in TO_CLK_DIVISION cycles. However,
the current driver programs magic values to TO_CLK_DIVISION, HSTX_TO_CNT
and LPRX_TO_CNT register fields, which makes timeout error event wrongly
happen for
According to Synopsys support channel, each region of HSA, HBP and HFP must
have minimum number of 10 bytes where constant 4 bytes are for HSS or HSE
and 6 bytes are for blanking packet(header + CRC). Hence, the below table
comes in.
++--+---+
| data lanes | min lbcc | byt
To get better accuration, use pixel clock rate to calculate lbcc instead of
lane_mbps since the pixel clock rate is in KHz while lane_mbps is in MHz.
Without this, distorted image can be seen on a HDMI monitor connected with
i.MX93 11x11 EVK through ADV7535 DSI to HDMI bridge in 1920x1080p@60 video
Vendor drivers may need to fixup mode due to pixel clock tree limitation,
so introduce the ->mode_fixup() callcack to struct dw_mipi_dsi_plat_data
and call it at atomic check stage if available.
Signed-off-by: Liu Ying
---
v1->v2:
* No change.
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 14
The DATAEN_ACTIVE_LOW bit in DSI_DPI_CFG_POL register is set to zero,
so set the DRM_BUS_FLAG_DE_HIGH flag in input_bus_cfg.flags. It appears
that the DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE flag also makes sense, so
set it in input_bus_cfg.flags too. With this patch, the flags set by
drm_atomic_brid
Introduce ->get_input_bus_fmts() callback to struct dw_mipi_dsi_plat_data
so that vendor drivers can implement specific methods to get input bus
formats for Synopsys DW MIPI DSI.
While at it, implement a generic callback for ->atomic_get_input_bus_fmts(),
where we try to get the input bus formats
Add dw_mipi_dsi_get_bridge() helper so that it can be used by vendor
drivers which implement vendor specific extensions to Synopsys DW MIPI DSI.
Signed-off-by: Liu Ying
---
v1->v2:
* No change.
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++
include/drm/bridge/dw_mipi_dsi.h
Hi,
This series aims to add MIPI DSI support for Freescale i.MX93 SoC.
There is a Synopsys DesignWare MIPI DSI host controller and a Synopsys
Designware MIPI DPHY embedded in i.MX93. Some configurations and
extensions to them are controlled by i.MX93 media blk-ctrl.
Add a DRM bridge for i.MX93
Bootloader may leave gpio direction as input and gpio value as logical low.
It hints that initial backlight power state should be FB_BLANK_POWERDOWN
since the gpio value is literally logical low. So, let's drop output gpio
direction check and only check gpio value to set the initial power state.
On Tuesday, July 18, 2023 11:47 PM Sam Ravnborg wrote:
>
> Hi Ying Liu,
Hi Sam,
>
> On Tue, Jul 18, 2023 at 09:00:25AM +0000, Ying Liu wrote:
> > > > + if (IS_ERR(dsi->regmap)) {
> > > > + ret = PTR_ERR(dsi->regmap);
> > > &g
On Tuesday, July 18, 2023 6:51 PM Jagan Teki wrote:
>
> Hi,
Hi,
>
> On Tue, Jul 18, 2023 at 3:19 PM Ying Liu wrote:
> >
> > On Tuesday, July 18, 2023 5:35 PM Jagan Teki
> wrote:
> > >
> > > >
> > > > Hi Jagan,
> > &g
On Tuesday, July 18, 2023 5:31 PM Alexander Stein
wrote:
>
> Hi,
Hi,
>
> Am Dienstag, 18. Juli 2023, 11:00:25 CEST schrieb Ying Liu:
> > On Tuesday, July 18, 2023 3:49 PM Alexander Stein
> group.com> wrote:
> > > Hi,
> >
> > Hi,
> >
> &g
On Tuesday, July 18, 2023 5:35 PM Jagan Teki wrote:
>
> >
> > Hi Jagan,
> >
> > On Monday, July 17, 2023 2:44 PM Jagan Teki
> wrote:
> > > On Mon, Jul 17, 2023 at 11:44 AM Liu Ying wrote:
> > > >
> > > > Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
> > > > controller and a Sy
On Tuesday, July 18, 2023 3:49 PM Alexander Stein
wrote:
>
> Hi,
Hi,
>
> thanks for the patch.
Thanks for your review.
>
> Am Montag, 17. Juli 2023, 08:18:31 CEST schrieb Liu Ying:
> > Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
> > controller and a Synopsys Designware MIP
On Tuesday, July 18, 2023 3:40 PM Alexander Stein
wrote:
>
> Hi,
Hi,
>
> Am Montag, 17. Juli 2023, 08:18:22 CEST schrieb Liu Ying:
> > Hi,
> >
> > This series aims to add MIPI DSI support for Freescale i.MX93 SoC.
> >
> > There is a Synopsys DesignWare MIPI DSI host controller and a Synopsys
Hi Jagan,
On Monday, July 17, 2023 2:44 PM Jagan Teki wrote:
> On Mon, Jul 17, 2023 at 11:44 AM Liu Ying wrote:
> >
> > Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host
> > controller and a Synopsys Designware MIPI DPHY. Some configurations
> > and extensions to them are controll
On Mon, Jun 12, 2023 at 5:06 PM Marek Vasut wrote:
>
> On 6/12/23 09:55, Liu Ying wrote:
> > When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),
> > overlay plane's framebuffer pointer is NULL. So, dereferencing it would
> > cause a kernel Oops(NULL pointer dereferencing). Fix t
On Mon, Jun 12, 2023 at 4:04 PM Sam Ravnborg wrote:
>
> Hi Liu Ying.
Hi Sam,
>
> On Mon, Jun 12, 2023 at 03:55:30PM +0800, Liu Ying wrote:
> > When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),
> > overlay plane's framebuffer pointer is NULL. So, dereferencing it would
> > cau
On Sun, Jun 4, 2023 at 3:57 PM Masahiro Yamada wrote:
> With the previous fix, these modules are built from a single C file.
>
> Rename the source files so they match the module names.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/bridge/imx/Makefile
On Sun, Jun 4, 2023 at 3:57 PM Masahiro Yamada wrote:
> With CONFIG_DRM_IMX8QM_LDB=m and CONFIG_DRM_IMX8QXP_LDB=y (or vice
> versa), imx-ldb-helper.o is linked to a module and also to vmlinux
> even though the expected CFLAGS are different between builtins and
> modules.
>
> This is the same situa
On Sun, Jun 4, 2023 at 6:16 PM Krzysztof Kozlowski
wrote:
> On 02/06/2023 05:54, Ying Liu wrote:
> > On Fri, Jun 2, 2023 at 1:45 AM Krzysztof Kozlowski
> > wrote:
> >>
> >> On 31/05/2023 11:32, Liu Ying wrote:
> >>> NXP i.MX93 mediamix blk
On Thu, Jun 1, 2023 at 2:45 AM Lucas Stach wrote:
>
> Force a modeset if the new FB has a different format than the
> currently active one. While it might be possible to change between
> compatible formats without a full modeset as the format control is
> also supposed to be double buffered, the c
On Fri, Jun 2, 2023 at 1:45 AM Krzysztof Kozlowski
wrote:
>
> On 31/05/2023 11:32, Liu Ying wrote:
> > NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which
> > configures parallel display format by using the "PARALLEL_DISP_FORMAT"
> > field. Add device tree bindings for the display
On Thu, Jun 1, 2023 at 6:33 PM Marek Vasut wrote:
>
> On 6/1/23 08:24, Ying Liu wrote:
> > On Thu, Jun 1, 2023 at 2:45 AM Lucas Stach wrote:
> >>
> >> Force a modeset if the new FB has a different format than the
> >> currently active one. While
On Thu, Jun 1, 2023 at 2:45 AM Lucas Stach wrote:
>
> Force a modeset if the new FB has a different format than the
> currently active one. While it might be possible to change between
> compatible formats without a full modeset as the format control is
> also supposed to be double buffered, the c
Hi Lucas,
On Thu, Jun 1, 2023 at 2:45 AM Lucas Stach wrote:
>
> The buffer pitch may change when switching the buffer on a
> atomic update. As the register is double buffered it can be
> safely changed while the display is active.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/mxsfb/lcd
Hi Marek,
On Thu, May 11, 2023 at 12:24 AM Marek Vasut wrote:
> On 5/10/23 11:24, Liu Ying wrote:
> > The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> > simultaneously. Look at LCDIF output port's remote port parents to
> > find all enabled first bridges. Add an encoder for
On Tue, May 9, 2023 at 10:14 AM Marek Vasut wrote:
>
> On 5/8/23 07:57, Liu Ying wrote:
> > The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> > simultaneously. Look at LCDIF output port's remote port parents to
> > find all enabled first bridges. Add an encoder for each found
On Tue, May 9, 2023 at 10:14 AM Marek Vasut wrote:
>
> On 5/8/23 07:57, Liu Ying wrote:
>
> Hi,
Hi,
>
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index 262bc43b1079..e54200a9fcb9 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/driv
Hi Fabio,
On Mon, Mar 15, 2021 at 8:38 PM Fabio Estevam wrote:
>
> The retrieval of driver data can be a bit simplified by using
> device_get_match_data(), so switch to it.
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/gpu/drm/imx/dcss/dcss-dev.c | 9 +
> 1 file changed, 1 insertion(
Hi Marek,
MXSFB can connect with LDB(LVDS display bridge) on i.MX6SX.
We have an existing LDB drm driver which works with IPUv3
embedded in i.MX6Q/DL and i.MX53.
Do you see a clear picture how all of these stuffs work together?
Adding Philipp also.
Regards,
Liu Ying
On Fri, Dec 2, 2016 at 2:02
On Mon, Oct 24, 2016 at 7:50 PM, Philipp Zabel
wrote:
> Am Freitag, den 21.10.2016, 16:49 +0800 schrieb Ying Liu:
>> On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel
>> wrote:
>> > Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
>> >> On Thu, Oc
On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel
wrote:
> Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
>> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
>> wrote:
>> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
>> >> >>
On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
wrote:
> Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu:
>> >> Does the clip thing potentially change the user's request by force?
>> >> For example, the user request an unreasonable big resolution.
>
On Thu, Oct 20, 2016 at 4:41 PM, Ville Syrjälä
wrote:
> On Thu, Oct 20, 2016 at 03:53:46PM +0800, Ying Liu wrote:
>> On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
>> wrote:
>> > Use drm_plane_helper_check_state to clip raw user coordinates to crtc
>> > b
On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
wrote:
> Use drm_plane_helper_check_state to clip raw user coordinates to crtc
> bounds. This checks for full plane coverage and scaling already, so
> we can drop some custom checks. Use the clipped coordinates everywhere.
>
> Suggested-by: Ville Syr
On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
wrote:
> Hook up support for DRM_FORMAT_YUV422, DRM_FORMAT_YVU422,
> DRM_FORMAT_YUV444, DRM_FORMAT_YVU444, DRM_FORMAT_NV12,
> and DRM_FORMAT_NV16.
>
> Signed-off-by: Philipp Zabel
Acked-by: Liu Ying
> ---
> Changes since v1:
> - Make UBO/VBO swa
On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
wrote:
> ipu_cpmem_set_yuv_planar_full is only used directly, remove the wrapper.
>
> Suggested-by: Liu Ying
> Signed-off-by: Philipp Zabel
Acked-by: Liu Ying
> ---
> drivers/gpu/ipu-v3/ipu-cpmem.c | 36
> i
On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
wrote:
> To support 4:2:2 or 4:4:4 chroma subsampling, divide the x/y offsets in
> drm_plane_state_to_ubo/vbo only if necessary for the given pixel format.
>
> Signed-off-by: Philipp Zabel
Acked-by: Liu Ying
> ---
> drivers/gpu/drm/imx/ipuv3-pla
On Wed, Oct 19, 2016 at 6:21 PM, Philipp Zabel
wrote:
> Odd x/y offsets are not allowed for horizontally/vertically chroma
> subsampled planar YUV formats.
>
> Signed-off-by: Philipp Zabel
Acked-by: Liu Ying
> ---
> Changes since v1:
> - Improve comment
> ---
> drivers/gpu/drm/imx/ipuv3-pla
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> If we want to stop resetting the IPU in the future, masking all
> interrupts before registering the irq handlers will not be enough to
> avoid spurious interrupts. We also have to clear them.
>
> Signed-off-by: Philipp Zabel
Acked-by: Liu
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> Hook up support for DRM_FORMAT_YUV422, DRM_FORMAT_YVU422,
> DRM_FORMAT_YUV444, DRM_FORMAT_YVU444, DRM_FORMAT_NV12,
> and DRM_FORMAT_NV16.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 52
> +
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> The IDMAC does support reading and writing DRM_FORMAT_YUV444 and
> DRM_FORMAT_YVU444.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 2 ++
> drivers/gpu/ipu-v3/ipu-cpmem.c | 17 +
> 2 files ch
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> ipu_cpmem_set_fmt is already prepared to handle DRM_FORMAT_YVU422.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/ipu-v3/ipu-cpmem.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/driv
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> To support 4:2:2 or 4:4:4 chroma subsampling, divide the x/y offsets in
> drm_plane_state_to_ubo/vbo only if necessary for the given pixel format.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 27 +++
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> ipu_plane_atomic_set_base is called from ipu_plane_atomic_update in two
> different places, depending on whether drm_atomic_crtc_needs_modeset is
> true. Also depending on the same condition, this function does two
> different things.
> Thi
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> If the framebuffer pixel format is planar YUV and unchanged, but the U
> or V plane offsets change, do not return an error, but request a modeset
> instead.
>
> Signed-off-by: Philipp Zabel
Acked-by: Liu Ying
> ---
> drivers/gpu/drm/im
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> Without this patch, after enabling the overlay plane with an RGBA
> framebuffer, switching to a framebuffer without alpha channel would
> cause the plane to vanish, since the pixel local alpha is constant
> zero in that case. Disable local
On Wed, Oct 19, 2016 at 12:07 AM, Philipp Zabel
wrote:
> Odd x/y offsets are not allowed for chroma subsampled planar YUV
> formats.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/ip
On Wed, Sep 7, 2016 at 5:52 PM, Maarten Lankhorst
wrote:
> This reverts commit 77953bd136d2a70bca2dc93b3ccda07a2b37076f.
>
> This causes a kernel panic when trying to assign a blob to a property,
> and has obviously never been tested.
>
> Signed-off-by: Maarten Lankhorst
Tested-by: Liu Ying
>
On Mon, Aug 29, 2016 at 4:27 PM, Daniel Vetter
wrote:
> They work exactly the same now, after the refcounting unification a bit
> ago. The only reason they're distinct is backwards compat with existing
> userspace.
>
> Cc: Daniel Stone
> Reviewed-by: Archit Taneja
> Signed-off-by: Daniel Vetter
On Mon, Aug 29, 2016 at 6:33 PM, Philipp Zabel
wrote:
> Add defines for the memory reset bits and export the memory reset
> function to IPU modules.
This one is probably unneeded since patch 2/2 is questionable.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 17 +++
On Mon, Aug 29, 2016 at 6:33 PM, Philipp Zabel
wrote:
> Reset the write FIFO memories after disabling the DMFC
> to make sure no stale data is kept around.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff
On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel
wrote:
> Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
>> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
>> wrote:
>> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> >> According to bas
On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
wrote:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> According to basic tests, it looks there is no issue if we don't wait for
>> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that,
>> either. This patch is nee
On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter wrote:
> On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
>> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
>> of the helper drm_atomic_helper_commit_planes() if the relevant display
>> controllers(e.g., IPUv3 for
Hi Thorsten,
On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis
wrote:
> Lo! Dave, below report made it to the list of regression for 4.8, but
> afaics nothing happened after the initial report. Was it discussed (and
> maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
> be on
On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu wrote:
>>>> +
>>>> + /*
>>>> + * The relevant plane's ->atomic_check callback may set
>>>> + * crtc_state->mode_chan
Hi Daniel,
On Mon, Aug 22, 2016 at 3:20 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote:
>> We don't support configuring active plane on-the-fly for imx-drm.
>> The relevant CRTC should be disabled before the plane configuration.
>> Of course, the plane itself
On Mon, Aug 22, 2016 at 3:01 PM, Daniel Vetter wrote:
> On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote:
>> Some display controllers need plane(s) to be disabled together with
>> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
>> This patch adds atomic_disable CRTC help
On Sun, Aug 14, 2016 at 7:43 PM, Peter Senna Tschudin
wrote:
> On Sun, Aug 14, 2016 at 12:46:27PM +0200, Daniel Vetter wrote:
>> On Sun, Aug 14, 2016 at 11:44:14AM +0200, Daniel Vetter wrote:
>> > On Sat, Aug 13, 2016 at 12:29:47PM +0100, Russell King - ARM Linux wrote:
>> > > On Sat, Aug 13, 2016
1 - 100 of 122 matches
Mail list logo
