-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout f2d51786363ee2a72c55570835e4c79066af2782
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by
Hi all,
Today's linux-next merge of the generic-ioremap tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_gtt.c
between commit:
2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")
from the drm-intel tree and commit:
4bdc0d676a64 ("remove ioremap_nocache and devm_ioremap_nocache")
We accidentally set "psb" which is a no-op instead of "*psb" so it
generates a static checker warning. We should probably set it before
the first error return so that it's always initialized.
Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support")
Signed-off-by: Dan Carpenter
We moved this code to a different file and accidentally deleted a
newline.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/drm_lock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 2e8ce99d0baa..2c79e8199e3c 10
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_device.c | 21 +
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 22
When there is a single power domain per device, the core will
ensure the power domains are all switched on.
However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.
Signed-off-by: Nicolas Boichat
---
The downstream driver we use on chromeos-4.19 c
It is useful to know which component cannot be powered on.
Signed-off-by: Nicolas Boichat
---
Was useful when trying to probe bifrost GPU, to understand what
issue we are facing.
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
Hi!
Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.
The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could probe the GPU, to check that the
binding is inde
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 48e3c4165247cea..f
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
The evb part of this change depe
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.
Signed-off-by: Nicolas Boichat
---
.../bindings/gpu/arm,mali-bifrost.yaml | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.ya
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.
TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18
Hi
Am 08.01.20 um 03:25 schrieb Rong Chen:
> Hi Thomas,
>
> The previous throughput was reduced from 43955 to 35691, and there is a
> little increase in next-20200106,
> but there is no obvious change after the patchset:
OK, I would have hoped for some improvements. Anyway, thanks for testing.
amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 [1794/2680]
drm/amdkcl/autoconf: generate config.h for in-tree build
config: x86_64-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
gi
[AMD Public Use]
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, January 8, 2020 2:57 AM
> To: Lin, Wayne
> Cc: Jani Nikula ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Zuo, Jerry
> ; Kazlauskas, Nicholas
>
> Subject: Re: [PATCH] drm/dp_mst: corre
Hi all,
On Wed, 8 Jan 2020 12:04:50 +1100 Stephen Rothwell
wrote:
>
> -hw_flags = 0;
> +/* For resource streamer on HSW+ and power context elsewhere */
> +BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
> +BUILD_BUG_ON(HSW_MI_RS_
Hi Thomas,
The previous throughput was reduced from 43955 to 35691, and there is a little
increase in next-20200106,
but there is no obvious change after the patchset:
commit:
f1f8555dfb ("drm/bochs: Use shadow buffer for bochs framebuffer console")
90f479ae51 ("drm/mgag200: Replace struc
From: Rob Clark
Since zap firmware can be device specific, allow for a firmware-name
property in the zap node to specify which firmware to load, similarly to
the scheme used for dsp/wifi/etc.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
1
From: Rob Clark
For devices which use zap fw to take the GPU out of secure mode on
reset, the firmware is likely to be signed with a device specific key.
Meaning that we can't have a single filesystem (or /lib/firmware) that
works on multiple devices.
So allow a firmware-name to be specified in
From: Rob Clark
We want to specify per-device firmware-name, so move the zap node into
the .dts file for individual boards/devices. This lets us get rid of
the /delete-node/ for cheza, which does not use zap.
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi |
From: Rob Clark
The firmware-name property in the zap node can be used to specify a
device specific zap firmware.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_display.c
between commit:
2b2c4a83d69d ("drm/i915/dp: Disable Port sync mode correctly on teardown")
from the drm-intel-fixes tree and commit:
773b4b54351c ("drm/i915: Move stuff from
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
ce69e553b9a4 ("drm/i915/gt: Restore coarse power gating")
from the drm-intel-fixes tree and commit:
90eb7d2aa3ce ("drm/i915: Simplify NEEDS_WaRsDisableCoarsePowerGating")
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_ring_submission.c
between commit:
103309977589 ("drm/i915/gt: Do not restore invalid RS state")
from the drm-intel-fixes tree and commit:
3cd6e8860ecd ("drm/i915/gen7: Re-enable full-ppgtt
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_f
Hi Yifan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2680] drm/amdkcl: Test
whether drm_encoder_init() wants name
config: i386-allyes
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:
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
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
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
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_
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
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
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
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
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
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
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-
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,
The "track FOLL_PIN pages" would have been the very next patch, but it is
not included here because I'm still debugging a bug report from Leon.
Let's get all of the prerequisite work (it's been reviewed) into the tree
so that future reviews are easier. It's clear that any fixes that are
requir
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
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page().
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff -
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
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
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 set_page_
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
https://bugzilla.kernel.org/show_bug.cgi?id=204559
--- Comment #14 from the...@gmail.com ---
i have not seen the oops on a 5.3.x kernel (ubuntu eoan), even without tweaking
the runpm setting (again, only saw it a few times on an earlier kernel).
--
You are receiving this mail because:
You are wa
On Tue, Jan 7, 2020 at 11:12 PM Laurent Pinchart
wrote:
> On Tue, Jan 07, 2020 at 11:09:13PM +0100, Arnd Bergmann wrote:
> > On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart wrote:
> > > Isn't this something that should be fixed at the compiler level ?
> >
> > I suspect but have not verified that
Hi Arnd,
On Tue, Jan 07, 2020 at 11:09:13PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart wrote:
> > On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> > > With gcc -O3, the compiler can inline very aggressively,
> > > leading to rather large stack us
On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart
wrote:
>
> Hi Arnd,
>
> Thank you for the patch.
>
> On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> > With gcc -O3, the compiler can inline very aggressively,
> > leading to rather large stack usage:
> >
> > drivers/gpu/drm/panel/p
Hi Arnd,
Thank you for the patch.
On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> With gcc -O3, the compiler can inline very aggressively,
> leading to rather large stack usage:
>
> drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function
> 'td028ttec1_prepare':
> drivers/gpu/
Without this, we get a couple of warnings when CONFIG_PM
is disabled:
drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12: error:
'komeda_rt_pm_resume' defined but not used [-Werror=unused-function]
static int komeda_rt_pm_resume(struct device *dev)
^~~
drivers/gpu
Hi Arnd,
Thank you for the patch.
On Tue, Jan 07, 2020 at 10:37:32PM +0100, Arnd Bergmann wrote:
> The new dummy helper is non-static, so every driver gets
> its own copy, leading to a link failure:
>
> drivers/gpu/drm/imx/imx-ldb.o: In function
> `drm_of_lvds_get_dual_link_pixel_order':
> imx-
Casting a pointer to dma_addr_t produces a warning:
drivers/gpu/drm/meson/meson_rdma.c: In function 'meson_rdma_free':
drivers/gpu/drm/meson/meson_rdma.c:59:25: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
priv->rdma.addr_phys = (dma_addr_t)NULL;
In this
The new dummy helper is non-static, so every driver gets
its own copy, leading to a link failure:
drivers/gpu/drm/imx/imx-ldb.o: In function
`drm_of_lvds_get_dual_link_pixel_order':
imx-ldb.c:(.text+0x140): multiple definition of
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/imx/imx-dr
With gcc -O3, the compiler can inline very aggressively,
leading to rather large stack usage:
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 'td028ttec1_prepare':
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of
2768 bytes is larger than 2048 bytes [-Werror=
-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
Making this IS_REACHABLE() was still wrong, as that just determines
whether the lower-level backlight code would be reachable from the panel
driver. However, with CONFIG_DRM=y and CONFIG_BACKLIGHT_CLASS_DEVICE=m,
the drm_panel_of_backlight is left out of drm_panel.o but the condition
tells the driv
With the db845c running AOSP, I see the following error on every
frame on the home screen:
[drm:dpu_plane_atomic_check:915] [dpu error]plane33 invalid src
2880x1620+0+470 line:2560
This is due to the error paths in atomic_check using
DPU_ERROR_PLANE(), and the drm_hwcomposer using atomic_check
On Thu, Jan 2, 2020 at 4:17 AM Sam Ravnborg wrote:
>
> 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 Thu, Jan 2, 2020 at 4:17 AM Sam Ravnborg wrote:
>
> 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 pane
This reverts commit 6ed7e9625fa6 ("drm/bridge: Add a drm_bridge_state
object") which introduced a circular dependency between drm.ko and
drm_kms_helper.ko. Looks like the helper/core split is not appropriate
and fixing that is not simple.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_at
This reverts commit b18398c16e17 ("drm/bridge: Fix a NULL pointer
dereference in drm_atomic_bridge_chain_check()"). 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 th
This reverts commit e351e4d5eaec ("drm/bridge: Add the necessary bits
to support bus format negotiation"). 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 i
Hello
Sorry for the noise. I realize the v1 didn't contain any explanation
about why those commits were reverted and were missing my SoB.
The addition of a bridge_state object introduced a circular dependency
between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how
the whole thing
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
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
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
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
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 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.
> > +
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
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 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 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
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
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 -
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
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 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
1 - 100 of 168 matches
Mail list logo
