Am Dienstag, dem 20.04.2021 um 13:47 + schrieb Robin Gong:
> On 2021/04/19 17:46 Lucas Stach wrote:
> > Am Montag, dem 19.04.2021 um 07:17 + schrieb Robin Gong:
> > > Hi Lucas,
> > >
> > > On 2021/04/14 Lucas Stach wrote:
> > > > Hi Robin,
Am Montag, dem 19.04.2021 um 07:17 + schrieb Robin Gong:
> Hi Lucas,
>
> On 2021/04/14 Lucas Stach wrote:
> > Hi Robin,
> >
> > Am Mittwoch, dem 14.04.2021 um 14:33 + schrieb Robin Gong:
> > > On 2020/05/20 17:43 Lucas Stach wrote:
> > &g
Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
> Le 16/04/2021 à 12:54, Lucas Stach a écrit :
> > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > > In order to be able to share the control hardware block between
> > >
Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> In order to be able to share the control hardware block between
> VPUs use a syscon instead a ioremap it in the driver.
> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
> phandle is not found look at 'ctrl'
Hi Robin,
Am Mittwoch, dem 14.04.2021 um 14:33 + schrieb Robin Gong:
> On 2020/05/20 17:43 Lucas Stach wrote:
> > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > Hi
> > >
> > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> >
Hi Russell,
sorry for the noise of this arriving in your inbox twice. Apparently I
messed up and replied in private in my last mail.
Am Dienstag, dem 13.04.2021 um 11:51 +0100 schrieb Russell King - ARM Linux
admin:
> On Tue, Apr 13, 2021 at 12:00:45PM +0200, Lucas Stach wrote:
> >
ch a case is to apply this series and look for any
fallout.
So for what it is worth:
Acked-by: Lucas Stach
> regards,
> Oleksij
>
> Oleksij Rempel (7):
> ARM: imx6q: remove PHY fixup for KSZ9031
> ARM: imx6q: remove TX clock delay of ar8031_phy_fixup()
> ARM: imx6q
me this sounds much like the reasoning for the etnaviv
dependency. There is no actual build dependency, as the allocations are
done through the DMA API, but for the allocations to succeed you most
likely want CMA to be enabled. But that's just an observation from the
outside, I have no real clue about
Hi Adrien,
I feel like I already mentioned to you some time ago that there is
already a much more complete patch series to add this functionality on
the list [1].
If you want this functionality to go upstream, please help test and
extend this patch series.
Regards,
Lucas
[1]
_BYPASS bits of GPR registers should be cleared from default
> value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
> turned on.
>
> Signed-off-by: Richard Zhu
Reviewed-by: Lucas Stach
> ---
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 3 +++
&
VREG_BYPASS bits of GPR registers should be cleared from default
> value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
> turned on.
>
> Signed-off-by: Richard Zhu
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 20
VREG_BYPASS bits of GPR registers should be cleared from default
> value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
> turned on.
>
> Signed-off-by: Richard Zhu
Reviewed-by: Lucas Stach
I guess you need to split this patch out of the series and post it for
Shawn
Am Donnerstag, dem 25.03.2021 um 16:44 +0800 schrieb Richard Zhu:
> Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> the VREG_BYPASS
Am Mittwoch, dem 24.03.2021 um 13:34 +0800 schrieb Richard Zhu:
> Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> the VREG_BYPASS
Hi Richard,
Am Mittwoch, dem 24.03.2021 um 13:34 +0800 schrieb Richard Zhu:
> Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> the
Hi Richard,
Am Montag, dem 22.03.2021 um 09:06 + schrieb Richard Zhu:
> > -Original Message-
> > From: Lucas Stach
> > Sent: Friday, March 19, 2021 5:49 PM
> > To: Richard Zhu ; andrew.smir...@gmail.com;
> > shawn...@kernel.org; k...@linux.com
Am Freitag, dem 19.03.2021 um 16:24 +0800 schrieb Richard Zhu:
> Both 1.8v and 3.3v power supplies can be feeded to i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> the VREG_BYPASS
Am Mittwoch, dem 17.02.2021 um 16:39 -0300 schrieb Ezequiel Garcia:
> Hi Benjamin,
>
> On Wed, 2021-02-17 at 09:02 +0100, Benjamin Gaignard wrote:
> > Define allocation range for the default CMA region.
> >
> > Signed-off-by: Benjamin Gaignard
> > Signed-off-by: Ezequiel Garcia
>
> Despite it
e too.
>
> Signed-off-by: Richard Zhu
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 0cf1333c0440..8
Am Montag, dem 15.02.2021 um 10:54 -0500 schrieb Sven Van Asbroeck:
> Hi Lucas,
>
> On Mon, Feb 15, 2021 at 5:15 AM Lucas Stach wrote:
> >
> > The straight forward way to fix this would be to just disable the PRE
> > when the stride is getting too large, which might
Am Montag, dem 15.02.2021 um 13:04 +0100 schrieb Christian König:
> Am 15.02.21 um 12:53 schrieb Lucas Stach:
> > Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
> > > Am 15.02.21 um 10:06 schrieb Simon Ser:
> > > > On Monday, February 15th, 20
Am Montag, dem 15.02.2021 um 10:34 +0100 schrieb Christian König:
>
> Am 15.02.21 um 10:06 schrieb Simon Ser:
> > On Monday, February 15th, 2021 at 9:58 AM, Christian König
> > wrote:
> >
> > > we are currently working an Freesync and direct scan out from system
> > > memory on AMD APUs in A+A
Am Samstag, dem 13.02.2021 um 18:40 +0100 schrieb Pavel Machek:
> Hi!
>
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order to identify when two fd (e.g. device
> >
Hi Sven,
Am Freitag, dem 12.02.2021 um 18:52 -0500 schrieb Sven Van Asbroeck:
> Philipp, Fabio,
>
> I was able to verify that the PREs do indeed overrun their allocated ocram
> area.
>
> Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size
> required: width(pixels) x 8 lines x 4
Drewry
> Cc: Andrew Morton
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Lucas Stach
> ---
> init/Kconfig | 11 +++
> kernel/Makefile | 2 +-
> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
>
Am Mittwoch, dem 16.12.2020 um 12:42 +0100 schrieb Christian Gmeiner:
> Make it possible for the user space to access these ID values.
Thanks, I've added this patch to my etnaviv/next branch.
Regards,
Lucas
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
Hi Guido,
this time hopefully with less broken quoting. My mailer is driving me
mad right now...
Am Mittwoch, dem 16.12.2020 um 12:27 +0100 schrieb Guido Günther:
> This allows us to shut down the mipi power domain on the imx8. The
> alternative would be to drop the dphy from the mipi power
Hi Guido,
Am Mittwoch, dem 16.12.2020 um 12:27 +0100 schrieb Guido Günther:
This allows us to shut down the mipi power domain on the imx8. The
alternative would be to drop the dphy from the mipi power domain in the
SOCs device tree and only have the DSI host controller visible there but
since the
Hi Steven,
Am Montag, den 07.12.2020, 14:47 -0500 schrieb Steven Rostedt:
On Mon, 07 Dec 2020 17:24:58 +0100
Lucas Stach wrote:
> I would be happy to test a patch on our whimpy machines, though. :)
Let me know if this helps:
-- Steve
diff --git a/kernel/trace/trace.c b/kernel/trace/trac
ce script
> wasn't working, to let people know I was on vacation.
No problem, I already figured that this might have fallen through the
cracks. It's also not really a high prio issue for us.
> On Mon, 07 Sep 2020 18:16:52 +0200
> Lucas Stach wrote:
>
> > Hi all,
> >
> >
Am Dienstag, den 01.12.2020, 12:34 +0100 schrieb Guido Günther:
> This allows us to raise DRAM bandiwth to a high enough value for a
> stable picture on i.mx8mq. We pick a bandwidth that should be sufficient
> for 4k@60Hz.
>
> Modelled like mdp5_kms.
>
> Signed-off-by: Guido Günther
> ---
>
Am Dienstag, den 01.12.2020, 11:01 +0100 schrieb Martin Kepplinger:
> Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely
> available for testing.
>
> Signed-off-by: Martin Kepplinger
> ---
> arch/arm64/configs/defconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2
Am Dienstag, den 01.12.2020, 11:01 +0100 schrieb Martin Kepplinger:
> Add interconnect ports for lcdif to set bus capabilities.
>
> Signed-off-by: Martin Kepplinger
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git
Am Dienstag, den 01.12.2020, 11:37 +0100 schrieb Martin Kepplinger:
> Add interconnect support to mxsfb so that it is able to request enough
> bandwidth to DDR for display output to work.
>
> Signed-off-by: Martin Kepplinger
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 33
On Do, 2020-11-05 at 16:50 +0200, Laurentiu Palcu wrote:
> This patch adds support for using NN interpolation scaling by setting the
> SCALING_FILTER plane property to 1. Otherwise, the default method is used.
>
> Signed-off-by: Laurentiu Palcu
Reviewed and pushed into drm-misc-next.
Regards,
On Do, 2020-11-05 at 16:01 +0200, Laurentiu Palcu wrote:
> Hi,
>
> This patchset fixes 90/270 rotations for Vivante tiled and super-tiled
> formats and a Coccinelle warning.
Thanks, looks good. I've pushed them into drm-misc-next.
Regards,
Lucas
On Mi, 2020-11-25 at 12:39 +0200, Laurentiu Palcu wrote:
> This patch adds the node for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
Reviewed-by: Lucas Stach
> ---
> Hi,
>
> This is, actually, a resend of the patch because we decided to drop it
Hi Lukas,
just some general comments, not a full review.
Am Dienstag, den 24.11.2020, 18:27 +0100 schrieb Lukas F. Hartmann:
> This is the device tree for the MNT Reform 2.0 open hardware laptop
> which is based on NXP i.MX8MQ. It is designed around the Boundary Devices
> Nitrogen8M SoM.
Since
Am Donnerstag, den 29.10.2020, 07:18 -0500 schrieb Adam Ford:
> On Thu, Oct 29, 2020 at 6:55 AM Lucas Stach
> wrote:
> > Am Montag, den 26.10.2020, 11:23 -0500 schrieb Adam Ford:
> > > On Mon, Oct 26, 2020 at 10:44 AM Lucas Stach <
> > > l.st...@pengutronix.
Am Montag, den 26.10.2020, 11:23 -0500 schrieb Adam Ford:
> On Mon, Oct 26, 2020 at 10:44 AM Lucas Stach wrote:
> > Am Montag, den 26.10.2020, 10:12 -0500 schrieb Adam Ford:
> > > On Mon, Oct 26, 2020 at 9:55 AM Abel Vesa wrote:
> > > > On 20-10-25 11:05:32, Ada
PD, it was trying
> to blindly write/read the gate bit and therefore freeze.
>
> > Unfortunately, the i.MX8MN needs to have 0x100 written to both
> > 32e28000 and 32e28004, and the values written for the 8MM are not
> > compatible.
> > By forcing the GPC to
t; > >
> >
> > Yeah, that makes sense. Basically, it was trying to disable unused clocks
> > (see clk_disable_unused) but in order to disable the clocks from the
> > media BLK_CTL (which I think should be renamed in display BLK_CTL) the
> > PD need to be on. Sin
On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> From: Rob Clark
>
> If there is only a single ring (no-preemption), everything is FIFO order
> and there is no need to implicit-sync.
>
> Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> is undefined when fences are
On Do, 2020-10-22 at 13:31 -0500, Adam Ford wrote:
> On Thu, Oct 22, 2020 at 1:17 PM Marek Vasut wrote:
> > On 10/22/20 7:16 PM, Adam Ford wrote:
> > > According to the documentation from NXP, the i.MX8M Nano has a
> > > Vivante GC7000 Ultra Lite as its GPU core.
> > >
> > > With this patch, the
On Fr, 2020-09-25 at 08:59 +0200, Jens Wiklander wrote:
> On Fri, Sep 18, 2020 at 7:45 PM Rouven Czerwinski
> wrote:
> > On Kernels with CONFIG_PREEMPT_NONE might_sleep() is not enough to force
> > rescheduling, replace it with a resched check and cond_resched. Fixes
> > the following stall:
> >
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 46fcc4b00c3cca8adb9b7c9afdd499f64e427135
Gitweb:
https://git.kernel.org/tip/46fcc4b00c3cca8adb9b7c9afdd499f64e427135
Author:Lucas Stach
AuthorDate:Mon, 31 Aug 2020 13:07:19 +02:00
Committer
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> These two perf counters represent the total read and write
> GPU bandwidth in terms of 64bits.
>
> The used sequence was taken from Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
> ---
>
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> This little patch set adds support for the total bandwidth used by HI. The
> basic hi bandwidth read-out is quite simple but I needed to add some little
> clean-ups to make it nice looking.
>
> Christian Gmeiner (4):
> drm/etnaviv:
On Mi, 2020-09-23 at 11:45 +0200, Oleksij Rempel wrote:
> Add Protonic Holland WD3 iMX6qp based board
>
> Signed-off-by: Oleksij Rempel
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
On Do, 2020-09-10 at 13:21 +0300, Laurentiu Palcu wrote:
> On Thu, Sep 10, 2020 at 11:57:10AM +0200, Daniel Vetter wrote:
> > On Thu, Sep 10, 2020 at 11:53 AM Laurentiu Palcu
> > wrote:
> > > When compiling for 32bit platforms, the compilation fails with:
> > >
> > > ERROR: modpost:
Hi Laurentiu,
On Mo, 2020-08-31 at 14:24 +0300, Laurentiu Palcu wrote:
> Hi Lucas, Sam,
>
> On Mon, Aug 31, 2020 at 12:37:23PM +0200, Lucas Stach wrote:
> > Hi Laurentiu,
> >
> > On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote:
> > > Hi Lucas
On Mi, 2020-09-02 at 11:43 +0200, pet...@infradead.org wrote:
> On Wed, Sep 02, 2020 at 08:00:24AM +0200, Juri Lelli wrote:
> > On 31/08/20 13:07, Lucas Stach wrote:
> > > When a boosted task gets throttled, what normally happens is that it's
> > > immediately enqueued a
Hi all,
one of my colleagues has taken a look at device boot times and stumbled
across a pretty big amount of kernel boot time being spent in
tracer_init_tracefs(). On this particular i.MX6Q based device the
kernel spends more than 1 second in this function, which is a
significant amount of the
x8mq: add GPC power domains")
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lucas Stach
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts
grp$', 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lucas Stach
> ---
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dt
On Fr, 2020-09-04 at 16:53 +0200, Krzysztof Kozlowski wrote:
> Remove whitespace at the end of line.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lucas Stach
> ---
> Documentation/devicetree/bindings/gpu/vivante,gc.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 del
interrupt-cells', 'interrupt-controller' do not match any of the
> regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lucas Stach
> ---
> Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 4
> 1 file changed, 4 insertions(+)
>
>
'assigned-clock-parents', 'assigned-clock-rates',
> 'assigned-clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Lucas Stach
> ---
> Documentation/devicetree/bindings/gpu/vivante,gc.yaml | 7 +++
> 1 file changed
lmost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Robin Murphy
Acked-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 12
.
Clear the dl_throttled flag before dropping back to the normal scheduling
class to fix this issue.
Signed-off-by: Lucas Stach
---
This is the root cause and fix of the issue described at [1]. After working
on other stuff for the last few months, I finally was able to circle back
to this issue
Hi Laurentiu,
On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote:
> Hi Lucas,
>
> I was wondering about the plans to merge this series. Since not many
> people can test it properly due to lack of DCSS support in the upstream
> NWL driver (which I heard it's coming soon) and a completely
Hi Russell,
Am Sonntag, den 23.08.2020, 20:19 +0100 schrieb Russell King - ARM Linux admin:
> On Sun, Aug 23, 2020 at 09:10:25PM +0200, Christian Gmeiner wrote:
> > Hi
> >
> > > I have formally tested the patch with 5.7.10 - and it doesn't resolve
> > > the issue - sadly :(
> > >
> > > From my
Am Sonntag, den 23.08.2020, 21:09 +0200 schrieb Christian Gmeiner:
> It looks like that this GPU core triggers an abort when
> reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID.
>
> I looked at different versions of Vivante's kernel driver and did
> not found anything about this issue or
Am Dienstag, den 11.08.2020, 09:29 +0800 schrieb Anson Huang:
> When devm_clk_get() returns -EPROBE_DEFER, i.MX6 PCI driver should
> NOT print error message, use dev_err_probe() to handle it.
>
> Signed-off-by: Anson Huang
Reviewed-by: Lucas Stach
> ---
> drivers/pci/contr
Am Dienstag, den 04.08.2020, 13:38 +0800 schrieb Anson Huang:
> When devm_clk_get() returns -EPROBE_DEFER, i.MX6 PCI driver should
> NOT print error message, just return -EPROBE_DEFER is enough.
The reasoning behind this change is fine, but I think we should use the
recently merged
Am Dienstag, den 21.07.2020, 15:44 +0800 schrieb Richard Zhu:
> Add one regulator, used to power up the external oscillator,
> and enable PCIe on iMX6QP SABRESD board.
That's not the right thing to do. If there is an external oscillator,
which requires a power supply then the oscillator should
Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu:
> Hi Lukas and Daniel,
>
> On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> > > Am Freitag, den 17.07.2020, 10:59 +02
Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote:
> > Hi Laurentiu,
> >
> > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> > > From: Laurentiu Palcu
> > >
> >
Hi Laurentiu,
Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> From: Laurentiu Palcu
>
> Hi,
>
> This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> includes only graphics plane support (no video planes), no HDR10 capabilities,
> no graphics
Hi Christian,
Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> This patch series add support for loadavg values for GPU
> sub-components. I am adding a SMA algorithm as I was not
> really sure if EWMA would be a good fit for this use case.
1 second is a pretty long window in
Hi Christian,
Am Freitag, den 10.07.2020, 09:41 +0200 schrieb Christian Gmeiner:
> The GPU has an idle state register where each bit represents the idle
> state of a sub-GPU component like FE or TX. Sample this register
> every 10ms and calculate a simple moving average over the sub-GPU
>
Am Dienstag, den 16.06.2020, 23:21 +0200 schrieb Lubomir Rintel:
> Hi,
>
> please consider applying patches that are chained to this message.
Thanks, I've applied all of them to etnaviv/next.
Regards,
Lucas
> They make getting/enabling the clocks in the etnaviv driver slightly nicer,
> first
;Explicit pinning of user-space pages":
> https://lwn.net/Articles/807108/
>
> Signed-off-by: John Hubbard
Thanks, I've applied this to etnaviv/next.
Regards,
Lucas
> ---
>
> Hi,
>
> Changes since v1:
>
> * Rebased onto Linux 5.7-rc7
>
&g
Hi Navid,
Am Montag, den 15.06.2020, 01:12 -0500 schrieb Navid Emamdoost:
> in etnaviv_gpu_submit, etnaviv_gpu_recover_hang, etnaviv_gpu_debugfs,
> and etnaviv_gpu_init the call to pm_runtime_get_sync increments the
> counter even in case of failure, leading to incorrect ref count.
> In case of
Hi Lubomir,
Am Mittwoch, den 17.06.2020, 00:44 +0200 schrieb Lubomir Rintel:
> Hi,
>
> please consider applying the patches chained to this message. It's the
> fifth version of the driver for the ENE KB3930 Embedded Controller.
>
> This version is essentially a resend of v4. The only actual
Am Mittwoch, den 20.05.2020, 15:38 +0200 schrieb Lubomir Rintel:
> On Thu, May 14, 2020 at 09:53:08AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote:
> > > Am Donnerstag, den 14.05.2020, 09:27 +0100 schri
Hi Martin,
Am Mittwoch, den 20.05.2020, 12:10 +0200 schrieb Martin Fuzzey:
> When using mmap() on a prime imported buffer allocated by a
> different driver (such as imx-drm) the later munmap() does
> not correctly decrement the refcount of the original enaviv_gem_object,
> leading to a leak.
>
>
Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> Hi
>
> On Tue, May 19, 2020 at 6:04 PM Lucas Stach wrote:
> > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > There are two requirements that we need to move the request
> &g
Am Dienstag, den 19.05.2020, 07:30 +0200 schrieb Christian Gmeiner:
> 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 -
Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> There are two requirements that we need to move the request
> of dma channel from probe to open.
How do you handle -EPROBE_DEFER return code from the channel request if
you don't do it in probe?
> - When dma device binds with
Hi Christian,
Am Montag, den 11.05.2020, 14:37 +0200 schrieb Christian Gmeiner:
> 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
Am Freitag, den 15.05.2020, 12:27 +0200 schrieb Christian Gmeiner:
> Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach
> :
> > Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > > Hi Christian,
> > >
> > > Le ven. 15 mai 2020 à
Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> Hi Christian,
>
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > :
> > > The GC860 has one GPU device which has a 2d and 3d core. In this
> > > case
Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux
admin:
> On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > > On Wed, May 13, 2020 at 2:09 PM Fa
Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote:
>
> > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > says that only the 'reg' clock could be optional, the others are
> > required.
>
>
Am Montag, den 27.04.2020, 15:37 + schrieb Jacky Bai:
> > -Original Message-
> > From: Lucas Stach
> > Sent: Monday, April 27, 2020 11:11 PM
> > To: Abel Vesa ; Jacky Bai ; Shawn
> > Guo ; Sascha Hauer ; Liam
> > Girdwood ; Mark Brown
> > C
Am Sonntag, den 03.05.2020, 09:49 -0500 schrieb Adam Ford:
> On Thu, Apr 30, 2020 at 7:46 AM Schrempf Frieder
> wrote:
> > From: Frieder Schrempf
> >
> > According to the documents, the i.MX8M-Mini features a GC320 and a
> > GCNanoUltra GPU core. Etnaviv detects them as:
> >
> >
Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> From: Frieder Schrempf
>
> On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
> Changing the order of clock initalization to
>
> core -> shader -> bus -> reg
>
> fixes the issue. This is the same order
Hi Frieder,
Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
> From: Frieder Schrempf
>
> On i.MX8MM there is an interrupt getting triggered immediately after
> requesting the IRQ, which leads to a stall as the handler accesses
> the GPU registers whithout the clock being
pecify "INT2" since providing
> two interrupts is not necessary or useful (the driver will only use
> one).
>
> Signed-off-by: Fabio Estevam
> [andrew.smir...@gmail.com modified the patch to drop INT1]
> Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
> Cc: Fa
Am Montag, den 21.10.2019, 21:05 -0700 schrieb Andrey Smirnov:
> Specify 'vdd' and 'vddio' supplies for accelerometer to avoid warnings
> during boot.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
> Cc: Fabio Estevam
> Cc: Chris Healy
> Cc: Lucas Stach
arning in this case.
Regards,
Lucas
> Signed-off-by: Andrey Smirnov
> Cc: Fabio Estevam
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Shawn Guo
> Cc: linux-arm-ker...@lists.infradead.org,
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/imx6qdl-zii-rdu2
On Fr, 2019-10-18 at 15:50 +0200, Guido Günther wrote:
> Hi,
> On Wed, Sep 11, 2019 at 07:40:36PM -0700, Guido Günther wrote:
> > Add #cooling-cells for when the gpu acts as a cooling device.
> >
> > Signed-off-by: Guido Günther
> > ---
> >
On Fr, 2019-08-16 at 22:59 +0200, Heiner Kallweit wrote:
> On 15.08.2019 17:32, Christian Herber wrote:
> > This patch adds basic support for BASE-T1 PHYs in the framework.
> > BASE-T1 PHYs main area of application are automotive and industrial.
> > BASE-T1 is standardized in IEEE 802.3, namely
>
ng: obsolete array initializer, use C99
> syntax
> drivers/soc/imx/gpc.c:269:34: warning: obsolete array initializer, use C99
> syntax
> drivers/soc/imx/gpc.c:278:30: warning: obsolete array initializer, use C99
> syntax
>
> Signed-off-by: Ben Dooks
Reviewed-by: Lucas Stach
&g
Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM
Linux admin:
> On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote:
> > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux
> > admin wrote:
> > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport
Am Donnerstag, den 03.10.2019, 14:30 +0300 schrieb Mike Rapoport:
> On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote:
> > > (trimmed the CC)
> > >
> > > On Wed, Oct 02, 2019 at 06:14:11AM -0500,
Am Montag, den 23.09.2019, 13:12 -0300 schrieb Fabio Estevam:
> Hi Laurentiu,
>
> On Mon, Sep 23, 2019 at 11:14 AM Laurentiu Palcu
> wrote:
>
> > +
> > + dcss: dcss@0x32e0 {
>
> Node names should be generic, so:
>
> dcss: display-controller@32e0
>
> > +
y restart the channel.
> > >
> > > As sdmac->desc is constant we can move desc out of the loop.
> > >
> > > Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
> > > Signed-off-by: Philipp Puschmann
> > &g
Hi Philipp,
On Do, 2019-09-19 at 12:23 +0200, Philipp Puschmann wrote:
> BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the
> buffer, when 0 ARM owns it. When processing the buffers in
> sdma_update_channel_loop the ownership of the currently processed
> buffer was set to SDMA again
1 - 100 of 976 matches
Mail list logo
