On Tue, 10 Dec 2019, Kirti Wankhede wrote:
> On 12/9/2019 7:31 PM, Jani Nikula wrote:
>> On Tue, 03 Dec 2019, Jani Nikula wrote:
>>> Now that the fbops member of struct fb_info is const, we can start
>>> making the ops const as well.
>>>
>>> v2: fix typo (Christophe de Dinechin)
>>>
>>> Cc:
Per HW, d71->num_blocks includes reserved blocks but no PERIPH block,
correct the block counting accordingly.
D71 happens to only have one reserved block and periph block, which
hides this counting error.
Signed-off-by: james qian wang (Arm Technology China)
---
On 12/9/19 3:46 PM, John Hubbard wrote:
On 12/9/19 2:53 PM, John Hubbard wrote:
...
@@ -212,10 +211,9 @@ static void mm_iommu_unpin(struct
mm_iommu_table_group_mem_t *mem)
if (!page)
continue;
- if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
-
On 12/9/19 4:56 PM, Andrew Morton wrote:
On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just
The CMDQ (Command Queue) in MT8183 is used to help update all
relevant display controller registers with critical time limation.
This patch add cmdq interface in ddp_comp interface, let all
ddp_comp interface can support cpu/cmdq function at the same time.
These patches also can fixup cursor
The DRM core atomic helper now supports asynchronous commits natively.
The custom drm implementation isn't needed anymore, remove it.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h
Support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 98 +++-
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_plane.c |
layer_on and layer_off both are unused external function,
remove them from mtk_ddp_comp_funcs structure.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 --
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16
2 files changed, 18
Unlike other SoCs, MT8183 does not have "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen
Under shadow register case, we do not disable all the plane before
disable all the hardwares. Fix it.
Fixes: 9dc84e98a31f ("drm/mediatek: add shadow register support")
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
1 file changed, 1
The CMDQ (Command Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
Signed-off-by: YT Shen
Signed-off-by:
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For the sake of symmetry with the crtc stuff let's add
> a helper to reset the plane state to sane default values.
> For the moment this only gets caller from the plane init.
>
Reviewed-by: José Roberto de Souza
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a few places where we want to reset a crtc state to its
> default values. Let's add a helper for that. We'll need the new
> __drm_atomic_helper_crtc_state_reset() helper for this to allow
> us to just reset
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the redundant intel_ prefix on our variables.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
>
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We already have alloc/free helpers for planes, add the same for
> crtcs. The main benefit is we get to move all the annoying state
> initialization out of the main crtc_init() flow.
>
Reviewed-by: José Roberto de
Hi, Mihail:
On Wed, 2019-12-04 at 11:48 +, Mihail Atanassov wrote:
> No functional change.
>
Acked-by: CK Hu
> Signed-off-by: Mihail Atanassov
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #53 from MasterCATZ (masterc...@hotmail.com) ---
its been like this since mid kernel 4's, just wish I knew whats locking that
file root has no permissions and it seems to activate @ 70 deg , which even if
i run the fan 100% will be
On 12/9/19 2:53 PM, John Hubbard wrote:
...
> @@ -212,10 +211,9 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> if (!page)
> continue;
>
> - if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
> -
On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call, without
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via unpin_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
1. Change vfio from get_user_pages_remote(), to
pin_user_pages_remote().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Note that this effectively changes the code's behavior in
A subsequent patch requires access to gup flags, so pass the flags
argument through to the __gup_device_* functions.
Also placate checkpatch.pl by shortening a nearby line.
TODO: Christoph Hellwig requested folding this into the patch the uses
the gup flags arguments.
Reviewed-by: Jan Kara
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
In order to provide a clearer, more symmetric API for pinning
and unpinning DMA pages. This way, pin_user_pages*() calls
match up with unpin_user_pages*() calls, and the API is a lot
closer to being self-explanatory.
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
This, combined with the fact that get_user_pages_fast() falls back to
"slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need
1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Leon Romanovsky
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
Hi,
This implements an API naming change (put_user_page*() -->
unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It
extends that tracking to a few select subsystems. More subsystems will
be added in follow up work.
Christoph Hellwig, a couple of points of interest:
a) I've
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
For now, these are placeholder calls, until the various call sites
are converted to use the correct get_user_pages*() or
pin_user_pages*() API.
These variants will eventually all set
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/gup.c | 29
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
Update VFIO to take advantage of the recently loosened restriction on
FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to
fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it
wasn't setting FOLL_LONGTERM.
Also, remove an unnessary pair of calls that were
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "goldfish_pin_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
From: Dan Williams
After the removal of the device-public infrastructure there are only 2
->page_free() call backs in the kernel. One of those is a device-private
callback in the nouveau driver, the other is a generic wakeup needed in
the DAX case. In the hopes that all ->page_free() callbacks
On Mon, Dec 2, 2019 at 5:36 PM Gurchetan Singh
wrote:
>
> With the misc device, we should end up using the result of
> get_arch_dma_ops(..) or dma-direct ops.
>
> This can allow us to have WC mappings in the guest after
> synchronization.
>
> Signed-off-by: Gurchetan Singh
> ---
>
Hi all,
[Just adding Dave Airlie to the cc list]
On Tue, 10 Dec 2019 09:39:57 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/spinlock_types.h:18,
>
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/spinlock_types.h:18,
from include/linux/mutex.h:16,
from include/linux/kernfs.h:12,
from
Hi Thierry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20191209]
[also build test WARNING on tegra-drm/drm/tegra/for-next v5.5-rc1]
[cannot apply to tegra/for-next drm-intel/for-linux-next v5.4]
[if your patch is applied to the wrong git tree, please drop
Neil Armstrong writes:
> This adds support for the ARM Framebuffer Compression decoders found
> in the Amlogic GXM and G12A SoCs.
>
> This patchset is a merge of v2 "drm/meson: add AFBC support" at [3] and v2
> "drm/meson: implement RDMA for AFBC reset on vsync" at [4].
Oops, replied to the
Neil Armstrong writes:
> When using an AFBC encoded frame, the AFBC Decoder must be resetted,
minor grammar nit: s/resetted/reset/
> configured and enabled at each vsync IRQ.
>
> To leave time for that, use the maximum lines hold time to give time
> for AFBC setup and avoid visual glitches.
>
On Sat, Dec 07, 2019 at 03:03:28PM +0100, Sam Ravnborg wrote:
> This patchset include a couple of different
> things - all related to panels.
>
> - The callbacks are optional - so drop error if
> callback is not present.
>
> - Add support for backlight in drm_panel.
> This allows us to make
Neil Armstrong writes:
> The VPU embeds a "Register DMA" that can write a sequence of registers
> on the VPU AHB bus, either manually or triggered by an internal IRQ
> event like VSYNC or a line input counter.
>
> The initial implementation handles a single channel (over 8), triggered
> by the
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #52 from muncrief (rmuncr...@humanavance.com) ---
(In reply to MasterCATZ from comment #51)
> current temp: 61000
> interpolated pwm value for temperature 61000 is: 170
> current pwm: 165, requested to set pwm to 170
> current pwm:
On Mon, Dec 9, 2019 at 9:57 AM Chuhong Yuan wrote:
>
> oaktrail_lvds_mode_set() misses a gma_power_end() in an error path.
> Add the call to fix it.
>
> Signed-off-by: Chuhong Yuan
Hi Chuhong, thanks for the patch.
Applied to drm-misc-next
-Patrik
> ---
>
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Attempt to enable split pagetables if the arm-smmu driver supports it.
> This will move the default address space from the default region to
> the address range assigned to TTBR1. The behavior should be transparent
> to the driver for now
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU struct in.
On Fri, Nov 22, 2019 at 3:32 PM Jordan Crouse wrote:
>
> Everywhere an IOMMU object is created by msm_gpu_create_address_space
> the IOMMU device is attached immediately after. Instead of carrying around
> the infrastructure to do the attach from the device specific code do it
> directly in the
This is a note to let you know that I've just added the patch titled
drm: damage_helper: Fix race checking plane->state->fb
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm: damage_helper: Fix race checking plane->state->fb
to the 5.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
real CRC value of the last edid data block, and write it back.
Current edid CRC calculates routine adds the last CRC byte,
and check if non-zero.
This behavior is not accurate; actually, we need to return
the actual CRC value when
At the moment, video mode parameters like video=540x960,reflect_x,
(without rotation set) are silently ignored.
One of the reasons for this is that the calculation that
combines the panel_orientation with cmdline->rotation_reflection
does not handle the case when cmdline->rotation_reflection does
Hi Rob.
>
> Yes. The issue would be enforcing the big disclaimer of "Do not add
> your panel here unless it has a single power rail." (And anything else
> we think of). Between a single line add vs. a whole new doc, you know
> what people will pick. I guess panels could still be moved out of the
On Wed, Dec 4, 2019 at 2:15 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Mon, Dec 02, 2019 at 08:38:39AM -0600, Rob Herring wrote:
> > On Sat, Nov 30, 2019 at 1:43 PM Sam Ravnborg wrote:
> > >
> > > Hi Rob.
> > >
> > > Thanks for doing this boring, trivial and tiresome task.
> >
> > It was somewhat
On Mon, Dec 09, 2019 at 11:16:27AM -0500, Sean Paul wrote:
> On Mon, Dec 9, 2019 at 10:21 AM Ville Syrjälä
> wrote:
> >
> > On Fri, Dec 06, 2019 at 08:52:33AM -0500, Sean Paul wrote:
> > > On Thu, Dec 05, 2019 at 09:39:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Dec 03, 2019 at 12:36:27PM
On Mon, Dec 9, 2019 at 10:21 AM Ville Syrjälä
wrote:
>
> On Fri, Dec 06, 2019 at 08:52:33AM -0500, Sean Paul wrote:
> > On Thu, Dec 05, 2019 at 09:39:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 03, 2019 at 12:36:27PM -0500, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > Now that
On Mon, Dec 9, 2019 at 10:18 AM Ville Syrjälä
wrote:
>
> On Fri, Dec 06, 2019 at 08:55:09AM -0500, Sean Paul wrote:
> > On Thu, Dec 05, 2019 at 09:33:19PM +0200, Ville Syrjälä wrote:
> > > On Tue, Dec 03, 2019 at 12:36:26PM -0500, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > >
On Mon, Dec 9, 2019 at 7:31 AM Rob Herring wrote:
>
> On Sun, Dec 8, 2019 at 3:24 PM Rob Clark wrote:
> >
> > On Sun, Dec 8, 2019 at 10:28 AM Laurent Pinchart
> > wrote:
> > >
> > > Hi Rob,
> > >
> > > On Sun, Dec 08, 2019 at 08:50:32AM -0800, Rob Clark wrote:
> > > > On Sun, Dec 8, 2019 at
Add support for Rocktech RK101II01D-CT, 10.1" 1280x800 TFT with LVDS
interface, LED backlight and integrated Goodix GT928 capacitive touch
panel.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32
Add DT schema binding for Rocktech Displays Limited RK101II01D-CT
10.1" TFT 1280x800 Pixels with LVDS interface, LED Backlight and
capacitive touch panel.
Signed-off-by: Jyri Sarha
---
.../display/panel/rocktech,rk101ii01d-ct.yaml | 48 +++
1 file changed, 48 insertions(+)
Since v1:
- Add "Reviewed-by: Tomi Valkeinen " to
"drm/panel: simple: Add Rocktech RK101II01D-CT panel"
- Fix "dt-bindings: display: DT schema for rocktech,rk101ii01d-ct panel"
Fix a copy-paste error on line 4 ("$id: http://devicetree.org/schemas...;)
Add support for Rocktech RK101II01D-CT
Hi Hsin-Yi,
On Mon, Dec 09, 2019 at 11:09:34PM +0800, Hsin-Yi Wang wrote:
> On Mon, Dec 9, 2019 at 10:55 PM Laurent Pinchart wrote:
> > On Mon, Dec 09, 2019 at 10:50:15PM +0800, Hsin-Yi Wang wrote:
> > > Support optional feature: bypass GPIO.
> > >
> > > Some SoC (eg. mt8173) have a hardware mux
On Sun, Dec 8, 2019 at 3:24 PM Rob Clark wrote:
>
> On Sun, Dec 8, 2019 at 10:28 AM Laurent Pinchart
> wrote:
> >
> > Hi Rob,
> >
> > On Sun, Dec 08, 2019 at 08:50:32AM -0800, Rob Clark wrote:
> > > On Sun, Dec 8, 2019 at 6:45 AM Laurent Pinchart wrote:
> > > > On Sat, Dec 07, 2019 at 12:35:50PM
On Fri, Dec 06, 2019 at 08:52:33AM -0500, Sean Paul wrote:
> On Thu, Dec 05, 2019 at 09:39:35PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 03, 2019 at 12:36:27PM -0500, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > Now that we can rely on transcoder disable to toggle signalling off,
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=205815
Bernard MAUDRY (ramaspaces...@free.fr) changed:
What|Removed |Added
Summary|When playing a wine game, |amdgpu: When
https://bugzilla.kernel.org/show_bug.cgi?id=205815
--- Comment #1 from Bernard MAUDRY (ramaspaces...@free.fr) ---
Created attachment 286237
--> https://bugzilla.kernel.org/attachment.cgi?id=286237=edit
I also attached amdgpu_firmware_info.
--
You are receiving this mail because:
You are
On Fri, Dec 06, 2019 at 08:55:09AM -0500, Sean Paul wrote:
> On Thu, Dec 05, 2019 at 09:33:19PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 03, 2019 at 12:36:26PM -0500, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > Currently we rely on intel_hdcp_disable() to disable HDCP signalling in
> >
https://bugzilla.kernel.org/show_bug.cgi?id=205815
Bug ID: 205815
Summary: When playing a wine game, got black screen then screen
flickers, game crashes and back to normal
Product: Drivers
Version: 2.5
Kernel Version:
On 09/12/2019 16:38, Andrey Smirnov wrote:
On Mon, Dec 9, 2019 at 1:38 AM Tomi Valkeinen wrote:
(Cc'ing Daniel for the last paragraph)
On 09/12/2019 07:08, Andrey Smirnov wrote:
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color selection.
Hi Hsin-Yi,
Thank you for the patch.
On Mon, Dec 09, 2019 at 10:50:15PM +0800, Hsin-Yi Wang wrote:
> Support optional feature: bypass GPIO.
>
> Some SoC (eg. mt8173) have a hardware mux that connects to 2 ports:
> anx7688 and hdmi. When the GPIO is active, the bridge is bypassed.
This doesn't
Hi Hsin-Yi,
Thank you for the patch.
On Mon, Dec 09, 2019 at 10:50:13PM +0800, Hsin-Yi Wang wrote:
> From: Nicolas Boichat
>
> Add support for analogix,anx7688
>
> Signed-off-by: Nicolas Boichat
> Signed-off-by: Hsin-Yi Wang
> ---
> .../bindings/display/bridge/anx7688.txt | 32
Hi Jyri,
Thank you for the patch.
On Mon, Dec 09, 2019 at 04:42:15PM +0200, Jyri Sarha wrote:
> The "ti,tilcdc,panel" binding should not be used anymore, since tilcdc
> is fully capable of using generic drm panels like panel-simple and
> panel-common binding. However, the obsolete binding is
Hi Jyri,
Thank you for the patch.
On Mon, Dec 09, 2019 at 04:42:16PM +0200, Jyri Sarha wrote:
> Add WARN() to the beginnig of tilcdc-panel probe. The obsolete
s/beginnig/beginning/
> tilcdc-panel driver should not be used anymore, since tilcdc is fully
> capable of using generic drm panels
intel_bw_state allocated memory is not getting freed even after
module removal.
kmemleak reported backtrace:
[<79019739>] kmemdup+0x17/0x40
[] intel_bw_duplicate_state+0x1b/0x40 [i915]
[<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140
The "ti,tilcdc,panel" binding should not be used anymore, since tilcdc
is fully capable of using generic drm panels like panel-simple and
panel-common binding. However, the obsolete binding is still widely
used in many mainline supported platforms that I do not have access to
and who knows how
From: Heiko Stuebner
Shenzhen Xinpeng Technology Co., Ltd produces for example display panels.
Signed-off-by: Heiko Stuebner
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
From: Heiko Stuebner
Base on the somewhat similar Rocktech driver but adapted for
panel-specific init of the XPP055C272.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
Add WARN() to the beginnig of tilcdc-panel probe. The obsolete
tilcdc-panel driver should not be used anymore, since tilcdc is fully
capable of using generic drm panels like panel-simple and panel-common
binding.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 10
Remove obsolete bundled tfp410 driver with its "ti,tilcdc,tfp410"
devicetree binding. No platform has ever used this driver in the
mainline kernel and if anybody connects tfp410 to tilcdc he or she
should use the generic drm tfp410 bridge driver.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent
Since v1:
- Add Reviewed-by: Laurent Pinchart
to "drm/tilcdc: Remove obsolete bundled tilcdc tfp410 driver"
- Add "drm/tilcdc: panel: Add WARN() with a comment to tilcdc-panel probe"
Nobody should any more use the old tilcdc bundled drivers anymore. The
driver is fully capable of using the
From: Heiko Stuebner
The XPP055C272 is a 5.5" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
.../display/panel/xinpeng,xpp055c272.yaml | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
On Fri, 6 Dec 2019 at 12:47, Thomas Zimmermann wrote:
>
> DPMS functionality is only used by the CRTC's enable and disable
> functions. Inline the code.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_modeset.c | 84 +++
> 1 file changed, 30
From: Heiko Stuebner
If implementation-specific phy_ops need to be defined they probably
should be enabled before trying to talk to the panel and disabled only
after the panel was disabled.
Right now they are enabled last and disabled first, so might make it
impossible to talk to some panels -
From: Heiko Stuebner
The timing values for dw-dsi are often dependent on the used display and
according to Philippe Cornu will most likely also depend on the used phy
technology in the soc-specific implementation.
To solve this and allow specific implementations to define them as needed
add a
From: Heiko Stuebner
Add the compatible and GRF definitions for the PX30 soc.
changes in v5:
- rebased on top of 5.5-rc1
- merged with dsi timing change to prevent ordering conflicts
Signed-off-by: Heiko Stuebner
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 27 +++
1
From: Heiko Stuebner
This series addes support for the px30 Rockchip soc to the dsi driver.
This includes support for external dsi-phys like used on the px30.
What happened between v1 and v5? The then separate dsi hs2lp timing
patch happened ;-) . As both it and this series touch similar areas
From: Heiko Stuebner
Some dw-mipi-dsi instances in Rockchip SoCs use external dphys.
In these cases the needs clock will also be generated externally
so these don't need the ref-clock as well.
changes in v5:
- rebased on top of 5.5-rc1
- merged with dsi timing change to prevent ordering
From: Heiko Stuebner
While the common case is that the dsi controller uses an internal dphy,
accessed through the phy registers inside the dsi controller, there is
also the possibility to use a separate dphy from a different vendor.
One such case is the Rockchip px30 that uses a Innosilicon
1 - 100 of 179 matches
Mail list logo
