On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
wrote:
>
> On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > From: Liu Shixin
> >
> > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> >
> > Signed-off-by: Liu Shixin
> > ---
> > drivers/gpu/drm/arm/d
The driver seemed to try to make the total cumulative time of all delays
across the whole power up sequence to sum up to 120ms.
The datasheet on the other hand specifies that there needs to be 120ms
delay after the sleep out command, not after reset as the driver
assumes.
Lastly, the delay betwee
The address of the DMA descriptor never changes. It can therefore be set
in the probe function.
v2-v3: No change
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-dr
Hi,
On Tue, Jul 14, 2020 at 03:13:05PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> The Primo73 is an MSI branded Allwinner A20-based 7-inch tablet. It has
> a metal back case with a plastic insert around where the WiFi antenna is.
> The tablet is (as of July of 2020) no longer available
Hi Guido,
On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote:
> Hi Ondrej,
> On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote:
> > When extending the driver for xbd599 panel support I tried to do minimal
> > changes and keep the existing initialization timing.
> >
> > It t
Hi,
On Fri, Jul 10, 2020 at 05:31:24PM -0300, Fabio Estevam wrote:
> Commit 13871279ff5c ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
> introduced a double instance of 'iommus' causing the following build
> error with 'make dt_binding_check':
>
> found duplicate key "iommus" with value "
在 2020/7/16 21:34, Thierry Reding 写道:
On Thu, Jul 16, 2020 at 05:03:23PM +0800, Qinglang Miao wrote:
From: Yongqiang Liu
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yongqiang Liu
---
drivers/gpu/host1x/debug.c | 28
1 file changed, 4
Support multiple panels or bridges connected to the same DPI output of
the SoC. This setup can be found for instance on the GCW Zero, where the
same DPI output interfaces the internal 320x240 TFT panel, and the ITE
IT6610 HDMI chip.
v2: No change
v3: Allow > 80-char lines where it makes sense
Si
From: Yongqiang Liu
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yongqiang Liu
---
drivers/gpu/host1x/debug.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index
If you pass a string that is not terminated with a carriage return to
dev_err(), it will eventually be printed with a carriage return, but
not right away, since the kernel will wait for a pr_cont().
v2: New patch
v3: No change
Signed-off-by: Paul Cercueil
Acked-by: Sam Ravnborg
---
drivers/gpu
When extending the driver for xbd599 panel support I tried to do minimal
changes and keep the existing initialization timing.
It turned out that it's not good enough and the existing init sequence
is too aggressive and doesn't follow the specification. On PinePhone
panel is being powered down/up d
From: Liu Shixin
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Liu Shixin
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/
The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
isof_mbi_* APIs when ISOF_MBI is disabled.
Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms.
Signed-off-by: Jisheng Zhang
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a
By changing the pixel clock and the length of the back porch, it is
possible to obtain a perfect 50 Hz refresh rate.
v2: Rebase on drm-misc-next
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-simple.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletion
Aside from being more correct, the non optional version of the function
prints an error when failing to find the IRQ.
Fixes: eea9b97b4504 ("drm/v3d: Add support for V3D v4.2")
Signed-off-by: Nicolas Saenz Julienne
---
drivers/gpu/drm/v3d/v3d_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On Thu 16 Jul 13:21 PDT 2020, Douglas Anderson wrote:
> On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
> a small spike on the HPD line right when you power the panel on. The
> picture looks something like this:
>
> +--
>
These two patches fix the same issue:
- drm/v3d: Fix memory leak in v3d_submit_cl_ioctl (29cd13cfd76)
- drm/v3d: don't leak bin job if v3d_job_init fails (0d352a3a8a1)
And it seems that the conflict was missed during the merge.
Get rid of one of the free() calls.
Fixes: 77e0723bd27f ("Merge v5.
Full rename without any modification, except to the Makefile.
Renaming ingenic-drm.c to ingenic-drm-drv.c allow to decouple the module
name from the source file name in the Makefile. This will be useful
later when more source files are added.
v2: New patch
v3: No change
Signed-off-by: Paul Cercu
The standard binding for DSI requires that the channel number
of the panel is encoded in DT. This adds the channel number in
all OMAP3-5 boards in preparation for using common infrastructure.
Reviewed-by: Laurent Pinchart
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/motorola-mapphone-
All Ingenic SoCs starting from the JZ4725B support OSD mode.
In this mode, two separate planes can be used. They can have different
positions and sizes, and one can be overlayed on top of the other.
v2: Use fallthrough; instead of /* fall-through */
v3: - Add custom atomic_tail function to handl
On 2020/07/16 19:00, Daniel Vetter wrote:
> On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
>> On 2020/07/16 0:12, Dan Carpenter wrote:
>>> I've complained about integer overflows in fbdev for a long time...
>>>
>>> What I'd like to see is something like the following maybe. I don't
From: Krishna Manikandan
Move the bus clock to mdp device node,in order
to facilitate bus band width scaling on sc7180
target.
The parent device MDSS will not vote for bus bw,
instead the vote will be triggered by mdp device
node. Since a minimum vote is required to turn
on bus clock, move the c
Add documentation of the Device Tree bindings for the Image Processing
Unit (IPU) found in most Ingenic SoCs.
v2: Add missing 'const' in items list
v3: No change
Signed-off-by: Paul Cercueil
Reviewed-by: Rob Herring
Acked-by: Sam Ravnborg
---
.../bindings/display/ingenic,ipu.yaml | 65
Move the register definitions to ingenic-drm.h, to keep
ingenic-drm-drv.c tidy.
v2: Fix SPDX license tag
v3: No change
Signed-off-by: Paul Cercueil
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 116 +---
drivers/gpu/drm/ingenic/ingenic-drm.h | 126 +
Use dmam_alloc_coherent() instead of dma_alloc_coherent(). Then we don't
need to register a custom cleanup handler.
v3: New patch
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/dr
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:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
-
The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
signals, which sorts-of worked, but resulted in the picture fading out
under certain circumstances.
Fix this issue by marking VSYNC and HSYNC signals active-low.
v2: Rebase on drm-misc-next
Fixes: 7b6bd8433609 ("drm/panel: s
From: Krishna Manikandan
This change adds the interconnect bindings to the
MDSS node. This will establish Display to DDR path
for bus bandwidth voting.
Changes in v2:
- Change in commit message(Matthias Kaehlcke)
Changes in v3:
- Updated commit message to include
revie
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Pi-Hsun Shih
Signed-off-by: Yilun Lin
Signed-off-by: Hermes Wu
Signed-off-by: Allen Chen
---
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Mak
Hi Sam,
Le jeu. 16 juil. 2020 à 19:43, Sam Ravnborg a
écrit :
Hi Paul.
On Thu, Jul 16, 2020 at 06:38:35PM +0200, Paul Cercueil wrote:
plane->index is NOT the index of the color plane in a YUV frame.
Actually, a YUV frame is represented by a single drm_plane, even
though
it contains thre
Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.
In the process, the new ingenic,jz4780-lcd compatible string has been
added.
v2: Add info about IPU at port@8
v3: No change
Signed-off-by: Paul Cercueil
Reviewed-by: Rob Herring
Acked-by: Sam Ravnborg
---
.../bindings/display/ingeni
This change adds support to scale src clk and bandwidth as
per composition requirements.
Interconnect registration for bw has been moved to mdp
device node from mdss to facilitate the scaling.
Changes in v1:
- Address armv7 compilation issues with the patch (Rob)
Signed-off-by: Kalyan Thota
--
The cleanup series for omapdrm's DSI code got too big. Reviewing
this is not fun and the same goes for keeping track of the change
requests. Let's do the cleanup in smaller steps instead. This is
the first batch, which updates the binding (txt -> yaml) and
modifies the DT slightly.
Changes since P
Convert panel-dsi-cm bindings to YAML and add
missing properties while at it.
Reviewed-by: Laurent Pinchart
Reviewed-by: Rob Herring
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel/panel-dsi-cm.txt | 29 ---
.../bindings/display/panel/panel-dsi-cm.yaml | 86 +
Add support for the Image Processing Unit (IPU) found in all Ingenic
SoCs.
The IPU can upscale and downscale a source frame of arbitrary size
ranging from 4x4 to 4096x4096 on newer SoCs, with bicubic filtering
on newer SoCs, bilinear filtering on older SoCs. Nearest-neighbour can
also be obtained
On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Some LCD panels do not support 24-bit true color, or 8bits per channel
> RGB. Many low end ones only support up to 6 bits per channel natively.
>
> Add a device tree property to describe the native bit depth o
Current dma-buf heaps can handle only default CMA. This introduces
dma_heap_add_cma() function to attach CMA heaps that belongs to a device.
At first, the driver calls of_reserved_mem_device_init() to set
memory-region property associated with reserved-memory defined as CMA
to the device. And when
Add information about panel orientation, so that the
system boots into a properly rotated shell.
Reviewed-by: Laurent Pinchart
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/motorola-mapphone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/motorola-mapp
Bump version to 1.1 and set date to 2020-07-16.
v3: New patch
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
plane->index is NOT the index of the color plane in a YUV frame.
Actually, a YUV frame is represented by a single drm_plane, even though
it contains three Y, U, V planes.
v2-v3: No change
Cc: sta...@vger.kernel.org # v5.3
Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Sig
The datasheet specifies that it's better to keep reset asserted
while powering up the supplies, and that IOVCC should be enabled
first.
There also needs to be a delay after enabling the supplies and
before deasserting the reset. The datasheet specifies 1ms after
the supplies reach the required vol
Add Droid 4 specific compatible value in addition to the
generic one, so that we have the ability to add panel
specific quirks in the future.
Reviewed-by: Laurent Pinchart
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/motorola-mapphone-common.dtsi | 2 +-
1 file changed, 1 insertion(+)
On Fri, Jul 17, 2020 at 09:06:57AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> wrote:
> >
> > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > From: Liu Shixin
> > >
> > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify th
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 decompres
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,
> >
> > This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> > includes only graphics plane sup
On Tue, Jun 09, 2020 at 03:02:14PM +0200, Daniel Vetter wrote:
> Hi Eugeniy,
>
> Very much appreciated, and kinda expected. That 2nd backtrace really
> confuses me, so "something strange is going on" and the bisect looks
> funny is within expectations. Hopefully we can track down what's going
> on
This is a prep step to convert arc over to the simple kms helpers, for
now we just use this as an embedding container to drop all the various
allocations. Big change is the removal of the various devm_kzalloc,
which have the wrong lifetimes anyway.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
Really straighforward, only slight issue is that the sim connector is
created after the pipe is set up, so can't use the helpers perfectly
yet. Subsequent patches will fix that.
Aside from lots of deleting code no functional changes in here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
That way we can get rid of this final piece of init code, and use the
simple pipe helpers as intended.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_drv.c | 51 ++--
1 file changed, 16 insertions(+), 35 deletions(-)
diff --git a/driv
Removes the last devm_kzalloc, which means we're now prepared to use
drmm_mode_config_cleanup!
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_sim.c | 14 +-
2 files changed, 2 insertions(+), 13 deletions(-)
di
It's redundant, drm core guarantees that state->fb is set iff
state->crtc is set.
v2: I had a misconception about simple helpers here and thought they
filter this out. They don't. Issue reported by Eugeniy.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/dr
Really not big anymore.
v2: Fixup update function, bug reported by Eugeniy
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_crtc.c | 169 --
drivers
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Signed-off-by: Dan
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h |
Because it is.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/Makefile| 1 -
drivers/gpu/drm/arc/Kconfig
Really not worth the function, much less the separate file now that
almost all the code is gone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
drivers/gpu/drm/arc/arcpgu_h
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 2 ++
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 ++--
drivers/gpu/drm/arc/arcpgu_drv.c | 4 +---
3 files ch
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 4 ++--
drivers/gpu/drm/armada/armada_debugfs.c | 2 +-
drivers/gpu/drm/armada/armada_drm.h | 2
At less than 500 lines total feels like the right thing to do.
Also noticed that the simple wrapper around drm_connector_cleanup can
be dropped.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 39
drivers/gpu/drm/arc
Simple pipe helpers only have an enable and disable hook, no more
mode_set_nofb. Call it from our enable hook to align with that
conversions.
Atomic helpers always call mode_set_nofb and enable together, so
there's no functional change here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
Leftover from the conversion to the generic fbdev emulation.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 87821c91a00c..ed77dd5dd5cb 100644
--
drm_connector_register does nothing before drm_dev_register(), it
is meant for hotpluggable connectors only. Same for the unregister side.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_sim.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/dri
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c c
Since aspeed doesn't use devm_kzalloc anymore we can use the managed
mode config cleanup.
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 11 ++-
1
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Qiu Wenbo
Sent: Friday, July 17, 2020 3:10 PM
To: Quan, Evan ; amd-...@lists.freedesktop.org
Cc: Qiu Wenbo ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David Airl
On Fri, Jul 17, 2020 at 04:00:36PM +0800, miaoqinglang wrote:
>
>
> 在 2020/7/17 15:06, Daniel Vetter 写道:
> > On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > > From: Liu Shixin
> >
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,
> > >
> > > This patchset adds initial
On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> 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: L
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 +0200 schrieb Daniel Vetter:
> > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach
> > > wrote:
> > > > Hi Laurent
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 +0200 schrieb Daniel Vetter:
> > > > O
Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
once something breaks.
On Fri, Jul 17, 2020 at 2:43 AM Karol Herbst wrote:
>
> On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> >
> > [+cc Sasha -- stable kerne
On Fri, Jul 17, 2020 at 12:51 PM Lucas Stach wrote:
>
> 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 Fre
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #71 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
Just to give some news, I can confirm that I haven't had any freeze since
Wednesday. Usually, when my system just idled, it would quickly trigger the
bug. That or doing something C
Hi Dave, Daniel,
More stuff for 5.9.
The following changes since commit 9555152beb1143c85c03f9b9de59863cbbe89f4b:
Merge tag 'amd-drm-next-5.9-2020-07-01' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-07-02 15:17:31
+1000)
are available in the Git repository at:
git://p
From: Sharat Masetty
This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm dri
From: Sharat Masetty
Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.
Signed-off-by: Sharat Masetty
Acked-by: Rob Herring
Signed-off-by: Akhil P Oommen
---
.../devicetree/bindings/display/msm/gpu.txt
This series add support for GPU DDR bandwidth scaling and is based on the
bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on the
tip of msm-next branch.
[1]
https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/
[2] https://patchwork.fre
From: Sharat Masetty
This patch adds the interconnects property to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/ar
From: Sharat Masetty
Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.
Signed-off-by: Sharat Masetty
Reviewed-by: Matthias Kaehlcke
Signed
From: Sharat Masetty
This patch adds the interconnects property for the gpu node and the
opp-peak-kBps property to the opps of the gpu opp table. This should
help enable DDR bandwidth scaling dynamically and proportionally to the
GPU frequency.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil
From: Sharat Masetty
This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.
Signed-off-by: Sharat
Hi All,
Here is v5 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
This series consists of 4 parts:
1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
2.
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consume
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file chan
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
backlight-ena
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v5:
- Fix an indentation issue
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
controller
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enable
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
From: Ville Syrjälä
Add a TODO for plumbing drm_atomic_state all over to ease
the hurdles of accessing additional object states.
Reviewed-by: Daniel Vetter #irc
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/todo.rst | 46 ++
1 file changed, 46 insertio
Am 17.07.20 um 04:27 schrieb Laurent Pinchart:
Hi Christian,
On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote:
On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
Most of the DRM drivers uAPI headers are licensed under t
1 - 100 of 139 matches
Mail list logo
