", i);
> imx_ldb->clk_sel[i] = devm_clk_get(imx_ldb->dev, clkname);
> if (IS_ERR(imx_ldb->clk_sel[i])) {
> ret = PTR_ERR(imx_ldb->clk_sel[i]);
> --
> 2.39.2
--
Ville Syrjälä
Intel
ach
> an agreement.
>
> I raised the same question to Wolfram.
I don't know where that discussion happened, but my opinion
is NAK to "client". Life is already confusing enough with
these renames, so let's not make it even more confusing by
inventing new names nowhere to be found in the spec.
And let's especially not invent names that don't even fit
the purpose. "Client" makes me think of "client/server" or
some real world analogy. Neither of which seem to have any
resemblence to how the term would be used for i2c.
--
Ville Syrjälä
Intel
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the
+ /**
> + * @acpi_edid_allowed: Get the EDID from the BIOS, if available.
> + * This is only applicable to eDP and LVDS displays.
> + */
> + bool acpi_edid_allowed;
Aren't there other bools/small stuff in there for tighter packing?
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7923bc00dc7a..1c1ee927de9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -459,5 +459,6 @@ bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> +const struct drm_edid *drm_edid_read_acpi(struct drm_connector *connector);
>
> #endif /* __DRM_EDID_H__ */
> --
> 2.34.1
--
Ville Syrjälä
Intel
cting vscan>1 outright. Which driver is this?
Is there an actual usecase where nouveau needs this (and does
it even work?) or could we just rip out the whole thing and
reject vscan>1 globally?
>
> return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
> }
> --
> 2.25.1
--
Ville Syrjälä
Intel
e DPCD backlights that need PWM
> enable/disable")
> Cc: # v5.12+
Seems consistent enough.
Reviewed-by: Ville Syrjälä
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 27 ++-
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git
On Fri, Oct 22, 2021 at 03:01:52PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> > On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
&g
On Fri, Oct 22, 2021 at 12:25:33PM +0200, Claudio Suarez wrote:
> On Thu, Oct 21, 2021 at 04:49:59PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 20, 2021 at 12:51:21AM +0200, Claudio Suarez wrote:
> > > drm_get_edid() internally calls to drm_connector_up
intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
> connector->display_info.is_hdmi;
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
ev, "%s: EDID invalid.\n",
> + connector->name);
Could you respin this to use the standard [CONNECTOR:%d:%s] form
while at it? Or I guess a patch to mass convert the whole drm_edid.c
might be another option.
Patch looks good.
Reviewed-by: Ville Syrjälä
> return 0;
> }
>
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
es, the VESA backlight interface will stop working once
> we've programmed the
> + * panel with Intel's OUI - which is also required for us to be able to
> detect Intel's
> + * backlight interface at all. This means that the only sensible way
> for us to detect bot
rols to work. In the mean time,
> these machines typically
> - * work just fine using normal PWM controls anyway.
> - */
> - if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> - drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> + if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
> drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
> return true;
> }
> --
> 2.31.1
--
Ville Syrjälä
Intel
On Fri, Oct 15, 2021 at 10:33:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> > On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
On Fri, Oct 15, 2021 at 09:24:06PM +0200, Claudio Suarez wrote:
> On Fri, Oct 15, 2021 at 03:03:13PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 15, 2021 at 01:36:59PM +0200, Claudio Suarez wrote:
> > > According to the documentation, drm_add_edid_modes
> > > "...
;
> A helper like this belongs in drm, not i915. Seems useful in other
> drivers too.
Not sure it's actually helpful for i915. We end up having to root around
in the display_info in a lot of places anyway. So a helper for single
boolean seems a bit out of place perhaps.
--
Ville Syrjälä
Intel
nnector->is_hdmi) {
> - intel_sdvo->has_hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> intel_sdvo->has_hdmi_audio =
> drm_detect_monitor_audio(edid);
> + intel_sdvo->has_hdmi_monitor =
> +
> intel_connector_is_hdmi_monitor(connector);
FYI there's a third copy of this in intel_dp.c
> }
> } else
> status = connector_status_disconnected;
> --
> 2.33.0
>
--
Ville Syrjälä
Intel
drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
> return 0;
> --
> 2.33.0
>
>
--
Ville Syrjälä
Intel
eau: Use drm_fb_helper_fill_info")
also broke the abi. But for the pm-utils use case at least
just having the "drmfb" in there should cover even nouveau.
Cc: sta...@vger.kernel.org
Reviewed-by: Ville Syrjälä
>
> Reported-by: Johannes Stezenbach
> Signed-off-by: Javier Marti
ant
changes coming in via drm-misc they usually will cause conflicts for
people during drm-tip rebuild. Also I would expect to see an ack
requested from i915 maintainers for merging anything significant via
drm-misc, which I don't think happened in this case.
--
Ville Syrjälä
Intel
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:
On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > > On F
On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> On Fri, Oct 01, 2021 at 10:00:50PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:36:55PM -0400, Sean Paul wrote:
> > > On Fri, Sep 24, 2021 at 08:43:07AM +0200, Fernando Ramos wrote:
> > > >
() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
> > drm/i915: cleanup: drm_modeset_lock_all() -->
> > DRM_MODESET_LOCK_ALL_BEGIN() part 2
> > drm/gma500: cleanup: drm_modeset_lock_all() -->
cture where the driver is fully initialzied
before anything gets exposed to userspace.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
_is_tiled(fb->modifier) ||
> + is_nouveau_device(fb->fd))
> create_cairo_surface__gpu(fd, fb);
> else
> create_cairo_surface__gtt(fd, fb);
> @@ -3733,6 +3805,8 @@ void igt_remove_fb(int fd, struct ig
65, and after removing a bogus max_w==max_h
assert it all passed, and your non-square probing worked fine.
I'll need to send a patch to nuke that bogus assert, and I also had
an idea to test the max sized cursor as well (in case it's not square
and thus not being tested already)...
with the
On Fri, Mar 19, 2021 at 02:43:56PM -0400, Lyude Paul wrote:
> On Fri, 2021-03-19 at 20:00 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 01:40:52PM -0400, Lyude Paul wrote:
> > > On Fri, 2021-03-19 at 17:01 +0200, Ville Syrjälä wrote:
> > > > On Thu, Ma
On Fri, Mar 19, 2021 at 01:40:52PM -0400, Lyude Paul wrote:
> On Fri, 2021-03-19 at 17:01 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 18, 2021 at 06:21:23PM -0400, Lyude wrote:
> > > From: Lyude Paul
> > >
> > > Currently we just assume that every cu
igt_subtest_group {
> + igt_fixture
> + require_cursor_size(data, w, h);
> +
> + /* Using created cursor FBs to test cursor support */
> + igt_subtest_
efb875 ("lib/igt_fb: Fix domain tracking for GTT cairo surfaces")
then got broken again by
commit 89b3ffe02c2a ("lib: Map dumb buffers")
and later fixed again with
commit 3bd68529c464 ("lib/igt_fb: Add missing set_domain calls")
So yeah, not needed anymore.
Reviewed-by:
nel to see if it accepts the
requested cursor size, and skip the subtest if not. That
would also let us remove the i915 platform specific information
from has_nonsquare_cursors().
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesk
iers;
> +
> + ret = drm_universal_plane_init(dev, >plane, heads, _wndw,
> format, nformat,
> +format_modifiers, type, "%s-%d", name,
> index);
> if (ret) {
> kfree(*pwndw);
>
On Tue, Sep 29, 2020 at 01:54:13PM -0400, Lyude Paul wrote:
> On Mon, 2020-09-28 at 16:01 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote:
> > > While I thought I had this correct (since it actually did reject modes
> > > lik
org/archives/dri-devel/2020-September/280276.html
>
> For more info.
>
> So, let's rewrite this using Ville's advice.
>
> Signed-off-by: Lyude Paul
> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits
> for mode validation")
> Cc: Ville Syrjä
ownstream_max_dotclock();
if (ds_clock && mode->clock > ds_clock)
return CLOCK_HIGH;
+ a bit more if you want to also deal with the TMDS
clock limits sensibly. That also requires some though
as to which bpc to use. In i915 we assume 8bpc when
calculating the TMDS clock since that's the minimum
DVI/HDMI supports.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
e Paul
Thanks for the review. I fixed up the missing/bad docs and
pushed the lot to drm-intel-next-queued (with Daniel's irc ack).
PS.
Had to s/drm_dp_downstream_max_clock/drm_dp_downstream_max_dotclock/
in nouveau_dp.c to keep it in a buildable shape. I hope I didn't step
on too many toes with this...
--
On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > It's next to impossible for us to do connector probing on topologies
> > >
topology_put_port(port);
> return ret;
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
sfer-Encoding: 8bit
In-Reply-To:
X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)
On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
> wrote:
>
> > OK, so I went ahead a wrote a bit of cocci [1] to find the b
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> wrote:
> > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
>
> > > I have long suspected that a whole bunch of the "simple" displays
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > wrote:
> > &g
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> > On 25.02.2020 12:21, Ville Syrjälä wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2
On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> On 19.02.2020 21:35, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Get rid of mode->vrefresh and just calculate it on demand. Saves
> > a bit of space and avoids the cached value gettin
pclk);
> >
>
> This just caught my eye while browsing the patch.
> It looks like a backward way to get the clock.
Yep. I'll cook up a patch to switch this to ->clock.
>
> But patch is fine, it was just a drive-by comment.
>
> Whole patch is:
> Reviewed-
-off-by: Thomas Zimmermann
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c| 27 +++
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> include/drm/drm_vblank.h| 10 +-
> 3 files changed, 9 insertions(+), 30 deletions(-)
>
pipe)
> {
> + struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> struct drm_pending_vblank_event *e, *t;
> ktime_t now;
> u64 seq;
> + bool high_prec;
>
> assert_spin_locked(>event_lock);
>
> @@ -1812,8 +1866,10 @@ static void drm_handle_vblank_
djusted_mode,
> + * drm_crtc_vblank_helper_get_vblank_timestamp(). We can't just access
> + * the hardware mode by e.g. looking at _crtc_state.adjusted_mode,
>* because that one is really hard to get from interrupt context.
>*/
> struct drm_display_mode hwmode;
> @@ -238,4 +238,22 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
> void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
> u32 max_vblank_count);
> +
> +/*
> + * Helpers for struct drm_crtc_funcs
> + */
> +
> +bool
> +drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> + struct drm_crtc *crtc, int *max_error, ktime_t *vblank_time,
> + bool in_vblank_irq,
> + bool (*get_scanout_position)(struct drm_crtc *crtc,
> + bool in_vblank_irq, int *vpos, int
> *hpos,
> + ktime_t *stime, ktime_t *etime,
> + const struct drm_display_mode *mode));
Ugly alignment. Could maybe add a typedef for the function pointer if it
otherwise gets super horrible with proper alignment.
> +bool drm_crtc_vblank_helper_get_vblank_timestamp(struct drm_crtc *crtc,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq);
> +
> #endif
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Thu, Jan 16, 2020 at 09:44:55AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 15.01.20 um 15:49 schrieb Ville Syrjälä:
> > On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote:
> >> @@ -2020,3 +2042,193 @@ int drm_crtc_queue_sequence_ioctl(struct
> >
>vblank[pipe];
> - vblank_enabled = dev->vblank_disable_immediate &&
> READ_ONCE(vblank->enabled);
> + vblank_enabled = __vblank_disable_immediate(dev, pipe) &&
> + READ_ONCE(vblank->enabled);
>
> if (!vblank_enabled) {
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
pipe = crtc->pipe;
> int position;
> int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> @@ -879,6 +881,14 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev,
> unsigned int index,
> return true;
> }
>
> +bool i915_crtc_get_vblank_timest
e new
> >> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
> >> wrappers passing in the relevant get_scanout_position function.
> >
> > Of course. Will be in v2 of the series.
>
> Please give Ville (Cc'd) a moment before sending v2 in case he wants
same job
> with no functional change.
I don't think non-atomic drivers have that fallback in place.
They probable should...
Apart from that lgtm
Reviewed-by: Ville Syrjälä
>
> v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
>
> Suggested-by: Ville Syrjälä
&g
@lock: mutex protecting this struct
> * @adap: the CEC adapter for CEC-Tunneling-over-AUX support.
> - * @name: name of the CEC adapter
> - * @parent: parent device of the CEC adapter
> + * @connector: the connector this CEC adapter is associated with
> * @unregister_work: unreg
On Wed, Aug 28, 2019 at 11:11:41AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
> wrote:
> >
> > On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > > wrote:
> &
On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> wrote:
> >
> > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > > This should probably be fixed to account for the scenario where an
>
veau_encoder.h
> > index 3517f920bf89..e17971a30221 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
> > @@ -63,6 +63,7 @@ struct nouveau_encoder {
> > struct nv50_mstm *mstm;
> >
coder's possible_clones field.
> + * Returns:
> + * A bit mask with the nth bit set, where n is the index of the encoder. Take
> + * care when using this, as the DRM UAPI only allows for 32 bit encoder masks
> + * while internally encoder masks are 64 bits.
> */
> -static inline u32 drm_encoder_mask(const struct drm_encoder *encoder)
> +static inline u64 drm_encoder_mask(const struct drm_encoder *encoder)
> {
> return 1 << drm_encoder_index(encoder);
> }
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
s awesome!
Can't quite tell if that's irony or not. Anyways, this has been
suggested before but no volunteers stepped forward.
> drm_atomic_state is indeed not a state, but a transaction representing
> how we go from the old to the new state.
On a semi-related topic, I've occasionally pondered about moving
mode_changed & co. from the obj states to the top level
state/transaction (maybe stored as a bitmask). But that would
definitely not be a trivial sed job.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:38, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> >> On 21.11.2018 19:19, Laurent Pinchart wrote:
> >>> Hi Ville,
>
On Wed, Dec 05, 2018 at 09:46:40AM +0100, Andrzej Hajda wrote:
> On 05.12.2018 07:32, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
&g
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Vi
On Wed, Dec 05, 2018 at 08:40:34AM +0100, Andrzej Hajda wrote:
> On 04.12.2018 20:02, Ville Syrjälä wrote:
> > On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> >> On 03.12.2018 22:48, Ville Syrjälä wrote:
> >>> On Thu, Nov 29, 2018 at 09:46:1
On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Quite late, hopefully not too late.
>
>
> On 21.11.2018 12:51, Ville Syrjälä wrote:
> > On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>
> >>> return;
> >>&
On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> On 21.11.2018 19:19, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > Thank you for the patch.
> >
> > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
> >> From: Ville Syrjä
create_scaling_mode_property(struct drm_device *dev);
> int drm_connector_attach_content_type_property(struct drm_connector *dev);
> int drm_connector_attach_scaling_mode_property(struct drm_connector
> *connector,
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> On Tue, 20 Nov 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make life easier for drivers by simply passing the connector
> > to drm_hdmi_avi_infoframe_from_display_mode() and
> > d
(crtc_state, 0, sizeof(*crtc_state));
> - crtc_state->base.crtc = >base;
> + __drm_atomic_helper_crtc_reset(>base, _state->base);
intel_crtc_init() could use the same treatment.
And intel_create_plane_state() could use the plane reset. In fact it
looks like we aren't intializing plane constant alpha at all. So it'll
start out as zero which probably isn't what most people would expect.
I also wonder if this patch shouldn't be split up more. Just in case
there's some unforseen regression somewhere I'd hate to see the
entire thing get reverted.
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
tform_probe(struct platform_device
> *pdev)
> static int nouveau_platform_remove(struct platform_device *pdev)
> {
> struct drm_device *dev = platform_get_drvdata(pdev);
> +
> + drm_mode_config_cleanup(dev);
> nouveau_drm_device_remove(dev);
> +
> return 0;
> }
>
> --
> 2.19.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
te = drm_atomic_get_new_crtc_state(state,
> new_connector_state->crtc);
> crtc_state->connectors_changed = true;
>
> DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> [CRTC:%d:%s]\n",
> --
> 2.17.1
>
> __
y there are three driver structs in nouveau.
Maybe someone can just nuke two of them?
>
> On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We now have per-device driver_features, so let's use that
> > to disable atomic only for
n while we're at it since it's
> nearly impossible to read properly.
>
> Changes since v1:
> - Don't skip ddc probing for LVDS if we can't switch DDC through
> vga-switcheroo, just do the DDC probing without calling
> vga_switcheroo_lock_ddc() - skeggsb
>
> Signed-off-by: Ly
anyway.
The current code looks somewhat busted anyway. First problem is that
it's accessing crtc->state without the appropriate locks held (unless
something always pulls in all crtcs to every commit?). Second issue
is that the rpm_put() is called without waiting for nonblocking commits
to have fin
On Mon, Jul 02, 2018 at 04:04:45PM +0300, Ville Syrjälä wrote:
> On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote:
> > Hi Ville,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > url:
> > https://github.com/0day-c
> nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1);
> 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300);
> 1a1841d30 Ben Skeggs 2012-12-10 428 }
> 1a1841d30 Ben Skeggs 2012-12-10 429 }
> 6ee738610 Ben Skeggs 200
On Thu, Jun 28, 2018 at 04:13:06PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Changes from the previous version mainly involve Danoie's suggestion
Can't type today either: "Daniel's"
> of hiding the drm_encoder_find() in the iterator macro. I also polished
>
On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 20:29:48 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 19:5
On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 19:54:02 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> > > On Fri, 11 May 2018 18:3
On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:
> On Fri, 11 May 2018 18:34:50 +0300
> Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
>
> > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:
> > > Applying an underscan setup i
tate)
> vc4_state->crtc_w = state->crtc_w;
> vc4_state->crtc_h = state->crtc_h;
>
> + ret = vc4_plane_underscan_adj(state);
> + if (ret)
> + return ret;
> +
> vc4_state->x_scali
scan_hborder_property;
> +
> + /**
> + * @underscan_hborder_property: Optional connector underscan vertical
> + * border (expressed in pixels). Used by the driver to adjust the
> + * output image position and compensate an overscan done on the display
> +
@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs;
> nouveau@lists.freedesktop.org
> Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()
>
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> drm_prope
On Tue, Feb 27, 2018 at 10:49:39AM +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote:
> > On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> > > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> > &g
On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> > <ville.syrj...@linux.intel.com> wrote:
> >> From: Ville Sy
On Thu, Feb 08, 2018 at 07:34:11PM -0500, Ilia Mirkin wrote:
> On Wed, Feb 7, 2018 at 12:01 PM, Ville Syrjälä
> <ville.syrj...@linux.intel.com> wrote:
> > On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> >> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia M
On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> > In case anyone's curious about 30bpp framebuffer support, here's the
> > current status:
> >
> > Kernel:
> >
> > Ben and I have
ay that they prefer YCbCr 4:2:0 over
RGB 4:4:4.
> - Test out Wayland compositors
> - Teach xf86-video-modesetting about addfb2 or that nouveau's
> ordering is different.
>
> I don't necessarily plan on working further on this, so if there are
> interested parties, they should def
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> This series first unifies all users of drm_atomic_helper_check_plane_state()
> to populate the clip rectangle with drm_mode_get_hv_timing(), and once
>
gt; + *
> + * Bitmask used to look for drm plane reflections.
> + */
> +#define DRM_MODE_REFLECT_MASK (\
> + DRM_MODE_REFLECT_X | \
> + DRM_MODE_REFLECT_Y)
> +
> +
> struct drm_mode_modeinfo {
> __u32 cl
;
> plane->state = _state->base;
> plane->state->plane = plane;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
On Wed, Mar 29, 2017 at 10:24:05AM -0400, Alastair Bridgewater wrote:
> On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
> >
> > On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote:
> > > And the tenth
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmi_infoframe.c
>
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
gt; + crtc_state->pflip_flags = flags;
Still wondering why we can't afford to spell out "page_flip" completely?
>
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state))
> return PTR_ER
s:
> + *
> + * Flip related config options
> + */
> + u32 pflip_flags;
> +
> struct drm_atomic_state *state;
> };
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
-blocking operation. But you can argue that
userspace is being silly if it sends such things, and we can just refuse
it early on.
--
Ville Syrjälä
Intel OTC
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Thu, Dec 13, 2012 at 12:54:44PM +0100, Daniel Vetter wrote:
On Thu, Dec 13, 2012 at 12:38 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
And if we _really_ want such semantics, we can always get them by
introducing another pageflip mutex between the mode_config.mutex
97 matches
Mail list logo
