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 DBA9A1E990D for ; Wed, 15 Jan 2025 11:01:28 +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=1736938890; cv=none; b=DuKLO0G3N4Hi7LFiY8rvx5IXk1FPvJni1o5bTiuifjPMRYrpan/RPH84Cf99uv2zqpvrLVG6IbOuqmscAWWVzuSA61AF6mdTjy7nRZlkAypIEw0nfZBzvjHo/W4mG1gq0Vg3P3Qv+9OmsHeEk3hD25TfcLEqAhM+DAeI0RjvQig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736938890; c=relaxed/simple; bh=0tFKwGxinDFaQXPF4NP4iI3ffyDH/jmVWOZ3pYdFH54=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=b/vOT8VKh0KftlKtVAo3Sz+8KqiUmVGaORoNBXWY1VvX8wVMswvW1+tp9scYINFdEZRptNOwJb53xOggrrMPXtEE2EIN+p/SU+fCFjRemDzlQLyHIM+M/NFgn5KrHT/LK5Va9J+2hKibBdyydqJNdNmrOqQzpjC2R2IudiJTs90= 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=D2AfcCtL; 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="D2AfcCtL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736938887; 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=QjzHDq2aERn0VakRka9qUVAea6K8S7N+dOI19uQGdAU=; b=D2AfcCtLHyNqbcsX4qvO0Y/bLw1swPEouM+vo3WowbXOdAf/CMnI3auzHs8ix/cKq1WHyj N01OnY0FmJZWeSZ8TlAYqpkKU7LGsysbWGFrCO7XQVDsDAUrSElY2yS7OxgR/V2h1MX9y6 1rF9zn/8cDZOiITpxl3u2X5wZ9L6U50= 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-643-YSKCAVqkNwWEXu-_pR5Z7A-1; Wed, 15 Jan 2025 06:01:26 -0500 X-MC-Unique: YSKCAVqkNwWEXu-_pR5Z7A-1 X-Mimecast-MFC-AGG-ID: YSKCAVqkNwWEXu-_pR5Z7A Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43631d8d9c7so3558995e9.1 for ; Wed, 15 Jan 2025 03:01:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736938885; x=1737543685; 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=QjzHDq2aERn0VakRka9qUVAea6K8S7N+dOI19uQGdAU=; b=dn5efWm6Gk/jkOkljz6GnQ6fHpOJ+/+Q9v4JatWZTKeLHmmqhw9XMqUwKpE1mj0suC i044JamG6ciyYqYn9nMJDjEIcpx66se+5VvGZVO8733J69aLLAtA4Yiygd+aHOngi0wm UNTLq9gbOr0IIf3EkDetVxltzSNcGqfhDLvL7AlHAAzaGJWsGRpGAesPl3HsoewrfQ3y CL3O7KIL2fytmpV6ja1zpTjx5O8P50RPEQ+sLPPqQIJG1x1xBoeaa/w1M8sqvS6I+JgG 99nKx4lsy1cPwrhwicVv6VUReRZG7jp9zcyaW2bxzCLZJiUnb3X1pA8yW9fJ2klH9YDM Ys/g== X-Forwarded-Encrypted: i=1; AJvYcCVGOKYy6iPFMYXZKavST829n/ZOAezi1ayARQW6vuLFo3QQtQD8hgVpEl8/E4z6DU++FPl8MhWzp/BRgJ8=@vger.kernel.org X-Gm-Message-State: AOJu0YxZUOq1N/MBUwOUwOH+4Ia56PvNb2kcakhCAi3iJS+ppc7ByVBX ZZeOmjkhoHLClQPejtYcHO0o2kUc1X3FOXHn31K3fMKw+XHNI8P+gXr5/bnt0FfGlFsGUzOf1qI UvnzO4e3/kReC4RwAlXLSeTQQMP93PFqaZl070JrR4xr/gCAUkYV6MpA9T7a1cw== X-Gm-Gg: ASbGncvmSIWN8hcMo0TT1kn/GqO2h4zaopqkNFlCbIHkjfF0fmv0whNfx9Z9HcYcZuM UosRXlflf1MrdEvDJHi7hOxX03FLjIj4AdDXq3UIMn3kjNvmAEzPbARiA/B31OGAYoGrMfbZM3m E+OlMEaparm/V3DxeWWRO6glXnjmJ5f98OuDnteDLHAulq16u9Pzg4E7MaTc6QgcAHhW8g9t1zo jB2aD51NGKsW7ixnY9BqsqdMsPlOFrD70RL+HTMUWYJqOLfrcdOdNx7k3VMhKMNfOikzON6VJkm mLMqCz2c+3LhGdWH+EXBxzdhhyuEa/gIznHlSaE= X-Received: by 2002:a05:600c:3481:b0:436:fdac:26eb with SMTP id 5b1f17b1804b1-437c6afdb21mr21000775e9.7.1736938885125; Wed, 15 Jan 2025 03:01:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IH75wZZHjjhCZJ6RruxMhop3f1GE1K2yA06f8GB0EnTjILDJNkGgRn1t2VWah6QKH9lU2Oa2A== X-Received: by 2002:a05:600c:3481:b0:436:fdac:26eb with SMTP id 5b1f17b1804b1-437c6afdb21mr21000475e9.7.1736938884739; Wed, 15 Jan 2025 03:01:24 -0800 (PST) Received: from localhost (62-151-111-63.jazzfree.ya.com. [62.151.111.63]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c74ab449sm19106655e9.10.2025.01.15.03.01.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2025 03:01:23 -0800 (PST) From: Javier Martinez Canillas To: John Keeping Cc: 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: References: <20250113152752.3369731-1-jkeeping@inmusicbrands.com> <20250113152752.3369731-2-jkeeping@inmusicbrands.com> <87y0zdvxy2.fsf@minerva.mail-host-address-is-not-set> Date: Wed, 15 Jan 2025 12:01:22 +0100 Message-ID: <87jzawwdbx.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: > Hi Javier, > > Thanks for the review. > > On Tue, Jan 14, 2025 at 11:21:25PM +0100, Javier Martinez Canillas wrote: >> John Keeping writes: >> 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). > > The version of the datasheet I have for SD1322 says: > > Power ON sequence: > > 1. Power ON VCI, VDDIO. > 2. After VCI, V DDIO become stable, set wait time at least 1ms (t 0) for > internal V DD become stable. Then set RES# pin LOW (logic low) for at > least 100us (t1) (4) and then HIGH (logic high). > 3. After set RES# pin LOW (logic low), wait for at least 100us (t2). > Then Power ON V CC.(1) Oh, that's interesting... I was looking at the datasheet for SSD1327 (the only SSD132x OLED I have). Maybe we could parameterize the delay values and be new members to the struct ssd130x_deviceinfo ? > 4. After VCC become stable, send command AFh for display ON. SEG/COM > will be ON after 200ms (t AF). > > And on the hardware I have 4us seems to be too short. > Yeah, it says 100us in your datasheet while it says 3us in the one I've for the SSD1327. > However, having tested it again today it seems to be fine with the 4us > delay so I suspect this was a misleading change in the midst of other > debugging. > Got it. > I will drop this patch from v2. > Ok. >> > 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(): > > I don't think this matters. It is a delay before the user sees the > image, but that is not relevant to the timing of any commands > Oh right, it's only about the time that the SEG/COM are ON indeed. > > Regards, > John > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat