Hi Maxime, as always, thanks for the series!
Some extra context, and comments below.
On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based
changes since v1:
- make `backlight_properties props` constant
- a couple of line breaks
- change name and compatible to reflect ASUS being the vendor
- remove a redundant TODO
Konrad Dybcio (2):
drivers: drm: panel: Add ASUS TM5P5 NT35596 panel driver
dt-bindings: display: Document ASUS Z00T
Hello there,
linux-5.7-rc4/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c:1393:63:
style: Unsigned expression 'j' can't be negative so it is unnecessary to test
it. [unsignedPositive]
Source code is
for (closest_clk_lvl = 0, j = dcn2_1_soc.num_states - 1; j >= 0;
j--) {
b
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 the ECC aren't 0xff.
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/
The mtk_dpi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/med
On 5/4/20 12:38 PM, Konrad Dybcio wrote:
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index a1723c1b5fbf8..3aa57a927c4bd 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -18,6 +18,16 @@ config DRM_PANEL_ARM_VERSATILE
>
---
>>> drivers/gpu/drm/mgag200/mgag200_reg.h| 5 +-
>>> drivers/gpu/drm/mgag200/mgag200_ttm.c| 35 +-
>>> 9 files changed, 563 insertions(+), 872 deletions(-)
>>> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c
>>>
&
changes since v2:
- fix Kconfig indentation
changes since v1:
- make `backlight_properties props` constant
- a couple of line breaks
- change name and compatible to reflect ASUS being the vendor
- remove a redundant TODO
Konrad Dybcio (2):
drivers: drm: panel: Add ASUS TM5P5 NT35596 panel drive
Maximum allowed bandwidth has no dependency on the type
of panel used. Hence, cleanup the code to use max_bw_high
as the threshold value for bandwidth checks.
Update the maximum allowed bandwidth as 6.8Gbps for
SC7180 target.
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/disp/dpu1/
Small Page NAND uses byte 6 for BBI and Large Page NAND uses first 2 bytes.
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/m
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 bindings for the
> device since the beginning but were never implem
From: Christoph Hellwig
> Sent: 04 May 2020 17:03
>
> On Sun, May 03, 2020 at 09:20:19PM +0100, Chris Wilson wrote:
> > > Err, why does i915 implements its own uncached memcpy instead of relying
> > > on core functionality to start with?
> >
> > What is this core functionality that provides movntq
On Tue, Apr 28, 2020 at 11:50:51PM +0200, Arnd Bergmann wrote:
> Older compilers warn about initializers with incorrect curly
> braces:
>
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function
> 'sun6i_dsi_encoder_enable':
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing braces aroun
No one uses the return value of this function, so make it return void.
This fixes the following coccicheck warning:
drivers/gpu/drm/vc4/vc4_gem.c:1029:5-8: Unneeded variable: "ret". Return
"0" on line 1044
Signed-off-by: Jason Yan
---
drivers/gpu/drm/vc4/vc4_drv.h | 6 +++---
drivers/gpu/drm/vc
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
Fix the following coccicheck warning:
drivers/gpu/drm/zte/zx_vga.c:158:2-3: Unneeded semicolon
drivers/gpu/drm/zte/zx_vga.c:171:2-3: Unneeded semicolon
drivers/gpu/drm/zte/zx_vga.c:179:2-3: Unneeded semicolon
Signed-off-by: Jason Yan
---
drivers/gpu/drm/zte/zx_vga.c | 6 +++---
1 file changed,
Quoting Douglas Anderson (2020-05-04 21:32:29)
> If the rate in our table is _equal_ to the rate we want then it's OK
> to pick it. It doesn't need to be greater than the one we want.
>
> Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
> Signed-off-by: Douglas Anderson
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) {
drivers/gpu/drm/radeon/radeon_kms.c:857:11: warning:
comparison
I just sent out a v3. Hope it solves the issue.
Konrad
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fix the following coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded
semicolon
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded
semicolon
Signed-off-by: Jason Yan
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
drivers/gpu/drm/nouveau/nv
…
> The proper pointer to be passed as argument is ce.
>
> This bug was detected with the help of Coccinelle.
My software development attention was caught also by your commit message.
…
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1325,7 +1325,7 @@ static int __reloc_gpu_alloc(st
First 2 bytes are used in large-page nand.
Signed-off-by: Álvaro Fernández Rojas
---
v2: extend original comment
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brc
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
This adds support for TMP5P5 NT35596 1080x1920 video
mode panel that can be found on some Asus Zenfone 2
Laser (Z00T) devices.
This panel seems to only be found in this device
and we have no straightforward way of actually
getting the correct model number, as no schematics
are released publicly.
Signed-off-by: Konrad Dybcio
---
.../display/panel/asus,z00t-tm5p5-n35596.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-n35596.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel
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:
On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
wrote:
>
> On Tue
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 bindings for the
device since the beginning but were never implemented in the driver.
Implement both of them.
Part of t
If the rate in our table is _equal_ to the rate we want then it's OK
to pick it. It doesn't need to be greater than the one we want.
Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 f
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #11 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #10)
> I did get an apparent graphics crash at the bisect-point above, but it
> didn't dump anything in the log this time
Got a gpf dump with amdgpu_atomic_co
On Mon, May 4, 2020 at 12:56 PM Uwe Kleine-König
wrote:
>
> Hi Sam,
>
> On Mon, May 04, 2020 at 07:45:22PM +0200, Sam Ravnborg wrote:
> > On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> > > There are some new broken doc links due to yaml renames
> > > at DT. Developers sho
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_ra
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
Acked-by: Felix Kuehling
Reviewed-by: Ch
On 2020-05-01 11:20, Jason Gunthorpe wrote:
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault()
IS_BUILTIN can be use to replace various initializations
like #if CONFIG_ int val = 1; #else int val = 0; #endif
so do so.
Signed-off-by: Joe Perches
---
drivers/video/fbdev/aty/aty128fb.c | 6 +-
drivers/video/fbdev/aty/atyfb_base.c | 7 +--
drivers/video/fbdev/aty/radeon_base.c
On Mon, May 04, 2020 at 10:02:25PM +0100, Al Viro wrote:
> On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote:
>
> > > || * arm: much, much worse. We have several files that pull
> > > linux/highmem.h:
> > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c,
> > > || arch/arm
Applied. Thanks!
Alex
On Mon, May 4, 2020 at 9:20 AM Jason Yan wrote:
>
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:1574:5-8: Unneeded
> variable: "ret". Return "0" on line 1586
>
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/amd/display/
On Mon, May 04, 2020 at 01:18:51PM +0200, Daniel Vetter wrote:
> On Mon, May 4, 2020 at 3:09 AM wrote:
> >
> > From: Ira Weiny
> >
> > kmap_atomic_prot() is now exported by all architectures. Use this
> > function rather than open coding a driver specific kmap_atomic.
> >
> > Reviewed-by: Christ
Hi David.
On Tue, Apr 28, 2020 at 02:45:21PM +0800, David Lu wrote:
> fix boe_tv105wum_nw0 display shift.
>
> Signed-off-by: David Lu
Added fixes: tag and applied to drm-misc-next.
Sam
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8
> 1 file changed, 4 insertions(
On Mon, May 04, 2020 at 06:33:57AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote:
>
> > Grepping for 'asm/highmem.h' and investigations don't reveal any issues...
> > But
> > you do have me worried. That said 0-day has been crunching on multiple
> > versions
Hi Lubomir.
Drivers looks good. I look forward to the day we have moved
connector stuff to the displaydriver - this will simplify this driver
even more.
One Q in the following.
Sam
On Fri, Apr 24, 2020 at 11:35:39PM +0200, Lubomir Rintel wrote:
> This is a driver for video encoder with
On Thu, Apr 23, 2020 at 01:00:58PM +0300, Adrian Ratiu wrote:
> This converts the Synopsis MIPI DSI binding documentation to yaml and
> should be quite straightforward. I've added a missing ref clk and also
> added Philippe as maintainer b/c he's the original txt author following
> the algorithm pr
Hi Tomi.
On Fri, Apr 17, 2020 at 02:40:43PM +0300, Tomi Valkeinen wrote:
> The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
> indicated by the current bus_format.
>
> Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
> connector_type to LVDS.
>
> Signed-o
On Mon, 2020-05-04 at 19:55 +0200, Uwe Kleine-König wrote:
> Hi Sam,
>
> On Mon, May 04, 2020 at 07:45:22PM +0200, Sam Ravnborg wrote:
> > On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> > > There are some new broken doc links due to yaml renames
> > > at DT. Developers sh
Hi GVRao,
Thanks for the patch. Sorry for late reply.
On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu wrote:
> The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
> data from AXI-4 stream interface.
>
> It supports upto 4 lanes, optional register interface for th
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(...) {
...
struct intel_crtc *T = ...;
+struc
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct drm_device pointer
can be extracted.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/gem/i915_
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Conversion is done with below sementic patch:
@@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN*.
Conversion is done with below semantic patch:
@@
identifier func, T;
@@
func(struct intel_runtime_pm *T,...) {
+ struct drm_i9
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* at places where struct intel_dp or struct
drm_i915_private pointer is available.
Conversion is done with below sementic patch:
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_pmu.c | 12 +---
1 file changed, 9 insertions(+), 3
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
changes since v1:
- Added dev_priv local variable and used it in drm_WARN* calls (Jani)
Signed-off-by: Pankaj Bharadiya
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
changes since v1:
- Add parentheses around the dev_priv macro argument (Jani)
Signed-off-by: Pankaj Bharadiya
---
driver
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct i915_power_domains
struct is available.
Conversion is done with below sementic patch:
@@
identifier
Now we have struct drm_device specific drm_WARN* macros which include
device information in the backtrace, so we know what device the
warnings originate from.
This series converts WARN* with drm_WARN* where struct drm_device
pointer can be extracted.
This series is the continuation of:
https://pa
Hi Sam,
On Mon, May 04, 2020 at 07:45:22PM +0200, Sam Ravnborg wrote:
> On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> > There are some new broken doc links due to yaml renames
> > at DT. Developers should really run:
> >
> > ./scripts/documentation-file-ref-check
>
Hi Mauro.
On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
>
> ./scripts/documentation-file-ref-check
>
> in order to solve those issues while submitting patches.
Would lo
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 else at the very
least been able to reproduce the problem?
It happens for me in every single pro
On Mon, 2020-05-04 at 11:30 +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
>
> ./scripts/documentation-file-ref-check
>
> in order to solve those issues while submitting patches.
> This tool can even fix m
On Thu, Apr 30, 2020 at 02:46:54PM -0700, Sultan Alsawaf wrote:
> From: Sultan Alsawaf
>
> In commit 5a7d202b1574, a logical AND was erroneously changed to an OR,
> causing WaIncreaseLatencyIPCEnabled to be enabled unconditionally for
> kabylake and coffeelake, even when IPC is disabled. Fix the
Den 04.05.2020 14.06, skrev Daniel Vetter:
> On Wed, Apr 29, 2020 at 02:48:22PM +0200, Noralf Trønnes wrote:
>> This adds a function that creates a backlight device for a connector.
>> It does not deal with the KMS backlight ABI proposition[1] to add a
>> connector property. It only takes the cur
Userspace can severely fragment rb_hole_addr rbtree by manipulating
alignment while allocating buffers. Fragmented rb_hole_addr rbtree
would result in large delays while allocating buffer object for a
userspace application. It takes long time to find suitable hole
because if we fail to find a suita
On 5/4/20 3:35 PM, Christian König wrote:
Am 04.05.20 um 12:42 schrieb Nirmoy Das:
Userspace can severely fragment rb_hole_addr rbtree by manipulating
alignment while allocating buffers. Fragmented rb_hole_addr rbtree
would result in large delays while allocating buffer object for a
userspace a
Fix inconsistent IS_ERR and PTR_ERR in __reloc_gpu_alloc().
The proper pointer to be passed as argument is ce.
This bug was detected with the help of Coccinelle.
Fixes: 6f576d6277ce ("drm/i915/gem: Try an alternate engine for relocations")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm
On Mon, May 04, 2020 at 02:07:22PM +0200, 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 mo
Hi Daniel,
On 21/04/2020 18:15, Neil Armstrong wrote:
> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> It considerably reduces memory bandwidth while writing and reading
On 04/05/2020 13:51, Jyri Sarha wrote:
On 29/04/2020 15:10, Tomi Valkeinen wrote:
AM65x PG1 has a HW issue with YUV pixel formats, resulting in wrong
colors on the screen. This issue is fixed in PG2 hardware.
The driver currently has code to hide YUV pixel formats from the
userspace. To support
On 29/04/2020 15:10, Tomi Valkeinen wrote:
> AM65x PG1 has a HW issue with YUV pixel formats, resulting in wrong
> colors on the screen. This issue is fixed in PG2 hardware.
>
> The driver currently has code to hide YUV pixel formats from the
> userspace. To support PG2, we would need to add code
Hi Thomas.
> >
> >
> >> + WREG_SEQ(0x01, seq1);
> >> +
> >> + memctl = RREG32(MGAREG_MEMCTL);
> >> +
> >> + memctl |= RESET_FLAG;
> >> + WREG32(MGAREG_MEMCTL, memctl);
> >> +
> >> + udelay(1000);
> >> +
> >> + memctl &= ~RESET_FLAG;
> >> + WREG32(MGAREG_MEMCTL, memctl);
> >> +
> >> + /*
Hi Thomas.
> >> @@ -1161,9 +1174,11 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> >>}
> >>
> >>WREG_ECRT(0, ext_vga[0]);
> >> - /* Enable mga pixel clock */
> >> - misc = 0x2d;
> >>
> >> + misc = RREG8(MGA_MISC_IN);
> >> + misc |= MGAREG_MISC_IOADSEL |
> >> + MG
---
>> drivers/gpu/drm/mgag200/mgag200_reg.h | 5 +-
>> drivers/gpu/drm/mgag200/mgag200_ttm.c | 35 +-
>> 9 files changed, 563 insertions(+), 872 deletions(-)
>> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c
>>
>> --
>&
Am 04.05.20 um 12:42 schrieb Nirmoy Das:
Userspace can severely fragment rb_hole_addr rbtree by manipulating
alignment while allocating buffers. Fragmented rb_hole_addr rbtree
would result in large delays while allocating buffer object for a
userspace application. It takes long time to find suita
Hi Paul,
Just had a casual quick look for custom KMS properties, since new
drivers made that mistake in the past.
Thanks for not including any o/
I made a couple of trivial suggestions - if you agree, feel free to
keep them as follow-up patches.
On Thu, 30 Apr 2020 at 20:28, Paul Kocialkowski
w
On 04/05/2020 13:53, 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 with the original number of entri
Hi,
On 4/30/20 3:22 AM, David Santamaría Rogado wrote:
I'm thinking also about the i915 part. Could be something different
that Intel does in the Windows version of their driver? Seem very
strange that Microsoft could patch something because of this
particular hardwares.
On Windows devices oft
Hi
Am 03.05.20 um 18:25 schrieb Sam Ravnborg:
> Hi Thomas.
>
> One nit about a bit name below.
> Acked-by: Sam Ravnborg
>
> On Wed, Apr 29, 2020 at 04:32:33PM +0200, Thomas Zimmermann wrote:
>> 5
>>
>> The TAGFIFO state is now reset in mgag200_g200er_reset_tagfifo().
>>
>> Signed-off-by: Thomas
Hi
Am 03.05.20 um 17:42 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Wed, Apr 29, 2020 at 04:32:31PM +0200, Thomas Zimmermann wrote:
>> The framebuffer's pitch is now set in mgag200_set_offset().
>>
>> Signed-off-by: Thomas Zimmermann
>
> I failed to follow this code.
Is it because of the line-of
Hi Christoph,
On 04.05.2020 14:52, Christoph Hellwig wrote:
> On Mon, May 04, 2020 at 02:50:17PM +0200, Marek Szyprowski wrote:
>> v2:
>> - dropped most of the changes to drm/i915
>> - added fixes for rcar-du, xen, media and ion
>> - fixed a few issues pointed by kbuild test robot
>> - added wide
Hi
Am 03.05.20 um 17:34 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Wed, Apr 29, 2020 at 04:32:29PM +0200, Thomas Zimmermann wrote:
>> 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 writte
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
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 in
t I will prepare a common
dma_{map,sync,unmap}_sgtable() wrappers, which will use a proper sg_table
entries and call respective DMA-mapping functions. I hope this will help
to avoid issue like this in the future.
Patches are based on top of Linux next-20200504.
Best regards,
Marek Szyprowski
Reference
1 - 100 of 137 matches
Mail list logo
