From: dillon min
Add documentation for "ilitek,ili9341" panel.
Signed-off-by: dillon min
---
Changes:
V3:
change compatible to st,sf-tc240t-9370-t, match #vendor,#lcd_module style
V2:
verifyied with make dt_binding_check
V1:
none
.../bindings/display/panel/ilitek,ili9341.yaml
The Energy Model framework supports also other devices than CPUs. Update
related information and add description for the new usage.
Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 135 +++
1 file changed, 75 insertions(+), 6
Energy Model framework supports now other devices than CPUs. Refactor some
of the functions in order to prevent wrong usage. The old function
em_pd_energy has to generic name. It must not be used without proper
cpumask pointer, which is possible only for CPU devices. Thus, rename it
and add proper
Devfreq framework can change the device status in the background. To
mitigate this situation make a copy of the status structure and use it
for internal calculations.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 14 ++
1 file changed, 10 insertions(+), 4 deletio
From: dillon min
This patchset has following changes:
V3:
merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
to support serial spi & parallel rgb interface in one driver.
update ilitek,ili9341.yaml dts binding documentation.
update stm32f429-disco dts binding
V
The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration functions which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for coming changes
which are going to replace old power model with the new EM.
Signed-off-by: Lu
On Thu 07 May 14:34 PDT 2020, Douglas Anderson wrote:
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> be used as GPIOs in a system. Each pin can be configured as input,
> output, or a special function for the bridge chip. These are:
> - GPIO1: SUSPEND Input
> - GPIO2:
The current code checks that the whole OOB area is erased.
This is a problem when JFFS2 cleanmarkers are added to the OOB, since it will
fail due to the usable OOB bytes not being 0xff.
Correct this by only checking that data and ECC bytes aren't 0xff.
Fixes: 02b88eea9f9c ("mtd: brcmnand: Add chec
From: dillon min
Currently, we can use tinydrm ili9341 driver to drive ili9341 panel
by spi interface (both register configuration and video)
ili9341 have parallel and mcu interface as well, we extend the
support to parallel rgb interface with DRM_MODE_CONNECTOR_DPI
this driver can work as para
Add now function in the Energy Model framework which is going to support
new devices. This function will help in transition and make it smoother.
For now it still checks if the cpumask is a valid pointer, which will be
removed later when the new structures and infrastructure will be ready.
Acked-b
These patches improve the OOB hamming layout by reducing the number of oob
sections and correctly
v3: invert patch order.
v2: extend original comment and correctly skip byte 6 for small-page.
Álvaro Fernández Rojas (2):
mtd: rawnand: brcmnand: fix hamming oob layout
mtd: rawnand: brcmnand: i
Register devfreq cooling device and attempt to register Energy Model. This
will add the devfreq device to the Energy Model framework. It will create
a dedicated and unified data structures used i.e. in thermal framework.
The last NULL parameter indicates that the power model is simplified and
creat
Change the license headers and use SPDX standard.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 12 ++--
include/linux/devfreq_cooling.h | 12 ++--
2 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/
The Energy Model framework is going to support devices other that CPUs. In
order to make this happen change the callback function and add pointer to
a device as an argument.
Update the related users to use new function and new callback from the
Energy Model.
Signed-off-by: Lukasz Luba
---
drive
Hi all,
This patch set introduces support for devices in the Energy Model (EM)
framework. It will unify the power model for thermal subsystem. It will
make simpler to add support for new devices willing to use more
advanced features (like Intelligent Power Allocation). Now it should
require less k
Add support for other devices that CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been reorganized in order to
keep consistent view (like removing per_cpu pd pointers). To track usage
of the Energy Mod
Remove old function em_register_perf_domain which is no longer needed.
There is em_dev_register_perf_domain that covers old use cases and new as
well.
Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
---
include/linux/energy_model.h | 7 ---
kernel/power/energy_model.c | 25 ---
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale data
and get more up-to-date values of load and frequency.
In addition this patch adds normalization function, which also makes sure
that whatever data comes
First 2 bytes are used in large-page nand.
Fixes: ef5eeea6e911 ("mtd: nand: brcm: switch to mtd_ooblayout_ops")
Cc: sta...@vger.kernel.org
Signed-off-by: Álvaro Fernández Rojas
---
v3: invert patch order
v2: extend original comment
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 11 +++
1
The current code generates 8 oob sections:
S1 1-5
ECC 6-8
S2 9-15
S3 16-21
ECC 22-24
S4 25-31
S5 32-37
ECC 38-40
S6 41-47
S7 48-53
ECC 54-56
S8 57-63
Change it by merging continuous sections:
S1 1-5
ECC 6-8
S2 9-21
ECC 22-24
Thank you Greg for the comments.
On 5/6/2020 2:30 PM, Greg KH wrote:
On Wed, May 06, 2020 at 02:00:10PM +0530, Charan Teja Kalla wrote:
Thank you Greg for the reply.
On 5/5/2020 3:38 PM, Greg KH wrote:
On Tue, Apr 28, 2020 at 01:24:02PM +0530, Charan Teja Reddy wrote:
The following race occ
From: dillon min
as store stm32f4_rcc_register_pll return to the wrong offset of clks,
so ltdc gate clk is null. need change clks[PLL_VCO_SAI] to clks[PLL_SAI]
add CLK_IGNORE_UNUSED for ltdc to make sure clk not be freed by
clk_disable_unused
Signed-off-by: dillon min
---
drivers/clk/clk-stm3
Hello,
syzbot found the following crash on:
HEAD commit:1d3962ae Merge tag 'io_uring-5.7-2020-05-08' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1487425810
kernel config: https://syzkaller.appspot.com/x/.config?x=b0212dbee046bc1f
das
On Thu 07 May 14:35 PDT 2020, Douglas Anderson wrote:
> We don't have the HPD line hooked up to the bridge chip. Add it as
> suggested in the patch ("dt-bindings: drm/bridge: ti-sn65dsi86:
> Document no-hpd").
>
> NOTE: this patch isn't expected to have any effect but just keeps us
> cleaner for
The Energy Model uses concept of performance domain and capacity states in
order to calculate power used by CPUs. Change naming convention from
capacity to performance state would enable wider usage in future, e.g.
upcoming support for other devices other than CPUs.
Acked-by: Daniel Lezcano
Signe
Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed in the next
changes.
Reviewed-by: Steven Rostedt (VMware) # for tracing code
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 3 +--
include/tr
From: dillon min
Enable the ltdc & ili9341 on stm32429-disco board.
Signed-off-by: dillon min
---
Changes:
V3:
change dts binding compatible to "st,sf-tc240t-9370-t"
V2:
none
v1:
none
arch/arm/boot/dts/stm32f429-disco.dts | 39 +++
1 file changed
Remove old power model and use new Energy Model to calculate the power
budget. It drops static + dynamic power calculations and power table
in order to use Energy Model performance domain data. This model
should be easy to use and could find more users. It is also less
complicated to setup the need
The Energy Model framework supports not only CPU devices. Drop the CPU
specific interface with cpumask and add struct device. Add also a return
value, user might use it. This new interface provides easy way to create
a simple Energy Model, which then might be used by e.g. thermal subsystem.
Acked-
From: dillon min
This patch adds the pin configuration for ltdc, spi5 controller
on stm32f429-disco board.
Signed-off-by: dillon min
---
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 67 ++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f4-pinc
Am 11.05.20 um 22:46 schrieb Alex Deucher:
On Mon, May 11, 2020 at 4:41 PM John Paul Adrian Glaubitz
wrote:
On 5/11/20 10:05 PM, Alex Deucher wrote:
For Nouveau I'm not 100% sure, but from the code it of hand looks like we can
do it similar to Radeon.
Please comment what you think about this
On Mon, 11 May 2020 19:47:24 +0200
Hans de Goede wrote:
> From: Rajat Jain
>
> Add support for generic electronic privacy screen properties, that
> can be added by systems that have an integrated EPS.
>
> Changes in v2 (Hans de Goede)
> - Create 2 properties, "privacy-screen sw-state" and
>
On 2020-05-11 10:51 p.m., Alex Deucher wrote:
> On Mon, May 11, 2020 at 4:25 PM Rui Salvaterra wrote:
>> A segunda, 11/05/2020, 21:21, Alex Deucher escreveu:
>>>
>>> Note there is no loss of functionality here, at least on radeon
>>> hardware. It just comes down to which MMU gets used for access
Hi,
On 5/12/20 9:49 AM, Pekka Paalanen wrote:
On Mon, 11 May 2020 19:47:24 +0200
Hans de Goede wrote:
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties
Am 11.05.20 um 22:56 schrieb Al Dunsmuir:
Hello Dave,
On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:
On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
[SNIP]
Maybe we can find some way to compartmentalise AGP further?
Dave.
Significantly reduced caching on memory accesses defin
Hi,
On 5/11/20 10:04 PM, Rajat Jain wrote:
On Mon, May 11, 2020 at 10:47 AM Hans de Goede wrote:
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "pr
On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> On Mon, May 11, 2020 at 1:17 PM Christian König
> wrote:
>>
>> AGP is deprecated for 10+ years now and not used any more on modern hardware.
>>
>> Old hardware should continue to work in PCI mode.
>
> Might want to clarify that there is no loss of f
Hi,
On 5/11/20 9:55 PM, Rajat Jain wrote:
Hi Hans,
On Mon, May 11, 2020 at 10:47 AM Hans de Goede mailto:hdego...@redhat.com>> wrote:
Hi All,
This RFC takes Rajat's earlier patch for adding privacy-screen properties
infra to drm_connector.c and then adds the results of the discuss
The primary plane's format registers are now updated in a
mgag200_set_format_regs().
v2:
* get bpp shift from helper function
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 109 ---
The mode-setting code is now located in mgag200_set_mode_regs(), sans
a few flags that will be moved in a later patch for clarity.
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_mode.c
Registers are initialized with constants. This is now done in
mgag200_init_regs(), mgag200_set_dac_regs() and mgag200_set_pci_regs().
Later patches should move these calls from mode setting to device
initialization.
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann
Tested-by
This patchset converts mgag200 to atomic modesetting. It uses simple
KMS helpers and SHMEM.
Patch 1 removes cursor support. The HW cursor is not usable with the
way universal planes work.
Patches 2 to 11 untangle the existing modesetting code into smaller
functions. Specifically, mode setting and
The function now only takes the device structure, and the old and new
framebuffers.
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a
Set different fields in MISC in their rsp location in the code. This
patch also fixes a bug in the original code where the mode's SYNC flags
were never written into the MISC register.
v2:
* use u8 instead of uint8_t
* define MGAREG_MISC_CLK_SEL_MASK
Signed-off-by: Thomas Zimmerman
The framebuffer's pitch is now set in mgag200_set_offset().
v2:
* move offset and bpp-shift calculation into helper functions
* use u8 instead of uint8_t
* add MGAREG_CRTCEXT0_OFFSET_MASK
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
---
drivers/gpu/drm/mgag
The MGA CRTC data structure struct mga_crtc contains unused additional
fields; so it can removed. The standard DRM CRTC and encoder structures
are embedded now in struct drm_simple_display_pipe. Done in preparation
of converting mgag200 to simple KMS helpers.
Signed-off-by: Thomas Zimmermann
Test
The HW cursor of Matrox G200 cards only supports a 16-color palette
format. Univeral planes require at least ARGB or a similar component-
based format, so remove the HW cursor.
Alternatively, the driver could dither a cursor image from ARGB to
16 colors. But this does not produce pleasent-looking
Setting the plane registers first and the mode registers afterwards
reproduces the sequence used by atomic helpers. Done in preparation
of switching to simple KMS helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_mode.
All register names and fields are now named according to the
MGA programming manuals. The function doesn't need the CRTC, so
callers pass in the device structure directly. The logging now
uses device-specific macros.
v2:
* use to_mga_device()
* use MiB instead of MB
* repla
The mgag200 supports a single pipeline with only a primary plane. It can
be converted to simple KMS helpers. This also adds support for atomic
modesetting. Wayland compositors, which use pageflip ioctls, can now be
used with mgag200.
v2:
* prepare encoder and CRTC in a separate patch
The VRAM helpers managed the framebuffer memory for mgag200. This came
with several problems, as some MGA device require the scanout address
to be located at VRAM offset 0. It's incompatible with the page-flip
semantics of DRM's atomic modesettting. With atomic modesetting, old and
new framebuffers
The suspend/resume helpers are unused. Also remove associated state
from struct mga_device.
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 -
drivers/gpu/drm/mgag200/mgag200_mode.c | 71 --
The hiprivlvl settings are now updated in mgag200_g200se_set_hiprilvl()
and mgag200_g200ev_set_hiprilvl().
v2:
* replace uint8_t with u8
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 98 ++-
The TAGFIFO state is now reset in mgag200_g200er_reset_tagfifo().
v2:
* define MGAREG_SEQ1_SCROFF
Signed-off-by: Thomas Zimmermann
Tested-by: John Donnelly
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 6
drivers/gpu/drm/mgag200/mgag200_mode.c | 45
On Tue, May 12, 2020 at 10:43:18AM +0530, Charan Teja Kalla wrote:
> > Ok, but watch out, now you have 2 different reference counts for the
> > same structure. Keeping them coordinated is almost always an impossible
> > task so you need to only rely on one. If you can't use the file api,
> > just
On Fri, May 08, 2020 at 12:11:03PM +0530, Charan Teja Reddy wrote:
> The following race occurs while accessing the dmabuf object exported as
> file:
> P1P2
> dma_buf_release() dmabuffs_dname()
> [say lsof reading /proc//fd/]
>
>
Dear All,
During the Exynos DRM GEM rework and fixing the issues in the.
drm_prime_sg_to_page_addr_arrays() function [1] I've noticed that most
drivers in DRM framework incorrectly use nents and orig_nents entries of
the struct sg_table.
In case of the most DMA-mapping implementations exchanging
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no exper
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cross-driver
dma_fence rules we might want to be m
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: l
Hi all,
I've dragged my feet for years on this, hoping that cross-release lockdep
would do this for us, but well that never really happened unfortunately.
So here we are.
Cc'ed quite a pile of people since this is about the cross-driver contract
around dma_fences. Which is heavily used for dma_bu
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this is
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] ---
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vge
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
i
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
i915 does tons of allocations from this worker, which lockdep catches.
Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic c
struct sg_table is a common structure used for describing a memory
buffer. It consists of a scatterlist with memory pages and DMA addresses
(sgl entry), as well as the number of scatterlist entries: CPU pages
(orig_nents entry) and DMA mapped pages (nents entry).
It turned out that it was a common
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
struct sg_table is a common structure used for describing a memory
buffer. It consists of a scatterlist with memory pages and DMA addresses
(sgl entry), as well as the number of scatterlist entries: CPU pages
(orig_nents entry) and DMA mapped pages (nents entry).
It turned out that it was a common
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is simple and
easy to understand, so the comment descri
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/20200512085710.14688-1-m.szyprow...@sa
struct sg_table is a common structure used for describing a memory
buffer. It consists of a scatterlist with memory pages and DMA addresses
(sgl entry), as well as the number of scatterlist entries: CPU pages
(orig_nents entry) and DMA mapped pages (nents entry).
It turned out that it was a common
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/20200512085710.14688-1-m.szyprow...@samsung.com/T/
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/20200512085710.14688-1-m.szyprow...@samsung.com/T/
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
It is a common operation done by DRM drivers to check the contiguity
of the DMA-mapped buffer described by a scatterlist in the
sg_table object. Let's add a common helper for this operation.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table n
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/20200512085710.14688-1-m.szyprow...@sa
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
1 - 100 of 189 matches
Mail list logo
