On Tue, 25 Aug 2020 at 17:21, Alexander Kapshuk
wrote:
>
> Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have
> had my mouse pointer disappear soon after logging in, and I have
> observed the system freezing temporarily when clicking on objects and
> when typing text.
> I have
On Wed, 26 Aug 2020 at 02:52, Lyude Paul wrote:
>
> On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> > On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
> > > Not entirely sure why this never came up when I originally tested this
> > > (maybe some BIOSes already have this setup?) but the
Hi Paul,
On Thu, 27 Aug 2020 at 09:04, Paul Cercueil wrote:
>
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
>
Hi, Chunfeng & Kishon:
How do you feel about this patch?
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2020年8月23日 週日 上午9:48寫道：
>
> Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
> drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
> information.
>
>
Hi, Chunfeng & Kishon:
How do you feel about this patch?
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2020年8月23日 週日 上午9:48寫道：
>
> From: CK Hu
>
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy
On Mon, Aug 24, 2020 at 02:23:42PM -0400, Alex Deucher wrote:
On Mon, Aug 24, 2020 at 12:36 PM Sasha Levin wrote:
From: Jiansong Chen
[ Upstream commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3 ]
gfxoff is temporarily disabled for navy_flounder,
since at present the feature has broken some
Hi Marek.
On Thu, Aug 27, 2020 at 01:39:06PM +0200, Marek Szyprowski wrote:
> Hi Sam,
>
> On 26.07.2020 22:33, Sam Ravnborg wrote:
> > Prepare the tc358764 bridge driver for use in a chained setup by
> > replacing direct use of drm_panel with drm_panel_bridge support.
> >
> > The bridge panel
Hi Laurent.
> >
> > Please read the cover letter, it explains why it's done this way. The
> > whole point of this patchset is to merge DSI and DBI frameworks in a
> > way that can be maintained.
>
> I think this proves the point that the proposed naming is confusing. At
> least a rename would
Hi Paul,
On Sun, Aug 30, 2020 at 06:48:12PM +0200, Paul Cercueil wrote:
> Le dim. 30 août 2020 à 16:36, 何小龙 (Leon He) a écrit :
> >> +struct ili9341 {
> >> + struct drm_panel panel;
> >> + struct mipi_dsi_device *dsi;
> >> + const struct ili9341_pdata *pdata;
> >> +
> >> +
https://bugzilla.kernel.org/show_bug.cgi?id=209071
Oscar Megía (megia.os...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
> +struct ili9341 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + const struct ili9341_pdata *pdata;
> +
> + struct gpio_desc*reset_gpiod;
> + u32 rotation;
> +};
> +
Hi Paul, you put the mipi_dsi_device inside the struct. I think it maybe
This is the V5 version of a series that introduces the writeback support
to VKMS. The first two patches of this series are a pre-work for the
latest patch that adds the writeback connector, this patchset can be seen
in two parts:
* A pre-work that aims to make vkms composer operations a little
The compute_crc() function is responsible for calculating the
framebuffer CRC value; due to the XRGB format, this function has to
ignore the alpha channel during the CRC computation. Therefore,
compute_crc() set zero to the alpha channel directly in the input
framebuffer, which is not a problem
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 writeback support.
Change in V4 (Emil and Melissa):
- Move signal completion above drm_crtc_add_crc_entry()
- Make writeback always
In the vkms_composer.c, some of the functions related to CRC and compose
have interdependence between each other. This patch reworks some
functions inside vkms_composer to make crc and composer computation
decoupled.
This patch is preparation work for making vkms able to support new
features.
Reviewed-by: Rodrigo Siqueira
On 08/25, Melissa Wen wrote:
> The VKMS blend function was ignoring the alpha channel and just
> overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a
> warning when running the kms_cursor_crc/cursor-alpha-transparent test
> case. In IGT,
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cycle
are now u64
Changes
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
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
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
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
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
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
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
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0
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 v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Changes in v5:
- Fix an
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
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
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
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
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 /*
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
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
Hi All,
Unfortunately while testing some unrelated things I found another issue with
this series related to the CHT ACPI GFX0._PS3 code poking the PWM controller
in unexpected ways.
This new version contains a new patch: "[PATCH v8 07/17] pwm: lpss: Always
update state and set update bit" fixing
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 =
From: Mike Rapoport
The only in-tree user for mbx driver for Intel 2700G graphics chip was
cm-x270 platform. Since this platform was removed by the commit
9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards") there is no
point to keep the obsolete framebuffer driver.
Signed-off-by: Mike
Additional properties or nodes actually might appear (e.g. power
domains) so use unevaluatedProperties to fix dtbs_check warnings like:
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
'iommus', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by:
Update the address of Maxime Ripard as one in @free-electrons.com does
not work.
Cc: Maxime Ripard
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Additional properties or nodes actually might appear (e.g. operating
points table) so use unevaluatedProperties to fix dtbs_check warnings
like:
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
'opp_table' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by:
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 21 +
drivers/gpu/drm/radeon/sumo_dpm.c| 20
This patch series adds support for reporting sclk and vddc values for Radeon
GPUs, where supported.
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_pm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=208839
sandy.8...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=207137
sandy.8...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Aug 26, 2020 at 12:02 PM Jani Nikula
wrote:
>
> On Thu, 20 Aug 2020, Maxime Ripard wrote:
> > This PR diffstat is pretty massive since we merged 5.9-rc1 and it's not
> > (yet?) in drm-next.
> >
> > I'm not entirely sure how to tackle this (if it causes an issue?).
> >
> > Let me know,
43 matches
Mail list logo
