Re: [PATCH 1/5] extcon: gpio-usb: Introduce gpio usb extcon driver
Hi Roger,
On 01/20/2015 02:52 AM, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-Host (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/extcon/extcon-usb.txt | 20 ++
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-gpio-usb.c | 225
> +
> 4 files changed, 253 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb.txt
> create mode 100644 drivers/extcon/extcon-gpio-usb.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> new file mode 100644
> index 000..171c5a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
Need to rename from extcon-usb.txt to extcon-gpio-usb.txt.
> @@ -0,0 +1,20 @@
> +USB Extcon device
> +
> +This is a virtual device used to generate USB cable states from the USB ID
> pin
> +connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Should be "linux,extcon-usb"
I think you better use "linux,extcon-gpio-usb"
because the point of this driver use the gpio for usb cable.
> +- id-gpio: gpio for USB ID pin. See gpio binding.
> +
> +Example:
> + extcon_usb1 {
> + compatible = "linux,extcon-usb";
ditto.
> + id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + usb@1 {
> + ...
> + extcon = <&extcon_usb1>;
> + ...
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de..8106a83 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -35,6 +35,13 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_GPIO_USB
> + tristate "USB GPIO extcon support"
> + depends on GPIOLIB
> + help
> + Say Y here to enable GPIO based USB cable detection extcon support.
> + Used typically if GPIO is used for USB ID pin detection.
> +
> config EXTCON_MAX14577
> tristate "MAX14577/77836 EXTCON Support"
> depends on MFD_MAX14577
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42..bae594b 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_GPIO_USB)+= extcon-gpio-usb.o
Need to re-order it alphabetically.
> diff --git a/drivers/extcon/extcon-gpio-usb.c
> b/drivers/extcon/extcon-gpio-usb.c
> new file mode 100644
> index 000..aeb2298
> --- /dev/null
> +++ b/drivers/extcon/extcon-gpio-usb.c
> @@ -0,0 +1,225 @@
> +/**
> + * drivers/extcon/extcon_gpio_usb.c - USB GPIO extcon driver
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
> + *
Remove un-necessary blank line.
> + * Author: Roger Quadros
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
Is it necessary? I think it is your mistake?
> +#include
Don't need it because 'of_gpio.h' includes already 'gpio.h'.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
> +
> +struct usb_extcon_info {
> + struct device *dev;
> + struct extcon_dev *edev;
> +
> + struct gpio_desc *id_gpiod;
> + int id_irq;
> +
> + unsigned long debounce_jiffies;
> + struct delayed_work wq_detcable;
> +};
> +
> +/* List of detectable cables */
> +enum {
> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> +
> + EXTCON_CABLE_END,
> +};
> +
> +static const char *usb_extcon_cable[] = {
> + [EXTCON_CABLE_USB] = "USB",
> + [EXTCON_CABLE_USB_H
Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support
* Tony Lindgren [150117 08:38]:
>
> And the sysc and syss offsets for mcspi1 need 0x100 added to them for
> it to work, like on am33xx. Updated patch below.
Here's this one updated with the alwon_l3s_clkdm naming changes
Paul commented in the related clockdomain patch.
Regards,
Tony
8<
From: Tony Lindgren
Date: Tue, 20 Jan 2015 18:24:47 -0800
Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support
Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova .
I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomains.
This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
Cc: Aida Mynzhasova
Cc: Brian Hutchinson
Cc: Paul Walmsley
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4)+=
$(omap-prcm-4-5-common)
obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common)
am33xx-43xx-prcm-common+= prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common)
obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common)
obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \
$(am33xx-43xx-prcm-common)
@@ -225,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX)+=
omap_hwmod_33xx_43xx_ipblock_data.o
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o
obj-$(CONFIG_SOC_AM43XX) +=
omap_hwmod_33xx_43xx_interconnect_data.o
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o
+obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
obj-$(CONFIG_SOC_OMAP5)+= omap_hwmod_54xx_data.o
obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ed3e6e8f..e60780f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -545,10 +545,12 @@ void __init ti814x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+ am33xx_prm_init();
+ am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
- omap3xxx_hwmod_init();
+ ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
@@ -564,10 +566,12 @@ void __init ti816x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+ am33xx_prm_init();
+ am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
- omap3xxx_hwmod_init();
+ ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 1c0cb48..be50454 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3916,7 +3916,7 @@ void __init omap_hwmod_init(void)
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
- } else if (soc_is_am33xx()) {
+ } else if (cpu_is_ti816x() || soc_is_am33xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -748,6 +748,7 @@ extern int omap3xxx_hwmod_init(void);
extern int omap44xx_hwmod_init(void);
extern int omap54xx_hwmod_init(void);
extern int am33xx_hwmod_init(void);
+extern int ti81xx_hwmod_init(void);
extern int dra7xx_hwmod_init(void);
int am43xx_hwmod_init(void);
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -0,0 +1,1025 @@
+/*
+ * DM81xx hwmod data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by
Re: [PATCH 1/2] ARM: OMAP2+: Add clock domain support for dm816x
Hi,
* Paul Walmsley [150120 18:08]:
> On Tue, 13 Jan 2015, Tony Lindgren wrote:
> > +
> > +/*
> > + * - Add other domains as required
> > + * - Fill up associated powerdomans (especially ALWON powerdomains are
> > NULL at
> > + * the moment
> > + * - Consider dependencies across domains (probably not applicable till
> > now)
>
> Minor comment: I guess these are to-do items; would suggest explicitly
> putting a "To-do" header on this list.
Replacing them with better comments.
> > + */
> > +
> > +/* Common TI81XX */
>
> I can't comment on how many of these are truly common; since I haven't
> cross-checked this file against the 814x TRM. But if you haven't had the
> chance to cross-check it against the 814x TRM either, I'd suggest starting
> by making this file explicitly 816x-specific.
Seem to be common in the old TI PSP tree too at:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
Except it seems that dm814x has CLKDM_CAN_SWSUP while dm816x
has CLKDM_CAN_HWSUP_SWSUP. I've booted that tree only on dm816x
but let's assume it also works for dm814x as that's the TI tree
for it.
> > +static struct clockdomain alwon_l3_slow_81xx_clkdm = {
> > + .name = "l3s_clkdm",
>
> This should mention "alwon" in the name like the other L3 always-on
> clockdomains, since there's another L3 Slow clockdomain on this chip
> that's in the DEFAULT power domain, according to Section 18.7.6.4
> "CM_DEFAULT_L3_SLOW_CLKSTCTRL Register"
Oops I missed that one while cleaning up Aida's patch trying to
unify it with am33xx. Will search and replace also in the
omap_hwmod_81xx_data.c.
> > + .pwrdm = { .name = "alwon_pwrdm" },
> > + .cm_inst= TI81XX_CM_ALWON_MOD,
> > + .clkdm_offs = TI81XX_CM_ALWON_L3_SLOW_CLKDM,
> > + .flags = CLKDM_CAN_HWSUP_SWSUP,
>
> According to Table 18-136 "CM_ALWON_L3_SLOW_CLKSTCTRL Register Field
> Descriptions", only SW_SLEEP and SW_WKUP are supported. So if that's
> correct, this should be CLKDM_CAN_SWSUP.
Looks like TI's tree has these ifdef else and 816x seems to
have both CAN_HWSUP_SWSUP so probably the TRM is wrong.
My guess the TRM for 816x has tons of copy-paste errors from the
dm814x TRM. So I've kept all them the same way as the TI tree has
them.
> > +/* OCMC clock domain */
>
> Hmm I think this comment is wrong, there are two other clock domains
> labeled "OCMC".
Removed, that seems to have come from the TI tree for 814x.
> > +static struct clockdomain default_ducati_816x_clkdm = {
>
> I can't find any mention of the Ducati in the TRM. Does this SoC have a
> Ducati?
So it seems for dm816x. Also clock816x_data.c references ducati_ick.
> According to the TRM here, looks like this should just be
> "default_816x_clkdm" ? The corresponding register is named
> CM_DEFAULT_CLKSTCTRL. It references two clockdomains, GCLKINTR and
> GCLKIN200TR, but I can't find any other mention of those in the TRM, so,
> no idea what they're associated with.
No mention of CM_DEFAULT_CLKSTCTRL in the TI tree. It seems the
TRM is wrong here too.
> > + .name = "default_ducati_clkdm",
> > + .pwrdm = { .name = "default_pwrdm" },
> > + .cm_inst= TI816X_CM_DEFAULT_MOD,
> > + .clkdm_offs = TI816X_CM_DEFAULT_DUCATI_CLKDM,
>
> (see 'Ducati' comments above)
>
> > + .flags = CLKDM_CAN_HWSUP_SWSUP,
>
> According to Table 18-81 "CM_DEFAULT_CLKSTCTRL Register Field
> Descriptions", only SW_SLEEP and SW_WKUP are supported. So if that's
> correct, this should be CLKDM_CAN_SWSUP.
That too is CLKDM_CAN_HWSUP_SWSUP in the TI tree so keeping it
that way like the others.
> > +};
> > +
> > +static struct clockdomain default_pcie_816x_clkdm = {
> > + .name = "default_pcie_clkdm",
>
> The TRM calls this the "DEFAULT_PCI" clockdomain - would suggest sticking
> to the TRM and register name to avoid confusion.
OK fixed.
> > +static struct clockdomain default_usb_816x_clkdm = {
>
> The TRM calls this "DEFAULT_L3_SLOW" - would suggest sticking to the TRM
> and register name to avoid confusion.
>
> > + .name = "default_usb_clkdm",
>
> As above
OK fixed.
> > +static struct clockdomain *clockdomains_ti81xx[] __initdata = {
> > + &alwon_mpu_816x_clkdm,
> > + &alwon_l3_slow_81xx_clkdm,
> > + &alwon_l3_med_81xx_clkdm,
> > + &alwon_l3_fast_81xx_clkdm,
> > + &alwon_ethernet_81xx_clkdm,
> > + &mmu_81xx_clkdm,
> > + &mmu_cfg_81xx_clkdm,
> > + &active_gem_816x_clkdm,
> > + &ivahd0_816x_clkdm,
> > + &ivahd1_816x_clkdm,
> > + &ivahd2_816x_clkdm,
> > + &sgx_816x_clkdm,
> > + &default_l3_med_816x_clkdm,
> > + &default_ducati_816x_clkdm,
> > + &default_pcie_816x_clkdm,
> > + &default_usb_816x_clkdm,
> > + NULL,
> > +};
>
> As the comment at the top of the file suggests, this is missing a lot
> of clockdomains. The TRM lists 56 ALWON clockdomains, 13 DEFAULT
> clockdomains, 4 ACTIVE clockdomains, etc.
Yes it seems incomplete.
Re: [PATCH 1/2] ARM: OMAP2+: Add clock domain support for dm816x
Hi
On Tue, 13 Jan 2015, Tony Lindgren wrote:
> From: Aida Mynzhasova
>
> This patch adds required definitions and structures for clockdomain
> initialization, so omap3xxx_clockdomains_init() was substituted by
> new ti81xx_clockdomains_init() while early initialization of
> TI81XX platform.
>
> This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
> published at:
>
> http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
>
> Cc: Brian Hutchinson
> Cc: Paul Walmsley
> Signed-off-by: Aida Mynzhasova
> [t...@atomide.com: updated to apply, renamed to clockdomains81xx.c
> fixed to use am33xx_clkdm_operations]
> Signed-off-by: Tony Lindgren
A few comments below based on SPRUGX8B:
> ---
> arch/arm/mach-omap2/Makefile| 2 +
> arch/arm/mach-omap2/clockdomain.h | 1 +
> arch/arm/mach-omap2/clockdomains81xx_data.c | 191
>
> arch/arm/mach-omap2/cm81xx.h| 61 +
> arch/arm/mach-omap2/io.c| 4 +-
> 5 files changed, 257 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/mach-omap2/clockdomains81xx_data.c
> create mode 100644 arch/arm/mach-omap2/cm81xx.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 3a6463f..352873c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -171,6 +171,8 @@ obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common)
> obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o
> obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common)
> obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o
> +obj-$(CONFIG_SOC_TI81XX) += $(clockdomain-common)
> +obj-$(CONFIG_SOC_TI81XX) += clockdomains81xx_data.o
> obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common)
> obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o
> obj-$(CONFIG_SOC_OMAP5) += $(clockdomain-common)
> diff --git a/arch/arm/mach-omap2/clockdomain.h
> b/arch/arm/mach-omap2/clockdomain.h
> index 82c37b1..77bab5f 100644
> --- a/arch/arm/mach-omap2/clockdomain.h
> +++ b/arch/arm/mach-omap2/clockdomain.h
> @@ -216,6 +216,7 @@ extern void __init omap242x_clockdomains_init(void);
> extern void __init omap243x_clockdomains_init(void);
> extern void __init omap3xxx_clockdomains_init(void);
> extern void __init am33xx_clockdomains_init(void);
> +extern void __init ti81xx_clockdomains_init(void);
> extern void __init omap44xx_clockdomains_init(void);
> extern void __init omap54xx_clockdomains_init(void);
> extern void __init dra7xx_clockdomains_init(void);
> diff --git a/arch/arm/mach-omap2/clockdomains81xx_data.c
> b/arch/arm/mach-omap2/clockdomains81xx_data.c
> new file mode 100644
> index 000..05c4635
> --- /dev/null
> +++ b/arch/arm/mach-omap2/clockdomains81xx_data.c
> @@ -0,0 +1,191 @@
> +/*
> + * TI81XX Clock Domain data.
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
> + * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_81XX_H
> +#define __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_81XX_H
> +
> +#include
> +#include
> +
> +#include "clockdomain.h"
> +
> +#include "cm81xx.h"
> +
> +/*
> + * - Add other domains as required
> + * - Fill up associated powerdomans (especially ALWON powerdomains are NULL
> at
> + * the moment
> + * - Consider dependencies across domains (probably not applicable till now)
Minor comment: I guess these are to-do items; would suggest explicitly
putting a "To-do" header on this list.
> + */
> +
> +/* Common TI81XX */
I can't comment on how many of these are truly common; since I haven't
cross-checked this file against the 814x TRM. But if you haven't had the
chance to cross-check it against the 814x TRM either, I'd suggest starting
by making this file explicitly 816x-specific.
> +static struct clockdomain alwon_l3_slow_81xx_clkdm = {
> + .name = "l3s_clkdm",
This should mention "alwon" in the name like the other L3 always-on
clockdomains, since there's another L3 Slow clockdomain on this chip
that's in the DEFAULT power domain, according to Section 18.7.6.4
"CM_DEFAULT_L3_SLOW_CLKSTCTRL Register"
> + .pwrdm = { .name = "alwon_pwrdm" },
> + .cm_inst= TI81XX_CM_ALWON_MOD,
> + .clkdm_offs = TI81XX_CM_ALWON_L3_SLOW_CLKDM,
> + .flags = CLKDM_CAN_HWSUP_SW
Re: [PATCH v10 3/3] clk: Add rate constraints to clocks
It's looking fairly close. Thanks for keeping up with the review
comments.
On 01/20, Tomeu Vizoso wrote:
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index e867d6a..f241e27 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2143,6 +2280,10 @@ struct clk *__clk_register(struct device *dev, struct
> clk_hw *hw)
> else
> clk->owner = NULL;
>
> + INIT_HLIST_HEAD(&clk->clks);
> +
> + hw->clk = __clk_create_clk(hw, NULL, NULL);
> +
> ret = __clk_init(dev, hw->clk);
> if (ret)
> return ERR_PTR(ret);
Don't we need to __clk_free_clk() here too?
> @@ -2151,6 +2292,19 @@ struct clk *__clk_register(struct device *dev, struct
> clk_hw *hw)
> }
> EXPORT_SYMBOL_GPL(__clk_register);
>
> +static void __clk_free_clk(struct clk *clk)
> +{
> + struct clk_core *core = clk->core;
> +
> + clk_prepare_lock();
> + hlist_del(&clk->child_node);
> + clk_prepare_unlock();
> +
> + kfree(clk);
> +
> + clk_core_set_rate(core, core->req_rate);
Is it safe to call this during clock registration? I hope that it
will just bail out and do nothing because core->rate ==
core->req_rate. Maybe we can avoid this given my next comment
below.
> +}
> +
> /**
> * clk_register - allocate a new clock, register it and return an opaque
> cookie
> * @dev: device that is registering this clock
> @@ -2210,12 +2364,14 @@ struct clk *clk_register(struct device *dev, struct
> clk_hw *hw)
> }
> }
>
> + INIT_HLIST_HEAD(&clk->clks);
> +
> hw->clk = __clk_create_clk(hw, NULL, NULL);
> ret = __clk_init(dev, hw->clk);
> if (!ret)
> return hw->clk;
>
> - kfree(hw->clk);
> + __clk_free_clk(hw->clk);
> fail_parent_names_copy:
> while (--i >= 0)
> kfree(clk->parent_names[i]);
> @@ -2421,7 +2577,7 @@ void __clk_put(struct clk *clk)
> return;
>
> clk_core_put(clk->core);
> - kfree(clk);
> + __clk_free_clk(clk);
This doesn't look right. First we drop the core reference here
with clk_core_put() and then we call __clk_free_clk() which will
go and call clk_core_set_rate() on the clk->core which may or may
not exist anymore. I'd think we want to do these steps:
1. Unlink clk from clks list
2. Recalculate rate and set if changed
3. Drop kref on core with clk_core_put()
4. kfree the clk
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3
On Thu, 8 Jan 2015, Lokesh Vutla wrote:
> With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
> with DEBUG_LL' we moved from parsing cmdline to identify uart used
> for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.
>
> On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
> BeagleBoard-X15, where we use UART3 for console, boot fails with
> DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.
>
> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
>
> Fixes: 90020c7b2c5e ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
> Cc: # v3.12+
> Reviewed-by: Felipe Balbi
> Acked-by: Felipe Balbi
> Signed-off-by: Lokesh Vutla
Thanks, queued for v3.20. Note that I don't have a DRA7xx board, so,
cannot test.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/3] clk: Make clk API return per-user struct clk instances
On 01/20, Tomeu Vizoso wrote:
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 97f3425..e867d6a 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1719,6 +1817,31 @@ out:
>
> return ret;
> }
> +
> +/**
> + * clk_set_parent - switch the parent of a mux clk
> + * @clk: the mux clk whose input we are switching
> + * @parent: the new input to clk
> + *
> + * Re-parent clk to use parent as its new input source. If clk is in
> + * prepared state, the clk will get enabled for the duration of this call. If
> + * that's not acceptable for a specific clk (Eg: the consumer can't handle
> + * that, the reparenting is glitchy in hardware, etc), use the
> + * CLK_SET_PARENT_GATE flag to allow reparenting only when clk is unprepared.
> + *
> + * After successfully changing clk's parent clk_set_parent will update the
> + * clk topology, sysfs topology and propagate rate recalculation via
> + * __clk_recalc_rates.
> + *
> + * Returns 0 on success, -EERROR otherwise.
> + */
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + if (!clk || !parent)
> + return 0;
This is a behavior change, although it's very possible nobody
cares besides clk.c itself. Before this change
clk_set_parent(clk, NULL) would orphan the clock and move it to
the orphan list. Now we're going to do nothing. We should keep
the original behavior, although I don't know why anybody would
want to orphan a clock from a driver. The only place I think
we're using this correctly is on the clock unregistration path.
> +
> + return clk_core_set_parent(clk->core, parent->core);
> +}
> EXPORT_SYMBOL_GPL(clk_set_parent);
>
> /**
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [next-20150119]regression (mm)?
On 16:05-20150120, Kirill A. Shutemov wrote: > Russell King - ARM Linux wrote: > > On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: > > > Better option would be converting 2-lvl ARM configuration to > > > , but I'm not sure if it's possible. > > > > Well, IMHO the folded approach in asm-generic was done the wrong way > > which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? > > From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 20 Jan 2015 15:47:22 +0200 > Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE > > ARM uses custom implementation of PMD folding in 2-level page table case. > Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is > folded, but ARM doesn't do this. Let's fix it. > > Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). > It also fixes problems with recently-introduced pmd accounting on ARM > without LPAE. > > Signed-off-by: Kirill A. Shutemov > Reported-by: Nishanth Menon > --- > arch/arm/include/asm/pgtable-2level.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/pgtable-2level.h > b/arch/arm/include/asm/pgtable-2level.h > index bcc5e300413f..bfd662e49a25 100644 > --- a/arch/arm/include/asm/pgtable-2level.h > +++ b/arch/arm/include/asm/pgtable-2level.h > @@ -10,6 +10,8 @@ > #ifndef _ASM_PGTABLE_2LEVEL_H > #define _ASM_PGTABLE_2LEVEL_H > > +#define __PAGETABLE_PMD_FOLDED > + > /* > * Hardware-wise, we have a two level page table structure, where the first > * level has 4096 entries, and the second level has 256 entries. Each entry > -- > 2.1.4 Above helps the TI platforms 1: am335x-evm: BOOT: PASS: am335x-evm.txt 2: am335x-sk: BOOT: PASS: am335x-sk.txt 3: am3517-evm: BOOT: PASS: am3517-evm.txt 4: am37x-evm: BOOT: PASS: am37x-evm.txt 5: am437x-sk: BOOT: PASS: am437x-sk.txt 6:am43xx-epos: BOOT: PASS: am43xx-epos.txt 7: am43xx-gpevm: BOOT: PASS: am43xx-gpevm.txt 8:BeagleBoard-X15(am57xx-evm): BOOT: PASS: am57xx-evm.txt 9: BeagleBoard-XM: BOOT: PASS: beagleboard.txt 10:beagleboard-vanilla: BOOT: PASS: beagleboard-vanilla.txt 11: beaglebone-black: BOOT: PASS: beaglebone-black.txt 12: beaglebone: BOOT: PASS: beaglebone.txt 13: craneboard: BOOT: PASS: craneboard.txt 14: dra72x-evm: BOOT: PASS: dra72x-evm.txt 15: dra7xx-evm: BOOT: PASS: dra7xx-evm.txt 16: OMAP3430-Labrador(LDP): BOOT: PASS: ldp.txt 17: n900: BOOT: FAIL: n900.txt (legacy issue with my farm) 18: omap5-evm: BOOT: PASS: omap5-evm.txt 19: pandaboard-es: BOOT: PASS: pandaboard-es.txt 20: pandaboard-vanilla: BOOT: PASS: pandaboard-vanilla.txt 21:sdp2430: BOOT: PASS: sdp2430.txt 22:sdp3430: BOOT: PASS: sdp3430.txt 23:sdp4430: BOOT: PASS: sdp4430.txt TOTAL = 23 boards, Booted Boards = 22, No Boot boards = 1 please feel free to add my Tested-by: Nishanth Menon -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bluetooth: Add hci_h4p driver
On Tue 2015-01-20 10:28:50, Johan Hedberg wrote:
> Hi Pavel,
>
> On Tue, Dec 23, 2014, Pavel Machek wrote:
> > + while (1) {
> > + int cmd, len;
> > +
> > + fw_pos += cmd_len;
> > +
> > + if (fw_pos >= fw_entry->size)
> > + break;
> > +
> > + if (fw_pos + 2 > fw_entry->size) {
> > + dev_err(info->dev, "Corrupted firmware image\n");
> > + err = -EMSGSIZE;
> > + break;
> > + }
> > +
> > + cmd_len = fw_entry->data[fw_pos++];
> > + cmd_len += fw_entry->data[fw_pos++] << 8;
> > + if (cmd_len == 0)
> > + break;
> > +
> > + if (fw_pos + cmd_len > fw_entry->size) {
> > + dev_err(info->dev, "Corrupted firmware image\n");
> > + err = -EMSGSIZE;
> > + break;
> > + }
> > +
> > + /* Skip first two packets */
> > + if (++num <= 2)
> > + continue;
> > +
> > + /* Note that this is timing-critical. If sending packets takes
> > too
> > +* long, initialization will fail.
> > +*/
> > + cmd = fw_entry->data[fw_pos+1];
> > + cmd += fw_entry->data[fw_pos+2] << 8;
> > + len = fw_entry->data[fw_pos+3];
> > +
> > + skb = __hci_cmd_sync(info->hdev, cmd, len,
> > fw_entry->data+fw_pos+4, 500);
> > + if (IS_ERR(skb)) {
> > + dev_err(info->dev, "...sending cmd %x len %d failed
> > %ld\n",
> > + cmd, len, PTR_ERR(skb));
> > + err = -EIO;
> > + break;
> > + }
> > + }
>
> Looks like the code is leaking skb when __hci_cmd_sync() succeeds.
Fixed, thanks!
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support
* Dave Gerlach [150120 12:35]: > Tony, > On 01/20/2015 12:03 PM, Tony Lindgren wrote: > > * Dave Gerlach [141126 13:54]: > >> Hi, > >> This series is v5 of the series to add suspend/resume support for Texas > >> Instruments AM335x SoC. It has gone through a rather major overhaul > >> since the last version and because of that has been split into multiple > >> different sets of patches, on which this series depends. Previous > >> discussion > >> that influenced there changes can be found here [1]. This series depends on > >> generic sram exec mapping patch here [2], emif series here [3], > >> and wkup_m3_ipc series here [4]. I have pushed a branch containing the > >> patches > >> from ALL required series here [5] for testing or a view of the high level > >> flow of the entire series. > >> > >> The largest change with this revision is the introduction of a > >> wkup_m3_ipc driver which handles all communication with the Cortex M3 > >> present on am335x for handling low power tasks. Previously this was > >> handled in the wkup_m3_rproc driver (also sent in an earlier series) > >> but that driver is now only responsible for booting the wkup_m3. The > >> wkup_m3_ipc driver exposes an API with all required PM functionality > >> needed by the PM code introduced by this series, so the PM code has > >> shrunk considerably. > >> > >> Another major change is that the EMIF code previously present in the > >> sleep33xx asm code and pm33xx code for save and restore of EMIF context > >> and entry into low power mode has all been moved in to a separate EMIF > >> driver, further reducing the size of the PM code. Because of this, moving > >> the emif header defines into include/linux/ti_emif.h is no longer > >> necessary. > >> > >> Other changes include clean up of the timer suspend/resume handlers, now > >> look up hwmod in init and use that handle along with renaming to > >> *_idle/*_unidle to avoid confusion with true suspend handlers. > >> > >> Suspend support requires: > >> CONFIG_TI_EMIF_SRAM > >> CONFIG_WKUP_M3_RPROC > >> CONFIG_WKUP_M3_IPC > >> > >> And also requires AM335x USB support to be enabled to work for multiple > >> cycles. If you want to load firmware from rootfs in /lib/firmware you now > >> must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK. > >> > >> This code works with version 0x189 of the CM3 firmware found here [6] on > >> the next branch, /bin/am335x-pm-firmware.elf. > > > > Dave, does this series have dependencies to the other patches? Can some > > parts of this already be applied without breaking anything? > > > > The only patch with no dependencies is patch 1 (ARM: OMAP2+: timer: Add > suspend-resume callbacks for clkevent device). It's ready to be applied, I > just > applied to v3.19-rc5 and built and booted on am335x-evm with no issue just to > be > sure. It won't actually do anything until suspend is completely implemented. OK thanks for checking, best to wait until it's usable then. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support
Tony, On 01/20/2015 12:03 PM, Tony Lindgren wrote: > * Dave Gerlach [141126 13:54]: >> Hi, >> This series is v5 of the series to add suspend/resume support for Texas >> Instruments AM335x SoC. It has gone through a rather major overhaul >> since the last version and because of that has been split into multiple >> different sets of patches, on which this series depends. Previous discussion >> that influenced there changes can be found here [1]. This series depends on >> generic sram exec mapping patch here [2], emif series here [3], >> and wkup_m3_ipc series here [4]. I have pushed a branch containing the >> patches >> from ALL required series here [5] for testing or a view of the high level >> flow of the entire series. >> >> The largest change with this revision is the introduction of a >> wkup_m3_ipc driver which handles all communication with the Cortex M3 >> present on am335x for handling low power tasks. Previously this was >> handled in the wkup_m3_rproc driver (also sent in an earlier series) >> but that driver is now only responsible for booting the wkup_m3. The >> wkup_m3_ipc driver exposes an API with all required PM functionality >> needed by the PM code introduced by this series, so the PM code has >> shrunk considerably. >> >> Another major change is that the EMIF code previously present in the >> sleep33xx asm code and pm33xx code for save and restore of EMIF context >> and entry into low power mode has all been moved in to a separate EMIF >> driver, further reducing the size of the PM code. Because of this, moving >> the emif header defines into include/linux/ti_emif.h is no longer necessary. >> >> Other changes include clean up of the timer suspend/resume handlers, now >> look up hwmod in init and use that handle along with renaming to >> *_idle/*_unidle to avoid confusion with true suspend handlers. >> >> Suspend support requires: >> CONFIG_TI_EMIF_SRAM >> CONFIG_WKUP_M3_RPROC >> CONFIG_WKUP_M3_IPC >> >> And also requires AM335x USB support to be enabled to work for multiple >> cycles. If you want to load firmware from rootfs in /lib/firmware you now >> must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK. >> >> This code works with version 0x189 of the CM3 firmware found here [6] on >> the next branch, /bin/am335x-pm-firmware.elf. > > Dave, does this series have dependencies to the other patches? Can some > parts of this already be applied without breaking anything? > The only patch with no dependencies is patch 1 (ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device). It's ready to be applied, I just applied to v3.19-rc5 and built and booted on am335x-evm with no issue just to be sure. It won't actually do anything until suspend is completely implemented. Regards, Dave > Regards, > > Tony > >> [1] http://www.spinics.net/lists/linux-omap/msg109331.html >> [2] http://www.spinics.net/linux/lists/kernel/msg1876629.html >> [3] http://www.spinics.net/linux/lists/kernel/msg1876646.html >> [4] http://www.spinics.net/linux/lists/kernel/msg1876642.html >> [5] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6 >> [6] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next >> >> Dave Gerlach (3): >> ARM: OMAP2+: AM33XX: Add assembly code for PM operations >> ARM: OMAP2+: AM33XX: Basic suspend resume support >> ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds >> >> Vaibhav Bedia (1): >> ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device >> arch/arm/boot/dts/am33xx.dtsi | 2 + >> arch/arm/mach-omap2/Makefile| 2 + >> arch/arm/mach-omap2/common.h| 9 ++ >> arch/arm/mach-omap2/io.c| 1 + >> arch/arm/mach-omap2/pm.h| 6 + >> arch/arm/mach-omap2/pm33xx.c| 250 >> >> arch/arm/mach-omap2/sleep33xx.S | 216 ++ >> arch/arm/mach-omap2/timer.c | 28 + >> 8 files changed, 514 insertions(+) >> create mode 100644 arch/arm/mach-omap2/pm33xx.c >> create mode 100644 arch/arm/mach-omap2/sleep33xx.S >> >> -- >> 2.1.0 >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: dts: dra72-evm: Add extcon nodes for USB
On Mon, Jan 19, 2015 at 07:52:21PM +0200, Roger Quadros wrote:
> On this EVM, the USB cable state has to be determined via the
> ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
> to read the ID pin and the extcon framework to forward
> the USB cable state information to the USB driver so the
> controller can be configured in the right mode (host/peripheral).
>
> Gets USB peripheral mode to work on this EVM.
>
> Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
> ---
> arch/arm/boot/dts/dra72-evm.dts | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index 89085d0..d93a98f 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -8,6 +8,7 @@
> /dts-v1/;
>
> #include "dra72x.dtsi"
> +#include
>
> / {
> model = "TI DRA722";
> @@ -24,6 +25,16 @@
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> };
> +
> + extcon_usb1: extcon_usb1 {
> + compatible = "linux,extcon-usb";
> + id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + extcon_usb2: extcon_usb2 {
> + compatible = "linux,extcon-usb";
> + id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
> + };
> };
>
> &dra7_pmx_core {
> @@ -243,6 +254,18 @@
> ti,palmas-long-press-seconds = <6>;
> };
> };
> +
> + pcf_gpio_21: gpio@21 {
> + compatible = "ti,pcf8575";
> + reg = <0x21>;
> + lines-initial-states = <0x1408>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> };
>
> &uart1 {
> @@ -345,6 +368,14 @@
> phy-supply = <&ldo4_reg>;
> };
>
> +&omap_dwc3_1 {
> + extcon = <&extcon_usb1>;
> +};
> +
> +&omap_dwc3_2 {
> + extcon = <&extcon_usb2>;
> +};
> +
> &usb1 {
> dr_mode = "peripheral";
> pinctrl-names = "default";
> --
> 2.1.0
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/5] extcon: usb: Introduce USB GPIO extcon driver. Fix DRA7 USB.
On Mon, Jan 19, 2015 at 07:52:17PM +0200, Roger Quadros wrote: > Hi, > > On DRA7 EVMs the USB ID pin is connected to a GPIO line. The USB drivers > (dwc3 + dwc3-omap) depend on extcon framework to get the USB cable state > (USB or USB-Host) to put the controller in the right mode. > > There were earlier attempts [1] to get this working by trying to patch up > the existing GPIO extcon driver. > > This series attemts to take a different approach by introducing a new > USB specific extcon driver to handle the USB ID GPIO pin and > interpret a right USB cable state. > > The reasoning to introduce this new driver is: > 1) The existing GPIO extcon driver doesn't understand USB cable states > and it can't handle more than one cable per instance. > > For the USB case we need to handle at least 2 cable states. > a) USB (attach/detach) > b) USB-Host (attach/detach) > and could possible include more states like > c) Fast-charger (attach/detach) > d) Slow-charger (attach/detach) > > 2) This USB specific driver can be easily updated in the future to > handle VBUS events, or charger detect events, in case it happens > to be available on GPIO for any platform. > > 3) The DT implementation is very easy. You just need one extcon node per USB > instead of one extcon node per cable state as in case of [1]. > > 4) The cable state string doesn't need to be encoded in the device tree > as in case of [1]. > > 5) With only ID event available, you can simulate a USB-peripheral attach > when USB-Host is detacted instead of hacking the USB driver to do the same. > > Tested on DRA7-evm and DRA72-evm. while at that, you might want to patch X15 too. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/5] ARM: dts: dra7-evm: Add extcon nodes for USB
On Mon, Jan 19, 2015 at 07:52:20PM +0200, Roger Quadros wrote:
> On this EVM, the USB cable state has to be determined via the
> ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
> to read the ID pin and the extcon framework to forward
> the USB cable state information to the USB driver so the
> controller can be configured in the right mode (host/peripheral).
>
> Gets USB peripheral mode to work on this EVM.
>
> Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
> ---
> arch/arm/boot/dts/dra7-evm.dts | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 10b725c..47d9a06 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -26,6 +26,16 @@
> regulator-max-microvolt = <330>;
> };
>
> + extcon_usb1: extcon_usb1 {
> + compatible = "linux,extcon-usb";
> + id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + extcon_usb2: extcon_usb2 {
> + compatible = "linux,extcon-usb";
> + id-gpio = <&pcf_gpio_21 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> vtt_fixed: fixedregulator-vtt {
> compatible = "regulator-fixed";
> regulator-name = "vtt_fixed";
> @@ -391,6 +401,19 @@
> };
> };
> };
> +
> + pcf_gpio_21: gpio@21 {
> + compatible = "ti,pcf8575";
> + reg = <0x21>;
> + lines-initial-states = <0x1408>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> };
>
> &i2c2 {
> @@ -520,6 +543,14 @@
> };
> };
>
> +&omap_dwc3_1 {
> + extcon = <&extcon_usb1>;
> +};
> +
> +&omap_dwc3_2 {
> + extcon = <&extcon_usb2>;
> +};
> +
> &usb1 {
> dr_mode = "peripheral";
> pinctrl-names = "default";
> --
> 2.1.0
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/5] usb: extcon: Fix USB-Host cable name
On Mon, Jan 19, 2015 at 07:52:19PM +0200, Roger Quadros wrote:
> The recommended name for USB-Host cable state is "USB-Host" and not
> "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name.
>
> Change all instances of "USB-HOST" to "USB-Host".
>
> Signed-off-by: Roger Quadros
I checked that these are not documented and there are no DTS using
USB-HOST, so it's fine to change
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
> ---
> drivers/extcon/extcon-palmas.c | 18 +-
> drivers/usb/dwc3/dwc3-omap.c | 6 +++---
> drivers/usb/phy/phy-omap-otg.c | 4 ++--
> drivers/usb/phy/phy-tahvo.c| 8
> 4 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 11c6757..6d002c3 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -31,7 +31,7 @@
>
> static const char *palmas_extcon_cable[] = {
> [0] = "USB",
> - [1] = "USB-HOST",
> + [1] = "USB-Host",
> NULL,
> };
>
> @@ -93,26 +93,26 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
> *_palmas_usb)
> PALMAS_USB_ID_INT_LATCH_CLR,
> PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
> palmas_usb->linkstat = PALMAS_USB_STATE_ID;
> - extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
> - dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
> + extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
> + dev_info(palmas_usb->dev, "USB-Host cable is attached\n");
> } else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
> (id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
> palmas_write(palmas_usb->palmas, PALMAS_USB_OTG_BASE,
> PALMAS_USB_ID_INT_LATCH_CLR,
> PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
> palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
> - extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
> - dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
> + extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
> + dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
> } else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
> (!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
> palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
> - extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
> - dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
> + extcon_set_cable_state(palmas_usb->edev, "USB-Host", false);
> + dev_info(palmas_usb->dev, "USB-Host cable is detached\n");
> } else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
> (id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
> palmas_usb->linkstat = PALMAS_USB_STATE_ID;
> - extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
> - dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
> + extcon_set_cable_state(palmas_usb->edev, "USB-Host", true);
> + dev_info(palmas_usb->dev, " USB-Host cable is attached\n");
> }
>
> return IRQ_HANDLED;
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index 172d64e..6713ad9 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -445,14 +445,14 @@ static int dwc3_omap_extcon_register(struct dwc3_omap
> *omap)
>
> omap->id_nb.notifier_call = dwc3_omap_id_notifier;
> ret = extcon_register_interest(&omap->extcon_id_dev,
> -edev->name, "USB-HOST",
> +edev->name, "USB-Host",
> &omap->id_nb);
> if (ret < 0)
> - dev_vdbg(omap->dev, "failed to register notifier for
> USB-HOST\n");
> + dev_vdbg(omap->dev, "failed to register notifier for
> USB-Host\n");
>
> if (extcon_get_cable_state(edev, "USB") == true)
> dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
> - if (extcon_get_cable_state(edev, "USB-HOST") == true)
> + if (extcon_get_cable_state(edev, "USB-Host") == true)
> dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
> }
>
> diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
> index 56ee760..53cba3f 100644
> --- a/drivers/usb/phy/phy-omap-otg.c
> +++ b/drivers/usb/phy/phy-omap-otg.c
> @@ -119,7 +119,7 @@ static int omap_otg_probe(struct platform_device *pdev)
> otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
>
> ret = extcon_register_interest(&otg_dev->id_dev, con
Re: [PATCH 1/5] extcon: gpio-usb: Introduce gpio usb extcon driver
On Mon, Jan 19, 2015 at 07:52:18PM +0200, Roger Quadros wrote:
> This driver observes the USB ID pin connected over a GPIO and
> updates the USB cable extcon states accordingly.
>
> The existing GPIO extcon driver is not suitable for this purpose
> as it needs to be taught to understand USB cable states and it
> can't handle more than one cable per instance.
>
> For the USB case we need to handle 2 cable states.
> 1) USB (attach/detach)
> 2) USB-Host (attach/detach)
>
> This driver can be easily updated in the future to handle VBUS
> events in case it happens to be available on GPIO for any platform.
>
> Signed-off-by: Roger Quadros
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
> ---
> .../devicetree/bindings/extcon/extcon-usb.txt | 20 ++
> drivers/extcon/Kconfig | 7 +
> drivers/extcon/Makefile| 1 +
> drivers/extcon/extcon-gpio-usb.c | 225
> +
> 4 files changed, 253 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb.txt
> create mode 100644 drivers/extcon/extcon-gpio-usb.c
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> new file mode 100644
> index 000..171c5a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb.txt
> @@ -0,0 +1,20 @@
> +USB Extcon device
> +
> +This is a virtual device used to generate USB cable states from the USB ID
> pin
> +connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Should be "linux,extcon-usb"
> +- id-gpio: gpio for USB ID pin. See gpio binding.
> +
> +Example:
> + extcon_usb1 {
> + compatible = "linux,extcon-usb";
> + id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + usb@1 {
> + ...
> + extcon = <&extcon_usb1>;
> + ...
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de..8106a83 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -35,6 +35,13 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_GPIO_USB
> + tristate "USB GPIO extcon support"
> + depends on GPIOLIB
> + help
> + Say Y here to enable GPIO based USB cable detection extcon support.
> + Used typically if GPIO is used for USB ID pin detection.
> +
> config EXTCON_MAX14577
> tristate "MAX14577/77836 EXTCON Support"
> depends on MFD_MAX14577
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42..bae594b 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_GPIO_USB)+= extcon-gpio-usb.o
> diff --git a/drivers/extcon/extcon-gpio-usb.c
> b/drivers/extcon/extcon-gpio-usb.c
> new file mode 100644
> index 000..aeb2298
> --- /dev/null
> +++ b/drivers/extcon/extcon-gpio-usb.c
> @@ -0,0 +1,225 @@
> +/**
> + * drivers/extcon/extcon_gpio_usb.c - USB GPIO extcon driver
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Author: Roger Quadros
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
> +
> +struct usb_extcon_info {
> + struct device *dev;
> + struct extcon_dev *edev;
> +
> + struct gpio_desc *id_gpiod;
> + int id_irq;
> +
> + unsigned long debounce_jiffies;
> + struct delayed_work wq_detcable;
> +};
> +
> +/* List of detectable cables */
> +enum {
> + EXTCON_CABLE_USB = 0,
> + EXTCON_CABLE_USB_HOST,
> +
> + EXTCON_CABLE_END,
> +};
> +
> +static const char *usb_extcon_cable[] = {
> + [EXTCON_CABLE_USB] = "USB",
> + [EXTCON_CABLE_USB_HOST] = "USB-Host",
> + NULL,
> +};
> +
> +static void usb_extcon_detect_cable(struct work_struct *work)
> +{
> + int id;
> + struct usb_extcon_info *info;
> + const char **cable_names;
> +
> + info = container_of(to_delayed_work(work), struct usb_extcon_info,
> +
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi Pavel,
>>> Add HCI driver for H4 with Nokia extensions. This device is used on
>>> Nokia N900 cell phone.
>>>
>>> Older version of this driver lived in staging, before being reverted
>>> in a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd .
>>>
>>> Signed-off-by: Pavel Machek
>>> Thanks-to: Sebastian Reichel
>>> Thanks-to: Joe Perches
>>>
>>> ---
>>>
>>> Please apply,
>>> Pavel
>>>
>>>
>>> Kconfig | 10
>>> Makefile |4
>>> nokia_core.c | 1149
>>> +++
>>> nokia_fw.c | 99 +
>>> nokia_h4p.h | 214 ++
>>> nokia_uart.c | 171
>>> 7 files changed, 1667 insertions(+)
>
> Speaking about formatting, could you properly format your emails, that
> is inserting newline after ~78 columns, to make them easier to reply
> to?
or you get an email client that can handle that part.
>> so when I run this through checkpatch --strict, then I get tons of warning
>> that we have DOS style ^M line breaks. There are also trailing whitespace
>> that need fixing. I can use cleanpatch to do this, but so can you.
>>
>
> Strange, where do you see DOS style line breaks? Checkpatch here does
> not warn about that, and they really should not be there.
If that would be the only pieces, then I would have fixed it already. That is
not the big deal. The rest of checkpatch is what I am not going to fix for you.
>> Even after doing that there are still obvious plain coding style violation
>> in the patch. For example:
>>
>> ERROR: space prohibited before that ',' (ctx:WxW)
>> #610: FILE: drivers/bluetooth/nokia_core.c:517:
>> +__h4p_set_auto_ctsrts(info, 0 , UART_EFR_RTS);
>
> Yeah, I should have catched that one.
>
>> CHECK: Alignment should match open parenthesis
>> #662: FILE: drivers/bluetooth/nokia_core.c:569:
>> +h4p_outb(info, UART_OMAP_SCR,
>> + h4p_inb(info, UART_OMAP_SCR) |
>>
>> CHECK: Blank lines aren't necessary before a close brace '}'
>> #692: FILE: drivers/bluetooth/nokia_core.c:599:
>> +
>> +}
>>
>> These are only few. They are more and all these need fixing before I
>> even consider it.
>
> Yeah, so first patch was too good for staging, and I "would be allowed
> to clean it up in tree", and now you run checkpatch --strict,
> complaining about very serious stuff such as "blank lines before }".
The network subsystem requires the --strict option.
Please stop complaining about staging. The patch went in, it was ignored for
month and multiple kernel release and it got removed. Deal with it.
>
> Yes, checkpatch produces a lot of junk, like warnings about
> mdelay(). I'm not sure how you'd want #662 above, formatted.
>
> pavel@amd:/data/l/linux-n900$ scripts/checkpatch.pl --strict --file
> drivers/bluetooth/*.c | wc -l 3194
> pavel@amd:/data/l/linux-n900$
>
> ...so I really can't know which checkpatch complains you consider
> serious and which are ok... And yes, I guess I should trim down those
> FSF notices.
The FSF notices are the ones I do not care about right now. Even the over 80
characters lines can be ignored if it just makes sense to go over.
The indentations ones need to be fixed.
>
>> Also this worries me:
>>
>> WARNING: DT compatible string "brcm,uart,bcm2048" appears un-documented --
>> check ./Documentation/devicetree/bindings/
>> #1222: FILE: drivers/bluetooth/nokia_core.c:1129:
>> +{ .compatible = "brcm,uart,bcm2048" },
>
> Yes, that wories me, too. It is one of reasons I wanted this to be
> merged to staging. Arguing about right bindings will take some time.
Then that needs to be figured out. It is not that I have mentioned DT for the
first time. I said that right from the beginning.
> I can fix the checkpatch stuff that makes sense. That does not include
> uglyfying code just for checkpatch. Can you then take the patch, as
> you promised, and let me argue the bindings, and the other stuff that
> needs to be fixed?
>
> If not, can we agree that the driver in staging should be reverted, as
> Greg promised would be "easy", and I can clean it up there?
I am refusing to allow this into staging. Get this into shape for
drivers/bluetooth/ or keep the driver external.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 2/3] omap defconfig changes for v3.20
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/defconfig-modular for you to fetch changes up to 697549cdd637841e7c88d0014fe25dfbb72565de: ARM: omap2plus_defconfig: Enable OHCI & EHCI HCD support (2015-01-20 09:46:31 -0800) Defconfig changes for omap2plus_defconfig to make it more modular, and to add few more drivers found on various boards. Felipe Balbi (2): ARM: omap2plus_defconfig: reduce zImage size on omap2plus_defconfig ARM: omap2plus_defconfig: enable TPS65218 power button Nishanth Menon (1): ARM: omap2plus_defconfig: Enable misc options for BeagleBoard-X15 platform Sjoerd Simons (1): ARM: omap2plus_defconfig: Enable OHCI & EHCI HCD support Tony Lindgren (3): ARM: omap2plus_defconfig: Enable support for davinci_emac ARM: omap2plus_defconfig: Add NOR flash support ARM: omap2plus_defconfig: Enable pcf857x arch/arm/configs/omap2plus_defconfig | 128 +++ 1 file changed, 84 insertions(+), 44 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/3] drop legacy booting for omap3517
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/drop-legacy-3517-v2 for you to fetch changes up to 549f95ed20168daa06901054a028e185ebb905ab: ARM: OMAP3: Add back Kconfig option MACH_OMAP3517EVM for ASoC (2015-01-20 08:49:08 -0800) We have had omap3517 booting in device tree mode for quite some time now and we have at least a minimal dts file for the 3517 based boards. Also almost all the drivers are usable in device tree mode. And if there are any drivers not yet supported in device tree mode, those can be enabled using pdata quirks. This leaves omap3430 to omap3730 as the only remaining mach-omap2 platforms still booting in legacy mode also. For those were are printing a warning during the boot to get people to update their systems to boot in device tree mode and slowly converting them over to device tree based booting. Tony Lindgren (5): ARM: OMAP3: Remove legacy support for am3517-evm ARM: OMAP3: Remove legacy support for am3517crane ARM: OMAP3: Remove cm-t3517 legacy support ARM: OMAP3: Remove legacy support for am35xx-emac ARM: OMAP3: Add back Kconfig option MACH_OMAP3517EVM for ASoC arch/arm/mach-omap2/Kconfig| 12 - arch/arm/mach-omap2/Makefile | 8 - arch/arm/mach-omap2/am35xx-emac.c | 114 - arch/arm/mach-omap2/am35xx-emac.h | 15 -- arch/arm/mach-omap2/am35xx.h | 46 arch/arm/mach-omap2/board-am3517crane.c| 150 arch/arm/mach-omap2/board-am3517evm.c | 373 - arch/arm/mach-omap2/board-cm-t3517.c | 335 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 33 +-- arch/arm/mach-omap2/pdata-quirks.c | 1 - 10 files changed, 2 insertions(+), 1085 deletions(-) delete mode 100644 arch/arm/mach-omap2/am35xx-emac.c delete mode 100644 arch/arm/mach-omap2/am35xx-emac.h delete mode 100644 arch/arm/mach-omap2/am35xx.h delete mode 100644 arch/arm/mach-omap2/board-am3517crane.c delete mode 100644 arch/arm/mach-omap2/board-am3517evm.c delete mode 100644 arch/arm/mach-omap2/board-cm-t3517.c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 3/3] omap device tree changes for v3.20, part 2
The following changes since commit 7300bfff886a1340cfeb252035303e265cd556d9: ARM: dts: omap3-gta04: Add handling for tv output (2015-01-13 08:02:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/dt-pt2 for you to fetch changes up to 1f43c45df7afb706470f7d81d983dd7763a9452f: ARM: dts: dra72-evm: Add qspi device (2015-01-20 10:07:25 -0800) More changes for omap dts files mostly to add support for dm816x devices and clocks. Also adds a qspi device for dra72x-evm. Mugunthan V N (1): ARM: dts: dra72-evm: Add qspi device Tony Lindgren (3): ARM: dts: Add basic dm816x device tree configuration ARM: dts: Add basic clocks for dm816x ARM: dts: Add minimal support for dm8168-evm arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/dm8168-evm.dts | 129 arch/arm/boot/dts/dm816x-clocks.dtsi | 250 ++ arch/arm/boot/dts/dm816x.dtsi| 387 +++ arch/arm/boot/dts/dra72-evm.dts | 77 +++ include/dt-bindings/pinctrl/omap.h | 1 + 6 files changed, 845 insertions(+) create mode 100644 arch/arm/boot/dts/dm8168-evm.dts create mode 100644 arch/arm/boot/dts/dm816x-clocks.dtsi create mode 100644 arch/arm/boot/dts/dm816x.dtsi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2plus_defconfig: Enable misc options for BeagleBoard-X15 platform
* Felipe Balbi [150108 14:03]: > On Thu, Jan 08, 2015 at 03:14:40PM -0600, Nishanth Menon wrote: > > BeagleBoard-X15 has options such as rtc, fan that need to be functional > > > > Signed-off-by: Nishanth Menon > > Reviewed-by: Felipe Balbi Applying into omap-for-v3.20/defconfig thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: dts: dra72-evm: Add qspi device
* Mugunthan V N [150119 01:53]: > These add device tree entry for qspi device on dra72-evm. Applying into omap-for-v3.20/dt thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
* Ohad Ben-Cohen [150116 16:50]: > Mark, > > On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland wrote: > >> The hwlock is a basic hardware primitive that allow synchronization > >> between different processors in the system, which may be running Linux > >> as well as other operating systems, and may have no other means of > >> communication. > >> > >> The hwlock id numbers are predefined, global and static across the > >> entire system: Linux may boot well after other operating systems are > >> already running and using these hwlocks to communicate, and therefore, > >> in order to use these hardware devices, it must not enumerate them > >> differently than the rest of the system. > > > > That's not true. > > > > In order to communicate it must agree with the other users as to the > > meaning of each instance, and the protocol for use. That doesn't > > necessarily mean that Linux needs to know the numerical ID from a > > datasheet, and regardless that ID is separate from the logical ID Linux > > uses internally. > > Let me describe hwspinlocks a bit more so we all get to know it better > and can then agree on a proper solution. > > - What makes handling of hwspinlock ID numbers convenient is the fact > that it's not based on random datasheet numbers. In fact, hwspinlocks > is just special memory: usually datasheets just define the base > address and the size of the hwspinlock area. So any numerical ID we > use to call the locks themselves are already logical and sane, similar > to the way we handle memory (i.e. if we have 32 locks we'll always use > 0..31). So hwlocks ids are very much like memory addressing, and not > irq numbers. > > - Sometimes Linux will have to dynamically allocate a hwlock, and send > the ID of the allocated lock to a remote processor (which may not be > running Linux). > - Sometimes a remote processor, which may not be running Linux, will > have to dynamically allocate a hwlock, and send the ID of the > allocated lock to us (another processor running Linux) > > We cannot tell in advance what kind of IPC is going to be used for > sending and receiving this hwlock ID. Some are handled by Linux > (kernel) and some by the user space. So we must be able to expose an > ID the system will understand as well as receive one. How about default to Linux id space and allow overriding that with a module param option if needed? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 0/4] ARM: OMAP2+: AM33XX: Add suspend-resume support
* Dave Gerlach [141126 13:54]: > Hi, > This series is v5 of the series to add suspend/resume support for Texas > Instruments AM335x SoC. It has gone through a rather major overhaul > since the last version and because of that has been split into multiple > different sets of patches, on which this series depends. Previous discussion > that influenced there changes can be found here [1]. This series depends on > generic sram exec mapping patch here [2], emif series here [3], > and wkup_m3_ipc series here [4]. I have pushed a branch containing the patches > from ALL required series here [5] for testing or a view of the high level > flow of the entire series. > > The largest change with this revision is the introduction of a > wkup_m3_ipc driver which handles all communication with the Cortex M3 > present on am335x for handling low power tasks. Previously this was > handled in the wkup_m3_rproc driver (also sent in an earlier series) > but that driver is now only responsible for booting the wkup_m3. The > wkup_m3_ipc driver exposes an API with all required PM functionality > needed by the PM code introduced by this series, so the PM code has > shrunk considerably. > > Another major change is that the EMIF code previously present in the > sleep33xx asm code and pm33xx code for save and restore of EMIF context > and entry into low power mode has all been moved in to a separate EMIF > driver, further reducing the size of the PM code. Because of this, moving > the emif header defines into include/linux/ti_emif.h is no longer necessary. > > Other changes include clean up of the timer suspend/resume handlers, now > look up hwmod in init and use that handle along with renaming to > *_idle/*_unidle to avoid confusion with true suspend handlers. > > Suspend support requires: > CONFIG_TI_EMIF_SRAM > CONFIG_WKUP_M3_RPROC > CONFIG_WKUP_M3_IPC > > And also requires AM335x USB support to be enabled to work for multiple > cycles. If you want to load firmware from rootfs in /lib/firmware you now > must also select CONFIG_FW_LOADER_USER_HELPER_FALLBACK. > > This code works with version 0x189 of the CM3 firmware found here [6] on > the next branch, /bin/am335x-pm-firmware.elf. Dave, does this series have dependencies to the other patches? Can some parts of this already be applied without breaking anything? Regards, Tony > [1] http://www.spinics.net/lists/linux-omap/msg109331.html > [2] http://www.spinics.net/linux/lists/kernel/msg1876629.html > [3] http://www.spinics.net/linux/lists/kernel/msg1876646.html > [4] http://www.spinics.net/linux/lists/kernel/msg1876642.html > [5] https://github.com/dgerlach/linux-pm/tree/rfc-pm-am335x-v3.18-rc6 > [6] https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next > > Dave Gerlach (3): > ARM: OMAP2+: AM33XX: Add assembly code for PM operations > ARM: OMAP2+: AM33XX: Basic suspend resume support > ARM: OMAP2+: AM33XX: Hookup AM33XX PM code into OMAP builds > > Vaibhav Bedia (1): > ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device > > arch/arm/boot/dts/am33xx.dtsi | 2 + > arch/arm/mach-omap2/Makefile| 2 + > arch/arm/mach-omap2/common.h| 9 ++ > arch/arm/mach-omap2/io.c| 1 + > arch/arm/mach-omap2/pm.h| 6 + > arch/arm/mach-omap2/pm33xx.c| 250 > > arch/arm/mach-omap2/sleep33xx.S | 216 ++ > arch/arm/mach-omap2/timer.c | 28 + > 8 files changed, 514 insertions(+) > create mode 100644 arch/arm/mach-omap2/pm33xx.c > create mode 100644 arch/arm/mach-omap2/sleep33xx.S > > -- > 2.1.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: omap2plus_defconfig: Enable OHCI & EHCI HCD support
* Felipe Balbi [150119 13:45]: > On Mon, Jan 19, 2015 at 10:28:36PM +0100, Sjoerd Simons wrote: > > Enable CONFIG_USB_EHCI_HCD and CONFIG_USB_OHCI_HCD to get USB supports > > with omap2plus_defconfig. > > > > Signed-off-by: Sjoerd Simons > > Reviewed-by: Felipe Balbi Applying into omap-for-v3.20/defconfig thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi!
> > Add HCI driver for H4 with Nokia extensions. This device is used on
> > Nokia N900 cell phone.
> >
> > Older version of this driver lived in staging, before being reverted
> > in a4102f90e87cfaa3fdbed6fdf469b23f0eeb4bfd .
> >
> > Signed-off-by: Pavel Machek
> > Thanks-to: Sebastian Reichel
> > Thanks-to: Joe Perches
> >
> > ---
> >
> > Please apply,
> > Pavel
> >
> >
> > Kconfig | 10
> > Makefile |4
> > nokia_core.c | 1149
> > +++
> > nokia_fw.c | 99 +
> > nokia_h4p.h | 214 ++
> > nokia_uart.c | 171
> > 7 files changed, 1667 insertions(+)
Speaking about formatting, could you properly format your emails, that
is inserting newline after ~78 columns, to make them easier to reply
to?
> so when I run this through checkpatch --strict, then I get tons of warning
> that we have DOS style ^M line breaks. There are also trailing whitespace
> that need fixing. I can use cleanpatch to do this, but so can you.
>
Strange, where do you see DOS style line breaks? Checkpatch here does
not warn about that, and they really should not be there.
> Even after doing that there are still obvious plain coding style violation in
> the patch. For example:
>
> ERROR: space prohibited before that ',' (ctx:WxW)
> #610: FILE: drivers/bluetooth/nokia_core.c:517:
> + __h4p_set_auto_ctsrts(info, 0 , UART_EFR_RTS);
Yeah, I should have catched that one.
> CHECK: Alignment should match open parenthesis
> #662: FILE: drivers/bluetooth/nokia_core.c:569:
> + h4p_outb(info, UART_OMAP_SCR,
> + h4p_inb(info, UART_OMAP_SCR) |
>
> CHECK: Blank lines aren't necessary before a close brace '}'
> #692: FILE: drivers/bluetooth/nokia_core.c:599:
> +
> +}
>
> These are only few. They are more and all these need fixing before I
> even consider it.
Yeah, so first patch was too good for staging, and I "would be allowed
to clean it up in tree", and now you run checkpatch --strict,
complaining about very serious stuff such as "blank lines before }".
Yes, checkpatch produces a lot of junk, like warnings about
mdelay(). I'm not sure how you'd want #662 above, formatted.
pavel@amd:/data/l/linux-n900$ scripts/checkpatch.pl --strict --file
drivers/bluetooth/*.c | wc -l 3194
pavel@amd:/data/l/linux-n900$
...so I really can't know which checkpatch complains you consider
serious and which are ok... And yes, I guess I should trim down those
FSF notices.
> Also this worries me:
>
> WARNING: DT compatible string "brcm,uart,bcm2048" appears un-documented --
> check ./Documentation/devicetree/bindings/
> #1222: FILE: drivers/bluetooth/nokia_core.c:1129:
> + { .compatible = "brcm,uart,bcm2048" },
Yes, that wories me, too. It is one of reasons I wanted this to be
merged to staging. Arguing about right bindings will take some time.
I can fix the checkpatch stuff that makes sense. That does not include
uglyfying code just for checkpatch. Can you then take the patch, as
you promised, and let me argue the bindings, and the other stuff that
needs to be fixed?
If not, can we agree that the driver in staging should be reverted, as
Greg promised would be "easy", and I can clean it up there?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Menelaus cleanup for DT, phase 1
On Sat, 27 Dec 2014, Aaro Koskinen wrote: > These patches start removal of board-specific callbacks from Menelaus: > delete platform data and a callback from the driver to the board files. > > Tested on top of 3.19-rc1 on N800/N810 which are the only in-tree users > for the driver. > > Aaro Koskinen (7): > mfd: menelaus: delete omap_has_menelaus > mfd: menelaus: drop support for SW controller VCORE > mfd: menelaus: add initial DT support > ARM: OMAP: N8x0: configure menelaus using DT > mfd: menelaus: delete platform data support > mfd: menelaus: make vcore and regulator controls internal > mfd: menelaus: use macro for magic number > > Documentation/devicetree/bindings/mfd/menelaus.txt | 30 > arch/arm/boot/dts/omap2420-n8x0-common.dtsi| 3 + > arch/arm/mach-omap2/board-n8x0.c | 57 -- > arch/arm/mach-omap2/common-board-devices.h | 2 - > arch/arm/mach-omap2/pdata-quirks.c | 1 - > drivers/mfd/menelaus.c | 86 > ++ > include/linux/mfd/menelaus.h | 25 --- > 7 files changed, 87 insertions(+), 117 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mfd/menelaus.txt Scrap that. Looks like I can't apply the other patches without 03/07. Please sort this out with Felipe and re-submit. Don't forget to apply my Ack to the patches I said I "applied". -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP3: MACH_OMAP3517EVM?
* Tony Lindgren [150120 08:52]:
> * Paul Bolle [150120 01:06]:
> > Tony,
> >
> > Your commit 4d62dbda8561 ("ARM: OMAP3: Remove legacy support for
> > am3517-evm") is included in today's linux-next (ie, next-20150120). I
> > noticed because a script I use to check linux-next spotted a problem
> > caused by it.
>
> OK thanks for spotting that.
>
> > See, your commit removes the Kconfig symbol MACH_OMAP3517EVM. But
> > there's still a reference to that symbol in sound/soc/omap/Kconfig. This
> > means that in linux-next a symbol, SND_OMAP_SOC_AM3517EVM, cannot be set
> > anymore.
> >
> > I assume a patch that address this (either by removing
> > SND_OMAP_SOC_AM3517EVM or by updating its dependencies) is queued
> > somewhere. Is that correct?
>
> Not yet, I missed that part sorry. I'll add back the Kconfig symbol.
> I'll rather do the removal in smaller steps, and first remove the
> 3517 related board-*.c file before messing with the legacy drivers.
Below is a fix for this.
Regards,
Tony
8<
From: Tony Lindgren
Date: Tue, 20 Jan 2015 08:49:08 -0800
Subject: [PATCH] ARM: OMAP3: Add back Kconfig option MACH_OMAP3517EVM for ASoC
We still have SND_OMAP_SOC_AM3517EVM depending on MACH_OMAP3517EVM,
so let's keep MACH_OMAP3517EVM Kconfig option around for a little
bit longer.
This removes the dependency between ARM SoC changes and the ASoC
changes, and allows the following three options for the driver:
1. Update the driver for device tree based booting
2. Initialize the driver with legacy platform data, then update
the driver for device tree based booting
3. Just remove the driver if there are no audio users for
3517-evm board
Reported-by: Paul Bolle
Signed-off-by: Tony Lindgren
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -213,6 +213,11 @@ config MACH_OVERO
default y
select OMAP_PACKAGE_CBB
+config MACH_OMAP3517EVM
+ bool "OMAP3517/ AM3517 EVM board"
+ depends on ARCH_OMAP3
+ default y
+
config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM: OMAP3: MACH_OMAP3517EVM?
* Paul Bolle [150120 01:06]:
> Tony,
>
> Your commit 4d62dbda8561 ("ARM: OMAP3: Remove legacy support for
> am3517-evm") is included in today's linux-next (ie, next-20150120). I
> noticed because a script I use to check linux-next spotted a problem
> caused by it.
OK thanks for spotting that.
> See, your commit removes the Kconfig symbol MACH_OMAP3517EVM. But
> there's still a reference to that symbol in sound/soc/omap/Kconfig. This
> means that in linux-next a symbol, SND_OMAP_SOC_AM3517EVM, cannot be set
> anymore.
>
> I assume a patch that address this (either by removing
> SND_OMAP_SOC_AM3517EVM or by updating its dependencies) is queued
> somewhere. Is that correct?
Not yet, I missed that part sorry. I'll add back the Kconfig symbol.
I'll rather do the removal in smaller steps, and first remove the
3517 related board-*.c file before messing with the legacy drivers.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.19-rc2 v15 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S
* Daniel Thompson [150120 01:03]: > On 19/01/15 21:38, Tony Lindgren wrote: > > * Daniel Thompson [150105 04:49]: > >> The omap1's debug-macro.S is similar to the generic 8250 code. Compared to > >> the 8520 code the omap1 macro automatically determines what UART to use > >> based on breadcrumbs left by the bootloader and automatically copes with > >> the eccentric register layout on OMAP7XX. > >> > >> This patch drops both these features and relies instead on the generic > >> 8250 macros: > >> > >> 1. Dropping support for the bootloader breadcrumbs is identical to the > >>way the migration was handled for OMAP2 (see 808b7e07464d...). > >> > >> 2. Support for OMAP7XX still exists but it must be configured by hand > >>(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. > >> > >> Signed-off-by: Daniel Thompson > >> Cc: Russell King > >> Cc: Arnd Bergmann > >> Cc: linux-omap@vger.kernel.org > >> Tested-by: Aaro Koskinen > >> Acked-by: Tony Lindgren > > > > Daniel, I suggest you upload this patch into Russell's patch tracking > > system to get it merged. That at least shrinks down your patch series > > if the other patches need more work. > > This has been in the patch tracker for a week or so: > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8271/1 OK good to hear thanks. > I'm very aware that this patch (and indeed the whole patch set) has been > knocking round for longer than it should have. The changelog for this > patchset is certainly not one to be especially proud off ;-) . Yeah, it's been floating around for a while :) Here it may have been doable to first add the Kconfig entries, then flip them on and remove the related .S file in a follow up patch. Not sure if that would have helped to remove the dependencies for the rest of the series though. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Tue, 20 Jan 2015, R, Vignesh wrote:
> On 1/20/2015 5:23 PM, Lee Jones wrote:
> > On Wed, 07 Jan 2015, Vignesh R wrote:
> >
> >> In one shot mode, sequencer automatically disables all enabled steps at
> >> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> >> need not be saved in reg_se_cache for clearing these steps at a later
> >> stage.
> >> Also, when ADC wakes up Sequencer should not be busy executing any of the
> >> config steps except for the charge step. Previously charge step was 1 ADC
> >> clock cycle and hence it was ignored.
> >> TSC steps are always disabled at the end of each conversion cycle, hence
> >> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
> >>
> >> Signed-off-by: Vignesh R
> >> ---
> >>
> >> v5:
> >> - Remove unnecessary clearing of REG_SE
> >>
> >> drivers/mfd/ti_am335x_tscadc.c | 13 +
> >> include/linux/mfd/ti_am335x_tscadc.h | 1 +
> >> 2 files changed, 6 insertions(+), 8 deletions(-)
> >
> > Looks fine.
> >
> > For my own reference:
> > Acked-by: Lee Jones
> >
> > Can this patch be applied on its own?
> >
>
> I prefer to wait until input patches are picked up.
I have no problem with that, but is there a technical reason why?
> >> diff --git a/drivers/mfd/ti_am335x_tscadc.c
> >> b/drivers/mfd/ti_am335x_tscadc.c
> >> index 467c80e1c4ae..e4e4b22eebc9 100644
> >> --- a/drivers/mfd/ti_am335x_tscadc.c
> >> +++ b/drivers/mfd/ti_am335x_tscadc.c
> >> @@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> >> *tsadc)
> >>DEFINE_WAIT(wait);
> >>u32 reg;
> >>
> >> - /*
> >> - * disable TSC steps so it does not run while the ADC is using it. If
> >> - * write 0 while it is running (it just started or was already running)
> >> - * then it completes all steps that were enabled and stops then.
> >> - */
> >> - tscadc_writel(tsadc, REG_SE, 0);
> >>reg = tscadc_readl(tsadc, REG_ADCFSM);
> >>if (reg & SEQ_STATUS) {
> >>tsadc->adc_waiting = true;
> >> @@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> >> *tsadc)
> >>spin_lock_irq(&tsadc->reg_lock);
> >>finish_wait(&tsadc->reg_se_wait, &wait);
> >>
> >> + /*
> >> + * Sequencer should either be idle or
> >> + * busy applying the charge step.
> >> + */
> >>reg = tscadc_readl(tsadc, REG_ADCFSM);
> >> - WARN_ON(reg & SEQ_STATUS);
> >> + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
> >>tsadc->adc_waiting = false;
> >>}
> >>tsadc->adc_in_use = true;
> >> @@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> >> *tsadc)
> >> void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
> >> {
> >>spin_lock_irq(&tsadc->reg_lock);
> >> - tsadc->reg_se_cache |= val;
> >>am335x_tscadc_need_adc(tsadc);
> >>
> >>tscadc_writel(tsadc, REG_SE, val);
> >> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> >> b/include/linux/mfd/ti_am335x_tscadc.h
> >> index 3f4e994ace2b..1fd50dcfe47c 100644
> >> --- a/include/linux/mfd/ti_am335x_tscadc.h
> >> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> >> @@ -128,6 +128,7 @@
> >>
> >> /* Sequencer Status */
> >> #define SEQ_STATUS BIT(5)
> >> +#define CHARGE_STEP 0x11
> >>
> >> #define ADC_CLK 300
> >> #define TOTAL_STEPS 16
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: hwmod fixes for v3.19-rc
* Paul Walmsley [150119 22:51]: > Hi Tony > > On Mon, 19 Jan 2015, Tony Lindgren wrote: > > > * Paul Walmsley [150104 15:38]: > > > The following changes since commit > > > 97bf6af1f928216fd6c5a66e8a57bfa95a659672: > > > > > > Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git > > > tags/for-v3.19-rc/omap-fixes-a > > > > > > for you to fetch changes up to 99d076b747455449b2eec9e37f3fb0bfdf51af32: > > > > > > MAINTAINERS: add maintainer for OMAP hwmod data (2015-01-02 16:24:27 > > > -0700) > > > > > > > > > For v3.19-rc, fix some hwmod structure details for the OMAP DSS modules > > > for DRA7xx and AM43xx. Also update the MAINTAINERS file to encourage > > > folks to cc me on hwmod data patches. > > > > > > Basic build, boot, and PM testlogs are available here: > > > > > > http://www.pwsan.com/omap/testlogs/omap-fixes-a-for-v3.19-rc/20150103144242/ > > > > Paul, got any updates on this? Anyways, I'll just untag this email as > > you asked me to wait on pulling this. > > At this point I think I will just requeue the remaining two valid patches > for v3.20. Thanks for the ping OK makes sense for me if they are not critical fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [next-20150119]regression (mm)?
On Tue, Jan 20, 2015 at 12:50:59PM -0200, Fabio Estevam wrote: > On Tue, Jan 20, 2015 at 12:05 PM, Kirill A. Shutemov > wrote: > > Russell King - ARM Linux wrote: > >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: > >> > Better option would be converting 2-lvl ARM configuration to > >> > , but I'm not sure if it's possible. > >> > >> Well, IMHO the folded approach in asm-generic was done the wrong way > >> which barred ARM from ever using it. > > > > Okay, I see. > > > > Regarding the topic bug. Completely untested patch is below. Could anybody > > check if it helps? > > Yes, it helps. Now I can boot mx6 running linux-next 20150120 with > your patch applied. worked fine here too with AM437x SK, AM437x IDK and BeagleBoneBlack. thanks -- balbi signature.asc Description: Digital signature
Re: [RFC/PATCH] arm: omap: hwmod: add debugfs interface
On Tue, Jan 20, 2015 at 08:36:03AM -0600, Felipe Balbi wrote: > Hi, > > On Tue, Jan 20, 2015 at 08:13:57AM +, Paul Walmsley wrote: > > On Tue, 20 Jan 2015, Paul Walmsley wrote: > > > > > On Fri, 5 Dec 2014, Felipe Balbi wrote: > > > > > > > By exposing the details of hwmod structures > > > > to debugfs we can much more easily verify > > > > that changes to hwmod data is correct and won't > > > > cause regressions. > > > > > > > > The idea is that this can be used to check the > > > > state of one hwmod, verify hwmod sysc fields, etc. > > > > > > > > For example, this will be used to move some of > > > > the sysc fields to DT and later verify that they > > > > are correct pre- and post-patch. > > > > > > > > Signed-off-by: Felipe Balbi > > > > > > This one had a bunch of unnecessary includes and checkpatch issues > > > (below). I cleaned those up here and have queued the result (also below) > > > for v3.20. > > > > ... and, the patch doesn't even boot. Dropped. > > > > If you really want something like this to be merged, resend a version that > > boots, and has checkpatch warnings fixed and unnecessary includes dropped. > > Otherwise you're just wasting my time. > > you're using a really old version, though. There have been other > versions which are still under discussion. not to mention that this was an RFC, not meant for merging at the time it was sent. -- balbi signature.asc Description: Digital signature
Re: [next-20150119]regression (mm)?
On Tue, Jan 20, 2015 at 12:05 PM, Kirill A. Shutemov wrote: > Russell King - ARM Linux wrote: >> On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: >> > Better option would be converting 2-lvl ARM configuration to >> > , but I'm not sure if it's possible. >> >> Well, IMHO the folded approach in asm-generic was done the wrong way >> which barred ARM from ever using it. > > Okay, I see. > > Regarding the topic bug. Completely untested patch is below. Could anybody > check if it helps? Yes, it helps. Now I can boot mx6 running linux-next 20150120 with your patch applied. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap: hwmod: add debugfs interface
Hi, On Tue, Jan 20, 2015 at 08:13:57AM +, Paul Walmsley wrote: > On Tue, 20 Jan 2015, Paul Walmsley wrote: > > > On Fri, 5 Dec 2014, Felipe Balbi wrote: > > > > > By exposing the details of hwmod structures > > > to debugfs we can much more easily verify > > > that changes to hwmod data is correct and won't > > > cause regressions. > > > > > > The idea is that this can be used to check the > > > state of one hwmod, verify hwmod sysc fields, etc. > > > > > > For example, this will be used to move some of > > > the sysc fields to DT and later verify that they > > > are correct pre- and post-patch. > > > > > > Signed-off-by: Felipe Balbi > > > > This one had a bunch of unnecessary includes and checkpatch issues > > (below). I cleaned those up here and have queued the result (also below) > > for v3.20. > > ... and, the patch doesn't even boot. Dropped. > > If you really want something like this to be merged, resend a version that > boots, and has checkpatch warnings fixed and unnecessary includes dropped. > Otherwise you're just wasting my time. you're using a really old version, though. There have been other versions which are still under discussion. -- balbi signature.asc Description: Digital signature
Re: [next-20150119]regression (mm)?
Russell King - ARM Linux wrote: > On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: > > Better option would be converting 2-lvl ARM configuration to > > , but I'm not sure if it's possible. > > Well, IMHO the folded approach in asm-generic was done the wrong way > which barred ARM from ever using it. Okay, I see. Regarding the topic bug. Completely untested patch is below. Could anybody check if it helps? >From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Tue, 20 Jan 2015 15:47:22 +0200 Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE ARM uses custom implementation of PMD folding in 2-level page table case. Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is folded, but ARM doesn't do this. Let's fix it. Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). It also fixes problems with recently-introduced pmd accounting on ARM without LPAE. Signed-off-by: Kirill A. Shutemov Reported-by: Nishanth Menon --- arch/arm/include/asm/pgtable-2level.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index bcc5e300413f..bfd662e49a25 100644 --- a/arch/arm/include/asm/pgtable-2level.h +++ b/arch/arm/include/asm/pgtable-2level.h @@ -10,6 +10,8 @@ #ifndef _ASM_PGTABLE_2LEVEL_H #define _ASM_PGTABLE_2LEVEL_H +#define __PAGETABLE_PMD_FOLDED + /* * Hardware-wise, we have a two level page table structure, where the first * level has 4096 entries, and the second level has 256 entries. Each entry -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] mfd: menelaus: make vcore and regulator controls internal
On Tue, 20 Jan 2015, Lee Jones wrote: > On Sat, 27 Dec 2014, Aaro Koskinen wrote: > > > Make vcore and regulator control functions internal to the driver. > > > > Signed-off-by: Aaro Koskinen > > --- > > drivers/mfd/menelaus.c | 13 +++-- > > include/linux/mfd/menelaus.h | 12 > > 2 files changed, 11 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c > > index 4a900cc..8660adf 100644 > > --- a/drivers/mfd/menelaus.c > > +++ b/drivers/mfd/menelaus.c > > @@ -163,6 +163,15 @@ > > #define MCT_PIN_ST_S1_CD_ST(1 << 0) > > #define MCT_PIN_ST_S2_CD_ST(1 << 1) > > > > +#define EN_VPLL_SLEEP (1 << 7) > > +#define EN_VMMC_SLEEP (1 << 6) > > +#define EN_VAUX_SLEEP (1 << 5) > > +#define EN_VIO_SLEEP (1 << 4) > > +#define EN_VMEM_SLEEP (1 << 3) > > +#define EN_DC3_SLEEP (1 << 2) > > +#define EN_DC2_SLEEP (1 << 1) > > +#define EN_VC_SLEEP(1 << 0) > > Better to use the BIT() macro for this kind of stuff. > > Please take this opportunity to use it. In fact, nevermind. I'll do it from here. Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] mfd: menelaus: use macro for magic number
On Sat, 27 Dec 2014, Aaro Koskinen wrote: > Use macro to check a register bit. > > Signed-off-by: Aaro Koskinen > --- > drivers/mfd/menelaus.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c > index 8660adf..05bae40 100644 > --- a/drivers/mfd/menelaus.c > +++ b/drivers/mfd/menelaus.c > @@ -1242,7 +1242,7 @@ static int menelaus_probe(struct i2c_client *client, > err = menelaus_read_reg(MENELAUS_VCORE_CTRL1); > if (err < 0) > goto fail; > - if (err & BIT(7)) > + if (err & VCORE_CTRL1_HW_NSW) > menelaus->vcore_hw_mode = 1; > else > menelaus->vcore_hw_mode = 0; -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] mfd: menelaus: make vcore and regulator controls internal
On Sat, 27 Dec 2014, Aaro Koskinen wrote: > Make vcore and regulator control functions internal to the driver. > > Signed-off-by: Aaro Koskinen > --- > drivers/mfd/menelaus.c | 13 +++-- > include/linux/mfd/menelaus.h | 12 > 2 files changed, 11 insertions(+), 14 deletions(-) > > diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c > index 4a900cc..8660adf 100644 > --- a/drivers/mfd/menelaus.c > +++ b/drivers/mfd/menelaus.c > @@ -163,6 +163,15 @@ > #define MCT_PIN_ST_S1_CD_ST (1 << 0) > #define MCT_PIN_ST_S2_CD_ST (1 << 1) > > +#define EN_VPLL_SLEEP(1 << 7) > +#define EN_VMMC_SLEEP(1 << 6) > +#define EN_VAUX_SLEEP(1 << 5) > +#define EN_VIO_SLEEP (1 << 4) > +#define EN_VMEM_SLEEP(1 << 3) > +#define EN_DC3_SLEEP (1 << 2) > +#define EN_DC2_SLEEP (1 << 1) > +#define EN_VC_SLEEP (1 << 0) Better to use the BIT() macro for this kind of stuff. Please take this opportunity to use it. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] mfd: menelaus: delete platform data support
On Sat, 27 Dec 2014, Aaro Koskinen wrote:
> Delete platform data support.
>
> Signed-off-by: Aaro Koskinen
> ---
> arch/arm/mach-omap2/common-board-devices.h | 2 --
> drivers/mfd/menelaus.c | 10 +-
> include/linux/mfd/menelaus.h | 6 --
> 3 files changed, 1 insertion(+), 17 deletions(-)
Applied, thanks.
> diff --git a/arch/arm/mach-omap2/common-board-devices.h
> b/arch/arm/mach-omap2/common-board-devices.h
> index 07c88ae..7a30228 100644
> --- a/arch/arm/mach-omap2/common-board-devices.h
> +++ b/arch/arm/mach-omap2/common-board-devices.h
> @@ -2,7 +2,6 @@
> #define __OMAP_COMMON_BOARD_DEVICES__
>
> #include
> -#include
> #include "twl-common.h"
>
> #define NAND_BLOCK_SIZE SZ_128K
> @@ -14,7 +13,6 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int
> gpio_debounce,
> struct ads7846_platform_data *board_pdata);
> void *n8x0_legacy_init(void);
>
> -extern struct menelaus_platform_data n8x0_menelaus_platform_data;
> extern struct aic3x_pdata n810_aic33_data;
>
> #endif /* __OMAP_COMMON_BOARD_DEVICES__ */
> diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
> index 3e04c64..4a900cc 100644
> --- a/drivers/mfd/menelaus.c
> +++ b/drivers/mfd/menelaus.c
> @@ -1181,8 +1181,6 @@ static int menelaus_probe(struct i2c_client *client,
> int rev = 0;
> int err = 0;
> struct device_node *np = client->dev.of_node;
> - struct menelaus_platform_data *menelaus_pdata =
> - dev_get_platdata(&client->dev);
>
> if (the_menelaus) {
> dev_dbg(&client->dev, "only one %s for now\n",
> @@ -1240,13 +1238,7 @@ static int menelaus_probe(struct i2c_client *client,
> else
> menelaus->vcore_hw_mode = 0;
>
> - if (menelaus_pdata != NULL) {
> - if (menelaus_pdata->late_init != NULL) {
> - err = menelaus_pdata->late_init(&client->dev);
> - if (err < 0)
> - goto fail;
> - }
> - } else if (np) {
> + if (np) {
> u32 vcore_min;
> u32 vcore_max;
>
> diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
> index 9e85ac0..21eeff5 100644
> --- a/include/linux/mfd/menelaus.h
> +++ b/include/linux/mfd/menelaus.h
> @@ -5,12 +5,6 @@
> #ifndef __ASM_ARCH_MENELAUS_H
> #define __ASM_ARCH_MENELAUS_H
>
> -struct device;
> -
> -struct menelaus_platform_data {
> - int (* late_init)(struct device *dev);
> -};
> -
> extern int menelaus_register_mmc_callback(void (*callback)(void *data, u8
> card_mask),
> void *data);
> extern void menelaus_unregister_mmc_callback(void);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] mfd: menelaus: drop support for SW controller VCORE
On Sat, 27 Dec 2014, Aaro Koskinen wrote:
> Drop support for SW controlled VCORE, nobody uses it.
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/mfd/menelaus.c | 23 ---
> include/linux/mfd/menelaus.h | 1 -
> 2 files changed, 24 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
> index 9f01aef..917fa86 100644
> --- a/drivers/mfd/menelaus.c
> +++ b/drivers/mfd/menelaus.c
> @@ -532,29 +532,6 @@ static const struct menelaus_vtg_value vcore_values[] = {
> { 1450, 18 },
> };
>
> -int menelaus_set_vcore_sw(unsigned int mV)
> -{
> - int val, ret;
> - struct i2c_client *c = the_menelaus->client;
> -
> - val = menelaus_get_vtg_value(mV, vcore_values,
> - ARRAY_SIZE(vcore_values));
> - if (val < 0)
> - return -EINVAL;
> -
> - dev_dbg(&c->dev, "Setting VCORE to %d mV (val 0x%02x)\n", mV, val);
> -
> - /* Set SW mode and the voltage in one go. */
> - mutex_lock(&the_menelaus->lock);
> - ret = menelaus_write_reg(MENELAUS_VCORE_CTRL1, val);
> - if (ret == 0)
> - the_menelaus->vcore_hw_mode = 0;
> - mutex_unlock(&the_menelaus->lock);
> - msleep(1);
> -
> - return ret;
> -}
> -
> int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int floor_mV)
> {
> int fval, rval, val, ret;
> diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h
> index a1e12bf3..9e85ac0 100644
> --- a/include/linux/mfd/menelaus.h
> +++ b/include/linux/mfd/menelaus.h
> @@ -24,7 +24,6 @@ extern int menelaus_set_vaux(unsigned int mV);
> extern int menelaus_set_vdcdc(int dcdc, unsigned int mV);
> extern int menelaus_set_slot_sel(int enable);
> extern int menelaus_get_slot_pin_states(void);
> -extern int menelaus_set_vcore_sw(unsigned int mV);
> extern int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned int
> floor_mV);
>
> #define EN_VPLL_SLEEP(1 << 7)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] mfd: menelaus: delete omap_has_menelaus
On Sat, 27 Dec 2014, Aaro Koskinen wrote: > Delete unused macro. > > Signed-off-by: Aaro Koskinen > --- > include/linux/mfd/menelaus.h | 6 -- > 1 file changed, 6 deletions(-) Applied, thanks. > diff --git a/include/linux/mfd/menelaus.h b/include/linux/mfd/menelaus.h > index f097e89..a1e12bf3 100644 > --- a/include/linux/mfd/menelaus.h > +++ b/include/linux/mfd/menelaus.h > @@ -38,10 +38,4 @@ extern int menelaus_set_vcore_hw(unsigned int roof_mV, > unsigned int floor_mV); > > extern int menelaus_set_regulator_sleep(int enable, u32 val); > > -#if defined(CONFIG_ARCH_OMAP2) && defined(CONFIG_MENELAUS) > -#define omap_has_menelaus() 1 > -#else > -#define omap_has_menelaus() 0 > -#endif > - > #endif -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 3/3] clk: Add rate constraints to clocks
Adds a way for clock consumers to set maximum and minimum rates. This
can be used for thermal drivers to set minimum rates, or by misc.
drivers to set maximum rates to assure a minimum performance level.
Changes the signature of the determine_rate callback by adding the
parameters min_rate and max_rate.
Signed-off-by: Tomeu Vizoso
---
v10:* Refactor __clk_determine_rate to share code with
clk_round_rate.
* Remove clk_core_round_rate_nolock as it's unused now
v9: * s/floor/min and s/ceiling/max
* Add a bunch of NULL checks
* Propagate our rate range when querying our parent for the rate
* Take constraints into account in clk_round_rate
* Add __clk_determine_rate() for clk providers to ask their
parents for a rate within their range
* Make sure that what ops->round_rate returns when changing
rates is within the range
v7: * Update a few more instances in new code
v6: * Take the prepare lock before removing a per-user clk
* Init per-user clks list before adding the first clk
* Pass the constraints to determine_rate and let clk
implementations deal with constraints
* Add clk_set_rate_range
v5: * Initialize clk.ceiling_constraint to ULONG_MAX
* Warn about inconsistent constraints
v4: * Copy function docs from header
* Move WARN out of critical section
* Refresh rate after removing a per-user clk
* Rename clk_core.per_user_clks to clk_core.clks
* Store requested rate and re-apply it when constraints are updated
---
Documentation/clk.txt | 2 +
arch/arm/mach-omap2/dpll3xxx.c | 2 +
arch/arm/mach-omap2/dpll44xx.c | 2 +
arch/mips/alchemy/common/clock.c| 8 ++
drivers/clk/at91/clk-programmable.c | 2 +
drivers/clk/bcm/clk-kona.c | 2 +
drivers/clk/clk-composite.c | 9 +-
drivers/clk/clk.c | 237 ++--
drivers/clk/hisilicon/clk-hi3620.c | 2 +
drivers/clk/mmp/clk-mix.c | 2 +
drivers/clk/qcom/clk-pll.c | 1 +
drivers/clk/qcom/clk-rcg.c | 10 +-
drivers/clk/qcom/clk-rcg2.c | 6 +
drivers/clk/sunxi/clk-factors.c | 2 +
drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +
include/linux/clk-private.h | 6 +
include/linux/clk-provider.h| 15 ++-
include/linux/clk.h | 28 +
include/linux/clk/ti.h | 4 +
19 files changed, 297 insertions(+), 45 deletions(-)
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 4ff8462..0e4f90a 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -73,6 +73,8 @@ the operations defined in clk.h:
unsigned long *parent_rate);
long(*determine_rate)(struct clk_hw *hw,
unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw
**best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index c2da2a0..ac3fb11 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -473,6 +473,8 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
* in failure.
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk)
{
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 0e58e5a..acacb90 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -222,6 +222,8 @@ out:
* in failure.
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk)
{
diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c
index 48a9dfc..4e65404 100644
--- a/arch/mips/alchemy/common/clock.c
+++ b/arch/mips/alchemy/common/clock.c
@@ -373,6 +373,8 @@ static long alchemy_calc_div(unsigned long rate, unsigned
long prate,
}
static long alchemy_clk_fgcs_detr(struct clk_hw *hw, unsigned long rate,
+ unsigned long min_rate,
+
[PATCH v10 2/3] clk: Make clk API return per-user struct clk instances
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Signed-off-by: Tomeu Vizoso
---
v10:* Add more missing NULL checks
* Remove __clk_reparent as it's now unused
* Remove clk_core_round_rate as it's now unused
* Call nolock variants from __clk_mux_determine_rate
v9: * Add missing NULL checks
* Remove __clk_prepare and __clk_unprepare as they are unused
now
v7: * Add stub for __of_clk_get_by_name to fix builds without OF
v6: * Guard against NULL pointer
v4: * Remove unused function __clk_core_to_clk
* Use "core" more often as the name for struct clk_core* variables
* Make sure we don't lose information about the caller in of_clk_get_*
v3: * Rebase on top of linux-next 20141009
v2: * Remove exported functions that aren't really used outside clk.c
* Rename new internal functions to clk_core_ prefix
* Remove redundant checks for error pointers in *_get_parent
* Change __clk_create_clk to take a struct clk_hw instead
* Match the original error behavior in clk_get_sys
---
arch/arm/mach-omap2/cclock3xxx_data.c | 108 --
arch/arm/mach-omap2/clock.h | 11 +-
arch/arm/mach-omap2/clock_common_data.c | 5 +-
drivers/clk/clk.c | 628
drivers/clk/clk.h | 5 +
drivers/clk/clkdev.c| 80 +++-
include/linux/clk-private.h | 35 +-
include/linux/clk-provider.h| 12 +-
8 files changed, 583 insertions(+), 301 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 644ff32..4305105 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -82,7 +82,7 @@ DEFINE_CLK_MUX(osc_sys_ck, osc_sys_ck_parent_names, NULL, 0x0,
OMAP3430_PRM_CLKSEL, OMAP3430_SYS_CLKIN_SEL_SHIFT,
OMAP3430_SYS_CLKIN_SEL_WIDTH, 0x0, NULL);
-DEFINE_CLK_DIVIDER(sys_ck, "osc_sys_ck", &osc_sys_ck, 0x0,
+DEFINE_CLK_DIVIDER(sys_ck, "osc_sys_ck", &osc_sys_ck_core, 0x0,
OMAP3430_PRM_CLKSRC_CTRL, OMAP_SYSCLKDIV_SHIFT,
OMAP_SYSCLKDIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
@@ -132,7 +132,7 @@ static struct clk_hw_omap dpll3_ck_hw = {
DEFINE_STRUCT_CLK(dpll3_ck, dpll3_ck_parent_names, dpll3_ck_ops);
-DEFINE_CLK_DIVIDER(dpll3_m2_ck, "dpll3_ck", &dpll3_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll3_m2_ck, "dpll3_ck", &dpll3_ck_core, 0x0,
OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
OMAP3430_CORE_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_CORE_DPLL_CLKOUT_DIV_WIDTH,
@@ -149,12 +149,12 @@ static const struct clk_ops core_ck_ops = {};
DEFINE_STRUCT_CLK_HW_OMAP(core_ck, NULL);
DEFINE_STRUCT_CLK(core_ck, core_ck_parent_names, core_ck_ops);
-DEFINE_CLK_DIVIDER(l3_ick, "core_ck", &core_ck, 0x0,
+DEFINE_CLK_DIVIDER(l3_ick, "core_ck", &core_ck_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L3_SHIFT, OMAP3430_CLKSEL_L3_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
-DEFINE_CLK_DIVIDER(l4_ick, "l3_ick", &l3_ick, 0x0,
+DEFINE_CLK_DIVIDER(l4_ick, "l3_ick", &l3_ick_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L4_SHIFT, OMAP3430_CLKSEL_L4_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
@@ -275,9 +275,9 @@ static struct clk_hw_omap dpll1_ck_hw = {
DEFINE_STRUCT_CLK(dpll1_ck, dpll3_ck_parent_names, dpll1_ck_ops);
-DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, "dpll1_ck", &dpll1_ck, 0x0, 2, 1);
+DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, "dpll1_ck", &dpll1_ck_core, 0x0, 2, 1);
-DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, "dpll1_x2_ck", &dpll1_x2_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, "dpll1_x2_ck", &dpll1_x2_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKSEL2_PLL),
OMAP3430_MPU_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_MPU_DPLL_CLKOUT_DIV_WIDTH,
@@ -292,7 +292,7 @@ static const char *mpu_ck_parent_names[] = {
DEFINE_STRUCT_CLK_HW_OMAP(mpu_ck, "mpu_clkdm");
DEFINE_STRUCT_CLK(mpu_ck, mpu_ck_parent_names, core_l4_ick_ops);
-DEFINE_CLK_DIVIDER(arm_fck, "mpu_ck", &mpu_ck, 0x0,
+DEFINE_CLK_DIVIDER(arm_fck, "mpu_ck", &mpu_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_IDLEST_PLL),
OMAP3430_ST_MPU_CLK_SHIFT, O
Re: [PATCH v9 3/3] clk: Add floor and ceiling constraints to clock rates
On 20 January 2015 at 01:00, Stephen Boyd wrote:
> On 01/19, Tomeu Vizoso wrote:
>> Adds a way for clock consumers to set maximum and minimum rates. This can be
>> used for thermal drivers to set ceiling rates, or by misc. drivers to set
>> floor rates to assure a minimum performance level.
>>
>> Changes the signature of the determine_rate callback by adding the
>> parameters floor_rate and ceiling_rate.
>
> Commit text needs the s/floor/min and s/ceiling/max treatment
> too.
>
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index f2a1ff3..55b3124 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1026,6 +1051,28 @@ static unsigned long
>> clk_core_round_rate_nolock(struct clk_core *clk,
>> else
>> return clk->rate;
>> }
>> +unsigned long __clk_determine_rate(struct clk_hw *hw,
>> +unsigned long rate,
>> +unsigned long min_rate,
>> +unsigned long max_rate)
>> +{
>> + unsigned long parent_rate = 0;
>> + struct clk_core *core = hw->core;
>> + struct clk_hw *parent_hw;
>> +
>> + if (!core->ops->determine_rate)
>> + return 0;
>> +
>> + if (core->parent) {
>> + parent_rate = core->parent->rate;
>> + parent_hw = core->parent->hw;
>> + }
>> +
>> + return core->ops->determine_rate(core->hw, rate,
>> + min_rate, max_rate,
>> + &parent_rate, &parent_hw);
>> +}
>> +EXPORT_SYMBOL_GPL(__clk_determine_rate);
>
> Maybe I misled you with the API name. I was thinking more along
> the lines of clk_round_rate() and this new function ending up
> calling clk_core_round_rate(), but clk_round_rate() would call it
> with whatever range the clock is constrained to while this new
> function would allow driver authors to specify the range. It
> should be easy enough to add min/max to clk_core_round_rate()
> given that it's a private API in this file.
Yeah, I wasn't sure whether it made sense for __clk_determine_rate to
have the fallbacks because any caller would need to have checked that
the clock implementation supports determine_rate and is aware of the
rate constraints.
As long as people don't get confused, I'm fine with any of the possibilities.
Regards,
Tomeu
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On 1/20/2015 5:23 PM, Lee Jones wrote:
> On Wed, 07 Jan 2015, Vignesh R wrote:
>
>> In one shot mode, sequencer automatically disables all enabled steps at
>> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
>> need not be saved in reg_se_cache for clearing these steps at a later
>> stage.
>> Also, when ADC wakes up Sequencer should not be busy executing any of the
>> config steps except for the charge step. Previously charge step was 1 ADC
>> clock cycle and hence it was ignored.
>> TSC steps are always disabled at the end of each conversion cycle, hence
>> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
>>
>> Signed-off-by: Vignesh R
>> ---
>>
>> v5:
>> - Remove unnecessary clearing of REG_SE
>>
>> drivers/mfd/ti_am335x_tscadc.c | 13 +
>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> Looks fine.
>
> For my own reference:
> Acked-by: Lee Jones
>
> Can this patch be applied on its own?
>
I prefer to wait until input patches are picked up.
>> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
>> index 467c80e1c4ae..e4e4b22eebc9 100644
>> --- a/drivers/mfd/ti_am335x_tscadc.c
>> +++ b/drivers/mfd/ti_am335x_tscadc.c
>> @@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
>> *tsadc)
>> DEFINE_WAIT(wait);
>> u32 reg;
>>
>> -/*
>> - * disable TSC steps so it does not run while the ADC is using it. If
>> - * write 0 while it is running (it just started or was already running)
>> - * then it completes all steps that were enabled and stops then.
>> - */
>> -tscadc_writel(tsadc, REG_SE, 0);
>> reg = tscadc_readl(tsadc, REG_ADCFSM);
>> if (reg & SEQ_STATUS) {
>> tsadc->adc_waiting = true;
>> @@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
>> *tsadc)
>> spin_lock_irq(&tsadc->reg_lock);
>> finish_wait(&tsadc->reg_se_wait, &wait);
>>
>> +/*
>> + * Sequencer should either be idle or
>> + * busy applying the charge step.
>> + */
>> reg = tscadc_readl(tsadc, REG_ADCFSM);
>> -WARN_ON(reg & SEQ_STATUS);
>> +WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
>> tsadc->adc_waiting = false;
>> }
>> tsadc->adc_in_use = true;
>> @@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
>> *tsadc)
>> void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
>> {
>> spin_lock_irq(&tsadc->reg_lock);
>> -tsadc->reg_se_cache |= val;
>> am335x_tscadc_need_adc(tsadc);
>>
>> tscadc_writel(tsadc, REG_SE, val);
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
>> b/include/linux/mfd/ti_am335x_tscadc.h
>> index 3f4e994ace2b..1fd50dcfe47c 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -128,6 +128,7 @@
>>
>> /* Sequencer Status */
>> #define SEQ_STATUS BIT(5)
>> +#define CHARGE_STEP 0x11
>>
>> #define ADC_CLK 300
>> #define TOTAL_STEPS 16
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/14] mfd: twl-core: Constify struct regmap_config and reg_default array
On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
> The regmap_config struct may be const because it is not modified by the
> driver and regmap_init() accepts pointer to const. Make array of
> struct reg_default const as well.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> ---
> drivers/mfd/twl-core.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Applied with Tony's Ack, thanks.
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index db11b4f40611..489674a2497e 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -207,7 +207,7 @@ static struct twl_mapping twl4030_map[] = {
> { 2, TWL5031_BASEADD_INTERRUPTS },
> };
>
> -static struct reg_default twl4030_49_defaults[] = {
> +static const struct reg_default twl4030_49_defaults[] = {
> /* Audio Registers */
> { 0x01, 0x00}, /* CODEC_MODE*/
> { 0x02, 0x00}, /* OPTION*/
> @@ -306,7 +306,7 @@ static const struct regmap_access_table
> twl4030_49_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(twl4030_49_volatile_ranges),
> };
>
> -static struct regmap_config twl4030_regmap_config[4] = {
> +static const struct regmap_config twl4030_regmap_config[4] = {
> {
> /* Address 0x48 */
> .reg_bits = 8,
> @@ -369,7 +369,7 @@ static struct twl_mapping twl6030_map[] = {
> { 1, TWL6030_BASEADD_GASGAUGE },
> };
>
> -static struct regmap_config twl6030_regmap_config[3] = {
> +static const struct regmap_config twl6030_regmap_config[3] = {
> {
> /* Address 0x48 */
> .reg_bits = 8,
> @@ -1087,7 +1087,7 @@ twl_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> struct twl4030_platform_data*pdata = dev_get_platdata(&client->dev);
> struct device_node *node = client->dev.of_node;
> struct platform_device *pdev;
> - struct regmap_config*twl_regmap_config;
> + const struct regmap_config *twl_regmap_config;
> int irq_base = 0;
> int status;
> unsignedi, num_slaves;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/14] mfd: twl6040: Constify struct regmap_config and reg_default array
On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
> The regmap_config struct may be const because it is not modified by the
> driver and regmap_init() accepts pointer to const. Make array of
> struct reg_default const as well.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> ---
> drivers/mfd/twl6040.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied with Tony's Ack, thanks.
> diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
> index 9687645162ae..f71ee3dbc2a2 100644
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -44,7 +44,7 @@
> #define VIBRACTRL_MEMBER(reg) ((reg == TWL6040_REG_VIBCTLL) ? 0 : 1)
> #define TWL6040_NUM_SUPPLIES (2)
>
> -static struct reg_default twl6040_defaults[] = {
> +static const struct reg_default twl6040_defaults[] = {
> { 0x01, 0x4B }, /* REG_ASICID (ro) */
> { 0x02, 0x00 }, /* REG_ASICREV (ro) */
> { 0x03, 0x00 }, /* REG_INTID*/
> @@ -580,7 +580,7 @@ static bool twl6040_writeable_reg(struct device *dev,
> unsigned int reg)
> }
> }
>
> -static struct regmap_config twl6040_regmap_config = {
> +static const struct regmap_config twl6040_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] mfd: tps65218: Constify struct regmap_config
On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
> The regmap_config struct may be const because it is not modified by the
> driver and regmap_init() accepts pointer to const.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> ---
> drivers/mfd/tps65218.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied with Tony's Ack, thanks.
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 0d256cb002eb..b019b3198afe 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -125,7 +125,7 @@ int tps65218_clear_bits(struct tps65218 *tps, unsigned
> int reg,
> }
> EXPORT_SYMBOL_GPL(tps65218_clear_bits);
>
> -static struct regmap_config tps65218_regmap_config = {
> +static const struct regmap_config tps65218_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> .cache_type = REGCACHE_RBTREE,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] mfd: tps65217: Constify struct regmap_config
On Mon, 05 Jan 2015, Krzysztof Kozlowski wrote:
> The regmap_config struct may be const because it is not modified by the
> driver and regmap_init() accepts pointer to const.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> ---
> drivers/mfd/tps65217.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied with Tony's Ack, thanks.
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 80a919a8ca97..7d1cfc1d3ce0 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -145,7 +145,7 @@ int tps65217_clear_bits(struct tps65217 *tps, unsigned
> int reg,
> }
> EXPORT_SYMBOL_GPL(tps65217_clear_bits);
>
> -static struct regmap_config tps65217_regmap_config = {
> +static const struct regmap_config tps65217_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [next-20150119]regression (mm)?
On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote:
> Better option would be converting 2-lvl ARM configuration to
> , but I'm not sure if it's possible.
Well, IMHO the folded approach in asm-generic was done the wrong way
which barred ARM from ever using it.
By that, I mean that the asm-generic stuff encapsulates a pgd into a pud,
and a pud into a pmd:
typedef struct { pgd_t pgd; } pud_t;
typedef struct { pud_t pud; } pmd_t;
This, I assert, is the wrong way around. Think about it when you have a
real 4 level page table structure - a single pgd points to a set of puds.
So, one pgd encapsulates via a pointer a set of puds. One pud does not
encapsulate a set of pgds.
What we have on ARM is slightly different: because of the sizes of page
tables, we have a pgd entry which is physically two page table pointers.
However, there are cases where we want to access these as two separate
pointers.
So, we define pgd_t to be an array of two u32's, and a pmd_t to be a
single entry. This works fine, we set the masks, shifts and sizes
appropriately so that the pmd code is optimised away, but leaves us with
the ability to go down to the individual pgd_t entries when we need to
(eg, for section mappings, writing the pgd pointers for page tables,
etc.)
I think I also ran into problems with:
#define pmd_val(x) (pud_val((x).pud))
#define __pmd(x)((pmd_t) { __pud(x) } )
too - but it's been a very long time since the nopmd.h stuff was
introduced, and I last looked at it.
In any case, what we have today is what has worked for well over a decade
(and pre-dates nopmd.h), and I'm really not interested today in trying to
rework tonnes of code to make use of nopmd.h - especially as it will most
likely require nopmd.h to be rewritten too, and we now have real 3 level
page table support (which I have no way to test.)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Wed, 07 Jan 2015, Vignesh R wrote:
> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
> Also, when ADC wakes up Sequencer should not be busy executing any of the
> config steps except for the charge step. Previously charge step was 1 ADC
> clock cycle and hence it was ignored.
> TSC steps are always disabled at the end of each conversion cycle, hence
> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
>
> Signed-off-by: Vignesh R
> ---
>
> v5:
> - Remove unnecessary clearing of REG_SE
>
> drivers/mfd/ti_am335x_tscadc.c | 13 +
> include/linux/mfd/ti_am335x_tscadc.h | 1 +
> 2 files changed, 6 insertions(+), 8 deletions(-)
Looks fine.
For my own reference:
Acked-by: Lee Jones
Can this patch be applied on its own?
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index 467c80e1c4ae..e4e4b22eebc9 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> *tsadc)
> DEFINE_WAIT(wait);
> u32 reg;
>
> - /*
> - * disable TSC steps so it does not run while the ADC is using it. If
> - * write 0 while it is running (it just started or was already running)
> - * then it completes all steps that were enabled and stops then.
> - */
> - tscadc_writel(tsadc, REG_SE, 0);
> reg = tscadc_readl(tsadc, REG_ADCFSM);
> if (reg & SEQ_STATUS) {
> tsadc->adc_waiting = true;
> @@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> *tsadc)
> spin_lock_irq(&tsadc->reg_lock);
> finish_wait(&tsadc->reg_se_wait, &wait);
>
> + /*
> + * Sequencer should either be idle or
> + * busy applying the charge step.
> + */
> reg = tscadc_readl(tsadc, REG_ADCFSM);
> - WARN_ON(reg & SEQ_STATUS);
> + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
> tsadc->adc_waiting = false;
> }
> tsadc->adc_in_use = true;
> @@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
> *tsadc)
> void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
> {
> spin_lock_irq(&tsadc->reg_lock);
> - tsadc->reg_se_cache |= val;
> am335x_tscadc_need_adc(tsadc);
>
> tscadc_writel(tsadc, REG_SE, val);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> b/include/linux/mfd/ti_am335x_tscadc.h
> index 3f4e994ace2b..1fd50dcfe47c 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -128,6 +128,7 @@
>
> /* Sequencer Status */
> #define SEQ_STATUS BIT(5)
> +#define CHARGE_STEP 0x11
>
> #define ADC_CLK 300
> #define TOTAL_STEPS 16
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 14/21] ARM: imx6: convert GPC to stacked domains
On Mon, Jan 19, 2015 at 09:44:08AM +, Marc Zyngier wrote: > IMX6 has been (ab)using the gic_arch_extn to provide > wakeup from suspend, and it makes a lot of sense to convert > this code to use stacked domains instead. > > This patch does just this, updating the DT files to actually > reflect what the HW provides. > > BIG FAT WARNING: because the DTs were so far lying by not > exposing the fact that the GPC block is actually the first > interrupt controller in the chain, kernels with this patch > applied wont have any suspend-resume facility when booted > with old DTs, and old kernels with updated DTs won't even boot. > > Tested-by: Stefan Agner > Acked-by: Stefan Agner > Signed-off-by: Marc Zyngier Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 2/3] clk: Make clk API return per-user struct clk instances
On 19 January 2015 at 21:59, Stephen Boyd wrote:
> On 01/19, Tomeu Vizoso wrote:
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 97f3425..f2a1ff3 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -694,32 +751,32 @@ long __clk_mux_determine_rate(struct clk_hw *hw,
>> unsigned long rate,
>> unsigned long *best_parent_rate,
>> struct clk_hw **best_parent_p)
>> {
>> - struct clk *clk = hw->clk, *parent, *best_parent = NULL;
>> + struct clk_core *core = hw->clk->core, *parent, *best_parent = NULL;
>
> Can't we just use hw->core here?
Yup.
>> int i, num_parents;
>> unsigned long parent_rate, best = 0;
>>
>>
>> @@ -820,15 +877,18 @@ int clk_prepare(struct clk *clk)
>> {
>> int ret;
>>
>> + if (IS_ERR_OR_NULL(clk))
>> + return PTR_ERR(clk);
>
> What's going on here? Should be if (!clk)?
Yeah, guess I miscopied it from a function that was expected to be
called chained with others.
>> +
>> clk_prepare_lock();
>> - ret = __clk_prepare(clk);
>> + ret = clk_core_prepare(clk->core);
>> clk_prepare_unlock();
>>
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(clk_prepare);
>> @@ -1066,9 +1149,24 @@ long clk_get_accuracy(struct clk *clk)
>>
>> return accuracy;
>> }
>> +
>> +/**
>> + * clk_get_accuracy - return the accuracy of clk
>> + * @clk: the clk whose accuracy is being returned
>> + *
>> + * Simply returns the cached accuracy of the clk, unless
>> + * CLK_GET_ACCURACY_NOCACHE flag is set, which means a recalc_rate will be
>> + * issued.
>> + * If clk is NULL then returns 0.
>> + */
>> +long clk_get_accuracy(struct clk *clk)
>> +{
>> + return clk_core_get_accuracy(clk->core);
>
> Oops. Missing NULL check.
Yup.
>> +}
>> EXPORT_SYMBOL_GPL(clk_get_accuracy);
>>
>> @@ -1130,14 +1220,29 @@ unsigned long clk_get_rate(struct clk *clk)
> [...]
>> + *
>> + * Simply returns the cached rate of the clk, unless CLK_GET_RATE_NOCACHE
>> flag
>> + * is set, which means a recalc_rate will be issued.
>> + * If clk is NULL then returns 0.
>> + */
>> +unsigned long clk_get_rate(struct clk *clk)
>> +{
>> + return clk_core_get_rate(clk->core);
>
> Oops. Missing NULL check.
Agreed.
>> +}
>> EXPORT_SYMBOL_GPL(clk_get_rate);
>> @@ -1629,37 +1741,26 @@ static struct clk *__clk_init_parent(struct clk *clk)
> [...]
>> -int clk_set_parent(struct clk *clk, struct clk *parent)
>> +void __clk_reparent(struct clk *clk, struct clk *new_parent)
>> +{
>> + clk_core_reparent(clk->core, new_parent->core);
>> +}
>
> Is this used? Looks like we can remove it. Sorry, not sure how I
> missed this last time.
Yes, done.
>> +
>> +static int clk_core_set_parent(struct clk_core *clk, struct clk_core
>> *parent)
>> {
>> int ret = 0;
>> int p_index = 0;
>> @@ -1719,6 +1820,28 @@ out:
> [...]
>> +int clk_set_parent(struct clk *clk, struct clk *parent)
>> +{
>> + return clk_core_set_parent(clk->core, parent->core);
>
> Oops. Missing NULL check for both inputs.
Agreed.
>> +}
>> EXPORT_SYMBOL_GPL(clk_set_parent);
>>
>> /**
>> @@ -1793,18 +1909,31 @@ out:
>> }
>>
>> /**
>> + * clk_get_phase - return the phase shift of a clock signal
>> + * @clk: clock signal source
>> + *
>> + * Returns the phase shift of a clock node in degrees, otherwise returns
>> + * -EERROR.
>> + */
>> +int clk_get_phase(struct clk *clk)
>> +{
>> + return clk_core_get_phase(clk->core);
>
> Oops. Missing NULL check.
Agreed.
I have also reworked the changes to __clk_init to maintain the
existing behaviour.
Thanks,
Tomeu
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 15/21] ARM: exynos4/5: convert pmu wakeup to stacked domains
Hi Pankaj,
On 2015-01-20 07:42, Pankaj Dubey wrote:
Hi Marc,
On Monday 19 January 2015 03:14 PM, Marc Zyngier wrote:
Exynos has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.
This patch does just this, updating the DT files to actually
reflect what the HW provides.
BIG FAT WARNING: because the DTs were so far lying by not
exposing the fact that the PMU block is actually the first
interrupt controller in the chain for RTC, kernels with this patch
applied wont have any suspend-resume facility when booted
with old DTs, and old kernels with updated DTs may not even boot.
Also, I stronly suspect that there is more than two wake-up
interrupts on these platforms, but I leave it to the maintainers
to fix their mess.
Signed-off-by: Marc Zyngier
---
I tested this patch series on SMDK5250 board.
With the addition of "#interrupt-cells = <3>;"in PMU device node S2R
is working on Exynos5250 based SMDK board.
Thanks for letting me know. Can I add your Tested-by tag on this?
arch/arm/boot/dts/exynos4.dtsi| 4 ++
arch/arm/boot/dts/exynos5250.dtsi | 4 ++
arch/arm/boot/dts/exynos5420.dtsi | 4 ++
arch/arm/mach-exynos/exynos.c | 14 ++---
arch/arm/mach-exynos/suspend.c| 122
++
5 files changed, 129 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi
index b8168f1..0e7d74e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -141,6 +141,9 @@
pmu_system_controller: system-controller@1002 {
compatible = "samsung,exynos4210-pmu", "syscon";
reg = <0x1002 0x4000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
dsi_0: dsi@11C8 {
@@ -253,6 +256,7 @@
rtc@1007 {
compatible = "samsung,s3c6410-rtc";
reg = <0x1007 0x100>;
+ interrupt-parent = <&pmu_system_controller>;
interrupts = <0 44 0>, <0 45 0>;
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a229fc..1dc5f6b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -194,6 +194,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
@@ -230,6 +233,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f..35ecd36 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -309,6 +309,7 @@
rtc: rtc@101E {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
+ interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
@@ -748,6 +749,9 @@
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
#clock-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/mach-exynos/exynos.c
b/arch/arm/mach-exynos/exynos.c
index c13d083..e417fdc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -175,16 +175,15 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Apparently, these SoCs are not able to wake-up from suspend
using
+ * the PMU. Too bad. Should they suddenly become capable of such a
+ * feat, the matches below should be moved to suspend.c.
+ */
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = "samsung,exynos3250-pmu" },
As I know Exynos3250, S2R support has been added in kgene/for-next
and should work as expected so we may need to do update
"exynos_wkup_irq" for exynos3250 and remove it from this list, so
that
it's S2R should not break. I am adding concern engineer (+cc: Chanwoo
Choi) in the loop.
That would have to be an additional patch, unless we decide to delay
this series.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
Re: [PATCH 5/5] ARM: omap2plus_defconfig: Enable PCF857X and EXTCON_GPIO_USB
On 19/01/15 21:38, Tony Lindgren wrote: > * Tony Lindgren [150119 10:52]: >> * Roger Quadros [150119 09:55]: >>> Both are needed for USB cable type detection on dra7-evm. >>> >>> Signed-off-by: Roger Quadros >>> --- >>> arch/arm/configs/omap2plus_defconfig | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/arm/configs/omap2plus_defconfig >>> b/arch/arm/configs/omap2plus_defconfig >>> index c2c3a85..bc23b90 100644 >>> --- a/arch/arm/configs/omap2plus_defconfig >>> +++ b/arch/arm/configs/omap2plus_defconfig >>> @@ -203,6 +203,7 @@ CONFIG_SPI_OMAP24XX=y >>> CONFIG_PINCTRL_SINGLE=y >>> CONFIG_DEBUG_GPIO=y >>> CONFIG_GPIO_SYSFS=y >>> +CONFIG_GPIO_PCF857X=y >>> CONFIG_GPIO_TWL4030=y >>> CONFIG_W1=y >>> CONFIG_BATTERY_BQ27x00=m >> >> Looks like I have this too but as a loadable module :) So I'll keep >> that one. >> >>> @@ -326,6 +327,7 @@ CONFIG_DMADEVICES=y >>> CONFIG_TI_EDMA=y >>> CONFIG_DMA_OMAP=y >>> CONFIG_EXTCON=y >>> +CONFIG_EXTCON_GPIO_USB=y >>> CONFIG_EXTCON_PALMAS=y >>> CONFIG_PWM=y >>> CONFIG_PWM_TIECAP=y >> >> I'll apply this part into omap-for-v3.20/defconfig but make it into =m >> instead of =y. > > Oh but this depends on the driver being added, so not applying. > Can you please repost a patch adding CONFIG_EXTCON_GPIO_USB=m > once the driver is merged? > Yes, I'll do that. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM: OMAP3: MACH_OMAP3517EVM?
Tony,
Your commit 4d62dbda8561 ("ARM: OMAP3: Remove legacy support for
am3517-evm") is included in today's linux-next (ie, next-20150120). I
noticed because a script I use to check linux-next spotted a problem
caused by it.
See, your commit removes the Kconfig symbol MACH_OMAP3517EVM. But
there's still a reference to that symbol in sound/soc/omap/Kconfig. This
means that in linux-next a symbol, SND_OMAP_SOC_AM3517EVM, cannot be set
anymore.
I assume a patch that address this (either by removing
SND_OMAP_SOC_AM3517EVM or by updating its dependencies) is queued
somewhere. Is that correct?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.19-rc2 v15 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S
On 19/01/15 21:38, Tony Lindgren wrote: > * Daniel Thompson [150105 04:49]: >> The omap1's debug-macro.S is similar to the generic 8250 code. Compared to >> the 8520 code the omap1 macro automatically determines what UART to use >> based on breadcrumbs left by the bootloader and automatically copes with >> the eccentric register layout on OMAP7XX. >> >> This patch drops both these features and relies instead on the generic >> 8250 macros: >> >> 1. Dropping support for the bootloader breadcrumbs is identical to the >>way the migration was handled for OMAP2 (see 808b7e07464d...). >> >> 2. Support for OMAP7XX still exists but it must be configured by hand >>(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. >> >> Signed-off-by: Daniel Thompson >> Cc: Russell King >> Cc: Arnd Bergmann >> Cc: linux-omap@vger.kernel.org >> Tested-by: Aaro Koskinen >> Acked-by: Tony Lindgren > > Daniel, I suggest you upload this patch into Russell's patch tracking > system to get it merged. That at least shrinks down your patch series > if the other patches need more work. This has been in the patch tracker for a week or so: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8271/1 I'm very aware that this patch (and indeed the whole patch set) has been knocking round for longer than it should have. The changelog for this patchset is certainly not one to be especially proud off ;-) . Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ASoC: OMAP: mcbsp: ensure that CLKX and CLKR are not used as ouput pins when they are used as input clock for the SRG.
On 01/19/2015 11:24 PM, Thomas Niederprüm wrote: > This patch fixes faulty behaviour in a setup where the input clock for the > SRG is fed through the CLKR/CLKX pin but the McBSP is configured to be > master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR/CLKX must > not be configured as output pin. Otherwise the input clock is messed up > horribly. > > This patch makes it possible to use the CLKR/CLKX pin rather than CLKS to > inject a reference clock in setups where McBSP is master and not both > rx and tx are used. However for this to work it has to be ensured that > set_dai_sysclk() is called after set_dai_fmt(). > > This was tested on a beagleboard-xm using McBSP1 to drive a i2s DAC through > the tx lines (CLKX,FSX,DX). Using this patch the CLKR pin is used to inject > an external reference clock. > > changes since v1: > - added comments explaining the bit masking to disable output on CLKR/CLKX Acked-by: Peter Ujfalusi > > Signed-off-by: Thomas Niederprüm > --- > sound/soc/omap/omap-mcbsp.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c > index bd3ef2a..c37f606 100644 > --- a/sound/soc/omap/omap-mcbsp.c > +++ b/sound/soc/omap/omap-mcbsp.c > @@ -530,8 +530,19 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct > snd_soc_dai *cpu_dai, > > case OMAP_MCBSP_SYSCLK_CLKX_EXT: > regs->srgr2 |= CLKSM; > + regs->pcr0 |= SCLKME; > + /* > + * If McBSP is master but yet the CLKX/CLKR pin drives the SRG, > + * disable output on those pins. This enables to inject the > + * reference clock through CLKX/CLKR. For this to work > + * set_dai_sysclk() _needs_ to be called after set_dai_fmt(). > + */ > + regs->pcr0 &= ~CLKXM; > + break; > case OMAP_MCBSP_SYSCLK_CLKR_EXT: > regs->pcr0 |= SCLKME; > + /* Disable ouput on CLKR pin in master mode */ > + regs->pcr0 &= ~CLKRM; > break; > default: > err = -ENODEV; > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi Pavel,
On Tue, Dec 23, 2014, Pavel Machek wrote:
> + while (1) {
> + int cmd, len;
> +
> + fw_pos += cmd_len;
> +
> + if (fw_pos >= fw_entry->size)
> + break;
> +
> + if (fw_pos + 2 > fw_entry->size) {
> + dev_err(info->dev, "Corrupted firmware image\n");
> + err = -EMSGSIZE;
> + break;
> + }
> +
> + cmd_len = fw_entry->data[fw_pos++];
> + cmd_len += fw_entry->data[fw_pos++] << 8;
> + if (cmd_len == 0)
> + break;
> +
> + if (fw_pos + cmd_len > fw_entry->size) {
> + dev_err(info->dev, "Corrupted firmware image\n");
> + err = -EMSGSIZE;
> + break;
> + }
> +
> + /* Skip first two packets */
> + if (++num <= 2)
> + continue;
> +
> + /* Note that this is timing-critical. If sending packets takes
> too
> + * long, initialization will fail.
> + */
> + cmd = fw_entry->data[fw_pos+1];
> + cmd += fw_entry->data[fw_pos+2] << 8;
> + len = fw_entry->data[fw_pos+3];
> +
> + skb = __hci_cmd_sync(info->hdev, cmd, len,
> fw_entry->data+fw_pos+4, 500);
> + if (IS_ERR(skb)) {
> + dev_err(info->dev, "...sending cmd %x len %d failed
> %ld\n",
> + cmd, len, PTR_ERR(skb));
> + err = -EIO;
> + break;
> + }
> + }
Looks like the code is leaking skb when __hci_cmd_sync() succeeds.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap: hwmod: add debugfs interface
On Tue, 20 Jan 2015, Paul Walmsley wrote: > On Fri, 5 Dec 2014, Felipe Balbi wrote: > > > By exposing the details of hwmod structures > > to debugfs we can much more easily verify > > that changes to hwmod data is correct and won't > > cause regressions. > > > > The idea is that this can be used to check the > > state of one hwmod, verify hwmod sysc fields, etc. > > > > For example, this will be used to move some of > > the sysc fields to DT and later verify that they > > are correct pre- and post-patch. > > > > Signed-off-by: Felipe Balbi > > This one had a bunch of unnecessary includes and checkpatch issues > (below). I cleaned those up here and have queued the result (also below) > for v3.20. ... and, the patch doesn't even boot. Dropped. If you really want something like this to be merged, resend a version that boots, and has checkpatch warnings fixed and unnecessary includes dropped. Otherwise you're just wasting my time. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
