On 30.09.2022 17:45, Matt Roper wrote:
> Rather than treating multicast registers as 'i915_reg_t' let's define
> them as a completely new type. This will allow the compiler to help us
> make sure we're using multicast-aware functions to operate on multicast
> registers.
>
> This plan does break d
On 10/11/22 18:51, Javier Martinez Canillas wrote:
> Add a helper function and make drivers that have the same logic in their
> struct drm_crtc_helper_funcs .atomic_check handler to use this instead.
>
> Patch #1, #2 and #3 are just cleanups for the mgag200, simpledrm and
> ssd130x drivers respect
Hello,
On 10/12/22 16:27, Michal Suchánek wrote:
[...]
>>
>> If you are using the framebuffer code from vga.c, I would guess that
>> that you can run a big-endian kernel with qemu-system-ppc64,
>> or a little-endian kernel with qemu-system-ppc64le and get the
>> correct colors, while running a l
Il 12/10/22 21:12, Justin Green ha scritto:
Tested on MT8195 and confirmed both correct video output and improved DRAM
bandwidth performance.
v3:
* Replaced pitch bitshift math with union based approach.
* Refactored overlay register writes to shared code between non-AFBC and
AFBC.
* Minor co
在 2022/10/13 14:39, Cai Huoqing 写道:
On 27 9月 22 13:38:47, Yuan Can wrote:
After commit 64ff18911878("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE
Hi yuan,
This is not a valid Fixes: tag.
Add to your ~/.gitconfig and add:
[pretty]
fixes = Fixes: %h (\"%s\")
You can then do
git l
On Thu, 13 Oct 2022, Gwan-gyeong Mun wrote:
> diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
> index 0d98c9bc75da..44da9d190057 100644
> --- a/lib/overflow_kunit.c
> +++ b/lib/overflow_kunit.c
> @@ -16,6 +16,11 @@
> #include
> #include
>
> +/* We're expecting to do a lot of "always
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was moved to another file with
commit 85397f6bc4ff ("drm/mg
Hi Noralf,
On Sat, Oct 01, 2022 at 02:52:06PM +0200, Noralf Trønnes wrote:
> Den 29.09.2022 18.31, skrev Maxime Ripard:
> > Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> > 625-lines modes in their drivers.
> >
> > Since those modes are fairly standard, and that we'll need
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
>
> adv7533 bridge tries to dynamically switch lanes based on the
> mode by detaching and attaching the mipi dsi device.
>
> This approach is incorrect because this method of dynamic switch of
> detaching and attaching the mipi dsi device also res
Hi Justin,
On Wed, 12 Oct 2022 at 20:12, Justin Green wrote:
> @@ -226,6 +249,32 @@ int mtk_ovl_layer_check(struct device *dev, unsigned
> int idx,
> if (state->fb->format->is_yuv && rotation != 0)
> return -EINVAL;
>
> + if (state->fb->modifier) {
>
Please spell t
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Nirmoy Das
---
include/drm/drm_print.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_print.h b/include/drm/dr
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file cha
Hi Florian,
On Mon, Oct 10, 2022 at 12:07:22PM -0700, Florian Fainelli wrote:
> On 10/10/22 04:44, Maxime Ripard wrote:
> > Hi Florian,
> >
> > On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
> > > Those patches used to be part of a larger clock fixes series:
> > > https://lore.ker
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was mov
Hi,
Those patches used to be part of a larger clock fixes series:
https://lore.kernel.org/linux-clk/20220715160014.2623107-1-max...@cerno.tech/
However, that series doesn't seem to be getting anywhere, so I've split out
these patches that fix a regression that has been there since 5.18 and that
p
We'll need the clock IDs in more drivers than just the clock driver from
now on, so let's move them in the firmware header.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 18 --
include/soc/bcm2835/raspberrypi-firmware.h | 18 ++
2 f
A significant number of RaspberryPi drivers using the firmware don't
have a phandle to it, so end up scanning the device tree to find a node
with the firmware compatible.
That code is duplicated everywhere, so let's introduce a helper instead.
Signed-off-by: Maxime Ripard
---
drivers/firmware/r
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60 parameter in their config.txt file.
We were detecting this so far by calling clk_round_rate() on the core
clock with the frequency we're supposed to run at when one of those
modes is enabled. Whether or not the pa
The firmware allows to query for its clocks the operating range of a
given clock. We'll need this for some drivers (KMS, in particular) to
infer the state of some configuration options, so let's create a
function to do so.
Acked-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/firmware
Following the clock rate range improvements to the clock framework,
trying to set a disjoint range on a clock will now result in an error.
Thus, we can't set a minimum rate higher than the maximum reported by
the firmware, or clk_set_min_rate() will fail.
Thus we need to clamp the rate we are abo
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60 parameter in their config.txt file.
This will have the side-effect of raising the maximum of the core clock,
tied to the HVS, and managed by the HVS driver.
However, we are querying this in the HDMI driver by pok
From: Dom Cobley
At least the 4096x2160@60Hz mode requires some overclocking that isn't
available by default, even if hdmi_enable_4kp60 is enabled.
Let's add some logic to detect whether we can satisfy the core clock
requirements for that mode, and prevent it from being used otherwise.
Signed-o
Hello Maxime,
On 9/2/22 16:41, Maxime Ripard wrote:
> The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
> will register a device matching the HDMI codec driver, and then register
> an ASoC card using tha
On 2022-10-12 16:08:07, Abhinav Kumar wrote:
>
>
> On 10/9/2022 11:51 AM, Marijn Suijten wrote:
> > According to the `/* bpc 8 */` comment below only values for a
> > bits_per_component of 8 are currently hardcoded in place. This is
> > further confirmed by downstream sources [1] containing diff
On 2022-10-12 16:03:06, Abhinav Kumar wrote:
>
>
> On 10/9/2022 11:50 AM, Marijn Suijten wrote:
> > As per the FIXME this code is entirely duplicate with what is already
> > provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
> > why this comment was put in place instead of res
On 13/10/2022 11:05, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested
Hello Maxime,
On 9/29/22 11:21, Maxime Ripard wrote:
> This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
> rate initialization"), with the code slightly moved around.
>
> It turns out that we can't downright remove that code from the driver,
> since the Pi0-3 and Pi4 are in di
On 9/29/22 11:21, Maxime Ripard wrote:
> If our HSM clock has not been properly initialized, any register access
> will silently lock up the system.
>
> Let's check that this can't happen by adding a check for the rate before
> any register access, and error out otherwise.
>
> Link:
> https://lo
/vc4_dpi.c | 16 +---
include/uapi/linux/media-bus-format.h | 5 -
2 files changed, 17 insertions(+), 4 deletions(-)
---
base-commit: c9b48b91e2fbb74fb981aa616a6ef3c78194077f
change-id: 20221013-rpi-dpi-improvements-c3d755531c39
Best regards,
--
Maxime Ripard
From: Joerg Quinten
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X18 supported by the
RaspberryPi.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/media-
From: Joerg Quinten
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X24_CPADHI supported by the
RaspberryPi.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux
From: Dave Stevenson
DPI hasn't really been used up until now, so the default has
been meaningless.
In theory we should be able to pass the desired format for the
adjacent bridge chip through, but framework seems to be missing
for that.
As the main device to use DPI is the VGA666 or Adafruit Kip
From: Chris Morgan
The RGB565 format with padding over 24 bits
(MEDIA_BUS_FMT_RGB565_1X24_CPADHI) is supported by the vc4 DPI
controller as "mode 3". This is what the Geekworm MZP280 DPI display
uses, so let's add support for it in the DPI controller driver.
Reviewed-by: Dave Stevenson
Signed-
From: Joerg Quinten
The VC4 DPI output can support multiple BGR666 variants, but they were
never added to the driver. Let's add the the support for those formats.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 6 ++
1 file changed, 6 insertio
From: Chris Morgan
Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm
MZP280 panel for the Raspberry Pi.
Signed-off-by: Chris Morgan
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/i
From: Dave Stevenson
The mapping is incorrect for RGB565_1X16 as it should be
DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3.
Fixes: 08302c35b59d ("drm/vc4: Add DPI driver")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 2 +-
On Thu, Oct 13, 2022 at 11:05:19AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
> > For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
> > or "signal out of range" on VGA display.
> > previous code had "m |= 0x80" which was changed to
> >
This series let driver can read properties from dt to restrict dp output
bandwidth.
Changes in v3:
-Rename property name.
Changes in v4:
-Use data-lanes and link-frequencies instead of "ite,dp-output-data-lane-count"
and "ite,dp-output-max-pixel-clock-mhz".
allen chen (2):
dt-bindings: it6505
From: allen chen
Add driver to read data-lanes and link-frequencies from dt property to
restrict output bandwidth.
Signed-off-by: Allen chen
Signed-off-by: Pin-yen Lin
---
drivers/gpu/drm/bridge/ite-it6505.c | 54 +++--
1 file changed, 51 insertions(+), 3 deletions(-)
From: allen chen
Add properties to restrict dp output data-lanes and clock.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.yaml | 43 +++
1 file changed, 43 insertions(+)
diff --git a/Documentation/devicetree/bindings/display
The main purpose of this series is to improve the synchronizations of
it6505 driver. The first two patches are required for the third one, but
they alone can be clean ups to the driver.
Changes in v2:
- Remove redundant spaces in it6505_detect
- Read sink count in it6505_irq_hpd
- Add the empty li
During device boot, the HPD interrupt could be triggered before the DRM
subsystem registers it6505 as a DRM bridge. In such cases, the driver
tries to access AUX channel and causes NULL pointer dereference.
Initializing the AUX channel earlier to prevent such error.
Fixes: b5c84a9edcd4 ("drm/bridg
Originally, the it6505 relies on a short sleep in the IRQ handler and a
long sleep to make sure it6505->lane_swap and it6505->lane_count is
configured in it6505_extcon_work and it6505_detect, respectively.
Use completion and additional DPCD read to remove the unnecessary waits,
and use a different
Move the DPCD read and link setup steps to HPD IRQ handler to remove
an unnecessary dependency between .detect callback and the HPD IRQ
handler before registering it6505 as a DRM bridge. This is safe because
there is always a .detect call after each HPD IRQ handler triggered by
the drm_helper_hpd_i
Hi Allen,
Thank you for the patch.
On Thu, Oct 13, 2022 at 06:51:13PM +0800, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 43 +
Hold I/O-register lock in atomic_commit_tail to protect all pipeline
updates at once. Protects modesetting against concurrent EDID reads.
Complex modesetting operations involve mode changes and plane updates.
These steps used to be protected individually against concurrent I/O.
Make all this atomi
Always call drm_atomic_helper_check_plane_state() in each plane's
atomic_check function. At the minimum, it needs to set or clear the
plane state's 'visible' field. Otherwise the plane-state handling
is bogus and would keep updating planes that have been disabled.
While at it, also warn if the pri
This patchset converts ast to GEM SHMEM helpers. Fixes problems with
memory allocation and BMC scanout updates.
Patches 1 to 3 are fixes for various minor problems in the ast driver.
We should merge them even without SHMEM support.
Patches 4 to 6 prepare the driver for the conversion. The cursor
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from ast.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset(). There's no reason
to call drm_atomic_add_affected_planes() unco
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the address' value.
v2:
* only update offset if it changed (Jocelyn)
Reported-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Rename some of the variables in the plane code to better reflect the
old and new state during checks and updates. Change some indention as
well. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c |
Update the cursor image via damage handling in-place. The cursor's
double buffering has no visible effect on the output, so remove it.
Done in preparation of switching ast to GEM SHMEM helpers. Removing
double buffering will allow us to use the same data structure for
primary and cursor plane.
Si
Rename the plane structure struct ast_cursor_plane to struct
ast_plane as it will be used for the primary plane as well. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_drv.h | 15 +--
driv
Replace GEM VRAM helpers with GEM SHMEM helpers in ast. Avoids OOM
errors when allocating video memory. Also adds support for dma-buf
functionality.
Aspeed display hardware supports display resolutions of FullHD and
higher at 32-bit pixel depth. But the amount of video memory is in
the range of 8
On 10/12/2022 11:56 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that w
Hi Javier,
Thanks for reviewing this
On Thu, Oct 13, 2022 at 11:27:15AM +0200, Javier Martinez Canillas wrote:
> On 9/2/22 16:41, Maxime Ripard wrote:
> > The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> > order to set it up properly, in vc4_hdmi_audio_init(), our HDMI dr
On Thu, 29 Sep 2022 11:21:17 +0200, Maxime Ripard wrote:
> This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
> rate initialization"), with the code slightly moved around.
>
> It turns out that we can't downright remove that code from the driver,
> since the Pi0-3 and Pi4 are in
On Fri, 2 Sep 2022 16:41:11 +0200, Maxime Ripard wrote:
> The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
> will register a device matching the HDMI codec driver, and then register
> an ASoC card using
On Thu, 29 Sep 2022 11:21:18 +0200, Maxime Ripard wrote:
> If our HSM clock has not been properly initialized, any register access
> will silently lock up the system.
>
> Let's check that this can't happen by adding a check for the rate before
> any register access, and error out otherwise.
>
>
Hi Dave and Daniel,
this is the weekly PR for drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2022-10-13:
Short summary of fixes pull:
* vc4: HDMI fixes
The following changes since commit cc62d98bd56d45de4531844ca23913a15136c05b:
Revert "drm: bridge: analogix/dp: add panel prepare/unprep
On Wed, Oct 12, 2022 at 01:34:38PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote:
> > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson
> > wrote:
> > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote:
> > > > On Tue, Oct 4, 2022 at 10:35
Hi Dave, Daniel,
Not sure if there is time for one more pull during the merge window, but
in case there is here it is. Only one which affects platforms outside
force_probe and that is the fix for DPT PTE corruption after resume. The
rest are all DG2 specific.
Regards,
Tvrtko
drm-intel-next-fixe
Hello Max, Marek, Dave et al.
On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote:
> From: Max Krummenacher
>
> The property is used to set the enum bus_format and infer the bpc
> for a panel defined by 'panel-dpi'.
> This specifies how the panel is connected to the display interfac
On 13/10/2022 12:36, Ville Syrjälä wrote:
On Thu, Oct 13, 2022 at 11:05:19AM +0200, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x8
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
* The
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that fu
The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.
Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Signed-off-by:
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by: Maxime Ripard
---
Change
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Removed useless (
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usual
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_connector.h | 7 +++
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Signed-off-by
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Sig
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Switched to KUNIT_ASSERT_NOT_NULL
---
drivers/gpu/drm/drm_modes.c
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, the
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by: Mate
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcas
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Removed the count variable in get_modes
- Removed spurious vc4 change
---
drivers/gpu/drm/sun4i/sun
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was moved to another file with
commit 85397f6bc4ff ("drm/mg
Hi!
I bisected an issue of the 6.0 kernel which started happening after
6.0-rc7 on all my machines.
Backtrace of this issue looks like as:
[ 2807.339439] [ cut here ]
[ 2807.339445] WARNING: CPU: 11 PID: 2061 at
drivers/gpu/drm/drm_modeset_lock.c:276
drm_modeset_drop_locks
Am 13.10.22 um 15:28 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was moved
Thanks for the comments everyone! I'll upload a new CL sometime today.
I did want to ask though, I realize I should be using u32/u64 for
kernel code in general, but the rest of this file seems to be written
using unsigned int/unsigned long long. In this circumstance, does
keeping with the style of
On 10/12/2022 8:26 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that we
On 10/13/2022 4:34 AM, Tauro, Riana wrote:
On 10/12/2022 11:56 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min f
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
v5: s/hwmon_device_register_with_info/
devm_hwmon_device_register_with_info/ (Ashu
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use
Expose power1_max_interval, that is the tau corresponding to PL1, as a
custom hwmon attribute. Some bit manipulation is needed because of the
format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2: Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in d
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jan
1 - 100 of 147 matches
Mail list logo
