Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu/dr
So i'm sending these on the off-chance that DCE-8/10 do
support fp16 scanout without hw bugs. Would be nice to
enable this if it is supported, even if the hw can't do
HDR. This is also useful for non-HDR to get effectively
11 bpc precision from the fb to the display outputs for
more precise color r
Assuming the hw supports fp16, this would be also
useful for standard dynamic range displays, not
only for HDR use cases, because it would allow
to get more precise color reproduction with about
~11 bpc linear precision in the unorm range
0.0 -1.0.
Signed-off-by: Mario Kleiner
---
drivers/gpu/dr
Hello,
On Fri, Jun 05, 2020 at 03:53:15PM +0200, Jacopo Mondi wrote:
> On Fri, Jun 05, 2020 at 03:41:24PM +0200, Eugeniu Rosca wrote:
> > On Fri, Jun 05, 2020 at 03:29:00PM +0200, Jacopo Mondi wrote:
> >> On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote:
> >>> Could you kindly share t
Hi GVRao,
On Sun, May 31, 2020 at 05:41:50PM +, Venkateshwar Rao Gannavarapu wrote:
> On Sunday, May 24, 2020 8:38 AM, Laurent Pinchart wrote:
> > On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
> >> On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu wrote:
> >>> The
Hi Jonas,
On Tue, May 26, 2020 at 02:23:33PM +, Jonas Karlman wrote:
> On 2020-05-26 14:50, Neil Armstrong wrote:
> > On 26/05/2020 03:15, Laurent Pinchart wrote:
> >> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
> >> require a video output port connected to an HDMI sink
Hi Neil,
On Tue, May 26, 2020 at 02:50:21PM +0200, Neil Armstrong wrote:
> On 26/05/2020 03:15, Laurent Pinchart wrote:
> > On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
> > require a video output port connected to an HDMI sink (most likely an
> > HDMI connector, in rare cases
Hi Neil,
On Tue, May 26, 2020 at 02:35:19PM +0200, Neil Armstrong wrote:
> On 26/05/2020 03:15, Laurent Pinchart wrote:
> > Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
> > call drm_bridge_hpd_notify() notify to report HPD. This provides the
> > necessary API to support
Here's the dmesg from a successful boot (commit
f84e1ba336a4f47ae251e4d2d8a694902571b0df).
David
---
[0.007455] Normal [mem 0x0001-0x00041fdf]
[0.007456] Movable zone start for each node
[0.007456] Early memory node ranges
[0.007457] node 0: [mem 0x0
Hi,
I'm seeing the attached oops and panic from the i915 drm driver. I've tried
bisecting it, but there's a problem in that one of the merged branches causes
the machine to hang without output.
The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:
BUG: kernel NULL pointer de
Hi Emil,
On Fri, Jun 05, 2020 at 03:58:53PM +0100, Emil Velikov wrote:
> Hi Laurent,
>
> With the previous disclaimer in mind, the series is:
> Reviewed-by: Emil Velikov
Sorry, which disclaimer is that ?
> There's a small suggestion inline, for future work.
>
> On Sat, 30 May 2020 at 04:11, L
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
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()).
Signed-off-by: Hans de Goede
---
drivers/gp
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 poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
Add debug prints, test patch for moving i915 to atomic PWM.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 2cb0e2a9c08c..c1f8e6da0cd7 100644
--- a/
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
---
drivers/pwm/pwm-crc.c | 107 +++---
1 file changed, 59 insertions(+), 48 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/dri
On the LPSS PWM controller found on Bay Trail (BYT) and Cherry Trail (CHT)
platforms, the following sequence results in an output duty-cycle of 100%
independent of what the duty-cycle requested in the ctrl-reg is:
1. Clear ENABLE bit in ctrl register
2. Let the machine reach a S0i3 low power state
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
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 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
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 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
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
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-crc.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 58c7e9ef7278.
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
Hi All,
This patch series converts the i915 driver's cpde for controlling the
panel's backlight with an external PWM controller to use the atomic PWM API.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to support the atomic PWM API and
2. convert the i
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
On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> >
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs that can be used by virtio
> > > drivers to share exporte
Hi Maxime,
Am 05.06.20 um 16:35 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote:
>> Am 02.06.20 um 17:54 schrieb Maxime Ripard:
>>> On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
On Wed, May 27, 2020 at 8:51 AM Maxime Ripard
30 matches
Mail list logo
