Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove
> it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The current code has some logic, disabled by default, to dump the register
> setup in the HDMI controller.
>
> However, since we're going to split those functions in multiple, shorter,
> functions that only make sense where they are
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HDMI driver was registering a single ALSA card so far with the name
> vc4-hdmi.
>
> Obviously, this is not going to work anymore when will have multiple HDMI
s/will/we
> controllers since we will end up trying to register two
On Tue, Jul 28, 2020 at 11:32:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 28.07.20 um 11:17 schrieb dan...@ffwll.ch:
> > On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote:
> >> The ast driver loads firmware for the DP501 display encoder. The
> >> patch replaces the removal
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Now that we only configure the PixelValve in vc4_crtc_config_pv, it doesn't
> really make much sense to dump its register content in its caller.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> the vc4_hdmi driver has some custom structures to hold the data it needs to
> associate with the drm_encoder and drm_connector structures.
>
> However, it allocates them separately from the vc4_hdmi structure which
> makes it more
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI driver was registering a single debugfs file so far with the name
> hdmi_regs.
>
> Obviously, this is not going to work anymore when will have multiple HDMI
> controllers since we will end up trying to register two files
On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote:
> The ast driver loads firmware for the DP501 display encoder. The
> patch replaces the removal code with a managed release function.
>
> Signed-off-by: Thomas Zimmermann
Hm a devm_request_firmware which does exactly this would
On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:
> On 2020-07-27 5:32 p.m., Daniel Vetter wrote:
> > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
> > >
> > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
> > >
> > > > On Mon, Jul 27, 2020 at 9:28 PM
On Tue, Jul 28, 2020 at 09:44:24AM +0200, Thomas Zimmermann wrote:
> The ast driver keeps a backup copy of the DP501 encoder's firmware. This
> patch adds managed release of the allocated memory.
>
> Signed-off-by: Thomas Zimmermann
We can't really do anything with the firmware after the device
On Mon, Jul 27, 2020 at 3:38 PM Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> 163d5446c37a ("drm/nouveau/disp/gm200-: fix regression from HDA SOR
> selection changes")
>
> Fixes tag
>
> Fixes: 9b5ca547bb8 ("drm/nouveau/disp/gm200-: detect and potentially
> disable HDA support on
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The vc4_crtc_handle_page_flip already has a local variable holding the
> value of vc4_crtc->channel, so let's use it instead.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c |
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The VIDEN bit in the pixelvalve currently being used to enable or disable
> the pixelvalve seems to not be enough in some situations, which whill end
> up with the pixelvalve stalling.
>
> In such a case, even re-enabling VIDEN
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to clear our intermediate FIFOs that might end up with a stale
> pixel, let's make sure our FIFO channel is reset everytime our channel is
> setup.
Minor nit pick: s/everytime/every time
> Signed-off-by: Maxime Ripard
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The unbind function needs to retrieve a vc4_hdmi structure pointer through
> the struct device that we're given since we want to support multiple HDMI
> controllers.
>
> However, our optional ASoC support doesn't make that trivial
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI PHY in the BCM2711 HDMI controller is significantly more
> complicated to setup than in the older BCM283x SoCs.
>
> Let's add hooks to enable and disable the PHY.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Similarly to the previous patches, the CSC setup is slightly different in
> the BCM2711 than in the previous generations. Let's add a callback for it.
We've gained the set_timings callback in this patch as well as
csc_setup. Was
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan wrote:
>
> 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
On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
> Managed releases of the device's I2C adapter simplify the connector's
> release.
>
> Signed-off-by: Thomas Zimmermann
I think this breaks bisect, since at this point the release callback is
called when the connector is already
Hi Yongqiang,
Missatge de Yongqiang Niu del dia ds., 25
de jul. 2020 a les 5:29:
>
> 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:
> > >
> > >
On Monday, July 27, 2020 7:42 PM, Mazin Rezk wrote:
> On Monday, July 27, 2020 5:32 PM, Daniel Vetter wrote:
>
> > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
> > >
> > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
> > >
> > > > On Mon, Jul 27, 2020 at 9:28 PM Christian
On Monday, July 27, 2020 5:32 PM, Daniel Vetter wrote:
> On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
> >
> > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
> >
> > > On Mon, Jul 27, 2020 at 9:28 PM Christian König
> > > wrote:
> > > >
> > > > Am 27.07.20 um 16:05 schrieb
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The vc4 CRTC will use the encoder type to control its output clock
> muxing. However, this will be different from HDMI0 to HDMI1, so let's
> store our type in the variant structure so that we can support multiple
> controllers later
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The mode_valid hook on the encoder uses a pointer to a drm_encoder called
> crtc, which is pretty confusing. Let's rename it to encoder to make it
> clear what it is.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HSM clock needs to be setup at around 101% of the pixel rate. This
> was done previously by setting the clock rate to 163.7MHz at probe time and
> only check in mode_valid whether the mode pixel clock was under the pixel
> clock
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HSM clock needs to be running at 101% the pixel clock of the HDMI
> controller, however it's shared between the two HDMI controllers, which
> means that if the resolutions are different between the two HDMI
> controllers, and
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid pixels getting stuck in an unflushable FIFO, we need when
> we disable the HDMI controller to switch away from getting our pixels from
> the pixelvalve and instead use blank pixels, and switch back to the
>
Am 28.07.20 um 05:23 schrieb Dave Airlie:
Hi Christian + Ben,
Just been reviewing around driver TTM code, and found an inconsistency,
amdgpu + radeon both call the above before binding the ttm and going
gpu vram->ram copies, but I don't see nouveau doing it Not sure if it
could cause any
Hi Greg,
Apparently the patchset has no more comments.
Could you take the patches to your tree? At least 1st and 2nd.
Regards
Andrzej
On 13.07.2020 16:43, Andrzej Hajda wrote:
> Hi All,
>
> Thanks for comments.
>
> Changes since v8:
> - fixed typo in function name,
> - removed cocci script
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to prevent some pixels getting stuck in an unflushable FIFO on
> bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI
> controller (the encoder) in an intertwined way, and with tight delays.
>
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to avoid stale pixels getting stuck in an intermediate FIFO
> between the HVS and the pixelvalve on BCM2711, we need to configure the HVS
> channel before the pixelvalve is reset and configured.
>
> Signed-off-by: Maxime
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI controllers found in the BCM2711 have most of the registers
> reorganized in multiple registers areas and at different offsets than
> previously found.
>
> The logic however remains pretty much the same, so it doesn't
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The BCM2711 and BCM283x HDMI controllers use a slightly different reset
> sequence, so let's add a callback to reset the controller.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid a pixel getting stuck in an unflushable FIFO, we need to
> recenter the FIFO every time we're doing a modeset and not only if we're
> connected to an HDMI monitor.
>
> Signed-off-by: Maxime Ripard
Reviewed-by:
Hi
Am 28.07.20 um 11:17 schrieb dan...@ffwll.ch:
> On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote:
>> The ast driver loads firmware for the DP501 display encoder. The
>> patch replaces the removal code with a managed release function.
>>
>> Signed-off-by: Thomas Zimmermann
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Since we moved the pixelvalve configuration to atomic_enable, we're now
> first calling the function that resets the pixelvalve and then the one that
> configures it.
>
> However, the first thing the latter is doing is calling the
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> On BCM2711 to avoid stale pixels getting stuck in intermediate FIFOs, the
> pixelvalve needs to be setup each time there's a mode change or enable /
> disable sequence.
>
> Therefore, we can't really use mode_set_nofb anymore to
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller
> requires very precise ordering and timing that the regular atomic callbacks
> don't provide. Let's add new callbacks on top of the regular ones to be
> able to
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to avoid a stale pixel getting stuck on mode change or a disable
> / enable cycle, we need to make sure to flush the PV FIFO on disable.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Similarly to the audio support, CEC support is not there yet for the
> BCM2711, so let's skip entirely the CEC initialization through a variant
> flag.
CEC is sorted now, but it's easier & cleaner to keep this patch and
add a new
On Tue, Jul 28, 2020 at 01:42:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just drop the argument from this.
>
> This does ask the question if this is the function vmwgfx
> should be using or should it be doing an evict all like
> the other drivers.
Yeah this looks a bit like
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Even though it's not really clear why we need to flush the PV FIFO during
> the configuration even though we started by flushing it, experience shows
> that without it we get a stale pixel stuck in the FIFO between the HVS and
> the
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we already
have primed):
mmap_read_lock ->
Hi
Am 28.07.20 um 11:23 schrieb dan...@ffwll.ch:
> On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote:
>> Managed releases of the device's I2C adapter simplify the connector's
>> release.
>>
>> Signed-off-by: Thomas Zimmermann
>
> I think this breaks bisect, since at this point
On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote:
> Changes to allow vga-switcheroo to switch the mux while modesetting
> clients remain active. There is existing support for switching the
> mux without checking can_switch; however, this support also does not
> reprobe after the mux
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with
> pixelvalves each being assigned to a given output, but each output can
> then be muxed to feed from multiple FIFOs.
>
> Since vc4 had that entirely static, both were
On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang wrote:
>
> From: Kevin Tang
Hm still no ack for dt bindings? We need that for merging.
Also what's the maintainer plan here? Imo best would be to put this
into the drm-misc group maintainer model, with commit rights and all:
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to make further refactoring easier, let's move the HVS channel
> setup / teardown to their own function.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hvs.c | 104
Hi Dave and Daniel,
here's this week's PR for drm-misc-fixes. It's mostly driver stuff.
There's one fix in the GEM ioctl code, but it has no impact on the
UAPI.
Best regards
Thomas
drm-misc-fixes-2020-07-28:
* drm: fix possible use-after-free
* dbi: fix SPI Type 1 transfer
* drm_fb_helper:
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI controllers found in the BCM2711 has a pretty different clock and
> registers areas than found in the older BCM283x SoCs.
>
> Let's create a variant structure to store the various adjustments we'll
> need later on, and a
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Let's continue the implementation of hooks for the parts that change in the
> BCM2711 SoC with the PHY RNG setup.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 15
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The CEC init code was put directly into the bind function, which was quite
> inconsistent with how the audio support was done, and would prevent us from
> further changes to skip that initialisation entirely.
>
> Signed-off-by:
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The VID_CTL setup is done in several places in the driver even though it's
> not really required. Let's simplify it a bit to do the configuration in one
> go.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 278
Hi Kevin
On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> From: Kevin Tang
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
>
>-Original Message-
>From: Ben Skeggs
>Sent: Tuesday, July 28, 2020 4:16 PM
>To: Ruhl, Michael J
>Cc: Dave Airlie ; dri-devel@lists.freedesktop.org;
>bske...@redhat.com
>Subject: Re: [PATCH] nouveau: use ttm populate mapping functions. (v2)
>
>On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael
Hi Kevin.
Thanks for submitting this set of drivers.
To better review the pataches can you please give some kind of high
level overview.
An ascii block diagram that identifies all the relevant blocks and how
they relate would be great.
This makes it easier to verify if the right modelling is
On Tue, 28 Jul 2020 at 17:49, Christian König wrote:
>
> Am 28.07.20 um 06:51 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > This was removed in
> > f5a9a9383f279de9da63296cb623a6418a66196b drm/ttm: remove
> > TTM_MEMTYPE_FLAG_CMA
> >
> > but the the declaration was left dangling.
> >
> >
On Wed, 29 Jul 2020 at 02:08, Ruhl, Michael J wrote:
>
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Dave Airlie
> >Sent: Monday, July 27, 2020 11:26 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: bske...@redhat.com
> >Subject: [PATCH] nouveau: use ttm populate mapping
Hi Paul.
On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote:
> Here are a few cleanups to the ingenic-drm driver.
> - some error paths were missing and have been added;
> - the mode validation has been moved to the .mode_valid helper callback.
>
> Cheers,
> -Paul
>
> Paul Cercueil
On Tue, Jul 28, 2020 at 01:07:13PM -0400, Kazlauskas, Nicholas wrote:
> On 2020-07-28 5:22 a.m., Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > Am 25.07.20 um 07:20 schrieb Mazin Rezk:
> > > On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
> > >
> > > > On Sat, 25 Jul 2020 03:03:52
On Tue, Jul 28, 2020 at 10:17:36PM +0200, Sam Ravnborg wrote:
> Hi Paul.
>
> On Tue, Jul 28, 2020 at 05:16:39PM +0200, Paul Cercueil wrote:
> > Here are a few cleanups to the ingenic-drm driver.
> > - some error paths were missing and have been added;
> > - the mode validation has been moved to
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
Possibly a comment to say that the VEC and PV3 are deliberately NOT
enabled as the VEC requires further very specific clock
On 2020-07-28 5:22 a.m., Paul Menzel wrote:
Dear Linux folks,
Am 25.07.20 um 07:20 schrieb Mazin Rezk:
On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
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
On Tue, Jul 28, 2020 at 02:12:46PM +0200, Marek Vasut wrote:
> Add support 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
Hi Thomas.
On Tue, Jul 28, 2020 at 09:44:12AM +0200, Thomas Zimmermann wrote:
> This is the final patchset for converting ast to managed initialization.
>
> Patches #1 to #4 address I2C helpers. The structures are being stored
> in struct ast_connector. The initialization and cleanups is being
VMAs with a pg_offs that's offset from the start of the vma_node need
to adjust the offset within the BO accordingly. This matches the
offset calculation in ttm_bo_vm_fault_reserved.
Signed-off-by: Felix Kuehling
Tested-by: Laurent Morichetti
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++-
1
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
> In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
> runtime-pm reference; and then on any errors it needs to release it
> again.
>
> This leads to somewhat hard to read code. This commit introduces a new
>
From: Kevin Tang
Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dphy.yaml | 75 +
.../devicetree/bindings/display/sprd/dsi.yaml
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/drm.yaml | 36
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
---
V2: Add the
From: Kevin Tang
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
On 28/07/2020 17:59, Roger Pau Monné wrote:
> On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 27/07/2020 10:13, Roger Pau Monne wrote:
>>> To be used in order to create foreign mappings. This is based on the
>>> ZONE_DEVICE facility which is used by persistent memory
Hi Roger,
On 28/07/2020 17:59, Roger Pau Monné wrote:
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory
From: chunhui dai
- disable tmds on phy on mt2701
- support other resolutions like 1280x1024
without this Patch i see flickering on my TFT (1280x1024),
so i guess clock is wrong.
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
Add support 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
---
V2: Add bus_flags
On Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote:
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> >> Hi,
> >>
> >> On 27/07/2020 10:13, Roger Pau Monne wrote:
> >>> To be used in order to create foreign mappings. This
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on
From: Stu Hsieh
Test: build pass and run ok
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 42 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 2 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
Currently `struct drm_buf_desc` is defined as follows:
struct drm_buf_desc {
int count;
int size;
int low_mark;
int high_mark;
enum {
_DRM_PAGE_ALIGN = 0x01,
_DRM_AGP_BUFFER = 0x02,
_DRM_SG_BUFFER = 0x04,
fixed the following warning:
hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
v2:
using the pci_dev.msi_enabled instead of priv->msi_enabled.
v3:
just call pci_enable_msi() and pci_disable_msi(), it's no
From: Kevin Tang
ChangeList:
v1:
1. only upstream modeset and atomic at first commit.
2. remove some unused code;
3. use alpha and blend_mode properties;
3. add yaml support;
4. remove auto-adaptive panel driver;
5. bugfix
v2:
1. add sprd crtc and plane module for KMS, preparing for multi crtc
From: Kevin Tang
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem.
It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
RFC v6:
- Access registers via readl/writel
- Checking for unsupported KMS properties (format, rotation, blend_mode, etc)
Here are a few cleanups to the ingenic-drm driver.
- some error paths were missing and have been added;
- the mode validation has been moved to the .mode_valid helper callback.
Cheers,
-Paul
Paul Cercueil (2):
drm/ingenic: Handle errors of drm_atomic_get_plane_state
drm/ingenic: Validate
On 7/28/20 3:07 AM, Kevin Tang wrote:
> diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> new file mode 100644
> index 000..b189a54
> --- /dev/null
> +++ b/drivers/gpu/drm/sprd/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_SPRD
> + tristate "DRM Support for Unisoc SoCs
This Patch-Series adds missing Patches/Bugfixes to get hdmi working
on BPI-R2
This is v2 of series https://patchwork.kernel.org/cover/10903309/ after
getting mmsys done
v1->v2:
- using get_possible_crtc API instead of hardcoded
- drop unused dts-nodes
- refine commit-messages as far as i can
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
arch/arm/boot/dts/mt7623.dtsi | 177
drm_atomic_get_plane_state() can return errors, so we need to handle
these.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dpu.yaml
From: Kevin Tang
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by
From: Peilin Ye
> Sent: 28 July 2020 12:52
> Currently `struct drm_buf_desc` is defined as follows:
>
> struct drm_buf_desc {
> int count;
> int size;
> int low_mark;
> int high_mark;
> enum {
> _DRM_PAGE_ALIGN = 0x01,
> _DRM_AGP_BUFFER =
Dear Linux folks,
Am 25.07.20 um 07:20 schrieb Mazin Rezk:
On Saturday, July 25, 2020 12:59 AM, Duncan wrote:
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
Hi Emil,
Sorry, I left for a long time because of other things. Now i'm back~
V6 fix access registers via readl/writel, check unsupported KMS
properties (format, rotation, blend mode, etc) by plane_check callback
ops
and remove always true checks for dpu core ops
Add changelog within the
From: Bibby Hsieh
We can select output component by decive node port.
Main path default output component is DSI.
External path default output component is DPI.
without this Patch i get this warning:
WARNING: CPU: 3 PID: 70 at drivers/gpu/drm/drm_mode_config.c:621
Validate modes in the drm_crtc_helper_funcs.mode_valid() callback, which
is designed for this purpose, instead of doing it in
drm_crtc_helper_funcs.atomic_check().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +--
1 file changed, 20
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle
Unlike we previously thought, the per-pixel alpha is just as broken on the
A20 as it is on the A10. Remove the quirk that says we can use it.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
alpha support")
Signed-off-by: Maxime Ripard
---
Unlike what we previously thought, only the per-pixel alpha is broken on
the lowest plane and the per-plane alpha isn't. Remove the check on the
alpha property being set on the lowest plane to reject a mode.
Cc: Paul Kocialkowski
Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for
On Tue, Jul 28, 2020 at 12:35:17PM +, David Laight wrote:
> From: Peilin Ye
> > Sent: 28 July 2020 12:52
> > Currently `struct drm_buf_desc` is defined as follows:
> >
> > struct drm_buf_desc {
> > int count;
> > int size;
> > int low_mark;
> > int high_mark;
> > enum {
>
From: Jitao Shi
[Detail]
dpi/dsi get the possible_crtc by
mtk_drm_find_possible_crtc_by_comp(*drm_dev, ddp_comp)
Test: build pass and boot to logo
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_dsi.c | 3 ++-
2 files changed, 4
1 - 100 of 172 matches
Mail list logo
