* [PATCH v2] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Rob Herring @ 2018-05-30 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sh69nelw.fsf@anholt.net>
On Wed, May 30, 2018 at 2:11 PM, Eric Anholt <eric@anholt.net> wrote:
> Rob Herring <robh@kernel.org> writes:
>
>> The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
>> Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
>> DT change which breaks compatibility with older kernels. The AUX irqchip
>> was already rejected for upstream[1] and the DT change would break
>> working systems if the DTB is updated to a newer one. The latter issue
>> was brought to my attention by Alex Graf.
>>
>> The root cause however is a bug in the shared handler. A shared handler
>> must correctly identify it actually handled an interrupt. The handler
>> here was processing data whether interrupts were enabled or not.
>> It would return IRQ_HANDLED if there was any data and not only when
>> there was an actual interrupt pending. The result is that another
>> device's IRQ could cause the SPI's IRQ handler to run and process data
>> when the the SPI driver working in polled mode. Fix this by adding a
>> check in the IRQ handler that the TXEMPTY or IDLE interrupts are enabled
>> and always return IRQ_NONE when they are not.
>
> FWIW, I see v1 already applied in -next.
Sigh, indeed. I thought I had checked that. Though Mark had comments
on the commit msg, so I assumed he wanted changes. The automated
applied emails just get lost in my inbox. It would be nice if they
kept the subject instead of adding 'Applied "...' so gmail would group
them. Of course, it would be nice if gmail could honor threading too.
Rob
^ permalink raw reply
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Andreas Färber @ 2018-05-30 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530204838.22079-1-luc.vanoostenryck@gmail.com>
Hi Luc,
The typo in the subject made me curious...
Am 30.05.2018 um 22:48 schrieb Luc Van Oostenryck:
> By default, sparse assumes a 64bit machine when compiled on x86-64
> and 32bit when compiled on anything else.
>
> This can of course create all sort of problems for the other archs, like
> issuing false warnings ('shift too big (32) for type unsigned long'), or
> worse, failing to emit legitimate warnings.
>
> Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
> to CHECKFLAGS in the main Makefile (and so for all archs).
> Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
> ---
> Makefile | 3 +++
> arch/alpha/Makefile | 2 +-
> arch/arm/Makefile | 2 +-
> arch/arm64/Makefile | 2 +-
> arch/ia64/Makefile | 2 +-
> arch/mips/Makefile | 3 ---
> arch/parisc/Makefile | 2 +-
> arch/sparc/Makefile | 2 +-
> arch/x86/Makefile | 2 +-
> 9 files changed, 10 insertions(+), 10 deletions(-)
What about the architectures not touched by your patch that previously
had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32,
nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa)
You forgot to CC them on this patch.
Have you really checked that all their toolchains support the -m32/-m64
flags you newly introduce for them? Apart from non-biarch architectures,
I'm thinking of 31-bit s390 as a corner case where !64 != 32.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] ASoC: mediatek: export mtk-afe symbols as needed
From: Arnd Bergmann @ 2018-05-30 22:00 UTC (permalink / raw)
To: linux-arm-kernel
The new mt6797-afe driver uses some functions in a common file, which
works for a built-in driver but fails for a loadable module:
ERROR: "mtk_afe_pcm_free" [sound/soc/mediatek/mt6797/snd-soc-mt6797-afe.ko] undefined!
ERROR: "mtk_afe_add_sub_dai_control" [sound/soc/mediatek/mt6797/snd-soc-mt6797-afe.ko] undefined!
ERROR: "mtk_afe_pcm_new" [sound/soc/mediatek/mt6797/snd-soc-mt6797-afe.ko] undefined!
ERROR: "mtk_afe_combine_sub_dai" [sound/soc/mediatek/mt6797/snd-soc-mt6797-afe.ko] undefined!
ERROR: "mtk_afe_pcm_ops" [sound/soc/mediatek/mt6797/snd-soc-mt6797-afe.ko] undefined!
This exports the five symbols above for modules.
Fixes: b3c702f56bf5 ("ASoC: mt6797: combine DAI to register component")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
sound/soc/mediatek/common/mtk-afe-platform-driver.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/soc/mediatek/common/mtk-afe-platform-driver.c b/sound/soc/mediatek/common/mtk-afe-platform-driver.c
index 00618587ef1e..51ec4ff6ed95 100644
--- a/sound/soc/mediatek/common/mtk-afe-platform-driver.c
+++ b/sound/soc/mediatek/common/mtk-afe-platform-driver.c
@@ -57,6 +57,7 @@ int mtk_afe_combine_sub_dai(struct mtk_base_afe *afe)
return 0;
}
+EXPORT_SYMBOL_GPL(mtk_afe_combine_sub_dai);
int mtk_afe_add_sub_dai_control(struct snd_soc_component *component)
{
@@ -90,6 +91,7 @@ int mtk_afe_add_sub_dai_control(struct snd_soc_component *component)
return 0;
}
+EXPORT_SYMBOL_GPL(mtk_afe_add_sub_dai_control);
static snd_pcm_uframes_t mtk_afe_pcm_pointer
(struct snd_pcm_substream *substream)
@@ -130,6 +132,7 @@ const struct snd_pcm_ops mtk_afe_pcm_ops = {
.ioctl = snd_pcm_lib_ioctl,
.pointer = mtk_afe_pcm_pointer,
};
+EXPORT_SYMBOL_GPL(mtk_afe_pcm_ops);
int mtk_afe_pcm_new(struct snd_soc_pcm_runtime *rtd)
{
@@ -143,11 +146,13 @@ int mtk_afe_pcm_new(struct snd_soc_pcm_runtime *rtd)
afe->dev,
size, size);
}
+EXPORT_SYMBOL_GPL(mtk_afe_pcm_new);
void mtk_afe_pcm_free(struct snd_pcm *pcm)
{
snd_pcm_lib_preallocate_free_for_all(pcm);
}
+EXPORT_SYMBOL_GPL(mtk_afe_pcm_free);
const struct snd_soc_component_driver mtk_afe_pcm_platform = {
.name = AFE_PCM_NAME,
--
2.9.0
^ permalink raw reply related
* [PATCH 00/12] introduce support for early platform drivers
From: Rob Herring @ 2018-05-30 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530194032.982.41562@harbor.lan>
On Wed, May 30, 2018 at 2:40 PM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Hi Rob,
>
> Quoting Rob Herring (2018-05-14 06:20:57)
>> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> > 2018-05-11 22:13 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
>> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
>> >>>
>> >>> NOTE: this series applies on top of my recent patches[2] that move the previous
>> >>> implementation of early platform devices to arch/sh.
>> >>>
>> >>> Problem:
>> >>>
>> >>> Certain class of devices, such as timers, certain clock drivers and irq chip
>> >>> drivers need to be probed early in the boot sequence. The currently preferred
>> >>> approach is using one of the OF_DECLARE() macros. This however does not create
>> >>> a platform device which has many drawbacks - such as not being able to use
>> >>> devres routines, dev_ log functions or no way of deferring the init OF function
>> >>> if some other resources are missing.
>> >>
>> >> I skimmed though this and it doesn't look horrible (how's that for
>> >> positive feedback? ;) ). But before going into the details, I think
>> >> first there needs to be agreement this is the right direction.
>> >>
>> >> The question does remain though as to whether this class of devices
>> >> should be platform drivers. They can't be modules. They can't be
>> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
>> >>
>> >
>> > The main (but not the only) advantage for drivers that can both be
>> > platform drivers and OF_DECLARE drivers is that we get a single entry
>> > point and can reuse code without resorting to checking if (!dev). It
>> > results in more consistent code base. Another big advantage is
>> > consolidation of device tree and machine code for SoC drivers used in
>> > different boards of which some are still using board files and others
>> > are defined in DT (see: DaVinci).
>> >
>> >> I assume that the clock maintainers had some reason to move clocks to
>> >> be platform drivers. It's just not clear to me what that was.
>> >>
>> >>> For drivers that use both platform drivers and OF_DECLARE the situation is even
>> >>> more complicated as the code needs to take into account that there can possibly
>> >>> be no struct device present. For a specific use case that we're having problems
>> >>> with, please refer to the recent DaVinci common-clock conversion patches and
>> >>> the nasty workaround that this problem implies[3].
>> >>
>> >> So devm_kzalloc will work with this solution? Why did we need
>> >> devm_kzalloc in the first place? The clocks can never be removed and
>> >> cleaning up on error paths is kind of pointless. The system would be
>> >> hosed, right?
>> >>
>> >
>> > It depends - not all clocks are necessary for system to boot.
>>
>> That doesn't matter. You have a single driver for all/most of the
>> clocks, so the driver can't be removed.
>
> -ECANOFWORMS
>
> A couple of quick rebuttals, but I imagine we're going to disagree on
> the platform_driver thing as a matter of taste no matter what...
It's really more should the clocksource, clockevents and primary
interrupt controller be drivers. Let's get agreement on that first. If
yes, then it probably does make sense that their dependencies are
drivers too. If not, then making only the dependencies drivers doesn't
seem right to me.
> 1) There should be multiple clk drivers in a properly modeled system.
> Some folks still incorrectly put all clocks in a system into a single
> driver because That's How We Used To Do It, and some systems (simpler
> ones) really only have a single clock generator IP block.
>
> Excepting those two reasons above, we really should have separate
> drivers for clocks controlled by the PMIC, for the (one or more) clock
> generator blocks inside of the AP/SoC, and then even more for the
> drivers that map to IP blocks that have their own clock gens.
I agree those should be separate entities at least. But for a given
h/w block, if you already have to use OF_DECLARE, why would you try to
split that into OF_DECLARE and a driver? what advantage does putting
non-boot essential clocks in a driver or transitioning to a driver get
you?
And I've seen PMIC clocks could be inputs to the SoC's clock
controller(s), so the dependencies get more complicated. Then does the
PMIC driver and its dependencies need to be early drivers too?
> Good examples of the latter are display controllers that generate their
> own PLL and pixel clock. Or MMC controllers that have a
> runtime-programmable clock divider. Examples of these are merged into
> mainline.
But those are drivers of types other than a clock controller that
happen to register some clocks as well. I wasn't saying these cases
can't or shouldn't be part of the driver model. Look at irqchips. We
have some that use the driver model (e.g. every GPIO driver) and some
that don't because there's no need (e.g. GIC).
> 2) Stephen and I wanted clock drivers to actually be represented in the
> driver model. There were these gigantic clock drivers that exclusively
> used CLK_OF_DECLARE and they just sort of floated out there in the
> ether... no representation in sysfs, no struct device to map onto a
> clock controller struct, etc.
>
> I'd be happy to hear why you think that platform_driver is a bad fit for
> a device driver that generally manages memory-mapped system resources
> that are part of the system glue and not really tied to a specific bus.
> Sounds like a good fit to me.
>
> If platform_driver doesn't handle the early boot thing well, that tells
> me that we have a problem to solve in platform_driver, not in the clk
> subsystem or drivers.
Doing things earlier is not the only way to solve the problems.
Perhaps we need to figure out how to start things later. Maybe it's
not feasible here, I don't know.
> 3) Lots of clock controllers should be loadable modules. E.g. i2c clock
> expanders, potentially external PMIC-related drivers, external audio
> codecs, etc.
>
> Again, repeating my point #1 above, just because many platforms have a
> monolithic clock driver does not mean that this is the Right Way to do
> it.
And in those cases, I completely agree they should be part of a driver.
Rob
^ permalink raw reply
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Rob Landley @ 2018-05-30 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d47b72cc-9209-a190-38b3-969870e1bf26@suse.de>
On 05/30/2018 05:00 PM, Andreas F?rber wrote:
> What about the architectures not touched by your patch that previously
> had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32,
> nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa)
>
> You forgot to CC them on this patch.
A) He cc'd arch/sh on the previous patch earlier today, to which I replied:
https://marc.info/?l=linux-sh&m=152769132515226&w=2
B) Every change to common infrastructure should cc: every arch? Really? So like
filesystem changes and stuff to?
> Have you really checked that all their toolchains support the -m32/-m64
> flags you newly introduce for them? Apart from non-biarch architectures,
> I'm thinking of 31-bit s390 as a corner case where !64 != 32.
1) Last I heard Linux implements lp64:
http://www.unix.org/whitepapers/64bit.html
2) it's unlikely to be worse than it was before the patch,
3) last I checked https://github.com/landley/mkroot boots to an s390 shell
prompt under qemu, although I haven't tried building with this patch. (And you
may still need to add HOST_EXTRA='lex yacc bison flex' to the command line
unless they've re-added the _shipped versions like the old kconfig had...) Point
is, shouldn't be too hard to test it. Presumably that's why we have an -rc1 and
then 6 more -rc versions each release...
Rob
^ permalink raw reply
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Luc Van Oostenryck @ 2018-05-30 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d47b72cc-9209-a190-38b3-969870e1bf26@suse.de>
On Thu, May 31, 2018 at 12:00 AM, Andreas F?rber <afaerber@suse.de> wrote:
> Hi Luc,
>
> The typo in the subject made me curious...
>
> Am 30.05.2018 um 22:48 schrieb Luc Van Oostenryck:
>> By default, sparse assumes a 64bit machine when compiled on x86-64
>> and 32bit when compiled on anything else.
>>
>> This can of course create all sort of problems for the other archs, like
>> issuing false warnings ('shift too big (32) for type unsigned long'), or
>> worse, failing to emit legitimate warnings.
>>
>> Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
>> to CHECKFLAGS in the main Makefile (and so for all archs).
>> Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
>>
>> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
>> ---
>> Makefile | 3 +++
>> arch/alpha/Makefile | 2 +-
>> arch/arm/Makefile | 2 +-
>> arch/arm64/Makefile | 2 +-
>> arch/ia64/Makefile | 2 +-
>> arch/mips/Makefile | 3 ---
>> arch/parisc/Makefile | 2 +-
>> arch/sparc/Makefile | 2 +-
>> arch/x86/Makefile | 2 +-
>> 9 files changed, 10 insertions(+), 10 deletions(-)
>
> What about the architectures not touched by your patch that previously
> had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32,
> nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa)
As explained in the patch, by default sparse uses -m64 if compiled on x86-64
and 32bit on everything else (well, more recent versions use -m64 if
compiled on any 64 bit machine). I think that most ppc devs use a ppc
machine and so ppc was most probably fine (at least ppc64) but I suspect
that most of these others archs either had never sparse used on them
or had a lot of wrong warnings. IOW, it was maybe OK but most probably
incorrect for them and now it is OK.
> You forgot to CC them on this patch.
I didn't thought/knew it was needed and the CC list is already
quite long but, if needed, no problem for me.
> Have you really checked that all their toolchains support the -m32/-m64
> flags you newly introduce for them? Apart from non-biarch architectures,
> I'm thinking of 31-bit s390 as a corner case where !64 != 32.
Hmm, there is no change to anything I call 'toolchain related', like
compiler and linker. The only change is sparse (or any other checker)
receiving now a correct and explicit -m32 or -m64.
For s390, as far as I know:
1) it has CONFIG_64BIT unconditionally definee (because the old 31bit
is no more supported, now everything is s390x only).
2) even if the *address space* was only 31 bit, I'm very sure
that sizeof(long) and sizeof(void*) was 4 on these machine
hence -m32 would have been correct.
Best regards,
-- Luc
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: David Collins @ 2018-05-30 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WL9enzYCoSx0fT_ny40ciLJU-hhS9joJ6nySXvWPqAxQ@mail.gmail.com>
Hello Mark and Doug,
On 05/30/2018 09:24 AM, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:20 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Wed, May 30, 2018 at 09:12:25AM -0700, Doug Anderson wrote:
>>> On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
>>
>>>> No, I'm saying that I don't know why that property exists at all. This
>>>> sounds like it's intended to be the amount of current the regulator can
>>>> deliver in each mode which is normally a design property of the silicon.
>>
>>> Ah, got it. So the whole point here is to be able to implement either
>>> the function "set_load" or the function "get_optimum_mode". We need
>>> some sort of table to convert from current to mode. That's what this
>>> table does.
>>
>> We do need that table, my expectation would be that this table would be
>> in the driver as it's not something I'd expect to vary between different
>> systems but rather be a property of the silicon design. No sense in
>> every single board having to copy it in.
>
> Ah, got it! I'd be OK with it being hardcoded in the driver.
>
> At one point I think David was making the argument that some boards
> have different noise needs for the rails and thus you might want to
> change modes at different currents. I don't know if this is realistic
> but I believe it was part of his original argument for why this needed
> to be specified. If we can hardcode this in the driver I'm fine with
> it... That would actually solve many of my objections too...
The DRMS modes to use and max allowed current per mode need to be
specified at the board level in device tree instead of hard-coded per
regulator type in the driver. There are at least two use cases driving
this need: LDOs shared between RPMh client processors and SMPSes requiring
PWM mode in certain circumstances.
For LDOs the maximum low power mode (LPM) current is typically 10 mA or 30
mA (depending upon subtype) per hardware documentation. Unfortunately,
sharing control of regulators with other processors adds some subtlety to
the LPM current limit that should actually be applied at runtime.
Consider the case of a regulator with physical 10 mA LPM max current. Say
that modem and application processors each have a load on the regulator
that draws 9 mA. If they each respect the 10 mA limit, then they'd each
vote for LPM. The VRM block in RPMh hardware will aggregate these requests
together using a max function which will result in the regulator being set
to LPM, even though the total load is 18 mA (which would require high
power mode (HPM)). To get around this corner case, a LPM max current of 1
uA can be used for all LDO supplies that have non-application processor
consumers. Thus, any non-zero regulator_set_load() current request will
result in setting the regulator to HPM (which is always safe).
The second situation that needs board-level DRMS mode and current limit
specification is SMPS regulator AUTO mode to PWM (HPM) mode switching.
SMPS regulators should theoretically always be able to operate in AUTO
mode as it switches automatically between PWM mode (which can provide the
maximum current) and PFM mode (which supports lower current but has higher
efficiency). However, there may be board/system issues that require
switching to PWM mode for certain use cases as it has better load
regulation (i.e. no PFM ripple for lower loads) and supports more
aggressive load current steps (i.e. greater A/ns).
If a Linux consumer requires the ability to force a given SMPS regulator
from AUTO mode into PWM mode and that SMPS is shared by other Linux
consumers (which may be the case, but at least must be guaranteed to work
architecturally), then regulator_set_load() is the only option since it
provides aggregation, where as regulator_set_mode() does not.
regulator_set_load() can be utilized in this case by specifying AUTO mode
and PWM mode as drms modes and specifying some particular AUTO mode
maximum current (that is known by the consumer) in device tree. The
consumer can then call regulator_set_load() with the imposed AUTO mode
limit + delta when PWM mode is required and a lower value when AUTO mode
is sufficient.
Note that I previously mentioned the need for board-level drms mode and
current limit specification in [1].
Take care,
David
[1]: https://lkml.org/lkml/2018/3/22/802
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Stephen Boyd @ 2018-05-30 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527266717-8406-3-git-send-email-ray.jui@broadcom.com>
Subject is missing an 's' on stringray?
Quoting Ray Jui (2018-05-25 09:45:16)
> Update and add Stingray clock definitions and tables so they match the
> binding document and the latest ASIC datasheet
>
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Otherwise it looks ok, but maybe Pramod should be the author?
^ permalink raw reply
* [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
From: David Collins @ 2018-05-30 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WF+onhAAWrbmwcHiWyCjuZ=6vvnhodUsia=Ps-da6_4A@mail.gmail.com>
Hello Doug,
On 05/29/2018 10:32 PM, Doug Anderson wrote:
> On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
>> + * @ever_enabled: Boolean indicating that the regulator has been
>> + * explicitly enabled at least once. Voltage
>> + * requests should be cached when this flag is not
>> + * set.
>
> Do you really need this extra boolean? Can't you just check if
> "enabled" is still "-EINVAL"? If it is then you don't pass the
> voltage along.
>
> ...this would mean that you'd also need to send the voltage vote when
> the regulator core tries to disable unused regulators at the end of
> bootup, but that should be OK right? If we never touched a regulator
> anywhere at probe time and we're about to vote to disable it, we know
> there's nobody requiring it to still be on. We can vote for the
> voltage now without fear of messing up a vote that the BIOS left in
> place.
>
> In theory this should also allow you to assert your vote about the
> voltage of a regulator that has never been enabled, which (if I
> understand correctly) you consider to be a feature.
Removing 'ever_enabled' and caching the voltage when 'enabled == -EINVAL'
seems workable. I'm a little concerned about this resulting in voltage =
regulator-min-microvolt requests being sent for all regulators that are
not explicitly enabled by Linux consumers before late_initcall_sync().
Theoretically all of the boot loader hand-off cases should be taken care
of by this point so it should be safe.
I'll make this change.
Take care,
David
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] kbuild: add machine size to CHEKCFLAGS
From: Randy Dunlap @ 2018-05-31 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMHZB6GXVPvr1uwbemuxqPPtNzYT7jeVokR6q9tz2mS_=TG6vA@mail.gmail.com>
On 05/30/2018 04:06 PM, Luc Van Oostenryck wrote:
> On Thu, May 31, 2018 at 12:00 AM, Andreas F?rber <afaerber@suse.de> wrote:
>> Hi Luc,
>>
>> The typo in the subject made me curious...
>>
>> Am 30.05.2018 um 22:48 schrieb Luc Van Oostenryck:
>>> By default, sparse assumes a 64bit machine when compiled on x86-64
>>> and 32bit when compiled on anything else.
>>>
>>> This can of course create all sort of problems for the other archs, like
>>> issuing false warnings ('shift too big (32) for type unsigned long'), or
>>> worse, failing to emit legitimate warnings.
>>>
>>> Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
>>> to CHECKFLAGS in the main Makefile (and so for all archs).
>>> Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.
>>>
>>> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
>>> ---
>>> Makefile | 3 +++
>>> arch/alpha/Makefile | 2 +-
>>> arch/arm/Makefile | 2 +-
>>> arch/arm64/Makefile | 2 +-
>>> arch/ia64/Makefile | 2 +-
>>> arch/mips/Makefile | 3 ---
>>> arch/parisc/Makefile | 2 +-
>>> arch/sparc/Makefile | 2 +-
>>> arch/x86/Makefile | 2 +-
>>> 9 files changed, 10 insertions(+), 10 deletions(-)
>>
>> What about the architectures not touched by your patch that previously
>> had no -m32/-m64? (arc, c6x, h8300, hexagon, m68k, microblaze, nds32,
>> nios2, openrisc, powerpc, riscv, s390, sh, unicore32, xtensa)
>
> As explained in the patch, by default sparse uses -m64 if compiled on x86-64
> and 32bit on everything else (well, more recent versions use -m64 if
> compiled on any 64 bit machine). I think that most ppc devs use a ppc
> machine and so ppc was most probably fine (at least ppc64) but I suspect
> that most of these others archs either had never sparse used on them
> or had a lot of wrong warnings. IOW, it was maybe OK but most probably
> incorrect for them and now it is OK.
>
>> You forgot to CC them on this patch.
>
> I didn't thought/knew it was needed and the CC list is already
> quite long but, if needed, no problem for me.
Ideally, adding linux-arch at vger.kernel.org would be sufficient, but
sadly I have doubts about that.
>> Have you really checked that all their toolchains support the -m32/-m64
>> flags you newly introduce for them? Apart from non-biarch architectures,
>> I'm thinking of 31-bit s390 as a corner case where !64 != 32.
>
> Hmm, there is no change to anything I call 'toolchain related', like
> compiler and linker. The only change is sparse (or any other checker)
> receiving now a correct and explicit -m32 or -m64.
>
> For s390, as far as I know:
> 1) it has CONFIG_64BIT unconditionally definee (because the old 31bit
> is no more supported, now everything is s390x only).
> 2) even if the *address space* was only 31 bit, I'm very sure
> that sizeof(long) and sizeof(void*) was 4 on these machine
> hence -m32 would have been correct.
--
~Randy
^ permalink raw reply
* [PATCH v10 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
From: Rob Herring @ 2018-05-31 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525091712.37227-3-liwei213@huawei.com>
On Fri, May 25, 2018 at 05:17:09PM +0800, Li Wei wrote:
> add ufs node document for Hisilicon.
>
> Signed-off-by: Li Wei <liwei213@huawei.com>
> ---
> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 41 ++++++++++++++++++++++
> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 ++++--
> 2 files changed, 48 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: David Collins @ 2018-05-31 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530163343.GV6920@sirena.org.uk>
Hello Mark,
On 05/30/2018 09:33 AM, Mark Brown wrote:
> On Tue, May 22, 2018 at 07:43:16PM -0700, David Collins wrote:
>> This patch series adds a driver and device tree binding documentation for
>> PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
>> Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
>
> So, this is a very big driver and obviously it being RPM based it
> doesn't look like other regulators which is causing problems, especially
> when coupled with the desire to implement a bunch of more exotic
> features like the mode setting. I think this review is going to go a
> lot more smoothly if you split this up into a base driver with just
> normal, standard stuff that doesn't add too many custom properties or
> unusual ways of working and then a series of patches on top of that
> adding things like the mode adjustment and interaction with other RPM
> clients.
>
> We've got other RPM based regulators in tree already so the baseline bit
> shouldn't be too hard, that'll make the rest of the patches much smaller
> and easier to review and mean that the bits that are simpler and easier
> to cope with don't need to be reposted.
I'll split up the patches so that reviewing is easier. For the base
patch, would you prefer that I remove *all* mode support (handled by
generic regulator framework DT properties) or only remove the special
purpose drms mode handling support (i.e. qcom,regulator-drms-modes and
qcom,drms-mode-max-microamps)?
Thanks,
David
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 1/2] dt-bindings: pinctrl: qcom: add gpio-ranges, gpio-reserved-ranges
From: Rob Herring @ 2018-05-31 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dbaadee4bb22638a2c2e6433e8d1740884ecfd9.1527505307.git.chunkeey@gmail.com>
On Mon, May 28, 2018 at 01:06:01PM +0200, Christian Lamparter wrote:
> This patch adds the gpio-ranges and gpio-reserved-ranges property
> definitions to the binding text files supported by the pinctrl-msm
> driver framework.
>
> gpio-ranges:
> For DT-based platforms the pinctrl-msm framework currently relies
> on the deprecated-for-DT gpiochip_add_pin_range() function to add
> the range of GPIOs to be handled by the pin controller. Due to
> interactions within gpiolib code, this causes the pinctrl-msm
> driver to bail out (-517) during boot when a gpio-hog is declared.
> This can be fatal and cause the system to not boot or reset
> (for a detailed explanation and call-trace, refer to patch:
> "pinctrl: msm: fix gpio-hog related boot issues" in this series).
>
> gpio-reserved-ranges:
> The binding has been added as a precaution since the TrustZone
> firmware (aka QSEE), which is running as the hypervisor, might
> have reserved certain, but undisclosed pins. Hence reading or
> writing to the registers for those pins will cause an
> XPU violation and this subsequently crashes the kernel.
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt | 6 ++++++
> .../devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 6 ++++++
> .../devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt | 6 ++++++
> .../devicetree/bindings/pinctrl/qcom,ipq8074-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,mdm9615-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,msm8660-pinctrl.txt | 6 ++++++
> .../devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt | 6 ++++++
> .../devicetree/bindings/pinctrl/qcom,msm8994-pinctrl.txt | 9 +++++++++
> .../devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt | 9 +++++++++
> 12 files changed, 93 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Ray Jui @ 2018-05-31 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152772366322.144038.12289577935853704907@swboyd.mtv.corp.google.com>
Hi Stephen,
On 5/30/2018 4:41 PM, Stephen Boyd wrote:
> Subject is missing an 's' on stringray?
>
Yes, will fix this.
> Quoting Ray Jui (2018-05-25 09:45:16)
>> Update and add Stingray clock definitions and tables so they match the
>> binding document and the latest ASIC datasheet
>>
>> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>
> Otherwise it looks ok, but maybe Pramod should be the author?
>
Will fix this for all commits in this series.
I'll fix the above and send out v2.
Thanks,
Ray
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-31 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <75088820-f20d-32ac-780a-5e7dacdf20ff@codeaurora.org>
Hi,
On Wed, May 30, 2018 at 4:39 PM, David Collins <collinsd@codeaurora.org> wrote:
> Consider the case of a regulator with physical 10 mA LPM max current. Say
> that modem and application processors each have a load on the regulator
> that draws 9 mA. If they each respect the 10 mA limit, then they'd each
> vote for LPM. The VRM block in RPMh hardware will aggregate these requests
> together using a max function which will result in the regulator being set
> to LPM, even though the total load is 18 mA (which would require high
> power mode (HPM)). To get around this corner case, a LPM max current of 1
> uA can be used for all LDO supplies that have non-application processor
> consumers. Thus, any non-zero regulator_set_load() current request will
> result in setting the regulator to HPM (which is always safe).
Is there any plan to change the way this works for future versions of RPMh?
> The second situation that needs board-level DRMS mode and current limit
> specification is SMPS regulator AUTO mode to PWM (HPM) mode switching.
> SMPS regulators should theoretically always be able to operate in AUTO
> mode as it switches automatically between PWM mode (which can provide the
> maximum current) and PFM mode (which supports lower current but has higher
> efficiency). However, there may be board/system issues that require
> switching to PWM mode for certain use cases as it has better load
> regulation (i.e. no PFM ripple for lower loads) and supports more
> aggressive load current steps (i.e. greater A/ns).
>
> If a Linux consumer requires the ability to force a given SMPS regulator
> from AUTO mode into PWM mode and that SMPS is shared by other Linux
> consumers (which may be the case, but at least must be guaranteed to work
> architecturally), then regulator_set_load() is the only option since it
> provides aggregation, where as regulator_set_mode() does not.
> regulator_set_load() can be utilized in this case by specifying AUTO mode
> and PWM mode as drms modes and specifying some particular AUTO mode
> maximum current (that is known by the consumer) in device tree. The
> consumer can then call regulator_set_load() with the imposed AUTO mode
> limit + delta when PWM mode is required and a lower value when AUTO mode
> is sufficient.
Mark: I'm leaving this firmly in your hands. I can see David's points
here. I could even believe that some of this stuff could be board
specific where one board might have slightly different capacitors or
they might be placed differently and might need a higher power mode to
keep the signal clean.
-Doug
^ permalink raw reply
* [PATCH v2 0/3] Update Broadcom Stingray clock entries
From: Ray Jui @ 2018-05-31 0:36 UTC (permalink / raw)
To: linux-arm-kernel
This patch series updates Broadcom Stingray clock entries so they match the
latest ASIC datasheet
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sr-clk-v2
Changes since v1:
- Fix patch author to Pramod Kumar on all 3 patches
- Fix patch subject spelling error on patch 2/3
Pramod Kumar (3):
dt-bindings: clk: Update Stingray binding doc
clk: bcm: Update and add Stingray clock entries
arm64: dts: Update Stingray clock DT nodes
.../bindings/clock/brcm,iproc-clocks.txt | 26 ++--
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26 ++--
drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++---
include/dt-bindings/clock/bcm-sr.h | 24 ++--
4 files changed, 170 insertions(+), 41 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: clk: Update Stingray binding doc
From: Ray Jui @ 2018-05-31 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527726980-11723-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update Stingray clock binding document to add additional clock entries
with names matching the latest ASIC datasheet. Also modify a few existing
entries to make their naming more consistent with the rest of the entries
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../bindings/clock/brcm,iproc-clocks.txt | 26 ++++++++++++----------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
index f8e4a93..ab730ea 100644
--- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -276,36 +276,38 @@ These clock IDs are defined in:
clk_ts_500_ref genpll2 2 BCM_SR_GENPLL2_TS_500_REF_CLK
clk_125_nitro genpll2 3 BCM_SR_GENPLL2_125_NITRO_CLK
clk_chimp genpll2 4 BCM_SR_GENPLL2_CHIMP_CLK
- clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH
+ clk_nic_flash genpll2 5 BCM_SR_GENPLL2_NIC_FLASH_CLK
+ clk_fs genpll2 6 BCM_SR_GENPLL2_FS_CLK
genpll3 crystal 0 BCM_SR_GENPLL3
clk_hsls genpll3 1 BCM_SR_GENPLL3_HSLS_CLK
clk_sdio genpll3 2 BCM_SR_GENPLL3_SDIO_CLK
genpll4 crystal 0 BCM_SR_GENPLL4
- ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK
+ clk_ccn genpll4 1 BCM_SR_GENPLL4_CCN_CLK
clk_tpiu_pll genpll4 2 BCM_SR_GENPLL4_TPIU_PLL_CLK
- noc_clk genpll4 3 BCM_SR_GENPLL4_NOC_CLK
+ clk_noc genpll4 3 BCM_SR_GENPLL4_NOC_CLK
clk_chclk_fs4 genpll4 4 BCM_SR_GENPLL4_CHCLK_FS4_CLK
clk_bridge_fscpu genpll4 5 BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK
-
genpll5 crystal 0 BCM_SR_GENPLL5
- fs4_hf_clk genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK
- crypto_ae_clk genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK
- raid_ae_clk genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK
+ clk_fs4_hf genpll5 1 BCM_SR_GENPLL5_FS4_HF_CLK
+ clk_crypto_ae genpll5 2 BCM_SR_GENPLL5_CRYPTO_AE_CLK
+ clk_raid_ae genpll5 3 BCM_SR_GENPLL5_RAID_AE_CLK
genpll6 crystal 0 BCM_SR_GENPLL6
- 48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK
+ clk_48_usb genpll6 1 BCM_SR_GENPLL6_48_USB_CLK
lcpll0 crystal 0 BCM_SR_LCPLL0
clk_sata_refp lcpll0 1 BCM_SR_LCPLL0_SATA_REFP_CLK
clk_sata_refn lcpll0 2 BCM_SR_LCPLL0_SATA_REFN_CLK
- clk_usb_ref lcpll0 3 BCM_SR_LCPLL0_USB_REF_CLK
- sata_refpn lcpll0 3 BCM_SR_LCPLL0_SATA_REFPN_CLK
+ clk_sata_350 lcpll0 3 BCM_SR_LCPLL0_SATA_350_CLK
+ clk_sata_500 lcpll0 4 BCM_SR_LCPLL0_SATA_500_CLK
lcpll1 crystal 0 BCM_SR_LCPLL1
- wan lcpll1 1 BCM_SR_LCPLL0_WAN_CLK
+ clk_wan lcpll1 1 BCM_SR_LCPLL1_WAN_CLK
+ clk_usb_ref lcpll1 2 BCM_SR_LCPLL1_USB_REF_CLK
+ clk_crmu_ts lcpll1 3 BCM_SR_LCPLL1_CRMU_TS_CLK
lcpll_pcie crystal 0 BCM_SR_LCPLL_PCIE
- pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK
+ clk_pcie_phy_ref lcpll1 1 BCM_SR_LCPLL_PCIE_PHY_REF_CLK
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/3] clk: bcm: Update and add Stingray clock entries
From: Ray Jui @ 2018-05-31 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527726980-11723-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update and add Stingray clock definitions and tables so they match the
binding document and the latest ASIC datasheet
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++++++++++++++++-----
include/dt-bindings/clock/bcm-sr.h | 24 +++++--
2 files changed, 137 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c
index adc74f4..7b9efc0 100644
--- a/drivers/clk/bcm/clk-sr.c
+++ b/drivers/clk/bcm/clk-sr.c
@@ -56,8 +56,8 @@ static const struct iproc_pll_ctrl sr_genpll0 = {
};
static const struct iproc_clk_ctrl sr_genpll0_clk[] = {
- [BCM_SR_GENPLL0_SATA_CLK] = {
- .channel = BCM_SR_GENPLL0_SATA_CLK,
+ [BCM_SR_GENPLL0_125M_CLK] = {
+ .channel = BCM_SR_GENPLL0_125M_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
@@ -102,6 +102,65 @@ static int sr_genpll0_clk_init(struct platform_device *pdev)
return 0;
}
+static const struct iproc_pll_ctrl sr_genpll2 = {
+ .flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC |
+ IPROC_CLK_PLL_NEEDS_SW_CFG,
+ .aon = AON_VAL(0x0, 1, 13, 12),
+ .reset = RESET_VAL(0x0, 12, 11),
+ .dig_filter = DF_VAL(0x0, 4, 3, 0, 4, 7, 3),
+ .sw_ctrl = SW_CTRL_VAL(0x10, 31),
+ .ndiv_int = REG_VAL(0x10, 20, 10),
+ .ndiv_frac = REG_VAL(0x10, 0, 20),
+ .pdiv = REG_VAL(0x14, 0, 4),
+ .status = REG_VAL(0x30, 12, 1),
+};
+
+static const struct iproc_clk_ctrl sr_genpll2_clk[] = {
+ [BCM_SR_GENPLL2_NIC_CLK] = {
+ .channel = BCM_SR_GENPLL2_NIC_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 6, 0, 12),
+ .mdiv = REG_VAL(0x18, 0, 9),
+ },
+ [BCM_SR_GENPLL2_TS_500_CLK] = {
+ .channel = BCM_SR_GENPLL2_TS_500_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 7, 1, 13),
+ .mdiv = REG_VAL(0x18, 10, 9),
+ },
+ [BCM_SR_GENPLL2_125_NITRO_CLK] = {
+ .channel = BCM_SR_GENPLL2_125_NITRO_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
+ [BCM_SR_GENPLL2_CHIMP_CLK] = {
+ .channel = BCM_SR_GENPLL2_CHIMP_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 9, 3, 15),
+ .mdiv = REG_VAL(0x1c, 0, 9),
+ },
+ [BCM_SR_GENPLL2_NIC_FLASH_CLK] = {
+ .channel = BCM_SR_GENPLL2_NIC_FLASH_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 10, 4, 16),
+ .mdiv = REG_VAL(0x1c, 10, 9),
+ },
+ [BCM_SR_GENPLL2_FS4_CLK] = {
+ .channel = BCM_SR_GENPLL2_FS4_CLK,
+ .enable = ENABLE_VAL(0x4, 11, 5, 17),
+ .mdiv = REG_VAL(0x1c, 20, 9),
+ },
+};
+
+static int sr_genpll2_clk_init(struct platform_device *pdev)
+{
+ iproc_pll_clk_setup(pdev->dev.of_node,
+ &sr_genpll2, NULL, 0, sr_genpll2_clk,
+ ARRAY_SIZE(sr_genpll2_clk));
+ return 0;
+}
+
static const struct iproc_pll_ctrl sr_genpll3 = {
.flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC |
IPROC_CLK_PLL_NEEDS_SW_CFG,
@@ -157,6 +216,30 @@ static const struct iproc_clk_ctrl sr_genpll4_clk[] = {
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
},
+ [BCM_SR_GENPLL4_TPIU_PLL_CLK] = {
+ .channel = BCM_SR_GENPLL4_TPIU_PLL_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 7, 1, 13),
+ .mdiv = REG_VAL(0x18, 10, 9),
+ },
+ [BCM_SR_GENPLL4_NOC_CLK] = {
+ .channel = BCM_SR_GENPLL4_NOC_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
+ [BCM_SR_GENPLL4_CHCLK_FS4_CLK] = {
+ .channel = BCM_SR_GENPLL4_CHCLK_FS4_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 9, 3, 15),
+ .mdiv = REG_VAL(0x1c, 0, 9),
+ },
+ [BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK] = {
+ .channel = BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x4, 10, 4, 16),
+ .mdiv = REG_VAL(0x1c, 10, 9),
+ },
};
static int sr_genpll4_clk_init(struct platform_device *pdev)
@@ -181,18 +264,21 @@ static const struct iproc_pll_ctrl sr_genpll5 = {
};
static const struct iproc_clk_ctrl sr_genpll5_clk[] = {
- [BCM_SR_GENPLL5_FS_CLK] = {
- .channel = BCM_SR_GENPLL5_FS_CLK,
- .flags = IPROC_CLK_AON,
+ [BCM_SR_GENPLL5_FS4_HF_CLK] = {
+ .channel = BCM_SR_GENPLL5_FS4_HF_CLK,
.enable = ENABLE_VAL(0x4, 6, 0, 12),
.mdiv = REG_VAL(0x18, 0, 9),
},
- [BCM_SR_GENPLL5_SPU_CLK] = {
- .channel = BCM_SR_GENPLL5_SPU_CLK,
- .flags = IPROC_CLK_AON,
- .enable = ENABLE_VAL(0x4, 6, 0, 12),
+ [BCM_SR_GENPLL5_CRYPTO_AE_CLK] = {
+ .channel = BCM_SR_GENPLL5_CRYPTO_AE_CLK,
+ .enable = ENABLE_VAL(0x4, 7, 1, 12),
.mdiv = REG_VAL(0x18, 10, 9),
},
+ [BCM_SR_GENPLL5_RAID_AE_CLK] = {
+ .channel = BCM_SR_GENPLL5_RAID_AE_CLK,
+ .enable = ENABLE_VAL(0x4, 8, 2, 14),
+ .mdiv = REG_VAL(0x18, 20, 9),
+ },
};
static int sr_genpll5_clk_init(struct platform_device *pdev)
@@ -214,24 +300,30 @@ static const struct iproc_pll_ctrl sr_lcpll0 = {
};
static const struct iproc_clk_ctrl sr_lcpll0_clk[] = {
- [BCM_SR_LCPLL0_SATA_REF_CLK] = {
- .channel = BCM_SR_LCPLL0_SATA_REF_CLK,
+ [BCM_SR_LCPLL0_SATA_REFP_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_REFP_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 7, 1, 13),
.mdiv = REG_VAL(0x14, 0, 9),
},
- [BCM_SR_LCPLL0_USB_REF_CLK] = {
- .channel = BCM_SR_LCPLL0_USB_REF_CLK,
+ [BCM_SR_LCPLL0_SATA_REFN_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_REFN_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 8, 2, 14),
.mdiv = REG_VAL(0x14, 10, 9),
},
- [BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
- .channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
+ [BCM_SR_LCPLL0_SATA_350_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_350_CLK,
.flags = IPROC_CLK_AON,
.enable = ENABLE_VAL(0x0, 9, 3, 15),
.mdiv = REG_VAL(0x14, 20, 9),
},
+ [BCM_SR_LCPLL0_SATA_500_CLK] = {
+ .channel = BCM_SR_LCPLL0_SATA_500_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 10, 4, 16),
+ .mdiv = REG_VAL(0x18, 0, 9),
+ },
};
static int sr_lcpll0_clk_init(struct platform_device *pdev)
@@ -259,6 +351,18 @@ static const struct iproc_clk_ctrl sr_lcpll1_clk[] = {
.enable = ENABLE_VAL(0x0, 7, 1, 13),
.mdiv = REG_VAL(0x14, 0, 9),
},
+ [BCM_SR_LCPLL1_USB_REF_CLK] = {
+ .channel = BCM_SR_LCPLL1_USB_REF_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 8, 2, 14),
+ .mdiv = REG_VAL(0x14, 10, 9),
+ },
+ [BCM_SR_LCPLL1_CRMU_TS_CLK] = {
+ .channel = BCM_SR_LCPLL1_CRMU_TS_CLK,
+ .flags = IPROC_CLK_AON,
+ .enable = ENABLE_VAL(0x0, 9, 3, 15),
+ .mdiv = REG_VAL(0x14, 20, 9),
+ },
};
static int sr_lcpll1_clk_init(struct platform_device *pdev)
@@ -298,6 +402,7 @@ static int sr_lcpll_pcie_clk_init(struct platform_device *pdev)
static const struct of_device_id sr_clk_dt_ids[] = {
{ .compatible = "brcm,sr-genpll0", .data = sr_genpll0_clk_init },
+ { .compatible = "brcm,sr-genpll2", .data = sr_genpll2_clk_init },
{ .compatible = "brcm,sr-genpll4", .data = sr_genpll4_clk_init },
{ .compatible = "brcm,sr-genpll5", .data = sr_genpll5_clk_init },
{ .compatible = "brcm,sr-lcpll0", .data = sr_lcpll0_clk_init },
diff --git a/include/dt-bindings/clock/bcm-sr.h b/include/dt-bindings/clock/bcm-sr.h
index cff6c6f..419011b 100644
--- a/include/dt-bindings/clock/bcm-sr.h
+++ b/include/dt-bindings/clock/bcm-sr.h
@@ -35,7 +35,7 @@
/* GENPLL 0 clock channel ID SCR HSLS FS PCIE */
#define BCM_SR_GENPLL0 0
-#define BCM_SR_GENPLL0_SATA_CLK 1
+#define BCM_SR_GENPLL0_125M_CLK 1
#define BCM_SR_GENPLL0_SCR_CLK 2
#define BCM_SR_GENPLL0_250M_CLK 3
#define BCM_SR_GENPLL0_PCIE_AXI_CLK 4
@@ -50,9 +50,11 @@
/* GENPLL 2 clock channel ID NITRO MHB*/
#define BCM_SR_GENPLL2 0
#define BCM_SR_GENPLL2_NIC_CLK 1
-#define BCM_SR_GENPLL2_250_NITRO_CLK 2
+#define BCM_SR_GENPLL2_TS_500_CLK 2
#define BCM_SR_GENPLL2_125_NITRO_CLK 3
#define BCM_SR_GENPLL2_CHIMP_CLK 4
+#define BCM_SR_GENPLL2_NIC_FLASH_CLK 5
+#define BCM_SR_GENPLL2_FS4_CLK 6
/* GENPLL 3 HSLS clock channel ID */
#define BCM_SR_GENPLL3 0
@@ -62,11 +64,16 @@
/* GENPLL 4 SCR clock channel ID */
#define BCM_SR_GENPLL4 0
#define BCM_SR_GENPLL4_CCN_CLK 1
+#define BCM_SR_GENPLL4_TPIU_PLL_CLK 2
+#define BCM_SR_GENPLL4_NOC_CLK 3
+#define BCM_SR_GENPLL4_CHCLK_FS4_CLK 4
+#define BCM_SR_GENPLL4_BRIDGE_FSCPU_CLK 5
/* GENPLL 5 FS4 clock channel ID */
#define BCM_SR_GENPLL5 0
-#define BCM_SR_GENPLL5_FS_CLK 1
-#define BCM_SR_GENPLL5_SPU_CLK 2
+#define BCM_SR_GENPLL5_FS4_HF_CLK 1
+#define BCM_SR_GENPLL5_CRYPTO_AE_CLK 2
+#define BCM_SR_GENPLL5_RAID_AE_CLK 3
/* GENPLL 6 NITRO clock channel ID */
#define BCM_SR_GENPLL6 0
@@ -74,13 +81,16 @@
/* LCPLL0 clock channel ID */
#define BCM_SR_LCPLL0 0
-#define BCM_SR_LCPLL0_SATA_REF_CLK 1
-#define BCM_SR_LCPLL0_USB_REF_CLK 2
-#define BCM_SR_LCPLL0_SATA_REFPN_CLK 3
+#define BCM_SR_LCPLL0_SATA_REFP_CLK 1
+#define BCM_SR_LCPLL0_SATA_REFN_CLK 2
+#define BCM_SR_LCPLL0_SATA_350_CLK 3
+#define BCM_SR_LCPLL0_SATA_500_CLK 4
/* LCPLL1 clock channel ID */
#define BCM_SR_LCPLL1 0
#define BCM_SR_LCPLL1_WAN_CLK 1
+#define BCM_SR_LCPLL1_USB_REF_CLK 2
+#define BCM_SR_LCPLL1_CRMU_TS_CLK 3
/* LCPLL PCIE clock channel ID */
#define BCM_SR_LCPLL_PCIE 0
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: Update Stingray clock DT nodes
From: Ray Jui @ 2018-05-31 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527726980-11723-1-git-send-email-ray.jui@broadcom.com>
From: Pramod Kumar <pramod.kumar@broadcom.com>
Update clock output names in the Stingray clock DT nodes so they match
the binding document and the latest ASIC datasheet. Also add entries
for LCPLL2
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26 ++++++++++++++++------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
index 3a4d452..10a106a 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-clock.dtsi
@@ -52,12 +52,24 @@
reg = <0x0001d104 0x32>,
<0x0001c854 0x4>;
clocks = <&osc>;
- clock-output-names = "genpll0", "clk_125", "clk_scr",
+ clock-output-names = "genpll0", "clk_125m", "clk_scr",
"clk_250", "clk_pcie_axi",
"clk_paxc_axi_x2",
"clk_paxc_axi";
};
+ genpll2: genpll2 at 1d1ac {
+ #clock-cells = <1>;
+ compatible = "brcm,sr-genpll2";
+ reg = <0x0001d1ac 0x32>,
+ <0x0001c854 0x4>;
+ clocks = <&osc>;
+ clock-output-names = "genpll2", "clk_nic",
+ "clk_ts_500_ref", "clk_125_nitro",
+ "clk_chimp", "clk_nic_flash",
+ "clk_fs";
+ };
+
genpll3: genpll3 at 1d1e0 {
#clock-cells = <1>;
compatible = "brcm,sr-genpll3";
@@ -75,8 +87,8 @@
<0x0001c854 0x4>;
clocks = <&osc>;
clock-output-names = "genpll4", "clk_ccn",
- "clk_tpiu_pll", "noc_clk",
- "pll_chclk_fs4",
+ "clk_tpiu_pll", "clk_noc",
+ "clk_chclk_fs4",
"clk_bridge_fscpu";
};
@@ -86,8 +98,8 @@
reg = <0x0001d248 0x32>,
<0x0001c870 0x4>;
clocks = <&osc>;
- clock-output-names = "genpll5", "fs4_hf_clk",
- "crypto_ae_clk", "raid_ae_clk";
+ clock-output-names = "genpll5", "clk_fs4_hf",
+ "clk_crypto_ae", "clk_raid_ae";
};
lcpll0: lcpll0 at 1d0c4 {
@@ -107,9 +119,9 @@
reg = <0x0001d138 0x3c>,
<0x0001c870 0x4>;
clocks = <&osc>;
- clock-output-names = "lcpll1", "clk_wanpn",
+ clock-output-names = "lcpll1", "clk_wan",
"clk_usb_ref",
- "timesync_evt_clk";
+ "clk_crmu_ts";
};
hsls_clk: hsls_clk {
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu idle driver
From: Anson Huang @ 2018-05-31 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BYgPu_T=_x8JDkj=k6TUmP0QEQmT8qxoMfxzyTgZrF7g@mail.gmail.com>
Hi, Fabio
Anson Huang
Best Regards!
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Wednesday, May 30, 2018 8:34 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio
> Estevam <fabio.estevam@nxp.com>; Russell King - ARM Linux
> <linux@armlinux.org.uk>; dl-linux-imx <linux-imx@nxp.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu
> idle driver
>
> Hi Anson,
>
> On Wed, May 30, 2018 at 4:12 AM, Anson Huang <Anson.Huang@nxp.com>
> wrote:
> > i.MX6SLL supports ARM power off in cpu idle, better to reuse i.MX6SX
> > cpu idle driver instead of i.MX6SL which does NOT support ARM power
> > off.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > arch/arm/mach-imx/cpuidle-imx6sl.c | 7 ++-----
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c
> > b/arch/arm/mach-imx/cpuidle-imx6sl.c
> > index fa8ead1..8d866fb 100644
> > --- a/arch/arm/mach-imx/cpuidle-imx6sl.c
> > +++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
> > @@ -12,7 +12,6 @@
> >
> > #include "common.h"
> > #include "cpuidle.h"
> > -#include "hardware.h"
>
> The removal of this header file seems to be an unrelated change.
This header file is no longer needed since no " cpu_is_imx6sl()" used in this file.
Anson.
^ permalink raw reply
* [PATCH RESEND V4 6/9] dt-bindings: clock: add imx7ulp clock binding doc
From: Rob Herring @ 2018-05-31 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527234671-31755-7-git-send-email-aisheng.dong@nxp.com>
On Fri, May 25, 2018 at 03:51:08PM +0800, Dong Aisheng wrote:
> i.MX7ULP Clock functions are under joint control of the System
> Clock Generation (SCG) modules, Peripheral Clock Control (PCC)
> modules, and Core Mode Controller (CMC)1 blocks
>
> Note IMX7ULP has two clock domains: M4 and A7. This binding doc
> is only for A7 clock domain.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Anson Huang <Anson.Huang@nxp.com>
> Cc: Bai Ping <ping.bai@nxp.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> ---
> ChangeLog:
> v2->v3:
> * no changes
> v1->v2: no changes
> ---
> .../devicetree/bindings/clock/imx7ulp-clock.txt | 62 ++++++++++++
> include/dt-bindings/clock/imx7ulp-clock.h | 105 +++++++++++++++++++++
> 2 files changed, 167 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> create mode 100644 include/dt-bindings/clock/imx7ulp-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> new file mode 100644
> index 0000000..76ea3c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
> @@ -0,0 +1,62 @@
> +* Clock bindings for Freescale i.MX7ULP
> +
> +i.MX7ULP Clock functions are under joint control of the System
> +Clock Generation (SCG) modules, Peripheral Clock Control (PCC)
> +modules, and Core Mode Controller (CMC)1 blocks
> +
> +The clocking scheme provides clear separation between M4 domain
> +and A7 domain. Except for a few clock sources shared between two
> +domains, such as the System Oscillator clock, the Slow IRC (SIRC),
> +and and the Fast IRC clock (FIRCLK), clock sources and clock
> +management are separated and contained within each domain.
> +
> +M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules.
> +A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules.
> +
> +Note: this binding doc is only for A7 clock domain.
> +
> +Required properties:
> +
> +- compatible: Should be "fsl,imx7ulp-clock".
> +- reg : Should contain registers location and length for scg1,
> + pcc2 and pcc3.
> +- reg-names: Should contain the according reg names "scg1", "pcc2"
> + and "pcc3".
Sounds like separate blocks. These should each be their own node and
binding.
^ permalink raw reply
* [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu idle driver
From: Fabio Estevam @ 2018-05-31 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB13157285F0D882AD1C189617F5630@AM3PR04MB1315.eurprd04.prod.outlook.com>
Hi Anson,
On Wed, May 30, 2018 at 9:52 PM, Anson Huang <anson.huang@nxp.com> wrote:
>> The removal of this header file seems to be an unrelated change.
>
> This header file is no longer needed since no " cpu_is_imx6sl()" used in this file.
cpu_is_imx6sl() is not defined inside arch/arm/mach-imx/hardware.h header file.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527251668-31396-2-git-send-email-codrin.ciubotariu@microchip.com>
On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
> The I2S mux clock can be used to select the I2S input clock. The
> available parents are the peripheral and the generated clocks.
>
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> .../devicetree/bindings/clock/at91-clock.txt | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
> index 51c259a..1c46b3c 100644
> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
> @@ -90,6 +90,8 @@ Required properties:
> "atmel,sama5d2-clk-audio-pll-pmc"
> at91 audio pll output on AUDIOPLLCLK that feeds the PMC
> and can be used by peripheral clock or generic clock
> + "atmel,sama5d2-clk-i2s-mux":
> + at91 I2S clock source selection
Is this boolean or takes some values. If latter, what are valid values?
>
> Required properties for SCKC node:
> - reg : defines the IO memory reserved for the SCKC.
> @@ -507,3 +509,35 @@ For example:
> atmel,clk-output-range = <0 83000000>;
> };
> };
> +
> +Required properties for I2S mux clocks:
> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
> +- name: device tree node describing a specific mux clock.
> + * #clock-cells : from common clock binding; shall be set to 0.
> + * clocks : shall be the mux clock parent phandles; shall be 2 phandles:
> + peripheral and generated clock; the first phandle shall belong to the
> + peripheral clock and the second one shall belong to the generated
> + clock; "clock-indices" property can be user to specify
> + the correct order.
> + * reg: I2S bus id of the corresponding mux clock.
> + e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
> +
> +For example:
> + i2s_clkmux {
What is this a child of?
> + compatible = "atmel,sama5d2-clk-i2s-mux";
> + #address-cells = <1>;
> + #size-cells = <0>;
How do you address this block? My guess is you don't because it is just
part of some other block and you are just creating this node to
instantiate a driver. Just make the node for the actual h/w block a
clock provider and define the clock ids (0 and 1).
> +
> + i2s0muxck: i2s0_muxclk {
> + clocks = <&i2s0_clk>, <&i2s0_gclk>;
> + #clock-cells = <0>;
> + reg = <0>;
> + };
> +
> + i2s1muxck: i2s1_muxclk {
> + clocks = <&i2s1_clk>, <&i2s1_gclk>;
> + #clock-cells = <0>;
> + reg = <1>;
> + };
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu idle driver
From: Anson Huang @ 2018-05-31 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BJzSHx4zmkMWZVR-Z-y6p-=bMG+WQ2LASOroEdXHdyLA@mail.gmail.com>
Hi, Fabio
Anson Huang
Best Regards!
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Thursday, May 31, 2018 8:57 AM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; Sascha Hauer
> <s.hauer@pengutronix.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio
> Estevam <fabio.estevam@nxp.com>; Russell King - ARM Linux
> <linux@armlinux.org.uk>; dl-linux-imx <linux-imx@nxp.com>; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> <linux-arm-kernel@lists.infradead.org>; linux-kernel
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu
> idle driver
>
> Hi Anson,
>
> On Wed, May 30, 2018 at 9:52 PM, Anson Huang <anson.huang@nxp.com>
> wrote:
>
> >> The removal of this header file seems to be an unrelated change.
> >
> > This header file is no longer needed since no " cpu_is_imx6sl()" used in this
> file.
>
> cpu_is_imx6sl() is not defined inside arch/arm/mach-imx/hardware.h header
> file.
It is in arch/arm/mach-imx/mxc.h included by hardware.h, it is added by commit
(dee5dee ARM: imx: Add basic msl support for imx6sll), so I removed it since we
no longer need it.
Anson.
^ permalink raw reply
* [PATCH v4 2/6] dt-bindings: add binding for atmel-usart in SPI mode
From: Rob Herring @ 2018-05-31 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525171941.26766-3-radu.pirea@microchip.com>
On Fri, May 25, 2018 at 08:19:37PM +0300, Radu Pirea wrote:
> This patch moves the bindings for serial from serial/atmel-usart.txt to
> mfd/atmel-usart.txt and adds bindings for USART in SPI mode.
>
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> .../bindings/{serial => mfd}/atmel-usart.txt | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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