Am 12.05.20 um 10:59 schrieb Daniel Vetter:
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 the
On Wed, May 13, 2020 at 9:02 AM Christian König
wrote:
>
> Am 12.05.20 um 10:59 schrieb Daniel Vetter:
> > 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 mi
On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On T
Am 12.05.20 um 22:12 schrieb Dave Airlie:
On Wed, 13 May 2020 at 04:21, Alex Deucher wrote:
On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote:
On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
Otherwise all agree, agp is a mighty mess and essentially just
crapshot outside of x86. It kin
Hi Paul,
I'm one of the drm/bridge maintainer and, with Jernel & Jonas, we did most of
the
changes on the dw-hdmi driver recently for the Amlogic, Rockchip & Allwinner
platforms.
On 12/05/2020 21:37, Paul Boddie wrote:
> Hello,
>
> On and off over the past few months, I have been looking at ge
Am 12.05.20 um 23:12 schrieb Alex Deucher:
On Tue, May 12, 2020 at 4:52 PM Roy Spliet wrote:
Op 12-05-2020 om 14:36 schreef Alex Deucher:
On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
On 2020-05-11 10:12 p.m., Alex Deucher wrote:
On Mon, May 11, 2020 at 1:17 PM Christian König
wrote
On Tue, 12 May 2020 18:09:15 +0200
Hans de Goede wrote:
> Hi,
>
> On 5/12/20 4:20 PM, Pekka Paalanen wrote:
> > On Tue, 12 May 2020 10:18:31 +0200
> > Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 5/11/20 9:55 PM, Rajat Jain wrote:
> >>> Hi Hans,
> >>>
> >>> On Mon, May 11, 2020 at 10:47
On 2020-05-13 9:46 a.m., Christian König wrote:
> Am 12.05.20 um 23:12 schrieb Alex Deucher:
>> On Tue, May 12, 2020 at 4:52 PM Roy Spliet wrote:
>>>
>>> I'll volunteer to be the one asking: how big is this performance
>>> difference? Have any benchmarks been run before and after removal of AGP
>>
Am 13.05.20 um 09:19 schrieb Daniel Vetter:
On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR)
wrote:
Hi,
On Tue, 12 May
https://bugzilla.kernel.org/show_bug.cgi?id=195159
linux4all (joerg.ka...@gmx.de) changed:
What|Removed |Added
CC||joerg.ka...@gmx.de
--- C
On Tue, 12 May 2020, Wolfram Sang wrote:
> On Fri, Apr 17, 2020 at 11:14:46AM +0100, Lee Jones wrote:
> > On Thu, 26 Mar 2020, Wolfram Sang wrote:
> >
> > > Move away from the deprecated API and return the shiny new ERRPTR where
> > > useful.
> > >
> > > Signed-off-by: Wolfram Sang
> > > ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=195159
--- Comment #12 from linux4all (joerg.ka...@gmx.de) ---
on a HP ZBook 17 G4
17: PCI 100.0: 0300 VGA compatible controller (VGA)
[Created at pci.386]
Unique ID: VCu0.mCEkXGSxUXA
Parent ID: vSkL.fBtNDRZZiP3
SysFS ID: /devices/pc
On 31-Jan-20 4:50 PM, Ville Syrjälä wrote:
On Thu, Jan 30, 2020 at 08:07:07PM +, Souza, Jose wrote:
On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
wrote:
TGL timeouts when disabling MST transcoder and fifo underruns
On Tue, May 12, 2020 at 11:19 AM Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-12 10:08:47)
> > On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-05-12 09:59:29)
> > > > Design is similar to the lockdep annotations for workers, but with
> > > >
Hi Rob,
Thanks for reviewing the patch and I'm sorry it had so many mistakes,
this was my first attempt at converting a DT binding to schema.
On lun 11-05-2020 16:31:08, Rob Herring wrote:
> > This binding is meant to be used in conjunction with
> > Documentation/bindings/display/rockchip/analog
On Tue, 12 May 2020 at 19:34, Thomas Zimmermann wrote:
>
> Hi Emil
>
> Am 12.05.20 um 12:27 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> >
> >> @@ -1143,20 +1178,15 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
> >> WREG_CR
Hi Miquèl
> El 12 may 2020, a las 9:16, Miquel Raynal
> escribió:
>
> Hi Álvaro,
>
> Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> 08:51:11 +0200:
>
>> 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
Current pages sizes apply to controllers after v3.4
Signed-off-by: Álvaro Fernández Rojas
---
v2: add new patch.
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 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
The subject is not specific enough. I'd expect it to be something like:
drm/bridge: ti-sn65dsi86: ensure bridge suspend happens during PM sleep
Quoting Harigovindan P (2020-04-22 02:04:43)
> ti-sn65dsi86 bridge is enumerated as a runtime device.
>
> Adding sleep ops to force runtime_suspend when
These registers are also used on v3.3.
Signed-off-by: Álvaro Fernández Rojas
Reviewed-by: Miquel Raynal
---
v2: fix commit title.
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/dr
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
Hi Álvaro,
Álvaro Fernández Rojas wrote on Tue, 12 May 2020
09:26:23 +0200:
> Hi Miquèl,
>
> > El 12 may 2020, a las 9:19, Miquel Raynal
> > escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> > 09:12:10 +0200:
> >
> >> Hi Miquel,
> >>
> >> I also ha
On 5/8/20 8:14 PM, Stephen Rothwell wrote:
> Hi Arnd,
>
> On Sat, 9 May 2020 00:01:31 +0200 Arnd Bergmann wrote:
>>
>> In order to call kmap_atomic() etc, we need to include linux/highmem.h:
>>
>> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: In function 'vmw_bo_cpu_blit_line':
>> drivers/gpu/drm/vmwgfx
Tested on Netgear DGND3700v2 (BCM6362 with v2.2 controller).
Signed-off-by: Álvaro Fernández Rojas
---
v2: split page sizes rename into a different patch.
name all block and page sizes versions.
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 74 +---
1 file changed, 66 ins
Hi Miquel,
I also had a hard time understanding your email.
It was quite misleading.
> El 12 may 2020, a las 9:08, Miquel Raynal
> escribió:
>
> Hi Álvaro,
>
> Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> 08:00:23 +0200:
>
>> The current code generates 8 oob sections:
>> S1 1-5
>> E
No one is using the LVDS_BIT_MAP_SPWG/JEIDA enums since a previous
commit which changes the imx_ldb_bit_mappings[] array definition,
so let's remove them.
Fixes: 5e501ed7253b ("drm/imx: imx-ldb: allow to determine bus format from the
connected panel")
Cc: Philipp Zabel
Cc: Sascha Hauer
Cc: Peng
Hi Álvaro,
Álvaro Fernández Rojas wrote on Tue, 12 May 2020
08:00:23 +0200:
> The current code generates 8 oob sections:
> S11-5
> ECC 6-8
> S29-15
> S316-21
> ECC 22-24
> S425-31
> S532-37
> ECC 38-40
> S641-47
> S748-53
> ECC 54-56
> S857-63
>
> Change
Only v3.3-v5.0 have a different CS0 layout.
Controllers before v3.3 use the same layout for every CS.
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB
NAND controller")
Signed-off-by: Álvaro Fernández Rojas
---
v2: fix commit log.
drivers/mtd/nand/raw/brcmnand/brcmn
Hi Álvaro,
Álvaro Fernández Rojas wrote on Tue, 12 May 2020
08:51:11 +0200:
> 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 check
Op 12-05-2020 om 14:36 schreef Alex Deucher:
On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
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
Hi Álvaro,
Álvaro Fernández Rojas wrote on Tue, 12 May 2020
09:24:32 +0200:
> Hi Miquèl
>
> > El 12 may 2020, a las 9:16, Miquel Raynal
> > escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> > 08:51:11 +0200:
> >
> >> The current code checks that the
On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote:
>
> Otherwise all agree, agp is a mighty mess and essentially just
> crapshot outside of x86. It kinda worked for the much more static
> allocations for dri1, but with in-kernel memory managers all the cache
> flushing issues showed up big time an
Hi Álvaro,
Álvaro Fernández Rojas wrote on Tue, 12 May 2020
09:12:10 +0200:
> Hi Miquel,
>
> I also had a hard time understanding your email.
> It was quite misleading.
>
> > El 12 may 2020, a las 9:08, Miquel Raynal
> > escribió:
> >
> > Hi Álvaro,
> >
> > Álvaro Fernández Rojas wrote on
On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> }
> EXPORT_SYMBO
On Mon, May 11, 2020 at 04:50:14PM -0500, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 05:35:11PM +0200, Maxime Ripard wrote:
> > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > bindings, especially since the registers have been shuffled around in more
> > register ra
Added brcm,brcmnand-v2.1 and brcm,brcmnand-v2.2 as possible compatible
strings to support brcmnand controllers v2.1 and v2.2.
Signed-off-by: Álvaro Fernández Rojas
---
v2: add new patch
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add support for v2.1 and v2.2 NAND controllers.
v2: introduce changes suggested by Miquèl.
Álvaro Fernández Rojas (5):
mtd: rawnand: brcmnand: rename v4 registers
mtd: rawnand: brcmnand: fix CS0 layout
mtd: rawnand: brcmnand: rename page sizes
dt: bindings: brcmnand: add v2.1 and v2.2 sup
On Fri, Apr 17, 2020 at 11:14:46AM +0100, Lee Jones wrote:
> On Thu, 26 Mar 2020, Wolfram Sang wrote:
>
> > Move away from the deprecated API and return the shiny new ERRPTR where
> > useful.
> >
> > Signed-off-by: Wolfram Sang
> > ---
> > drivers/video/backlight/tosa_lcd.c | 4 ++--
> > 1 file
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
---
v4: no changes
v3: invert patch order
v2: extend original comment
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 11
Hello everybody,
since Kernel 5.6.5 I encounter many syslog lines like
[kernel] [drm] Reducing the compressed framebuffer size. This may lead to less
power savings than a non-reduced-size. Try to increase stolen memory size if
available in BIOS.
- Last output repeated 4 times -
On Mon, Mar 16, 2020 at 05:39:05PM +0100, Wolfram Sang wrote:
> While converting I2C users to new APIs, I found a refcounting problem in
> the encoder_slave implementation. This series fixes it and converts to
> the new API.
>
> Based on linux-next and only build tested.
>
> Wolfram Sang (2):
>
On 5/11/20 2:43 PM, Quentin Perret wrote:
Hey Lukasz,
On Monday 11 May 2020 at 12:19:01 (+0100), Lukasz Luba wrote:
@@ -27,12 +29,15 @@ struct em_perf_state {
* em_perf_domain - Performance domain
* @table:List of performance states, in ascending order
* @nr_perf_states
These patches improve the OOB hamming layout by reducing the number of oob
sections and correctly reserving first two bytes for large page NANDs.
v4: clarify small/large pages comment.
v3: invert patch order.
v2: extend original comment and correctly skip byte 6 for small-page.
Álvaro Fernández R
Hi Rob,
On Mon, May 11, 2020 at 04:47:27PM -0500, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 05:33:44PM +0200, Maxime Ripard wrote:
> > The firmware running on the RPi VideoCore can be used to discover and
> > change the various clocks running in the BCM2711. Since devices will
> > need to use t
Hi,
On Tue, 12 May 2020, Rui Salvaterra wrote:
> > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a
> > big performance difference between AGP and PCI GART. The latter was
> > sort of usable for normal desktop operation, but not so much for
> > OpenGL apps (which were usable w
On Tue, 12 May 2020 at 08:58, Michel Dänzer wrote:
>
> FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a big
> performance difference between AGP and PCI GART. The latter was sort of
> usable for normal desktop operation, but not so much for OpenGL apps
> (which were usable with
Hi Miquèl,
> El 12 may 2020, a las 9:19, Miquel Raynal
> escribió:
>
> Hi Álvaro,
>
> Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> 09:12:10 +0200:
>
>> Hi Miquel,
>>
>> I also had a hard time understanding your email.
>> It was quite misleading.
>>
>>> El 12 may 2020, a las 9:08, Miq
Hi Quentin,
On 5/11/20 12:57 PM, Quentin Perret wrote:
On Monday 11 May 2020 at 12:19:00 (+0100), Lukasz Luba wrote:
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 61623e2ff149..11ee24e06d12 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/sc
> -Original Message-
> From: Hans de Goede
> Sent: Monday, May 11, 2020 12:47 PM
> To: Maarten Lankhorst; Maxime Ripard; Thomas Zimmermann; Daniel Vetter; David
> Airlie; Rajat Jain; Jani Nikula
> Cc: Hans de Goede; Pekka Paalanen; Limonciello, Mario; Quintanilla, Sonny;
> Jared Dominguez;
Hi Miquèl,
El mar., 12 may. 2020 a las 9:34, Miquel Raynal
() escribió:
>
> Hi Álvaro,
>
> Álvaro Fernández Rojas wrote on Tue, 12 May 2020
> 09:24:32 +0200:
>
> > Hi Miquèl
> >
> > > El 12 may 2020, a las 9:16, Miquel Raynal
> > > escribió:
> > >
> > > Hi Álvaro,
> > >
> > > Álvaro Fernández
Both of the two LVDS channels should be disabled for split mode
in the encoder's ->disable() callback, because they are enabled
in the encoder's ->enable() callback.
Fixes: 6556f7f82b9c ("drm: imx: Move imx-drm driver out of staging")
Cc: Philipp Zabel
Cc: Sascha Hauer
Cc: Pengutronix Kernel Tea
On Tue, 12 May 2020 at 19:47, Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.05.20 um 12:14 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote:
> >>
> >> The suspend/resume helpers are unused. Also remove associated state
> >> from struct mga_device.
> >
On Tue, 12 May 2020 at 20:48, Alex Deucher wrote:
> > >>
> > >> There's some AGP support code in the DRM core. Can some of that declared
> > >> as legacy?
> > >>
> > >> Specifically, what about these AGP-related ioctl calls? Can they be
> > >> declared as legacy? It would appear to me that KMS-ba
Hi Wolfram,
On Wed, 13 May 2020 at 10:10, Wolfram Sang
wrote:
>
> On Mon, Mar 16, 2020 at 05:39:05PM +0100, Wolfram Sang wrote:
> > While converting I2C users to new APIs, I found a refcounting problem in
> > the encoder_slave implementation. This series fixes it and converts to
> > the new API.
Hi Vinay,
On Thu, 7 May 2020 at 17:18, Emil Velikov wrote:
>
> On Thu, 7 May 2020 at 13:29, Vinay Simha B N wrote:
> >
> > Emil,
> >
> > Reply inline
> >
> > On Tue, 5 May 2020 at 9:35 PM, Emil Velikov
> > wrote:
> >>
> >> From: Emil Velikov
> >>
> >> The helper uses the MIPI_DCS_SET_TEAR_SCA
Hi,
This series adds driver and bindings for Lontium LT9611 bridge chip which
takes MIPI DSI as input and HDMI as output.
This chip can be found in 96boards RB3 platform [1] commonly called DB845c.
[1]: https://www.96boards.org/product/rb3-platform/
Vinod Koul (3):
dt-bindings: vendor-prefixe
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 178 ++
1 file changed, 178 insertions(+)
create mode 100644
Documentation/devicetre
Add prefix for Lontium Semiconductor Corporation
Signed-off-by: Vinod Koul
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.
On Wed, May 13, 2020 at 9:55 AM Christian König
wrote:
>
> Am 13.05.20 um 09:19 schrieb Daniel Vetter:
> > On Tue, May 12, 2020 at 8:22 PM Alex Deucher wrote:
> >> On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote:
> >>> On Tue, May 12, 2020 at 3:22 PM Alex Deucher
> >>> wrote:
> On Tu
On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
>>
>> i915 is even worse, we manually mess around with clflush. In
>> userspace. So really there's 2 axis for dma memory: coherent vs.
>> non-coherent (which is something the dma-api somewhat expos
On Wed, May 13, 2020 at 12:26 PM Michel Dänzer wrote:
>
> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
> > On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
> >>
> >> i915 is even worse, we manually mess around with clflush. In
> >> userspace. So really there's 2 axis for dma memory: 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
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devi
On 2020-05-13 12:29 p.m., Daniel Vetter wrote:
> On Wed, May 13, 2020 at 12:26 PM Michel Dänzer wrote:
>>
>> On 2020-05-13 11:28 a.m., Rui Salvaterra wrote:
>>> On Wed, 13 May 2020 at 08:19, Daniel Vetter wrote:
i915 is even worse, we manually mess around with clflush. In
userspace
This fixes the following use-after-free problem in case an MST down
message times out, while waiting for the response for it:
[ 449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send
80ba7fa2 2 0
[ 449.022898] [ cut here ]
[ 449.022903] list_add co
Hi Rob,
On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote:
> > > >
> > > > On 2020-05-01 11:21 am, B
On 2020-05-13 12:39 p.m., Rui Salvaterra wrote:
> On Wed, 13 May 2020 at 11:27, Michel Dänzer wrote:
>>
>> The only theoretical problem there was that the kernel still had a
>> cacheable mapping of the same memory, and any access via that (e.g.
>> prefetch due to access to a neighbouring page) cou
Hi
Am 11.05.20 um 19:17 schrieb Christian König:
> Hi guys,
>
> Well let's face it AGP is a total headache to maintain and dead for at least
> 10+ years.
>
> We have a lot of x86 specific stuff in the architecture independent graphics
> memory management to get the caching right, abusing the D
Hi
Am 13.05.20 um 11:27 schrieb Emil Velikov:
> On Tue, 12 May 2020 at 20:48, Alex Deucher wrote:
>
>
> There's some AGP support code in the DRM core. Can some of that declared
> as legacy?
>
> Specifically, what about these AGP-related ioctl calls? Can they be
> declared
Unfortunately AGP is still to widely used as we could just drop support for
using its GART.
Not using the AGP GART also doesn't mean a loss in functionality since drivers
will just fallback to the driver specific PCI GART.
For now just deprecate the code and don't enable the AGP GART in TTM eve
Even when core AGP support is compiled in Radeon and
Nouveau can also work with the PCI GART.
The AGP support was notorious unstable and hard to
maintain, so deprecate it for now and only enable it if
there is a good reason to do so.
Signed-off-by: Christian König
---
drivers/gpu/drm/Kconfig
Always use the PCI GART instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index bbb0883e8ce6..a71f13116d6b 100644
--- a/drivers/gpu/drm
Hi
Am 12.05.20 um 20:56 schrieb Sam Ravnborg:
> Hi Thomas.
>
> On Tue, May 12, 2020 at 10:42:43AM +0200, Thomas Zimmermann wrote:
>> 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 wit
-Original Message-
From: Navare, Manasi D
Sent: Wednesday, May 13, 2020 11:05 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Modem, Bhanuprakash ; Navare, Manasi D
; Jani Nikula ; Ville
Syrjälä
Subject: [PATCH v5 3/3] drm/i915/dp: Expose connector VRR info
Hi Laurent,
On mié 06-05-2020 18:53:20, Laurent Pinchart wrote:
> I didn't if I remember correctly, I just mapped it to the hardware
> features. The hardware register indeed takes a value between 0 and 7,
> and that is mapped to [-4,3] x t(STEP). I don't mind either option.
I was taking a look at
On some qualcomm platforms DPU needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Reviewed-by: Rob Clark
Revie
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@li
>-Original Message-
>From: Marek Szyprowski
>Sent: Tuesday, May 12, 2020 4:34 PM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org; io...@lists.linux-foundation.org; linaro-mm-
>s...@lists.linaro.org; linux-ker...@vger.kernel.org
>Cc: Pawel Osciak ; Bartlomiej Zolnierkiewicz
>; Davi
On Wed, May 13, 2020 at 01:58:47PM +0530, Sharma, Swati2 wrote:
>
>
> On 31-Jan-20 4:50 PM, Ville Syrjälä wrote:
> > On Thu, Jan 30, 2020 at 08:07:07PM +, Souza, Jose wrote:
> >> On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> >>> On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Rober
On Wed, May 13, 2020 at 03:09:52PM +0300, Ville Syrjälä wrote:
> On Wed, May 13, 2020 at 01:58:47PM +0530, Sharma, Swati2 wrote:
> >
> >
> > On 31-Jan-20 4:50 PM, Ville Syrjälä wrote:
> > > On Thu, Jan 30, 2020 at 08:07:07PM +, Souza, Jose wrote:
> > >> On Thu, 2020-01-30 at 19:25 +0200, Vill
https://bugzilla.kernel.org/show_bug.cgi?id=207673
--- Comment #2 from phileimer (p...@jpmr.org) ---
I can give more information about the over temperature problem :
* if I keep the 120C limit, the card runs at power level 3 until the driver
crashes
* limiting at 100C allows the driver to decrea
On Wed, May 13, 2020 at 10:15:25AM +0100, Emil Velikov wrote:
> On Tue, 12 May 2020 at 19:47, Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 12.05.20 um 12:14 schrieb Emil Velikov:
> > > Hi Thomas,
> > >
> > > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann
> > > wrote:
> > >>
> > >> The suspend
On Tue, May 12, 2020 at 03:36:01PM +0200, Massimo B. wrote:
> Hello everybody,
>
> since Kernel 5.6.5 I encounter many syslog lines like
>
> [kernel] [drm] Reducing the compressed framebuffer size. This may lead to
> less power savings than a non-reduced-size. Try to increase stolen memory
> si
On Wed, May 13, 2020 at 01:03:13PM +0200, Christian König wrote:
> Even when core AGP support is compiled in Radeon and
> Nouveau can also work with the PCI GART.
>
> The AGP support was notorious unstable and hard to
> maintain, so deprecate it for now and only enable it if
> there is a good reas
On Wed, May 13, 2020 at 01:31:55PM +0300, Imre Deak wrote:
> This fixes the following use-after-free problem in case an MST down
> message times out, while waiting for the response for it:
>
> [ 449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send
> 80ba7fa2 2 0
> [ 449.
Am 13.05.20 um 14:34 schrieb Daniel Vetter:
On Wed, May 13, 2020 at 01:03:13PM +0200, Christian König wrote:
Even when core AGP support is compiled in Radeon and
Nouveau can also work with the PCI GART.
The AGP support was notorious unstable and hard to
maintain, so deprecate it for now and onl
On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
>
> Thank you Greg for the comments.
> On 5/12/2020 2:22 PM, Greg KH wrote:
> > 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
> >> fi
On Wed, May 13, 2020 at 03:48:58PM +0300, Ville Syrjälä wrote:
> On Wed, May 13, 2020 at 01:31:55PM +0300, Imre Deak wrote:
> > This fixes the following use-after-free problem in case an MST down
> > message times out, while waiting for the response for it:
> >
> > [ 449.022841] [drm:drm_dp_mst_w
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
On 2020-05-12 10:00 am, Marek Szyprowski wrote:
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
On 2020-05-12 10:00 am, Marek Szyprowski wrote:
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
On 2020-05-12 10:00 am, Marek Szyprowski wrote:
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
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
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
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
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 v5 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_
1 - 100 of 220 matches
Mail list logo
