* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WTTKXwPchuWRh-RNTc8=X8Xo28oTqk=3wW4+SiTHhxuA@mail.gmail.com>
On Wed, May 30, 2018 at 07:54:47AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote:
> > I'm confused as to why we are specifying the maximum current the device
> > can deliver in a given mode in the DT - surely that's a fixed property
> > of the hardware?
> Said another way: you're saying that you'd expect the "max-microamps"
> table to have one fewer element than the listed modes? So in the
> above example you'd have:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/ae2343e4/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-30 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0476932-a6e9-6ef1-69ad-c9a8c55d9739@ti.com>
* Tero Kristo <t-kristo@ti.com> [180530 15:44]:
> On 30/05/18 18:28, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
> > > For the OCP if part, I think that is still needed until we switch over to
> > > full sysc driver. clkctrl_offs you probably also need because that is used
> > > for mapping the omap_hwmod against a specific clkctrl clock. Those can be
> > > only removed once we are done with hwmod (or figure out some other way to
> > > assign the clkctrl clock to a hwmod.)
> >
> > Hmm might be worth testing. I thought your commit 70f05be32133
> > ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
> > already parses the clkctrl from dts?
>
> It maps the clkctrl clock to be used by hwmod, if those are available. We
> didn't add any specific clock entries to DT for mapping the actual clkctrl
> clock without the hwmod_data hints yet though, as that was deemed temporary
> solution only due to transition to interconnect driver. I.e., you would need
> something like this in DT for every device node:
>
> &uart3 {
> clocks = <l4per_clkctrl UART3_CLK 0>;
> clock-names = "clkctrl";
> };
>
> ... which is currently not present.
Hmm is that not the "fck" clkctrl clock we have already in
the dts files for the interconnect target modules?
We can also use pdata callbacks to pass the clock node if
needed. But I guess I don't quite still understand what we
are missing :)
Regards,
Tony
^ permalink raw reply
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Stephen Boyd @ 2018-05-30 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <664089d4-b30d-99bb-2021-12128b2895ba@codeaurora.org>
Quoting Sricharan R (2018-05-24 22:40:11)
> Hi Bjorn,
>
> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
> > On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> >
> >> From: Stephen Boyd <sboyd@codeaurora.org>
> >>
> >> Krait CPUs have a handful of L2 cache controller registers that
> >> live behind a cp15 based indirection register. First you program
> >> the indirection register (l2cpselr) to point the L2 'window'
> >> register (l2cpdr) at what you want to read/write. Then you
> >> read/write the 'window' register to do what you want. The
> >> l2cpselr register is not banked per-cpu so we must lock around
> >> accesses to it to prevent other CPUs from re-pointing l2cpdr
> >> underneath us.
> >>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Russell King <linux@arm.linux.org.uk>
> >> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > This should have your signed-off-by here as well.
> >
>
> ok.
>
> > Apart from that:
> >
> > Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >
>
Will these patches come around again? I'll do a quick sweep on them
today but I expect them to be resent.
^ permalink raw reply
* [PATCH v2 4/4] mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq
From: Georgi Djakov @ 2018-05-30 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c84f6fc-270c-d826-6d87-7f9f6fc5015f@codeaurora.org>
Hi Vijay,
On 05/30/2018 10:11 AM, Vijay Viswanath wrote:
> Hi Georgi,
>
> Thanks for testing the patch on 8096 and pointing out this issue.
> The issue is coming because, when card is removed, the HOST_CONTROL2
> register is retaining the 1.8V Signalling enable bit till SDHCI reset
> happens after a new card is inserted.
>
> Adding the change you suggested can avoid this wait, but I feel a better
> solution is to clear the 1.8V signalling bit when the card is removed.
> When a new card is inserted, we shouldn't be keeping the 1.8V bit set
> until we send cmd11 to the SD card. A new SD card should start with 3V.
>
> One solution is to explicitly clear the HOST_CONTROL2 register when card
> is removed.
>
> Other way is to revert the commit:
> 9718f84b85396e090ca42fafa730410d286d61e3 "mmc: sdhci-msm: Do not reset
> the controller if no card in the slot"
>
> The sdhci-msm doesn't require "SDHCI_QUIRK_NO_CARD_NO_RESET". The issue
> which above commit is trying to avoid is fixed by the pwr-irq patches.
> Resetting the controller will clear the HOST_CONTROL2 register and avoid
> this issue.
>
> Can you please try this ? I tested reverting the QUIRK on two platforms:
> db410c(8916) and sdm845. SD card insert/remove worked fine after that
> and I didn't get any "Reset 0x1 never completed" error during card
> insert/remove or shutdown.
Thank you! I have submitted a patch to remove the quirk and tested it on
db410c and db820c.
BR,
Georgi
^ permalink raw reply
* [PATCH v2 00/17] arm64 SSBD (aka Spectre-v4) mitigation
From: Will Deacon @ 2018-05-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529121121.24927-1-marc.zyngier@arm.com>
Hi Marc,
On Tue, May 29, 2018 at 01:11:04PM +0100, Marc Zyngier wrote:
> This patch series implements the Linux kernel side of the "Spectre-v4"
> (CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable"
> (SSBD).
>
> More information can be found at:
>
> https://bugs.chromium.org/p/project-zero/issues/detail?id=1528
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
>
> For all released Arm Cortex-A CPUs that are affected by this issue, then
> the preferred mitigation is simply to set a chicken bit in the firmware
> during CPU initialisation and therefore no change to Linux is required.
> Other CPUs may require the chicken bit to be toggled dynamically (for
> example, when switching between user-mode and kernel-mode) and this is
> achieved by calling into EL3 via an SMC which has been published as part
> of the latest SMCCC specification:
>
> https://developer.arm.com/cache-speculation-vulnerability-firmware-specification
>
> as well as an ATF update for the released ARM cores affected by SSBD:
>
> https://github.com/ARM-software/arm-trusted-firmware/pull/1392
>
> These patches provide the following:
>
> 1. Safe probing of firmware to establish which CPUs in the system
> require calling into EL3 as part of the mitigation.
>
> 2. For CPUs that require it, call into EL3 on exception entry/exit
> from EL0 to apply the SSBD mitigation when running at EL1.
>
> 3. A command-line option to force the SSBD mitigation to be always on,
> always off, or dymamically toggled (default) for CPUs that require
> the EL3 call.
>
> 4. An initial implementation of a prctl() backend for arm64 that allows
> userspace tasks to opt-in to the mitigation explicitly. This is
> intended to match the interface provided by x86, and so we rely on
> their core changes here. The seccomp interface is provided as an
> extra set of patches, which I'd like *not* to see merged. The main
> reason is that it is invasive, has ugly/unclear semantics, and could
> probably be left to the existing prctl interface.
I agree with you here. For patches 1-10, then:
Acked-by: Will Deacon <will.deacon@arm.com>
but I'd prefer to leave the seccomp stuff alone for the moment because I
don't think the implicit enabling is necessarily the right thing to do
there and supporting it comes at a cost.
Will
^ permalink raw reply
* [PATCH v2 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Jon Hunter @ 2018-05-30 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-9-ulf.hansson@linaro.org>
On 29/05/18 11:04, Ulf Hansson wrote:
> To support devices being partitioned across multiple PM domains, let's
> begin with extending genpd to cope with these kind of configurations.
>
> Therefore, add a new exported function genpd_dev_pm_attach_by_id(), which
> is similar to the existing genpd_dev_pm_attach(), but with the difference
> that it allows its callers to provide an index to the PM domain that it
> wants to attach.
>
> Note that, genpd_dev_pm_attach_by_id() shall only be called by the driver
> core / PM core, similar to how the existing dev_pm_domain_attach() makes
> use of genpd_dev_pm_attach(). However, this is implemented by following
> changes on top.
>
> Because, only one PM domain can be attached per device, genpd needs to
> create a virtual device that it can attach/detach instead. More precisely,
> let the new function genpd_dev_pm_attach_by_id() register a virtual struct
> device via calling device_register(). Then let it attach this device to the
> corresponding PM domain, rather than the one that is provided by the
> caller. The actual attaching is done via re-using the existing genpd OF
> functions.
>
> At successful attachment, genpd_dev_pm_attach_by_id() returns the created
> virtual device, which allows the caller to operate on it to deal with power
> management. Following changes on top, provides more details in this
> regards.
>
> To deal with detaching of a PM domain for the multiple PM domains case,
> let's also extend the existing genpd_dev_pm_detach() function, to cover the
> cleanup of the created virtual device, via make it call device_unregister()
> on it. In this way, there is no need to introduce a new function to deal
> with detach for the multiple PM domain case, but instead the existing one
> is re-used.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> Changes in v2:
> - Fixed comments from Jon. Clarified function descriptions
> and changelog.
>
> ---
> drivers/base/power/domain.c | 80 +++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 8 ++++
> 2 files changed, 88 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 2af99bfcbe3c..2b496d79159d 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2171,6 +2171,15 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> }
> EXPORT_SYMBOL_GPL(of_genpd_remove_last);
>
> +static void genpd_release_dev(struct device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static struct bus_type genpd_bus_type = {
> + .name = "genpd",
> +};
> +
> /**
> * genpd_dev_pm_detach - Detach a device from its PM domain.
> * @dev: Device to detach.
> @@ -2208,6 +2217,10 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
>
> /* Check if PM domain can be powered off after removing this device. */
> genpd_queue_power_off_work(pd);
> +
> + /* Unregister the device if it was created by genpd. */
> + if (dev->bus == &genpd_bus_type)
> + device_unregister(dev);
> }
>
> static void genpd_dev_pm_sync(struct device *dev)
> @@ -2298,6 +2311,67 @@ int genpd_dev_pm_attach(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> +/**
> + * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
> + * @dev: Device to attach.
Can you update the description of the above as well?
Thanks
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v2 6/9] PM / Domains: Don't attach devices in genpd with multi PM domains
From: Jon Hunter @ 2018-05-30 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-7-ulf.hansson@linaro.org>
On 29/05/18 11:04, Ulf Hansson wrote:
> The power-domain DT property may now contain a list of PM domain
> specifiers, which represents that a device are partitioned across multiple
> PM domains. This leads to a new situation in genpd_dev_pm_attach(), as only
> one PM domain can be attached per device.
>
> To remain things simple for the most common configuration, when a single PM
> domain is used, let's treat the multiple PM domain case as being specific.
>
> In other words, let's change genpd_dev_pm_attach() to check for multiple PM
> domains and prevent it from attach any PM domain for this case. Instead,
> leave this to be managed separately, from following changes to genpd.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> Suggested-by: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
>
> Changes in v2:
> - Minor update to changelog to mention "PM domain specifiers" rather
> than a "list of phandles".
>
> ---
> drivers/base/power/domain.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 7ebf7993273a..12a20f21974d 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2229,10 +2229,10 @@ static void genpd_dev_pm_sync(struct device *dev)
> * attaches the device to retrieved pm_domain ops.
> *
> * Returns 1 on successfully attached PM domain, 0 when the device don't need a
> - * PM domain or a negative error code in case of failures. Note that if a
> - * power-domain exists for the device, but it cannot be found or turned on,
> - * then return -EPROBE_DEFER to ensure that the device is not probed and to
> - * re-try again later.
> + * PM domain or when multiple power-domains exists for it, else a negative error
> + * code. Note that if a power-domain exists for the device, but it cannot be
> + * found or turned on, then return -EPROBE_DEFER to ensure that the device is
> + * not probed and to re-try again later.
> */
> int genpd_dev_pm_attach(struct device *dev)
> {
> @@ -2243,10 +2243,18 @@ int genpd_dev_pm_attach(struct device *dev)
> if (!dev->of_node)
> return 0;
>
> + /*
> + * Devices with multiple PM domains must be attached separately, as we
> + * can only attach one PM domain per device.
> + */
> + if (of_count_phandle_with_args(dev->of_node, "power-domains",
> + "#power-domain-cells") != 1)
> + return 0;
> +
> ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> "#power-domain-cells", 0, &pd_args);
> if (ret < 0)
> - return 0;
> + return ret;
>
> mutex_lock(&gpd_list_lock);
> pd = genpd_get_from_provider(&pd_args);
>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530154849.GQ6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 8:48 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 08:34:50AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 8:02 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > What you're describing sounds like what we should be doing normally, if
>> > we're not doing that we should probably be fixing the core.
>
>> I'm not convinced that this behavior makes sense to move to the core.
>> On most regulators I'd expect that when the regulator driver says to
>> turn them off that they will output no voltage. The reason RPMh is
>
> Oh, you mean while the regulator is off... TBH I don't see a huge
> problem doing that anyway and just reverting to the bottom of the
> constraints when everything gets turned off since we have to see if we
> need to adjust the voltage every time we enabled anyway.
>
>> In any other system when Linux disabled the regulator it wouldn't
>> matter that you left it set at 1.4V. Thus RPMh is special and IMO the
>> workaround belongs there.
>
> Without the core doing something the regulator isn't going to get told
> that anything updated voltages anyway...
I was just suggesting that when the core tells the regulator driver to
disable itself that the regulator driver tell RPMh to not only disable
itself but also (temporarily) vote for a lower voltage. When the core
tells the regulator to re-enable itself then the regulator driver
restores the original voltage vote (or applies any vote that might
have been attempted while the regulator was disabled). That wouldn't
require any regulator core changes.
-Doug
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=X2u=hMyWinSDtim-PmFwAy5mXcwg3HeYojAHcsUFhV3g@mail.gmail.com>
On Wed, May 30, 2018 at 09:06:16AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 8:48 AM, Mark Brown <broonie@kernel.org> wrote:
> > Without the core doing something the regulator isn't going to get told
> > that anything updated voltages anyway...
> I was just suggesting that when the core tells the regulator driver to
> disable itself that the regulator driver tell RPMh to not only disable
> itself but also (temporarily) vote for a lower voltage. When the core
> tells the regulator to re-enable itself then the regulator driver
> restores the original voltage vote (or applies any vote that might
> have been attempted while the regulator was disabled). That wouldn't
> require any regulator core changes.
It needs something to tell it what the new voltage to set is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/383a4352/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 7/9] PM / Domains: Split genpd_dev_pm_attach()
From: Jon Hunter @ 2018-05-30 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-8-ulf.hansson@linaro.org>
On 29/05/18 11:04, Ulf Hansson wrote:
> To extend genpd to deal with allowing multiple PM domains per device, some
> of the code in genpd_dev_pm_attach() can be re-used. Let's prepare for this
> by moving some of the code into a sub-function.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 60 ++++++++++++++++++++-----------------
> 1 file changed, 33 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 12a20f21974d..2af99bfcbe3c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2221,38 +2221,15 @@ static void genpd_dev_pm_sync(struct device *dev)
> genpd_queue_power_off_work(pd);
> }
>
> -/**
> - * genpd_dev_pm_attach - Attach a device to its PM domain using DT.
> - * @dev: Device to attach.
> - *
> - * Parse device's OF node to find a PM domain specifier. If such is found,
> - * attaches the device to retrieved pm_domain ops.
> - *
> - * Returns 1 on successfully attached PM domain, 0 when the device don't need a
> - * PM domain or when multiple power-domains exists for it, else a negative error
> - * code. Note that if a power-domain exists for the device, but it cannot be
> - * found or turned on, then return -EPROBE_DEFER to ensure that the device is
> - * not probed and to re-try again later.
> - */
> -int genpd_dev_pm_attach(struct device *dev)
> +static int __genpd_dev_pm_attach(struct device *dev, struct device_node *np,
> + unsigned int index)
> {
> struct of_phandle_args pd_args;
> struct generic_pm_domain *pd;
> int ret;
>
> - if (!dev->of_node)
> - return 0;
> -
> - /*
> - * Devices with multiple PM domains must be attached separately, as we
> - * can only attach one PM domain per device.
> - */
> - if (of_count_phandle_with_args(dev->of_node, "power-domains",
> - "#power-domain-cells") != 1)
> - return 0;
> -
> - ret = of_parse_phandle_with_args(dev->of_node, "power-domains",
> - "#power-domain-cells", 0, &pd_args);
> + ret = of_parse_phandle_with_args(np, "power-domains",
> + "#power-domain-cells", index, &pd_args);
> if (ret < 0)
> return ret;
>
> @@ -2290,6 +2267,35 @@ int genpd_dev_pm_attach(struct device *dev)
>
> return ret ? -EPROBE_DEFER : 1;
> }
> +
> +/**
> + * genpd_dev_pm_attach - Attach a device to its PM domain using DT.
> + * @dev: Device to attach.
> + *
> + * Parse device's OF node to find a PM domain specifier. If such is found,
> + * attaches the device to retrieved pm_domain ops.
> + *
> + * Returns 1 on successfully attached PM domain, 0 when the device don't need a
> + * PM domain or when multiple power-domains exists for it, else a negative error
> + * code. Note that if a power-domain exists for the device, but it cannot be
> + * found or turned on, then return -EPROBE_DEFER to ensure that the device is
> + * not probed and to re-try again later.
> + */
> +int genpd_dev_pm_attach(struct device *dev)
> +{
> + if (!dev->of_node)
> + return 0;
> +
> + /*
> + * Devices with multiple PM domains must be attached separately, as we
> + * can only attach one PM domain per device.
> + */
> + if (of_count_phandle_with_args(dev->of_node, "power-domains",
> + "#power-domain-cells") != 1)
> + return 0;
> +
> + return __genpd_dev_pm_attach(dev, dev->of_node, 0);
> +}
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> static const struct of_device_id idle_state_match[] = {
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530160744.GS6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:06:16AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 8:48 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Without the core doing something the regulator isn't going to get told
>> > that anything updated voltages anyway...
>
>> I was just suggesting that when the core tells the regulator driver to
>> disable itself that the regulator driver tell RPMh to not only disable
>> itself but also (temporarily) vote for a lower voltage. When the core
>> tells the regulator to re-enable itself then the regulator driver
>> restores the original voltage vote (or applies any vote that might
>> have been attempted while the regulator was disabled). That wouldn't
>> require any regulator core changes.
>
> It needs something to tell it what the new voltage to set is.
The regulator driver has its own cache of what voltage was most
recently requested by Linux. It can use that, can't it?
-Doug
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530155044.GR6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 8:50 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 07:54:47AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > I'm confused as to why we are specifying the maximum current the device
>> > can deliver in a given mode in the DT - surely that's a fixed property
>> > of the hardware?
>
>> Said another way: you're saying that you'd expect the "max-microamps"
>> table to have one fewer element than the listed modes? So in the
>> above example you'd have:
>
> 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.
My argument to David was that since set_load / get_optimum_mode were
features of the regulator core these should actually be standard
properties and not Qualcomm-specific ones.
-Doug
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WVGu0f+=q-C9kiEmaLEUJqGY+Jbns83h72uF-9iasrUw@mail.gmail.com>
On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
> > It needs something to tell it what the new voltage to set is.
> The regulator driver has its own cache of what voltage was most
> recently requested by Linux. It can use that, can't it?
If we're just going to use the most recently set voltage then hopefully
the hardware already knew that, and it might not be the lowest available
voltage if the last consumer to get turned off was holding the voltage
higher.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/10a575f9/attachment.sig>
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WVUmvPPd5BxXv9Sa_2CRPrrjQvYFyqroY-3fRr4f0Bzg@mail.gmail.com>
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/e99e0527/attachment-0001.sig>
^ permalink raw reply
* [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530162007.GU6920@sirena.org.uk>
Hi,
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...
-Doug
^ permalink raw reply
* [PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling
From: Herbert Xu @ 2018-05-30 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527171551-21979-1-git-send-email-gilad@benyossef.com>
On Thu, May 24, 2018 at 03:19:05PM +0100, Gilad Ben-Yossef wrote:
> The patch set enables the use of CryptoCell found in some Renesas R-Car
> Salvator-X boards and fixes some driver issues uncovered that prevented
> to work properly.
>
> Changes from v1:
> - Properly fix the bug that caused us to read a bad signature register
> rather than dropping the check
> - Proper DT fields as indicated by Geert Uytterhoeven.
> - Better clock enabling as suggested by Geert Uytterhoeven.
>
> Note! the last two patches in the set depend on the
> "clk: renesas: r8a7795: Add CR clock" patch from Geert Uytterhoeven.
Patches 1-3 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530161311.GT6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:09:02AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:07 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It needs something to tell it what the new voltage to set is.
>
>> The regulator driver has its own cache of what voltage was most
>> recently requested by Linux. It can use that, can't it?
>
> If we're just going to use the most recently set voltage then hopefully
> the hardware already knew that, and it might not be the lowest available
> voltage if the last consumer to get turned off was holding the voltage
> higher.
To circle back to the original point: the problem is that (IMHO) the
hardware is doing the wrong thing by still counting Linux's vote for a
voltage even though Linux also voted that the regulator should be
disabled. So basically we're working around the hardware by
pretending to vote for a dummy lower voltage whenever Linux wants the
regulator disabled. From Linux's point of view everything works as
normal--we just tell the hardware a falsehood so it doesn't count our
vote for a voltage while the regulator is disabled.
-Doug
^ permalink raw reply
* [PATCH v4 0/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-30 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1527040878.git.collinsd@codeaurora.org>
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/fd8d3adf/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UpWEMSPUYOHmLQ0g_mF990kwn4_zm=ZCNttLKZiz7i=Q@mail.gmail.com>
On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
> > If we're just going to use the most recently set voltage then hopefully
> > the hardware already knew that, and it might not be the lowest available
> > voltage if the last consumer to get turned off was holding the voltage
> > higher.
> To circle back to the original point: the problem is that (IMHO) the
> hardware is doing the wrong thing by still counting Linux's vote for a
> voltage even though Linux also voted that the regulator should be
> disabled. So basically we're working around the hardware by
> pretending to vote for a dummy lower voltage whenever Linux wants the
> regulator disabled. From Linux's point of view everything works as
> normal--we just tell the hardware a falsehood so it doesn't count our
> vote for a voltage while the regulator is disabled.
Yeah, and I don't think that's unreasonable for the core to do - just
drop the voltage to the constraint minimum after it has turned off the
regulator, then recheck and raise if needed before it enables again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/aed2a9fd/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530163644.GW6920@sirena.org.uk>
Hi,
On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 30, 2018 at 09:31:55AM -0700, Doug Anderson wrote:
>> On Wed, May 30, 2018 at 9:13 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > If we're just going to use the most recently set voltage then hopefully
>> > the hardware already knew that, and it might not be the lowest available
>> > voltage if the last consumer to get turned off was holding the voltage
>> > higher.
>
>> To circle back to the original point: the problem is that (IMHO) the
>> hardware is doing the wrong thing by still counting Linux's vote for a
>> voltage even though Linux also voted that the regulator should be
>> disabled. So basically we're working around the hardware by
>> pretending to vote for a dummy lower voltage whenever Linux wants the
>> regulator disabled. From Linux's point of view everything works as
>> normal--we just tell the hardware a falsehood so it doesn't count our
>> vote for a voltage while the regulator is disabled.
>
> Yeah, and I don't think that's unreasonable for the core to do - just
> drop the voltage to the constraint minimum after it has turned off the
> regulator, then recheck and raise if needed before it enables again.
Would it do this for all regulators, though? Most regulators are
hooked up over a slow i2c bus, so that means that every regulator
disable would now do an extra i2c transfer even though for all
regulators (other than RPMh) the voltage of a regulator doesn't matter
when it's been "disabled' (from Linux's point of view).
Hrmmm, I suppose maybe it'd be OK though because for most regulators
we'd use "regcache" and most regulators that we enabled/disable a lot
are not expected to change voltage in Linux (so the regcache write
would hopefully be a noop), so maybe it wouldn't be _that_
inefficient...
-Doug
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add missing CPU clocks to secondary CPUs on Exynos542x
From: Krzysztof Kozlowski @ 2018-05-30 16:49 UTC (permalink / raw)
To: linux-arm-kernel
Secondary CPUs should have the same information in DeviceTree as booting
CPU from both correctness point of view and for possible hotplug
scenarios.
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index a8e449471304..0ee6e92a3c29 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -38,6 +38,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -49,6 +50,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -60,6 +62,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -83,6 +86,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -94,6 +98,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -105,6 +110,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 7c130a00d1a8..e4a5857c135f 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -37,6 +37,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -48,6 +49,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -59,6 +61,7 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <1000000000>;
cci-control-port = <&cci_control0>;
operating-points-v2 = <&cluster_a7_opp_table>;
@@ -69,8 +72,8 @@
cpu4: cpu at 0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
- clocks = <&clock CLK_ARM_CLK>;
reg = <0x0>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -82,6 +85,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -93,6 +97,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
@@ -104,6 +109,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <1800000000>;
cci-control-port = <&cci_control1>;
operating-points-v2 = <&cluster_a15_opp_table>;
--
2.14.1
^ permalink raw reply related
* [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Mark Brown @ 2018-05-30 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=V1gGccKr1mHM0zx_-FFdLU1vrzUChwx6KTUyTGzj39Tw@mail.gmail.com>
On Wed, May 30, 2018 at 09:41:55AM -0700, Doug Anderson wrote:
> On Wed, May 30, 2018 at 9:36 AM, Mark Brown <broonie@kernel.org> wrote:
> > Yeah, and I don't think that's unreasonable for the core to do - just
> > drop the voltage to the constraint minimum after it has turned off the
> > regulator, then recheck and raise if needed before it enables again.
> Would it do this for all regulators, though? Most regulators are
> hooked up over a slow i2c bus, so that means that every regulator
> disable would now do an extra i2c transfer even though for all
> regulators (other than RPMh) the voltage of a regulator doesn't matter
> when it's been "disabled' (from Linux's point of view).
It'd only affect regulators that can vary in voltage and actually get
disabled which is a pretty small subset. Most regulators are either
fixed voltage or always on.
> Hrmmm, I suppose maybe it'd be OK though because for most regulators
> we'd use "regcache" and most regulators that we enabled/disable a lot
> are not expected to change voltage in Linux (so the regcache write
> would hopefully be a noop), so maybe it wouldn't be _that_
> inefficient...
Even if the regulator lacks a cache we'd at least skip out on the write
when we're not changing voltage as we'd do a read/modify/update cycle
and stop at the modify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/af4e9b3f/attachment-0001.sig>
^ permalink raw reply
* arch_wb_cache_pmem on ARM64
From: Mikulas Patocka @ 2018-05-30 17:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I'd like to ask what's the purpose of dmb(osh) in the function
arch_wb_cache_pmem in arch/arm64/mm/flush.c?
void arch_wb_cache_pmem(void *addr, size_t size)
{
/* Ensure order against any prior non-cacheable writes */
dmb(osh);
__clean_dcache_area_pop(addr, size);
}
The processor may flush the cache spontaneously, that means that all the
flushing may actually happen before the dmb(osh) instruction - so what
does that dmb instruction guard against?
Mikulas
^ permalink raw reply
* [PATCH 4/9] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: Michael Turquette @ 2018-05-30 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525181150.17873-5-david@lechnology.com>
Quoting David Lechner (2018-05-25 11:11:45)
> From: Sekhar Nori <nsekhar@ti.com>
>
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> Reviewed-by: David Lechner <david@lechnology.com>
> ---
> drivers/clk/davinci/pll-dm646x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
> index a61cc3256418..0ae827e3ce80 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
> .flags = 0,
> };
>
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
Nitpick: I dislike setting a platform-specific flag that just sets a
framework-specific flag during clk registration.
I know there is some legacy here so I'll take this patch as-is, but
perhaps cleaning this up to directly use CLK_IS_CRITICAL can be added to
someone's todo list?
Thanks,
Mike
>
> int dm646x_pll2_init(struct device *dev, void __iomem *base)
> {
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v2 1/2] ARM: debug: Add Iproc UART3 debug addresses
From: Ray Jui @ 2018-05-30 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530131956.13972-1-peron.clem@gmail.com>
Hi Cl?ment,
Correct me if I'm wrong, but I thought the trend is to move to use
earlycon that can be activated from kernel command line for early print
before the serial driver is loaded.
Have you tried earlcon?
Thanks,
Ray
On 5/30/2018 6:19 AM, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> Broadcom Iproc SoCs typically use the UART3 for
> debug/console, provide a known good location for that.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
>
> arch/arm/Kconfig.debug | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 199ebc1c4538..4ea9d5793b91 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -207,6 +207,14 @@ choice
> depends on ARCH_BCM_HR2
> select DEBUG_UART_8250
>
> + config DEBUG_BCM_IPROC_UART3
> + bool "Kernel low-level debugging on BCM IPROC UART3"
> + depends on ARCH_BCM_CYGNUS
> + select DEBUG_UART_8250
> + help
> + Say Y here if you want the debug print routines to direct
> + their output to the third serial port on these devices.
> +
> config DEBUG_BCM_KONA_UART
> bool "Kernel low-level debugging messages via BCM KONA UART"
> depends on ARCH_BCM_MOBILE
> @@ -1557,6 +1565,7 @@ config DEBUG_UART_PHYS
> default 0x18000400 if DEBUG_BCM_HR2
> default 0x18010000 if DEBUG_SIRFATLAS7_UART0
> default 0x18020000 if DEBUG_SIRFATLAS7_UART1
> + default 0x18023000 if DEBUG_BCM_IPROC_UART3
> default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1
> default 0x20001000 if DEBUG_HIP01_UART
> default 0x20060000 if DEBUG_RK29_UART0
> @@ -1676,6 +1685,7 @@ config DEBUG_UART_VIRT
> default 0xf1002000 if DEBUG_MT8127_UART0
> default 0xf1006000 if DEBUG_MT6589_UART0
> default 0xf1009000 if DEBUG_MT8135_UART3
> + default 0xf1023000 if DEBUG_BCM_IPROC_UART3
> default 0xf11f1000 if DEBUG_VERSATILE
> default 0xf1600000 if DEBUG_INTEGRATOR
> default 0xf1c28000 if DEBUG_SUNXI_UART0
> @@ -1791,7 +1801,7 @@ config DEBUG_UART_8250_WORD
> DEBUG_KEYSTONE_UART0 || DEBUG_KEYSTONE_UART1 || \
> DEBUG_ALPINE_UART0 || \
> DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
> - DEBUG_DAVINCI_DA8XX_UART2 || \
> + DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_BCM_IPROC_UART3 || \
> DEBUG_BCM_KONA_UART || DEBUG_RK32_UART2
>
> config DEBUG_UART_8250_PALMCHIP
>
^ 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