-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
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
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
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
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(-)
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
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
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
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 |
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:
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);
> +
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
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 ++---
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
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
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:
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 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
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
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
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
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
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 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
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
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
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
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
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
---
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
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
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
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"
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
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. 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
---
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
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
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
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:
> >
> >
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':
>
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)
^~~
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':
>
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'
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
-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
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
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
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
---
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
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
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
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
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;
> >
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
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!
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:
>
>
Hi Daniel.
> > + * Logging when a * is available, but no _device *
> > + *
> > ~
> > + *
> > + * DRM/Drivers can use the following functions for logging when there is a
> > + * struct device * available.
> > + * The
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
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
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 /
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 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 -
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
1 - 100 of 168 matches
Mail list logo
