On Mon, Feb 17, 2020 at 04:04:26PM +0100, Nirmoy Das wrote:
> Switch over to GEM VRAM's implementation to retrieve bo->offset
>
> Signed-off-by: Nirmoy Das
Acked-by: Gerd Hoffmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis
On Mon, Feb 17, 2020 at 04:04:25PM +0100, Nirmoy Das wrote:
> Calculate GPU offset within vram-helper without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
Acked-by: Gerd Hoffmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
Hi,
> 2 unfortunately I can't say the same for bochs but it works with this patch
> series so I think bochs is fine as well.
bochs needs the offset only to scanout framebuffers, which in turn
requires framebuffers being pinned to vram. So all green here.
cheers,
Gerd
__
On Tue, Feb 18, 2020 at 09:48:15AM +0100, Thomas Zimmermann wrote:
> The qxl driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Ho
On Wed, Feb 19, 2020 at 11:20:40AM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> I also noticed that cirrus forgot to call drm_dev_fini().
>
> v2: Don't call kfree(cirrus) after we've handed overship of that to
> drm_device and the drmm_ stuff.
On Wed, Feb 19, 2020 at 11:20:58AM +0100, Daniel Vetter wrote:
> Small mistake that crept into
>
> commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
> Author: Gerd Hoffmann
> Date: Tue Feb 11 14:52:18 2020 +0100
>
> drm/bochs: add drm_driver.release callback
>
> where drm_atomic_helper_shut
On Wed, Feb 19, 2020 at 11:20:59AM +0100, Daniel Vetter wrote:
> Instead rely on the automatic clean, for which we just need to check
> that drm_mode_config_init succeeded. To avoid an inversion in the
> cleanup we also have to move the dev_private allocation over to
> drmm_kzalloc.
>
> Signed-off
On Wed, Feb 19, 2020 at 11:21:00AM +0100, Daniel Vetter wrote:
> We can even delete the drm_driver.release hook now!
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: virtualizat
On Wed, Feb 19, 2020 at 11:21:01AM +0100, Daniel Vetter wrote:
> With the drm_device lifetime fun cleaned up there's nothing in the way
> anymore to use devm_ for everything hw releated. Do it, and in the
> process, throw out the entire onion unwinding.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave
Hi, Jitao:
On Fri, 2020-02-21 at 19:28 +0800, Jitao Shi wrote:
> Add decriptions about supported chips, including MT2701 & MT8173 &
> mt8183
>
> 1. Add more chips support. ex. MT2701 & MT8173 & MT8183
> 2. Add property "dpi_pin_mode_swap" and "pinctrl-names" gpio mode dpi mode and
>gpio ouppu
Hi,
chained to this message is a driver for CH7033 along with device tree
binding docs.
Since the initial submission, issues pointed out in Laurent Pinchart's
review [1] were addressed. Details in individual patches' change log.
At his suggestion, the driver has been made to use bridge/display-co
Signed-off-by: Maya Rashish
Signed-off-by: Thomas Klausner
Co-authored-by: Thomas Klausner
---
drivers/gpu/drm/radeon/atombios.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 4b86e8b45009.
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally. In case when the
EM is
于 2020年2月22日 GMT+08:00 上午1:13:28, Torsten Duwe 写到:
>On Sat, Feb 22, 2020 at 12:51:27AM +0800, Icenowy Zheng wrote:
>> Current code tries to store the link rate (in bps, which is a big
>> number) in a u8, which surely overflow. Then it's converted back to
>> bandwidth code (which is thus 0) and w
On Sat, Feb 22, 2020 at 5:39 AM Sam Ravnborg wrote:
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:53PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > DPU (Display Processor Unit) is the Display Controller for the Unisoc
> SoCs
> > which transfers the image data from a video memory buffer
Arguments to GENMASK should be msb >= lsb.
Signed-off-by: Ondrej Jirman
---
I just grepped the whole kernel tree for GENMASK argument order issues,
and this is one of the three that popped up. No testing was done.
drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +-
1 file changed, 1 insertion(+), 1 del
Signed-off-by: Maya Rashish
Signed-off-by: Thomas Klausner
Co-authored-by: Thomas Klausner
---
drivers/gpu/drm/amd/include/atombios.h | 20 ++--
drivers/gpu/drm/amd/include/atomfirmware.h | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu
Den 09-01-2020 kl. 17:12, skrev Christian König:
Hi Christoph,
Am 09.01.20 um 15:14 schrieb Christoph Hellwig:
Hi Woody,
sorry for the late reply, I've been off to a vacation over the holidays.
On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote:
Regression in 5.4 kernel on 32-bit
Current code tries to store the link rate (in bps, which is a big
number) in a u8, which surely overflow. Then it's converted back to
bandwidth code (which is thus 0) and written to the chip.
The code sometimes works because the chip will automatically fallback to
the lowest possible DP link rate
This is my attempt at adding devfreq (and cooling device) support to
the lima driver.
Test results from a Meson8m2 board:
TEST #1: glmark2-es2-drm --off-screen in an infinite loop while cycling
through all available frequencies using the userspace governor
From : To
:
Signed-off-by: Maya Rashish
Signed-off-by: Thomas Klausner
Co-authored-by: Thomas Klausner
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index f47d5710cc95..5
On Sun, Feb 23, 2020 at 12:26 PM tang pengchuan
wrote:
>
>
> On Sun, Feb 23, 2020 at 5:27 AM Sam Ravnborg wrote:
>
>> Hi Kevin/tang.
>>
>> Thanks for the quick and detailed feedback.
>> Your questions are addressed below.
>>
>> Sam
>>
>>
>> > > > +static int sprd_drm_bind(struct device *
Hello,
syzbot found the following crash on:
HEAD commit:0a44cac8 Merge tag 'dma-mapping-5.6' of git://git.infradea..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11bfb74ee0
kernel config: https://syzkaller.appspot.com/x/.config?x=a61f2164c515c07f
das
Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v1:
- Dual licensed with BSD-2-Clause
- Collected Rob's reviewed-by tag
.../display/bridge/chrontel,ch7033.yaml | 86 +++
1 file ch
Hi all,
This patch set introduces support for devices in the Energy Model (EM)
framework. It will unify the power model for thermal subsystem and make it
simpler. The 1st patch refactors EM framework and adds support for devices.
The 2nd patch changes dev_pm_opp_of_register_em() in OPP/OF which no
On Sat, 22 Feb 2020, at 19:30, Mauro Carvalho Chehab wrote:
> Several DT references got broken due to txt->yaml conversion.
>
> Those are auto-fixed by running:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
...
> .../bindings/pinctrl/asp
Hi,
One minor nit. Please see inline:
On 2/21/20 11:47 AM, Lukasz Luba wrote:
> Add support of other devices into the Energy Model framework not only the
> CPUs. Change the interface to be more unified which can handle other
> devices as well.
>
> Signed-off-by: Lukasz Luba
> ---
> Documentatio
Hi,
On 21/2/20 12:53, Matthias Brugger wrote:
>
>
> On 21/02/2020 12:37, Enric Balletbo i Serra wrote:
>> Hi CK and Matthias,
>>
>> On 21/2/20 12:11, CK Hu wrote:
>>> Hi, Matthias:
>>>
>>> On Fri, 2020-02-21 at 11:24 +0100, Matthias Brugger wrote:
On 21/02/2020 10:27, CK Hu wrote:
Hi Sam,
Thank you for your email
On Sat, Feb 22, 2020 at 5:21 AM Sam Ravnborg wrote:
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:51PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display inte
Chrontel makes encoders for video displays and perhaps other stuff.
Their web site is http://www.chrontel.com/.
Signed-off-by: Lubomir Rintel
Acked-by: Rob Herring
---
Changes since v1:
- Collect Rob's ack
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insert
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by: Lukasz Luba
---
driv
Hi Steven,
On Sun, Jan 12, 2020 at 1:16 AM Martin Blumenstingl
wrote:
>
> These are a bunch of devfreq fixes for panfrost that came up in a
> discussion with Robin Murphy during the code-review of the lima
> devfreq patches: [0]
>
> I am only able to test patch #1 properly because the only boards
On Sat, Feb 22, 2020 at 5:36 AM Sam Ravnborg wrote:
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:52PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > Adds drm support for the Unisoc's display subsystem.
>
> Thanks for the updated driver patch.
> Good split of patches.
> A few comments in
Most platforms with a Mali-400 or Mali-450 GPU also have support for
changing the GPU clock frequency. Add devfreq support so the GPU clock
rate is updated based on the actual GPU usage when the
"operating-points-v2" property is present in the board.dts.
The actual devfreq code is taken from panfr
On Sun, 23 Feb 2020, at 10:21, Ondrej Jirman wrote:
> Arguments to GENMASK should be msb >= lsb.
>
> Signed-off-by: Ondrej Jirman
> ---
> I just grepped the whole kernel tree for GENMASK argument order issues,
> and this is one of the three that popped up. No testing was done.
I think someone
On Wed, 19 Feb 2020, Daniel Vetter wrote:
> slab does this already, and I want to use this in a memory allocation
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
Would be better to export it without under
On Sat, Feb 22, 2020 at 5:21 AM Sam Ravnborg wrote:
>
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:51PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> >
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 133
Documentation/scheduler/sched-energy.rst | 2 +
Hi Sam,
Thanks for your feedback
In the future we will have dp(displayport), hdmi encoder and more, so all
those put into sprd directory, maybe better?
On Sat, Feb 22, 2020 at 5:17 AM Sam Ravnborg wrote:
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:50PM +0800, Kevin Tang wrote:
> > ChangeList:
Add device to the Energy Model framework. It will create a dedicated
and unified data structures used i.e. in the thermal framework.
The power model used in dev_pm_opp subsystem is simplified and created
based on DT 'dynamic-power-coefficient', volatage and frequency. It is
similar to the CPU model
use the drm_fb_helper_remove_conflicting_pci_framebuffer to remove
the framebuffer initialized by fireware/bootloader to avoid resource
conflict.
Signed-off-by: Tian Tao
---
v2: use the general API to remove the conflict resource instead of rolling
our own.
---
---
drivers/gpu/drm/h
This is a driver for video encoder with VGA and DVI/HDMI outputs.
There is no documentation for the chip -- the operation was guessed from
what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
come from the ch7035 driver in Mediatek's GPL code dump.
Only bare minimum is impleme
From: chenqiwu
Convert list_for_each() to list_for_each_entry() to simplify code.
Signed-off-by: chenqiwu
---
drivers/dma-buf/sync_debug.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index
On Sun, Feb 23, 2020 at 5:27 AM Sam Ravnborg wrote:
> Hi Kevin/tang.
>
> Thanks for the quick and detailed feedback.
> Your questions are addressed below.
>
> Sam
>
>
> > > > +static int sprd_drm_bind(struct device *dev)
> > > > +{
> > > > + struct drm_device *drm;
> > > > + struc
The GPU can be one of the big heat sources on a SoC. Allow the
"#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
overheating.
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bindings/gpu/
On Tue, Jan 14, 2020 at 09:41:01PM +0800, Martin Liu wrote:
CC more MLs for winder review.
> This commit adds SET_NAME ioctl coversion to
> support 32 bit ioctl.
>
> Signed-off-by: Martin Liu
> ---
> drivers/dma-buf/dma-buf.c | 22 +-
> 1 file changed, 21 insertions(+), 1 d
On Tue, Feb 18, 2020 at 12:05:53PM +0530, Sumit Semwal wrote:
> Hello Martin,
>
> Thanks for your patches - they look decent.
>
> May I please request you to run get_maintainers.pl (the patches need
> to be sent to a couple of other MLs too for wider review).
>
> Best,
> Sumit.
Sorry for the lat
The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
anywhere but in the raspberrypi_register_pllb_arm.
Let's remove it, this will make our lives easier in future patches.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
dr
Since we're going to introduce pixelvalve data structures for other SoCs
than the BCM2835, let's rename the structures defined in the code to
make it obvious which SoC we're targetting.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 12 ++--
1 file changed, 6 insertion
The BCM2711 audio support doesn't work yet, so let's add a boolean to
indicate whether or not it's supported, and only register a sound card if
that boolean is set.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
2 files changed,
For the upcoming registration of the clocks provided by the firmware, make
sure it's exposed to the device tree providers.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 15 +++
1 file change
The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove
it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1762484bd97a..9b06352da377 100644
Now that we don't have any users anymore, we can kill that pointer.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 -
drivers/gpu/drm/vc4/vc4_hdmi.c | 14 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/g
The driver isn't consistent with the name given to the vc4_hdmi
structure pointer in its functions. Make sure to use a consistent name.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 265 +-
1 file changed, 133 insertions(+), 132 deletions(-)
d
Not all pixelvalve FIFOs in vc5 have the same depth, so we need to add that
to our vc4_crtc_data structure to be able to compute the fill level
properly later on.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20
drivers/gpu/drm/vc4/vc4_drv.h | 3 +++
2
The hvs_latency_pix variable doesn't need to be a variable and can just be
defined.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 4a
Instead of creating planes for each CRTC, we eventually want to create all
the planes for each CRTCs.
In order to make that more convenient, let's iterate on the CRTCs in the
plane creation function instead of its caller.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 9 ++-
The HDMI blocks in the BCM2771 have an i2c controller to retrieve the
EDID. This block is split into two parts, the BSC and the AUTO_I2C,
lying in two separate register areas.
The AUTO_I2C block has a mailbox-like interface and will take away the
BSC control from the CPU if enabled. However, the B
The current firmware clock driver for the RaspberryPi can only be probed by
manually registering an associated platform_device.
While this works fine for cpufreq where the device gets attached a clkdev
lookup, it would be tedious to maintain a table of all the devices using
one of the clocks expos
The vc4_crtc_handle_page_flip already has a local variable holding the
value of vc4_crtc->channel, so let's use it instead.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers
Some pixelvalves in vc5 use the same interrupt line so let's register our
interrupt handler as a shared one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4
The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
being connected to a pixelvalve, and some muxing between the FIFOs and
outputs.
Any output cannot feed from any FIFO though, and they all have a bunch of
constraints.
In order to support this, let's store the possible FIFOs
The mode_valid hook on the encoder uses a pointer to a drm_encoder called
crtc, which is pretty confusing. Let's rename it to encoder to make it
clear what it is.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
The reset-simple code lacks a reset callback that is still pretty easy to
implement. The only real thing to consider is the delay needed for a device
to be reset, so let's expose that as part of the reset-simple driver data.
Cc: Philipp Zabel
Signed-off-by: Maxime Ripard
---
drivers/reset/reset
The clkdev lookup created for the cpufreq device is never removed if
there's an issue later in probe or at module removal time.
Let's convert to the managed variant of the clk_hw_register_clkdev function
to make sure it happens.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.o
The HDMI PHY in the BCM2711 HDMI controller is significantly more
complicated to setup than in the older BCM283x SoCs.
Let's add hooks to enable and disable the PHY.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +++--
From: Dave Stevenson
The HVS found in the BCM2711 is slightly different from the previous
generations.
Most notably, the display list layout changes a bit, the LBM doesn't have
the same size and the formats ordering for some formats is swapped.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxi
The BCM2711 and BCM283x HDMI controllers use a slightly different reset
sequence, so let's add a callback to reset the controller.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
2 files changed, 15 insertions(+), 5
So far the plane creation was done when each CRTC was bound, and those
planes were only tied to the CRTC that was registering them.
This causes two main issues:
- The planes in the vc4 hardware are actually not tied to any CRTC, but
can be used with every combination
- More importantly, s
The VIDEN bit in the pixelvalve currently being used to enable or disable
the pixelvalve seems to not be enough in some situations, which whill end
up with the pixelvalve stalling.
In such a case, even re-enabling VIDEN doesn't bring it back and we need to
clear the FIFO. This can only be done if
Now that we have a driver for the DVP, let's add its DT node.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
index 4742e1a77a65..1e89f2a810f3 100
The raspberry_clock_property only takes the clock ID as an argument, but
now that we have a clock data structure it makes more sense to just pass
that structure instead.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-ra
So far the driver has really only been providing a single clock, and stored
both the data associated to that clock in particular with the data
associated to the "controller".
Since we will change that in the future, let's decouple the clock data from
the provider data.
Cc: Michael Turquette
Cc:
Now that we have a clock driver for the clocks exposed by the firmware,
let's add the device tree nodes for it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/bcm2711.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dts
Now that we are passing the vc4_hdmi structure to the connector init
function, we can simply use the pointer in that structure instead of
having the pointer as an argument.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-
The BCM2711 comes with a new VideoCore. Add a compatible for it.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/
The COB allocation depends on the HVS channel used for a given
pixelvalve.
While the channel allocation was entirely static in vc4, vc5 changes
that and at bind time, a pixelvalve can be assigned to multiple
HVS channels.
Let's prepare that rework by allocating the COB when it's actually
needed.
Let's now create more planes that can be affected to all the CRTCs.
vc4 has 3 CRTCs, 1 primary and 1 cursor each, and was having 24 (8
planes per CRTC) overlays.
However, vc5 has 5 CRTCs, so keeping the same logic would put us at 50
planes which is well above the 32 planes limit imposed by DRM.
The longer FIFOs in vc5 pixelvalves means that the FIFO full level
doesn't fit in the original register field and that we also have a
secondary field. In order to prepare for this, let's move the registers
fill part to a helper function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_c
The driver has really only supported one clock so far and has hardcoded the
ID used in communications with the firmware in all the functions
implementing the clock framework hooks. Let's store that in the clock data
structure so that we can support more clocks later on.
Cc: Michael Turquette
Cc:
The reset-simple code can be useful for drivers outside of drivers/reset
that have a few reset controls as part of their features. Let's move it to
include/linux/reset.
Cc: Philipp Zabel
Signed-off-by: Maxime Ripard
---
drivers/reset/reset-simple.c| 3 +--
drivers/reset/reset-simple.h
Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle.
Let's put the number of pixel output per clock cycle in the CRTC data and
update the various calculations to reflect that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 17 ++---
drivers/gpu/dr
While the device tree and the driver expected a clock-names property, it
wasn't explicitly documented in the previous binding. The documented order
was wrong too, so make sure clock-names is there and in the proper order.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: Maxime Ripard
The raspberrypi_fw_pll_is_on function doesn't only apply to PLL
registered in the driver, but any clock exposed by the firmware.
Since we also implement the is_prepared hook, make the function
consistent with the other function names, and drop the fw from the
function name.
Cc: Michael Turquette
The BCM2711 has a reworked display pipeline, and the load tracker needs
some adjustement to operate properly. Let's add a compatible for BCM2711
and disable the load tracker until properly supported.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4
The clock framework DT provider helpers don't check the pointers in the
array registered by the clock provider before returning it.
This means that if the array is sparse, we will end up returning a NULL
pointer while the caller expects an error pointer, resulting in a crash.
Let's test the point
The planes so far were created as part of the CRTC binding code with
each planes created associated only to one CRTC. However, the hardware
in the vc4 doesn't really have such constraint and can be used with any
CRTC.
In order to rework this, let's first move the overlay and cursor planes
creation
The firmare 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 Turquette
Cc: Stephen Boyd
Cc: Rob Herring
Cc: linux-...@vger.kernel.org
Cc:
The HDMI driver was registering a single debugfs file so far with the name
hdmi_regs.
Obviously, this is not going to work anymore when will have multiple HDMI
controllers since we will end up trying to register two files with the same
name.
Let's use the ID to avoid that name conflict.
Signed-o
The driver calls the helper to add the color management properties twice,
which is redundant. Remove the first one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
i
Switch the DT binding to a YAML schema to enable the DT validation.
Cc: Kamal Dasu
Cc: Florian Fainelli
Cc: Rob Herring
Cc: Wolfram Sang
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
Documentation/devic
the vc4_hdmi driver has some custom structures to hold the data it needs to
associate with the drm_encoder and drm_connector structures.
However, it allocates them separately from the vc4_hdmi structure which
makes it more complicated than it needs to be.
Move those structures to be contained by
Since we don't care about retrieving the clk_lookup structure pointer
returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev
function.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 11
Similarly to the audio support, CEC support is not there yet for the
BCM2711, so let's skip entirely the CEC initialization through a variant
flag.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4
drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
2 files changed, 7 insertions(+)
The pllb_arm clock is defined as a fixed factor clock with the pllb clock
as a parent. However, all its configuration is entirely static, and thus we
don't really need to call clk_hw_register_fixed_factor but can simply call
clk_hw_register with a static clk_fixed_factor structure.
Cc: Michael Tur
The function vc4_hdmi_connector_detect access its vc4_hdmi struct by
dereferencing the pointer in the structure vc4_dev. This will cause some
issues when we will have multiple HDMI controllers, so let's just use the
local variable for now instead of dereferencing that pointer all the time,
and we'l
The firmware has an interface to discover the clocks it exposes.
Let's use it to discover, register the clocks in the clocks framework and
then expose them through the device tree for consumers to use them.
Cc: Michael Turquette
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Signed-off-by: Maxi
We're calling vc4_debugfs_add_file with our struct vc4_hdmi pointer set
in the private field, but we don't use that field and go through the
main struct vc4_dev to get it.
Let's use the private field directly, that will save us some trouble
later on.
Signed-off-by: Maxime Ripard
---
drivers/gpu
The raspberrypi_register_pllb has been returning an integer so far to
notify whether the functions has exited successfully or not.
However, the OF provider functions in the clock framework require access to
the clk_hw structure so that we can expose those clocks to device tree
consumers.
Since we
In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with
pixelvalves each being assigned to a given output, but each output can
then be muxed to feed from multiple FIFOs.
Since vc4 had that entirely static, both were probably equivalent, but
since that changes, let's rename hvs_channel to hvs
1 - 100 of 254 matches
Mail list logo
