A very unfortunate aspect of tc_write()/tc_read() macro helpers is
that they capture quite a bit of context around them and thus require
the caller to have magic variables 'ret' and 'tc' as well as label
'err'. That makes a number of code paths rather counter-intuitive and
somewhat clunky, for
tc_get_display_props() never reads more than a byte via AUX, so
there's no need to reserve 8 for that purpose. No function change
intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Move common code converting clock rate to an appropriate constant and
configuring SYS_PLLPARAM register into a separate routine and convert
the rest of the code to use it. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Cc:
We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so
we may as well hardcode that value and simplify function's signature.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp
Simplify AUX data write by dropping index arithmetic and shifting and
replacing it with a call to a helper function that does two things:
1. Copies user-provided data into a write buffer
2. Transfers contents of the write buffer to up to 4 32-bit
registers on the chip
Note that
Don't assume that requested data transfer size is the same as amount
of data that was transferred. Change the code to get that information
from DP0_AUXSTATUS instead.
Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it
will always called after tc_aux_wait_busy()) and there's only
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in
tc_wait_pll_lock() is always called as a follow-up for updating
PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
things, merge the two operation into a single helper function
tc_pllupdate() and convert the rest of the code to use it. No
functional change intended.
We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be
enough. This also gets rid of a magic number as a bonus.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc:
Simplify AUX data read by removing index arithmetic and shifting with
a helper function that does two things:
1. Fetch data from up to 4 32-bit registers from the chip
2. Copy read data into user provided array.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Transfer size of zero means a request to do an address-only
transfer. Since the HW support this, we probably shouldn't be just
ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
through, since it is supported by the HW as well.
Signed-off-by: Andrey Smirnov
Reviewed-by:
Simplify tc_set_video_mode() by replacing explicit shifting using
macros from . No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc: Chris
Replace explicit polling in tc_link_training() with equivalent call to
tc_poll_timeout() for simplicity. No functional change intended (not
including slightly altered debug output).
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi
Replace explicit polling loop with equivalent call to
tc_poll_timeout() for brevity. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Andrzej Hajda
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Andrey Gusakov
Cc: Philipp Zabel
Cc: Cory Tusar
Cc:
Everyone:
This series contains various improvements (at least in my mind) and
fixes that I made to tc358767 while working with the code of the
driver. Hopefuly each patch is self explanatory.
Feedback is welcome!
Thanks,
Andrey Smirnov
Changes since [v5]:
- Fixed regression in
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.
On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
wrote:
>
> On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > dmesg
> >
> > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> > nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> > nouveau :01:00.0: fifo:
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #94 from Diego Viola ---
This bug is still present with mesa 19.1.0-1.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Wed, Jun 12, 2019 at 9:22 AM Andrey Smirnov wrote:
>
> On Wed, Jun 12, 2019 at 5:48 AM Tomi Valkeinen wrote:
> >
> > Hi,
> >
> > On 12/06/2019 11:32, Andrey Smirnov wrote:
> > > Transfer size of zero means a request to do an address-only
> > > transfer. Since the HW support this, we probably
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/Makefile.header-test
between commit:
e846f0dc57f4 ("kbuild: add support for ensuring headers are self-contained")
from the kbuild tree and commits:
112ed2d31a46 ("drm/i915: Move GraphicsTechnology
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #71 from Richard Thier ---
Made a similar writeup on this topic too:
http://ballmerpeak.web.elte.hu/devblog/debugging-hyperz-and-fixing-a-radeon-drm-linux-kernel-module.html
Also tried to document all relevant information if it
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
Reviewed-by:
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM)
that is needed in order to support some A3xx and A4xx based GPUs
upstream. This is based on Rob Clark's patch series that he submitted
in October 2015 and I am resubmitting updated patches with his
permission. See the individual
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
---
Changes since v1:
- Rename qcom,ocmem-msm8974 to qcom,msm8974-ocmem
- Renamed reg-names to ctrl and mem
- update hardware description
- moved from soc to sram
From: Rob Clark
Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
spare parameter.]
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Changes since v1:
- None
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs.
Devices which have OCMEM do not have GMEM inside the GPU core, so the
GPU must instead use OCMEM to be functional. Since currently the GPU
is the only OCMEM user with an upstream
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
need to change the ifdef check for CONFIG_MSM_OCMEM to CONFIG_QCOM_OCMEM
now that
On 06/07, Daniel Vetter wrote:
> The crc core code can cope with some late crc, the race is kinda
> unavoidable. So no need to flush pending workers, they'll complete in
> time.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
>
On 06/07, Daniel Vetter wrote:
> No need to have them multiple times.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.h | 8
> drivers/gpu/drm/vkms/vkms_plane.c | 8
> 2 files changed,
On 06/13, Oleg Vasilev wrote:
> Other drivers are able to list crc sources when accessing
> /sys/kernel/debug/dri/.../crtc-0/crc/control
>
> Even though VKMS now supports only 'auto' mode, it is more consistent to
> have the list available to the userspace.
>
> Signed-off-by: Oleg Vasilev
> ---
For historical reason, the function drm_wait_vblank_ioctl always return
-EINVAL if something gets wrong. This scenario limits the flexibility
for the userspace make detailed verification of the problem and take
some action. In particular, the validation of “if (!dev->irq_enabled)”
in the
On 2019-06-18 1:37, Christoph Hellwig wrote:
> On Mon, Jun 17, 2019 at 09:45:09PM -0300, Jason Gunthorpe wrote:
>> Am I looking at the wrong thing? Looks like it calls it through a work
>> queue should should be OK..
> Yes, it calls it through a work queue. I guess that is fine because
> it needs
On Wed, Jun 19, 2019 at 12:25 AM Rodrigo Siqueira
wrote:
>
> On Tue, Jun 18, 2019 at 7:08 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter wrote:
> > >
> > > On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> > > wrote:
> > > > Finally, not related with this
On 2019-05-22 17:55:35, Jani Nikula wrote:
> On Wed, 22 May 2019, Gen Zhang wrote:
> > In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
> > is dereferenced in the following codes. However, memory allocation
> > functions such as kstrdup() may fail and returns NULL.
On Tue, Jun 18, 2019 at 7:08 PM Daniel Vetter wrote:
>
> On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter wrote:
> >
> > On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at
Am Mittwoch, 19. Juni 2019, 00:09:57 CEST schrieb Ezequiel Garcia:
> On Tue, 2019-06-18 at 17:47 -0400, Ilia Mirkin wrote:
> > On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia
> > wrote:
> > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > This is currently enabled via a
On Tue, Jun 18, 2019 at 6:34 AM Daniel Vetter wrote:
>
> On Mon, Jun 17, 2019 at 11:45:55PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with
From: Georgi Djakov
The interconnect API provides an interface for consumer drivers to
express their bandwidth needs in the SoC. This data is aggregated
and the on-chip interconnect hardware is configured to the most
appropriate power/performance profile.
Use the API to configure the
On Tue, 2019-06-18 at 17:47 -0400, Ilia Mirkin wrote:
> On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia
> wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which needs to be specified in the devicetree.
On Wed, Jun 19, 2019 at 12:06 AM Daniel Vetter wrote:
>
> On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
> wrote:
> >
> > On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > > > On 06/12, Daniel Vetter wrote:
On Tue, Jun 18, 2019 at 11:54 PM Rodrigo Siqueira
wrote:
>
> On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter wrote:
> >
> > On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > > On 06/12, Daniel Vetter wrote:
> > > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira
On Tue, Jun 18, 2019 at 5:56 AM Daniel Vetter wrote:
>
> On Mon, Jun 17, 2019 at 11:49:04PM -0300, Rodrigo Siqueira wrote:
> > On 06/12, Daniel Vetter wrote:
> > > On Wed, Jun 12, 2019 at 10:28:41AM -0300, Rodrigo Siqueira wrote:
> > > > Hi Daniel,
> > > >
> > > > First of all, thank you very
On Tue, Jun 18, 2019 at 2:18 AM Simon Ser wrote:
>
> On Tuesday, June 18, 2019 5:19 AM, Rodrigo Siqueira
> wrote:
> > I made the patch, but when I started to write the commit message, I just
> > realized that I did not understand why possible_crtcs should not be
> > equal zero. Why can we not
On Tue, Jun 18, 2019 at 5:43 PM Ezequiel Garcia wrote:
>
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some SoCs, such
On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> > wrote:
> > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > > I could just
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
---
.../bindings/display/rockchip/rockchip-vop.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi
Let's support Gamma LUT configuration on RK3288 SoCs.
In order to do so, this series adds a new and optional
address resource.
A separate address resource is required because on this RK3288,
the LUT address is after the MMU address, which is requested
by the iommu driver. This prevents the
On Tue, Jun 18, 2019 at 1:44 PM Jeffrey Hugo wrote:
>
> On Tue, Jun 18, 2019 at 2:25 PM Rob Clark wrote:
> >
> > From: Georgi Djakov
> >
> > The interconnect API provides an interface for consumer drivers to
> > express their bandwidth needs in the SoC. This data is aggregated
> > and the
https://bugs.freedesktop.org/show_bug.cgi?id=110803
diplosa...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110721
diplosa...@gmail.com changed:
What|Removed |Added
CC||diplosa...@gmail.com
--- Comment
Those files are actually at ReST format. Ok, currently, they
don't belong to any place yet at the organized book series,
but we don't want patches to break them as ReST files. So,
rename them and add a :orphan: in order to shut up warning
messages like those:
...
Documentation/svga.rst:
Those files belong to the driver-api guide. Add them to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
I had to remove the long list of maintainers got by
getpatch.pl, as it was too long. I opted to keep only the
mailing lists.
Documentation/ABI/removed/sysfs-class-rfkill | 2
Those files belong to the admin guide. Add them to the
admin-guide book.
Signed-off-by: Mauro Carvalho Chehab
---
I had to remove the long list of maintainers got by
getpatch.pl, as it was too long. I opted to keep only the
mailing lists.
Documentation/ABI/stable/sysfs-devices-node | 2 +-
Rename the iio documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.
The cdrom.txt and hdio.txt have their own particular syntax.
In order to speedup the conversion, I used a small ancillary
perl script:
my $d;
Those files belong to the driver-api guide. Add them to the
driver-api book.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
Documentation/ABI/stable/sysfs-class-rfkill | 2 +-
.../ABI/testing/sysfs-class-switchtec | 2 +-
Convert this small file to ReST in preparation for adding it to
the driver-api book.
While this is not part of the driver-api book, mark it as
:orphan:, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab
---
.../console/{console.txt => console.rst} | 63
On Tue, Jun 18, 2019 at 2:25 PM Rob Clark wrote:
>
> From: Georgi Djakov
>
> The interconnect API provides an interface for consumer drivers to
> express their bandwidth needs in the SoC. This data is aggregated
> and the on-chip interconnect hardware is configured to the most
> appropriate
On Tue, Jun 18, 2019 at 01:24:10PM -0700, Rob Clark wrote:
> From: Jayant Shekhar
>
> The interconnect framework is designed to provide a
> standard kernel interface to control the settings of
> the interconnects on a SoC.
>
> The interconnect API uses a consumer/provider-based model,
> where
On Tue, Jun 18, 2019 at 01:24:09PM -0700, Rob Clark wrote:
> From: Jayant Shekhar
>
> Since the upstream interconnect bus framework has landed
> upstream, the existing references of custom bus scaling
> needs to be cleaned up.
>
> Changes in v2:
> - Fixed build error due to partial clean
From: Georgi Djakov
The interconnect API provides an interface for consumer drivers to
express their bandwidth needs in the SoC. This data is aggregated
and the on-chip interconnect hardware is configured to the most
appropriate power/performance profile.
Use the API to configure the
From: Jayant Shekhar
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line
From: Abhinav Kumar
dpu_mdss_destroy() can get called not just from
msm_drm_uninit() but also from msm_drm_bind() in case
of any failures.
dpu_mdss_destroy() removes the icc voting by calling
icc_put. This could accidentally remove the voting
done by pm_runtime_enable.
To make the voting
From: Jayant Shekhar
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various
From: Jayant Shekhar
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- None
Changes in v3:
- Remove common property
From: Rob Clark
Most of this is a resend of things that have already been posted to
list. I've rebased the DPU patches, which was somewhat conflicty due to
other changes and refactoring in the DPU code.
Abhinav Kumar (1):
drm/msm/dpu: add icc voting in dpu_mdss_init
Georgi Djakov (1):
On Mon, Jun 17, 2019 at 04:47:30PM +0300, Serge Semin wrote:
> Hello folks,
>
> Any updates of this patch status? It has been here for about two months.
>
Sorry for the mixup, looks like this one just fell through the cracks. I've
applied it to drm-misc-next with the attached Ack and Review.
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Hi Dan, Jérôme and Jason,
>
> below is a series that cleans up the dev_pagemap interface so that
> it is more easily usable, which removes the need to wrap it in hmm
> and thus allowing to kill a lot of code
>
> Note: this series is on
On Mon, Jun 17, 2019 at 5:28 AM Christoph Hellwig wrote:
>
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/dax/dax-private.h | 4
> drivers/dax/device.c | 43 ---
On Fri, 14 Jun 2019 at 03:52, Andres Rodriguez wrote:
>
> DisplayID blocks allow embedding of CEA blocks. The payloads are
> identical to traditional top level CEA extension blocks, but the header
> is slightly different.
>
> This change allows the CEA parser to find a CEA block inside a
On Tue, 18 Jun 2019 at 19:42, Joseph Kogut wrote:
> > >
> > > > > + reg = <0x1180 0x5000>;
> > > > > + interrupts = ,
> > > > > + ,
> > > > > + ;
> > > > > + interrupt-names = "job", "mmu", "gpu";
> > > > >
Enable support for Mali GPU with Panfrost and LIMA drivers. Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/configs/exynos_defconfig | 3 ++-
1 file changed, 2
Enable support for Mali GPU with Panfrost and LIMA drivers. Most of
Exynos chipsets come with Mali GPUs:
1. Mali 400 (Exynos3250, Exynos4210, Exynos4412),
2. Mali T7xx (Exynos542x).
As Mali GPU is quite popular among ARM vendors, other platforms will
benefit as well.
Signed-off-by: Krzysztof
Add nodes for GPU (Mali 400) to Exynos4210 and Exynos4412. Describe the
GPU as much as possible however still few elements are missing:
1. Exynos4210 bus clock is not described in hardware manual therefore
the IP gate clock was provided,
2. Exynos4412: Not sure what to do with CLK_G3D clock
Enable support for Mali GPU with Panfrost driver, e.g. for Exynos5433
and Exynos7 (having Mali T760).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig
Add nodes for GPU (Mali T760) to Exynos7. Current support for Exynos7
misses a lot, including proper clocks, power domains, frequency and
voltage scaling and cooling. However this still can provide basic GPU
description. Not tested on HW.
Signed-off-by: Krzysztof Kozlowski
---
Add nodes for GPU (Mali T760) to Exynos5433. Missing element is the
cooling device. Not tested on HW.
Signed-off-by: Krzysztof Kozlowski
---
.../dts/exynos/exynos5433-tm2-common.dtsi | 5 ++
arch/arm64/boot/dts/exynos/exynos5433.dtsi| 51 +++
2 files changed, 56
Add ID and gate for bus clock for GPU (Mali 400) on Exynos4412.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos4.c | 1 +
include/dt-bindings/clock/exynos4.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
Add vendor compatibles for specific implementation of Mali Utgard
(Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt |
Hi,
Inspired by patch from Joseph Kogut [1], let's add support for Mali GPUs
to most of other boards. However it was tested only on Odroid U3
(Exynos4412) and not fully because requirement of special Mesa drivers
with Lima support.
Even without tests it brings full description of hardware and
Correct language typo and wrong indentation.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index
Add nodes for GPU (Mali 400) to Exynos3250. This is still limited and
not tested:
1. No dynamic voltage and frequency scaling,
2. Not sure what to do with CLK_G3D clock responsible for gating entire
IP block (it is now being disabled as unused).
Signed-off-by: Krzysztof Kozlowski
---
There is no point to print deferred probe (and its failures to get
resources) as an error. For example getting a regulator causes three
unneeded error messages:
lima 1300.gpu: failed to get regulator: -517
lima 1300.gpu: regulator init fail -517
lima 1300.gpu: Fatal error
There is no point to print deferred probe (and its failures to get
resources) as an error.
In case of multiple probe tries this would pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Mark long numbers with ULL to silence the Smatch warning:
drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 is
so big it is long long
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/lima/lima_vm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Tue, 2019-06-18 at 02:15 -0300, Ezequiel Garcia wrote:
> On Mon, 2019-06-17 at 12:06 +0200, Jacopo Mondi wrote:
> > Hi Ezequiel,
> >one small question, as I'm working on supporting gamma LUT for
> > rcar-du as well, and there's one point not totally clear to me
> >
> >
> > On Thu, Jun 13,
On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
>
> Let's try again.
>
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman
>
On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already,
Den 17.06.2019 16.51, skrev Maxime Ripard:
> Rotations and reflections setup are needed in some scenarios to initialise
> properly the initial framebuffer. Some drivers already had a bunch of
> quirks to deal with this, such as either a private kernel command line
> parameter (omapdss) or on the
https://bugzilla.kernel.org/show_bug.cgi?id=201539
Sean Birkholz (supas...@hotmail.com) changed:
What|Removed |Added
CC|
On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
wrote:
> On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > Greg is busy already, but maybe he won't do everything ...
> > >
> > > Cc: Greg Kroah-Hartman
>
Hi!
Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> Let's add some better support for HDMI audio to dw_hdmi.
> Specifically:
>
> 1. For 44.1 kHz audio the old code made the assumption that an N of
> 6272 was right most of the time. That wasn't true and the new table
Den 18.06.2019 18.35, skrev Laurent Pinchart:
> Hi Noralf,
>
> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
>> Den 18.06.2019 15.13, skrev Laurent Pinchart:
>>> The recommended way to specify GEM object functions is to provide a
>>> drm_gem_object_funcs structure instance and
Hi Laurent,
On 17/06/2019 22:09, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series refactors atomic commit tail handling in the R-Car DU
> driver to simplify the code flow, and open the door to further
> optimisations. It takes over Kieran's "[PATCH v2 0/6] drm: rcar-du:
> Rework
On Tue, Jun 18, 2019 at 04:18:43PM +0300, Dan Carpenter wrote:
> The copy_from_user() function returns the number of bytes remaining
> to be copied but we want to return a negative error code. Otherwise
> the callers treat it as a successful copy.
>
> Signed-off-by: Dan Carpenter
Thanks Dan,
On Tue, Jun 18, 2019 at 9:36 AM Ezequiel Garcia wrote:
>
> On Thu, 2019-06-13 at 15:36 -0400, Ilia Mirkin wrote:
> > Note that userspace may provide any size of gamma lut. Have a look at
> > i915/intel_color.c:intel_color_check which filters out only the
> > allowed sizes. Consider having a
On Tue, Jun 18, 2019 at 10:26:52AM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> > the null check is
Hi Fabrizio,
Thank you for the patch.
On Tue, Jun 18, 2019 at 04:18:37PM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (R8A774A1) SoC bindings.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
I don't have pending changes for this file for this kernel release. As
your
1 - 100 of 270 matches
Mail list logo
