Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.
Note that these helpers are intended to handle DPCD related backlight
control
On Fri, Feb 5, 2021 at 6:45 PM Lyude Paul wrote:
>
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
> 1 file
Also, stop printing the DPCD register that failed, and just describe it
instead. Saves us from having to look up each register offset when reading
through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give
us that anyway).
Signed-off-by: Lyude Paul
---
Since we're about to be moving this code into shared DRM helpers, we might
as well start to cache certain backlight capabilities that can be
determined from the EDP DPCD, and are likely to be relevant to the majority
of drivers using said helpers. The main purpose of this is just to prevent
every
Get rid of the extraneous switch case in here, and just open code
edp_backlight_mode as we only ever use it once.
Signed-off-by: Lyude Paul
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
This is kind of an annoying aspect of DRM's DP helpers:
drm_dp_dpcd_readb/writeb() return the size of bytes read/written on
success, thus we want to check against that instead of checking if the
return value is less than 0.
I'll probably be fixing this in the near future once I start doing DP
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).
Signed-off-by: Lyude Paul
Cc: Jani Nikula
Cc: Dave Airlie
Cc: greg.depo...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 file
This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
DPCD backlight control
v2 series-wide changes:
* Rebase
v3 series-wide changes:
* Split
The hardware needs a FB which is packed. Add checks to make sure
this is the case.
While at it, add debug logs for the existing checks. This allows
user-space to more easily figure out why a configuration is
rejected.
v2:
- Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia)
-
On Friday, February 5th, 2021 at 11:36 PM, Ilia Mirkin
wrote:
> > --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> > @@ -30,6 +30,7 @@
> >
> > #include
> > #include
> > +#include
>
> Why is this needed?
This is needed for the
On Fri, 2021-02-05 at 17:36 -0500, Ilia Mirkin wrote:
> On Fri, Feb 5, 2021 at 5:24 PM Simon Ser wrote:
> >
> > The hardware needs a FB which is packed. Add checks to make sure
> > this is the case.
> >
> > While at it, add debug logs for the existing checks. This allows
> > user-space to more
On Fri, Feb 5, 2021 at 5:24 PM Simon Ser wrote:
>
> The hardware needs a FB which is packed. Add checks to make sure
> this is the case.
>
> While at it, add debug logs for the existing checks. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> v2:
> - Use
The hardware needs a FB which is packed. Add checks to make sure
this is the case.
While at it, add debug logs for the existing checks. This allows
user-space to more easily figure out why a configuration is
rejected.
v2:
- Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia)
-
On Friday, February 5th, 2021 at 10:50 PM, Ilia Mirkin
wrote:
> > return head->func->curs_format(head, asyw, asyh);
>
> While you're at it, maybe give this one some love too?
Sure, although this would be a driver bug because DRM core already
checks the format. curs_format has WARN_ON when it
On Fri, Feb 5, 2021 at 4:00 PM Simon Ser wrote:
>
> The hardware needs a FB which is packed. Add checks to make sure
> this is the case.
>
> While at it, add debug logs for the existing checks. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> v2:
> - Use
On Fri, 2021-02-05 at 22:00 +0100, Simon Ser wrote:
> The hardware needs a FB which is packed. Add checks to make sure
> this is the case.
>
> While at it, add debug logs for the existing checks. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> v2:
> -
On Friday, February 5th, 2021 at 6:34 PM, Ilia Mirkin
wrote:
> > + if (asyw->image.pitch[0] != asyw->image.w * 4) {
>
> Rather than hard-coding to 4, make this look at the format (or cpp,
> which should be available somewhere too I think). (Yeah, currently we
> only expose RGBA8, but we
The hardware needs a FB which is packed. Add checks to make sure
this is the case.
While at it, add debug logs for the existing checks. This allows
user-space to more easily figure out why a configuration is
rejected.
v2:
- Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia)
-
On Fri, 2021-02-05 at 12:34 -0500, Ilia Mirkin wrote:
> On Fri, Feb 5, 2021 at 11:45 AM Simon Ser wrote:
> >
> > The hardware needs a FB which is packed and not too large. Add
> > checks to make sure this is the case.
> >
> > While at it, add a debug log for the existing check. This allows
> >
On Fri, Feb 5, 2021 at 11:45 AM Simon Ser wrote:
>
> The hardware needs a FB which is packed and not too large. Add
> checks to make sure this is the case.
>
> While at it, add a debug log for the existing check. This allows
> user-space to more easily figure out why a configuration is
>
Op 05-02-2021 om 13:05 schreef Bhaskar Chowdhury:
s/fuck/heck/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
The hardware needs a FB which is packed and not too large. Add
checks to make sure this is the case.
While at it, add a debug log for the existing check. This allows
user-space to more easily figure out why a configuration is
rejected.
This commit depends on "drm/nouveau/kms/nv50-: Report max
s/fuck/heck/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc
index
s/fucking/messing/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index
26 matches
Mail list logo
