Hi, YueHaibing:
Chun-Kuang Hu 於 2020年4月29日 週三 下午10:15寫道：
>
> Hi, YueHaibing:
>
> YueHaibing 於 2020年4月29日 週三 下午3:14寫道：
> >
> > WARNING: unmet direct dependencies detected for MTK_MMSYS
> > Depends on [n]: (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) &&
> > COMMON_CLK_MT8173_MMSYS [=n]
> >
Hi, Anand,
Chun-Kuang Hu 於 2020年4月29日 週三 上午12:37寫道：
>
> Hi, Anand,
>
> Anand K. Mistry 於 2020年4月28日 週二 上午9:54寫道：
> >
> > On Sun, 26 Apr 2020 at 18:04, Chun-Kuang Hu wrote:
> > >
> > > Hi, Anand:
> > >
> > > Anand K Mistry 於 2020年4月20日 週一 下午2:09寫道：
> > > >
> > > > If dma_map_sg() merges pages
Hi,
On Tue, May 5, 2020 at 2:24 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart
> wrote:
> >
> > > I'll add this documentation into the comments of the yaml, but I'm not
> > > going to try to implement enforcement at the yaml level.
> >
> > Why not ? :-)
>
>
Laurent,
On Tue, May 5, 2020 at 2:35 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> Thank you for the patch.
>
> On Thu, Apr 30, 2020 at 12:46:15PM -0700, Douglas Anderson wrote:
> > This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> > Unless there's someone known to be better,
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:16PM -0700, Douglas Anderson wrote:
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
> HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
> because of excessive debouncing in hardware.
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:13PM -0700, Douglas Anderson wrote:
> In the cases where there is no connector in a system there's no great
> place to put "hpd-gpios". As per discussion [1] the best place to put
> it is in the panel. Add this to the device tree
Hi Doug,
Thank you for the patch.
On Thu, Apr 30, 2020 at 12:46:15PM -0700, Douglas Anderson wrote:
> This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> Unless there's someone known to be better, I've set the maintainer in
> the yaml as the first person to submit bindings.
>
Hi,
On Tue, May 5, 2020 at 2:21 PM Sam Ravnborg wrote:
>
> Hi Dough.
>
> > >
> > > If we don't want to test that, I would at least document it in the DT
> > > bindings. It will be a good occasion to switch the bindings to YAML ;-)
> >
> > Interesting that you bring this up. Conversion to yaml
Hi,
On Tue, May 5, 2020 at 2:14 PM Laurent Pinchart
wrote:
>
> > I'll add this documentation into the comments of the yaml, but I'm not
> > going to try to implement enforcement at the yaml level.
>
> Why not ? :-)
Because trying to describe anything in the yaml bindings that doesn't
fit in the
Hi Dough.
> >
> > If we don't want to test that, I would at least document it in the DT
> > bindings. It will be a good occasion to switch the bindings to YAML ;-)
>
> Interesting that you bring this up. Conversion to yaml is sitting
> waiting to land (or additional review comments):
>
>
Hi Doug,
On Tue, May 05, 2020 at 02:12:20PM -0700, Doug Anderson wrote:
> On Tue, May 5, 2020 at 2:06 PM Laurent Pinchart wrote:
> > On Tue, May 05, 2020 at 10:59:30AM -0700, Doug Anderson wrote:
> >> On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart wrote:
> >>> On Mon, May 04, 2020 at 09:36:31PM
Hi,
On Tue, May 5, 2020 at 2:06 PM Laurent Pinchart
wrote:
>
> Hi Doug,
>
> On Tue, May 05, 2020 at 10:59:30AM -0700, Doug Anderson wrote:
> > On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart wrote:
> > > On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> > > > The ti-sn65dsi86
Hi Doug,
On Tue, May 05, 2020 at 10:59:30AM -0700, Doug Anderson wrote:
> On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart wrote:
> > On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> > > The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> > > remapping of eDP lanes
Hi Sam
On Tue, May 5, 2020 at 10:03 PM Sam Ravnborg wrote:
>
> Hi Artem.
>
> On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> > Hello all
> >
> > I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> > controller [1]. I have already implemented a POC
On Thu, 23 Apr 2020 21:03:36 +0530, Kiran Gunda wrote:
> Add WLED5 specific bindings.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> Acked-by: Daniel Thompson
> ---
> .../bindings/leds/backlight/qcom-wled.yaml | 59
> --
> 1 file
On Thu, 23 Apr 2020 21:03:34 +0530, Kiran Gunda wrote:
> Convert the qcom-wled bindings from .txt to .yaml format.
> Also replace PM8941 to WLED3 and PMI8998 to WLED4.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> Acked-by: Daniel Thompson
> ---
>
Hi Artem.
On Tue, May 05, 2020 at 01:24:16PM +0300, Artem Mygaiev wrote:
> Hello all
>
> I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
> controller [1]. I have already implemented a POC driver [2] which is working
> for
> me, although there are still plenty of
Hi
On Mon, May 4, 2020 at 10:44 PM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-05-04 21:36:31)
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> > remapping of eDP lanes and also polarity inversion. Both of these
> > features have been described in the device tree
From: Jason Yan
Date: Tue, 5 May 2020 15:46:08 +0800
> Fix the following coccicheck warning:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1991:5-46: WARNING:
> Comparison to bool
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:1993:10-54: WARNING:
> Comparison to bool
>
On 2020-05-05 5:51 pm, Andre Przywara wrote:
Date: Mon, 4 May 2020 12:41:55 +0100
Subject: [PATCH 01/16] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties,
since some boards (Arm Juno) integrate the GPU this way.
The same
Sure, I'll file one after work today.
To clarify though, FreeSync still "works" as in the monitor refresh rate
is updating, but it constantly bounces between the maximum and minimum
freesync refresh rates, causing it to look VERY stuttery.
Thanks for the attention, I'll file the but tonight. If
On Wed, Apr 29, 2020 at 12:20 PM Ramalingam C wrote:
>
> On 2020-04-29 at 10:46:29 -0400, Sean Paul wrote:
> > On Wed, Apr 29, 2020 at 10:22 AM Ramalingam C
> > wrote:
> > >
> > > On 2020-04-29 at 09:58:16 -0400, Sean Paul wrote:
> > > > On Wed, Apr 29, 2020 at 9:50 AM Ramalingam C
> > > >
Hi,
On Tue, May 5, 2020 at 1:24 AM Laurent Pinchart
wrote:
>
> Hi Douglas,
>
> Thank you for the patch.
>
> On Mon, May 04, 2020 at 09:36:31PM -0700, Douglas Anderson wrote:
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> > remapping of eDP lanes and also polarity
Can you file a full bug report on the gitlab tracker?
FreeSync is still working on my Navi setups with this patch applied, and
this patch is essentially just a revert of another patch already (where
FreeSync worked before).
I can understand the v2 of this series causing issues, but the v1
Mario or Nick any thoughts?
Alex
On Mon, May 4, 2020 at 1:35 PM Matt Coffin wrote:
>
> Hey guys,
>
> This is still an issue for me, and I'm still having to run a patch to
> revert this as of 5.7-rc4. To avoid breaking a lot of people's Navi
> setups in 5.7, is there any news on this? Has anyone
Date: Mon, 4 May 2020 12:41:55 +0100
Subject: [PATCH 01/16] dt-bindings: mali-midgard: Allow dma-coherent
Add the boolean dma-coherent property to the list of allowed properties,
since some boards (Arm Juno) integrate the GPU this way.
Signed-off-by: Andre Przywara
---
Hi Thomas.
On Tue, May 05, 2020 at 11:56:48AM +0200, Thomas Zimmermann wrote:
> Device initialization is now done in mgag200_device_init(). Specifically,
> the function allocates the DRM device and sets up the respective fields
> in struct mga_device.
>
> A call to mgag200_device_fini()
Hi Thomas.
On Tue, May 05, 2020 at 11:56:47AM +0200, Thomas Zimmermann wrote:
> Done in preparation of embedding the DRM device in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Trivial, one nit you can fix while applying, or ignore.
Reviewed-by: Sam Ravnborg
> ---
>
On Tue, May 05, 2020 at 11:56:46AM +0200, Thomas Zimmermann wrote:
> Done to simplify initialization code before embedding the DRM device
> instance in struct mga_device.
And replace DRM_ERROR with drm_err
And replace r with ret.
I could not follow all the code re-shuffeling, but I expect it to
Hi Thomas.
On Tue, May 05, 2020 at 11:56:45AM +0200, Thomas Zimmermann wrote:
> Mgag200 used dev_private to look up struct mga_device for instances
> of struct drm_device. Use of dev_private is deprecated, so hide it in
> the macro to_mga_device().
>
> Signed-off-by: Thomas Zimmermann
Hi Thomas.
On Tue, May 05, 2020 at 11:56:44AM +0200, Thomas Zimmermann wrote:
> After receiving reviews on the conversion of mgag200 to atomic mode
> setting, I thought it would make sense to embed the DRM device in
> struct mga_device first. Several comments in the atomic-conversion
> reviews
From: Emil Velikov
A few of the new panels create a local macro wrapping around
mipi_dsi_dcs_write. At the same time, they don't really care about the
command/payload split.
mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload > 7 bytes.
kmalloc - avoid that all together by using the
Currently the function heap allocates when we have any payload. Where in
many case the payload is 1 byte - ouch.
>From casual observation, vast majority of the payloads are smaller than
8 bytes - so use a stack array tx[8] to avoid the senseless kmalloc and
kfree dance.
Cc: Jani Nikula
Cc:
From: Emil Velikov
The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
using the generic write. This does not look right.
Perhaps some platforms don't distinguish between the two writers?
Cc: Robert Chiras
Cc: Vinay Simha BN
Cc: Jani Nikula
Cc: Thierry Reding
Fixes:
On Fri, Apr 24, 2020 at 10:34:04PM +0200, H. Nikolaus Schaller wrote:
> The Imagination PVR/SGX GPU is part of several SoC from
> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
> Allwinner A83 and others.
>
> With this binding, we describe how the SGX processor is
> interfaced to
On Wed, 29 Apr 2020 11:15:15 +0530, Harigovindan P wrote:
> Documenting compatible string vendor "visionox" in vendor-prefix yaml file.
>
> Signed-off-by: Harigovindan P
> ---
> Changes in v11:
> - Added compatible string in vendor-prefix yaml file
>
> Changes in v12:
> - Fixed the
On Tue, May 5, 2020 at 10:07 AM Christian König
wrote:
>
> Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
> > After the structure was padded to 1024 bytes, it is no longer
> > suitable for being a local variable, as the function surpasses
> > the warning limit for 32-bit architectures:
> >
> >
From: Emil Velikov
The function vop_cfg_done() is a simple VOP_REG_SET(). As such it should
be done under a reg_lock. A quick look through the driver shows that all
other instances (apart from driver init) have the lock. Do the same here
Cc: Sandy Huang
Cc: Heiko Stübner
Signed-off-by: Emil
On Tue, May 5, 2020 at 4:12 PM 'Marco Elver' via Clang Built Linux
wrote:
> On Tue, 5 May 2020 at 16:04, Arnd Bergmann wrote:
> > With the kcsan changes, __read_once_size() is not inlined, but
> > clang can decide to emit a version that hardcodes the address, which
> > in turn triggers a warning
On Tue, May 5, 2020 at 2:59 AM ChenTao wrote:
>
> Fixes warning because pipe is unsigned long and can never be negtative
>
> vers/gpu/drm/radeon/radeon_kms.c:831:11: warning:
> comparison of unsigned expression < 0 is always false [-Wtype-limits]
> if (pipe < 0 || pipe >= rdev->num_crtc) {
>
On Sat, May 2, 2020 at 4:35 AM Nathan Chancellor
wrote:
>
> When building with Clang:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: warning: overflow in
> expression; result is -294967296 with type 'long' [-Winteger-overflow]
> expires = ktime_get_mono_fast_ns() +
On Thu, 9 Apr 2020 at 15:46, Sam Ravnborg wrote:
>
> Hi Emil.
>
> Thanks for your feedback!
>
> On Thu, Apr 09, 2020 at 03:13:28PM +0100, Emil Velikov wrote:
> > On Thu, 9 Apr 2020 at 12:53, Sam Ravnborg wrote:
> > >
> > > The samsung-s6e63j0x03 had a local way to handle backlight.
> > >
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
Attachment #288915|0 |1
is
Clang does not appear to care, and instead prints a warning:
clang: warning: argument unused during compilation: '-mhard-float'
[-Wunused-command-line-argument]
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 5 +++--
On Tue, May 05, 2020 at 11:56:49AM +0200, Thomas Zimmermann wrote:
> As it is best practice now, the DRM device instance is now embedded in
> struct mga_device. All references to dev_private have been removed.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/mgag200/mgag200_cursor.c
Am 05.05.20 um 16:15 schrieb Arnd Bergmann:
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
Multiplying 10 by four overruns a 'long' variable, as clang
points out:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: error: overflow in
expression; result is -294967296 with type 'long' [-Werror,-Winteger-overflow]
expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC
On Mon, 4 May 2020 at 13:07, Thomas Zimmermann wrote:
>
> Hi Emil
>
> Am 01.05.20 um 15:20 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > Couple of fly-by ideas/suggestions.
> >
> > On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann wrote:
> >>
> >> Suspending failed because there's no mode if the
On Tue, May 05, 2020 at 11:56:48AM +0200, Thomas Zimmermann wrote:
> Device initialization is now done in mgag200_device_init(). Specifically,
> the function allocates the DRM device and sets up the respective fields
> in struct mga_device.
>
> A call to mgag200_device_fini() finalizes struct
On Tue, May 05, 2020 at 11:56:47AM +0200, Thomas Zimmermann wrote:
> Done in preparation of embedding the DRM device in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Not exactly sure what the goal is, since mga_vga_init still uses
drm_device and not the mdev struct. *shrug*
Am 05.05.20 um 16:01 schrieb Arnd Bergmann:
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
On Tue, May 05, 2020 at 11:56:46AM +0200, Thomas Zimmermann wrote:
> Done to simplify initialization code before embedding the DRM device
> instance in struct mga_device.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/mgag200/mgag200_main.c | 67
With the kcsan changes, __read_once_size() is not inlined, but
clang can decide to emit a version that hardcodes the address, which
in turn triggers a warning for dss_conv_list being __initdata but
__read_once_size() not being __init:
WARNING: modpost: vmlinux.o(.text+0x6e4d7a): Section mismatch
After the structure was padded to 1024 bytes, it is no longer
suitable for being a local variable, as the function surpasses
the warning limit for 32-bit architectures:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:587:5: error: stack frame size of 1072
bytes in function 'amdgpu_ras_feature_enable'
On Tue, May 05, 2020 at 11:56:45AM +0200, Thomas Zimmermann wrote:
> Mgag200 used dev_private to look up struct mga_device for instances
> of struct drm_device. Use of dev_private is deprecated, so hide it in
> the macro to_mga_device().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Mon, 4 May 2020 22:01:00 +0200, Konrad Dybcio wrote:
> Signed-off-by: Konrad Dybcio
> ---
> .../display/panel/asus,z00t-tm5p5-n35596.yaml | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644
>
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> The mtk_dpi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
>
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> Convert mtk_dpi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #3 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288913
--> https://bugzilla.kernel.org/attachment.cgi?id=288913=edit
git bisect log
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #2 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288911
--> https://bugzilla.kernel.org/attachment.cgi?id=288911=edit
lspci from IGEL UD7
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=207581
--- Comment #1 from Jan Burgmeier (jan.burgme...@unicon-software.com) ---
Created attachment 288909
--> https://bugzilla.kernel.org/attachment.cgi?id=288909=edit
lspci from lenovo 14w
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=207581
Bug ID: 207581
Summary: [amdgpu] Framebuffer no image CARRIZO and STONEY
Product: Drivers
Version: 2.5
Kernel Version: 5.4.27
Hardware: All
OS: Linux
Tree:
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named
Hi Christoph,
On 05.05.2020 12:15, Christoph Hellwig wrote:
>> -for_each_sg_page(st->sgl, _iter, st->nents, 0)
>> +for_each_sg_page(st->sgl, _iter, st->orig_nents, 0)
> Would it make sense to also add a for_each_sgtable_page helper that
> hides the use of orig_nents? To
Hi Christoph,
On 05.05.2020 12:22, Christoph Hellwig wrote:
>> +static inline int dma_map_sgtable_attrs(struct device *dev,
>> +struct sg_table *sgt, enum dma_data_direction dir, unsigned long attrs)
> Two tab indents for parameter continuation, please.
>
> Can we also skip the separate
Hello all
I am currently working on DRM/KMS driver for Fresco Logic FL2000 USB display
controller [1]. I have already implemented a POC driver [2] which is working for
me, although there are still plenty of things to improve or fix, of course.
So far I have one thing that I somehow cannot find
Mgag200 used dev_private to look up struct mga_device for instances
of struct drm_device. Use of dev_private is deprecated, so hide it in
the macro to_mga_device().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 4 ++--
drivers/gpu/drm/mgag200/mgag200_drv.c
Done to simplify initialization code before embedding the DRM device
instance in struct mga_device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 67 ++
1 file changed, 26 insertions(+), 41 deletions(-)
diff --git
After receiving reviews on the conversion of mgag200 to atomic mode
setting, I thought it would make sense to embed the DRM device in
struct mga_device first. Several comments in the atomic-conversion
reviews refer to that.
Patches 1 to 3 do some cleanups and preparation work. Patch 4 changes
the
Device initialization is now done in mgag200_device_init(). Specifically,
the function allocates the DRM device and sets up the respective fields
in struct mga_device.
A call to mgag200_device_fini() finalizes struct mga_device.
The old function mgag200_driver_load() and mgag200_driver_unload()
As it is best practice now, the DRM device instance is now embedded in
struct mga_device. All references to dev_private have been removed.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
Done in preparation of embedding the DRM device in struct mga_device.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_main.c | 21 +++--
drivers/gpu/drm/mgag200/mgag200_mode.c | 17 +
2 files changed, 20 insertions(+), 18 deletions(-)
diff
Hi Marek,
On Tue, May 5, 2020 at 10:48 AM Marek Szyprowski
wrote:
> The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
> numer of the created entries in the DMA address space. However the
> subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
> called
On Thu, Apr 30, 2020 at 05:33:46PM +0200, Emmanuel Vadot wrote:
> Source file was dual licenced but the header was omitted, fix that.
> Contributors for this file are:
> Daniel Vetter
> Matt Roper
> Maxime Ripard
> Noralf Trønnes
> Thomas Zimmermann
>
> Acked-by: Noralf Trønnes
> Acked-by:
On Tue, May 05, 2020 at 07:55:00AM +0200, Michał Orzeł wrote:
>
>
> On 04.05.2020 13:53, Daniel Vetter wrote:
> > On Fri, May 01, 2020 at 05:49:33PM +0200, Michał Orzeł wrote:
> >>
> >>
> >> On 30.04.2020 20:30, Daniel Vetter wrote:
> >>> On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>
Refocusing on where I think we still have a bit a disconnnect.
On Mon, May 04, 2020 at 03:22:28PM +0300, Pekka Paalanen wrote:
> On Mon, 4 May 2020 13:00:02 +0200
> Daniel Vetter wrote:
> > On Mon, May 4, 2020 at 11:49 AM Pekka Paalanen wrote:
> > > On Thu, 30 Apr 2020 15:53:23 +0200
> > >
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
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 pages (nents entry).
It turned out that it was a common
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of the entries passed to dma_map_sg. The
1 - 100 of 143 matches
Mail list logo
