Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 86 -
1 file changed, 35 insertions(+), 51 deleti
In order to integrate with a chain of drm_bridge, the internal VENC
encoder has to expose the mode valid, fixup and set, the enable and
disable and the get modes operations through the drm_bridge API.
Register a bridge at initialisation time to do so.
Most of those operations are removed from the
Due to the removal of several omapdrm display drivers, the omapdss HPD,
detected and EDID operations are not used anymore. Remove them and all
related code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 61
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 46
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 +++
driver
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
The omapdss device .set_infoframe() and .set_hdmi_mo
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as c
Group functions based on their purpose and split them in sections to
make the source code easier to navigate.
No functional change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 146 --
1 file changed, 79 insertions(+), 67 deleti
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 96 -
1 file changed, 40 insertions(+), 56 deleti
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
drivers/gpu/drm/omapdrm/omap_encoder.c | 26 --
2 files changed, 29 del
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
drivers/gpu/drm/omapdrm/omap_drv.c| 7 ---
3 files changed, 4 insertions(+), 13
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
- Keep MAX_EDID macro
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 36
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 2d0eb5fcbb5
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 6
drivers/gpu/drm/omapdrm/omap_encoder.c | 44
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as c
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 32 ---
1 file
The DSS core looks up the next device connected to an output by
traversing the OF graph. It currently hardcodes the local port number to
0, which breaks any output with a different port number (SDI on OMAP3
and any DPI output but the first one). Fix this by repurposing the
currently unused of_ports
As part of the move to drm_bridge ops, the dssdev ops will become empty
for some of the internal encoders. Make them optional in the driver to
allow them to be removed completely, easing the transition.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/
The TPD12S015, OPA362 and analog and HDMI connectors are now supported
by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
handled through the drm_bridge API. Switch the outputs to drm_bridge by
making the next bridge mandatory and removing the related
omapdrm-specific display drive
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can
be accessed directly from the connector's display info.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_connector.c | 11 ---
drivers/gpu/drm/omapdrm/omap_connector.h |
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
3 files change
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
In order to integrate with a chain of drm_bridge, the internal HDMI5
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on omap_
In order to support drm_bridge-based pipeline, the internal HDMI
encoders will need to expose the EDID read operation through the
drm_bridge API, and thus to expose a drm_bridge instance corresponding
to the encoder. The HDMI encoders are however handled as omap_dss_device
instances, which conflict
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
Changes since v1:
-
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
b/drivers/gpu/drm/omapdrm/d
Now that the VENC output is driven fully through the drm_bridge API its
omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/venc.c | 45 --
1 file changed, 45 deletions(-)
diff --git a/drivers/
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 11aa2f712ff4..
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
Now that the HDMI outputs are driven fully through the drm_bridge API
their omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 18 --
drivers/gpu/drm/o
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Si
From: Boris Brezillon
With the introduction of per-FD address space, the same BO can be mapped
in different address space if the BO is globally visible (GEM_FLINK)
and opened in different context or if the dmabuf is self-imported. The
current implementation does not take that case into account, a
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-o
On Sun, Dec 8, 2019 at 9:06 PM Robert Jarzmik wrote:
> Linus Walleij writes:
> > @@ -525,13 +525,33 @@ static void spitz_bl_kick_battery(void)
> > }
> > }
> >
> > +static struct gpiod_lookup_table spitz_lcdcon_gpio_table = {
> > + .dev_id = "spi0.1",
> How do you know the correct devi
Hi Linus.
On Tue, Dec 10, 2019 at 10:29:59PM +0100, Linus Walleij wrote:
> On Tue, Dec 10, 2019 at 8:48 PM Sam Ravnborg wrote:
>
> > Fix link failure for module builds of panels.
> > The conditional compilation around drm_panel_of_backlight()
> > was wrong for a module build.
> > Fix it using IS
On Mon, Dec 2, 2019 at 4:49 PM Hans de Goede wrote:
> There is only one problem, currently is is not possible to
> unregister a mapping added with pinctrl_register_mappings
> and the i915 driver is typically a module which can be unloaded
> and I believe actually is unloaded as part of the i915 C
On 12/10/19 5:39 AM, Jan Kara wrote:
...
>> +void grab_page(struct page *page, unsigned int flags)
>> +{
>> +if (flags & FOLL_GET)
>> +get_page(page);
>> +else if (flags & FOLL_PIN) {
>> +get_page(page);
>> +WARN_ON_ONCE(flags & FOLL_GET);
>> +
On 12/10/19 4:49 AM, Jan Kara wrote:
> On Mon 09-12-19 14:53:41, John Hubbard wrote:
>> 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
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #44 from crab2...@gmail.com ---
Created attachment 286253
--> https://bugzilla.kernel.org/attachment.cgi?id=286253&action=edit
log of x395 when suspend
--
You are receiving this mail because:
You are watching the assignee of the bu
https://bugzilla.kernel.org/show_bug.cgi?id=204241
crab2...@gmail.com changed:
What|Removed |Added
CC||crab2...@gmail.com
--- Comment #43 f
On Mon, 9 Dec 2019 21:53:00 -0800 John Hubbard wrote:
> > Correction: this is somehow missing the fixes that resulted from Jan Kara's
> > review (he
> > noted that we can't take a page lock in this context). I must have picked
> > up the
> > wrong version of it, when I rebased for -rc1.
> >
>
On Tue, Dec 10, 2019 at 12:58 AM Gerd Hoffmann wrote:
>
> virtio-gpu uses cached mappings. shmem helpers use writecombine though.
> So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak
> vm_page_prot accordingly.
>
> Reported-by: Gurchetan Singh
> Signed-off-by: Gerd Hoffmann
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 ca
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 point of interest:
a) I've moved the bulk
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 functi
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 p
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
vfio_iommu_type1.c:
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 FOLL
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
---
Documentation/core-api/p
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) R
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
Rev
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
---
drivers/media/v4l2-
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 i
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 releasi
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 correspon
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 set_page_
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 +++---
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 put_us
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 FO
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
---
drivers/plat
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".
P
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page().
Cc: Jan Kara
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/ar
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"
phr
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 put_
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 pin_u
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
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
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
On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
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]
[<000
On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote:
> On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote:
> >intel_bw_state allocated memory is not getting freed even after
> >module removal.
> >
> >kmemleak reported backtrace:
> >
> > [<79019739>] kmemdup+0x17/
Hi
Am 10.12.19 um 16:11 schrieb Mihail Atanassov:
> As suggested in [1], the 'dev' field is a bit repetitive, since it 1:1
> follows the setting and NULLing of the 'encoder' field. Therefore, use
> drm_bridge->encoder->dev in place of drm_bridge->dev.
>
> [1] https://patchwork.freedesktop.org/pat
On Mon, 9 Dec 2019 at 22:00, Thierry Reding wrote:
>
> From: Thierry Reding
>
> Hi Ben,
>
> here's a revised subset of the patches I had sent out a couple of weeks
> ago. I've reworked the BAR2 accesses in the way that you had suggested,
> which at least for GP10B turned out to be fairly trivial
Hi
Am 09.12.19 um 15:35 schrieb Emil Velikov:
> 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 +++
Hi Matthias,
On 7/12/19 23:47, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Check the return value of of_clk_get and print an error
> message if not EPROBE_DEFER.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 6 ++
> 1 file chan
Hi Matthias,
On 7/12/19 23:47, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Switch probing for the MMSYS to support invocation to a
> plain paltform device. The driver will be probed by the DRM subsystem.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/clk/mediatek/clk-mt27
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.
Signed-off-by: Hsin-Yi Wang
---
.../bindings/display/bridge/anx7688.txt | 40 ++-
1 file changed, 3
+ Chris Healy
On Mon, Dec 9, 2019 at 12:27 AM Tomi Valkeinen wrote:
>
> Link training fails with:
>
> Link training timeout waiting for LT_LOOPDONE!
> main link enable error: -110
>
> This is caused by too tight timeouts, which were changed recently in
> aa92213f388b ("drm/bridge: tc358767: S
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: Kirti Wankhede
Cc: k...@vger.kernel.org
Reviewed-by: Daniel Vetter
S
Hi Jani
Sorry to bother you. May this patch is OK to be upstream?
If have any suggestion, I will try to modify the code to meet the upstream
standard.
From: Allen Chen (陳柏宇)
Sent: Thursday, December 05, 2019 9:24 AM
To: 'Jani Nikula'
Cc: Jau-Chih Tseng (曾昭智); maxime.rip...@bootlin.com;
linux-k
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: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
Documentation/devicetree/bindings/display/spr
> De: "Lukas Bulwahn"
> À: "Thomas Hellstrom" , dri-devel@lists.freedesktop.org
> Cc: "David Airlie" , "Daniel Vetter" ,
> "Sinclair Yeh" ,
> linux-graphics-maintai...@vmware.com, kernel-janit...@vger.kernel.org,
> linux-ker...@vger.kernel.org, "Lukas Bulwahn"
>
> Envoyé: Dimanche 8 Décembre 20
This series is to add anx7688 bridge driver. It is extended from
previous work[1].
The first 2 patches are same as previous version, with some modification
due to drm core function changes and use regmap abstraction.
We add an optional feature bypass-gpios so that driver can decide if it serves
a
Support optional feature: bypass GPIO.
Get GPIO status in irq handler. If GPIO is active, mode_fixup would be
bypassed.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix-anx7688.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/bridge/a
Hi Matthias,
On 7/12/19 23:47, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the clocks. Omit this error o
From: Nicolas Boichat
From: Nicolas Boichat
ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.
The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side.
Hi all,
This patch is our Unisoc's new drm display driver, This driver
provides support for the Direct Rendering Infrastructure (DRI)
in XFree86 4.1.0 and higher.
This patch include display controller, mipi dsi and mipi dphy support
for Unisoc's display subsystem.
Best,
Kevin Tang
Kevin Tang (8)
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. It being a kernel module
> > param
From: Nicolas Boichat
ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.
The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane c
Support optional feature: bypass GPIO.
Get GPIO status in irq handler. If GPIO is active, mode_fixup would be
bypassed.
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/bridge/analogix-anx7688.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/bridge/a
From: Kevin Tang
Adds drm support for the Unisoc's display subsystem.
This is drm device and gem driver. This driver provides support for the
Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
Cc: Orson Zhai
Cc: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
dr
On Mon, Dec 9, 2019 at 7:05 AM Tomi Valkeinen wrote:
>
> 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 artif
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
.../bindings/display/bridge/ite,it6505.yaml| 99 ++
1 file changed, 99 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ite,it6505.
From: Kevin Tang
This is a generic mipi dsi panel driver, All the parameters related
to lcd panel, we are placed in the DTS to configure,
for example，lcd display timing, dpi parameter and more.
Cc: Orson Zhai
Cc: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sp
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.
Signed-off-by: Hsin-Yi Wang
---
.../bindings/display/bridge/anx7688.txt | 40 ++-
1 file changed, 3
syzbot has bisected this bug to:
commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
Author: Russell Currey
Date: Mon Feb 8 04:08:20 2016 +
powerpc/powernv: Remove support for p5ioc2
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13ea0aeae0
start commit: 9455d25f Merg
From: Kevin Tang
Adds generic MIPI panel support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/panel.txt | 110 +
1 file changed, 110 insertions(+)
create mode 1006
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: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/
From: Kevin Tang
Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../devicetree/bindings/display/sprd/dphy.txt | 49
.../devicetree/bindings/display/spr
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.
Cc: Orson Zhai
Cc: Baolin Wang
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sprd/Makefile |6
Hello,
syzbot found the following crash on:
HEAD commit:6cf8298d Add linux-next specific files for 20191209
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=168bbb7ae0
kernel config: https://syzkaller.appspot.com/x/.config?x=682fc0ce6c86e3c7
dashboard
1 - 100 of 336 matches
Mail list logo
