* [PATCH v2] clocksource/arm_arch_timer: Map frame with of_io_request_and_map()
From: Marc Zyngier @ 2016-10-26 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026073550.22918-1-sboyd@codeaurora.org>
On 26/10/16 08:35, Stephen Boyd wrote:
> Let's use the of_io_request_and_map() API so that the frame
> region is protected and shows up in /proc/iomem.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes from v1:
> * Check for IS_ERR instead
>
> drivers/clocksource/arm_arch_timer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487da6d2a..723cc924d8d1 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -964,8 +964,9 @@ static int __init arch_timer_mem_init(struct device_node *np)
> }
>
> ret= -ENXIO;
> - base = arch_counter_base = of_iomap(best_frame, 0);
> - if (!base) {
> + base = arch_counter_base = of_io_request_and_map(best_frame, 0,
> + "arch_mem_timer");
> + if (IS_ERR(base)) {
> pr_err("arch_timer: Can't map frame's registers\n");
> goto out;
> }
>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().
From: Robert Richter @ 2016-10-26 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477431061-7258-2-git-send-email-ddaney.cavm@gmail.com>
On 25.10.16 14:31:00, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> On arm64 NUMA kernels we can pass "numa=off" on the command line to
> disable NUMA. A side effect of this is that kmalloc_node() calls to
> non-zero nodes will crash the system with an OOPS:
>
> [ 0.000000] [<fffffc00081bba84>] __alloc_pages_nodemask+0xa4/0xe68
> [ 0.000000] [<fffffc00082163a8>] new_slab+0xd0/0x57c
> [ 0.000000] [<fffffc000821879c>] ___slab_alloc+0x2e4/0x514
> [ 0.000000] [<fffffc000823882c>] __slab_alloc+0x48/0x58
> [ 0.000000] [<fffffc00082195a0>] __kmalloc_node+0xd0/0x2e0
> [ 0.000000] [<fffffc00081119b8>] __irq_domain_add+0x7c/0x164
> [ 0.000000] [<fffffc0008b75d30>] its_probe+0x784/0x81c
> [ 0.000000] [<fffffc0008b75e10>] its_init+0x48/0x1b0
> .
> .
> .
>
> This is caused by code like this in kernel/irq/irqdomain.c
>
> domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) * size),
> GFP_KERNEL, of_node_to_nid(of_node));
>
> When NUMA is disabled, the concept of a node is really undefined, so
> of_node_to_nid() should unconditionally return NUMA_NO_NODE.
>
> Add __of_force_no_numa() to allow of_node_to_nid() to be forced to
> return NUMA_NO_NODE.
>
> The follow on patch will call this new function from the arm64 numa
> code.
Didn't that work before? numa=off just maps all mem to node 0. If mem
allocation is requested for another node it should just fall back to a
node with mem (node 0 then). I suspect there is something wrong with
the page initialization, see:
http://www.spinics.net/lists/arm-kernel/msg535191.html
https://bugzilla.redhat.com/show_bug.cgi?id=1387793
What is the complete oops?
So I think k*alloc_node() must be able to handle requests to
non-existing nodes. Otherwise your fix is incomplete, assume a failed
of_numa_init() causing a dummy init but still some devices reporting a
node.
-Robert
^ permalink raw reply
* [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver
From: Fu Wei @ 2016-10-26 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57010864-b2f0-d230-3138-8ace484acb04@arm.com>
Hi Marc,
On 26 October 2016 at 20:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 26/10/16 12:10, Fu Wei wrote:
>> Hi Mark,
>>
>> On 21 October 2016 at 00:37, Mark Rutland <mark.rutland@arm.com> wrote:
>>> Hi,
>>>
>>> As a heads-up, on v4.9-rc1 I see conflicts at least against
>>> arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up
>>> automatically, but this will need to be rebased before the next posting
>>> and/or merging.
>>>
>>> On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu.wei at linaro.org wrote:
>>>> +static int __init map_gt_gsi(u32 interrupt, u32 flags)
>>>> +{
>>>> + int trigger, polarity;
>>>> +
>>>> + if (!interrupt)
>>>> + return 0;
>>>
>>> Urgh.
>>>
>>> Only the secure interrupt (which we do not need) is optional in this
>>> manner, and (hilariously), zero appears to also be a valid GSIV, per
>>> figure 5-24 in the ACPI 6.1 spec.
>>>
>>> So, I think that:
>>>
>>> (a) we should not bother parsing the secure interrupt
>>
>> If I understand correctly, from this point of view, kernel don't
>> handle the secure interrupt.
>> But the current arm_arch_timer driver still enable/disable/request
>> PHYS_SECURE_PPI
>> with PHYS_NONSECURE_PPI.
>> That means we still need to parse the secure interrupt.
>> Please correct me, if I misunderstand something? :-)
>
> That's because we can use the per-cpu timer when 32bit Linux is running
> on the secure side (and we cannot distinguish between secure and
> non-secure at runtime). ACPI is 64bit only, and Linux on 64bit isn't
> supported on the secure side, so only registering the non-secure timer
> is perfectly acceptable.
Great thanks for your explanation :-)
So we just don't need to fill arch_timer_ppi[PHYS_SECURE_PPI] , just skip it.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Geert Uytterhoeven @ 2016-10-26 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1a85f851-29ec-1c14-8905-8b0645f5bb1c@cogentembedded.com>
On Wed, Oct 26, 2016 at 3:23 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 10/26/2016 03:08 PM, Geert Uytterhoeven wrote:
>>> Here's the set of 8 patches against Simon Horman's 'renesas.git'
>>> repo's
>>> 'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support
>>> for
>>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the
>>> board
>>> seems identical to the R8A7791/Porter board. The device tree patches
>>> depend on
>>> the R8A7743 CPG/MSSR driver series just posted in order to compile and
>>> work.
>>
>>
>> They depend only on "[PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock
>> index macros" of that series, right?
>>
>> "[PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support" is not
>> needed,
>
> How would "clocks" props _work_ without this patch?
Sorry, I was focusing too much on "compile"...
Got my coke, switching brain to overdrive mode...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-26 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUNgnYc1O7DATNH1r9SQ72eqtxwFvqcen08Tq+Er3LuvQ@mail.gmail.com>
On 10/26/2016 03:08 PM, Geert Uytterhoeven wrote:
>> Here's the set of 8 patches against Simon Horman's 'renesas.git' repo's
>> 'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support for
>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
>> seems identical to the R8A7791/Porter board. The device tree patches depend on
>> the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>
> They depend only on "[PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock
> index macros" of that series, right?
>
> "[PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support" is not needed,
How would "clocks" props _work_ without this patch?
> and introduces an additional dependency on "[PATCH 1/3] clk: renesas:
> cpg-mssr: add common R-Car Gen2 support".
Yes, of course...
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Lorenzo Pieralisi @ 2016-10-26 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025183436.GF3716@linux.vnet.ibm.com>
On Tue, Oct 25, 2016 at 11:34:36AM -0700, Paul E. McKenney wrote:
[...]
> > > +static int __init psci_checker(void)
> > > +{
> > > + int ret;
> > > +
> > > + /*
> > > + * Since we're in an initcall, we assume that all the CPUs that all
> > > + * CPUs that can be onlined have been onlined.
> > > + *
> > > + * The tests assume that hotplug is enabled but nobody else is using it,
> > > + * otherwise the results will be unpredictable. However, since there
> > > + * is no userspace yet in initcalls, that should be fine.
> >
> > I do not think it is. If you run a kernel with, say,
> > CONFIG_LOCK_TORTURE_TEST, cpus may disappear from the radar while
> > running the PSCI checker test itself; that at least would confuse the
> > checker, and that's just an example.
> >
> > I added Paul to check what are the assumptions behind the torture test
> > hotplug tests, in particular if there are any implicit assumptions for
> > it to work (ie it is the only kernel test hotplugging cpus in and out
> > (?)), what I know is that the PSCI checker assumptions are not correct.
>
> Both CONFIG_LOCK_TORTURE_TEST and CONFIG_RCU_TORTURE_TEST can and will
> hotplug CPUs. The locktorture.onoff_holdoff and rcutorture.onoff_holdoff
> kernel parameters can delay the start of CPU-hotplug testing, and in
> my testing I set this delay to 30 seconds after boot.
>
> One approach would be to make your test refuse to run if either of
> the lock/RCU torture tests was running. Or do what Lorenzo suggests
> below. The torture tests aren't crazy enough to offline the last CPU.
> Though they do try, just for effect, in cases where the last CPU is
> marked cpu_is_hotpluggable(). ;-)
Thank you Paul. I have an additional question though. Is there any
implicit assumption in LOCK/RCU torture tests whereby nothing else
in the kernel is hotplugging cpus in/out (through cpu_down()/up())
while they are running ?
I am asking because that's the main reason behind my query. Those tests
hotplug cpus in and out through cpu_down/up() but AFAICS nothing
prevents another piece of code in the kernel to call those functions and
the tests may just fail in that case (ie trying to cpu_down() a cpu
that is not online).
Are false negatives contemplated (or I am missing something) ?
I just would like to understand if what this patch currently does
is safe and sound. I think that calling cpu_down() and cpu_up()
is always safe, but the test can result in false negatives if
other kernel subsystems (eg LOCK torture test) are calling those
APIs in parallel (because cpu_down()/cpu_up() calls can fail - eg
trying to cpu_down() a cpu that is not online any longer, since it
was taken down by another kernel control path), that's the question
I have.
Thanks !
Lorenzo
>
> Thanx, Paul
>
> > There is something simple you can do to get this "fixed".
> >
> > You can use the new API James implemented for hibernate,
> > that allows you to disable (ie PSCI CPU OFF) all "secondary" cpus
> > other than the primary one passed in as parameter:
> >
> > freeze_secondary_cpus(int primary);
> >
> > that function will _cpu_down() all online cpus other than "primary"
> > in one go, without any interference allowed from other bits of the
> > kernel. It requires an enable_nonboot_cpus() counterpart, and you
> > can do that for every online cpus you detect (actually you can even
> > avoid using the online cpu mask and use the present mask to carry
> > out the test). If there is a resident trusted OS you can just
> > trigger the test with primary == tos_resident_cpu, since all
> > others are bound to fail (well, you can run them and check they
> > do fail, it is a checker after all).
> >
> > You would lose the capability of hotplugging a "cluster" at a time, but
> > I do not think it is a big problem, the test above would cover it
> > and more importantly, it is safe to execute.
> >
> > Or we can augment the torture test API to restrict the cpumask
> > it actually uses to offline/online cpus (I am referring to
> > torture_onoff(), kernel/torture.c).
> >
> > Further comments appreciated since I am not sure I grokked the
> > assumption the torture tests make about hotplugging cpus in and out,
> > I will go through the commits logs again to find more info.
> >
> > Thanks !
> > Lorenzo
> >
> > > + */
> > > + nb_available_cpus = num_online_cpus();
> > > +
> > > + /* Check PSCI operations are set up and working. */
> > > + ret = psci_ops_check();
> > > + if (ret)
> > > + return ret;
> > > +
> > > + pr_info("PSCI checker started using %u CPUs\n", nb_available_cpus);
> > > +
> > > + pr_info("Starting hotplug tests\n");
> > > + ret = hotplug_tests();
> > > + if (ret == 0)
> > > + pr_info("Hotplug tests passed OK\n");
> > > + else if (ret > 0)
> > > + pr_err("%d error(s) encountered in hotplug tests\n", ret);
> > > + else {
> > > + pr_err("Out of memory\n");
> > > + return ret;
> > > + }
> > > +
> > > + pr_info("Starting suspend tests (%d cycles per state)\n",
> > > + NUM_SUSPEND_CYCLE);
> > > + ret = suspend_tests();
> > > + if (ret == 0)
> > > + pr_info("Suspend tests passed OK\n");
> > > + else if (ret > 0)
> > > + pr_err("%d error(s) encountered in suspend tests\n", ret);
> > > + else {
> > > + switch (ret) {
> > > + case -ENOMEM:
> > > + pr_err("Out of memory\n");
> > > + break;
> > > + case -ENODEV:
> > > + pr_warn("Could not start suspend tests on any CPU\n");
> > > + break;
> > > + }
> > > + }
> > > +
> > > + pr_info("PSCI checker completed\n");
> > > + return ret < 0 ? ret : 0;
> > > +}
> > > +late_initcall(psci_checker);
> > > --
> > > 2.10.0
> > >
> >
>
^ permalink raw reply
* [PATCH] mfd: qcom-pm8xxx: Clean up PM8XXX namespace
From: Linus Walleij @ 2016-10-26 13:10 UTC (permalink / raw)
To: linux-arm-kernel
The Kconfig and file naming for the PM8xxx driver is totally
confusing:
- Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel
users depending on or selecting either at random.
- A driver file named pm8921-core.c even if it is indeed
used by the whole PM8xxx family of chips.
- An irqchip named pm8xxx since it was (I guess) realized that
the driver was generic for all pm8xxx PMICs.
As I may want to add support for PM8901 this is starting to get
really messy. Fix this situation by:
- Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX
and convert all users, including LEDs Kconfig and ARM defconfigs
for qcom and multi_v7 to use that single symbol.
- Renaming the driver to qcom-pm8xxx.c to fit along the two
other qcom* prefixed drivers.
- Rename functions withing the driver from 8921 to 8xxx to
indicate it is generic.
- Just drop the =m config from the pxa_defconfig, I have no clue
why it is even there, it is not a Qualcomm platform. (Possibly
older Kconfig noise from saveconfig.)
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I do NOT think it is a good idea to try to split this commit up,
I rather prefer that Lee simply merge it into MFD.
The reason is that files like qcom_defconfig already contain both
the right symbols, but the MFD_PM8921_CORE symbol cannot be removed
until this rename has happened, whereas multi_v7_defconfig needs
it added etc, and this is just a clean nice cut.
Jacek, ARM SoC person: please ACK this patch to get merged into
MFD.
---
arch/arm/configs/multi_v7_defconfig | 2 +-
arch/arm/configs/pxa_defconfig | 1 -
arch/arm/configs/qcom_defconfig | 1 -
drivers/leds/Kconfig | 2 +-
drivers/mfd/Kconfig | 14 ++++------
drivers/mfd/Makefile | 2 +-
drivers/mfd/{pm8921-core.c => qcom-pm8xxx.c} | 42 ++++++++++++++--------------
7 files changed, 29 insertions(+), 35 deletions(-)
rename drivers/mfd/{pm8921-core.c => qcom-pm8xxx.c} (92%)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 437d0740dec6..4280de7b9b4e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -489,7 +489,7 @@ CONFIG_MFD_MAX8907=y
CONFIG_MFD_MAX8997=y
CONFIG_MFD_MAX8998=y
CONFIG_MFD_RK808=y
-CONFIG_MFD_PM8921_CORE=y
+CONFIG_MFD_PM8XXX=y
CONFIG_MFD_QCOM_RPM=y
CONFIG_MFD_SPMI_PMIC=y
CONFIG_MFD_SEC_CORE=y
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index a016ecc0084b..e4314b1227a3 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -411,7 +411,6 @@ CONFIG_MFD_MAX77693=y
CONFIG_MFD_MAX8907=m
CONFIG_EZX_PCAP=y
CONFIG_UCB1400_CORE=m
-CONFIG_MFD_PM8921_CORE=m
CONFIG_MFD_SEC_CORE=y
CONFIG_MFD_PALMAS=y
CONFIG_MFD_TPS65090=y
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index c2dff4fd5fc4..74e9cd759b99 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -119,7 +119,6 @@ CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_MSM=y
CONFIG_THERMAL=y
CONFIG_MFD_PM8XXX=y
-CONFIG_MFD_PM8921_CORE=y
CONFIG_MFD_QCOM_RPM=y
CONFIG_MFD_SPMI_PMIC=y
CONFIG_REGULATOR=y
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7a628c6516f6..86bb1515a00e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -645,7 +645,7 @@ config LEDS_VERSATILE
config LEDS_PM8058
tristate "LED Support for the Qualcomm PM8058 PMIC"
- depends on MFD_PM8921_CORE
+ depends on MFD_PM8XXX
depends on LEDS_CLASS
help
Choose this option if you want to use the LED drivers in
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df6442ba2b..1ed0584f494e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -756,24 +756,20 @@ config UCB1400_CORE
module will be called ucb1400_core.
config MFD_PM8XXX
- tristate
-
-config MFD_PM8921_CORE
- tristate "Qualcomm PM8921 PMIC chip"
+ tristate "Qualcomm PM8xxx PMIC chips driver"
depends on (ARM || HEXAGON)
select IRQ_DOMAIN
select MFD_CORE
- select MFD_PM8XXX
select REGMAP
help
If you say yes to this option, support will be included for the
- built-in PM8921 PMIC chip.
+ built-in PM8xxx PMIC chips.
- This is required if your board has a PM8921 and uses its features,
+ This is required if your board has a PM8xxx and uses its features,
such as: MPPs, GPIOs, regulators, interrupts, and PWM.
- Say M here if you want to include support for PM8921 chip as a module.
- This will build a module called "pm8921-core".
+ Say M here if you want to include support for PM8xxx chips as a
+ module. This will build a module called "pm8xxx-core".
config MFD_QCOM_RPM
tristate "Qualcomm Resource Power Manager (RPM)"
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 9834e669d985..7bb5a50127cb 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -172,7 +172,7 @@ obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
-obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o ssbi.o
+obj-$(CONFIG_MFD_PM8XXX) += qcom-pm8xxx.o ssbi.o
obj-$(CONFIG_MFD_QCOM_RPM) += qcom_rpm.o
obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/qcom-pm8xxx.c
similarity index 92%
rename from drivers/mfd/pm8921-core.c
rename to drivers/mfd/qcom-pm8xxx.c
index 0e3a2ea25942..7f9620ec61e8 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/qcom-pm8xxx.c
@@ -53,7 +53,7 @@
#define REG_HWREV 0x002 /* PMIC4 revision */
#define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
-#define PM8921_NR_IRQS 256
+#define PM8XXX_NR_IRQS 256
struct pm_irq_chip {
struct regmap *regmap;
@@ -308,22 +308,22 @@ static const struct regmap_config ssbi_regmap_config = {
.reg_write = ssbi_reg_write
};
-static const struct of_device_id pm8921_id_table[] = {
+static const struct of_device_id pm8xxx_id_table[] = {
{ .compatible = "qcom,pm8018", },
{ .compatible = "qcom,pm8058", },
{ .compatible = "qcom,pm8921", },
{ }
};
-MODULE_DEVICE_TABLE(of, pm8921_id_table);
+MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
-static int pm8921_probe(struct platform_device *pdev)
+static int pm8xxx_probe(struct platform_device *pdev)
{
struct regmap *regmap;
int irq, rc;
unsigned int val;
u32 rev;
struct pm_irq_chip *chip;
- unsigned int nirqs = PM8921_NR_IRQS;
+ unsigned int nirqs = PM8XXX_NR_IRQS;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -384,46 +384,46 @@ static int pm8921_probe(struct platform_device *pdev)
return rc;
}
-static int pm8921_remove_child(struct device *dev, void *unused)
+static int pm8xxx_remove_child(struct device *dev, void *unused)
{
platform_device_unregister(to_platform_device(dev));
return 0;
}
-static int pm8921_remove(struct platform_device *pdev)
+static int pm8xxx_remove(struct platform_device *pdev)
{
int irq = platform_get_irq(pdev, 0);
struct pm_irq_chip *chip = platform_get_drvdata(pdev);
- device_for_each_child(&pdev->dev, NULL, pm8921_remove_child);
+ device_for_each_child(&pdev->dev, NULL, pm8xxx_remove_child);
irq_set_chained_handler_and_data(irq, NULL, NULL);
irq_domain_remove(chip->irqdomain);
return 0;
}
-static struct platform_driver pm8921_driver = {
- .probe = pm8921_probe,
- .remove = pm8921_remove,
+static struct platform_driver pm8xxx_driver = {
+ .probe = pm8xxx_probe,
+ .remove = pm8xxx_remove,
.driver = {
- .name = "pm8921-core",
- .of_match_table = pm8921_id_table,
+ .name = "pm8xxx-core",
+ .of_match_table = pm8xxx_id_table,
},
};
-static int __init pm8921_init(void)
+static int __init pm8xxx_init(void)
{
- return platform_driver_register(&pm8921_driver);
+ return platform_driver_register(&pm8xxx_driver);
}
-subsys_initcall(pm8921_init);
+subsys_initcall(pm8xxx_init);
-static void __exit pm8921_exit(void)
+static void __exit pm8xxx_exit(void)
{
- platform_driver_unregister(&pm8921_driver);
+ platform_driver_unregister(&pm8xxx_driver);
}
-module_exit(pm8921_exit);
+module_exit(pm8xxx_exit);
MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("PMIC 8921 core driver");
+MODULE_DESCRIPTION("PMIC 8xxx core driver");
MODULE_VERSION("1.0");
-MODULE_ALIAS("platform:pm8921-core");
+MODULE_ALIAS("platform:pm8xxx-core");
--
2.7.4
^ permalink raw reply related
* [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
From: Ard Biesheuvel @ 2016-10-26 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871sz3xw1s.fsf@concordia.ellerman.id.au>
On 26 October 2016 at 11:07, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Hi Ard,
>
> I like the concept, but ...
>
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>> The symbol CRCs are emitted as ELF symbols, which allows us to easily
>> populate the kcrctab sections by relying on the linker to associate
>> each kcrctab slot with the correct value.
>>
>> This has two downsides:
>> - given that the CRCs are treated as pointers, we waste 4 bytes for
>> each CRC on 64 bit architectures,
>> - on architectures that support runtime relocation, a relocation entry is
>> emitted for each CRC value, which may take up 24 bytes of __init space
>> (on ELF64 systems)
>>
>> This comes down to a x8 overhead in [uncompressed] kernel size. In addition,
>> each relocation has to be reverted before the CRC value can be used.
>>
>> Switching to explicit 32 bit values on 64 bit architectures fixes both
>> issues, since 32 bit values are not treated as relocatable quantities on
>> ELF64 systems, even if the value ultimately resolves to a linker supplied
>> value.
>
> Are we sure that part is true? ("not treated as relocatable")
>
Thanks for testing this.
> A quick test build on powerpc gives me:
>
> WARNING: 6829 bad relocations
> c000000000ca3748 R_PPC64_ADDR16 *ABS*+0x0000000013f53da6
> c000000000ca374a R_PPC64_ADDR16 *ABS*+0x00000000f7272059
> c000000000ca374c R_PPC64_ADDR16 *ABS*+0x0000000002013d36
> c000000000ca374e R_PPC64_ADDR16 *ABS*+0x00000000a59dffc8
> ...
>
> Which is coming from our relocs_check.sh script, which checks that the
> generated relocations are ones we know how to handle.
>
OK, first of all, it appears the ppc64 assembler interprets .word
differently than the arm64 one, so I will need to fold this in
"""
diff --git a/include/linux/export.h b/include/linux/export.h
index fa51ab2ad190..a000d421526d 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -54,7 +54,7 @@ extern struct module __this_module;
#define __CRC_SYMBOL(sym, sec) \
asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
" .weak " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
- " .word " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
+ " .long " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
" .previous \n");
#endif
#else
"""
With that change, the CRCs are actually emitted as
WARNING: 7525 bad relocations
c000000000ce7f50 R_PPC64_ADDR32 *ABS*+0x0000000013f53da6
c000000000ce7f54 R_PPC64_ADDR32 *ABS*+0x0000000004f7c64e
c000000000ce7f58 R_PPC64_ADDR32 *ABS*+0x0000000092be8a3e
which is still a bit disappointing, given that we still have 7525 RELA
entries to process.
I tried several thing, i.e., adding -Bsymbolic to the linker command
line, emitting the reference above as .hidden or emit the definition
from the linker script as HIDDEN(), but nothing seems to make any
difference. (On arm64, -Bsymbolic eliminates *all* runtime relocations
except R_<arch>_RELATIVE ones)
> And when I try to boot it I get:
>
> virtio: disagrees about version of symbol module_layout
> virtio: disagrees about version of symbol module_layout
> scsi_mod: disagrees about version of symbol module_layout
>
> And it can't find my root file system (unsurprisingly as it's on scsi).
>
Something like the below should fix it, I hope.
"""
diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
index d88736fbece6..99cdf2311ab5 100644
--- a/arch/powerpc/kernel/reloc_64.S
+++ b/arch/powerpc/kernel/reloc_64.S
@@ -14,6 +14,7 @@
RELA = 7
RELACOUNT = 0x6ffffff9
R_PPC64_RELATIVE = 22
+R_PPC64_ADDR32 = 1
/*
* r3 = desired final address of kernel
@@ -77,9 +78,22 @@ _GLOBAL(relocate)
add r0,r0,r3
stdx r0,r7,r6
addi r9,r9,24
- bdnz 5b
+ b 7f
+
+ /*
+ * CRCs of exported symbols are emitted as 32-bit relocations against
+ * the *ABS* section with the CRC value recorded in the addend.
+ */
+6: cmpdi r0,R_PPC64_ADDR32
+ bne 7f
+ ld r6,0(r9) /* reloc->r_offset */
+ ld r0,16(r9) /* reloc->r_addend */
+ stwx r0,r7,r6
+ addi r9,r9,24
+
+7: bdnz 5b
+ blr
-6: blr
.balign 8
p_dyn: .llong __dynamic_start - 0b
"""
Note that the loop no longer terminates at the first
non-R_PPC64_RELATIVE relocation, but that seems safer to me in any
case. It simply stores the value of r_addend at r_offset, which is the
correct thing to do for R_PPC64_ADDR32 relocations against the *ABS*
section, regardless of whether we are dealing with CRCs or something
else. Note that the comparison above will fail for R_PPC64_ADDR32
relocations against named symbols, since we compare the entire r_info
field and not just the type (as the comment a few lines higher up
suggests)
Also a fix for relocs_check.sh:
"""
diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
index ec2d5c835170..2f510fbc87da 100755
--- a/arch/powerpc/relocs_check.sh
+++ b/arch/powerpc/relocs_check.sh
@@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
R_PPC_RELATIVE
R_PPC_NONE' |
grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
- grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
+ grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
+ grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
)
if [ -z "$bad_relocs" ]; then
"""
If these changes work for PPC, I think we should fold them in.
Hopefully, GNU ld for PPC will gain that ability to resolve absolute
relocations@build time (like other architectures), and then the
R_PPC64_ADDR32 handling will simply become dead code. In any case, it
is an improvement over the mangling of CRC values to undo the runtime
relocation, imo.
Regards,
Ard.
^ permalink raw reply related
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-26 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026085620.GA5476@griffinp-ThinkPad-X1-Carbon-2nd>
> > > > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > > > to assume the hardware may have been used in previous boot stages, and it should
> > > > > not attempt to disable the clock.
> > > >
> > > > None of the boot loaders we use do this.
> > >
> > > But the Linux kernel isn't just used by us. It is not uncommon for STB
> > > bootloaders to get information from the frontend as part of the boot process.
> >
> > Okay, this is the clincher. Since we need to support non-standard
> > bootloaders, it's difficult to guarantee that the clock will be
> > disabled at boot. For this reason, I believe that we can call this a
> > critical clock.
> That's good news as the STi maintainer already acked and applied the patch.
Matters not. That's why we have `git rebase` and `git revert`. ;)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Daniel Vetter @ 2016-10-26 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58107523.20409@huawei.com>
On Wed, Oct 26, 2016 at 05:19:31PM +0800, Rongrong Zou wrote:
> Hi Daniel,
>
> Thansk for reviewing!
>
> ? 2016/10/26 13:56, Daniel Vetter ??:
> > On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
> > > Add support for fbdev and kms fb management.
> > >
> > > Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> >
> > Small drive-by comment below.
> >
> > > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > > index db8d80e..d41138a 100644
> > > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > > @@ -20,9 +20,23 @@
> > > #define HIBMC_DRM_DRV_H
> > >
> > > #include <drm/drmP.h>
> > > +#include <drm/drm_fb_helper.h>
> > > #include <drm/ttm/ttm_bo_driver.h>
> > > #include <drm/drm_gem.h>
> > >
> > > +struct hibmc_framebuffer {
> > > + struct drm_framebuffer fb;
> > > + struct drm_gem_object *obj;
> > > + bool is_fbdev_fb;
> > > +};
> > > +
> > > +struct hibmc_fbdev {
> > > + struct drm_fb_helper helper;
> > > + struct hibmc_framebuffer fb;
> >
> > I wouldn't embed the single framebuffer here, but instead have a pointer
> > and just refcount it. This here is a pattern that predates framebuffer
> > refcounting, and it leads to plenty of surprises.
>
> will allocate fbdev in next patch version, thanks.
Not the fbdev, the hibmc_framebuffer.
> > Maybe we should update the documentation of
> > drm_framebuffer_unregister_private() to mention that it is deprecated? The
> > overview doc in drm_framebuffer.c already explains that, but I guess
> > that's not obvious enough.
>
> Just replace drm_framebuffer_unregister_private() with
> drm_framebuffer_remove()?
>
> I found many other drivers use the following two functions in their
> own xxx_fbdev_destroy():
> drm_framebuffer_unregister_private(fbdev->fb);
> drm_framebuffer_remove(fbdev->fb);
> so the former is redundant and can be removed directly?
They all embed the fb instead of having a pointer, because those drivers
are all older than the fb refcounting support. In general good practice is
to look at the most recently merged driver, not at all of them. Only the
most recently one has a good chance to be up-to-date with latest best
practices. The function to call would be drm_framebuffer_unreference(),
and your struct above should be
struct hibmc_fbdev {
struct drm_fb_helper helper;
struct hibmc_framebuffer *fb;
...
};
Note how fb is a pointer here, not an embedded struct.
-Daniel
>
> >
> > Can you pls do that patch? And pls make sure it all looks pretty when
> > building the docs with
>
> No problem, i'll send another patch later.
>
> Regards,
> Rongrong
>
> >
> > $ make htmldocs
> >
> > Thanks, Daniel
> >
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 3/4] mfd: altr-a10sr: Add Arria10 SR Monitor
From: Lee Jones @ 2016-10-26 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476394329-31696-4-git-send-email-tthayer@opensource.altera.com>
On Thu, 13 Oct 2016, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> Add the Altera Arria10 DevKit System Resource Monitor functionality
> to the MFD device.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> drivers/mfd/altera-a10sr.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/altera-a10sr.c b/drivers/mfd/altera-a10sr.c
> index 06e1f7f..0942d7d 100644
> --- a/drivers/mfd/altera-a10sr.c
> +++ b/drivers/mfd/altera-a10sr.c
> @@ -33,6 +33,10 @@
> .name = "altr_a10sr_gpio",
> .of_compatible = "altr,a10sr-gpio",
> },
> + {
> + .name = "altr_a10sr_mon",
> + .of_compatible = "altr,a10sr-mon",
"-monitor" would be better in my opinion.
> + },
> };
>
> static bool altr_a10sr_reg_readable(struct device *dev, unsigned int reg)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Lee Jones @ 2016-10-26 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476394329-31696-2-git-send-email-tthayer@opensource.altera.com>
On Thu, 13 Oct 2016, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> Add the Arria10 DevKit System Resource Chip register and state
> monitoring module to the MFD.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> Note: This needs to be applied to the bindings document that
> was Acked & Applied but didn't reach the for-next branch.
> See https://patchwork.ozlabs.org/patch/629397/
> ---
> ---
> .../devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> index ea151f2..0787ec6 100644
> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
> Device Description
> ------ ----------
> a10sr_gpio GPIO Controller
> +a10sr_monitor Register and State Monitoring
>
> Arria10 GPIO
> Required Properties:
> @@ -27,6 +28,10 @@ Required Properties:
> the second cell is used to specify flags.
> See ../gpio/gpio.txt for more information.
>
> +Arria10 Register and State Monitor
> +Required Properties:
> +- compatible : Should be "altr,a10sr-mon"
Why not "-monitor"?
> Example:
>
> resource-manager at 0 {
> @@ -43,4 +48,8 @@ Example:
> gpio-controller;
> #gpio-cells = <2>;
> };
> +
> + a10sr_monitor {
> + compatible = "altr,a10sr-mon";
> + };
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] ARM: davinci: da8xx: Fix some redefined symbol warnings
From: Alexandre Bailon @ 2016-10-26 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3dc1c2c2-c4c5-07d0-3d3e-b8d917adda81@ti.com>
On 10/26/2016 01:57 PM, Sekhar Nori wrote:
> On Tuesday 25 October 2016 05:41 PM, Alexandre Bailon wrote:
>> Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
>> but da8xx-cfgchip.h intend to replace them.
>> The usb-da8xx.c is using both headers, causing redefined symbol warnings.
>> Remove the macro and update the da830-evm board file to use da8xx-cfgchip.h
>>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>
> This leads to build error on v4.9-rc2:
Oops! Sorry for that. I will fit it.
>
> arch/arm/mach-davinci/board-da830-evm.c: In function 'da830_evm_usb_init':
> arch/arm/mach-davinci/board-da830-evm.c:120:15: error: 'CFGCHIP2_REFFREQ' undeclared (first use in this function)
> cfgchip2 &= ~CFGCHIP2_REFFREQ;
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v3] ARM: davinci: da8xx: Fix some redefined symbol warnings
From: Alexandre Bailon @ 2016-10-26 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477485542-10555-1-git-send-email-abailon@baylibre.com>
Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
but da8xx-cfgchip.h intend to replace them.
The usb-da8xx.c is using both headers, causing redefined symbol warnings.
Remove the macro and update the board files to use da8xx-cfgchip.h
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 5 +++--
arch/arm/mach-davinci/board-omapl138-hawk.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3d8cf8c..32ee227 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -27,6 +27,7 @@
#include <linux/platform_data/mtd-davinci-aemif.h>
#include <linux/platform_data/spi-davinci.h>
#include <linux/platform_data/usb-davinci.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -116,7 +117,7 @@ static __init void da830_evm_usb_init(void)
cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
/* USB2.0 PHY reference clock is 24 MHz */
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
/*
@@ -133,7 +134,7 @@ static __init void da830_evm_usb_init(void)
* controller won't be able to drive VBUS thinking that it's a B-device.
* Otherwise, we want to use the OTG mode and enable VBUS comparators.
*/
- cfgchip2 &= ~CFGCHIP2_OTGMODE;
+ cfgchip2 &= ~CFGCHIP2_OTGMODE_MASK;
#ifdef CONFIG_USB_MUSB_HOST
cfgchip2 |= CFGCHIP2_FORCE_HOST;
#else
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index ee62486..5774742 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -14,6 +14,7 @@
#include <linux/console.h>
#include <linux/gpio.h>
#include <linux/platform_data/gpio-davinci.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -254,7 +255,7 @@ static __init void omapl138_hawk_usb_init(void)
/* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
__raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
diff --git a/include/linux/platform_data/usb-davinci.h b/include/linux/platform_data/usb-davinci.h
index e0bc4ab..0926e99 100644
--- a/include/linux/platform_data/usb-davinci.h
+++ b/include/linux/platform_data/usb-davinci.h
@@ -11,29 +11,6 @@
#ifndef __ASM_ARCH_USB_H
#define __ASM_ARCH_USB_H
-/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */
-#define CFGCHIP2_PHYCLKGD (1 << 17)
-#define CFGCHIP2_VBUSSENSE (1 << 16)
-#define CFGCHIP2_RESET (1 << 15)
-#define CFGCHIP2_OTGMODE (3 << 13)
-#define CFGCHIP2_NO_OVERRIDE (0 << 13)
-#define CFGCHIP2_FORCE_HOST (1 << 13)
-#define CFGCHIP2_FORCE_DEVICE (2 << 13)
-#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 << 13)
-#define CFGCHIP2_USB1PHYCLKMUX (1 << 12)
-#define CFGCHIP2_USB2PHYCLKMUX (1 << 11)
-#define CFGCHIP2_PHYPWRDN (1 << 10)
-#define CFGCHIP2_OTGPWRDN (1 << 9)
-#define CFGCHIP2_DATPOL (1 << 8)
-#define CFGCHIP2_USB1SUSPENDM (1 << 7)
-#define CFGCHIP2_PHY_PLLON (1 << 6) /* override PLL suspend */
-#define CFGCHIP2_SESENDEN (1 << 5) /* Vsess_end comparator */
-#define CFGCHIP2_VBDTCTEN (1 << 4) /* Vbus comparator */
-#define CFGCHIP2_REFFREQ (0xf << 0)
-#define CFGCHIP2_REFFREQ_12MHZ (1 << 0)
-#define CFGCHIP2_REFFREQ_24MHZ (2 << 0)
-#define CFGCHIP2_REFFREQ_48MHZ (3 << 0)
-
struct da8xx_ohci_root_hub;
typedef void (*da8xx_ocic_handler_t)(struct da8xx_ohci_root_hub *hub,
--
2.7.3
^ permalink raw reply related
* [PATCH v3] Fix some potential warnings
From: Alexandre Bailon @ 2016-10-26 12:39 UTC (permalink / raw)
To: linux-arm-kernel
Some changes I'm working on causes some warning because two included
headers defines the same macros.
Change in V2:
Update the d830 evm board file to use the da8xx-cfgchip.h
These changes are required as I'm sending this patch apart from
the series "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx"
Change in v3:
Fix build issues happening in omapl138 hawk and da830 evm board files.
Alexandre Bailon (1):
ARM: davinci: da8xx: Fix some redefined symbol warnings
arch/arm/mach-davinci/board-da830-evm.c | 5 +++--
arch/arm/mach-davinci/board-omapl138-hawk.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
3 files changed, 5 insertions(+), 26 deletions(-)
--
2.7.3
^ permalink raw reply
* [PATCH 0/7] mfd: Fix all W=1 warnings
From: Lee Jones @ 2016-10-26 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5506538.euWBouSNJd@wuerfel>
On Thu, 15 Sep 2016, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 11:45:14 AM CEST Lee Jones wrote:
> > It really is as simple as it sounds!
> >
>
> I seem to have one that you didn't find.
Applied, thanks.
> 8<--------
> From 6c63171eba728fc6d8bc6358884deaccd4cee33d Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Thu, 4 Aug 2016 15:28:51 +0200
> Subject: [PATCH] mfd: tps65912: move regmap config into core driver
>
> When building with extra warnings enabled, most files including
> linux/mfd/tps65912.h warn about a static variable defined in the
> header:
>
> include/linux/mfd/tps65912.h:331:35: warning: 'tps65912_regmap_config' defined but not used [-Wunused-const-variable=]
>
> We also duplicate the data structure between the i2c and spi front-end
> drivers. Moving it into the driver code avoids the warning and
> the duplication.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
> index a88cfa80dbc4..f33567bc428d 100644
> --- a/drivers/mfd/tps65912-core.c
> +++ b/drivers/mfd/tps65912-core.c
> @@ -77,6 +77,23 @@ static struct regmap_irq_chip tps65912_irq_chip = {
> .init_ack_masked = true,
> };
>
> +static const struct regmap_range tps65912_yes_ranges[] = {
> + regmap_reg_range(TPS65912_INT_STS, TPS65912_GPIO5),
> +};
> +
> +static const struct regmap_access_table tps65912_volatile_table = {
> + .yes_ranges = tps65912_yes_ranges,
> + .n_yes_ranges = ARRAY_SIZE(tps65912_yes_ranges),
> +};
> +
> +const struct regmap_config tps65912_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .cache_type = REGCACHE_RBTREE,
> + .volatile_table = &tps65912_volatile_table,
> +};
> +EXPORT_SYMBOL_GPL(tps65912_regmap_config);
> +
> int tps65912_device_init(struct tps65912 *tps)
> {
> int ret;
> diff --git a/include/linux/mfd/tps65912.h b/include/linux/mfd/tps65912.h
> index 1a603701550e..b25d0297ba88 100644
> --- a/include/linux/mfd/tps65912.h
> +++ b/include/linux/mfd/tps65912.h
> @@ -319,21 +319,7 @@ struct tps65912 {
> struct regmap_irq_chip_data *irq_data;
> };
>
> -static const struct regmap_range tps65912_yes_ranges[] = {
> - regmap_reg_range(TPS65912_INT_STS, TPS65912_GPIO5),
> -};
> -
> -static const struct regmap_access_table tps65912_volatile_table = {
> - .yes_ranges = tps65912_yes_ranges,
> - .n_yes_ranges = ARRAY_SIZE(tps65912_yes_ranges),
> -};
> -
> -static const struct regmap_config tps65912_regmap_config = {
> - .reg_bits = 8,
> - .val_bits = 8,
> - .cache_type = REGCACHE_RBTREE,
> - .volatile_table = &tps65912_volatile_table,
> -};
> +extern const struct regmap_config tps65912_regmap_config;
>
> int tps65912_device_init(struct tps65912 *tps);
> int tps65912_device_exit(struct tps65912 *tps);
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Pinctrl nodes missing for USB
From: Anand Moon @ 2016-10-26 12:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
I have tried to enable CONFIG_DEBUG_PINCTRL=y on Odroid XU4.
Just to try to understand the feature.
Is this feature suppoted for USB nodes.
Below is the output of failed to pase pinctrl for USB nodes via dts.
[ 11.627809] samsung-pinctrl 13400000.pinctrl: request pin 39
(gpx3-7) for gpx3:39
[ 11.726818] xhci-hcd xhci-hcd.2.auto: no of_node; not parsing pinctrl DT
[ 11.801452] usb usb3: no of_node; not parsing pinctrl DT
[ 11.805471] hub 3-0:1.0: no of_node; not parsing pinctrl DT
[ 11.883263] usb usb4: no of_node; not parsing pinctrl DT
[ 11.887362] hub 4-0:1.0: no of_node; not parsing pinctrl DT
[ 11.926683] xhci-hcd xhci-hcd.5.auto: no of_node; not parsing pinctrl DT
[ 11.999588] usb usb5: no of_node; not parsing pinctrl DT
[ 12.003208] hub 5-0:1.0: no of_node; not parsing pinctrl DT
[ 12.085100] usb usb6: no of_node; not parsing pinctrl DT
[ 12.088936] hub 6-0:1.0: no of_node; not parsing pinctrl DT
[ 12.491299] usb 3-1: no of_node; not parsing pinctrl DT
[ 12.528446] hub 3-1:1.0: no of_node; not parsing pinctrl DT
[ 12.555071] usb 4-1: no of_node; not parsing pinctrl DT
[ 12.611412] hub 4-1:1.0: no of_node; not parsing pinctrl DT
[ 13.020668] usb 4-1.1: no of_node; not parsing pinctrl DT
[ 13.081803] usb-storage 4-1.1:1.0: no of_node; not parsing pinctrl DT
[ 13.091721] usb 5-1: no of_node; not parsing pinctrl DT
[ 13.127124] r8152 5-1:2.0: no of_node; not parsing pinctrl DT
[ 13.208321] r8152 5-1:1.0: no of_node; not parsing pinctrl DT
[ 14.281196] sd 0:0:0:0: no of_node; not parsing pinctrl DT
[ 16.057197] usb 4-1.2: no of_node; not parsing pinctrl DT
[ 16.079507] usb-storage 4-1.2:1.0: no of_node; not parsing pinctrl DT
[ 17.236626] sd 1:0:0:0: no of_node; not parsing pinctrl DT
[ 17.612139] usbhid 2-1:1.0: no of_node; not parsing pinctrl DT
[ 17.625511] usbhid 2-1:1.1: no of_node; not parsing pinctrl DT
[ 17.755059] hid-generic 0003:24AE:1000.0001: no of_node; not
parsing pinctrl DT
[ 17.933665] hid-generic 0003:24AE:1000.0002: no of_node; not
parsing pinctrl DT
[ 1009.259380] usb 4-1.2: no of_node; not parsing pinctrl DT
[ 1009.267240] usb-storage 4-1.2:1.0: no of_node; not parsing pinctrl DT
[ 1010.311832] sd 1:0:0:0: no of_node; not parsing pinctrl DT
Below is the complete output of dmesg | grep pinctr
-------------------------------------
root at odroidcsh:/usr/src/odroidxu3-4.y-devel# dmesg | grep pinc
[ 1.704176] pinctrl core: initialized pinctrl subsystem
[ 1.716053] reg-dummy reg-dummy: no of_node; not parsing pinctrl DT
[ 2.221885] samsung-pinctrl 13400000.pinctrl: try to register 40 pins ...
[ 2.221925] pinctrl core: registered pin 0 (gpy7-0) on samsung-pinctrl
[ 2.222005] pinctrl core: registered pin 1 (gpy7-1) on samsung-pinctrl
[ 2.222041] pinctrl core: registered pin 2 (gpy7-2) on samsung-pinctrl
[ 2.222077] pinctrl core: registered pin 3 (gpy7-3) on samsung-pinctrl
[ 2.222113] pinctrl core: registered pin 4 (gpy7-4) on samsung-pinctrl
[ 2.222148] pinctrl core: registered pin 5 (gpy7-5) on samsung-pinctrl
[ 2.222183] pinctrl core: registered pin 6 (gpy7-6) on samsung-pinctrl
[ 2.222217] pinctrl core: registered pin 7 (gpy7-7) on samsung-pinctrl
[ 2.222275] pinctrl core: registered pin 8 (gpx0-0) on samsung-pinctrl
[ 2.222320] pinctrl core: registered pin 9 (gpx0-1) on samsung-pinctrl
[ 2.222364] pinctrl core: registered pin 10 (gpx0-2) on samsung-pinctrl
[ 2.222406] pinctrl core: registered pin 11 (gpx0-3) on samsung-pinctrl
[ 2.222449] pinctrl core: registered pin 12 (gpx0-4) on samsung-pinctrl
[ 2.222491] pinctrl core: registered pin 13 (gpx0-5) on samsung-pinctrl
[ 2.222532] pinctrl core: registered pin 14 (gpx0-6) on samsung-pinctrl
[ 2.222573] pinctrl core: registered pin 15 (gpx0-7) on samsung-pinctrl
[ 2.222614] pinctrl core: registered pin 16 (gpx1-0) on samsung-pinctrl
[ 2.222653] pinctrl core: registered pin 17 (gpx1-1) on samsung-pinctrl
[ 2.222693] pinctrl core: registered pin 18 (gpx1-2) on samsung-pinctrl
[ 2.222732] pinctrl core: registered pin 19 (gpx1-3) on samsung-pinctrl
[ 2.222771] pinctrl core: registered pin 20 (gpx1-4) on samsung-pinctrl
[ 2.222809] pinctrl core: registered pin 21 (gpx1-5) on samsung-pinctrl
[ 2.222847] pinctrl core: registered pin 22 (gpx1-6) on samsung-pinctrl
[ 2.222885] pinctrl core: registered pin 23 (gpx1-7) on samsung-pinctrl
[ 2.222922] pinctrl core: registered pin 24 (gpx2-0) on samsung-pinctrl
[ 2.222958] pinctrl core: registered pin 25 (gpx2-1) on samsung-pinctrl
[ 2.222994] pinctrl core: registered pin 26 (gpx2-2) on samsung-pinctrl
[ 2.223030] pinctrl core: registered pin 27 (gpx2-3) on samsung-pinctrl
[ 2.223065] pinctrl core: registered pin 28 (gpx2-4) on samsung-pinctrl
[ 2.223100] pinctrl core: registered pin 29 (gpx2-5) on samsung-pinctrl
[ 2.223134] pinctrl core: registered pin 30 (gpx2-6) on samsung-pinctrl
[ 2.223168] pinctrl core: registered pin 31 (gpx2-7) on samsung-pinctrl
[ 2.223202] pinctrl core: registered pin 32 (gpx3-0) on samsung-pinctrl
[ 2.223258] pinctrl core: registered pin 33 (gpx3-1) on samsung-pinctrl
[ 2.223302] pinctrl core: registered pin 34 (gpx3-2) on samsung-pinctrl
[ 2.223345] pinctrl core: registered pin 35 (gpx3-3) on samsung-pinctrl
[ 2.223388] pinctrl core: registered pin 36 (gpx3-4) on samsung-pinctrl
[ 2.223430] pinctrl core: registered pin 37 (gpx3-5) on samsung-pinctrl
[ 2.223471] pinctrl core: registered pin 38 (gpx3-6) on samsung-pinctrl
[ 2.223512] pinctrl core: registered pin 39 (gpx3-7) on samsung-pinctrl
[ 2.324367] samsung-pinctrl 13410000.pinctrl: try to register 85 pins ...
[ 2.324441] pinctrl core: registered pin 40 (gpc0-0) on samsung-pinctrl
[ 2.324501] pinctrl core: registered pin 41 (gpc0-1) on samsung-pinctrl
[ 2.324547] pinctrl core: registered pin 42 (gpc0-2) on samsung-pinctrl
[ 2.324591] pinctrl core: registered pin 43 (gpc0-3) on samsung-pinctrl
[ 2.324634] pinctrl core: registered pin 44 (gpc0-4) on samsung-pinctrl
[ 2.324676] pinctrl core: registered pin 45 (gpc0-5) on samsung-pinctrl
[ 2.324718] pinctrl core: registered pin 46 (gpc0-6) on samsung-pinctrl
[ 2.324760] pinctrl core: registered pin 47 (gpc0-7) on samsung-pinctrl
[ 2.324801] pinctrl core: registered pin 48 (gpc1-0) on samsung-pinctrl
[ 2.324841] pinctrl core: registered pin 49 (gpc1-1) on samsung-pinctrl
[ 2.324881] pinctrl core: registered pin 50 (gpc1-2) on samsung-pinctrl
[ 2.324921] pinctrl core: registered pin 51 (gpc1-3) on samsung-pinctrl
[ 2.324960] pinctrl core: registered pin 52 (gpc1-4) on samsung-pinctrl
[ 2.324999] pinctrl core: registered pin 53 (gpc1-5) on samsung-pinctrl
[ 2.325038] pinctrl core: registered pin 54 (gpc1-6) on samsung-pinctrl
[ 2.325076] pinctrl core: registered pin 55 (gpc1-7) on samsung-pinctrl
[ 2.325113] pinctrl core: registered pin 56 (gpc2-0) on samsung-pinctrl
[ 2.325151] pinctrl core: registered pin 57 (gpc2-1) on samsung-pinctrl
[ 2.325187] pinctrl core: registered pin 58 (gpc2-2) on samsung-pinctrl
[ 2.325224] pinctrl core: registered pin 59 (gpc2-3) on samsung-pinctrl
[ 2.325259] pinctrl core: registered pin 60 (gpc2-4) on samsung-pinctrl
[ 2.325295] pinctrl core: registered pin 61 (gpc2-5) on samsung-pinctrl
[ 2.325330] pinctrl core: registered pin 62 (gpc2-6) on samsung-pinctrl
[ 2.325365] pinctrl core: registered pin 63 (gpc3-0) on samsung-pinctrl
[ 2.325468] pinctrl core: registered pin 64 (gpc3-1) on samsung-pinctrl
[ 2.325503] pinctrl core: registered pin 65 (gpc3-2) on samsung-pinctrl
[ 2.325560] pinctrl core: registered pin 66 (gpc3-3) on samsung-pinctrl
[ 2.325604] pinctrl core: registered pin 67 (gpc4-0) on samsung-pinctrl
[ 2.325647] pinctrl core: registered pin 68 (gpc4-1) on samsung-pinctrl
[ 2.325795] pinctrl core: registered pin 69 (gpd1-0) on samsung-pinctrl
[ 2.325839] pinctrl core: registered pin 70 (gpd1-1) on samsung-pinctrl
[ 2.325881] pinctrl core: registered pin 71 (gpd1-2) on samsung-pinctrl
[ 2.325923] pinctrl core: registered pin 72 (gpd1-3) on samsung-pinctrl
[ 2.325963] pinctrl core: registered pin 73 (gpd1-4) on samsung-pinctrl
[ 2.326004] pinctrl core: registered pin 74 (gpd1-5) on samsung-pinctrl
[ 2.326044] pinctrl core: registered pin 75 (gpd1-6) on samsung-pinctrl
[ 2.326084] pinctrl core: registered pin 76 (gpd1-7) on samsung-pinctrl
[ 2.326123] pinctrl core: registered pin 77 (gpy0-0) on samsung-pinctrl
[ 2.326163] pinctrl core: registered pin 78 (gpy0-1) on samsung-pinctrl
[ 2.326201] pinctrl core: registered pin 79 (gpy0-2) on samsung-pinctrl
[ 2.326239] pinctrl core: registered pin 80 (gpy0-3) on samsung-pinctrl
[ 2.326277] pinctrl core: registered pin 81 (gpy0-4) on samsung-pinctrl
[ 2.326314] pinctrl core: registered pin 82 (gpy0-5) on samsung-pinctrl
[ 2.326351] pinctrl core: registered pin 83 (gpy1-0) on samsung-pinctrl
[ 2.326387] pinctrl core: registered pin 84 (gpy1-1) on samsung-pinctrl
[ 2.326423] pinctrl core: registered pin 85 (gpy1-2) on samsung-pinctrl
[ 2.326459] pinctrl core: registered pin 86 (gpy1-3) on samsung-pinctrl
[ 2.326493] pinctrl core: registered pin 87 (gpy2-0) on samsung-pinctrl
[ 2.326528] pinctrl core: registered pin 88 (gpy2-1) on samsung-pinctrl
[ 2.326562] pinctrl core: registered pin 89 (gpy2-2) on samsung-pinctrl
[ 2.326596] pinctrl core: registered pin 90 (gpy2-3) on samsung-pinctrl
[ 2.326653] pinctrl core: registered pin 91 (gpy2-4) on samsung-pinctrl
[ 2.326697] pinctrl core: registered pin 92 (gpy2-5) on samsung-pinctrl
[ 2.326740] pinctrl core: registered pin 93 (gpy3-0) on samsung-pinctrl
[ 2.326782] pinctrl core: registered pin 94 (gpy3-1) on samsung-pinctrl
[ 2.326824] pinctrl core: registered pin 95 (gpy3-2) on samsung-pinctrl
[ 2.326866] pinctrl core: registered pin 96 (gpy3-3) on samsung-pinctrl
[ 2.326908] pinctrl core: registered pin 97 (gpy3-4) on samsung-pinctrl
[ 2.326949] pinctrl core: registered pin 98 (gpy3-5) on samsung-pinctrl
[ 2.326990] pinctrl core: registered pin 99 (gpy3-6) on samsung-pinctrl
[ 2.327030] pinctrl core: registered pin 100 (gpy3-7) on samsung-pinctrl
[ 2.327070] pinctrl core: registered pin 101 (gpy4-0) on samsung-pinctrl
[ 2.327110] pinctrl core: registered pin 102 (gpy4-1) on samsung-pinctrl
[ 2.327148] pinctrl core: registered pin 103 (gpy4-2) on samsung-pinctrl
[ 2.327187] pinctrl core: registered pin 104 (gpy4-3) on samsung-pinctrl
[ 2.327225] pinctrl core: registered pin 105 (gpy4-4) on samsung-pinctrl
[ 2.327263] pinctrl core: registered pin 106 (gpy4-5) on samsung-pinctrl
[ 2.327300] pinctrl core: registered pin 107 (gpy4-6) on samsung-pinctrl
[ 2.327337] pinctrl core: registered pin 108 (gpy4-7) on samsung-pinctrl
[ 2.327373] pinctrl core: registered pin 109 (gpy5-0) on samsung-pinctrl
[ 2.327409] pinctrl core: registered pin 110 (gpy5-1) on samsung-pinctrl
[ 2.327445] pinctrl core: registered pin 111 (gpy5-2) on samsung-pinctrl
[ 2.327479] pinctrl core: registered pin 112 (gpy5-3) on samsung-pinctrl
[ 2.327514] pinctrl core: registered pin 113 (gpy5-4) on samsung-pinctrl
[ 2.327548] pinctrl core: registered pin 114 (gpy5-5) on samsung-pinctrl
[ 2.327583] pinctrl core: registered pin 115 (gpy5-6) on samsung-pinctrl
[ 2.327639] pinctrl core: registered pin 116 (gpy5-7) on samsung-pinctrl
[ 2.327683] pinctrl core: registered pin 117 (gpy6-0) on samsung-pinctrl
[ 2.327726] pinctrl core: registered pin 118 (gpy6-1) on samsung-pinctrl
[ 2.327769] pinctrl core: registered pin 119 (gpy6-2) on samsung-pinctrl
[ 2.327812] pinctrl core: registered pin 120 (gpy6-3) on samsung-pinctrl
[ 2.327853] pinctrl core: registered pin 121 (gpy6-4) on samsung-pinctrl
[ 2.327894] pinctrl core: registered pin 122 (gpy6-5) on samsung-pinctrl
[ 2.327935] pinctrl core: registered pin 123 (gpy6-6) on samsung-pinctrl
[ 2.327976] pinctrl core: registered pin 124 (gpy6-7) on samsung-pinctrl
[ 2.381195] samsung-pinctrl 14000000.pinctrl: try to register 46 pins ...
[ 2.381304] pinctrl core: registered pin 125 (gpe0-0) on samsung-pinctrl
[ 2.381343] pinctrl core: registered pin 126 (gpe0-1) on samsung-pinctrl
[ 2.381381] pinctrl core: registered pin 127 (gpe0-2) on samsung-pinctrl
[ 2.381452] pinctrl core: registered pin 128 (gpe0-3) on samsung-pinctrl
[ 2.381489] pinctrl core: registered pin 129 (gpe0-4) on samsung-pinctrl
[ 2.381526] pinctrl core: registered pin 130 (gpe0-5) on samsung-pinctrl
[ 2.381562] pinctrl core: registered pin 131 (gpe0-6) on samsung-pinctrl
[ 2.381597] pinctrl core: registered pin 132 (gpe0-7) on samsung-pinctrl
[ 2.381633] pinctrl core: registered pin 133 (gpe1-0) on samsung-pinctrl
[ 2.381668] pinctrl core: registered pin 134 (gpe1-1) on samsung-pinctrl
[ 2.381702] pinctrl core: registered pin 135 (gpf0-0) on samsung-pinctrl
[ 2.381737] pinctrl core: registered pin 136 (gpf0-1) on samsung-pinctrl
[ 2.381794] pinctrl core: registered pin 137 (gpf0-2) on samsung-pinctrl
[ 2.381838] pinctrl core: registered pin 138 (gpf0-3) on samsung-pinctrl
[ 2.381881] pinctrl core: registered pin 139 (gpf0-4) on samsung-pinctrl
[ 2.381923] pinctrl core: registered pin 140 (gpf0-5) on samsung-pinctrl
[ 2.381965] pinctrl core: registered pin 141 (gpf1-0) on samsung-pinctrl
[ 2.382006] pinctrl core: registered pin 142 (gpf1-1) on samsung-pinctrl
[ 2.382048] pinctrl core: registered pin 143 (gpf1-2) on samsung-pinctrl
[ 2.382089] pinctrl core: registered pin 144 (gpf1-3) on samsung-pinctrl
[ 2.382129] pinctrl core: registered pin 145 (gpf1-4) on samsung-pinctrl
[ 2.382169] pinctrl core: registered pin 146 (gpf1-5) on samsung-pinctrl
[ 2.382209] pinctrl core: registered pin 147 (gpf1-6) on samsung-pinctrl
[ 2.382248] pinctrl core: registered pin 148 (gpf1-7) on samsung-pinctrl
[ 2.382287] pinctrl core: registered pin 149 (gpg0-0) on samsung-pinctrl
[ 2.382326] pinctrl core: registered pin 150 (gpg0-1) on samsung-pinctrl
[ 2.382363] pinctrl core: registered pin 151 (gpg0-2) on samsung-pinctrl
[ 2.382400] pinctrl core: registered pin 152 (gpg0-3) on samsung-pinctrl
[ 2.382437] pinctrl core: registered pin 153 (gpg0-4) on samsung-pinctrl
[ 2.382473] pinctrl core: registered pin 154 (gpg0-5) on samsung-pinctrl
[ 2.382509] pinctrl core: registered pin 155 (gpg0-6) on samsung-pinctrl
[ 2.382544] pinctrl core: registered pin 156 (gpg0-7) on samsung-pinctrl
[ 2.382580] pinctrl core: registered pin 157 (gpg1-0) on samsung-pinctrl
[ 2.382614] pinctrl core: registered pin 158 (gpg1-1) on samsung-pinctrl
[ 2.382649] pinctrl core: registered pin 159 (gpg1-2) on samsung-pinctrl
[ 2.382683] pinctrl core: registered pin 160 (gpg1-3) on samsung-pinctrl
[ 2.382717] pinctrl core: registered pin 161 (gpg1-4) on samsung-pinctrl
[ 2.382774] pinctrl core: registered pin 162 (gpg1-5) on samsung-pinctrl
[ 2.382818] pinctrl core: registered pin 163 (gpg1-6) on samsung-pinctrl
[ 2.382861] pinctrl core: registered pin 164 (gpg1-7) on samsung-pinctrl
[ 2.382903] pinctrl core: registered pin 165 (gpg2-0) on samsung-pinctrl
[ 2.382945] pinctrl core: registered pin 166 (gpg2-1) on samsung-pinctrl
[ 2.382987] pinctrl core: registered pin 167 (gpj4-0) on samsung-pinctrl
[ 2.383027] pinctrl core: registered pin 168 (gpj4-1) on samsung-pinctrl
[ 2.383068] pinctrl core: registered pin 169 (gpj4-2) on samsung-pinctrl
[ 2.383108] pinctrl core: registered pin 170 (gpj4-3) on samsung-pinctrl
[ 2.443773] samsung-pinctrl 14010000.pinctrl: try to register 54 pins ...
[ 2.443876] pinctrl core: registered pin 171 (gpa0-0) on samsung-pinctrl
[ 2.443912] pinctrl core: registered pin 172 (gpa0-1) on samsung-pinctrl
[ 2.443948] pinctrl core: registered pin 173 (gpa0-2) on samsung-pinctrl
[ 2.443983] pinctrl core: registered pin 174 (gpa0-3) on samsung-pinctrl
[ 2.444041] pinctrl core: registered pin 175 (gpa0-4) on samsung-pinctrl
[ 2.444085] pinctrl core: registered pin 176 (gpa0-5) on samsung-pinctrl
[ 2.444129] pinctrl core: registered pin 177 (gpa0-6) on samsung-pinctrl
[ 2.444172] pinctrl core: registered pin 178 (gpa0-7) on samsung-pinctrl
[ 2.444213] pinctrl core: registered pin 179 (gpa1-0) on samsung-pinctrl
[ 2.444255] pinctrl core: registered pin 180 (gpa1-1) on samsung-pinctrl
[ 2.444297] pinctrl core: registered pin 181 (gpa1-2) on samsung-pinctrl
[ 2.444338] pinctrl core: registered pin 182 (gpa1-3) on samsung-pinctrl
[ 2.444379] pinctrl core: registered pin 183 (gpa1-4) on samsung-pinctrl
[ 2.444419] pinctrl core: registered pin 184 (gpa1-5) on samsung-pinctrl
[ 2.444458] pinctrl core: registered pin 185 (gpa2-0) on samsung-pinctrl
[ 2.444497] pinctrl core: registered pin 186 (gpa2-1) on samsung-pinctrl
[ 2.444536] pinctrl core: registered pin 187 (gpa2-2) on samsung-pinctrl
[ 2.444575] pinctrl core: registered pin 188 (gpa2-3) on samsung-pinctrl
[ 2.444612] pinctrl core: registered pin 189 (gpa2-4) on samsung-pinctrl
[ 2.444650] pinctrl core: registered pin 190 (gpa2-5) on samsung-pinctrl
[ 2.444687] pinctrl core: registered pin 191 (gpa2-6) on samsung-pinctrl
[ 2.444756] pinctrl core: registered pin 192 (gpa2-7) on samsung-pinctrl
[ 2.444792] pinctrl core: registered pin 193 (gpb0-0) on samsung-pinctrl
[ 2.444828] pinctrl core: registered pin 194 (gpb0-1) on samsung-pinctrl
[ 2.444864] pinctrl core: registered pin 195 (gpb0-2) on samsung-pinctrl
[ 2.444899] pinctrl core: registered pin 196 (gpb0-3) on samsung-pinctrl
[ 2.444934] pinctrl core: registered pin 197 (gpb0-4) on samsung-pinctrl
[ 2.444968] pinctrl core: registered pin 198 (gpb1-0) on samsung-pinctrl
[ 2.445002] pinctrl core: registered pin 199 (gpb1-1) on samsung-pinctrl
[ 2.445059] pinctrl core: registered pin 200 (gpb1-2) on samsung-pinctrl
[ 2.445102] pinctrl core: registered pin 201 (gpb1-3) on samsung-pinctrl
[ 2.445145] pinctrl core: registered pin 202 (gpb1-4) on samsung-pinctrl
[ 2.445188] pinctrl core: registered pin 203 (gpb2-0) on samsung-pinctrl
[ 2.445231] pinctrl core: registered pin 204 (gpb2-1) on samsung-pinctrl
[ 2.445273] pinctrl core: registered pin 205 (gpb2-2) on samsung-pinctrl
[ 2.445314] pinctrl core: registered pin 206 (gpb2-3) on samsung-pinctrl
[ 2.445355] pinctrl core: registered pin 207 (gpb3-0) on samsung-pinctrl
[ 2.445395] pinctrl core: registered pin 208 (gpb3-1) on samsung-pinctrl
[ 2.445435] pinctrl core: registered pin 209 (gpb3-2) on samsung-pinctrl
[ 2.445475] pinctrl core: registered pin 210 (gpb3-3) on samsung-pinctrl
[ 2.445514] pinctrl core: registered pin 211 (gpb3-4) on samsung-pinctrl
[ 2.445553] pinctrl core: registered pin 212 (gpb3-5) on samsung-pinctrl
[ 2.445591] pinctrl core: registered pin 213 (gpb3-6) on samsung-pinctrl
[ 2.445629] pinctrl core: registered pin 214 (gpb3-7) on samsung-pinctrl
[ 2.445766] pinctrl core: registered pin 215 (gpb4-0) on samsung-pinctrl
[ 2.445806] pinctrl core: registered pin 216 (gpb4-1) on samsung-pinctrl
[ 2.445843] pinctrl core: registered pin 217 (gph0-0) on samsung-pinctrl
[ 2.445879] pinctrl core: registered pin 218 (gph0-1) on samsung-pinctrl
[ 2.445915] pinctrl core: registered pin 219 (gph0-2) on samsung-pinctrl
[ 2.445950] pinctrl core: registered pin 220 (gph0-3) on samsung-pinctrl
[ 2.445985] pinctrl core: registered pin 221 (gph0-4) on samsung-pinctrl
[ 2.446019] pinctrl core: registered pin 222 (gph0-5) on samsung-pinctrl
[ 2.446053] pinctrl core: registered pin 223 (gph0-6) on samsung-pinctrl
[ 2.446088] pinctrl core: registered pin 224 (gph0-7) on samsung-pinctrl
[ 2.459704] samsung-pinctrl 3860000.pinctrl: try to register 7 pins ...
[ 2.459809] pinctrl core: registered pin 225 (gpz-0) on samsung-pinctrl
[ 2.459849] pinctrl core: registered pin 226 (gpz-1) on samsung-pinctrl
[ 2.459888] pinctrl core: registered pin 227 (gpz-2) on samsung-pinctrl
[ 2.459927] pinctrl core: registered pin 228 (gpz-3) on samsung-pinctrl
[ 2.459965] pinctrl core: registered pin 229 (gpz-4) on samsung-pinctrl
[ 2.460003] pinctrl core: registered pin 230 (gpz-5) on samsung-pinctrl
[ 2.460040] pinctrl core: registered pin 231 (gpz-6) on samsung-pinctrl
[ 2.939603] pinctrl core: add 4 pinctrl maps
[ 2.939841] samsung-pinctrl 14010000.pinctrl: found group selector
6 for gpa0-6
[ 2.939894] samsung-pinctrl 14010000.pinctrl: found group selector
6 for gpa0-6
[ 2.939944] samsung-pinctrl 14010000.pinctrl: found group selector
7 for gpa0-7
[ 2.939992] samsung-pinctrl 14010000.pinctrl: found group selector
7 for gpa0-7
[ 2.940022] samsung-pinctrl 14010000.pinctrl: request pin 177
(gpa0-6) for 12c80000.i2c
[ 2.940089] samsung-pinctrl 14010000.pinctrl: request pin 178
(gpa0-7) for 12c80000.i2c
[ 2.941356] s3c-i2c 12c80000.i2c: obtain a copy of previously claimed pinctrl
[ 4.370371] alarmtimer alarmtimer: no of_node; not parsing pinctrl DT
[ 5.154339] pinctrl core: add 2 pinctrl maps
[ 5.154682] pinctrl core: add 2 pinctrl maps
[ 5.154943] samsung-pinctrl 14010000.pinctrl: found group selector
32 for gpb2-0
[ 5.155011] samsung-pinctrl 14010000.pinctrl: found group selector
32 for gpb2-0
[ 5.155082] samsung-pinctrl 14010000.pinctrl: found group selector
34 for gpb2-2
[ 5.155148] samsung-pinctrl 14010000.pinctrl: found group selector
34 for gpb2-2
[ 5.155183] samsung-pinctrl 14010000.pinctrl: request pin 203
(gpb2-0) for 12dd0000.pwm
[ 5.155224] samsung-pinctrl 14010000.pinctrl: request pin 205
(gpb2-2) for 12dd0000.pwm
[ 6.901592] serial8250 serial8250: no of_node; not parsing pinctrl DT
[ 9.157724] pinctrl core: add 2 pinctrl maps
[ 9.157952] samsung-pinctrl 13400000.pinctrl: found group selector
39 for gpx3-7
[ 9.158011] samsung-pinctrl 13400000.pinctrl: found group selector
39 for gpx3-7
[ 9.158041] samsung-pinctrl 13400000.pinctrl: request pin 39
(gpx3-7) for 14530000.hdmi
[ 9.158853] samsung-pinctrl 13400000.pinctrl: request pin 39
(gpx3-7) for gpx3:39
[ 9.169059] exynos-drm exynos-drm: no of_node; not parsing pinctrl DT
[ 9.683767] usb usb1: no of_node; not parsing pinctrl DT
[ 9.688758] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[ 9.854041] usb usb2: no of_node; not parsing pinctrl DT
[ 9.857966] hub 2-0:1.0: no of_node; not parsing pinctrl DT
[ 9.925566] pinctrl core: add 4 pinctrl maps
[ 9.925744] samsung-pinctrl 14010000.pinctrl: found group selector
14 for gpa2-0
[ 9.925992] samsung-pinctrl 14010000.pinctrl: found group selector
14 for gpa2-0
[ 9.926046] samsung-pinctrl 14010000.pinctrl: found group selector
15 for gpa2-1
[ 9.926092] samsung-pinctrl 14010000.pinctrl: found group selector
15 for gpa2-1
[ 9.926122] samsung-pinctrl 14010000.pinctrl: request pin 185
(gpa2-0) for 12ca0000.i2c
[ 9.926155] samsung-pinctrl 14010000.pinctrl: request pin 186
(gpa2-1) for 12ca0000.i2c
[ 9.938344] pinctrl core: add 2 pinctrl maps
[ 9.938564] samsung-pinctrl 13400000.pinctrl: found group selector
12 for gpx0-4
[ 9.938620] samsung-pinctrl 13400000.pinctrl: found group selector
12 for gpx0-4
[ 9.938649] samsung-pinctrl 13400000.pinctrl: request pin 12
(gpx0-4) for 4-0066
[ 9.951595] s2mps11-pmic s2mps11-regulator: no of_node; not parsing
pinctrl DT
[ 10.354652] s5m-rtc s2mps14-rtc: no of_node; not parsing pinctrl DT
[ 10.358618] dummy 4-0006: no of_node; not parsing pinctrl DT
[ 10.391220] s2mps11-clk s2mps11-clk: no of_node; not parsing pinctrl DT
[ 10.504969] cpufreq-dt cpufreq-dt: no of_node; not parsing pinctrl DT
[ 10.605180] pinctrl core: add 2 pinctrl maps
[ 10.605286] samsung-pinctrl 13410000.pinctrl: found group selector
29 for gpd1-0
[ 10.605313] samsung-pinctrl 13410000.pinctrl: found group selector
29 for gpd1-0
[ 10.605331] samsung-pinctrl 13410000.pinctrl: request pin 69
(gpd1-0) for pwrseq
[ 10.605645] samsung-pinctrl 13410000.pinctrl: request pin 69
(gpd1-0) for gpd1:69
[ 10.623242] pinctrl core: add 2 pinctrl maps
[ 10.623392] pinctrl core: add 2 pinctrl maps
[ 10.623536] pinctrl core: add 2 pinctrl maps
[ 10.623706] pinctrl core: add 6 pinctrl maps
[ 10.623878] pinctrl core: add 8 pinctrl maps
[ 10.624024] pinctrl core: add 2 pinctrl maps
[ 10.624174] pinctrl core: add 2 pinctrl maps
[ 10.624278] samsung-pinctrl 13410000.pinctrl: found group selector
0 for gpc0-0
[ 10.624307] samsung-pinctrl 13410000.pinctrl: found group selector
0 for gpc0-0
[ 10.624335] samsung-pinctrl 13410000.pinctrl: found group selector
1 for gpc0-1
[ 10.624362] samsung-pinctrl 13410000.pinctrl: found group selector
1 for gpc0-1
[ 10.624389] samsung-pinctrl 13410000.pinctrl: found group selector
3 for gpc0-3
[ 10.624415] samsung-pinctrl 13410000.pinctrl: found group selector
3 for gpc0-3
[ 10.624442] samsung-pinctrl 13410000.pinctrl: found group selector
4 for gpc0-4
[ 10.624467] samsung-pinctrl 13410000.pinctrl: found group selector
4 for gpc0-4
[ 10.624493] samsung-pinctrl 13410000.pinctrl: found group selector
5 for gpc0-5
[ 10.624518] samsung-pinctrl 13410000.pinctrl: found group selector
5 for gpc0-5
[ 10.624543] samsung-pinctrl 13410000.pinctrl: found group selector
6 for gpc0-6
[ 10.624568] samsung-pinctrl 13410000.pinctrl: found group selector
6 for gpc0-6
[ 10.624594] samsung-pinctrl 13410000.pinctrl: found group selector
23 for gpc3-0
[ 10.624619] samsung-pinctrl 13410000.pinctrl: found group selector
23 for gpc3-0
[ 10.624644] samsung-pinctrl 13410000.pinctrl: found group selector
24 for gpc3-1
[ 10.624668] samsung-pinctrl 13410000.pinctrl: found group selector
24 for gpc3-1
[ 10.624693] samsung-pinctrl 13410000.pinctrl: found group selector
25 for gpc3-2
[ 10.624717] samsung-pinctrl 13410000.pinctrl: found group selector
25 for gpc3-2
[ 10.624755] samsung-pinctrl 13410000.pinctrl: found group selector
26 for gpc3-3
[ 10.624785] samsung-pinctrl 13410000.pinctrl: found group selector
26 for gpc3-3
[ 10.624815] samsung-pinctrl 13410000.pinctrl: found group selector
2 for gpc0-2
[ 10.624843] samsung-pinctrl 13410000.pinctrl: found group selector
2 for gpc0-2
[ 10.624873] samsung-pinctrl 13410000.pinctrl: found group selector
7 for gpc0-7
[ 10.624901] samsung-pinctrl 13410000.pinctrl: found group selector
7 for gpc0-7
[ 10.624917] samsung-pinctrl 13410000.pinctrl: request pin 40
(gpc0-0) for 12200000.mmc
[ 10.624936] samsung-pinctrl 13410000.pinctrl: request pin 41
(gpc0-1) for 12200000.mmc
[ 10.624954] samsung-pinctrl 13410000.pinctrl: request pin 43
(gpc0-3) for 12200000.mmc
[ 10.624972] samsung-pinctrl 13410000.pinctrl: request pin 44
(gpc0-4) for 12200000.mmc
[ 10.624990] samsung-pinctrl 13410000.pinctrl: request pin 45
(gpc0-5) for 12200000.mmc
[ 10.625007] samsung-pinctrl 13410000.pinctrl: request pin 46
(gpc0-6) for 12200000.mmc
[ 10.625025] samsung-pinctrl 13410000.pinctrl: request pin 63
(gpc3-0) for 12200000.mmc
[ 10.625043] samsung-pinctrl 13410000.pinctrl: request pin 64
(gpc3-1) for 12200000.mmc
[ 10.625061] samsung-pinctrl 13410000.pinctrl: request pin 65
(gpc3-2) for 12200000.mmc
[ 10.625078] samsung-pinctrl 13410000.pinctrl: request pin 66
(gpc3-3) for 12200000.mmc
[ 10.625095] samsung-pinctrl 13410000.pinctrl: request pin 42
(gpc0-2) for 12200000.mmc
[ 10.625113] samsung-pinctrl 13410000.pinctrl: request pin 47
(gpc0-7) for 12200000.mmc
[ 10.654376] samsung-pinctrl 13410000.pinctrl: request pin 42
(gpc0-2) for gpc0:42
[ 10.734790] pinctrl core: add 2 pinctrl maps
[ 10.735262] pinctrl core: add 2 pinctrl maps
[ 10.736085] pinctrl core: add 2 pinctrl maps
[ 10.736604] pinctrl core: add 2 pinctrl maps
[ 10.737220] pinctrl core: add 6 pinctrl maps
[ 10.737601] samsung-pinctrl 13410000.pinctrl: found group selector
16 for gpc2-0
[ 10.737699] samsung-pinctrl 13410000.pinctrl: found group selector
16 for gpc2-0
[ 10.737803] samsung-pinctrl 13410000.pinctrl: found group selector
17 for gpc2-1
[ 10.737899] samsung-pinctrl 13410000.pinctrl: found group selector
17 for gpc2-1
[ 10.738001] samsung-pinctrl 13410000.pinctrl: found group selector
18 for gpc2-2
[ 10.738095] samsung-pinctrl 13410000.pinctrl: found group selector
18 for gpc2-2
[ 10.738196] samsung-pinctrl 13410000.pinctrl: found group selector
19 for gpc2-3
[ 10.738289] samsung-pinctrl 13410000.pinctrl: found group selector
19 for gpc2-3
[ 10.738389] samsung-pinctrl 13410000.pinctrl: found group selector
20 for gpc2-4
[ 10.738481] samsung-pinctrl 13410000.pinctrl: found group selector
20 for gpc2-4
[ 10.738642] samsung-pinctrl 13410000.pinctrl: found group selector
21 for gpc2-5
[ 10.738749] samsung-pinctrl 13410000.pinctrl: found group selector
21 for gpc2-5
[ 10.738863] samsung-pinctrl 13410000.pinctrl: found group selector
22 for gpc2-6
[ 10.738968] samsung-pinctrl 13410000.pinctrl: found group selector
22 for gpc2-6
[ 10.739022] samsung-pinctrl 13410000.pinctrl: request pin 56
(gpc2-0) for 12220000.mmc
[ 10.739078] samsung-pinctrl 13410000.pinctrl: request pin 57
(gpc2-1) for 12220000.mmc
[ 10.739127] samsung-pinctrl 13410000.pinctrl: request pin 58
(gpc2-2) for 12220000.mmc
[ 10.739175] samsung-pinctrl 13410000.pinctrl: request pin 59
(gpc2-3) for 12220000.mmc
[ 10.739224] samsung-pinctrl 13410000.pinctrl: request pin 60
(gpc2-4) for 12220000.mmc
[ 10.739272] samsung-pinctrl 13410000.pinctrl: request pin 61
(gpc2-5) for 12220000.mmc
[ 10.739320] samsung-pinctrl 13410000.pinctrl: request pin 62
(gpc2-6) for 12220000.mmc
[ 10.923667] mmcblk mmc1:0007: no of_node; not parsing pinctrl DT
[ 11.140046] snd-soc-dummy snd-soc-dummy: no of_node; not parsing pinctrl DT
[ 11.220467] usb 2-1: no of_node; not parsing pinctrl DT
[ 11.626518] pinctrl core: add 2 pinctrl maps
[ 11.626743] samsung-pinctrl 13400000.pinctrl: found group selector
39 for gpx3-7
[ 11.626793] samsung-pinctrl 13400000.pinctrl: found group selector
39 for gpx3-7
[ 11.626820] samsung-pinctrl 13400000.pinctrl: request pin 39
(gpx3-7) for 14530000.hdmi
[ 11.627809] samsung-pinctrl 13400000.pinctrl: request pin 39
(gpx3-7) for gpx3:39
[ 11.726818] xhci-hcd xhci-hcd.2.auto: no of_node; not parsing pinctrl DT
[ 11.801452] usb usb3: no of_node; not parsing pinctrl DT
[ 11.805471] hub 3-0:1.0: no of_node; not parsing pinctrl DT
[ 11.883263] usb usb4: no of_node; not parsing pinctrl DT
[ 11.887362] hub 4-0:1.0: no of_node; not parsing pinctrl DT
[ 11.926683] xhci-hcd xhci-hcd.5.auto: no of_node; not parsing pinctrl DT
[ 11.999588] usb usb5: no of_node; not parsing pinctrl DT
[ 12.003208] hub 5-0:1.0: no of_node; not parsing pinctrl DT
[ 12.085100] usb usb6: no of_node; not parsing pinctrl DT
[ 12.088936] hub 6-0:1.0: no of_node; not parsing pinctrl DT
[ 12.491299] usb 3-1: no of_node; not parsing pinctrl DT
[ 12.528446] hub 3-1:1.0: no of_node; not parsing pinctrl DT
[ 12.555071] usb 4-1: no of_node; not parsing pinctrl DT
[ 12.611412] hub 4-1:1.0: no of_node; not parsing pinctrl DT
[ 13.020668] usb 4-1.1: no of_node; not parsing pinctrl DT
[ 13.081803] usb-storage 4-1.1:1.0: no of_node; not parsing pinctrl DT
[ 13.091721] usb 5-1: no of_node; not parsing pinctrl DT
[ 13.127124] r8152 5-1:2.0: no of_node; not parsing pinctrl DT
[ 13.208321] r8152 5-1:1.0: no of_node; not parsing pinctrl DT
[ 14.281196] sd 0:0:0:0: no of_node; not parsing pinctrl DT
[ 16.057197] usb 4-1.2: no of_node; not parsing pinctrl DT
[ 16.079507] usb-storage 4-1.2:1.0: no of_node; not parsing pinctrl DT
[ 17.236626] sd 1:0:0:0: no of_node; not parsing pinctrl DT
[ 17.612139] usbhid 2-1:1.0: no of_node; not parsing pinctrl DT
[ 17.625511] usbhid 2-1:1.1: no of_node; not parsing pinctrl DT
[ 17.755059] hid-generic 0003:24AE:1000.0001: no of_node; not
parsing pinctrl DT
[ 17.933665] hid-generic 0003:24AE:1000.0002: no of_node; not
parsing pinctrl DT
[ 1009.259380] usb 4-1.2: no of_node; not parsing pinctrl DT
[ 1009.267240] usb-storage 4-1.2:1.0: no of_node; not parsing pinctrl DT
[ 1010.311832] sd 1:0:0:0: no of_node; not parsing pinctrl DT
Best Regards
-Anand Moon
^ permalink raw reply
* [PATCH 1/4] mfd: ti_am335x_tscadc: store physical address
From: Lee Jones @ 2016-10-26 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f271b805-82c2-a45e-0de9-39edafd34d2e@ti.com>
On Fri, 30 Sep 2016, Mugunthan V N wrote:
> On Wednesday 28 September 2016 01:10 AM, Lee Jones wrote:
> > On Wed, 21 Sep 2016, Mugunthan V N wrote:
> >
> >> store the physical address of the device in its priv to use it
> >> for DMA addressing in the client drivers.
> >>
> >> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >> ---
> >> drivers/mfd/ti_am335x_tscadc.c | 1 +
> >> include/linux/mfd/ti_am335x_tscadc.h | 1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> >> index c8f027b..0f3fab4 100644
> >> --- a/drivers/mfd/ti_am335x_tscadc.c
> >> +++ b/drivers/mfd/ti_am335x_tscadc.c
> >> @@ -183,6 +183,7 @@ static int ti_tscadc_probe(struct platform_device *pdev)
> >> tscadc->irq = err;
> >>
> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> + tscadc->tscadc_phys_base = res->start;
> >
> > This is unusual. Can't you use a virt_to_phys() variant instead?
> >
>
> I tried using virt_to_phys(), but its not working for me.
> Also saw many drivers uses like this to get physical address
> ("git grep -n " res->start;" drivers/*").
Very well:
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Let me know how you wish this set to be handled.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver
From: Marc Zyngier @ 2016-10-26 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADyBb7tLJpPiMqWs4KZE=uCpo3HX3WcNVju2UKNuPOR0+M4UDw@mail.gmail.com>
On 26/10/16 12:10, Fu Wei wrote:
> Hi Mark,
>
> On 21 October 2016 at 00:37, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi,
>>
>> As a heads-up, on v4.9-rc1 I see conflicts at least against
>> arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up
>> automatically, but this will need to be rebased before the next posting
>> and/or merging.
>>
>> On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu.wei at linaro.org wrote:
>>> +static int __init map_gt_gsi(u32 interrupt, u32 flags)
>>> +{
>>> + int trigger, polarity;
>>> +
>>> + if (!interrupt)
>>> + return 0;
>>
>> Urgh.
>>
>> Only the secure interrupt (which we do not need) is optional in this
>> manner, and (hilariously), zero appears to also be a valid GSIV, per
>> figure 5-24 in the ACPI 6.1 spec.
>>
>> So, I think that:
>>
>> (a) we should not bother parsing the secure interrupt
>
> If I understand correctly, from this point of view, kernel don't
> handle the secure interrupt.
> But the current arm_arch_timer driver still enable/disable/request
> PHYS_SECURE_PPI
> with PHYS_NONSECURE_PPI.
> That means we still need to parse the secure interrupt.
> Please correct me, if I misunderstand something? :-)
That's because we can use the per-cpu timer when 32bit Linux is running
on the secure side (and we cannot distinguish between secure and
non-secure at runtime). ACPI is 64bit only, and Linux on 64bit isn't
supported on the secure side, so only registering the non-secure timer
is perfectly acceptable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Geert Uytterhoeven @ 2016-10-26 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2719479.geOc9vqcRS@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Oct 21, 2016 at 10:39 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Here's the set of 8 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support for
> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> seems identical to the R8A7791/Porter board. The device tree patches depend on
> the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
They depend only on "[PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock
index macros" of that series, right?
"[PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support" is not needed,
and introduces an additional dependency on "[PATCH 1/3] clk: renesas:
cpg-mssr: add common R-Car Gen2 support".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Geert Uytterhoeven @ 2016-10-26 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be>
Hi Mike, Stephen,
On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module. Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
>
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
> A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> driver,
> B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> files,
> C. Patches 12-17 convert the clock drivers to call into the new R-Car
> RST driver,
> D. Patches 18-20 remove passing mode pin state to the clock drivers
> from the platform code,
> E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
> - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
> - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
> - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
> - The block driver cleanups in part E depend on the board code
> cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***
> - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> approach above?
Is this OK for you?
I'd like to move forward with this, as this is a prerequisite for adding
support for new SoCs (RZ/G) without adding more copies of
rcar_gen2_read_mode_pins(), and removing that function from platform code
for good.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] ARM: davinci: da8xx: Fix some redefined symbol warnings
From: Sekhar Nori @ 2016-10-26 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477397492-7925-2-git-send-email-abailon@baylibre.com>
On Tuesday 25 October 2016 05:41 PM, Alexandre Bailon wrote:
> Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
> but da8xx-cfgchip.h intend to replace them.
> The usb-da8xx.c is using both headers, causing redefined symbol warnings.
> Remove the macro and update the da830-evm board file to use da8xx-cfgchip.h
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
This leads to build error on v4.9-rc2:
arch/arm/mach-davinci/board-da830-evm.c: In function 'da830_evm_usb_init':
arch/arm/mach-davinci/board-da830-evm.c:120:15: error: 'CFGCHIP2_REFFREQ' undeclared (first use in this function)
cfgchip2 &= ~CFGCHIP2_REFFREQ;
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Geert Uytterhoeven @ 2016-10-26 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477064730.2508.24.camel@pengutronix.de>
Hi Philip,
On Fri, Oct 21, 2016 at 5:45 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
>> Hi Philipp, Mike, Stephen, Simon, Magnus,
>> (see questions *** below!)
>>
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the platform code, or
>> directly by using a hardcoded register access. This is a bit messy, and
>> creates a dependency between driver and platform code.
>>
>> This patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new minimalistic R-Car RST driver.
[...]
>> - Philip: While this is a driver for a reset-controller, currently it
>> doesn't provide any reset-controller functionality. Hence I added it
>> to drivers/soc/renesas/. Is that OK for you?
>
> Absolutely, as long as the driver isn't even a reset controller
> provider, this is the right place.
Thank you!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Hans de Goede @ 2016-10-26 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024173900.GP15620@leverpostej>
Hi,
On 24-10-16 19:39, Mark Rutland wrote:
> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
>> Hi Rob, Mark, et al.,
>
> Hi Hans,
>
> Apologies for the delay in replying to this.
No worries, I believe that 1 week is actually a pretty good
turn around time, esp. directly after a conference.
> I'd like to be clear that I do understand that there is a problem that
> needs to be addressed here. However, I do not believe that the *current*
> in-kernel approach is correct. More on that below.
Ok.
>> Mark, I know that we discussed this at ELCE and you clearly indicated
>> that according to you this does not belong in the kernel. I was a bit
>> surprised by this part of the discussion.
>>
>> I had posted a RFC earlier and Rob had indicated that given that the q8
>> tablets are a special case, as my code uses actual probing rather then some
>> pre-arranged id mechanism with say an eeprom, that doing this in a
>> non-generic manner would be ok for my special case.
>
> To some extent, Rob and I may have differing views here; I'm not
> entirely sure what Rob's view is, and I cannot talk on his behalf. I
> certainly must apologise for having not commented on said RFC, however.
>
>> So on to why I believe that the kernel is the best place to do this, at least
>> for my special use-case:
>>
>> 1. Configurability
>>
>> Since the q8 tablets do not have any id mechanism I'm probing i2c busses to
>> generate i2c client dt nodes with the right address and compatible.
>> Some info in these nodes (e.g. touchscreen firmware-name) is not probable at
>> all and gets set by heuristics. This heuristics may get things wrong.
>> So my current implementation offers kernel cmdline options to override this.
>
> As I mentioned at ELCE, one major concern I have with this approach is
> this probing, which in part relies on a collection of heuristics.
This is quite use-case specific, anyways, the probing is a 2 step process:
1) Identify which hardware there is in the tablet, this is pretty
reliable, we only detect a fix set of known possible touchscreens
and accelerometers, at known addresses and almost all have an id
register to check.
2) Determine *defaults* for various none probable settings, like guessing
which firmware to load into the touchscreen controllers, as there are
at least 2 ways the gsl1680 is wired up on these tablets and this
requires 2 different firmware files. This uses heuristics, to, as said,
determine the defaults all of the non-probable bits are overidable
through config options (currently kernel module options). Getting these
wrong is not dangerous to the hardware, but will work in a non-functional
or misbehaving (wrong coordinates) touchscreen.
Note with the models I've access to so far the heuristics score 100%
but I'm not sure how representative the 16 models I've access to are
(they are all different and have been bought over a span of multiple
years).
> I'm worried that this is very fragile, and sets us up for having to
> maintain a much larger collection of heuristics and/or a database of
> particular boards in future. This is fragile, defeats much of the gain
> from DT.
I understand your worries, as said I'm confident the actual probing
is safe and getting the heuristics wrong will result in misbehavior,
but not in any hardware damage or such.
> Worse, this could be completely incompatible with some arbitrary board
> that comes by in future,
I assume you mean an arbitrary q8 tablet here, as the probe code does
bind by board/machine compatible, so for a really arbitrary board
this code will never activate.
> because the kernel assumed something that was
> not true, which it would not have done if things were explicitly
> described to the kernel.
I understand your worry, but moving the probing code to say u-boot
will not change any of this, the kernel will get the explicit
description created by the u-boot probe code, but it would be
just as wrong.
So maybe we need to answer 2 questions in a row:
1) Do we want such probe code at all ?
My answer to this is yes, these (cheap) tablets are interesting to
e.g. the maker community and I would like them to run mainline
(and run mainline well), but given the way there are put together
this require some code to dynamically adapt to the batch of the
month somewhere
2) Where do we put this code ?
If we agree on 1 (I assume we do) then this becomes the real
question, at which point your worries about the kernel assuming
something which is not true because the probe code got it wrong
may become true regardless where the code lives.
So wrt this worries is all I can do is ask you to trust me to
not mess things up, just like we all trust driver authors, etc.
all the time to not mess things up.
> As I mentioned at ELCE, I'm not opposed to the concept of the kernel
> applying overlays or fixups based on a well-defined set of criteria;
> having some of that embedded in the DT itself would be remarkably
> helpful. However, I am very much not keen on loosely defined criteria as
> with here, as it couples the DT and kernel, and creates problems longer
> term, as described above.
Right, so again I think we need to split the discussion in 2 steps:
1) How do we apply the fixups, currently I'm using free-form changes
done from C-code. I can envision moving to something like the quirk
mechanism suggested by Pantelis in the past. Note this is not a perfect
fit for my rather corner-case use-case, but I can understand that in
general you want the variants to be described in dt, and activated
in some way, rather then have c-code make free-form changes to the dt
2) How do we select which fixups to apply. Again I can understand
you wanting some well defined mechanism for this, but again my
use-case is special and simply does not allow for this as there
is no id-eeprom to read or some such.
>> Although having to specify kernel cmdline options is not the plug and play
>> experience I want to give end-users most distros do have documentation on
>> how to do this and doing this is relatively easy for end-users. Moving this
>> to the bootloader means moving to some bootloader specific config mechanism
>> which is going to be quite hard (and possibly dangerous) for users to use.
>
> I have to ask, why is it more dangerous?
Because for normal end users meddling with the bootloader / with u-boot's
environment is like flashing a PC BIOS. Most (non technical) end users will
want to install u-boot once (or not at all) and then just have it work.
> Perhaps more difficult, but that can be solved,
More difficult means not doable for many users.
> if the manual
> corrections are simply a set of options to be passed to the kernel, I
> don't see why the bootloader cannot pick this up.
>
>> 2. Upgradability
>>
>> Most users treat the bootloader like they treat an x86 machine BIOS/EFI,
>> they will never upgrade it unless they really have to. This means that it
>> will be very difficult to get users to actual benefit from bug-fixes /
>> improvements done to the probing code. Where as the kernel on boards running
>> e.g. Debian or Fedora gets regular updates together with the rest of the
>> system.
>
> Given that DTBs are supposed to remain supported, users should find
> themselves with a system that continues to work, but may not have all
> the bells and whistles it could, much like elsewhere.
>
> While it's true that we have issues in this area, I don't think that's
> an argument for putting things into the kernel for this specific set of
> boards.
It is an argument to put much of the dynamic (dt) hardware support in
the kernel in general.
>> 3. Infrastructure
>>
>> The kernel simply has better infrastructure for doing these kind of things.
>
> At least on the DT front, a lot of work has gone into improving the
> infrastructure, e.g. the work that Free Electrons have done [1]. I
> appreciate that the infrastructure for things like poking SPI may not be
> as advanced.
>
> Which bits of infrastructure do you find lacking today?
Nothing really specific (I've not yet tried porting the probe code
to u-boot), but I just find working within the kernel easier in general,
since there really just is a lot more infrastructure. Note I'm the
upstream u-boot maintainer for the allwinner SoC support, so this
is not due to me being unfamiliar with u-boot.
>> Yes we could improve the bootloader, but the kernel is also improving
>> and likely at a faster rate. Besides that the purpose of the
>> bootloader is mostly to be simple and small, load the kernel and get
>> out of the way, not to be a general purpose os kernel. So it will
>> simply always have less infrastructure and that is a good thing,
>> otherwise we will be writing another general purpose os which is a
>> waste of effort.
>
> I think this conflates a number of details. Yes, we'd like firmware and
> bootloaders to be small, and yes, their infrastructure and feature
> support will be smaller than a general purpose OS.
>
> That doesn't imply that they cannot have features necessary to boostrap
> an OS.
>
> It's also not strictly necessary that the firmware or bootloader have
> the capability to do all this probing, as that could be contained in
> another part (e.g. a U-Boot application which is run once to detect the
> board details, logging this into a file).
>
> It's also possible to ship an intermediary stage (e.g. like the
> impedance matcher) which can be upgradeable independently of the kernel.
Yes there are other solutions, but they all involve a lot more
moving pieces (and thus will break) then a single isolated .c file
in the kernel, which is all this series adds.
Esp the intermediate solution just adds a ton of complexity with 0
gain.
>> 4. This is not a new board file
>>
>> Mark, at ELCE I got the feeling that your biggest worry / objection is
>> that this will bring back board files, but that is not the case, if you
>> look at the actual code it is nothing like a board-file at all. Where a
>> board file was instantiating device after device after device from c-code,
>> with maybe a few if-s in there to deal with board revisions. This code is
>> all about figuring out which accelerometer and touchscreen there are,
>> to then add nodes to the dt for this 2 devices, almost all the code is
>> probing, the actual dt modifying code is tiny and no direct device
>> instantiation is done at all.
>
> Sorry, but I must disagree. This code:
>
> (a) identifies a set of boards based on a top-level compatible string.
> i.e. it's sole purpose is to handle those boards.
>
> (b) assumes non-general properties of those boards (e.g. that poking
> certain SPI endpoints is safe).
>
> (c) applies arbitrary properties to the DT, applying in-built knowledge
> of those boards (in addition to deep structural knowledge of the
> DTB in question).
>
> To me, given the implicit knowledge, that qualifies as a "board file".
>
> As I mentioned at ELCE, if this had no knowledge of the boards in
> question, I would be less concerned. e.g. if there was a well-defined
> identification mechanism, describe in the DT, with fixups also defined
> in the DT.
And as I tried to explain before, for this specific use-case describing
all this board specific knowledge in a generic manner in dt is simply
impossible, unless we add a turing complete language to dt aka aml.
I've a feeling that you're mixing this, rather special, use-case with
the more generic use-case of daughter-boards for various small-board-computers
I agree that for the SBC use-case it makes sense to try and come up with
a shared core / dt bindings for much of this. Note that even this boards
will still need a board (or board-family) specific method for getting
the actual id from a daughter-board, but this board specific code could
then pass the id to some more general hw-manager core which starts applying
dt changes based on the id. But this assumes there is a single id to
uniquely identify the extensions, which in my case there simply is not.
>> 5. This is an exception, not the rule
>>
>> Yes this is introducing board (family of boards) specific c-code into the
>> kernel, so in a way it is reminiscent of board files. But sometimes this is
>> necessary, just look at all the vendor / platform specific code in the kernel
>> in drivers/platform/x86, or all the places where DMI strings are used to
>> uniquely identify a x86 board and adjust behavior.
>>
>> But this really is the exception, not the rule. I've written/upstreamed a
>> number of drivers for q8 tablets hardware and if you look at e.g. the
>> silead touchscreen driver then in linux-next this is already used for 5
>> ARM dts files where no board specific C-code is involved at all.
>>
>> So this again is very different from the board file era, where C-code
>> had to be used to fill device specific platform-data structs, here all
>> necessary info is contained in the dt-binding and there are many users
>> who do not need any board specific C-code in the kernel at all.
>>
>> So dt is working as it should and is avoiding board specific C-code for
>> the majority of the cases. But sometimes hardware is not as we ideally
>> would like it to be; and for those *exceptions* we are sometimes going
>> to need C-code in the kernel, just like there is "board" specific C-code
>> in the x86 code.
>
> Your talk convinced me that we're both going to see more variation
> within this family of boards, and that we'll see more families of boards
> following a similar patter. Given that, I think that we need a more
> general solution, as I commented on the RFC.
>
> That doesn't necessarily mean that this can't happen in the kernel, but
> it certainly needs to be more strictly defined, e.g. with match criteria
> and fixups explicit in the DTB.
The only answer I've to: "with match criteria and fixups explicit in the DTB"
is: ok, give my a turing complete language inside DTB then, anything else
will not suffice. So either we are doomed to reinvent ACPI; or we must
accept some board(family) specific C-code in the kernel.
Regards,
Hans
^ permalink raw reply
* [PATCH 1/5] ARM: davinci: Compile MMC in kernel
From: Sekhar Nori @ 2016-10-26 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-2-git-send-email-david@lechnology.com>
On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
> This changes the davinci default configuration to compile the davinci
> MMC driver into the kernel. This allows booting from an SD card without
> requiring an initrd containing the kernel module.
>
> Signed-off-by: David Lechner <david@lechnology.com>
"build" is more relevant here than "compile" so I changed that. And also
used davinci_all_defconfig as detailed in last e-mail.
Applied to v4.10/defconfig
Thanks,
Sekhar
^ 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