From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 49DC04644E for ; Tue, 14 Jan 2025 22:21:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736893294; cv=none; b=cHyiSWvMnXwxfSHhF5bS2t3/Z4ZbSbhMJoPHA1MA7bGzSMg7XMNBAsvK3ne+XC+gzVWQlYKcGmSNaQdcZYAw7vpKG2TVo5SgLm/QWViutKwpRHB5DTOnd9m6eUIIPiyZW81YqrMcTdmBUaogx1W9P3ND9Yf68WIKWFdXN+sL7zc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736893294; c=relaxed/simple; bh=w1DAhUrO4DdQnXqEUxgYCMC/iBAa+9uJKXF6hks6Rqw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=h0UXFyzrEUefrhX6Fu42fMe+cnOWnHqo2rYmSCBi/J1c0yr3NuYd//M+SGPeI9hGYeXjjRfQ/W6FOsjSFmGOJPG7TVgLbPBDXm93TZWdkT4gOvboio2uCeXp2alrLLYJz8dGmsWHUoEshQpWnP7/A1Wt/NSI4KgI5Vl4Fb9ZK/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Mmkm36vM; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Mmkm36vM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736893291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9vJgeFoWfMpYZa2yqicc322CUq9ytQzvhdbBmt+4duA=; b=Mmkm36vMiOPbOmhPVMIsxTKmKOgk/O4mNLsrdyCOq/Hy3WKLL8Zlr7xisRYdZqTzE5oxmt bJcuocCdSA+q5kxGiTd1Wb+A1y+/OyASZLbmnIVmUYN+IMfk0yvOSeIv+p+Ry1fjx6tDHX nra/LMJMbvAWKYvoawZoLJn2k8Pbqkg= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-683-pXO9Ex2xMEGsWqCUdyKPmg-1; Tue, 14 Jan 2025 17:21:29 -0500 X-MC-Unique: pXO9Ex2xMEGsWqCUdyKPmg-1 X-Mimecast-MFC-AGG-ID: pXO9Ex2xMEGsWqCUdyKPmg Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4361fc2b2d6so33744345e9.3 for ; Tue, 14 Jan 2025 14:21:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736893288; x=1737498088; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9vJgeFoWfMpYZa2yqicc322CUq9ytQzvhdbBmt+4duA=; b=tO8Dgs49QsrwFtOsyPZ9Dv/yCbm9fGH5pNP3ZupECb4057VenMYVZEB1/xZo6sPmME Dr7d8V36mlbQmERt27mGKtIkt12Dm0fO6nEPqVi5XCvqHH3P4hpZfSrEH3yVQaDIgFOA 83duMw/O1VyuZDSz+ZWbC3PBBJdFk6go+zrBXerNm8cQjcfKyRgm4wYJJGF1Gwg30hzo ygRrHZ8eXGenCbqOOalZmvvmv9MdmD5rPMkxVw0TO7rNPQPdCWSQwlHKGOAd8FlUeVIC NSx2w88+m0SQsnny9ehZA2OVe/GOV6NmFtOaUF/zgGmZCxIRsM6zw3Cj7DWb2CH4NZLz MAOw== X-Forwarded-Encrypted: i=1; AJvYcCWqRfeQ10qsVEVJI4XV7i2q/0ydSRQWK5pduzmNqKu5XWymA9ETbxp4AG4DzEznFAdmWaiBQ9K7PDj+QP0=@vger.kernel.org X-Gm-Message-State: AOJu0YyJ+AoLapHtf/anTahSy8q5ki36kfS26J165H86ZokX69MqbhoX JNN7k7UVHvMESNZ5b6pZNnT+gGWFYxRTgah8qE3u6/+lpL1tbHwp2iy6W+wMfOFC8MqovIMB7Qm vpZ8NTNHufZlUNno323fS5QQZAxJTijadJB2i6zgkDEir9aY4GTjCNaXkIBGMRg== X-Gm-Gg: ASbGncvQKEx/6uaL0rHSPmNvCPncGYpikFTimQJWWSLP6WFeFzaiNkojj/kD/eYIMdC KU21CNlsgEzvwpAM8z4FBXn2HwQlqdHqeDa3kto8DZAse2iz1yncAbb8xCqmjFnXhm/rkU1R+Gv 6h3V6aG/cPcyOvUHC5RLukdcRBdKtt/pqW1gvIaOQXq+Qfbdz/g6UQDfQveWrEHRODkfDrMAr36 I+rXPo28kGRK2RGwh/8qvwZ0o7zJE+wAOJJ7kgZlDrO3YypnmLyIiAeiQKxB5H35FylfF1BEZNu awUN7wqaP87kyODvJWEFy0Bml32y4nvzqg8exu8= X-Received: by 2002:a05:600c:3ca0:b0:434:ff9d:a3a1 with SMTP id 5b1f17b1804b1-436e266e818mr230026765e9.2.1736893288162; Tue, 14 Jan 2025 14:21:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IHe0Wp/4RFeqjOjh2vP8LZJceetGO5GF0E+p5hagAtJC3YSRHAa5FSpFzR+YUCc581Hjt/+Ug== X-Received: by 2002:a05:600c:3ca0:b0:434:ff9d:a3a1 with SMTP id 5b1f17b1804b1-436e266e818mr230026645e9.2.1736893287809; Tue, 14 Jan 2025 14:21:27 -0800 (PST) Received: from localhost (62-151-111-63.jazzfree.ya.com. [62.151.111.63]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c74ad59fsm1262245e9.16.2025.01.14.14.21.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 14:21:26 -0800 (PST) From: Javier Martinez Canillas To: John Keeping Cc: John Keeping , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] drm/ssd130x: Fix reset timing for ssd132x In-Reply-To: <20250113152752.3369731-2-jkeeping@inmusicbrands.com> References: <20250113152752.3369731-1-jkeeping@inmusicbrands.com> <20250113152752.3369731-2-jkeeping@inmusicbrands.com> Date: Tue, 14 Jan 2025 23:21:25 +0100 Message-ID: <87y0zdvxy2.fsf@minerva.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain John Keeping writes: Hello John, Thanks for your patches! > The ssd132x family of chips require the result pulse to be at least > 100us in length. Increase the reset time to meet this requirement. > That's not what the datasheet says AFAIU. It says the following in the "8.9 Power ON and OFF sequence" section. Power ON sequence: 1. Power ON VDD. 2. After VDD become stable, set RES# pin LOW (logic LOW) for at least 3us (t1) and then HIGH (logic HIGH). 3. After set RES# pin LOW (logic LOW), wait for at least 3us (t2). Then Power ON VCC. 4. After VCC become stable, send command AFh for display ON. SEG/COM will be ON after 100ms (tAF). > Signed-off-by: John Keeping > --- > drivers/gpu/drm/solomon/ssd130x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c > index b777690fd6607..2622172228361 100644 > --- a/drivers/gpu/drm/solomon/ssd130x.c > +++ b/drivers/gpu/drm/solomon/ssd130x.c > @@ -363,7 +363,7 @@ static void ssd130x_reset(struct ssd130x_device *ssd130x) > > /* Reset the screen */ > gpiod_set_value_cansleep(ssd130x->reset, 1); > - udelay(4); > + usleep_range(100, 1000); > gpiod_set_value_cansleep(ssd130x->reset, 0); > udelay(4); That's why I think that the udelay(4) are correct here, since that will make for the delay to be bigger than 3 usecs. Now, is true that the mentioned 100ms (tAF) after sending an AFh command might not happen. Since I see there's no delay after sending a display ON command in ssd130x_encoder_atomic_enable(): static void ssd130x_encoder_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state *state) { .. ssd130x_write_cmd(ssd130x, 1, SSD13XX_DISPLAY_ON); Maybe the solution is to add the here? Also, according to the timers-howto doc [0], the usleep_range() helper should only be used for small msecs (in the 1~20ms range) and msleep() used for larger msecs. [0]: https://www.kernel.org/doc/Documentation/timers/timers-howto.rst -- Best regards, Javier Martinez Canillas Core Platforms Red Hat