* Re: Linux next-20190807: arm64: build failed - phy-rockchip-inno-hdmi.c:1046:26: error: anonymous bit-field has negative width (-1)
From: Stephen Rothwell @ 2019-08-08 1:01 UTC (permalink / raw)
To: Naresh Kamboju
Cc: heiko, open list, lkft-triage, kishon, linux-rockchip,
Linux-Next Mailing List, linux-arm-kernel
In-Reply-To: <CA+G9fYvehn=5Rn0RHjFvCc1pCDFTUtxNeR11CQjD6rjM53D4ig@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1770 bytes --]
Hi Naresh,
On Wed, 7 Aug 2019 16:48:15 +0530 Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> Linux next 20190807 arm64 default config build failed due to below error.
>
> /drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:1046:26: error:
> anonymous bit-field has negative width (-1)
> inno_write(inno, 0xc6, RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(v));
> ^
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:201:50: note:
> expanded from macro 'RK3328_TERM_RESISTOR_CALIB_SPEED_7_0'
> #define RK3328_TERM_RESISTOR_CALIB_SPEED_7_0(x) UPDATE(x, 7, 9)
> ^
> ../drivers/phy/rockchip/phy-rockchip-inno-hdmi.c:24:42: note: expanded
> from macro 'UPDATE'
> #define UPDATE(x, h, l) (((x) << (l)) & GENMASK((h), (l)))
> ^
> ../include/linux/bits.h:39:3: note: expanded from macro 'GENMASK'
> (GENMASK_INPUT_CHECK(high, low) + __GENMASK(high, low))
> ^
> ../include/linux/bits.h:24:18: note: expanded from macro 'GENMASK_INPUT_CHECK'
> ((unsigned long)BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> ^
> ../include/linux/build_bug.h:16:47: note: expanded from macro
> 'BUILD_BUG_ON_ZERO'
> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
>
> Config link,
> https://storage.kernelci.org/next/master/next-20190807/arm64/defconfig/clang-8/kernel.config
>
> Build link,
> https://storage.kernelci.org/next/master/next-20190807/arm64/defconfig/clang-8/build.log
I think the patch that caused this has been removed form linux-next for
today (it had other problems as well).
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/4] devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
From: Chanwoo Choi @ 2019-08-08 1:21 UTC (permalink / raw)
To: k.konieczny
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, linux-arm-kernel,
Bartlomiej Zolnierkiewicz, Stephen Boyd, Viresh Kumar, linux-pm,
linux-kernel, Krzysztof Kozlowski, Rob Herring, Kyungmin Park,
Kukjin Kim, MyungJoo Ham, devicetree, Marek Szyprowski
In-Reply-To: <20190807133838.14678-3-k.konieczny@partner.samsung.com>
Hi Kamil,
On 19. 8. 7. 오후 10:38, k.konieczny@partner.samsung.com wrote:
> Reuse opp core code for setting bus clock and voltage. As a side
> effect this allow usage of coupled regulators feature (required
> for boards using Exynos5422/5800 SoCs) because dev_pm_opp_set_rate()
> uses regulator_set_voltage_triplet() for setting regulator voltage
> while the old code used regulator_set_voltage_tol() with fixed
> tolerance. This patch also removes no longer needed parsing of DT
> property "exynos,voltage-tolerance" (no Exynos devfreq DT node uses
> it). After applying changes both functions exynos_bus_passive_target()
> and exynos_bus_target() have the same code, so remove
> exynos_bus_passive_target(). In exynos_bus_probe() replace it with
> exynos_bus_target.
>
> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com>
> ---
> Changes:
> v5:
> - squashed last patch into this one, as suggested by Chanwoo Choi
> v4:
> - remove unrelated changes, add newline before comment
>
> ---
> drivers/devfreq/exynos-bus.c | 130 +++++++----------------------------
> 1 file changed, 24 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index f34fa26f00d0..2aeb6cc07960 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -25,7 +25,6 @@
> #include <linux/slab.h>
>
> #define DEFAULT_SATURATION_RATIO 40
> -#define DEFAULT_VOLTAGE_TOLERANCE 2
>
> struct exynos_bus {
> struct device *dev;
> @@ -37,9 +36,8 @@ struct exynos_bus {
>
> unsigned long curr_freq;
>
> - struct regulator *regulator;
> + struct opp_table *opp_table;
> struct clk *clk;
> - unsigned int voltage_tolerance;
> unsigned int ratio;
> };
>
> @@ -93,62 +91,29 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
> }
>
> /*
> - * Must necessary function for devfreq simple-ondemand governor
> + * devfreq function for both simple-ondemand and passive governor
> */
> static int exynos_bus_target(struct device *dev, unsigned long *freq, u32 flags)
> {
> struct exynos_bus *bus = dev_get_drvdata(dev);
> struct dev_pm_opp *new_opp;
> - unsigned long old_freq, new_freq, new_volt, tol;
> int ret = 0;
>
> - /* Get new opp-bus instance according to new bus clock */
> + /* Get correct frequency for bus. */
> new_opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(new_opp)) {
> dev_err(dev, "failed to get recommended opp instance\n");
> return PTR_ERR(new_opp);
> }
>
> - new_freq = dev_pm_opp_get_freq(new_opp);
> - new_volt = dev_pm_opp_get_voltage(new_opp);
> dev_pm_opp_put(new_opp);
>
> - old_freq = bus->curr_freq;
> -
> - if (old_freq == new_freq)
> - return 0;
> - tol = new_volt * bus->voltage_tolerance / 100;
> -
> /* Change voltage and frequency according to new OPP level */
> mutex_lock(&bus->lock);
> + ret = dev_pm_opp_set_rate(dev, *freq);
> + if (!ret)
> + bus->curr_freq = *freq;
>
> - if (old_freq < new_freq) {
> - ret = regulator_set_voltage_tol(bus->regulator, new_volt, tol);
> - if (ret < 0) {
> - dev_err(bus->dev, "failed to set voltage\n");
> - goto out;
> - }
> - }
> -
> - ret = clk_set_rate(bus->clk, new_freq);
> - if (ret < 0) {
> - dev_err(dev, "failed to change clock of bus\n");
> - clk_set_rate(bus->clk, old_freq);
> - goto out;
> - }
> -
> - if (old_freq > new_freq) {
> - ret = regulator_set_voltage_tol(bus->regulator, new_volt, tol);
> - if (ret < 0) {
> - dev_err(bus->dev, "failed to set voltage\n");
> - goto out;
> - }
> - }
> - bus->curr_freq = new_freq;
> -
> - dev_dbg(dev, "Set the frequency of bus (%luHz -> %luHz, %luHz)\n",
> - old_freq, new_freq, clk_get_rate(bus->clk));
> -out:
> mutex_unlock(&bus->lock);
>
> return ret;
> @@ -196,54 +161,10 @@ static void exynos_bus_exit(struct device *dev)
>
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> - if (bus->regulator)
> - regulator_disable(bus->regulator);
> -}
> -
> -/*
> - * Must necessary function for devfreq passive governor
> - */
> -static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
> - u32 flags)
> -{
> - struct exynos_bus *bus = dev_get_drvdata(dev);
> - struct dev_pm_opp *new_opp;
> - unsigned long old_freq, new_freq;
> - int ret = 0;
> -
> - /* Get new opp-bus instance according to new bus clock */
> - new_opp = devfreq_recommended_opp(dev, freq, flags);
> - if (IS_ERR(new_opp)) {
> - dev_err(dev, "failed to get recommended opp instance\n");
> - return PTR_ERR(new_opp);
> - }
> -
> - new_freq = dev_pm_opp_get_freq(new_opp);
> - dev_pm_opp_put(new_opp);
> -
> - old_freq = bus->curr_freq;
> -
> - if (old_freq == new_freq)
> - return 0;
> -
> - /* Change the frequency according to new OPP level */
> - mutex_lock(&bus->lock);
> -
> - ret = clk_set_rate(bus->clk, new_freq);
> - if (ret < 0) {
> - dev_err(dev, "failed to set the clock of bus\n");
> - goto out;
> + if (bus->opp_table) {
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
> }
> -
> - *freq = new_freq;
> - bus->curr_freq = new_freq;
> -
> - dev_dbg(dev, "Set the frequency of bus (%luHz -> %luHz, %luHz)\n",
> - old_freq, new_freq, clk_get_rate(bus->clk));
> -out:
> - mutex_unlock(&bus->lock);
> -
> - return ret;
> }
>
> static void exynos_bus_passive_exit(struct device *dev)
> @@ -258,21 +179,19 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
> struct exynos_bus *bus)
> {
> struct device *dev = bus->dev;
> + struct opp_table *opp_table;
> + const char *vdd = "vdd";
> int i, ret, count, size;
>
> - /* Get the regulator to provide each bus with the power */
> - bus->regulator = devm_regulator_get(dev, "vdd");
> - if (IS_ERR(bus->regulator)) {
> - dev_err(dev, "failed to get VDD regulator\n");
> - return PTR_ERR(bus->regulator);
> - }
> -
> - ret = regulator_enable(bus->regulator);
> - if (ret < 0) {
> - dev_err(dev, "failed to enable VDD regulator\n");
> + opp_table = dev_pm_opp_set_regulators(dev, &vdd, 1);
> + if (IS_ERR(opp_table)) {
> + ret = PTR_ERR(opp_table);
> + dev_err(dev, "failed to set regulators %d\n", ret);
> return ret;
> }
>
> + bus->opp_table = opp_table;
> +
> /*
> * Get the devfreq-event devices to get the current utilization of
> * buses. This raw data will be used in devfreq ondemand governor.
> @@ -313,14 +232,11 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
> if (of_property_read_u32(np, "exynos,saturation-ratio", &bus->ratio))
> bus->ratio = DEFAULT_SATURATION_RATIO;
>
> - if (of_property_read_u32(np, "exynos,voltage-tolerance",
> - &bus->voltage_tolerance))
> - bus->voltage_tolerance = DEFAULT_VOLTAGE_TOLERANCE;
> -
> return 0;
>
> err_regulator:
> - regulator_disable(bus->regulator);
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
>
> return ret;
> }
> @@ -471,7 +387,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
> goto out;
> passive:
> /* Initialize the struct profile and governor data for passive device */
> - profile->target = exynos_bus_passive_target;
> + profile->target = exynos_bus_target;
> profile->exit = exynos_bus_passive_exit;
>
> /* Get the instance of parent devfreq device */
> @@ -511,8 +427,10 @@ static int exynos_bus_probe(struct platform_device *pdev)
> dev_pm_opp_of_remove_table(dev);
> clk_disable_unprepare(bus->clk);
> err_reg:
> - if (!passive)
> - regulator_disable(bus->regulator);
> + if (!passive) {
> + dev_pm_opp_put_regulators(bus->opp_table);
> + bus->opp_table = NULL;
> + }
>
> return ret;
> }
>
It looks good to me.
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] add coupled regulators for Exynos5422/5800
From: Chanwoo Choi @ 2019-08-08 1:47 UTC (permalink / raw)
To: k.konieczny
Cc: Mark Rutland, Nishanth Menon, linux-samsung-soc, linux-arm-kernel,
Bartlomiej Zolnierkiewicz, Stephen Boyd, Viresh Kumar, linux-pm,
linux-kernel, Krzysztof Kozlowski, Rob Herring, Kyungmin Park,
Kukjin Kim, MyungJoo Ham, devicetree, Marek Szyprowski
In-Reply-To: <20190807133838.14678-1-k.konieczny@partner.samsung.com>
Hi Kamil,
When I applied them to testing branch, those don't have the author name
only just have the email address as following:
You have to edit the your git author information with your name.
author k.konieczny@partner.samsung.com <k.konieczny@partner.samsung.com> 2019-08-07 15:38:36 +0200
committer Chanwoo Choi <cw00.choi@samsung.com> 2019-08-08 10:35:16 +0900
commit 4304f4ecec93cebd255463d56b0a4f112ee9dc50 (patch)
tree 2859e566d6f68219f71a61e7c412717c1adba4f5
parent 57d85421038b458dd87ec268404ff608f90c36ae (diff)
download linux-4304f4ecec93cebd255463d56b0a4f112ee9dc50.tar.gz
Regards,
Chanwoo Choi
On 19. 8. 7. 오후 10:38, k.konieczny@partner.samsung.com wrote:
> Hi,
>
> The main purpose of this patch series is to add coupled regulators for
> Exynos5422/5800 to keep constrain on voltage difference between vdd_arm
> and vdd_int to be at most 300mV. In exynos-bus instead of using
> regulator_set_voltage_tol() with default voltage tolerance it should be
> used regulator_set_voltage_triplet() with volatege range, and this is
> already present in opp/core.c code, so it can be reused. While at this,
> move setting regulators into opp/core.
>
> This patchset was tested on Odroid XU3.
>
> The DTS coupled regulators patch depends on previous patches.
>
> Changes:
> v5:
> - squashed last patch "remove exynos_bus_passive_target()" into second
> - added Acked-by to patch "correct clock enable sequence"
> v4:
> - removed "opp: core: add regulators enable and disable" from patchset
> as it was applied by Viresh Kumar and changed cover letter
> - fix patch "devfreq: exynos-bus: correct clock enable sequence" to
> correct order of enable/disable
> - removed unrelated changes in "devfreq: exynos-bus: convert to use
> dev_pm_opp_set_rate()"
> - added new patch "devfreq: exynos-bus: remove exynos_bus_passive_target()"
> as suggested by Chanwoo Choi
> v3:
> - added new exynos-bus patch to correct clock and regulator enabling
> and disabling sequence as suggested by Chanwoo Choi
> - corrected error path in enable and improved commit message in opp/core
> - improve comment in devfreq/exynos-bus.c before devfreq_recommended_opp()
> - change cover letter as there is new patch
> - added note before Signed-off-by in 4th patch
> v2:
> - improve regulators enable/disable code in opp/core as suggested by
> Viresh Kumar
> - add new patch for remove unused dt-bindings as suggested by Krzysztof
> Kozlowski
>
> Kamil Konieczny (3):
> devfreq: exynos-bus: correct clock enable sequence
> devfreq: exynos-bus: convert to use dev_pm_opp_set_rate()
> dt-bindings: devfreq: exynos-bus: remove unused property
>
> Marek Szyprowski (1):
> ARM: dts: exynos: add initial data for coupled regulators for
> Exynos5422/5800
>
> .../bindings/devfreq/exynos-bus.txt | 2 -
> arch/arm/boot/dts/exynos5420.dtsi | 34 ++--
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 +
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +
> arch/arm/boot/dts/exynos5800.dtsi | 32 ++--
> drivers/devfreq/exynos-bus.c | 153 +++++-------------
> 6 files changed, 78 insertions(+), 151 deletions(-)
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Ira Weiny @ 2019-08-08 2:36 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, amd-gfx, sparclinux, Dan Williams, devel, rds-devel,
linux-rdma, x86, Matthew Wilcox, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, John Hubbard,
intel-gfx, john.hubbard, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190807084649.GQ11812@dhcp22.suse.cz>
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> > On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > > > > > On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
> > > > > > > [...]
> > > > > > > > 2) Convert all of the call sites for get_user_pages*(), to
> > > > > > > > invoke put_user_page*(), instead of put_page(). This involves dozens of
> > > > > > > > call sites, and will take some time.
> > > > > > >
> > > > > > > How do we make sure this is the case and it will remain the case in the
> > > > > > > future? There must be some automagic to enforce/check that. It is simply
> > > > > > > not manageable to do it every now and then because then 3) will simply
> > > > > > > be never safe.
> > > > > > >
> > > > > > > Have you considered coccinele or some other scripted way to do the
> > > > > > > transition? I have no idea how to deal with future changes that would
> > > > > > > break the balance though.
> > >
> > > Hi Michal,
> > >
> > > Yes, I've thought about it, and coccinelle falls a bit short (it's not smart
> > > enough to know which put_page()'s to convert). However, there is a debug
> > > option planned: a yet-to-be-posted commit [1] uses struct page extensions
> > > (obviously protected by CONFIG_DEBUG_GET_USER_PAGES_REFERENCES) to add
> > > a redundant counter. That allows:
> > >
> > > void __put_page(struct page *page)
> > > {
> > > ...
> > > /* Someone called put_page() instead of put_user_page() */
> > > WARN_ON_ONCE(atomic_read(&page_ext->pin_count) > 0);
> > >
> > > > > >
> > > > > > Yeah, that's why I've been suggesting at LSF/MM that we may need to create
> > > > > > a gup wrapper - say vaddr_pin_pages() - and track which sites dropping
> > > > > > references got converted by using this wrapper instead of gup. The
> > > > > > counterpart would then be more logically named as unpin_page() or whatever
> > > > > > instead of put_user_page(). Sure this is not completely foolproof (you can
> > > > > > create new callsite using vaddr_pin_pages() and then just drop refs using
> > > > > > put_page()) but I suppose it would be a high enough barrier for missed
> > > > > > conversions... Thoughts?
> > >
> > > The debug option above is still a bit simplistic in its implementation
> > > (and maybe not taking full advantage of the data it has), but I think
> > > it's preferable, because it monitors the "core" and WARNs.
> > >
> > > Instead of the wrapper, I'm thinking: documentation and the passage of
> > > time, plus the debug option (perhaps enhanced--probably once I post it
> > > someone will notice opportunities), yes?
> >
> > So I think your debug option and my suggested renaming serve a bit
> > different purposes (and thus both make sense). If you do the renaming, you
> > can just grep to see unconverted sites. Also when someone merges new GUP
> > user (unaware of the new rules) while you switch GUP to use pins instead of
> > ordinary references, you'll get compilation error in case of renaming
> > instead of hard to debug refcount leak without the renaming. And such
> > conflict is almost bound to happen given the size of GUP patch set... Also
> > the renaming serves against the "coding inertia" - i.e., GUP is around for
> > ages so people just use it without checking any documentation or comments.
> > After switching how GUP works, what used to be correct isn't anymore so
> > renaming the function serves as a warning that something has really
> > changed.
>
> Fully agreed!
Ok Prior to this I've been basing all my work for the RDMA/FS DAX stuff in
Johns put_user_pages()... (Including when I proposed failing truncate with a
lease in June [1])
However, based on the suggestions in that thread it became clear that a new
interface was going to need to be added to pass in the "RDMA file" information
to GUP to associate file pins with the correct processes...
I have many drawings on my white board with "a whole lot of lines" on them to
make sure that if a process opens a file, mmaps it, pins it with RDMA, _closes_
it, and ummaps it; that the resulting file pin can still be traced back to the
RDMA context and all the processes which may have access to it.... No matter
where the original context may have come from. I believe I have accomplished
that.
Before I go on, I would like to say that the "imbalance" of get_user_pages()
and put_page() bothers me from a purist standpoint... However, since this
discussion cropped up I went ahead and ported my work to Linus' current master
(5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
John... :-(
I don't have the commit messages all cleaned up and I know there may be some
discussion on these new interfaces but I wanted to throw this series out there
because I think it may be what Jan and Michal are driving at (or at least in
that direction.
Right now only RDMA and DAX FS's are supported. Other users of GUP will still
fail on a DAX file and regular files will still be at risk.[2]
I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
I think the most relevant patch to this conversation is:
https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
I stole Jans suggestion for a name as the name I used while prototyping was
pretty bad... So Thanks Jan... ;-)
Also thanks to John for his contribution on some of this. I'm still tweaking
put_user_pages under the hood on the DAX path.
Ira
[1] https://lwn.net/Articles/790544/
[2] I've been looking into how to support io_uring next but I've had some issue
getting a test program to actually call GUP in that code path... :-(
[3] If it would be easier I can just throw an RFC on the list but right now the
cover letter and some of the commit messages are full of the old stuff and
various ideas I have had...
>
> > Your refcount debug patches are good to catch bugs in the conversions done
> > but that requires you to be able to excercise the code path in the first
> > place which may require particular HW or so, and you also have to enable
> > the debug option which means you already aim at verifying the GUP
> > references are treated properly.
> >
> > Honza
> >
> > --
> > Jan Kara <jack@suse.com>
> > SUSE Labs, CR
>
> --
> Michal Hocko
> SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: ep93xx: Mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-08-08 2:38 UTC (permalink / raw)
To: Hartley Sweeten, Alexander Sverdlin, Russell King
Cc: linux-kernel, linux-arm-kernel, Gustavo A. R. Silva
Mark switch cases where we are expecting to fall through.
Fix the following warnings (Building: arm-ep93xx_defconfig arm):
arch/arm/mach-ep93xx/crunch.c: In function 'crunch_do':
arch/arm/mach-ep93xx/crunch.c:46:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
memset(crunch_state, 0, sizeof(*crunch_state));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-ep93xx/crunch.c:53:2: note: here
case THREAD_NOTIFY_EXIT:
^~~~
Notice that, in this particular case, the code comment is
modified in accordance with what GCC is expecting to find.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
arch/arm/mach-ep93xx/crunch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-ep93xx/crunch.c b/arch/arm/mach-ep93xx/crunch.c
index 1c9a4be8b503..1c05c5bf7e5c 100644
--- a/arch/arm/mach-ep93xx/crunch.c
+++ b/arch/arm/mach-ep93xx/crunch.c
@@ -49,6 +49,7 @@ static int crunch_do(struct notifier_block *self, unsigned long cmd, void *t)
* FALLTHROUGH: Ensure we don't try to overwrite our newly
* initialised state information on the first fault.
*/
+ /* Fall through */
case THREAD_NOTIFY_EXIT:
crunch_task_release(thread);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Kevin Hilman @ 2019-08-08 2:59 UTC (permalink / raw)
To: Martin Blumenstingl, guillaume La Roque
Cc: devicetree, linux-pm, daniel.lezcano, linux-kernel, linux-amlogic,
linux-arm-kernel
In-Reply-To: <CAFBinCB3ZBPVEJKV2Rfh_w-zWrhoToYdoYE6Wox+JeB-YH+Khw@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> Hi Guillaume,
>
> On Mon, Aug 5, 2019 at 2:48 PM guillaume La Roque <glaroque@baylibre.com> wrote:
>>
>> Hi Martin,
>>
>> again thanks for your review.
> you're welcome - thank you for working on the driver :-)
>
> [...]
>> > The IP block has more functionality, which may be added to this driver
>> > in the future:
>> > - reading up to 16 stored temperature samples
>>
>> it's not working, you can verify it if you check the regmap define in the driver. in fact temp is only write in one register, it's confirmed by amlogic.
> I missed that - so please skip this part
>
> [...]
>> >> +config AMLOGIC_THERMAL
>> > we typically use "MESON" in the Kconfig symbols:
>> > $ grep -c AMLOGIC .config
>> > 1
>> > $ grep -c MESON .config
>> > 33
>> >
>> > I also wonder if we should add G12 or G12A so we don't conflict with
>> > upcoming thermal sensors with a different design (assuming that this
>> > will be a thing).
>> > for example we already have three different USB2 PHY drivers
>> >
>> > [...]
>>
>> i check with Neil and for new family it's better to use Amlogic instead of meson.
> can you please share the considerations behind this decision?
> if new drivers should use AMLOGIC_* Kconfig symbols instead of MESON_*
> then we all should know about it
>
>> i don't add G12 because we already know it's same sensors for SM1 SoC family [0].
> my idea behind this was to avoid conflicts in the future
> in case of the thermal driver we may be fine with using a generic name
> assuming that Amlogic will not switch to a new IP block in the next
> years
> I'm not saying you have to change the name - I'm bringing this up so
> you can decide for yourself based on examples from the past
>
> here are a few examples:
> - when Kevin upstreamed the MMC driver for GX he decided to use
> MMC_MESON_GX for the Kconfig symbol name. it turns out that this is
> smart because there are at least two other MMC controller IPs on the
> 32-bit SoCs. due to him including GX in the name the drivers are easy
> to differentiate (MMC_MESON_MX_SDIO and MMC_MESON_MX_SDHC being the
> other ones, while the latter is not upstream yet)
> - when Carlo upstreamed the eFuse driver he decided to use MESON_EFUSE
> for the Kconfig symbol name. I found out much later that the 32-bit
> SoCs use a different IP (or at least direct register access instead of
> going through Secure Monitor). the driver for the 32-bit SoCs now uses
> MESON_MX_EFUSE. if you don't know which driver applies where then it's
> easy to mix up MESON_EFUSE and MESON_MX_EFUSE
> - when Jerome upstreamed the ALSA driver for AXG (which is also used
> on G12A and G12B) he decided to use the SND_MESON_AXG_* prefix for the
> Kconfig symbol names. in my opinion this was a good choice because GXM
> and everything earlier (including the 32-bit SoCs) use a different
> audio IP block. we won't have a Kconfig symbol name clash when a
> driver for the "older" SoCs is upstreamed
> - (there are more examples, Meson8b USB PHY driver, Meson8b DWMAC
> glue, ... - just like there's many examples where the IP block is
> mostly compatible with older generations: SAR ADC, RNG, SPI, ...)
While these are all good examples, you can see it can go both ways, so
there's really no way know up front what is the "right" way. We only
know after the fact. Unfortunately, we simply have no visibility into
future chips and where IP blocks may be shared or not (there are other
examples where vendors add a new version of an IP *and* keep the old
version. ;)
Even having worked inside a (different) SoC vendor and having some
knowledge about what IPs are shared, it's difficult to get this right.
> I'm not sure what driver naming rules other mainline SoC teams use
> to me it seems that the rule for Allwinner driver names is to use the
> "code-name of the first SoC the IP block appeared in"
That's a good rule of thumb (and one we generally follow) but I don't
feel it's important enough to enforce strictly either.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: arm: amlogic: add bindings for G12B based S922X SoC
From: Kevin Hilman @ 2019-08-08 3:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Neil Armstrong, Christian Hewitt,
linux-kernel@vger.kernel.org, linux-amlogic,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqL_L2qHe334sB57hR_coRhawKiqXYjKAQDJt_DHfBamBQ@mail.gmail.com>
Rob Herring <robh@kernel.org> writes:
> On Mon, Aug 5, 2019 at 3:46 PM Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>> > Add a specific compatible for the Amlogic G12B family based S922X SoC
>> > to differentiate with the A311D SoC from the same family.
>> >
>> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> > ---
>> > Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> > index 325c6fd3566d..3c3bc806cd23 100644
>> > --- a/Documentation/devicetree/bindings/arm/amlogic.yaml
>> > +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
>> > @@ -139,6 +139,7 @@ properties:
>> > items:
>> > - enum:
>> > - hardkernel,odroid-n2
>> > + - const: amlogic,s922x
>> > - const: amlogic,g12b
>>
>> nit: in previous binding docs, we were trying to keep these sorted
>> alphabetically. I'll reorder the new "s922x" after "g12b" when
>> applying.
>
> No, this is not documentation ordering. It's the order compatible
> strings must be in.
Ah, thanks for clarifying,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: fsl: add support for Hummingboard Pulse
From: Fabio Estevam @ 2019-08-08 3:17 UTC (permalink / raw)
To: Baruch Siach
Cc: Sascha Hauer, Jon Nettleton, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <8dec8f80b1269df040251a14b671f9c834c121cd.1565188354.git.baruch@tkos.co.il>
Hi Baruch and Jon,
On Wed, Aug 7, 2019 at 11:32 AM Baruch Siach <baruch@tkos.co.il> wrote:
>
> From: Jon Nettleton <jon@solid-run.com>
>
> The SolidRun Hummingboard Pulse carrier board carries the SolidRun
> i.MX8MQ based SOM.
>
> Notably missing is PCIe support that depends on analog PLLOUT clock.
> Current imx clk driver does not support this clock.
>
> Signed-off-by: Jon Nettleton <jon@solid-run.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../freescale/imx8mq-hummingboard-pulse.dts | 237 ++++++++++++++
> .../boot/dts/freescale/imx8mq-sr-som.dtsi | 309 ++++++++++++++++++
Please add an entry for this board in
Documentation/devicetree/bindings/arm/fsl.yaml
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
No need for this "regulators {" node. You can just place
reg_usdhc2_vmmc directly outside of it.
> +
> + reg_usdhc2_vmmc: usdhc2_vmmc {
Convention is reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +&iomuxc {
We usually put the iomuxc node as the last one.
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog>;
> +
> + imx8mq-sr-hb {
No need for this imx8mq-sr-hb {
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + /* MikroBus Analog */
> + MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x41
> + /* MikroBus Reset */
> + MX8MQ_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x41
> + /* The following 2 pins need to be commented out and
> + * reconfigured to enable RTS/CTS on UART3
> + */
Incorrect multi-lines comment style.
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
> + MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
> + /* These pins are currently allocated to the
> + * uBLOX module on the SOM
> + */
Same here.
> + /* MX8MQ_IOMUXC_UART4_RXD_UART2_DCE_CTS_B 0x49 */
> + /* MX8MQ_IOMUXC_UART4_TXD_UART2_DCE_RTS_B 0x49 */
Just remove it?
> + >;
> + };
> +
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
> + MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
> + /* These pins are by default GPIO on the Mikro Bus
> + * Header. To use RTS/CTS on UART3 comment them out
> + * of the hoggrp and enable them here
Same comment about multi-line style.
> + fsl,pins = <
> + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
> + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
> + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
> + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
> + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
> + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
> + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
> + >;
> + };
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + typec_ptn5100: ptn5110@50 {
> + compatible = "usb,tcpci";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_typec>;
> + reg = <0x50>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <6 8>;
> + ss-sel-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
> + src-pdos = <0x380190c8>;
This property and others do not exist in mainline
Please see Documentation/devicetree/bindings/usb/typec-tcpci.txt and
arch/arm64/boot/dts/freescale/imx8mm-evk.dts for a reference.
> +&uart3 { /* Mikrobus */
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
> + assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
> + fsl,uart-has-rtscts;
Please use 'uart-has-rtscts' instead.
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fec1>;
> + phy-mode = "rgmii-id";
> + phy-handle = <ðphy0>;
> + phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
> + phy-reset-duration = <2>;
> + fsl,magic-packet;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <4>;
@0 does not match the reg property. Please fix it.
Also, make sure to build it with W=1 and do not introduce new warnings.
> + };
> + };
> +};
> +
> +&iomuxc {
> + microsom {
No need for this node.
> +&i2c1 {
> + clock-frequency = <400000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +
> + pmic: pfuze100@8 {
Node names should be generic: pmic@8
> +&qspi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_qspi>;
> + status = "okay";
> +
> + /* SPI flash; not assembled by default */
> + n25q256a@0 {
flash@0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/cache: silence -Woverride-init warnings
From: Qian Cai @ 2019-08-08 3:29 UTC (permalink / raw)
To: will, catalin.marinas
Cc: mark.rutland, clang-built-linux, Qian Cai, linux-kernel,
linux-arm-kernel
The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
VIVT I-caches") introduced some compiation warnings from GCC (and
Clang) with -Winitializer-overrides),
arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_VIPT] = "VIPT",
^~~~~~
arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
'icache_policy_str[2]')
arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_PIPT] = "PIPT",
^~~~~~
arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
'icache_policy_str[3]')
arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_VPIPT] = "VPIPT",
^~~~~~~
arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
'icache_policy_str[0]')
because it initializes icache_policy_str[0 ... 3] twice. Since
arm64 developers are keen to keep the style of initializing a static
array with a non-zero pattern first, just disable those warnings for
both GCC and Clang of this file.
Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/arm64/kernel/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 478491f07b4f..397ed5f7be1e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -11,6 +11,9 @@ CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
+CFLAGS_cpuinfo.o += $(call cc-disable-warning, override-init)
+CFLAGS_cpuinfo.o += $(call cc-disable-warning, initializer-overrides)
+
# Object file lists.
obj-y := debug-monitors.o entry.o irq.o fpsimd.o \
entry-fpsimd.o process.o ptrace.o setup.o signal.o \
--
2.20.1 (Apple Git-117)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 0/2] Remove smbus quick cmd and update adapter name
From: Rayagonda Kokatanur @ 2019-08-08 3:37 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Florian Fainelli, Rayagonda Kokatanur, linux-kernel,
Ray Jui, linux-i2c, bcm-kernel-feedback-list, linux-arm-kernel
Hi,
This patchset contains following changes:
- Remove SMBUS quick command support
- Update full name of dt node to adapter name
Lori Hikichi (2):
i2c: iproc: Stop advertising support of SMBUS quick cmd
i2c: iproc: Add full name of devicetree node to adapter name
drivers/i2c/busses/i2c-bcm-iproc.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/2] i2c: iproc: Stop advertising support of SMBUS quick cmd
From: Rayagonda Kokatanur @ 2019-08-08 3:37 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Rayagonda Kokatanur,
linux-kernel, Ray Jui, linux-i2c, bcm-kernel-feedback-list,
linux-arm-kernel
In-Reply-To: <1565235473-28461-1-git-send-email-rayagonda.kokatanur@broadcom.com>
From: Lori Hikichi <lori.hikichi@broadcom.com>
The driver does not support the SMBUS Quick command so remove the
flag that indicates that level of support.
By default the i2c_detect tool uses the quick command to try and
detect devices at some bus addresses. If the quick command is used
then we will not detect the device, even though it is present.
Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver)
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..19ef2b0 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -790,7 +790,10 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
{
- u32 val = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+ u32 val;
+
+ /* We do not support the SMBUS Quick command */
+ val = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
if (adap->algo->reg_slave)
val |= I2C_FUNC_SLAVE;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
From: Guenter Roeck @ 2019-08-08 3:42 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Neil Armstrong, David Airlie, dri-devel, linux-kernel,
Matthias Brugger, Thierry Reding, Laurent Pinchart, Shawn Guo,
kernel, Sam Ravnborg, linux-samsung-soc, Sean Paul,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip,
Chen-Yu Tsai, Kukjin Kim, NXP Linux Team, Dave Airlie,
Thomas Zimmermann, Jonas Karlman, linux-arm-msm, intel-gfx,
Jyri Sarha, Mamta Shukla, linux-mediatek, Maxime Ripard,
Rodrigo Vivi, linux-tegra, Thomas Gleixner, Vincent Abriou,
linux-arm-kernel, Jernej Skrabec, amd-gfx, Tomi Valkeinen,
Enrico Weigelt, Seung-Woo Kim, Douglas Anderson, Todor Tomov,
Kyungmin Park, Huang Rui, Pengutronix Kernel Team,
Greg Kroah-Hartman, Alex Deucher, freedreno, Christian König,
Gerd Hoffmann
In-Reply-To: <ebb75e71b8b7c8d65d54a947a03fd21b8969fb3a.1564161140.git.andrzej.p@collabora.com>
On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
This patch results in a crash when running qemu:versatilepb.
Unable to handle kernel NULL pointer dereference at virtual address 000000c5
pgd = (ptrval)
[000000c5] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc1+ #1
Hardware name: ARM-Versatile (Device Tree Support)
PC is at sysfs_do_create_link_sd+0x38/0xd8
LR is at sysfs_do_create_link_sd+0x38/0xd8
pc : [<c01ac94c>] lr : [<c01ac94c>] psr: a0000153
sp : c783bd18 ip : 00000000 fp : c783bde8
r10: c7ef5ea8 r9 : 00000001 r8 : c0955dc0
r7 : c73cb5b0 r6 : c73cd800 r5 : 000000ad r4 : 00000000
r3 : c7838ae0 r2 : 00000000 r1 : 00000008 r0 : c0aa2898
Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
Control: 00093177 Table: 00004000 DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))
Stack: (0xc783bd18 to 0xc783c000)
bd00: c73ccc48 c73ccc74
bd20: c73cd800 c0ac7c88 00000000 c729cc80 c7ef5ea8 c04c7fc0 c73ccc48 c0a73068
bd40: c73cd800 c0ac7c88 00000000 c04c87e0 00000001 00000000 c04cefcc c04dc3f8
bd60: c73a9030 c73cd800 c73ccc48 7fc2ce37 00000000 c73cd800 00000000 c04cefcc
bd80: c73cd800 00000000 00000000 c04b4ebc c0a73068 c7ef5ea8 c783bde8 c049ffcc
bda0: c73a9020 c73cd800 c78e6000 c73a9020 00000000 c73a9020 c0a73068 c04df2f8
bdc0: c783bde8 c095a76c c73a9020 c0065744 c73ccc20 c73a9020 00000000 00000001
bde0: c7838ae0 00000000 c73ccc20 7fc2ce37 00000000 c78e6000 00000000 c0ac7c34
be00: c07dc1f8 00000000 00000000 c0a6b384 c0a59858 c045e8d8 c78e6000 c1173a78
be20: 00000000 c0ac7c34 00000000 c04e77c4 c78e6000 c0ac7c34 c0ac7c34 c0a73068
be40: 00000000 ffffe000 c0a6b384 c04e7a34 c0ac7c34 c0ac7c34 c0a73068 c78e6000
be60: 00000000 c0ac7c34 c0a73068 00000000 ffffe000 c0a6b384 c0a59858 c04e7cf0
be80: 00000000 c0ac7c34 c78e6000 c04e7d7c 00000000 c0ac7c34 c04e7cf8 c04e5928
bea0: c73b2800 c78d88a0 c78dd110 7fc2ce37 ffffe000 c0ac7c34 c73b2800 c0ac16e0
bec0: 00000000 c04e6b28 c095a73c c0af0a60 c0a73068 c0ac7c34 c0af0a60 c0a73068
bee0: c0a401c4 c04e8968 ffffe000 c0af0a60 c0a73068 c000b3bc 00000115 00000000
bf00: c7ffce6c c7ffce00 c09e15b0 00000115 00000115 c0048844 c09e000c c097cfd4
bf20: 00000000 00000006 00000006 00000000 00000000 c7ffce6c ffffe000 c006954c
bf40: ffffe000 7fc2ce37 c0afb000 c0af0a60 00000115 c0afb000 00000007 c0a59850
bf60: ffffe000 c0a111e8 00000006 00000006 00000000 c0a10678 00000000 7fc2ce37
bf80: 00000000 00000000 c07824cc 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c07824d4 00000000 c00090b0 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c01ac94c>] (sysfs_do_create_link_sd) from [<c04c7fc0>] (drm_connector_register.part.1+0x40/0xa0)
[<c04c7fc0>] (drm_connector_register.part.1) from [<c04c87e0>] (drm_connector_register_all+0x90/0xb8)
[<c04c87e0>] (drm_connector_register_all) from [<c04cefcc>] (drm_modeset_register_all+0x44/0x6c)
[<c04cefcc>] (drm_modeset_register_all) from [<c04b4ebc>] (drm_dev_register+0x15c/0x1c0)
[<c04b4ebc>] (drm_dev_register) from [<c04df2f8>] (pl111_amba_probe+0x2e0/0x4ac)
[<c04df2f8>] (pl111_amba_probe) from [<c045e8d8>] (amba_probe+0x9c/0x118)
[<c045e8d8>] (amba_probe) from [<c04e77c4>] (really_probe+0x1c0/0x2bc)
[<c04e77c4>] (really_probe) from [<c04e7a34>] (driver_probe_device+0x5c/0x170)
[<c04e7a34>] (driver_probe_device) from [<c04e7cf0>] (device_driver_attach+0x58/0x60)
[<c04e7cf0>] (device_driver_attach) from [<c04e7d7c>] (__driver_attach+0x84/0xc0)
[<c04e7d7c>] (__driver_attach) from [<c04e5928>] (bus_for_each_dev+0x70/0xb4)
[<c04e5928>] (bus_for_each_dev) from [<c04e6b28>] (bus_add_driver+0x154/0x1e0)
[<c04e6b28>] (bus_add_driver) from [<c04e8968>] (driver_register+0x74/0x108)
[<c04e8968>] (driver_register) from [<c000b3bc>] (do_one_initcall+0x84/0x2e4)
[<c000b3bc>] (do_one_initcall) from [<c0a111e8>] (kernel_init_freeable+0x2bc/0x394)
[<c0a111e8>] (kernel_init_freeable) from [<c07824d4>] (kernel_init+0x8/0xf0)
[<c07824d4>] (kernel_init) from [<c00090b0>] (ret_from_fork+0x14/0x24)
Exception stack(0xc783bfb0 to 0xc783bff8)
bfa0: 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018)
---[ end trace f503b374936886c5 ]---
Bisect log attached.
Guenter
---
# bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files for 20190807
# good: [e21a712a9685488f5ce80495b37b9fdbe96c230d] Linux 5.3-rc3
git bisect start 'HEAD' 'v5.3-rc3'
# good: [83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa] Merge remote-tracking branch 'crypto/master'
git bisect good 83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa
# bad: [3add021bff629f1792a5e4268afe13b3047b5523] Merge remote-tracking branch 'sound/for-next'
git bisect bad 3add021bff629f1792a5e4268afe13b3047b5523
# good: [4ef58ee18a654b1992d00281501d6eff051a0c5e] Merge remote-tracking branch 'amdgpu/drm-next'
git bisect good 4ef58ee18a654b1992d00281501d6eff051a0c5e
# good: [f729d8d9628d4093675abfd62d8d3a06d3d11732] drm/tinydrm: Move tinydrm_machine_little_endian()
git bisect good f729d8d9628d4093675abfd62d8d3a06d3d11732
# bad: [178e5f3a5bc1d67d1248a74c0abab41040abe7c4] drm/crc-debugfs: Add notes about CRC<->commit interactions
git bisect bad 178e5f3a5bc1d67d1248a74c0abab41040abe7c4
# good: [0486ad20e73d03c82208b802ac41e80b942b23f6] drm/rockchip: Make analogix_dp_atomic_check static
git bisect good 0486ad20e73d03c82208b802ac41e80b942b23f6
# bad: [92cb3e5980638a37c56091e605aa837d0af05a9d] dma-buf: fix stack corruption in dma_fence_chain_release
git bisect bad 92cb3e5980638a37c56091e605aa837d0af05a9d
# good: [350fd554ee44325661d0d3c3831f428f4fbb0f2d] drm/ast: Provide ddc symlink in connector sysfs directory
git bisect good 350fd554ee44325661d0d3c3831f428f4fbb0f2d
# bad: [28ba1b1da49a20ba8fb767d6ddd7c521ec79a119] drm: mali-dp: Mark expected switch fall-through
git bisect bad 28ba1b1da49a20ba8fb767d6ddd7c521ec79a119
# bad: [5b50fa2b35a4ddad11cb3d06231bf71759b49566] drm/amdgpu: Provide ddc symlink in connector sysfs directory
git bisect bad 5b50fa2b35a4ddad11cb3d06231bf71759b49566
# bad: [9ebc4d2140adcdea2399b42d3f0d2f7e141ac1a8] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory
git bisect bad 9ebc4d2140adcdea2399b42d3f0d2f7e141ac1a8
# bad: [a4f9087e85de141e4e6d21ac2c583ae096cc9aba] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
git bisect bad a4f9087e85de141e4e6d21ac2c583ae096cc9aba
# first bad commit: [a4f9087e85de141e4e6d21ac2c583ae096cc9aba] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 2/2] i2c: iproc: Add full name of devicetree node to adapter name
From: Rayagonda Kokatanur @ 2019-08-08 3:37 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Rayagonda Kokatanur,
linux-kernel, Ray Jui, linux-i2c, bcm-kernel-feedback-list,
linux-arm-kernel
In-Reply-To: <1565235473-28461-1-git-send-email-rayagonda.kokatanur@broadcom.com>
From: Lori Hikichi <lori.hikichi@broadcom.com>
Add the full name of the devicetree node to the adapter name.
Without this change, all adapters have the same name making it difficult
to distinguish between multiple instances.
The most obvious way to see this is to use the utility i2c_detect.
e.g. "i2c-detect -l"
Before
i2c-1 i2c Broadcom iProc I2C adapter I2C adapter
i2c-0 i2c Broadcom iProc I2C adapter I2C adapter
After
i2c-1 i2c Broadcom iProc (i2c@e0000) I2C adapter
i2c-0 i2c Broadcom iProc (i2c@b0000) I2C adapter
Now it is easy to figure out which adapter maps to a which DT node.
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index 19ef2b0..183b220 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -922,7 +922,9 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev)
adap = &iproc_i2c->adapter;
i2c_set_adapdata(adap, iproc_i2c);
- strlcpy(adap->name, "Broadcom iProc I2C adapter", sizeof(adap->name));
+ snprintf(adap->name, sizeof(adap->name),
+ "Broadcom iProc (%s)",
+ of_node_full_name(iproc_i2c->device->of_node));
adap->algo = &bcm_iproc_algo;
adap->quirks = &bcm_iproc_i2c_quirks;
adap->dev.parent = &pdev->dev;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: John Hubbard @ 2019-08-08 3:46 UTC (permalink / raw)
To: Ira Weiny, Michal Hocko
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, amd-gfx, sparclinux, Dan Williams, devel, rds-devel,
linux-rdma, x86, Matthew Wilcox, Christoph Hellwig,
Jason Gunthorpe, xen-devel, devel, linux-media, intel-gfx,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190808023637.GA1508@iweiny-DESK2.sc.intel.com>
On 8/7/19 7:36 PM, Ira Weiny wrote:
> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
>> On Wed 07-08-19 10:37:26, Jan Kara wrote:
>>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
>>>> On 8/2/19 7:52 AM, Jan Kara wrote:
>>>>> On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
>>>>>> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
>>>>>>> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
>>>>>>>> On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
[...]
> Before I go on, I would like to say that the "imbalance" of get_user_pages()
> and put_page() bothers me from a purist standpoint... However, since this
> discussion cropped up I went ahead and ported my work to Linus' current master
> (5.3-rc3+) and in doing so I only had to steal a bit of Johns code... Sorry
> John... :-(
>
> I don't have the commit messages all cleaned up and I know there may be some
> discussion on these new interfaces but I wanted to throw this series out there
> because I think it may be what Jan and Michal are driving at (or at least in
> that direction.
>
> Right now only RDMA and DAX FS's are supported. Other users of GUP will still
> fail on a DAX file and regular files will still be at risk.[2]
>
> I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
>
> https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
>
> I think the most relevant patch to this conversation is:
>
> https://github.com/weiny2/linux-kernel/commit/5d377653ba5cf11c3b716f904b057bee6641aaf6
>
ohhh...can you please avoid using the old __put_user_pages_dirty()
function? I thought I'd caught things early enough to get away with
the rename and deletion of that. You could either:
a) open code an implementation of vaddr_put_pages_dirty_lock() that
doesn't call any of the *put_user_pages_dirty*() variants, or
b) include my first patch ("") are part of your series, or
c) base this on Andrews's tree, which already has merged in my first patch.
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* i2c: imx: support slave mode for imx I2C driver
From: Biwen Li @ 2019-08-08 3:53 UTC (permalink / raw)
To: shawnguo, s.hauer, kernel, festevam, linux-imx, wsa
Cc: Biwen Li, laurentiu.tudor, linux-i2c, linux-arm-kernel,
linux-kernel
The patch supports slave mode for imx I2C driver
Signed-off-by: Biwen Li <biwen.li@nxp.com>
---
drivers/i2c/busses/i2c-imx.c | 199 ++++++++++++++++++++++++++++++++---
1 file changed, 185 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b1b8b938d7f4..f7583a9fa56f 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -202,6 +202,9 @@ struct imx_i2c_struct {
struct pinctrl_state *pinctrl_pins_gpio;
struct imx_i2c_dma *dma;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ struct i2c_client *slave;
+#endif /* CONFIG_I2C_SLAVE */
};
static const struct imx_i2c_hwdata imx1_i2c_hwdata = {
@@ -583,23 +586,40 @@ static void i2c_imx_stop(struct imx_i2c_struct *i2c_imx)
imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
}
-static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
+/* Clear interrupt flag bit */
+static void i2c_imx_clr_if_bit(struct imx_i2c_struct *i2c_imx)
{
- struct imx_i2c_struct *i2c_imx = dev_id;
- unsigned int temp;
+ unsigned int status;
- temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
- if (temp & I2SR_IIF) {
- /* save status register */
- i2c_imx->i2csr = temp;
- temp &= ~I2SR_IIF;
- temp |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
- imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2SR);
- wake_up(&i2c_imx->queue);
- return IRQ_HANDLED;
- }
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IIF;
+ status |= (i2c_imx->hwdata->i2sr_clr_opcode & I2SR_IIF);
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
+
+/* Clear arbitration lost bit */
+static void i2c_imx_clr_al_bit(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ status &= ~I2SR_IAL;
+ imx_i2c_write_reg(status, i2c_imx, IMX_I2C_I2SR);
+}
- return IRQ_NONE;
+static irqreturn_t i2c_imx_master_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status;
+
+ dev_dbg(&i2c_imx->adapter.dev, "<%s>: master interrupt\n", __func__);
+
+ /* Save status register */
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ i2c_imx->i2csr = status | I2SR_IIF;
+
+ wake_up(&i2c_imx->queue);
+
+ return IRQ_HANDLED;
}
static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
@@ -1043,11 +1063,162 @@ static u32 i2c_imx_func(struct i2c_adapter *adapter)
| I2C_FUNC_SMBUS_READ_BLOCK_DATA;
}
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+static void i2c_imx_slave_init(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int temp;
+
+ dev_dbg(&i2c_imx->adapter.dev, "<%s>\n", __func__);
+
+ /* Set slave addr. */
+ imx_i2c_write_reg((i2c_imx->slave->addr << 1), i2c_imx, IMX_I2C_IADR);
+
+ /* Disable i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ ^ I2CR_IEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Reset status register */
+ imx_i2c_write_reg(i2c_imx->hwdata->i2sr_clr_opcode, i2c_imx,
+ IMX_I2C_I2SR);
+
+ /* Enable module and enable interrupt from i2c module */
+ temp = i2c_imx->hwdata->i2cr_ien_opcode
+ | I2CR_IIEN;
+ imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
+
+ /* Wait controller to be stable */
+ usleep_range(50, 150);
+}
+
+static irqreturn_t i2c_imx_slave_isr(struct imx_i2c_struct *i2c_imx)
+{
+ unsigned int status, ctl;
+ u8 value;
+
+ if (!i2c_imx->slave) {
+ dev_err(&i2c_imx->adapter.dev, "cannot deal with slave irq,i2c_imx->slave is null");
+ return IRQ_NONE;
+ }
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ ctl = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+ if (status & I2SR_IAL) { /* Arbitration lost */
+ i2c_imx_clr_al_bit(i2c_imx);
+ } else if (status & I2SR_IAAS) { /* Addressed as a slave */
+ if (status & I2SR_SRW) { /* Master wants to read from us*/
+ dev_dbg(&i2c_imx->adapter.dev, "read requested");
+ i2c_slave_event(i2c_imx->slave, I2C_SLAVE_READ_REQUESTED, &value);
+
+ /* Slave transimt */
+ ctl |= I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
+ /* Send data */
+ imx_i2c_write_reg(value, i2c_imx, IMX_I2C_I2DR);
+ } else { /* Master wants to write to us */
+ dev_dbg(&i2c_imx->adapter.dev, "write requested");
+ i2c_slave_event(i2c_imx->slave, I2C_SLAVE_WRITE_REQUESTED, &value);
+
+ /* Slave receive */
+ ctl &= ~I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+ /* Dummy read */
+ value = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ }
+ } else {
+ if (!(ctl & I2CR_MTX)) { /* Receive mode */
+ if (status & I2SR_IBB) { /* No STOP signal detected */
+ ctl &= ~I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
+ value = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ i2c_slave_event(i2c_imx->slave, I2C_SLAVE_WRITE_RECEIVED, &value);
+ } else { /* STOP signal is detected */
+ dev_dbg(&i2c_imx->adapter.dev,
+ "STOP signal detected");
+ i2c_slave_event(i2c_imx->slave, I2C_SLAVE_STOP, &value);
+ }
+ } else { /* Transmit mode */
+ if (!(status & I2SR_RXAK)) { /* Received ACK */
+ ctl |= I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+
+ i2c_slave_event(i2c_imx->slave, I2C_SLAVE_READ_PROCESSED, &value);
+
+ imx_i2c_write_reg(value, i2c_imx, IMX_I2C_I2DR);
+ } else { /* Received NAK */
+ ctl &= ~I2CR_MTX;
+ imx_i2c_write_reg(ctl, i2c_imx, IMX_I2C_I2CR);
+ value = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2DR);
+ }
+ }
+ }
+ return IRQ_HANDLED;
+}
+
+static int i2c_imx_reg_slave(struct i2c_client *client)
+{
+ struct imx_i2c_struct *i2c_imx = i2c_get_adapdata(client->adapter);
+
+ if (i2c_imx->slave)
+ return -EINVAL;
+
+ dev_dbg(&i2c_imx->adapter.dev, "<%s>\n", __func__);
+ i2c_imx->slave = client;
+
+ i2c_imx_slave_init(i2c_imx);
+
+ return 0;
+}
+
+static int i2c_imx_unreg_slave(struct i2c_client *client)
+{
+ struct imx_i2c_struct *i2c_imx = i2c_get_adapdata(client->adapter);
+
+ if (!i2c_imx->slave)
+ return -EINVAL;
+
+ i2c_imx->slave = NULL;
+
+ return 0;
+}
+#endif /* CONFIG_I2C_SLAVE */
+
static const struct i2c_algorithm i2c_imx_algo = {
.master_xfer = i2c_imx_xfer,
.functionality = i2c_imx_func,
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ .reg_slave = i2c_imx_reg_slave,
+ .unreg_slave = i2c_imx_unreg_slave,
+#endif /* CONFIG_I2C_SLAVE */
};
+static irqreturn_t i2c_imx_isr(int irq, void *dev_id)
+{
+ struct imx_i2c_struct *i2c_imx = dev_id;
+ unsigned int status, ctl;
+ irqreturn_t irq_status = IRQ_NONE;
+
+ status = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
+ ctl = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
+
+ if (status & I2SR_IIF) {
+ i2c_imx_clr_if_bit(i2c_imx);
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
+ if (ctl & I2CR_MSTA)
+ irq_status = i2c_imx_master_isr(i2c_imx);
+ else
+ irq_status = i2c_imx_slave_isr(i2c_imx);
+#else
+ irq_status = i2c_imx_master_isr(i2c_imx);
+
+#endif /* CONFIG_I2C_SLAVE */
+ }
+
+ return irq_status;
+}
+
static int i2c_imx_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/2] rtc: add new Amlogic Virtual Wake RTC
From: Kevin Hilman @ 2019-08-08 4:23 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, Kevin Hilman, linux-arm-kernel, Neil Armstrong
From: Kevin Hilman <khilman@baylibre.com>
Add a new driver for the virtual wake RTC on Amlogic SoCs.
The RTC is virtual from the Linux side because it's a hardware timer
managed by firmware on the secure co-processor (SCP.) The interface
is 1 register where a wakeup time (in seconds) is written. The SCP then
uses this value to program an always-on timer.
Changes since v1:
- add MAINTAINERS entry
- add nop ->alarm_irq_enable() (workaround for RTC core
limitation pointed out by Alexandre Belloni)
- remove unused ->read_alarm()
- fix statics
- move resume to dev_pm_ops
- add suspend hook
- don't calculate (or write) the alarm timer value until suspend time
Changes since Neil's original version
- move from do_gettimeofday() to ktime_get()
Kevin Hilman (1): dt-bindings: rtc: new binding for Amlogic VRTC
Neil Armstrong (1):
rtc: Add Amlogic Virtual Wake RTC
.../bindings/rtc/rtc-meson-vrtc.txt | 22 +++
drivers/rtc/Kconfig | 11 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 149 ++++++++++++++++++
4 files changed, 183 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: rtc: new binding for Amlogic VRTC
From: Kevin Hilman @ 2019-08-08 4:23 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, Kevin Hilman, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190808042357.4663-1-khilman@kernel.org>
From: Kevin Hilman <khilman@baylibre.com>
Add binding fo the new VRTC driver for Amlogic SoCs. The 64-bit
family of SoCs only has an RTC managed by firmware, and this VRTC
driver provides the simple, one-register firmware interface.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
.../bindings/rtc/rtc-meson-vrtc.txt | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
new file mode 100644
index 000000000000..c014f54a9853
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
@@ -0,0 +1,22 @@
+* Amlogic Virtual RTC (VRTC)
+
+This is a Linux interface to an RTC managed by firmware, hence it's
+virtual from a Linux perspective. The interface is 1 register where
+an alarm time (in seconds) is to be written.
+
+Required properties:
+- compatible: should be "amlogic,meson-vrtc"
+- reg: physical address for the alarm register
+
+The alarm register is a simple scratch register shared between the
+application processors (AP) and the secure co-processor (SCP.) When
+the AP suspends, the SCP will use the value of this register to
+program an always-on timer before going sleep. When the timer expires,
+the SCP will wake up and will then wake the AP.
+
+Example:
+
+ vrtc: rtc@0a8 {
+ compatible = "amlogic,meson-vrtc";
+ reg = <0x0 0x000a8 0x0 0x4>;
+ };
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] rtc: Add Amlogic Virtual Wake RTC
From: Kevin Hilman @ 2019-08-08 4:23 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc
Cc: linux-amlogic, Kevin Hilman, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190808042357.4663-1-khilman@kernel.org>
From: Neil Armstrong <narmstrong@baylibre.com>
The Amlogic Meson GX SoCs uses a special register to store the
time in seconds to wakeup after a system suspend.
In order to be able to reuse the RTC wakealarm feature, this
driver implements a fake RTC device which uses the system time
to deduce a suspend delay.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[khilman: rebase to v5.3-rc, rework and modernization]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 11 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-meson-vrtc.c | 153 +++++++++++++++++++++++++++++++++++
4 files changed, 166 insertions(+)
create mode 100644 drivers/rtc/rtc-meson-vrtc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e3c4b4..2ae83e1acb05 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1443,6 +1443,7 @@ F: arch/arm64/boot/dts/amlogic/
F: drivers/pinctrl/meson/
F: drivers/mmc/host/meson*
F: drivers/soc/amlogic/
+F: drivers/rtc/rtc-meson*
N: meson
ARM/Amlogic Meson SoC Sound Drivers
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e72f65b61176..7cd325ecc10b 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -373,6 +373,17 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
+config RTC_DRV_MESON_VRTC
+ tristate "Amlogic Meson Virtual RTC"
+ depends on ARCH_MESON || COMPILE_TEST
+ default m if ARCH_MESON
+ help
+ If you say yes here you will get support for the
+ Virtual RTC of Amlogic SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-meson-vrtc.
+
config RTC_DRV_RK808
tristate "Rockchip RK805/RK808/RK809/RK817/RK818 RTC"
depends on MFD_RK808
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6b09c21dc1b6..b50fd3aa81b3 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_RTC_DRV_MAX8907) += rtc-max8907.o
obj-$(CONFIG_RTC_DRV_MAX8925) += rtc-max8925.o
obj-$(CONFIG_RTC_DRV_MAX8997) += rtc-max8997.o
obj-$(CONFIG_RTC_DRV_MAX8998) += rtc-max8998.o
+obj-$(CONFIG_RTC_DRV_MESON_VRTC)+= rtc-meson-vrtc.o
obj-$(CONFIG_RTC_DRV_MC13XXX) += rtc-mc13xxx.o
obj-$(CONFIG_RTC_DRV_MCP795) += rtc-mcp795.o
obj-$(CONFIG_RTC_DRV_MESON) += rtc-meson.o
diff --git a/drivers/rtc/rtc-meson-vrtc.c b/drivers/rtc/rtc-meson-vrtc.c
new file mode 100644
index 000000000000..bdf9c2fe5b91
--- /dev/null
+++ b/drivers/rtc/rtc-meson-vrtc.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/time64.h>
+
+struct meson_vrtc_data {
+ void __iomem *io_alarm;
+ struct rtc_device *rtc;
+ unsigned long alarm_time;
+ bool enabled;
+};
+
+static int meson_vrtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct timespec64 time;
+
+ dev_dbg(dev, "%s\n", __func__);
+ ktime_get_raw_ts64(&time);
+ rtc_time64_to_tm(time.tv_sec, tm);
+
+ return 0;
+}
+
+static void meson_vrtc_set_wakeup_time(struct meson_vrtc_data *vrtc,
+ unsigned long time)
+{
+ writel_relaxed(time, vrtc->io_alarm);
+}
+
+static int meson_vrtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s: alarm->enabled=%d\n", __func__, alarm->enabled);
+ if (alarm->enabled)
+ vrtc->alarm_time = rtc_tm_to_time64(&alarm->time);
+ else
+ vrtc->alarm_time = 0;
+
+ return 0;
+}
+
+static int meson_vrtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ vrtc->enabled = enabled;
+ return 0;
+}
+
+static const struct rtc_class_ops meson_vrtc_ops = {
+ .read_time = meson_vrtc_read_time,
+ .set_alarm = meson_vrtc_set_alarm,
+ .alarm_irq_enable = meson_vrtc_alarm_irq_enable,
+};
+
+static int meson_vrtc_probe(struct platform_device *pdev)
+{
+ struct meson_vrtc_data *vrtc;
+ struct resource *res;
+
+ vrtc = devm_kzalloc(&pdev->dev, sizeof(*vrtc), GFP_KERNEL);
+ if (!vrtc)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ vrtc->io_alarm = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(vrtc->io_alarm))
+ return PTR_ERR(vrtc->io_alarm);
+
+ device_init_wakeup(&pdev->dev, 1);
+
+ platform_set_drvdata(pdev, vrtc);
+
+ vrtc->rtc = devm_rtc_device_register(&pdev->dev, "meson-vrtc",
+ &meson_vrtc_ops, THIS_MODULE);
+ if (IS_ERR(vrtc->rtc))
+ return PTR_ERR(vrtc->rtc);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int meson_vrtc_suspend(struct device *dev)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+ if (vrtc->alarm_time) {
+ unsigned long local_time;
+ long alarm_secs;
+ struct timespec64 time;
+
+ ktime_get_raw_ts64(&time);
+ local_time = time.tv_sec;
+
+ dev_dbg(dev, "alarm_time = %lus, local_time=%lus\n",
+ vrtc->alarm_time, local_time);
+ alarm_secs = vrtc->alarm_time - local_time;
+ if (alarm_secs > 0) {
+ meson_vrtc_set_wakeup_time(vrtc, alarm_secs);
+ dev_dbg(dev, "system will wakeup in %lds.\n",
+ alarm_secs);
+ } else {
+ dev_err(dev, "alarm time already passed: %lds.\n",
+ alarm_secs);
+ }
+ }
+
+ return 0;
+}
+
+static int meson_vrtc_resume(struct device *dev)
+{
+ struct meson_vrtc_data *vrtc = dev_get_drvdata(dev);
+
+ dev_dbg(dev, "%s\n", __func__);
+
+ vrtc->alarm_time = 0;
+ meson_vrtc_set_wakeup_time(vrtc, 0);
+ return 0;
+}
+#endif
+static SIMPLE_DEV_PM_OPS(meson_vrtc_pm_ops,
+ meson_vrtc_suspend, meson_vrtc_resume);
+
+static const struct of_device_id meson_vrtc_dt_match[] = {
+ { .compatible = "amlogic,meson-vrtc"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, meson_vrtc_dt_match);
+
+static struct platform_driver meson_vrtc_driver = {
+ .probe = meson_vrtc_probe,
+ .driver = {
+ .name = "meson-vrtc",
+ .of_match_table = meson_vrtc_dt_match,
+ .pm = &meson_vrtc_pm_ops,
+ },
+};
+
+module_platform_driver(meson_vrtc_driver);
+
+MODULE_DESCRIPTION("Amlogic Virtual Wakeup RTC Timer driver");
+MODULE_LICENSE("GPL");
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/8] dt-bindings: omap: add new binding for PRM instances
From: Keerthy @ 2019-08-08 4:35 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1565164139-21886-2-git-send-email-t-kristo@ti.com>
On 07/08/19 1:18 PM, Tero Kristo wrote:
> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> of these will act as a power domain controller and potentially as a reset
> provider.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/arm/omap/prm-inst.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> new file mode 100644
> index 0000000..e0ae87b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -0,0 +1,24 @@
> +OMAP PRM instance bindings
> +
> +Power and Reset Manager is an IP block on OMAP family of devices which
> +handle the power domains and their current state, and provide reset
> +handling for the domains and/or separate IP blocks under the power domain
> +hierarchy.
> +
> +Required properties:
> +- compatible: Must be one of:
> + "ti,am3-prm-inst"
> + "ti,am4-prm-inst"
> + "ti,omap4-prm-inst"
> + "ti,omap5-prm-inst"
> + "ti,dra7-prm-inst"
> +- reg: Contains PRM instance register address range
> + (base address and length)
How about reset-cells property, Isn't that a mandatory property?
> +
> +Example:
> +
> +prm_dsp2: prm@1b00 {
> + compatible = "ti,dra7-prm-inst";
> + reg = <0x1b00 0x40>;
> + #reset-cells = <1>;
> +};
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT v3 07/14] clk: meson: g12a: add notifiers to handle cpu clock change
From: Stephen Boyd @ 2019-08-08 4:43 UTC (permalink / raw)
To: Martin Blumenstingl, Neil Armstrong, dbasehore
Cc: khilman, linux-kernel, linux-gpio, linux-amlogic, linux-clk,
linux-arm-kernel, jbrunet
In-Reply-To: <CAFBinCAnKeGYkyCmEMugWuQaSxgBp4DqtHN3b0rLJY6jwOF0QA@mail.gmail.com>
Quoting Martin Blumenstingl (2019-07-02 16:28:55)
> Hi Stephen, Hi Neil,
>
> On Mon, Jul 1, 2019 at 11:13 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
> >
> > In order to implement clock switching for the CLKID_CPU_CLK and
> > CLKID_CPUB_CLK, notifiers are added on specific points of the
> > clock tree :
> >
> > cpu_clk / cpub_clk
> > | \- cpu_clk_dyn
> > | | \- cpu_clk_premux0
> > | | |- cpu_clk_postmux0
> > | | | |- cpu_clk_dyn0_div
> > | | | \- xtal/fclk_div2/fclk_div3
> > | | \- xtal/fclk_div2/fclk_div3
> > | \- cpu_clk_premux1
> > | |- cpu_clk_postmux1
> > | | |- cpu_clk_dyn1_div
> > | | \- xtal/fclk_div2/fclk_div3
> > | \- xtal/fclk_div2/fclk_div3
> > \ sys_pll / sys1_pll
> >
> > This for each cluster, a single one for G12A, two for G12B.
> >
> > Each cpu_clk_premux1 tree is marked as read-only and CLK_SET_RATE_NO_REPARENT,
> > to be used as "parking" clock in a safe clock frequency.
> it seems that this is one case where the "coordinated clocks" feature
> would come handy: [0]
> Stephen, do you know if those patches stopped in March or if there's
> still some ongoing effort to get them ready?
>
Derek told me yesterday he wants to work on it again, but I don't know
his timeline. If Derek doesn't reply here then maybe it can be picked up
by someone else.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] clk: core: introduce clk_hw_set_parent()
From: Stephen Boyd @ 2019-08-08 4:47 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong
Cc: Neil Armstrong, Martin Blumenstingl, linux-kernel, linux-amlogic,
linux-clk, linux-arm-kernel
In-Reply-To: <1j36iewvdo.fsf@starbuckisacylon.baylibre.com>
Quoting Jerome Brunet (2019-08-06 01:28:19)
> On Wed 31 Jul 2019 at 10:40, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> > Introduce the clk_hw_set_parent() provider call to change parent of
> > a clock by using the clk_hw pointers.
> >
> > This eases the clock reparenting from clock rate notifiers and
> > implementing DVFS with simpler code avoiding the boilerplates
> > functions as __clk_lookup(clk_hw_get_name()) then clk_set_parent().
> >
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Looks ok to me but we will obviously need Stephen's ack to apply it
Acked-by: Stephen Boyd <sboyd@kernel.org>
>
> > ---
> > drivers/clk/clk.c | 6 ++++++
> > include/linux/clk-provider.h | 1 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index c0990703ce54..c11b1781d24a 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -2487,6 +2487,12 @@ static int clk_core_set_parent_nolock(struct clk_core *core,
> > return ret;
> > }
> >
> > +int clk_hw_set_parent(struct clk_hw *hw, struct clk_hw *parent)
> > +{
> > + return clk_core_set_parent_nolock(hw->core, parent->core);
I wonder if you really want to call all those things in
clk_core_set_parent_nolock(). For example, do you want notifiers to run
again and for rates to be speculated? Maybe all you want to do is
overwrite some value for the clk's parent by calling into the ops for
the clk and generically parse the value that's passed as the "parent"
here.
I ask because it may be good to avoid doing all that work and updating
bookkeeping when we're deep in a notifier. If we can clearly understand
what the driver wants to do from the notifier then it's simpler to
change in the future to use things such as the coordinated clk rate
vaporware.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cache: silence -Woverride-init warnings
From: Nathan Chancellor @ 2019-08-08 4:50 UTC (permalink / raw)
To: Qian Cai
Cc: mark.rutland, catalin.marinas, linux-kernel, clang-built-linux,
will, linux-arm-kernel
In-Reply-To: <20190808032916.879-1-cai@lca.pw>
On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC (and
> Clang) with -Winitializer-overrides),
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VIPT] = "VIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> 'icache_policy_str[2]')
> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_PIPT] = "PIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> 'icache_policy_str[3]')
> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VPIPT] = "VPIPT",
> ^~~~~~~
> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> 'icache_policy_str[0]')
>
> because it initializes icache_policy_str[0 ... 3] twice. Since
> arm64 developers are keen to keep the style of initializing a static
> array with a non-zero pattern first, just disable those warnings for
> both GCC and Clang of this file.
>
> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> Signed-off-by: Qian Cai <cai@lca.pw>
It's a shame we can't just use one cc-disable-warning statement but
-Woverride-init wasn't added for GCC compatibility until clang 8.0.0
and we don't have an established minimum clang version.
With that said, I applied your patch and I don't see with warning with
W=1 anymore and I see both options get added to the clang command line
with V=1.
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cheers!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: clock: Add Bitmain BM1880 SoC clock controller binding
From: Stephen Boyd @ 2019-08-08 5:01 UTC (permalink / raw)
To: Manivannan Sadhasivam, mturquette, robh+dt
Cc: devicetree, Manivannan Sadhasivam, darren.tsao, linux-kernel,
linux-arm-kernel, fisher.cheng, alec.lin, linux-clk, haitao.suo
In-Reply-To: <20190705151440.20844-2-manivannan.sadhasivam@linaro.org>
Quoting Manivannan Sadhasivam (2019-07-05 08:14:36)
> Add devicetree binding for Bitmain BM1880 SoC clock controller.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> .../bindings/clock/bitmain,bm1880-clk.txt | 47 +++++++++++
Can you convert this to YAML? It's all the rage right now.
> include/dt-bindings/clock/bm1880-clock.h | 82 +++++++++++++++++++
> 2 files changed, 129 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> create mode 100644 include/dt-bindings/clock/bm1880-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> new file mode 100644
> index 000000000000..9c967095d430
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.txt
> @@ -0,0 +1,47 @@
> +* Bitmain BM1880 Clock Controller
> +
> +The Bitmain BM1880 clock controler generates and supplies clock to
> +various peripherals within the SoC.
> +
> +Required Properties:
> +
> +- compatible: Should be "bitmain,bm1880-clk"
> +- reg : Register address and size of PLL and SYS control domains
> +- reg-names : Register domain names: "pll" and "sys"
> +- clocks : Phandle of the input reference clock.
> +- #clock-cells: Should be 1.
> +
> +Each clock is assigned an identifier, and client nodes can use this identifier
> +to specify the clock which they consume.
> +
> +All available clocks are defined as preprocessor macros in corresponding
> +dt-bindings/clock/bm1880-clock.h header and can be used in device tree sources.
> +
> +External clocks:
> +
> +The osc clock used as the input for the plls is generated outside the SoC.
> +It is expected that it is defined using standard clock bindings as "osc".
> +
> +Example:
> +
> + clk: clock-controller@800 {
> + compatible = "bitmain,bm1880-clk";
> + reg = <0xe8 0x0c>,<0x800 0xb0>;
It looks weird still. What hardware module is this actually part of?
Some larger power manager block?
> + reg-names = "pll", "sys";
> + clocks = <&osc>;
> + #clock-cells = <1>;
> + };
> +
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-08 5:12 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Sunil Mohan Adapa, Martin Ayotte, linux-arm-kernel
In-Reply-To: <20190807144533.bbgtmkva34su7c5v@flea>
On Wed, Aug 7, 2019 at 10:45 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Wed, Aug 07, 2019 at 08:09:19PM +0800, Chen-Yu Tsai wrote:
> > On Wed, Aug 7, 2019 at 8:01 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Tue, Aug 06, 2019 at 02:25:17PM +0800, Chen-Yu Tsai wrote:
> > > > On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
> > > > >
> > > > > Fine for me too.
> > > > >
> > > > > Thanks .
> > > > >
> > > > > -----Message d'origine-----
> > > > > De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> > > > > Envoyé : Monday, August 05, 2019 1:25 AM
> > > > > Ą : Chen-Yu Tsai
> > > > > Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> > > > > Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> > > > > A64-OLinuXino
> > > > >
> > > > > On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> > > > > > On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
> > > > > >>
> > > > > >> On 01/08/19 6:49 am, Martin Ayotte wrote:
> > > > > >>> If my SOB could help here, I don't mind since I've done the commit
> > > > > >>> more than a year ago for Armbian ...
> > > > > >>>
> > > > > >>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> > > > > >>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> > > > > >> gmai.com is likely a typo.
> > > > > >>
> > > > > >>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> > > > > >>>
> > > > > >>>> Thanks. The patch looks good overall. The authorship is a little
> > > > > >>>> confusing though. If it was initially done by Martin (CC-ed), then
> > > > > >>>> he should be the author, and we should get his Signed-off-by if
> > > > > >>>> possible.
> > > > > >>
> > > > > >> Martin is indeed the original author of the patch. Thank you for
> > > > > reviewing.
> > > > > >
> > > > > > I'd like to apply this patch with Martin as the author, if that's OK with
> > > > > you
> > > > > > both?
> > > > >
> > > > > That is completely okay with me.
> > > >
> > > > Applied for 5.4.
> > > >
> > > > I reordered the tags so they make more sense:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
> > >
> > > Sorry for being late on this, but it looks like the eMMC, NAND and SPI
> > > pins are conflicting on the A64-Olinuxino design.
> > >
> > > There's no configuration with a NAND, so we don't really need to worry
> > > about that, but if we merge this in the main DT, we'll prevent anyone
> > > from using that DT on an olinuxino with a SPI flash.
> > >
> > > I think we should just create emmc and SPI-flash variants of that DT.
> >
> > Actually they aren't. Olimex specifically uses eMMC modules that don't
> > use the data strobe line, so SPI can be used together.
>
> Ah, right.
>
> Still, this creates a precedent that I'm not really comfortable
> with. Three actually.
>
> Merging this in the main DT means three things:
> - We're not consistent anymore, including within the olinuxino
> boards only. A20 Olinuxino is pretty much in the same situation,
> yet we dealt with it differently.
> - This means that this will create a spurious device and report
> errors in the kernel message and whenever someone will try to
> access the device on boards that don't have it wired. This
> shouldn't happen and we really shouldn't expose devices that just
> aren't there, just like you don't have all the devices that are
> not connected on your USB connector.
> - Finally, this means that in order to keep it somewhat consistent,
> we would have to merge the SPI flash in the main DT too. This will
> prevent people without a SPI flash to use the SPI signals on the
> UEXT connector for something else, which again goes against the
> policy we've had for basically any other board.
OK. Shall we back it out and figure out something else?
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/5] clk: Add driver for Bitmain BM1880 SoC clock controller
From: Stephen Boyd @ 2019-08-08 5:15 UTC (permalink / raw)
To: Manivannan Sadhasivam, mturquette, robh+dt
Cc: devicetree, Manivannan Sadhasivam, darren.tsao, linux-kernel,
linux-arm-kernel, fisher.cheng, alec.lin, linux-clk, haitao.suo
In-Reply-To: <20190705151440.20844-5-manivannan.sadhasivam@linaro.org>
Quoting Manivannan Sadhasivam (2019-07-05 08:14:39)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index fc1e0cf44995..ffc61ed85ade 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -304,6 +304,12 @@ config COMMON_CLK_FIXED_MMIO
> help
> Support for Memory Mapped IO Fixed clocks
>
> +config COMMON_CLK_BM1880
> + bool "Clock driver for Bitmain BM1880 SoC"
> + depends on ARCH_BITMAIN || COMPILE_TEST
> + help
> + This driver supports the clocks on Bitmain BM1880 SoC.
Can you add this config somewhere else besides the end? Preferably
close to alphabetically in this file.
> +
> source "drivers/clk/actions/Kconfig"
> source "drivers/clk/analogbits/Kconfig"
> source "drivers/clk/bcm/Kconfig"
> diff --git a/drivers/clk/clk-bm1880.c b/drivers/clk/clk-bm1880.c
> new file mode 100644
> index 000000000000..26cdb75bb936
> --- /dev/null
> +++ b/drivers/clk/clk-bm1880.c
> @@ -0,0 +1,947 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bitmain BM1880 SoC clock driver
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
Should probably add kernel.h for at least container_of()
> +
> +#include <dt-bindings/clock/bm1880-clock.h>
> +
> +#define BM1880_CLK_MPLL_CTL 0x00
> +#define BM1880_CLK_SPLL_CTL 0x04
> +#define BM1880_CLK_FPLL_CTL 0x08
> +#define BM1880_CLK_DDRPLL_CTL 0x0c
> +
> +#define BM1880_CLK_ENABLE0 0x00
> +#define BM1880_CLK_ENABLE1 0x04
> +#define BM1880_CLK_SELECT 0x20
> +#define BM1880_CLK_DIV0 0x40
> +#define BM1880_CLK_DIV1 0x44
> +#define BM1880_CLK_DIV2 0x48
> +#define BM1880_CLK_DIV3 0x4c
> +#define BM1880_CLK_DIV4 0x50
> +#define BM1880_CLK_DIV5 0x54
> +#define BM1880_CLK_DIV6 0x58
> +#define BM1880_CLK_DIV7 0x5c
> +#define BM1880_CLK_DIV8 0x60
> +#define BM1880_CLK_DIV9 0x64
> +#define BM1880_CLK_DIV10 0x68
> +#define BM1880_CLK_DIV11 0x6c
> +#define BM1880_CLK_DIV12 0x70
> +#define BM1880_CLK_DIV13 0x74
> +#define BM1880_CLK_DIV14 0x78
> +#define BM1880_CLK_DIV15 0x7c
> +#define BM1880_CLK_DIV16 0x80
> +#define BM1880_CLK_DIV17 0x84
> +#define BM1880_CLK_DIV18 0x88
> +#define BM1880_CLK_DIV19 0x8c
> +#define BM1880_CLK_DIV20 0x90
> +#define BM1880_CLK_DIV21 0x94
> +#define BM1880_CLK_DIV22 0x98
> +#define BM1880_CLK_DIV23 0x9c
> +#define BM1880_CLK_DIV24 0xa0
> +#define BM1880_CLK_DIV25 0xa4
> +#define BM1880_CLK_DIV26 0xa8
> +#define BM1880_CLK_DIV27 0xac
> +#define BM1880_CLK_DIV28 0xb0
> +
> +#define to_bm1880_pll_clk(_hw) container_of(_hw, struct bm1880_pll_hw_clock, hw)
> +#define to_bm1880_div_clk(_hw) container_of(_hw, struct bm1880_div_hw_clock, hw)
> +
> +static DEFINE_SPINLOCK(bm1880_clk_lock);
> +
> +struct bm1880_clock_data {
> + void __iomem *pll_base;
> + void __iomem *sys_base;
> + struct clk_onecell_data clk_data;
> +};
> +
> +struct bm1880_gate_clock {
> + unsigned int id;
> + const char *name;
> + const char *parent;
> + u32 gate_reg;
> + s8 gate_shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_mux_clock {
> + unsigned int id;
> + const char *name;
> + const char * const * parents;
> + s8 num_parents;
> + u32 reg;
> + s8 shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_clock {
> + unsigned int id;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + u8 shift;
> + u8 width;
> + u32 initval;
> + struct clk_div_table *table;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_hw_clock {
> + struct bm1880_div_clock div;
> + void __iomem *base;
> + spinlock_t *lock;
> + struct clk_hw hw;
> +};
> +
> +struct bm1880_composite_clock {
> + unsigned int id;
> + const char *name;
> + const char *parent;
> + const char * const * parents;
> + unsigned int num_parents;
> + unsigned long flags;
> +
> + u32 gate_reg;
> + u32 mux_reg;
> + u32 div_reg;
> +
> + s8 gate_shift;
> + s8 mux_shift;
> + s8 div_shift;
> + s8 div_width;
> + s16 div_initval;
> + struct clk_div_table *table;
> +};
> +
> +struct bm1880_pll_clock {
> + unsigned int id;
> + const char *name;
> + const char *parent;
> + u32 reg;
> + unsigned long flags;
> +};
> +
> +struct bm1880_pll_hw_clock {
> + struct bm1880_pll_clock pll;
> + void __iomem *base;
> + struct clk_hw hw;
> +};
> +
> +#define GATE_DIV(_id, _name, _parent, _gate_reg, _gate_shift, _div_reg, \
> + _div_shift, _div_width, _div_initval, _table, \
> + _flags) { \
> + .id = _id, \
> + .parent = _parent, \
> + .name = _name, \
> + .gate_reg = _gate_reg, \
> + .gate_shift = _gate_shift, \
> + .div_reg = _div_reg, \
> + .div_shift = _div_shift, \
> + .div_width = _div_width, \
> + .div_initval = _div_initval, \
> + .table = _table, \
> + .mux_shift = -1, \
> + .flags = _flags, \
> + }
> +
> +#define GATE_MUX(_id, _name, _parents, _gate_reg, _gate_shift, \
> + _mux_reg, _mux_shift, _flags) { \
> + .id = _id, \
> + .parents = _parents, \
> + .num_parents = ARRAY_SIZE(_parents), \
> + .name = _name, \
> + .gate_reg = _gate_reg, \
> + .gate_shift = _gate_shift, \
> + .div_shift = -1, \
> + .mux_reg = _mux_reg, \
> + .mux_shift = _mux_shift, \
> + .flags = _flags, \
> + }
> +
> +static const struct bm1880_pll_clock bm1880_pll_clks[] = {
> + { BM1880_CLK_MPLL, "clk_mpll", "osc", BM1880_CLK_MPLL_CTL,
> + CLK_IS_CRITICAL },
> + { BM1880_CLK_SPLL, "clk_spll", "osc", BM1880_CLK_SPLL_CTL,
> + CLK_IS_CRITICAL },
> + { BM1880_CLK_FPLL, "clk_fpll", "osc", BM1880_CLK_FPLL_CTL,
> + CLK_IS_CRITICAL },
> + { BM1880_CLK_DDRPLL, "clk_ddrpll", "osc", BM1880_CLK_DDRPLL_CTL,
> + CLK_IS_CRITICAL },
> +};
> +
> +static const struct bm1880_gate_clock bm1880_gate_clks[] = {
> + { BM1880_CLK_AHB_ROM, "clk_ahb_rom", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 2, CLK_IS_CRITICAL },
> + { BM1880_CLK_AXI_SRAM, "clk_axi_sram", "clk_axi1",
> + BM1880_CLK_ENABLE0, 3, CLK_IS_CRITICAL },
> + { BM1880_CLK_DDR_AXI, "clk_ddr_axi", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 4, CLK_IS_CRITICAL },
> + { BM1880_CLK_APB_EFUSE, "clk_apb_efuse", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 6, CLK_IS_CRITICAL },
> + { BM1880_CLK_AXI5_EMMC, "clk_axi5_emmc", "clk_axi5",
> + BM1880_CLK_ENABLE0, 7, 0 },
> + { BM1880_CLK_AXI5_SD, "clk_axi5_sd", "clk_axi5",
> + BM1880_CLK_ENABLE0, 10, 0 },
> + { BM1880_CLK_AXI4_ETH0, "clk_axi4_eth0", "clk_axi4",
> + BM1880_CLK_ENABLE0, 14, 0 },
> + { BM1880_CLK_AXI4_ETH1, "clk_axi4_eth1", "clk_axi4",
> + BM1880_CLK_ENABLE0, 16, 0 },
> + { BM1880_CLK_AXI1_GDMA, "clk_axi1_gdma", "clk_axi1",
> + BM1880_CLK_ENABLE0, 17, 0 },
> + /* Don't gate GPIO clocks as it is not owned by the GPIO driver */
> + { BM1880_CLK_APB_GPIO, "clk_apb_gpio", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 18, CLK_IGNORE_UNUSED },
> + { BM1880_CLK_APB_GPIO_INTR, "clk_apb_gpio_intr", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 19, CLK_IGNORE_UNUSED },
> + { BM1880_CLK_AXI1_MINER, "clk_axi1_miner", "clk_axi1",
> + BM1880_CLK_ENABLE0, 21, 0 },
> + { BM1880_CLK_AHB_SF, "clk_ahb_sf", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 22, 0 },
> + { BM1880_CLK_SDMA_AXI, "clk_sdma_axi", "clk_axi5",
> + BM1880_CLK_ENABLE0, 23, 0 },
> + { BM1880_CLK_APB_I2C, "clk_apb_i2c", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 25, 0 },
> + { BM1880_CLK_APB_WDT, "clk_apb_wdt", "clk_mux_axi6",
> + BM1880_CLK_ENABLE0, 26, 0 },
> + { BM1880_CLK_APB_JPEG, "clk_apb_jpeg", "clk_axi6",
> + BM1880_CLK_ENABLE0, 27, 0 },
> + { BM1880_CLK_AXI5_NF, "clk_axi5_nf", "clk_axi5",
> + BM1880_CLK_ENABLE0, 29, 0 },
> + { BM1880_CLK_APB_NF, "clk_apb_nf", "clk_axi6",
> + BM1880_CLK_ENABLE0, 30, 0 },
> + { BM1880_CLK_APB_PWM, "clk_apb_pwm", "clk_mux_axi6",
> + BM1880_CLK_ENABLE1, 0, 0 },
> + { BM1880_CLK_RV, "clk_rv", "clk_mux_rv",
> + BM1880_CLK_ENABLE1, 1, 0 },
> + { BM1880_CLK_APB_SPI, "clk_apb_spi", "clk_mux_axi6",
> + BM1880_CLK_ENABLE1, 2, 0 },
> + { BM1880_CLK_UART_500M, "clk_uart_500m", "clk_div_uart_500m",
> + BM1880_CLK_ENABLE1, 4, 0 },
> + { BM1880_CLK_APB_UART, "clk_apb_uart", "clk_axi6",
> + BM1880_CLK_ENABLE1, 5, 0 },
> + { BM1880_CLK_APB_I2S, "clk_apb_i2s", "clk_axi6",
> + BM1880_CLK_ENABLE1, 6, 0 },
> + { BM1880_CLK_AXI4_USB, "clk_axi4_usb", "clk_axi4",
> + BM1880_CLK_ENABLE1, 7, 0 },
> + { BM1880_CLK_APB_USB, "clk_apb_usb", "clk_axi6",
> + BM1880_CLK_ENABLE1, 8, 0 },
> + { BM1880_CLK_12M_USB, "clk_12m_usb", "clk_div_12m_usb",
> + BM1880_CLK_ENABLE1, 11, 0 },
> + { BM1880_CLK_APB_VIDEO, "clk_apb_video", "clk_axi6",
> + BM1880_CLK_ENABLE1, 12, 0 },
> + { BM1880_CLK_APB_VPP, "clk_apb_vpp", "clk_axi6",
> + BM1880_CLK_ENABLE1, 15, 0 },
> + { BM1880_CLK_AXI6, "clk_axi6", "clk_mux_axi6",
> + BM1880_CLK_ENABLE1, 21, CLK_IS_CRITICAL },
> +};
> +
> +static const char * const clk_a53_parents[] = { "clk_spll", "clk_mpll" };
> +static const char * const clk_rv_parents[] = { "clk_div_1_rv", "clk_div_0_rv" };
> +static const char * const clk_axi1_parents[] = { "clk_div_1_axi1", "clk_div_0_axi1" };
> +static const char * const clk_axi6_parents[] = { "clk_div_1_axi6", "clk_div_0_axi6" };
> +
> +static const struct bm1880_mux_clock bm1880_mux_clks[] = {
> + { BM1880_CLK_MUX_RV, "clk_mux_rv", clk_rv_parents, 2,
> + BM1880_CLK_SELECT, 1, 0 },
> + { BM1880_CLK_MUX_AXI6, "clk_mux_axi6", clk_axi6_parents, 2,
> + BM1880_CLK_SELECT, 3, 0 },
> +};
> +
> +static struct clk_div_table bm1880_div_table_0[] = {
Can these tables be const?
> + { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 4 },
> + { 4, 5 }, { 5, 6 }, { 6, 7 }, { 7, 8 },
> + { 8, 9 }, { 9, 10 }, { 10, 11 }, { 11, 12 },
> + { 12, 13 }, { 13, 14 }, { 14, 15 }, { 15, 16 },
> + { 16, 17 }, { 17, 18 }, { 18, 19 }, { 19, 20 },
> + { 20, 21 }, { 21, 22 }, { 22, 23 }, { 23, 24 },
> + { 24, 25 }, { 25, 26 }, { 26, 27 }, { 27, 28 },
> + { 28, 29 }, { 29, 30 }, { 30, 31 }, { 31, 32 },
> + { 0, 0 }
> +};
> +
> +static struct clk_div_table bm1880_div_table_1[] = {
> + { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 4 },
> + { 4, 5 }, { 5, 6 }, { 6, 7 }, { 7, 8 },
> + { 8, 9 }, { 9, 10 }, { 10, 11 }, { 11, 12 },
> + { 12, 13 }, { 13, 14 }, { 14, 15 }, { 15, 16 },
> + { 16, 17 }, { 17, 18 }, { 18, 19 }, { 19, 20 },
> + { 20, 21 }, { 21, 22 }, { 22, 23 }, { 23, 24 },
> + { 24, 25 }, { 25, 26 }, { 26, 27 }, { 27, 28 },
> + { 28, 29 }, { 29, 30 }, { 30, 31 }, { 31, 32 },
> + { 127, 128 }, { 0, 0 }
> +};
> +
> +static struct clk_div_table bm1880_div_table_2[] = {
> + { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 4 },
> + { 4, 5 }, { 5, 6 }, { 6, 7 }, { 7, 8 },
> + { 8, 9 }, { 9, 10 }, { 10, 11 }, { 11, 12 },
> + { 12, 13 }, { 13, 14 }, { 14, 15 }, { 15, 16 },
> + { 16, 17 }, { 17, 18 }, { 18, 19 }, { 19, 20 },
> + { 20, 21 }, { 21, 22 }, { 22, 23 }, { 23, 24 },
> + { 24, 25 }, { 25, 26 }, { 26, 27 }, { 27, 28 },
> + { 28, 29 }, { 29, 30 }, { 30, 31 }, { 31, 32 },
> + { 127, 128 }, { 255, 256 }, { 0, 0 }
> +};
> +
> +static struct clk_div_table bm1880_div_table_3[] = {
> + { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 4 },
> + { 4, 5 }, { 5, 6 }, { 6, 7 }, { 7, 8 },
> + { 8, 9 }, { 9, 10 }, { 10, 11 }, { 11, 12 },
> + { 12, 13 }, { 13, 14 }, { 14, 15 }, { 15, 16 },
> + { 16, 17 }, { 17, 18 }, { 18, 19 }, { 19, 20 },
> + { 20, 21 }, { 21, 22 }, { 22, 23 }, { 23, 24 },
> + { 24, 25 }, { 25, 26 }, { 26, 27 }, { 27, 28 },
> + { 28, 29 }, { 29, 30 }, { 30, 31 }, { 31, 32 },
> + { 127, 128 }, { 255, 256 }, { 511, 512 }, { 0, 0 }
> +};
> +
> +static struct clk_div_table bm1880_div_table_4[] = {
> + { 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 4 },
> + { 4, 5 }, { 5, 6 }, { 6, 7 }, { 7, 8 },
> + { 8, 9 }, { 9, 10 }, { 10, 11 }, { 11, 12 },
> + { 12, 13 }, { 13, 14 }, { 14, 15 }, { 15, 16 },
> + { 16, 17 }, { 17, 18 }, { 18, 19 }, { 19, 20 },
> + { 20, 21 }, { 21, 22 }, { 22, 23 }, { 23, 24 },
> + { 24, 25 }, { 25, 26 }, { 26, 27 }, { 27, 28 },
> + { 28, 29 }, { 29, 30 }, { 30, 31 }, { 31, 32 },
> + { 127, 128 }, { 255, 256 }, { 511, 512 }, { 65535, 65536 },
> + { 0, 0 }
> +};
> +
> +static const struct bm1880_div_clock bm1880_div_clks[] = {
> + { BM1880_CLK_DIV_0_RV, "clk_div_0_rv", "clk_spll",
> + BM1880_CLK_DIV12, 16, 5, 1, bm1880_div_table_0, CLK_IGNORE_UNUSED },
> + { BM1880_CLK_DIV_1_RV, "clk_div_1_rv", "clk_fpll",
> + BM1880_CLK_DIV13, 16, 5, 1, bm1880_div_table_0, CLK_IGNORE_UNUSED },
> + { BM1880_CLK_DIV_UART_500M, "clk_div_uart_500m", "clk_fpll",
> + BM1880_CLK_DIV15, 16, 7, 3, bm1880_div_table_1, 0 },
> + { BM1880_CLK_DIV_0_AXI1, "clk_div_0_axi1", "clk_mpll",
> + BM1880_CLK_DIV21, 16, 5, 2, bm1880_div_table_0, CLK_IS_CRITICAL },
> + { BM1880_CLK_DIV_1_AXI1, "clk_div_1_axi1", "clk_fpll",
> + BM1880_CLK_DIV22, 16, 5, 3, bm1880_div_table_0, CLK_IS_CRITICAL },
> + { BM1880_CLK_DIV_0_AXI6, "clk_div_0_axi6", "clk_fpll",
> + BM1880_CLK_DIV27, 16, 5, 15, bm1880_div_table_0, CLK_IS_CRITICAL },
> + { BM1880_CLK_DIV_1_AXI6, "clk_div_1_axi6", "clk_mpll",
> + BM1880_CLK_DIV28, 16, 5, 11, bm1880_div_table_0, CLK_IS_CRITICAL },
> + { BM1880_CLK_DIV_12M_USB, "clk_div_12m_usb", "clk_fpll",
> + BM1880_CLK_DIV18, 16, 7, 125, bm1880_div_table_1, 0 },
> +};
> +
> +static struct bm1880_composite_clock bm1880_composite_clks[] = {
> + GATE_MUX(BM1880_CLK_A53, "clk_a53", clk_a53_parents,
> + BM1880_CLK_ENABLE0, 0, BM1880_CLK_SELECT, 0,
> + CLK_IS_CRITICAL),
Please document why CLK_IS_CRITICAL. Maybe CPU clk so must be kept on?
> + GATE_DIV(BM1880_CLK_50M_A53, "clk_50m_a53", "clk_fpll",
> + BM1880_CLK_ENABLE0, 1, BM1880_CLK_DIV0, 16, 5, 30,
> + bm1880_div_table_0, CLK_IS_CRITICAL),
> + GATE_DIV(BM1880_CLK_EFUSE, "clk_efuse", "clk_fpll",
> + BM1880_CLK_ENABLE0, 5, BM1880_CLK_DIV1, 16, 7, 60,
> + bm1880_div_table_1, 0),
> + GATE_DIV(BM1880_CLK_EMMC, "clk_emmc", "clk_fpll",
> + BM1880_CLK_ENABLE0, 8, BM1880_CLK_DIV2, 16, 5, 15,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_100K_EMMC, "clk_100k_emmc", "clk_div_12m_usb",
> + BM1880_CLK_ENABLE0, 9, BM1880_CLK_DIV3, 16, 8, 120,
> + bm1880_div_table_2, 0),
> + GATE_DIV(BM1880_CLK_SD, "clk_sd", "clk_fpll",
> + BM1880_CLK_ENABLE0, 11, BM1880_CLK_DIV4, 16, 5, 15,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_100K_SD, "clk_100k_sd", "clk_div_12m_usb",
> + BM1880_CLK_ENABLE0, 12, BM1880_CLK_DIV5, 16, 8, 120,
> + bm1880_div_table_2, 0),
> + GATE_DIV(BM1880_CLK_500M_ETH0, "clk_500m_eth0", "clk_fpll",
> + BM1880_CLK_ENABLE0, 13, BM1880_CLK_DIV6, 16, 5, 3,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_500M_ETH1, "clk_500m_eth1", "clk_fpll",
> + BM1880_CLK_ENABLE0, 15, BM1880_CLK_DIV7, 16, 5, 3,
> + bm1880_div_table_0, 0),
> + /* Don't gate GPIO clocks as it is not owned by the GPIO driver */
> + GATE_DIV(BM1880_CLK_GPIO_DB, "clk_gpio_db", "clk_div_12m_usb",
> + BM1880_CLK_ENABLE0, 20, BM1880_CLK_DIV8, 16, 16, 120,
> + bm1880_div_table_4, CLK_IGNORE_UNUSED),
> + GATE_DIV(BM1880_CLK_SDMA_AUD, "clk_sdma_aud", "clk_fpll",
> + BM1880_CLK_ENABLE0, 24, BM1880_CLK_DIV9, 16, 7, 61,
> + bm1880_div_table_1, 0),
> + GATE_DIV(BM1880_CLK_JPEG_AXI, "clk_jpeg_axi", "clk_fpll",
> + BM1880_CLK_ENABLE0, 28, BM1880_CLK_DIV10, 16, 5, 4,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_NF, "clk_nf", "clk_fpll",
> + BM1880_CLK_ENABLE0, 31, BM1880_CLK_DIV11, 16, 5, 30,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_TPU_AXI, "clk_tpu_axi", "clk_spll",
> + BM1880_CLK_ENABLE1, 3, BM1880_CLK_DIV14, 16, 5, 1,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_125M_USB, "clk_125m_usb", "clk_fpll",
> + BM1880_CLK_ENABLE1, 9, BM1880_CLK_DIV16, 16, 5, 12,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_33K_USB, "clk_33k_usb", "clk_div_12m_usb",
> + BM1880_CLK_ENABLE1, 10, BM1880_CLK_DIV17, 16, 9, 363,
> + bm1880_div_table_3, 0),
> + GATE_DIV(BM1880_CLK_VIDEO_AXI, "clk_video_axi", "clk_fpll",
> + BM1880_CLK_ENABLE1, 13, BM1880_CLK_DIV19, 16, 5, 4,
> + bm1880_div_table_0, 0),
> + GATE_DIV(BM1880_CLK_VPP_AXI, "clk_vpp_axi", "clk_fpll",
> + BM1880_CLK_ENABLE1, 14, BM1880_CLK_DIV20, 16, 5, 4,
> + bm1880_div_table_0, 0),
> + GATE_MUX(BM1880_CLK_AXI1, "clk_axi1", clk_axi1_parents,
> + BM1880_CLK_ENABLE1, 15, BM1880_CLK_SELECT, 2,
> + CLK_IS_CRITICAL),
> + GATE_DIV(BM1880_CLK_AXI2, "clk_axi2", "clk_fpll",
> + BM1880_CLK_ENABLE1, 17, BM1880_CLK_DIV23, 16, 5, 3,
> + bm1880_div_table_0, CLK_IS_CRITICAL),
> + GATE_DIV(BM1880_CLK_AXI3, "clk_axi3", "clk_mux_rv",
> + BM1880_CLK_ENABLE1, 18, BM1880_CLK_DIV24, 16, 5, 2,
> + bm1880_div_table_0, CLK_IS_CRITICAL),
> + GATE_DIV(BM1880_CLK_AXI4, "clk_axi4", "clk_fpll",
> + BM1880_CLK_ENABLE1, 19, BM1880_CLK_DIV25, 16, 5, 6,
> + bm1880_div_table_0, CLK_IS_CRITICAL),
> + GATE_DIV(BM1880_CLK_AXI5, "clk_axi5", "clk_fpll",
> + BM1880_CLK_ENABLE1, 20, BM1880_CLK_DIV26, 16, 5, 15,
> + bm1880_div_table_0, CLK_IS_CRITICAL),
> +};
> +
> +static unsigned long bm1880_pll_rate_calc(u32 regval, unsigned long parent_rate)
> +{
> + u32 fbdiv, fref, refdiv;
> + u32 postdiv1, postdiv2;
> + unsigned long rate, numerator, denominator;
> +
> + fbdiv = (regval >> 16) & 0xfff;
> + fref = parent_rate;
> + refdiv = regval & 0x1f;
> + postdiv1 = (regval >> 8) & 0x7;
> + postdiv2 = (regval >> 12) & 0x7;
> +
> + numerator = parent_rate * fbdiv;
> + denominator = refdiv * postdiv1 * postdiv2;
> + do_div(numerator, denominator);
> + rate = numerator;
> +
> + return rate;
> +}
> +
> +static unsigned long bm1880_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct bm1880_pll_hw_clock *pll_hw = to_bm1880_pll_clk(hw);
> + unsigned long rate;
> + u32 regval;
> +
> + regval = readl(pll_hw->base + pll_hw->pll.reg);
> + rate = bm1880_pll_rate_calc(regval, parent_rate);
> +
> + return rate;
> +}
> +
> +static const struct clk_ops bm1880_pll_ops = {
> + .recalc_rate = bm1880_pll_recalc_rate,
> +};
> +
> +struct clk *bm1880_clk_register_pll(const struct bm1880_pll_clock *pll_clk,
> + void __iomem *sys_base)
> +{
> + struct bm1880_pll_hw_clock *pll_hw;
> + struct clk_init_data init;
> + struct clk_hw *hw;
> + int err;
> +
> + pll_hw = kzalloc(sizeof(*pll_hw), GFP_KERNEL);
> + if (!pll_hw)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = pll_clk->name;
> + init.ops = &bm1880_pll_ops;
> + init.flags = pll_clk->flags;
> + init.parent_names = &pll_clk->parent;
Can you use the new way of specifying parents instead of using strings
for everything?
> + init.num_parents = 1;
> +
> + pll_hw->hw.init = &init;
> + pll_hw->pll.reg = pll_clk->reg;
> + pll_hw->base = sys_base;
> +
> + hw = &pll_hw->hw;
> + err = clk_hw_register(NULL, hw);
> +
> + if (err) {
> + kfree(pll_hw);
> + return ERR_PTR(err);
> + }
> +
> + return hw->clk;
Can this return the clk_hw pointer instead?
> +}
> +
> +void bm1880_clk_unregister_pll(struct clk *clk)
Should this be static?
> +{
> + struct bm1880_pll_hw_clock *pll_hw;
> + struct clk_hw *hw;
> +
> + hw = __clk_get_hw(clk);
> + if (!hw)
> + return;
> +
> + pll_hw = to_bm1880_pll_clk(hw);
> +
> + clk_unregister(clk);
> + kfree(pll_hw);
> +}
> +
> +int bm1880_clk_register_plls(const struct bm1880_pll_clock *clks,
> + int num_clks, struct bm1880_clock_data *data)
> +{
> + struct clk *clk;
> + void __iomem *pll_base = data->pll_base;
> + int i;
> +
> + for (i = 0; i < num_clks; i++) {
> + const struct bm1880_pll_clock *bm1880_clk = &clks[i];
> +
> + clk = bm1880_clk_register_pll(bm1880_clk, pll_base);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register clock %s\n",
> + __func__, bm1880_clk->name);
> + goto err_clk;
> + }
> +
> + data->clk_data.clks[clks[i].id] = clk;
> + }
> +
> + return 0;
> +
> +err_clk:
> + while (i--)
I guess while (--i) is more idiomatic but this works too.
> + bm1880_clk_unregister_pll(data->clk_data.clks[clks[i].id]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +int bm1880_clk_register_mux(const struct bm1880_mux_clock *clks,
> + int num_clks, struct bm1880_clock_data *data)
> +{
> + struct clk *clk;
> + void __iomem *sys_base = data->sys_base;
> + int i;
> +
> + for (i = 0; i < num_clks; i++) {
> + clk = clk_register_mux(NULL, clks[i].name,
Can you use the clk_hw based APIs for generic type clks?
> + clks[i].parents,
> + clks[i].num_parents,
> + clks[i].flags,
> + sys_base + clks[i].reg,
> + clks[i].shift, 1, 0,
> + &bm1880_clk_lock);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register clock %s\n",
> + __func__, clks[i].name);
> + goto err_clk;
> + }
> +
> + data->clk_data.clks[clks[i].id] = clk;
> + }
> +
> + return 0;
> +
> +err_clk:
> + while (i--)
> + clk_unregister_gate(data->clk_data.clks[clks[i].id]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +static unsigned long bm1880_clk_div_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct bm1880_div_hw_clock *div_hw = to_bm1880_div_clk(hw);
> + struct bm1880_div_clock *div = &div_hw->div;
> + void __iomem *reg_addr = div_hw->base + div->reg;
> + unsigned int val;
> + unsigned long rate;
> +
> + if (!(readl(reg_addr) & BIT(3))) {
> + val = div->initval;
> + } else {
> + val = readl(reg_addr) >> div->shift;
> + val &= clk_div_mask(div->width);
> + }
> +
> + rate = divider_recalc_rate(hw, parent_rate, val, div->table,
> + div->flags, div->width);
> +
> + return rate;
> +}
> +
> +static long bm1880_clk_div_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + struct bm1880_div_hw_clock *div_hw = to_bm1880_div_clk(hw);
> + struct bm1880_div_clock *div = &div_hw->div;
> + void __iomem *reg_addr = div_hw->base + div->reg;
> +
> + if (div->flags & CLK_DIVIDER_READ_ONLY) {
> + u32 val;
> +
> + val = readl(reg_addr) >> div->shift;
> + val &= clk_div_mask(div->width);
> +
> + return divider_ro_round_rate(hw, rate, prate, div->table,
> + div->width, div->flags,
> + val);
> + }
> +
> + return divider_round_rate(hw, rate, prate, div->table,
> + div->width, div->flags);
> +}
> +
> +static int bm1880_clk_div_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct bm1880_div_hw_clock *div_hw = to_bm1880_div_clk(hw);
> + struct bm1880_div_clock *div = &div_hw->div;
> + void __iomem *reg_addr = div_hw->base + div->reg;
> + unsigned long flags = 0;
> + int value;
> + u32 val;
> +
> + value = divider_get_val(rate, parent_rate, div->table,
> + div->width, div_hw->div.flags);
> + if (value < 0)
> + return value;
> +
> + if (div_hw->lock)
> + spin_lock_irqsave(div_hw->lock, flags);
> + else
> + __acquire(div_hw->lock);
> +
> + if (div->flags & CLK_DIVIDER_HIWORD_MASK) {
> + val = clk_div_mask(div->width) << (div_hw->div.shift + 16);
> + } else {
> + val = readl(reg_addr);
> + val &= ~(clk_div_mask(div->width) << div_hw->div.shift);
> + }
> + val |= (u32)value << div->shift;
> + writel(val, reg_addr);
> +
> + if (div_hw->lock)
> + spin_unlock_irqrestore(div_hw->lock, flags);
> + else
> + __release(div_hw->lock);
> +
> + return 0;
> +}
> +
> +const struct clk_ops bm1880_clk_div_ops = {
static?
> + .recalc_rate = bm1880_clk_div_recalc_rate,
> + .round_rate = bm1880_clk_div_round_rate,
> + .set_rate = bm1880_clk_div_set_rate,
> +};
> +
> +struct clk *bm1880_clk_register_div(const struct bm1880_div_clock *div_clk,
> + void __iomem *sys_base)
> +{
> + struct bm1880_div_hw_clock *div_hw;
> + struct clk_init_data init;
> + struct clk_hw *hw;
> + int err;
> +
> + div_hw = kzalloc(sizeof(*div_hw), GFP_KERNEL);
> + if (!div_hw)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = div_clk->name;
> + init.ops = &bm1880_clk_div_ops;
> + init.flags = div_clk->flags;
> + init.parent_names = &div_clk->parent;
> + init.num_parents = 1;
> +
> + div_hw->hw.init = &init;
> + div_hw->div.reg = div_clk->reg;
> + div_hw->div.shift = div_clk->shift;
> + div_hw->div.width = div_clk->width;
> + div_hw->div.initval = div_clk->initval;
> + div_hw->div.table = div_clk->table;
> + div_hw->div.flags = CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO;
> + div_hw->base = sys_base;
> + div_hw->lock = &bm1880_clk_lock;
> +
> + hw = &div_hw->hw;
> + err = clk_hw_register(NULL, hw);
> +
> + if (err) {
> + kfree(div_hw);
> + return ERR_PTR(err);
> + }
> +
> + return hw->clk;
> +}
> +
> +void bm1880_clk_unregister_div(struct clk *clk)
> +{
> + struct bm1880_div_hw_clock *div_hw;
> + struct clk_hw *hw;
> +
> + hw = __clk_get_hw(clk);
> + if (!hw)
> + return;
> +
> + div_hw = to_bm1880_div_clk(hw);
> +
> + clk_unregister(clk);
> + kfree(div_hw);
> +}
> +
> +int bm1880_clk_register_divs(const struct bm1880_div_clock *clks,
> + int num_clks, struct bm1880_clock_data *data)
> +{
> + struct clk *clk;
> + void __iomem *sys_base = data->sys_base;
> + int i;
> +
> + for (i = 0; i < num_clks; i++) {
> + const struct bm1880_div_clock *bm1880_clk = &clks[i];
> +
> + clk = bm1880_clk_register_div(bm1880_clk, sys_base);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register clock %s\n",
> + __func__, bm1880_clk->name);
> + goto err_clk;
> + }
> +
> + data->clk_data.clks[clks[i].id] = clk;
> + }
> +
> + return 0;
> +
> +err_clk:
> + while (i--)
> + bm1880_clk_unregister_div(data->clk_data.clks[clks[i].id]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +int bm1880_clk_register_gate(const struct bm1880_gate_clock *clks,
> + int num_clks, struct bm1880_clock_data *data)
> +{
> + struct clk *clk;
> + void __iomem *sys_base = data->sys_base;
> + int i;
> +
> + for (i = 0; i < num_clks; i++) {
> + clk = clk_register_gate(NULL, clks[i].name,
> + clks[i].parent,
> + clks[i].flags,
> + sys_base + clks[i].gate_reg,
> + clks[i].gate_shift,
> + 0,
> + &bm1880_clk_lock);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register clock %s\n",
> + __func__, clks[i].name);
> + goto err_clk;
> + }
> +
> + data->clk_data.clks[clks[i].id] = clk;
> + }
> +
> + return 0;
> +
> +err_clk:
> + while (i--)
> + clk_unregister_gate(data->clk_data.clks[clks[i].id]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +struct clk *bm1880_clk_register_composite(struct bm1880_composite_clock *clks,
> + void __iomem *sys_base)
> +{
> + struct clk *clk;
> + struct clk_mux *mux = NULL;
> + struct clk_gate *gate = NULL;
> + struct bm1880_div_hw_clock *div_hws = NULL;
> + struct clk_hw *mux_hw = NULL, *gate_hw = NULL, *div_hw = NULL;
> + const struct clk_ops *mux_ops = NULL, *gate_ops = NULL, *div_ops = NULL;
> + const char * const *parent_names;
> + const char *parent;
> + int num_parents;
> + int ret;
> +
> + if (clks->mux_shift >= 0) {
> + mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> + if (!mux)
> + return ERR_PTR(-ENOMEM);
> +
> + mux->reg = sys_base + clks->mux_reg;
> + mux->mask = 1;
> + mux->shift = clks->mux_shift;
> + mux_hw = &mux->hw;
> + mux_ops = &clk_mux_ops;
> + mux->lock = &bm1880_clk_lock;
> +
> + parent_names = clks->parents;
> + num_parents = clks->num_parents;
> + } else {
> + parent = clks->parent;
> + parent_names = &parent;
> + num_parents = 1;
> + }
> +
> + if (clks->gate_shift >= 0) {
> + gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> + if (!gate) {
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + gate->reg = sys_base + clks->gate_reg;
> + gate->bit_idx = clks->gate_shift;
> + gate->lock = &bm1880_clk_lock;
> +
> + gate_hw = &gate->hw;
> + gate_ops = &clk_gate_ops;
> + }
> +
> + if (clks->div_shift >= 0) {
> + div_hws = kzalloc(sizeof(*div_hws), GFP_KERNEL);
> + if (!div_hws) {
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + div_hws->base = sys_base;
> + div_hws->div.reg = clks->div_reg;
> + div_hws->div.shift = clks->div_shift;
> + div_hws->div.width = clks->div_width;
> + div_hws->div.table = clks->table;
> + div_hws->div.initval = clks->div_initval;
> + div_hws->lock = &bm1880_clk_lock;
> + div_hws->div.flags = CLK_DIVIDER_ONE_BASED |
> + CLK_DIVIDER_ALLOW_ZERO;
> +
> + div_hw = &div_hws->hw;
> + div_ops = &bm1880_clk_div_ops;
> + }
> +
> + clk = clk_register_composite(NULL, clks->name, parent_names,
> + num_parents, mux_hw, mux_ops, div_hw,
> + div_ops, gate_hw, gate_ops, (clks->flags));
> +
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + goto err_out;
> + }
> +
> + return clk;
> +
> +err_out:
> + kfree(div_hws);
> + kfree(gate);
> + kfree(mux);
> +
> + return ERR_PTR(ret);
> +}
> +
> +int bm1880_clk_register_composites(struct bm1880_composite_clock *clks,
> + int num_clks, struct bm1880_clock_data *data)
> +{
> + struct clk *clk;
> + void __iomem *sys_base = data->sys_base;
> + int i;
> +
> + for (i = 0; i < num_clks; i++) {
> + struct bm1880_composite_clock *bm1880_clk = &clks[i];
> +
> + clk = bm1880_clk_register_composite(bm1880_clk, sys_base);
> + if (IS_ERR(clk)) {
> + pr_err("%s: failed to register clock %s\n",
> + __func__, bm1880_clk->name);
> + goto err_clk;
> + }
> +
> + data->clk_data.clks[clks[i].id] = clk;
> + }
> +
> + return 0;
> +
> +err_clk:
> + while (i--)
> + clk_unregister_composite(data->clk_data.clks[clks[i].id]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +static void bm1880_clk_init(struct device_node *np)
> +{
> + struct bm1880_clock_data *clk_data;
> + struct clk **clk_table;
> + void __iomem *pll_base, *sys_base;
> + int num_clks;
> +
> + pll_base = of_iomap(np, 0);
> + if (!pll_base) {
> + pr_err("%pOFn: unable to map pll resource", np);
> + of_node_put(np);
> + return;
> + }
> +
> + sys_base = of_iomap(np, 1);
> + if (!sys_base) {
> + pr_err("%pOFn: unable to map sys resource", np);
> + of_node_put(np);
> + return;
> + }
> +
> + clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> + if (!clk_data)
> + return;
> +
> + clk_data->pll_base = pll_base;
> + clk_data->sys_base = sys_base;
> + num_clks = ARRAY_SIZE(bm1880_gate_clks) +
> + ARRAY_SIZE(bm1880_composite_clks);
> +
> + clk_table = kcalloc(num_clks, sizeof(*clk_table), GFP_KERNEL);
> + if (!clk_table)
> + goto err_out;
> +
> + clk_data->clk_data.clks = clk_table;
> + clk_data->clk_data.clk_num = num_clks;
> +
> + /* Register PLL clocks */
> + bm1880_clk_register_plls(bm1880_pll_clks,
> + ARRAY_SIZE(bm1880_pll_clks),
> + clk_data);
> +
> + /* Register Divider clocks */
Please remove these comments, they provide no useful information.
> + bm1880_clk_register_divs(bm1880_div_clks,
> + ARRAY_SIZE(bm1880_div_clks),
> + clk_data);
> +
> + /* Register Mux clocks */
> + bm1880_clk_register_mux(bm1880_mux_clks,
> + ARRAY_SIZE(bm1880_mux_clks),
> + clk_data);
> +
> + /* Register Composite clocks */
> + bm1880_clk_register_composites(bm1880_composite_clks,
> + ARRAY_SIZE(bm1880_composite_clks),
> + clk_data);
> +
> + /* Register Gate clocks */
> + bm1880_clk_register_gate(bm1880_gate_clks,
> + ARRAY_SIZE(bm1880_gate_clks),
> + clk_data);
> +
> + of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data->clk_data);
> +
> + return;
> +
> +err_out:
> + kfree(clk_data);
> +}
> +
> +CLK_OF_DECLARE_DRIVER(bm1880_clk, "bitmain,bm1880-clk", bm1880_clk_init);
Is there a reason why it can't be a platform driver?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox