Hi Jani,
> On Dec 24, 2019, at 16:42, Kai-Heng Feng wrote:
>
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_d
syzbot has found a reproducer for the following crash on:
HEAD commit:c79f46a2 Linux 5.5-rc5
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=131bcee1e0
kernel config: https://syzkaller.appspot.com/x/.config?x=42c82694f792b2f5
dashboard link: https://syz
On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote:
> - Linux use of tiler aligned to 128 bytes
which is presumably a simplification of the alignment imposed by hardware:
- 64 bytes (64 pixels) for 8bpp
- 128 bytes (64 pixels) for 16bpp
- 128 bytes (32 pixels) for 32bpp
> - Fast user
Am Montag, 6. Januar 2020, 19:17:31 CET schrieb Sam Ravnborg:
> The reg property in the example caused following warnings:
>
> xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format):
> /example-0/dsi@ff45/panel@0:reg: property has invalid length (4 bytes)
> (#address-cells == 2, #size
LANE_CTRL register in latest version of DSI controller (v2.2)
has additional functionality introduced to enable/disable HS
signalling with default value set to enabled. To accommodate this
change, LANE_CTRL register should be read and bit wise ORed to enable
non continuous clock mode. Without this
fb_deferred_io_work() can access the vmbus ringbuffer by calling
fbdefio->deferred_io() -> synthvid_deferred_io() -> synthvid_update().
Because the vmbus ringbuffer is inaccessible between hvfb_suspend()
and hvfb_resume(), we must cancel info->deferred_work before calling
vmbus_close() and then re
Allow DisplayPort PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The configuration structure is used for reconfiguration of
DisplayPort PHYs during link training operation.
The parameters added here are the ones defined in the DisplayPort
Replace the use of IS_ERR and PTR_ZERO macros by returning the
PTR_ERR_OR_ZERO macro.
Changes suggested by coccinelle.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 4 +---
drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 4 +---
drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.
> From: Michael Kelley
> Sent: Monday, December 9, 2019 8:33 AM
> To: Wei Hu ; b.zolnier...@samsung.com; KY
> Srinivasan ; Haiyang Zhang ;
> Stephen Hemminger ; sas...@kernel.org;
> h...@lst.de; m.szyprow...@samsung.com; mchehab+sams...@kernel.org;
> s...@ravnborg.org; gre...@linuxfoundation.org;
On Mon, Jan 06, 2020 at 01:22:40PM +0100, Yuti Amonkar wrote:
> Allow DisplayPort PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
> The configuration structure is used for reconfiguration of
> DisplayPort PHYs during link training operati
On 04.01.2020 19:12, Sam Ravnborg wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Claudiu
>
> On Thu, Jan 02, 2020 at 10:08:48AM +0100, Sam Ravnborg wrote:
>> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
>>> From:
On 02.01.2020 11:08, Sam Ravnborg wrote:
> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
>> From: Peter Rosin
>>
>> The intention was to only select a higher pixel-clock rate than the
>> requested, if a slight overclocking would result in a rate significantly
>> closer to the
Hi Sam,
Sam Ravnborg wrote on Thu, 2 Jan 2020 18:27:00 +0100:
> Hi Miquel
>
> On Tue, Dec 24, 2019 at 03:21:34PM +0100, Miquel Raynal wrote:
> > The panel common bindings provide a gpios-reset property. Let's
> > support it in the simple driver.
> >
> > Two fields are added to the panel descri
Satoz is a Chinese TFT manufacturer.
Website: http://www.sat-sz.com/English/index.html
Signed-off-by: Miquel Raynal
Acked-by: Rob Herring
---
Changes since v3:
* None.
Changes since v2:
* None.
Changes since v1:
* Added Rob's Ack.
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 +
Add support for the Satoz SAT050AT40H12R2 panel.
Signed-off-by: Miquel Raynal
---
Changes since v3:
* Added connector type.
Changes since v2:
* Dropped two uneeded lines which would fail the build.
Changes since v1:
* Switched to display_timing's instead of display_mode.
drivers/gpu/drm/pane
Hi Heiko,
Heiko Stübner wrote on Mon, 06 Jan 2020 12:09:19
+0100:
> Am Sonntag, 5. Januar 2020, 15:05:26 CET schrieb Heiko Stuebner:
> > Am Dienstag, 24. Dezember 2019, 15:38:49 CET schrieb Miquel Raynal:
> > > Hello,
> > >
> > > This series aims at supporting LVDS on PX30.
> > >
> > > A fir
Satoz is a Chinese TFT manufacturer.
Website: http://www.sat-sz.com/English/index.html
Add (simple) bindings for its SAT050AT40H12R2 5.0 inch LCD panel.
Signed-off-by: Miquel Raynal
---
Changes since v3:
* Added the missing ".yaml" suffix in the $id.
* Removed the unnecessary "contains" asserti
Hi Rob,
Rob Herring wrote on Fri, 3 Jan 2020 17:09:57 -0700:
> On Tue, Dec 24, 2019 at 03:19:04PM +0100, Miquel Raynal wrote:
> > Satoz is a Chinese TFT manufacturer.
> > Website: http://www.sat-sz.com/English/index.html
> >
> > Add (simple) bindings for its SAT050AT40H12R2 5.0 inch LCD panel.
Am 03.01.2020 um 06:46 schrieb Vasily Khoruzhick:
On Wed, Jan 1, 2020 at 2:39 AM Qiang Yu wrote:
drm_sched_job_timedout works with drm_sched_stop as a pair,
so we'd better use the drm_sched_fault helper to make the
error and timeout handling go the same path.
This also fixes application hang w
On Mon, Jan 06, 2020 at 01:57:42PM +0100, Thomas Zimmermann wrote:
> This change makes information about VRAM consumption available on
> debugfs. See
>
> /sys/kernel/debug/dri/0/vram-mm
>
> for an overview of how VRAM is being used.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel V
On Mon, Jan 06, 2020 at 01:57:43PM +0100, Thomas Zimmermann wrote:
> The flag 'interruptible', which is passed to various functions,
> is always set to be false. Remove it and hard-code the value.
>
> Signed-off-by: Thomas Zimmermann
> Suggested-by: Daniel Vetter
> Reviewed-by: Daniel Vetter
>
On Mon, Jan 06, 2020 at 01:57:44PM +0100, Thomas Zimmermann wrote:
> TTM is an implementation detail of the VRAM helpers and therefore
> shouldn't be exposed to the callers. There's only one correct value
> for the BO device anyway, which is the one stored in the DRM device.
>
> So remove struct t
On Mon, Jan 06, 2020 at 01:57:45PM +0100, Thomas Zimmermann wrote:
> Drivers that what to allocate VRAM GEM objects with additional fields
> can now do this by implementing struct drm_driver.gem_create_object.
>
> v3:
> * separately check allocation failure in if/else branches
> befo
Hi Boris,
Sorry, for the late reply, I've just got back from my prolonged Chrismas
holidays.
On 27.12.2019 15:41, Boris Brezillon wrote:
> Commit 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
> list") patched the bridge chain logic to use a double-linked list instead
> of a si
On 06/01/2020 15:34, Neil Armstrong wrote:
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
>
> In order to support that, we need drm bridges to fully take part in the
>
The MFD parts for testing:
The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-drm-v5.6
for you to fetch changes
On Wed, 18 Dec 2019, Claudiu Beznea wrote:
> For HLCDC timing engine configurations bit ATMEL_HLCDC_SIP of
> ATMEL_HLCDC_SR needs to be polled before applying new config. In case of
> timeout there is no indicator about this, so, return in case of timeout
> and also print a message about this.
>
On Thu, 21 Nov 2019, Tony Lindgren wrote:
> Hi,
>
> * Jean-Jacques Hiblot [700101 00:00]:
> > From: Tomi Valkeinen
> >
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW. Multiple
drm_atomic_bridge_chain_check() callers can pass a NULL bridge. Let's
bail out before derefencing the bridge pointer when that happens.
Reported-by: Chris Wilson
Fixes: b86d895524ab ("drm/bridge: Add an ->atomic_check() hook")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_bridge.c | 6
drm-misc-next-2020-01-07:
drm-misc-next for v5.6:
UAPI Changes:
- Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n.
Cross-subsystem Changes:
- fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST.
- Use devm_platform_ioremap_resource in fbdev drivers.
- Vario
Hi,
On Mon, Jan 06, 2020 at 05:00:52PM +0300, Wambui Karuga wrote:
> Replace the use of IS_ERR and PTR_ZERO macros by returning the
> PTR_ERR_OR_ZERO macro.
> Changes suggested by coccinelle.
>
> Signed-off-by: Wambui Karuga
Unfortunately, that patch came up a number of time and shouldn't have
b
Hi Sam,
On Mon, Jan 6, 2020 at 6:08 PM Sam Ravnborg wrote:
> > > On Thu, Jan 02, 2020 at 03:12:46PM +0100, Geert Uytterhoeven wrote:
> > > > Add support for the Okaya RH128128T display to the st7735r driver.
> > > >
> > > > The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix
> > > >
On Thu, Jan 02, 2020 at 11:17:10AM +0100, Sam Ravnborg wrote:
> This patchset introduces two files:
>
> panel-simple.yaml
> panel-simple-dsi.yaml
>
> The two files will be used for bindings for simple
> panels that have only a single power-supply.
>
> For now only a few bindings are migr
Hi Boris,
Thank you for the patch.
On Tue, Jan 07, 2020 at 12:30:31PM +0100, Boris Brezillon wrote:
> drm_atomic_bridge_chain_check() callers can pass a NULL bridge. Let's
> bail out before derefencing the bridge pointer when that happens.
>
> Reported-by: Chris Wilson
> Fixes: b86d895524ab ("d
Hi
Am 07.01.20 um 12:36 schrieb tang pengchuan:
> Hi Thomas,
> Our soc needs to support both cma and iommu, but our iommu is not ready
> for upload, so i remove it from sprd_gem.c
> So can i upload the cma code first？ and add iommu support later
This might be possible, but I cannot make the decis
Quoting Laurent Pinchart (2020-01-07 12:15:47)
> Hi Boris,
>
> Thank you for the patch.
>
> On Tue, Jan 07, 2020 at 12:30:31PM +0100, Boris Brezillon wrote:
> > drm_atomic_bridge_chain_check() callers can pass a NULL bridge. Let's
> > bail out before derefencing the bridge pointer when that happe
Hi David,
On Mon, Jan 6, 2020 at 6:12 PM David Lechner wrote:
> On 1/6/20 3:28 AM, Geert Uytterhoeven wrote:
> > On Sun, Jan 5, 2020 at 10:13 AM Sam Ravnborg wrote:
> >> On Thu, Jan 02, 2020 at 03:12:46PM +0100, Geert Uytterhoeven wrote:
> >>> Add support for the Okaya RH128128T display to the s
Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
a écrit :
>
> Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> a écrit :
> >
> > Le mer. 4 déc. 2019 à 17:47, Jani Nikula a
> > écrit :
> > >
> > > On Thu, 28 Nov 2019, Benjamin Gaignard wrote:
> > > > Fix the warnings that show up with W=1.
> >
Le mer. 11 déc. 2019 à 10:20, Benjamin Gaignard
a écrit :
>
> Some variables are set but never used. To avoid warning when compiling
> with W=1 and keep the algorithm like it is tag theses variables
> with _maybe_unused macro.
Gentle ping.
Thanks,
Benjamin
>
> Signed-off-by: Benjamin Gaignard
>
Hi
Am 10.12.19 um 11:24 schrieb Benjamin Gaignard:
> Some variables are set but never used. To avoid warning when compiling
> with W=1 and keep the algorithm like it is tag theses variables
> with _maybe_unused macro.
>
> Signed-off-by: Benjamin Gaignard
Acked-by: Thomas Zimmermann
> ---
> ch
On 05/01/2020 22:37, Tony Lindgren wrote:
Hi,
* Tony Lindgren [200104 05:51]:
Just changing the alingment fixes the issue. Looks like the minimum
alignment we currently allow is 128, I think 512 was the minimum
that worked for me, so maybe the right fix would be to just change
the minimum to
On 07/01/2020 15:30, Tomi Valkeinen wrote:
On 05/01/2020 22:37, Tony Lindgren wrote:
Hi,
* Tony Lindgren [200104 05:51]:
Just changing the alingment fixes the issue. Looks like the minimum
alignment we currently allow is 128, I think 512 was the minimum
that worked for me, so maybe the right
Hi Marek,
On Tue, 7 Jan 2020 10:11:43 +0100
Marek Szyprowski wrote:
> Hi Boris,
>
> Sorry, for the late reply, I've just got back from my prolonged Chrismas
> holidays.
>
> On 27.12.2019 15:41, Boris Brezillon wrote:
> > Commit 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
On Thu, Dec 19, 2019 at 5:20 PM Maxime Ripard wrote:
>
> The backend needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one reques
On Thu, Dec 19, 2019 at 5:20 PM Maxime Ripard wrote:
>
> The DRC needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one requested
Hi!
> > * Jean-Jacques Hiblot [700101 00:00]:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backl
Quoting YueHaibing (2020-01-07 13:50:14)
> Fix build error:
> ./drivers/gpu/drm/i915/selftests/i915_random.h: In function
> i915_prandom_u32_max_state:
> ./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error:
> implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div?
> [
Quoting YueHaibing (2020-01-07 13:50:14)
> Fix build error:
> ./drivers/gpu/drm/i915/selftests/i915_random.h: In function
> i915_prandom_u32_max_state:
> ./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error:
> implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div?
> [
-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by
On Thu, Dec 19, 2019 at 5:20 PM Maxime Ripard wrote:
>
> The DRC needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one requested
On 27.12.2019 15:41, Boris Brezillon wrote:
> Commit 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
> list") patched the bridge chain logic to use a double-linked list instead
> of a single-linked list. This change induced changes to the Exynos driver
> which was manually resettin
On Tue, 07 Jan 2020, Pavel Machek wrote:
> Hi!
>
> > > * Jean-Jacques Hiblot [700101 00:00]:
> > > > From: Tomi Valkeinen
> > > >
> > > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > > pwm_bl except the driver uses a LED class driver to adjust the
> > > > brightne
Hi,
On Mon, Jan 06, 2020 at 03:34:06PM +0100, Neil Armstrong wrote:
> From: Boris Brezillon
>
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This pat
On Tue, Jan 07, 2020 at 03:01:13PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> In commit 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK
> to 1.") it was assumed that all TCON variants support a minimum divider
> of 1 if only DCLK was used.
>
> However, the oldest generation
On 27.12.2019 15:41, Boris Brezillon wrote:
> Commit 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked
> list") patched the bridge chain logic to use a double-linked list instead
> of a single-linked list. This change induced changes to the VC4 driver
> which was manually resetting t
On Tue, Jan 7, 2020 at 12:50 PM Maarten Lankhorst
wrote:
>
> drm-misc-next-2020-01-07:
> drm-misc-next for v5.6:
>
> UAPI Changes:
> - Allow overriding number of bootup penguins in fbcon using
> fbcon=logo-count:n.
>
> Cross-subsystem Changes:
> - fbdev fixes for mmp, and make it work with CONFIG
On 06.01.2020 11:29, Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Fri, Dec 27, 2019 at 03:41:22PM +0100, Boris Brezillon wrote:
>> Stop iterating on the bridge chain when we reach the bridge element.
>> That's what other helpers do and should allow bridge implementations
On Tue, 7 Jan 2020 16:27:10 +0100
Andrzej Hajda wrote:
> On 06.01.2020 11:29, Laurent Pinchart wrote:
> > Hi Boris,
> >
> > Thank you for the patch.
> >
> > On Fri, Dec 27, 2019 at 03:41:22PM +0100, Boris Brezillon wrote:
> >> Stop iterating on the bridge chain when we reach the bridge element.
Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg a écrit :
>
> There is an increasing number of new simple panels.
> Common for many of these simple panels are that they have one
> mandatory power-supply and some of them have backlight and / or
> an enable gpio.
>
> The binding file to describe these pa
On Mon, Dec 23, 2019 at 11:00:15AM +0200, Pekka Paalanen wrote:
> On Thu, 19 Dec 2019 13:42:33 +0100
> Daniel Vetter wrote:
>
> > On Thu, Dec 19, 2019 at 12:32 PM Gerd Hoffmann wrote:
> > >
> > > While being at it: How would a driver cleanup properly cleanup gem
> > > objects created by userspa
Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg a écrit :
>
> To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> panel-simple-dsi-yaml are for all simple DSP panels with a single
> power-supply and optional backlight / enable GPIO.
>
> Migrate panasonic,vvx10f034n00 over to the new file.
On Mon, Dec 23, 2019 at 02:31:01AM -0800, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit e3933f26b657c341055443103bad331f4537b113
> Author: Rex Zhu
> Date: Tue Jan 16 10:35:15 2018 +
>
> drm/amd/pp: Add edit/commit/show OD clock/voltage support in sysfs
Pretty sure you do
On Mon, Dec 30, 2019 at 02:27:34PM +0100, Geert Uytterhoeven wrote:
> When userspace requests a video mode parameter value that is not
> supported, frame buffer device drivers should round it up to a supported
> value, if possible, instead of just rejecting it. This allows
> applications to quickl
On Thu, Jan 02, 2020 at 11:15:19PM +0100, Sam Ravnborg wrote:
> Document the remaining DRM_ logging functions.
> As the logging functions are now all properly
> listed drop the few specific kernel-doc markers
> so we keep the relevant parts in the documentation.
>
> Signed-off-by: Sam Ravnborg
>
This reverts commit b18398c16e176513502f962b642f89225039ef1f.
---
drivers/gpu/drm/drm_bridge.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 32d43bfeeca1..37400607e9b7 100644
--- a/drivers/gpu/drm/drm_brid
This reverts commit f7619a58ef9299c42a604ede063bb6e5b88098fb.
---
.../drm/bridge/analogix/analogix_dp_core.c| 41 ++---
drivers/gpu/drm/drm_bridge.c | 61 ---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +--
include/drm/drm_bridge.h
This reverts commit b86d895524ab7281da8ca788e3666ab622fc8620.
---
drivers/gpu/drm/drm_atomic_helper.c | 12 +++---
drivers/gpu/drm/drm_bridge.c| 62 -
include/drm/drm_bridge.h| 29 +-
3 files changed, 7 insertions(+), 96 deletions(-)
dif
Hello,
The introduction of bridge_state introduced a circular dep between
drm.ko and drm_kms_helper.ko which releaved a misdesign in how the whole
thing was implemented. Let's revert all patches for now.
Regards,
Boris
Boris Brezillon (5):
Revert "drm/bridge: Fix a NULL pointer dereference in
This reverts commit 6ed7e9625fa6a6ee8230945820544767ed5799c4.
---
drivers/gpu/drm/drm_atomic.c| 39
drivers/gpu/drm/drm_atomic_helper.c | 20
drivers/gpu/drm/drm_bridge.c| 139 ++--
include/drm/drm_atomic.h| 3 -
include/drm/drm
On Thu, Jan 02, 2020 at 11:15:18PM +0100, Sam Ravnborg wrote:
> This is the documentation I have missed when I looked for help
> how to do proper logging. Hopefully it can help others.
>
> v2:
> - Add parameters to the logging functions in the doc
> - Drop notes on other types of logging
>
>
This reverts commit e351e4d5eaec713b2d4780c79f68702e88f2a212.
---
drivers/gpu/drm/drm_bridge.c | 267 +--
include/drm/drm_bridge.h | 124
2 files changed, 1 insertion(+), 390 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/
On Sat, Jan 04, 2020 at 09:43:31PM +0100, Julia Lawall wrote:
> From: kbuild test robot
>
> Remove dev_err() messages after platform_get_irq*() failures.
> Line 450 is redundant because platform_get_irq() already prints
> an error.
>
> Generated by: scripts/coccinelle/api/platform_get_irq.cocci
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
Hi,
The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.
It seems there is nothing really stopping all of them to take
pointer to const.
Patchset was really tested on all affected architectures.
Build testing is in progress -
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
On Tue, Jan 7, 2020 at 9:44 AM Benjamin Gaignard
wrote:
>
> Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg a écrit :
> >
> > To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> > panel-simple-dsi-yaml are for all simple DSP panels with a single
> > power-supply and optional backlight / e
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski wrote:
>
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be
On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard wrote:
>
> The DRC needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one requested a
On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard wrote:
>
> The backend needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one request
Hi Daniel.
> > + * Logging when a &device * is available, but no &drm_device *
> > + *
> > ~
> > + *
> > + * DRM/Drivers can use the following functions for logging when there is a
> > + * struct device * available.
> > +
Hi Maarten.
On Tue, Jan 07, 2020 at 10:17:48AM +, Lee Jones wrote:
> The MFD parts for testing:
>
> The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
>
> Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
>
> are available in the Git repository at:
>
> git://git.kerne
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162, v4.9.208,
v4.4.208.
v5.4.8: Failed to apply! Possible
On 06/01/2020 14:22, Yuti Amonkar wrote:
> Allow DisplayPort PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
> The configuration structure is used for reconfiguration of
> DisplayPort PHYs during link training operation.
>
> The paramete
On Tue, Dec 31, 2019 at 03:30:47AM +, Lin, Wayne wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> >
> > From: Jani Nikula
> > Sent: Monday, December 30, 2019 19:15
> > To: Lin, Wayne; dri-devel@lists.freedesktop.org;
> > amd-...@lists
This reverts commit f7619a58ef92 ("drm/bridge: Patch atomic hooks to
take a drm_bridge_state"). Commit 6ed7e9625fa6 ("drm/bridge: Add a
drm_bridge_state object") introduced a circular dependency between
drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the
whole thing was implemented.
This reverts commit b86d895524ab ("drm/bridge: Add an ->atomic_check()
hook"). Commit 6ed7e9625fa6 ("drm/bridge: Add a drm_bridge_state
object") introduced a circular dependency between drm.ko and
drm_kms_helper.ko which uncovered a misdesign in how the whole thing
was implemented. Let's revert all
1 - 100 of 168 matches
Mail list logo
