From: Viresh Kumar <viresh.kumar@linaro.org> To: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@codeaurora.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, Nishanth Menon <nm@ti.com>, Dmitry Torokhov <dtor@chromium.org>, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] PM / OPP: fix debugfs files for 64-bit Date: Thu, 8 Oct 2015 13:18:28 +0530 [thread overview] Message-ID: <20151008074828.GF4570@linux> (raw) In-Reply-To: <5308760.2G5KJFF9Pi@wuerfel> On 07-10-15, 21:12, Arnd Bergmann wrote: > I think it clearly makes sense to have a fixed length for each of these > members: > > either 32 bit is enough to represent all possible values, then > there is no need to make them 'long' on 64-bit architectures, or 32 bit > is not enough and then the code is broken on 32-bit architectures today > and should be fixed. I agree. But I am not 100% sure why it was done this way to start with. Probably this is the logic behind that: - Max clock rate supported by a u32 is ~ 4.295 GHz - People expected that, we will not reach this rate for 32 bit systems but for 64 bit ones. - If above is true, then making it u64 for all will generate not very optimized code for 32bit systems, as we need to fetch two 32bit values everytime then. - And making it u32 for 64 bit systems wouldn't be great as well, as we need to mask out half of the read value. Ofcourse, Mike and Stephen can correct me here :) > In my patch, I assumed that if 32-bit architectures work fine today, then > we don't need more range on 64-bit architectures either. The problem here is that we haven't fixed it properly. - clock framework expects it to be unsigned long - DT is sending a 64 bit value in Hz - But we are storing and exposing it in u32 That's weird, isn't it? So, either we update clock API and other similar APIs to u64 or u32 (which may not be the right thing to do), Or we keep it unsigned long here as well and add debugfs_create_ulong(). -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] PM / OPP: fix debugfs files for 64-bit Date: Thu, 8 Oct 2015 13:18:28 +0530 [thread overview] Message-ID: <20151008074828.GF4570@linux> (raw) In-Reply-To: <5308760.2G5KJFF9Pi@wuerfel> On 07-10-15, 21:12, Arnd Bergmann wrote: > I think it clearly makes sense to have a fixed length for each of these > members: > > either 32 bit is enough to represent all possible values, then > there is no need to make them 'long' on 64-bit architectures, or 32 bit > is not enough and then the code is broken on 32-bit architectures today > and should be fixed. I agree. But I am not 100% sure why it was done this way to start with. Probably this is the logic behind that: - Max clock rate supported by a u32 is ~ 4.295 GHz - People expected that, we will not reach this rate for 32 bit systems but for 64 bit ones. - If above is true, then making it u64 for all will generate not very optimized code for 32bit systems, as we need to fetch two 32bit values everytime then. - And making it u32 for 64 bit systems wouldn't be great as well, as we need to mask out half of the read value. Ofcourse, Mike and Stephen can correct me here :) > In my patch, I assumed that if 32-bit architectures work fine today, then > we don't need more range on 64-bit architectures either. The problem here is that we haven't fixed it properly. - clock framework expects it to be unsigned long - DT is sending a 64 bit value in Hz - But we are storing and exposing it in u32 That's weird, isn't it? So, either we update clock API and other similar APIs to u64 or u32 (which may not be the right thing to do), Or we keep it unsigned long here as well and add debugfs_create_ulong(). -- viresh
next prev parent reply other threads:[~2015-10-08 7:48 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-07 7:35 [PATCH] PM / OPP: fix debugfs files for 64-bit Arnd Bergmann 2015-10-07 7:35 ` Arnd Bergmann 2015-10-07 10:59 ` Viresh Kumar 2015-10-07 10:59 ` Viresh Kumar 2015-10-07 11:03 ` Viresh Kumar 2015-10-07 11:03 ` Viresh Kumar 2015-10-07 11:07 ` Greg Kroah-Hartman 2015-10-07 11:07 ` Greg Kroah-Hartman 2015-10-07 11:21 ` Viresh Kumar 2015-10-07 11:21 ` Viresh Kumar 2015-10-07 12:57 ` Greg Kroah-Hartman 2015-10-07 12:57 ` Greg Kroah-Hartman 2015-10-07 13:03 ` Viresh Kumar 2015-10-07 13:03 ` Viresh Kumar 2015-10-07 13:03 ` Viresh Kumar 2015-10-07 17:19 ` Greg Kroah-Hartman 2015-10-07 17:19 ` Greg Kroah-Hartman 2015-10-07 17:27 ` Viresh Kumar 2015-10-07 17:27 ` Viresh Kumar 2015-10-07 17:39 ` Greg Kroah-Hartman 2015-10-07 17:39 ` Greg Kroah-Hartman 2015-10-07 18:00 ` Viresh Kumar 2015-10-07 18:00 ` Viresh Kumar 2015-10-07 19:12 ` Arnd Bergmann 2015-10-07 19:12 ` Arnd Bergmann 2015-10-08 7:48 ` Viresh Kumar [this message] 2015-10-08 7:48 ` Viresh Kumar 2015-10-08 14:25 ` Alan Stern 2015-10-08 14:25 ` Alan Stern 2015-10-08 14:25 ` Alan Stern 2015-10-19 15:40 ` Michael Turquette 2015-10-19 15:40 ` Michael Turquette 2015-10-19 15:53 ` Russell King - ARM Linux 2015-10-19 15:53 ` Russell King - ARM Linux 2015-10-20 10:22 ` Michael Turquette 2015-10-20 10:22 ` Michael Turquette 2015-10-07 16:33 ` Russell King - ARM Linux 2015-10-07 16:33 ` Russell King - ARM Linux 2015-10-07 16:36 ` Viresh Kumar 2015-10-07 16:36 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151008074828.GF4570@linux \ --to=viresh.kumar@linaro.org \ --cc=arnd@arndb.de \ --cc=b.zolnierkie@samsung.com \ --cc=dtor@chromium.org \ --cc=gregkh@linuxfoundation.org \ --cc=len.brown@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=nm@ti.com \ --cc=pavel@ucw.cz \ --cc=rjw@rjwysocki.net \ --cc=sboyd@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.