Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp137801pxk; Tue, 15 Sep 2020 23:42:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqPgPkSfZMk76+6BhimRS0DkWquvAA/9n+Pin9Mf4zOHIl3PseSiDgmLEz/2nrxVzWMzL2 X-Received: by 2002:a17:906:95cd:: with SMTP id n13mr23263625ejy.297.1600238544864; Tue, 15 Sep 2020 23:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600238544; cv=none; d=google.com; s=arc-20160816; b=UB9J2VD3X6uYtbAwyp8UrgL4HEy/VBueUFBCQAnphqO25nOM1RKrB/Zux46GOeVvfS 73qDvqPeNxtynXr08RP66oFEe8rEyGSrgZJAbFB/XHJEWa14CAhFzSkoSFrf/OyFly0n +i07Y9GP+8ZNLaX/MaXwvndnnPp9Qq97XusaX/Vr6zFy22r5CtszyRPmCaLxJ1ZMDRpl MhD/d+vZrDXOTMCG4YYSLfNCf5YcJKdBPRY6MUxUPnKJnnYHyNVAGTpn78iCeSxVOeTp fYMQEBPBCEPc5U2ZMGOwDBkhSt8xfDkh5tYFPvQ05JI/FbCtf2AoRb0+EBxjyI/71XxJ sK8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=2fec4FY2qg9cFi4tysK1bqkZPme4Tjyu4Yh8wYL0J2Y=; b=GzQ3b4bRVmxOLzXIX1RzKaUa74FD+EhIPZtlWVRDHn2rqtYgaVRBrc6pbx7WKIB0FY 0IXG/ahMN4sKrUsZQ6D9myPFW/LgobYAPqHo9hCbcmvEjjdnsjkpUq7RZ5XKYQPlx0bn at5vJFzkVLJll3xWg2N4VjgLswgbL5DCWcT0RJlD9TFk3o5Po0o6YJtAMkKMe4/2BM4W 9xyaspBzcJucjV4QVFfBeVOLwxK0WrjhcbF7fYxpDHsMCRXhc5AcMo02Yme+mgWS8Yj7 16q/foodhD2P0GaPzcXkjwNHsTJVblPJzpALjvq5BqBO9L/1SdWHH2q1jmSjvFJpvShI uGtw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Ks4Ey8cf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e14si10968587eds.529.2020.09.15.23.42.02; Tue, 15 Sep 2020 23:42:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Ks4Ey8cf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726285AbgIPGkz (ORCPT + 99 others); Wed, 16 Sep 2020 02:40:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:50508 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726136AbgIPGku (ORCPT ); Wed, 16 Sep 2020 02:40:50 -0400 Received: from coco.lan (ip5f5ad5c9.dynamic.kabel-deutschland.de [95.90.213.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CA69A20708; Wed, 16 Sep 2020 06:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600238448; bh=K5Kj9HgJm7gM+MKCU/+K5/S5g3OT6iP7z0/H3hNi3Do=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ks4Ey8cfFsbf5k8pWgHTca7IKjs+0r0g/7Dd3nMX7aN6UEEoHkKo09czyivdr+M21 EhWyAshF4CqSE46ZQ+U3+BgmFpzHGcoT8Ht3B8zNHR52WD0LsOgVf/VCvlA+XMUDd6 JqA1HcTz6ZYUOMHve7AyKilMjxzTvcb169l7Bi0M= Date: Wed, 16 Sep 2020 08:40:36 +0200 From: Mauro Carvalho Chehab To: "Daniel W. S. Almeida" Cc: geert@linux-m68k.org, r.verdejo@samsung.com, linux-media@vger.kernel.org, nicolas@ndufresne.ca, skhan@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org, linux-kernel@vger.kernel.org, rdunlap@infradead.org Subject: Re: [PATCH] media: vidtv: fix build on 32bit architectures Message-ID: <20200916084036.09e8f3c8@coco.lan> In-Reply-To: <20200915180509.2661572-1-dwlsalmeida@gmail.com> References: <20200915180509.2661572-1-dwlsalmeida@gmail.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Tue, 15 Sep 2020 15:05:09 -0300 "Daniel W. S. Almeida" escreveu: > From: Daniel W. S. Almeida > > Fix the following error for builds on 32bit architectures: > > ERROR: modpost: "__udivdi3" > [drivers/media/test-drivers/vidtv/dvb-vidtv-bridge.ko] undefined! > > Which is due to 64bit divisions that did not go through the helpers > in linux/math64.h > > As vidtv_mux_check_mux_rate was not operational in its current form, > drop the entire function while it is not fixed properly. > > For now, call vidtv_mux_pad_with_nulls with a constant number of packets > to avoid warnings due to unused functions when building this driver. > > Fixes: f90cf6079bf67988 ("media: vidtv: add a bridge driver") > Signed-off-by: Daniel W. S. Almeida > --- > drivers/media/test-drivers/vidtv/vidtv_mux.c | 34 +------------------ > .../media/test-drivers/vidtv/vidtv_s302m.c | 4 +-- > 2 files changed, 3 insertions(+), 35 deletions(-) > > diff --git a/drivers/media/test-drivers/vidtv/vidtv_mux.c b/drivers/media/test-drivers/vidtv/vidtv_mux.c > index 5d1a275d504b..6e402a880fdc 100644 > --- a/drivers/media/test-drivers/vidtv/vidtv_mux.c > +++ b/drivers/media/test-drivers/vidtv/vidtv_mux.c > @@ -336,38 +336,6 @@ static u32 vidtv_mux_pad_with_nulls(struct vidtv_mux *m, u32 npkts) > return nbytes; > } > > -static u32 vidtv_mux_check_mux_rate(struct vidtv_mux *m) > -{ > - /* > - * attempt to maintain a constant mux rate, padding with null packets > - * if needed > - */ > - > - u32 nbytes = 0; /* the number of bytes written by this function */ > - > - u64 nbytes_expected; /* the number of bytes we should have written */ > - u64 nbytes_streamed; /* the number of bytes we actually wrote */ > - u32 num_null_pkts; /* number of null packets to bridge the gap */ > - > - u64 elapsed_time_msecs = jiffies_to_usecs(m->timing.current_jiffies - > - m->timing.past_jiffies); > - > - elapsed_time_msecs = min(elapsed_time_msecs, (u64)VIDTV_MAX_SLEEP_USECS / 1000); > - nbytes_expected = div64_u64(m->mux_rate_kbytes_sec * 1000, MSEC_PER_SEC); > - nbytes_expected *= elapsed_time_msecs; > - > - nbytes_streamed = m->mux_buf_offset; > - > - if (nbytes_streamed < nbytes_expected) { > - /* can't write half a packet: roundup to a 188 multiple */ > - nbytes_expected = roundup(nbytes_expected - nbytes_streamed, TS_PACKET_LEN); > - num_null_pkts = nbytes_expected / TS_PACKET_LEN; > - nbytes += vidtv_mux_pad_with_nulls(m, num_null_pkts); > - } > - > - return nbytes; > -} > - > static void vidtv_mux_clear(struct vidtv_mux *m) > { > /* clear the packets currently in the mux */ > @@ -397,7 +365,7 @@ static void vidtv_mux_tick(struct work_struct *work) > nbytes += vidtv_mux_push_si(m); > > nbytes += vidtv_mux_poll_encoders(m); > - nbytes += vidtv_mux_check_mux_rate(m); > + nbytes += vidtv_mux_pad_with_nulls(m, 256); > > npkts = nbytes / TS_PACKET_LEN; > > diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.c b/drivers/media/test-drivers/vidtv/vidtv_s302m.c > index f8049cdf564a..e3290facf57b 100644 > --- a/drivers/media/test-drivers/vidtv/vidtv_s302m.c > +++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.c > @@ -285,12 +285,12 @@ static void vidtv_s302m_compute_pts(struct vidtv_encoder *e) > { > u64 count = e->sample_count; > struct vidtv_access_unit *au = e->access_units; > + u32 duration = CLOCK_UNIT_90KHZ / e->sampling_rate_hz; > > while (au) { > count += au->num_samples; > > - au->pts = count * > - CLOCK_UNIT_90KHZ / e->sampling_rate_hz; > + au->pts = count * duration; That doesn't seem to be the right thing to do here. Assuming that sampling rate is 48 kHz, you'll have duration = 1.875, which would be rounded to 1. In other words, the above is identical to: au->pts = count Now, I don't know from where that CLOCK_UNIT_90KHZ came from. If such constant is not needed anymore, just drop it. If, on the other hand, this is required by the specs, then you may need to do a 64 bits division, e. g. using div64_u64() or do_div(). Thanks, Mauro