For DP MST outputs, the i2c device currently only supports transfers
that can be implemented using remote i2c reads. Such transfers must
consist of zero or more write transactions followed by one read
transaction. DDC/CI commands require standalone write transactions and
hence aren't supported.
Si
If CONFIG_DRM_NOUVEAU=y,the following errors
are seen while building crc.h.
In file included from
/scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47:
/scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_head_crc_late_register’:
/scratch/linux/drivers/gpu/drm/nouveau/
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #100 from mn...@protonmail.com ---
I posted the patch on the LKML [1] just now so I can get the other
reviewers' input on it. I think it's safe to say that it's working now due
to how much I've tested it but I will test more over the c
The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other
KMS objects. Rename it accordingly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/Makefile | 2 +-
drivers/gpu/drm/mxsfb/{mxsfb_crtc.c =>
The LCDC_CTRL register is located at address 0x. Some of the
accesses to the register simply use the mxsfb->base address. Reference
the LCDC_CTRL register explicitly instead to clarify the code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers
The LCDIF present in the i.MX6SX has extra features compared to
the i.MX28. It has however lost its IP version register, so no official
version number is known. Bump the version to MXSFB_V6 following the i.MX
version, in preparation for support for the additional features.
Signed-off-by: Laurent P
Hello,
This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
instance found in the i.MX7 is backward-compatible with the already
supported LCDC v4, but has extended features amongst which the most
notable one is a second plane.
The first 10 patches (01/22 to 10/22) contain miscella
mxsfb_regs.h defines macros related to register bits. Some of them are
not used and don't clearly map to any particular register, so their
purpose isn't known. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_regs.
This is a cosmetic change only, no code change is included.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
The mxsfb_reset_block() function isn't special, pass it the
mxsfb_drm_private pointer instead of a pointer to the base address.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
1 file changed, 6 insert
Replace the convoluted way to set the format and bus width through
difficult to read macros with more explicit ones. Also remove the
outdated comment related to the limitations on bus width setting as it
doesn't apply anymore (the bus width can be specified through the
display_info bus format).
Si
The debug0 and ipversion fields of the mxsfb_devdata structure are
unused. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 --
2 files changed, 6 deletions(-)
Using BIT() is preferred over manual shifts as it's more readable,
handles the 1 << 31 case properly, and avoids other mistakes as shown by
the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use
it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Veli
Enable vblank handling when the CRTC is turned on and disable it when it
is turned off. This requires moving vblank init after the KMS pipeline
initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agne
Extend the Kconfig option description by listing the i.MX7 and i.MX8M
SoCs, as they are supported by the same driver. Replace the list of SoCs
in the short description with just "(e)LCDIF LCD controller" to avoid
expanding it further in the future as support for more SoCs is added.
Signed-off-by:
The DRM simple display pipeline helper only supports a single plane. In
order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
move away from the helper. No new feature is added.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
Changes since
Replace the manual connector implementation based on drm_panel with the
drm_panel_bridge helper. This simplifies the mxsfb driver by removing
connector-related code, and standardizing all pipeline control
operations on bridges.
A hack is needed to get hold of the connector, as that's our only sour
The mxsfb driver is only used by OF platforms. Drop non-OF support.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/g
The driver attempts agressive power management by enabling and disabling
the AXI clock around register accesses. This results in attempts to
enable and disable the clock in the IRQ handler, which is a no-go as
preparing or unpreparing the clock may sleep.
On the other hand, the driver enables the
mxsfb_crtc.c defines several macros related to register addresses and
bit, which duplicates macros from mxsfb_regs.h. Use the macros from
mxsfb_regs.h instead and remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_cr
A fair number of includes are not needed. Drop them, and add a couple of
required includes that were included indirectly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 +++-
drivers/gpu/drm/mxsfb/mxsfb_dr
The mxsfb_set_pixel_fmt() function returns an error when the selected
pixel format is unsupported. This can never happen, as such errors are
caught by the DRM core. Remove the error check.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stefan Agner
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/m
The mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() functions both deal
with format configuration, are always called in a row from
mxsfb_crtc_mode_set_nofb(), and set fields from the LCDC_CTRL register.
This requires a read-modify-update cycle in mxsfb_set_bus_fmt(). Make
this more efficient by mergi
Commit 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
replaced fbdev handling with drm_fbdev_generic_setup() but left
inclusion of the drm/drm_fb_cma_helper.h header. Remove it.
Fixes: 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
Signed-off-by: Laurent Pinchart
Reviewed-by
The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
plane. Support it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Emil Velikov
Reviewed-by: Stefan Agner
---
Changes since v1:
- Split whitespace cleanup to a separate patch
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
d
The vblank event is armed in the plane .atomic_update(). This works fine
as we have a single plane, and was the only option when the driver was
using the drm_simple_kms_helper helper, but will break as soon as
multiple planes are supported. Move it to CRTC .atomic_flush().
Signed-off-by: Laurent P
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #99 from mn...@protonmail.com ---
(In reply to Nicholas Kazlauskas from comment #98)
> As much as I'd like to remove the DRM private object from the state instead
> of just carrying it over I'd really rather not be hacking around behav
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #98 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
As much as I'd like to remove the DRM private object from the state instead of
just carrying it over I'd really rather not be hacking around behavior from the
DRM core itse
https://bugzilla.kernel.org/show_bug.cgi?id=207383
mn...@protonmail.com changed:
What|Removed |Added
Attachment #290485|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #67 from mn...@protonmail.com ---
(In reply to mnrzk from comment #66)
> Created attachment 290589 [details]
> drm/amd/display: Clear dm_state for fast updates
>
> Alright, the bug patch I mentioned in the last comment seems to be goo
https://bugzilla.kernel.org/show_bug.cgi?id=204181
mn...@protonmail.com changed:
What|Removed |Added
CC||mn...@protonmail.com
--- Comment #
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:24PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for use in a chained setup.
>
> - Replacing direct use of drm_panel with drm_panel_bridge support.
> - Make the connector creation optional
>
> Note: the bridge panel will
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:23PM +0200, Sam Ravnborg wrote:
> Add the get_edid() bridge operation to prepare for
> use as a chained bridge.
> Add helper function that is also used by the connector.
>
> v2:
> - Fix memory leak (Laurent)
> - Do not save a cop
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:22PM +0200, Sam Ravnborg wrote:
> Make the connector creation optional to enable usage of the
> megachips-stdp-ge-b850v3-fw bridge with the DRM bridge connector
> helper.
>
> v2:
> - Set bridge.type to DRM_MODE_CONNECTOR_Displa
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:21PM +0200, Sam Ravnborg wrote:
> To prepare for a chained bridge setup add support for the
> get_edid bridge operation.
> There is no need for a copy of the edid - so drop
> the pointer to the copy.
>
> v2:
> - Fix so we do not le
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:17PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for use in a chained setup by
> replacing direct use of drm_panel with drm_panel_bridge support.
>
> The connecter is now either created by the panel bridge or the display
>
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:16PM +0200, Sam Ravnborg wrote:
> With the bridge operations implemented the last step to prepare
> this driver for a chained setup is the use of the bridge panel driver.
>
> The bridge panel driver is only used when a prot@2 is pres
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:15PM +0200, Sam Ravnborg wrote:
> Prepare for chained bridge with the addition of
> get_edid support.
>
> v2:
> - Fixed handling of edid storage (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:13PM +0200, Sam Ravnborg wrote:
> Prepare the tc358764 bridge driver for use in a chained setup by
> replacing direct use of drm_panel with drm_panel_bridge support.
>
> The bridge panel will use the connector type reported by the pa
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:14PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for chained operation by adding
> support for the detect operation.
>
> v2:
> - Do not announce detect operation if there is no hpd pin (Laurent)
>
> Signed-off-by: Sam R
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:11PM +0200, Sam Ravnborg wrote:
> All panels shall report a connector type.
> panel-simple has a lot of panels with no connector_type,
> and for these fall back to DPI as the default.
>
> v2:
> - Rebased on top of validation of pan
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:10PM +0200, Sam Ravnborg wrote:
> Warn if we detect a panel with incomplete/wrong description.
> This is inspired by a similar patch by Laurent that introduced checks
> for LVDS panels - this extends the checks to the remaining type o
Hi Marek.
On Sun, Jul 26, 2020 at 12:17:46PM +0200, Marek Vasut wrote:
> On 7/26/20 9:15 AM, Sam Ravnborg wrote:
> > Hi Marek.
>
> Hi,
>
> > On Sat, Jul 25, 2020 at 11:14:57PM +0200, Marek Vasut wrote:
> >> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
> >> from tc358764
Prepare the bridge driver for chained operation by adding
support for the detect operation.
v2:
- Do not announce detect operation if there is no hpd pin (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
--
Prepare the bridge driver for use in a chained setup.
- Replacing direct use of drm_panel with drm_panel_bridge support.
- Make the connector creation optional
Note: the bridge panel will use the connector type from the panel.
v2:
- Use panel_bridge for local variable name to align with other
Warn if we detect a panel with incomplete/wrong description.
This is inspired by a similar patch by Laurent that introduced checks
for LVDS panels - this extends the checks to the remaining type of
connectors.
This is known to warn for some of the existing panels but added
despite this as we need
Drop drm_connector handling that is not needed:
- drm_dev_register() in the display controller driver takes
care of registering connectors.
So the call to drm_connector_register() call is not needed in the bridge
driver.
- Use of drm_connector_unregister() is only required for drivers that
Prepare the tc358764 bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The bridge panel will use the connector type reported by the panel,
where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS.
The tc358764 did not any add
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The connecter is now either created by the panel bridge or the display
driver. So all code for connector creation in this driver is no longer
relevant and thus dropped.
The con
All panels shall report a connector type.
panel-simple has a lot of panels with no connector_type,
and for these fall back to DPI as the default.
v2:
- Rebased on top of validation of panel description
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Thierry Reding
Cc: Sam Ravnborg
---
To prepare for use in a chained bridge setup enable the
detect operation.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
The objective is that all bridge drivers shall support a chained setup
connector creation is moved to the display drivers.
This is just one step on this path.
The general approach for the bridge drivers:
- Introduce bridge operations
- Introduce use of panel bridge and make connector creation opti
Add the get_edid() bridge operation to prepare for
use as a chained bridge.
Add helper function that is also used by the connector.
v2:
- Fix memory leak (Laurent)
- Do not save a copy of edid, read it when needed
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent
Fix so drm_device is read from the bridge.
This is a preparation for the connector being optional.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Kar
Make the connector creation optional to enable usage of the
megachips-stdp-ge-b850v3-fw bridge with the DRM bridge connector
helper.
v2:
- Set bridge.type to DRM_MODE_CONNECTOR_DisplayPort
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andr
Factor out connector creation to a small helper function.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../bridge
With the bridge operations implemented the last step to prepare
this driver for a chained setup is the use of the bridge panel driver.
The bridge panel driver is only used when a prot@2 is present in
the DT. So when the display driver request a connector
support both situations:
- connector create
To prepare for a chained bridge setup add support for the
get_edid bridge operation.
There is no need for a copy of the edid - so drop
the pointer to the copy.
v2:
- Fix so we do not leak memory (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Wel
Prepare for chained bridge with the addition of
get_edid support.
v2:
- Fixed handling of edid storage (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 34 +
On Sat, Jul 11, 2020 at 01:34:30AM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Fri, Jul 03, 2020 at 09:24:09PM +0200, Sam Ravnborg wrote:
> > Factor out connector creation to a small helper function.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Peter Senna Tschud
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #96 from mn...@protonmail.com ---
(In reply to Nicholas Kazlauskas from comment #95)
> Created attachment 290583 [details]
> 0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch
>
> So the sequence looks like the following:
On Saturday, July 25, 2020 12:59 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> On Sat, 25 Jul 2020 03:03:52 +
> Mazin Rezk mn...@protonmail.com wrote:
>
> > > Am 24.07.20 um 19:33 schrieb Kees Cook:
> > >
> > > > There was a fix to disable the async path for this driver that
> > > > worked around
On Thursday, July 23, 2020 6:57 PM, Mazin Rezk wrote:
> It seems that I spoke too soon. I ran the system for another hour after
> submitting the patch and the bug just occurred. :/
>
> Sadly, that means the bug isn't really fixed and that I have to go
> investigate further.
>
> At the very least,
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
NOTE: ChristophH wanted the dma_set_offset_range() function
On Friday, July 24, 2020 5:19 PM, Paul Menzel wrote:
> Dear Kees,
>
> Am 24.07.20 um 19:33 schrieb Kees Cook:
>
> > On Fri, Jul 24, 2020 at 09:45:18AM +0200, Paul Menzel wrote:
> >
> > > Am 24.07.20 um 00:32 schrieb Kees Cook:
> > >
> > > > On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wro
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #95 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Created attachment 290583
--> https://bugzilla.kernel.org/attachment.cgi?id=290583&action=edit
0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch
So the seq
Hi Stefan,
On Fri, Jul 17, 2020 at 05:06:55AM +0300, Laurent Pinchart wrote:
> On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
> > On 2020-06-16 03:50, Laurent Pinchart wrote:
> >> On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
> >>> On 2020-05-30 05:10, Laurent Pincha
On Sun, Jul 19, 2020 at 01:33:22AM +0200, Linus Walleij wrote:
> Whenener a display update was sent, apart from updating
> the memory base address we called mcde_display_send_one_frame()
> which also sent a command to the display requesting the TE IRQ
> and enabling the FIFO.
>
> When continous up
Hi Swapnil
Small nits in the following.
Sam
On Wed, Jul 22, 2020 at 09:40:40AM +0200, Swapnil Jakhade wrote:
> Add j721e wrapper for mhdp, which sets up the clock and data muxes.
>
> Signed-off-by: Jyri Sarha
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-b
Hi Swapnil
Thanks for submitting this driver.
A few highlevel things.
New bridge drivers shall be prepare for use in a chained
bridge driver setup.
This prompts you to add the following:
- Reelvant bridge operations
I noticed at least get_edid, and detect seems applicable.
- Support the
Hi Swapnil.
On Wed, Jul 22, 2020 at 09:40:38AM +0200, Swapnil Jakhade wrote:
> From: Yuti Amonkar
>
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Rob Herring
> Reviewed-by: Lau
Hi Neil.
On Thu, Jul 23, 2020 at 11:05:50AM +0200, Neil Armstrong wrote:
> Fix the Amlogic Video Framebuffer Compression modifier macro to
> correctly add the layout options, a pair of parenthesis was missing.
>
> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing
> Amlogi
Hi Rodrigo.
On Fri, Jul 24, 2020 at 05:34:04PM -0300, Rodrigo Alencar wrote:
> The supported displays are ls027b7dh01 (tested), ls044q7dh01,
> ls013b7dh05, ls013b7dh03
>
> Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
Thanks for submitting this driver.
Unfortunately I have some
Hi Biju
On Thu, Jul 23, 2020 at 12:10:54PM +0100, Biju Das wrote:
> Fix double-free bug in the error path.
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Reported-by: Pavel Machek
> Signed-off-by: Biju Das
> Cc: sta...@vger.kernel.org
Thanks, applied to drm-mi
On Mon, Jul 20, 2020 at 03:42:27PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> After the drm_bridge_connector_init() helper function has been added, the ADV
> driver has been changed accordingly. However, the 'type' field of the bridge
> structure was left unset, which makes the hel
On Mon, Jul 20, 2020 at 8:41 AM Jordan Crouse wrote:
>
> Each submitqueue is attached to a context. Add a pointer to the
> context to the submitqueue at create time and refcount it so
> that it stays around through the life of the queue.
>
> GPU submissions can access the active context via the su
Hi Linus.
On Sun, Jul 19, 2020 at 01:33:22AM +0200, Linus Walleij wrote:
> Whenener a display update was sent, apart from updating
s/Whenener/Whenever
> the memory base address we called mcde_display_send_one_frame()
^ insert comma?
> which also sent a command to the disp
Hi Guido.
On Sat, Jul 18, 2020 at 08:26:36PM +0200, Guido Günther wrote:
>
> We don't create a connector but let panel_bridge handle that so there's
> no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> This was prompted by Sam in
> https://lore.kernel.org/dri-devel/20200718115734.ga2989..
On Thu, Jul 16, 2020 at 01:21:22PM -0700, Douglas Anderson wrote:
> On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
> a small spike on the HPD line right when you power the panel on. The
> picture looks something like this:
>
> +
On Tue, Jul 14, 2020 at 08:33:32PM +0800, Jitao Shi wrote:
> Fine tune the HBP and HFP to avoid the dot noise on the left and right edges.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff -
On 7/24/2020 10:01 AM, Felix Kuehling wrote:
Am 2020-07-24 um 7:56 a.m. schrieb Christian König:
We can't pipeline that during eviction because the memory needs
to be available immediately.
v2: fix how we cleanup the BOs resources
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
Hi Vinod.
On Thu, Jul 23, 2020 at 10:04:39PM +0530, Vinod Koul wrote:
> Hi,
>
> This series adds driver and bindings for Lontium LT9611 bridge chip which
> takes MIPI DSI as input and HDMI as output.
>
> This chip can be found in 96boards RB3 platform [1] commonly called DB845c.
>
> [1]: https:
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
drivers/usb/dwc3/dwc3-qcom.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qco
QUSB on these SoCs actually uses *almost* the same
configuration that msm8996 does, so we can reuse
the phy_cfg from there with just a single change
(se clock scheme).
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-
Am 22.07.20 um 23:43 schrieb Daniel Vetter:
On Wed, Jul 22, 2020 at 8:13 PM Alex Bee wrote:
Hi,
this series mainly ports existining functionality to older SoCs - most
importantly enables alpha blending for RK3036, RK3066, RK3126 and
RK3188.
Besides that, it also changes the window type from
On Sat, 25 Jul 2020 03:03:52 +
Mazin Rezk wrote:
> > Am 24.07.20 um 19:33 schrieb Kees Cook:
> >
> > > There was a fix to disable the async path for this driver that
> > > worked around the bug too, yes? That seems like a safer and more
> > > focused change that doesn't revert the SLUB defe
This commit adds support for the MDP5 IP on Snapdragon
630. The configuration is different from SDM660's, as
the latter one has two DSI outputs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 93
1 file changed, 93 insertions(+)
diff --git a
This also applies to sdm630/636 and their SDA
counterparts.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/dr
The Powertip Tech. Corp. is an LCD panel manufacturer.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions
Add DT bindings for Powertip PH800480T013 800x480 parallel LCD,
this one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
.../panel/powert
Add missing halt_check, hwcg_reg and hwcg_bit properties.
These were likely omitted when porting the driver upstream.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-sdm660.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.
On Sat, 2020-07-25 at 10:11 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2020年7月23日 週四 上午10:05寫道：
> >
> > add mmsys private data
> >
> > Feature: drm/mediatek
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/soc/mediatek/Makefile | 1 +
> > drivers/soc/medi
On Thu, 2020-07-23 at 11:32 +0200, Enric Balletbo Serra wrote:
> Hi Yongqiang Niu,
>
> Thank you for your patch.
>
> Missatge de Yongqiang Niu del dia dj., 23
> de jul. 2020 a les 4:05:
> >
> > add mmsys private data
> >
>
> I think this change requires a better explanation of what you are
> do
Hi!
This series brings most of the changes that have been
brought to sdm630/636/660 SoCs apart from device tree
part (I cannot add anything unless some [1] smmu quirks
are merged.. blame qcom!)
So far, the platform is shaping up nicely, though some
peripherals seem to be living their own lives (I
Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
.../display/bridge/toshi
On Sat, 2020-07-25 at 07:24 +0800, Chun-Kuang Hu wrote:
> Hi Yongqiang:
>
> Yongqiang Niu 於 2020年7月23日 週四 上午10:15寫道：
> >
> > This patch add support for mediatek SOC MT8183
> > 1.ovl_2l share driver with ovl
>
> I think this is done in [1], [2], [3], this patch just add the support
> of mt8183-ov
Build errors are seen on MIPS platforms because of
vc state separation and the following build erros
were reported.
../linux/drivers/video/console/newport_con.c: In function ‘newport_clear’:
../linux/drivers/video/console/newport_con.c:365:15: error:
‘struct vc_data’ has no member named ‘vc_color’
On Thu, Jul 23, 2020 at 10:30:58PM +0200, Karol Herbst wrote:
> On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg
> wrote:
> >
> > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote:
> > > On 7/21/20 10:27 AM, Mika Westerberg wrote:
> > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400,
Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
from tc358764 driver and panel-raspberrypi-touchscreen. This driver is
meant to replace the panel-raspberrypi-touchscreen too, as the bridge
connection can be described in DT too.
Signed-off-by: Marek Vasut
To: dri-devel@lists.
1 - 100 of 128 matches
Mail list logo
