On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
>
> On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> >
> > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter
> > wrote:
> > >
> > > It's the default.
> > Thanks for catching that.
> >
> > >
> > > Also so much for "we're not going to tell the gra
https://bugzilla.kernel.org/show_bug.cgi?id=207665
c3bac...@protonmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
>
> On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote:
> >
> > It's the default.
> Thanks for catching that.
>
> >
> > Also so much for "we're not going to tell the graphics people how to
> > review their code", dma_fence is a pretty core piece
On Tue, 12 May 2020 at 09:06, Ilia Mirkin wrote:
>
> On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> > b/drivers/gpu/drm/nouveau/nouveau_connector.c
> > index 43bcbb6d73c4..6dae00da5d7e 100644
> > --- a/drivers/gpu/drm/nouveau/nouv
On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Cañuelo wrote:
> Hi Rob,
>
> What's your opinion on this?
>
> Some context: It's about bindings that define signed integer properties
> with range checks that go below and above zero. The schema checker fails
> because, apparently, it interprets e
I'm not exactly an expert on this, but looks alright to me.
Acked-by: Roland Scheidegger
Am 05.05.20 um 10:46 schrieb Marek Szyprowski:
> 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
On Mon, Apr 27, 2020 at 03:52:44PM +0200, Enric Balletbo i Serra wrote:
> Hi Ricardo,
>
> Thank you for your patch.
>
> On 27/4/20 12:09, Ricardo Cañuelo wrote:
> > This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> > definitions and descriptions were expanded, apart from that i
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 43bcbb6d73c4..6dae00da5d7e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
On Tue, Apr 28, 2020 at 04:12:21PM +0200, Paul Cercueil wrote:
> This one patch will need a V2, I messed up with the clocks.
Looks fine otherwise.
>
> -Paul
>
>
> Le dim. 26 avril 2020 à 20:58, Paul Cercueil a écrit
> :
> > Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.
> >
> >
On Sun, 26 Apr 2020 20:58:55 +0200, Paul Cercueil wrote:
> Convert the ingenic,uart.txt to a new ingenic,uart.yaml file.
>
> A few things were changed in the process:
> - the dmas and dma-names properties are now required.
> - the ingenic,jz4770-uart and ingenic,jz4775-uart compatible strings now
On Sun, 26 Apr 2020 20:58:54 +0200, Paul Cercueil wrote:
> Convert the i2c-jz4780.txt file to ingenic,i2c.yaml.
>
> Two things were changed in the process:
> - the clock-frequency property can now only be set to the two values
> that can be set by the hardware;
> - the dmas and dma-names propert
On Sun, Apr 26, 2020 at 08:58:53PM +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nand.txt doc file to ingenic,nand.yaml.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/mtd/ingenic,jz4780-nand.txt | 92
> .../devicetree/bindings/mtd/ingenic,nand.yaml | 133 +++
On Sun, Apr 26, 2020 at 08:58:52PM +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nemc.txt doc file to ingenic,nemc.yaml.
>
> The ingenic,jz4725b-nemc compatible string was added in the process,
> with a fallback to ingenic,jz4740-nemc.
>
> Signed-off-by: Paul Cercueil
> ---
> .../ing
This patchset adds support for NEC NL10276BC13-01C panel.
Maksim Melnikov (2):
drm/panel-simple: add support for NEC NL10276BC13-01C panel
dt-bindings: display: panel: Add NEC NL10276BC13-01C panel bindings
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-si
Quoting Douglas Anderson (2020-05-07 14:34:55)
> 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: DSIA VSY
Am 11.05.20 um 22:24 schrieb John Paul Adrian Glaubitz:
> On 5/11/20 10:12 PM, Christian König wrote:
>> I unfortunately only have an x86 Mac to test this on, but as far as I know
>> the Radeon
>> AGP support for PowerPC is disabled for years already because it didn't
>> worked reliable.
>
> I ha
Add panel binding for NEC NL10276BC13-01C.
Signed-off-by: Maksim Melnikov
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documentation/devicetree/bindin
On Fri, May 1, 2020 at 2:52 PM Konrad Dybcio wrote:
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 70
> 1 file changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp
On Mon, May 11, 2020 at 3:03 PM Konrad Dybcio wrote:
>
> >Is the "| 0" really adding value here?
>
> As far as I can see, it is present in every other config.
Ah, I forgot about that.
Nothing to see here.
___
dri-devel mailing list
dri-devel@lists.free
On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote:
> CONFIG_DEVICE_PRIVATE cannot be selected in configurations
> without ZONE_DEVICE:
>
> WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
> Depends on [n]: ZONE_DEVICE [=n]
> Selected by [y]:
> - DRM_NOUVEAU_SVM [=y]
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 to
> system memory, the AGP MMU on the chipset or the MMU built into the
> GPU. On powerpc hardware, AGP ha
The NL10276BC13-01C is a 6.5" 1024x768 XGA TFT LCD panel with LVDS interface.
It is used for industrial purposes in devices such as HMI.
Signed-off-by: Maksim Melnikov
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/driv
发件人："Ruhl, Michael J"
发送日期：2020-05-08 23:45:07
收件人：Bernard Zhao ,Alex Deucher
,"Christian König" ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter ,Tom St Denis ,Sam Ravnborg
,Ori Messinger
,"amd-...@lists.freedesktop.org"
,"dri-devel@lists.freedesktop.org"
,"linux-ker...@vger.kernel.
>Is the "| 0" really adding value here?
As far as I can see, it is present in every other config.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sat, May 09, 2020 at 05:16:12PM -0700, Andrew Morton wrote:
> On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
>
> > From: Jason Gunthorpe
> >
> > There is no reason for a user to select this or not directly - it should
> > be selected by drivers that are going to use the feature, s
On Sun, Apr 26, 2020 at 08:58:51PM +0200, Paul Cercueil wrote:
> Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
>
> In the process, some compatible strings now require a fallback, as the
> corresponding SoCs are pin-compatible with their fallback variant.
>
> Signed-off-by: Pau
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'l
We'll need the core channel initialized and ready by the time that we
start creating modesetting objects, so that we can call the
NV507D_GET_CAPABILITIES method to make the hardware expose it's
modesetting capabilities for later probing.
So, when loading the driver prepare the core channel from wi
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
Thi
Currently, nouveau doesn't actually bother to try probing whether or not
it can actually handle interlaced modes over DisplayPort. As a result,
on volta and later we'll end up trying to set an interlaced mode even
when it's not supported and cause the front end for the display engine
to hang.
So,
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul
--
On Sun, 26 Apr 2020 20:58:50 +0200, Paul Cercueil wrote:
> Convert the ingenic,intc.txt doc file to ingenic,intc.yaml.
>
> Some compatible strings now require a fallback, as the controller
> generally works the same across the SoCs families.
>
> Signed-off-by: Paul Cercueil
> ---
> .../interrup
On Sun, 26 Apr 2020 20:58:49 +0200, Paul Cercueil wrote:
> Convert the ingenic,cgu.txt doc file to ingenic,cgu.yaml.
>
> The binding documentation has been updated as well. The node can have a
> child node that corresponds to the USB PHY, which happens to be present
> in the middle of the CGU regi
On Sat, 25 Apr 2020 17:40:37 +0200, Johan Jonker wrote:
> A test with the command below gives this error:
>
> arch/arm64/boot/dts/rockchip/px30-evb.dt.yaml: gpu@ff40:
> '#cooling-cells', 'power-domains'
> do not match any of the regexes: 'pinctrl-[0-9]+'
>
> With the conversion to yaml it als
On Mon, May 11, 2020 at 5:42 PM Alex Deucher wrote:
>
> On Mon, May 11, 2020 at 3:18 AM Paul Menzel wrote:
> >
> > Fix all occurrences with the commands below.
> >
> > $ git grep -l equnce drivers/gpu/ | xargs sed -i 's/equnce/equence/g'
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> >
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 ranges.
>
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed
Hi Alex!
On 5/11/20 10:46 PM, Alex Deucher wrote:
>>> Note there is no loss of functionality here, at least on radeon
>>> hardware. It just comes down to which MMU gets used for access to
>>> system memory, the AGP MMU on the chipset or the MMU built into the
>>> GPU. On powerpc hardware, AGP ha
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 them through the DT, let's add a pretty simple binding.
>
> Cc: Michael Turque
On Mon, May 11, 2020 at 3:18 AM Paul Menzel wrote:
>
> Fix all occurrences with the commands below.
>
> $ git grep -l equnce drivers/gpu/ | xargs sed -i 's/equnce/equence/g'
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: David (ChunMing) Zhou
> Cc: amd-...@lists.freedesktop.org
> Signed-o
Applied. thanks!
Alex
On Sat, May 9, 2020 at 5:05 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:65:18: warning: ‘crtc_offsets’
> defined but not used [-Wunused-const-variable=]
> static const u32 crtc_offsets[6] =
> ^
On Fri, Apr 24, 2020 at 6:26 AM Ricardo Cañuelo
wrote:
>
> This converts the DT binding for the Analogix DP bridge used in
> the Exynos 5 and Rockchip RK3288/RK3399 SoCs to yaml.
>
> Changes from the original binding:
> - phy and phy-names aren't defined as 'required' (rk3399-evb.dts doesn't
> d
On Fri, Apr 24, 2020 at 01:26:34PM +0200, Ricardo Cañuelo wrote:
> This converts the DT binding for the Analogix DP bridge used in
> the Exynos 5 and Rockchip RK3288/RK3399 SoCs to yaml.
>
> Changes from the original binding:
> - phy and phy-names aren't defined as 'required' (rk3399-evb.dts doesn
https://bugzilla.kernel.org/show_bug.cgi?id=207693
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Mon, 11 May 2020 at 21:43, Dave Airlie wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir
> > wrote:
> > >
> > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > > Hi guys,
> > >
> > > > Well let's face it AGP i
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:
>>
>> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
>> Note there is no loss of functionality here, at least on radeon
>> hardware. It just comes down to which MMU gets u
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 to
>> system memory, the AGP MMU on the
On Monday, May 11, 2020, 4:27:55 PM, Alex Deucher wrote:
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
>>
>> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
>> > Hi guys,
>>
>> > Well let's face it AGP is a total headache to maintain and dead for at
>> > least 10+ years.
>>
>
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.
> >>
> >> I would
On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
>
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
> >
> > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > Hi guys,
> >
> > > Well let's face it AGP is a total headache to maintain and dead for at
> > > least 10+ years.
>
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.
>>
>> I would be against such a move as AGP graphics is still used by people
>> running the pow
On Mon, May 11, 2020 at 8:29 AM Daniel Vetter wrote:
>
> On Mon, May 11, 2020 at 5:24 PM Rob Clark wrote:
> >
> > On Mon, May 11, 2020 at 2:36 AM Daniel Vetter
> > wrote:
> > >
> > > I honestly don't exactly understand what's going on here, but the
> > > current code is wrong for sure: It calls
https://bugzilla.kernel.org/show_bug.cgi?id=207693
Bug ID: 207693
Summary: amdgpu: RX 5500 XT boost frequency out of spec
Product: Drivers
Version: 2.5
Kernel Version: 5.6.12
Hardware: All
OS: Linux
Tree: Main
On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
>
> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > 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 indepen
On Wed, May 6, 2020 at 11:32 AM Sam Ravnborg wrote:
>
> Hi Dmitry
>
> On Sat, Apr 18, 2020 at 08:06:58PM +0300, Dmitry Osipenko wrote:
> > In some case, like a DRM display code for example, it's useful to silently
> > check whether port node exists at all in a device-tree before proceeding
> > wit
On 5/11/20 10:12 PM, Christian König wrote:
> I unfortunately only have an x86 Mac to test this on, but as far as I know
> the Radeon
> AGP support for PowerPC is disabled for years already because it didn't
> worked reliable.
I have a current Debian unstable running on an iBook G4 with Radeon g
On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> 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, abusin
Am 11.05.20 um 21:55 schrieb John Paul Adrian Glaubitz:
Hi Christian!
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
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 functionality here.
Something like:
"There is no loss of f
On Mon, May 11, 2020 at 4:02 PM John Paul Adrian Glaubitz
wrote:
>
> Hi Christian!
>
> > 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 g
Hi Christian!
> 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 DMA API on multiple occasions, need to
> distinc
https://bugzilla.kernel.org/show_bug.cgi?id=201505
Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) changed:
What|Removed |Added
Status|NEW
On Wed, Apr 22, 2020 at 11:38:14AM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> -
>-Original Message-
>From: dri-devel On Behalf Of
>Ruhl, Michael J
>Sent: Monday, May 11, 2020 2:13 PM
>To: Daniel Vetter ; LKML ker...@vger.kernel.org>
>Cc: Intel Graphics Development ; DRI
>Development ; linaro-mm-
>s...@lists.linaro.org; Vetter, Daniel ; linux-
>me...@vger.kernel.org
>S
>-Original Message-
>From: Intel-gfx On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML
>Cc: Daniel Vetter ; Intel Graphics Development
>; DRI Development de...@lists.freedesktop.org>; linaro-mm-...@lists.linaro.org; Vetter, Daniel
>; Sumit Semwal ; linux-
>me...@vg
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Monday, May 11, 2020 5:12 AM
>To: LKML
>Cc: David Airlie ; Daniel Vetter ;
>Intel Graphics Development ; DRI
>Development ; Thomas Zimmermann
>; Vetter, Daniel
>Subject: [PATCH 1/3] drm/writeback: don't set fence->op
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 discussion from
the "RFC: Drm-connector properties managed by another driver / privacy
screen support" mail thread on top, hence the v2.
The most important t
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
"privacy-screen hw-state", to deal with devices where the OS might be
lo
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 1 -
drivers/gpu/drm/ttm/ttm_agp_backend.c | 150 --
include/drm/ttm/ttm_set_memory.h | 44
include/drm/ttm/ttm_tt.h | 22
4 files changed, 21
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 DMA API on multiple
occasions, need to distinct between AGP and
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 46 +
drivers/gpu/drm/n
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile| 4 +-
drivers/gpu/drm/radeon/evergreen.c | 7 -
drivers/gpu/drm/radeon/r100.c
On 5/11/20 5:26 AM, Pekka Paalanen wrote:
On Sat, 9 May 2020 14:51:44 -0400
Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working
solution as there are a few unresolved issues we are hopping to get
advise on from people on the mailing list. Until now extractin
Hi Ricardo.
On Mon, May 11, 2020 at 04:59:11PM +0200, Ricardo Cañuelo wrote:
> Hi Rob,
>
> What's your opinion on this?
I'm not Rob, but anyway.
>
> Some context: It's about bindings that define signed integer properties
> with range checks that go below and above zero. The schema checker fails
Quoting Douglas Anderson (2020-05-07 14:34:58)
> 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.
>
> Signed-off-by: Douglas Anderson
> ---
Reviewed-by: S
On 05/05/2020 09:45, 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 the e
On Mon, May 11, 2020 at 5:24 PM Rob Clark wrote:
>
> On Mon, May 11, 2020 at 2:36 AM Daniel Vetter wrote:
> >
> > I honestly don't exactly understand what's going on here, but the
> > current code is wrong for sure: It calls dma_buf_vunmap without ever
> > calling dma_buf_vmap.
> >
> > What I'm n
On Mon, May 11, 2020 at 2:36 AM Daniel Vetter wrote:
>
> I honestly don't exactly understand what's going on here, but the
> current code is wrong for sure: It calls dma_buf_vunmap without ever
> calling dma_buf_vmap.
>
> What I'm not sure about is whether the WARN_ON is correct:
> - msm imports d
https://bugzilla.kernel.org/show_bug.cgi?id=203033
--- Comment #4 from Mathieu Malaterre (mathieu.malate...@gmail.com) ---
$ uname -a
Linux vostrodell 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1
(2020-03-09) x86_64 GNU/Linux
--
You are receiving this mail because:
You are watching the ass
On Mon, May 11, 2020 at 4:49 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> > +bool kthread_queue_flush_work(struct kthread_work *work,
> > + struct kthread_flush_work *fwork);
> > +void __kthread_flush_work_fn(struct kthr
On Fri, May 08, 2020 at 04:46:52PM -0400, Lyude Paul wrote:
> Add some simple wrappers around incrementing/decrementing
> kthread_work.cancelling under lock, along with checking whether queuing
> is currently allowed on a given kthread_work, which we'll use want to
> implement work cancelling with
https://bugzilla.kernel.org/show_bug.cgi?id=203033
--- Comment #3 from Mathieu Malaterre (mathieu.malate...@gmail.com) ---
Forgot to include hardware information:
$ lspci -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240]
(rev a2)
--
You are receiving this m
https://bugzilla.kernel.org/show_bug.cgi?id=203033
--- Comment #2 from Mathieu Malaterre (mathieu.malate...@gmail.com) ---
Same here:
May 11 16:54:31 vostrodell kernel: [ 605.330992] INFO: task kworker/u8:3:162
blocked for more than 120 seconds.
May 11 16:54:31 vostrodell kernel: [ 605.330997]
Hi Rob,
What's your opinion on this?
Some context: It's about bindings that define signed integer properties
with range checks that go below and above zero. The schema checker fails
because, apparently, it interprets every cell value as an uint32, which
makes the range check fail for negative num
Hello,
On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> +bool kthread_queue_flush_work(struct kthread_work *work,
> + struct kthread_flush_work *fwork);
> +void __kthread_flush_work_fn(struct kthread_work *work);
As an exposed interface, this doesn't seem gr
On Mon, May 11, 2020 at 4:08 PM Lukas Wunner wrote:
>
> On Mon, May 11, 2020 at 02:21:57PM +0200, Daniel Vetter wrote:
> > On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
> > > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > > > - One unfortunate thing with drm_dev_unplug i
On Mon, May 11, 2020 at 02:21:57PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
> > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > > - One unfortunate thing with drm_dev_unplug is that the driver core is
> > > very opinionated and doesn't
On Mon, May 11, 2020 at 09:53:18AM +0200, Linus Walleij wrote:
> This converts the lms283gf05 backlight driver to use GPIO
> descriptors and switches the single PXA Palm Z2 device
> over to defining these.
>
> Since the platform data was only used to convey GPIO
> information we can delete the pla
On Mon, May 11, 2020 at 02:41:13PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
> wrote:
> >
> > On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi
> > > wrote:
> > > >
> > > > On Fri, Apr 17, 2020 at 09
https://bugzilla.kernel.org/show_bug.cgi?id=207595
--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
If using X, you can also use `xrandr --verbose` to see number of crtcs.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=207595
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
You can ask any KMS driver via the drmModeGetResources() function call in
libdrm.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, May 11, 2020 at 2:34 PM Christian König
wrote:
>
> Am 11.05.20 um 13:19 schrieb Daniel Vetter:
> > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> >> On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
> >>> This RFC is a more of a proof of concept then a fu
On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
wrote:
>
> On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> > >
> > > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 17, 2020 at 08:10:26PM +020
Hi
Am 30.04.20 um 10:23 schrieb Thomas Zimmermann:
> Hi
>
> Am 29.04.20 um 20:20 schrieb Sam Ravnborg:
>> Hi Thomas,
>>
>> On Wed, Apr 29, 2020 at 04:32:26PM +0200, Thomas Zimmermann wrote:
>>> All register names and fields are now named according to the
>>> MGA programming manuals. The function
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are releva
On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> >
> > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 17, 2020 at 08:10:26PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 17, 2020 at 5:43 PM Vi
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are releva
Am 11.05.20 um 13:19 schrieb Daniel Vetter:
On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working solution as there
are a few unresolved issues we are hoppi
Am 11.05.20 um 11:26 schrieb Pekka Paalanen:
On Sat, 9 May 2020 14:51:44 -0400
Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working
solution as there are a few unresolved issues we are hopping to get
advise on from people on the mailing list. Until now extract
On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
>
> On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > - One unfortunate thing with drm_dev_unplug is that the driver core is
> > very opinionated and doesn't tell you whether it's a hotunplug or a
> > driver unload. In the fo
1 - 100 of 179 matches
Mail list logo
