* [PATCH 1/3] ARM: dts: imx27-phytec-phycard-s-som: Sort entries
From: Alexander Shiyan @ 2014-02-04 14:59 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts | 36 ++++++++++++------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
index e51e550..a28b6c7 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dts
@@ -29,6 +29,24 @@
status = "okay";
};
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ at24 at 52 {
+ compatible = "at,24c32";
+ pagesize = <32>;
+ reg = <0x52>;
+ };
+};
+
&iomuxc {
imx27-phycard-s-som {
pinctrl_fec1: fec1grp {
@@ -62,21 +80,3 @@
};
};
};
-
-&fec {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-};
-
-&i2c2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c2>;
- status = "okay";
-
- at24 at 52 {
- compatible = "at,24c32";
- pagesize = <32>;
- reg = <0x52>;
- };
-};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Gregory CLEMENT @ 2014-02-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F02816.1050708@gmail.com>
On 04/02/2014 00:36, Sebastian Hesselbarth wrote:
> On 02/04/2014 12:16 AM, Willy Tarreau wrote:
>> On Thu, Jan 30, 2014 at 11:31:32AM +0100, Sebastian Hesselbarth wrote:
>>> On 01/30/14 11:24, Gregory CLEMENT wrote:
>>>> On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
>>>>> This patch set fixes clk init order that went upside-down with
>>>>> v3.14. I haven't really investigated what caused this, but I assume
>>>>> it is related with DT node reordering by addresses.
>>>>
>>>> Can you explain what kind of issue do you observe?
>>>
>>> Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver
>>> gets registered before core-clocks. It therefore cannot resolve it's
>>> parent clock name for tclk and all clock gates will have no parent
>>> clock.
>>>
>>> Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors
>>> poping up, when they calculate a frequency division factors based on
>>> clock gate frequency, which should have been tclk but is 0 now.
>>
>> Well, to be honnest, I have no idea whether your patch is the right way
>> to fix the problem or not, but what I can say is that it fixes such oopses
>> that appear in 3.14-rc1 when booting on mirabox :
>>
>> Division by zero in kernel.
>
> Willy,
>
> you have hit exactly the reason for this patch.
>
> [...]
>> By the way, seeing how often a trick related to the DT is nedeed to solve an
>> oops or a panic, I'm really scared that this whole DT mess is just becoming
>> the exact copy of the ACPI mess (but 15 years later) and we'll experience the
>> same horrible things :-( Sometimes I'm wondering whether there are not too
>> many structural things put in there...
>
> To be precise, it is not a DT-related trick at all. You would have the
> same issues, if you'd register those "low-level" (i.e. early) drivers
> without DT. It is more about missing init ordering, here.
>
> There could be different ways to work this out, even elevating clock
> devices to "normal" probed devices could be possible. I am sure, in the
> long run, it will work out, but now this is a fix for v3.14-rc1.
>
> @Jason, Andrew, Gregory, Thomas:
> Now that v3.14 is out, anything against taking this in as fixes for rc1?
Hi Sebastian,
I am not found of this solution I still think it should be done
at framework level. However we still have this very annoying issue,
and this fix is better than nothing. So I am not against taking this
for rc1 with the hope that it will be later revert with a better
solution.
Thanks,
Gregory
>
> Sebastian
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Toradex Colibri PXA270 Sound Problem
From: Erik Habicht @ 2014-02-04 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Hallo List,
we are using a Toradex PXA270 SoC module with a patch to get the Wolfson
WM9715 working on 2.6.37 (2.6.36, 2.6.35, 2.6.27). It works pretty well.
Now i decided to switch to a newer kernel version. I started with 2.6.38
and modified the patch to compile it. The kernel boot to the
system, but only capturing is working. I get no audio output anymore.
In the previous kernel versions i always use the following amixer settings:
amixer set 'Headphone' 100% on
amixer set 'Speaker Mixer PCM' on
amixer set 'Left HP Mixer PCM' on
amixer set 'Right HP Mixer PCM' on
This is the kernel output. It looks like all versions before:
[ 8.405110] WM9711/WM9712 SoC Audio Codec 0.4
[ 8.457947] pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44)
[ 8.543333] asoc: wm9712-hifi <-> pxa2xx-ac97 mapping ok
[ 8.609104] asoc: wm9712-aux <-> pxa2xx-ac97-aux mapping ok
[ 8.687232] wm97xx-ts 0-0:wm9712-codec: detected a wm9712 codec
[ 8.760968] input: wm97xx touchscreen as
/devices/platform/soc-audio/0-0:wm9712-codec/input/input0
[ 8.875466] ALSA device list:
[ 8.911416] #0: Toradex Colibri
I already tried 3.2.y with the same behavior.
Maybe someone can help me to figure out whats going wrong?
I attached the patches i used:
working = patch-2.6.37.y.patch
not working = patch-2.6.38.y.patch
Best regards,
Erik
_______________________________________________________
Registergericht / Court of jurisdiction: Amtsgericht Gie?en HRB 5708
Gesch?ftsf?hrer / Managing Director: Edith Thiesen, J?rgen Thiesen
USt.-Id: DE 175 623 789
Ust.-Nr: 018 246 00743 FA Fulda
Hauptsitz / Headquarters:
Thiesen Hardware & Software Design GmbH / Im Tiegel 9 / 36367 Wartenberg / Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-2.6.37.y.patch
Type: text/x-patch
Size: 7300 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/d1fce0df/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-2.6.38.y.patch
Type: text/x-patch
Size: 7556 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/d1fce0df/attachment-0003.bin>
^ permalink raw reply
* [PATCH] ARM: pxa: fix various compilation problems
From: Arnd Bergmann @ 2014-02-04 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391518387-5934-1-git-send-email-linus.walleij@linaro.org>
On Tuesday 04 February 2014 13:53:07 Linus Walleij wrote:
> Hi ARM SoC folks: please apply this patch directly to the ARM
> SoC tree fixes branch if you are happy with it.
It's also needed for 3.13-backports, right?
Arnd
^ permalink raw reply
* [PATCH resend 1/2] arm64: defer reloading a task's FPSIMD state to userland resume
From: Ard Biesheuvel @ 2014-02-04 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203163609.GK14112@mudshark.cambridge.arm.com>
On 3 February 2014 17:36, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ard,
>
> On Fri, Jan 31, 2014 at 10:13:15AM +0000, Ard Biesheuvel wrote:
>> If a task gets scheduled out and back in again and nothing has touched
>> its FPSIMD state in the mean time, there is really no reason to reload
>> it from memory. Similarly, repeated calls to kernel_neon_begin() and
>> kernel_neon_end() will preserve and restore the FPSIMD state every time.
>>
>> This patch defers the FPSIMD state restore to the last possible moment,
>> i.e., right before the task re-enters userland. If a task does not enter
>> userland at all (for any reason), the existing FPSIMD state is preserved
>> and may be reused by the owning task if it gets scheduled in again on the
>> same CPU.
>
> The one situation I'm unsure of here is how you deal with the saved fpsimd
> state potentially being updated by a signal handler or a debugger. In this
> case, we probably need to set _TIF_FOREIGN_FPSTATE to force a reload, or are
> you handling this some other way?
>
If I am reading the code correctly, the signal handler is entered
using the normal userland resume path, so I don't think it requires
special treatment.
For the ptrace() case, it should suffice to set the 'last_cpu' field
to (u32)-1 to indicate that the FPSIMD context should be reloaded from
memory regardless of which CPU the debuggee is restarted on.
Regards,
Ard.
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204143119.GA4627@beef>
Hold your horses. :)
> > > Add a driver for the BCM59056 PMU multi-function device. The driver
> > > initially supports regmap initialization and instantiation of the
> > > voltage regulator device function of the PMU.
> > >
> > > Signed-off-by: Matt Porter <mporter@linaro.org>
> > > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > > ---
> > > drivers/mfd/Kconfig | 8 +++
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > > 4 files changed, 163 insertions(+)
> > > create mode 100644 drivers/mfd/bcm59056.c
> > > create mode 100644 include/linux/mfd/bcm59056.h
<snip>
> > I thought this was a DT only driver? If so, you probably want to use
> > of_match_device() instead.
>
> Correct, I'll use of_match_device()
If you're going to use this ...
<snip>
> > You've gone to the trouble of setting a device version here, but you
> > don't seem to use it?
>
> I'll drop the device version
... then you'll still need this.
> > > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > > + { "bcm59056", BCM59056 },
> > > + { }
> > > +};
> >
> > Ah, I guess this is where id->driver comes from.
> >
> > It's pretty silly that the I2C subsystem demands the presence of this
> > table, despite not using it if an of_device_id table is present.
>
> It does make it very difficult to follow DT enabled I2C client drivers
> :( I'll drop the BCM59056 too.
And I don't think you can drop this, as the I2C subsystem still
insists on it.
> > > +/* chip id */
> > > +#define BCM59056 0
> >
> > Lonely, oh so lonely!
>
> Understood. Will remove.
I think you need to keep this to supply the silly I2C ID table.
I would just omit the '.data = (void *) VERSION' from the
of_match_table until you require it.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/6] BCM59056 PMU regulator support
From: Matt Porter @ 2014-02-04 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204134043.GG13529@lee--X1>
On Tue, Feb 04, 2014 at 01:40:43PM +0000, Lee Jones wrote:
> > The BCM59056 is a multi-function power management unit used with the
> > BCM281xx family of SoCs. This series adds an MFD and voltage regulator
> > driver to support the BCM59056. The bcm28155-ap DT support is updated
> > to enable use of regulators on the otg and sdhci peripherals.
> >
> > Matt Porter (6):
> > i2c: bcm-kona: register with subsys_initcall
> > regulator: add bcm59056 pmu DT binding
> > mfd: add bcm59056 pmu driver
> > regulator: add bcm59056 regulator driver
> > ARM: configs: bcm_defconfig: enable bcm59056 regulator support
> > ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
> >
> > .../devicetree/bindings/regulator/bcm59056.txt | 37 ++
> > arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
> > arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
> > arch/arm/configs/bcm_defconfig | 7 +
> > drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
> > drivers/mfd/Kconfig | 8 +
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 ++++++
> > drivers/regulator/Kconfig | 8 +
> > drivers/regulator/Makefile | 1 +
> > drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 ++
> > 12 files changed, 873 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
> > create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 drivers/regulator/bcm59056-regulator.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> FYI: Mark's email address is not correct. Not sure where you pulled
> this one up from, but he doesn't have access to it anymore.
Thanks, I already updated (it was a stale .mutt/aliases entry here) it
after the bounces.
-Matt
^ permalink raw reply
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Santosh Shilimkar @ 2014-02-04 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgmTmAOy4SpZU8oxN=0AihcixX5aU1sM_LNe5TiScMaSw@mail.gmail.com>
On Monday 03 February 2014 09:18 PM, Olof Johansson wrote:
> Hi,
>
>
> On Mon, Feb 3, 2014 at 3:28 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> Currently arch specific DMA address translation routines can be enabled
>> using only defines which makes impossible to use them in with
>> multi-platform builds.
>>
>> Hence, introduce arch specific hooks for DMA address translations
>> routines to be compatible with multi-platform builds:
>> dma_addr_t (*arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
>> unsigned long (*arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
>> void* (*arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
>> dma_addr_t (*arch_virt_to_dma)(struct device *dev, void *addr);
>>
>> In case if architecture won't use it - DMA address translation routines
>> will fall-back to existing implementation.
>>
>> Also, modify machines omap1, ks8695, iop13xx to use new DMA hooks.
>
> [...]
>
>> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
>> index e701a4d..84acc46 100644
>> --- a/arch/arm/include/asm/dma-mapping.h
>> +++ b/arch/arm/include/asm/dma-mapping.h
>> @@ -55,28 +55,16 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
>> * functions used internally by the DMA-mapping API to provide DMA
>> * addresses. They must not be used by drivers.
>> */
>> -#ifndef __arch_pfn_to_dma
>> -static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>> -{
>> - return (dma_addr_t)__pfn_to_bus(pfn);
>> -}
>>
>> -static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
>> -{
>> - return __bus_to_pfn(addr);
>> -}
>> +extern dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
>> +extern unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
>> +extern void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
>> +extern dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr);
>
> I tend to prefer having these kind of function pointers grouped in a
> struct instead of in the toplevel namespace like this. It allows you
> to use a set_<foo>_ops() interface too instead and reduces
> exposed/exported internals since only the global struct pointer has to
> be exported.
>
agree
[..]
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 5c43ca5..74111bf 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -39,6 +39,35 @@
>>
>> #include "mm.h"
>>
>> +static inline dma_addr_t __pfn_to_dma(struct device *dev, unsigned long pfn)
>> +{
>> + return (dma_addr_t)__pfn_to_bus(pfn);
>> +}
>> +
>> +static inline unsigned long __dma_to_pfn(struct device *dev, dma_addr_t addr)
>> +{
>> + return __bus_to_pfn(addr);
>> +}
>> +
>> +static inline void *__dma_to_virt(struct device *dev, dma_addr_t addr)
>> +{
>> + return (void *)__bus_to_virt((unsigned long)addr);
>> +}
>> +
>> +static inline dma_addr_t __virt_to_dma(struct device *dev, void *addr)
>> +{
>> + return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>> +}
>> +
>> +dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn) = __pfn_to_dma;
>> +EXPORT_SYMBOL(__arch_pfn_to_dma);
>> +unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr) = __dma_to_pfn;
>> +EXPORT_SYMBOL(__arch_dma_to_pfn);
>> +void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr) = __dma_to_virt;
>> +EXPORT_SYMBOL(__arch_dma_to_virt);
>> +dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr) = __virt_to_dma;
>> +EXPORT_SYMBOL(__arch_virt_to_dma);
>
> Independent on whether someone objects to my preference of exporting a
> struct, these (or that struct pointer) should probably be
> EXPORT_SYMBOL_GPL().
>
Sure.
Regards,
Santosh
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204132951.GE13529@lee--X1>
On Tue, Feb 04, 2014 at 01:29:51PM +0000, Lee Jones wrote:
> > Add a driver for the BCM59056 PMU multi-function device. The driver
> > initially supports regmap initialization and instantiation of the
> > voltage regulator device function of the PMU.
> >
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> > Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> > ---
> > drivers/mfd/Kconfig | 8 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/mfd/bcm59056.h | 35 +++++++++++++
> > 4 files changed, 163 insertions(+)
> > create mode 100644 drivers/mfd/bcm59056.c
> > create mode 100644 include/linux/mfd/bcm59056.h
>
> <snip>
>
> > +static struct mfd_cell bcm59056s[] = {
> > + {
> > + .name = "bcm59056-pmu",
>
> If you plan to use *->of_node in the PMU driver, which it looks like
> you do, you should set the compatible string here.
Ok. I missed that..I'll split bindings to reflect this as well. There's
an error in that the regulator properties are all defined in the base
compatible of brcm,bcm59056 atm and they'll need to be in
brcm,bcm59056-pmu's binding.
> > + },
> > +};
> > +
> > +static const struct regmap_config bcm59056_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = BCM59056_MAX_REGISTER - 1,
>
> If you've just set this manually i.e. it's not part of an enum table,
> can't you set it a value you don't need to do math on? It's not used
> anywhere else is it?
Yes, I'll update this. It's not used elsewhere.
>
> > + .cache_type = REGCACHE_RBTREE,
> > +};
> > +
> > +static int bcm59056_i2c_probe(struct i2c_client *i2c,
> > + const struct i2c_device_id *id)
> > +{
> > + struct bcm59056 *bcm59056;
> > + int chip_id = id->driver_data;
>
> I thought this was a DT only driver? If so, you probably want to use
> of_match_device() instead.
Correct, I'll use of_match_device()
> > + int ret = 0;
> > +
> > + bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
> > + if (!bcm59056)
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(i2c, bcm59056);
> > + bcm59056->dev = &i2c->dev;
> > + bcm59056->i2c_client = i2c;
> > + bcm59056->id = chip_id;
> > +
> > + bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
> > + if (IS_ERR(bcm59056->regmap)) {
> > + ret = PTR_ERR(bcm59056->regmap);
> > + dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = mfd_add_devices(bcm59056->dev, -1,
> > + bcm59056s, ARRAY_SIZE(bcm59056s),
> > + NULL, 0, NULL);
>
> Are you sure you need all of your #includes?
>
> I notice that irqdomain is there, but you don't actually have one?
Right, I'll do a sweep on them. In that particular case, I don't yet
have a need to implement interrupt support so it needs to go.
>
> > + if (ret < 0)
> > + dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
>
> What if we change the name of the function? Probably better to say
> something like "device registration failed" or thelike.
Will do.
>
> > + return ret;
> > +}
> > +
> > +static int bcm59056_i2c_remove(struct i2c_client *i2c)
> > +{
> > + struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
> > +
> > + mfd_remove_devices(bcm59056->dev);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id bcm59056_of_match[] = {
> > + { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
>
> You've gone to the trouble of setting a device version here, but you
> don't seem to use it?
I'll drop the device version
> > + { }
> > +};
> > +
> > +static const struct i2c_device_id bcm59056_i2c_id[] = {
> > + { "bcm59056", BCM59056 },
> > + { }
> > +};
>
> Ah, I guess this is where id->driver comes from.
>
> It's pretty silly that the I2C subsystem demands the presence of this
> table, despite not using it if an of_device_id table is present.
It does make it very difficult to follow DT enabled I2C client drivers
:( I'll drop the BCM59056 too.
> > +MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
> > +
> > +static struct i2c_driver bcm59056_i2c_driver = {
> > + .driver = {
> > + .name = "bcm59056",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(bcm59056_of_match),
>
> No need to use of_match_ptr() here.
Will remove.
> > + },
> > + .probe = bcm59056_i2c_probe,
> > + .remove = bcm59056_i2c_remove,
> > + .id_table = bcm59056_i2c_id,
>
> *grumble*
:) Yes, unavoidable for now.
> > +};
> > +
> > +static int __init bcm59056_init(void)
> > +{
> > + return i2c_add_driver(&bcm59056_i2c_driver);
> > +}
> > +subsys_initcall(bcm59056_init);
>
> Really? :(
>
> Maybe you'll want to comment this, in case people do not know the back
> ground and attempts to clean it up.
I'll add a comment. This is the old problem of needing regulators really
early. It's exasperated by the fact that the USB gadget framework
drivers do not use driver probing. This means that they can not be
deferred after i2c/mfd/regulator init...the problem is particularly
noticeable when building in a gadget driver for nfsroot purposes.
Because of this I have the regulator, MFD, and i2c drivers all using
subsys_initcall() in this series. FWIW, there's some discussion about
how to resolve the USB gadget driver case but it's going to take a
while.
> > +static void __exit bcm59056_exit(void)
> > +{
> > + i2c_del_driver(&bcm59056_i2c_driver);
> > +}
> > +module_exit(bcm59056_exit);
>
> <snip>
>
> > +/* chip id */
> > +#define BCM59056 0
>
> Lonely, oh so lonely!
Understood. Will remove.
> > +/* max register address */
> > +#define BCM59056_MAX_REGISTER 0xe8
>
> Don't you have a table of registers which you care about?
I placed the register defs that I actually use in the regulator driver
itself since that is the only place they are used. I notice most MFD
drivers centralize this in linux/mfd/*.h. However, generally chunk
of register defs are only used in one subdriver and not shared. If
it's preferred to move all register defs centrally I can do that.
> > +/* bcm59056 chip access */
>
> Superfluous comment? Don't we all know what these containers do?
Indeed, will remove.
Thanks for reviewing.
-Matt
> > +struct bcm59056 {
> > + struct device *dev;
> > + struct i2c_client *i2c_client;
> > + struct regmap *regmap;
> > + unsigned int id;
> > +};
> > +
> > +#endif /* __LINUX_MFD_BCM59056_H */
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC/RFT 2/2] ARM: keystone: Install hooks for dma address translation routines
From: Santosh Shilimkar @ 2014-02-04 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgzsx3gE6cT-nMTJfnO1T5pvfTr8HA6tVGv8svF_kCYjg@mail.gmail.com>
On Monday 03 February 2014 09:05 PM, Olof Johansson wrote:
> Hi,
>
> On Mon, Feb 3, 2014 at 3:28 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> Keystone platforms have their physical memory mapped at an address
>> outside the 32-bit physical range. A Keystone machine with 16G of RAM
>> would find its memory at 0x0800000000 - 0x0bffffffff.
>> The system interconnect allows to perform DMA transfers from first 2G of
>> physical memory (0x08 0000 0000 to 08 7FFF FFFF) which aliased in
>> hardware to the 32-bit addressable space (0x80000000 - 0xffffffff),
>> because DMA HW supports only 32-bits addressing.
>>
>> Hence, add arch hooks for dma address translation routines.
>>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Olof Johansson <olof@lixom.net>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>> arch/arm/mach-keystone/keystone.c | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
>> index 1b43a27..54dae03 100644
>> --- a/arch/arm/mach-keystone/keystone.c
>> +++ b/arch/arm/mach-keystone/keystone.c
>> @@ -14,6 +14,7 @@
>> #include <linux/init.h>
>> #include <linux/of_platform.h>
>> #include <linux/of_address.h>
>> +#include <linux/dma-mapping.h>
>>
>> #include <asm/setup.h>
>> #include <asm/mach/map.h>
>> @@ -53,6 +54,28 @@ static phys_addr_t keystone_virt_to_idmap(unsigned long x)
>> return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
>> }
>>
>> +static unsigned long keystone_dma_pfn_offset __read_mostly;
>> +
>> +static dma_addr_t keystone_pfn_to_dma(struct device *dev, unsigned long pfn)
>> +{
>> + return PFN_PHYS(pfn - keystone_dma_pfn_offset);
>> +}
>> +
>> +static unsigned long keystone_dma_to_pfn(struct device *dev, dma_addr_t addr)
>> +{
>> + return PFN_DOWN(addr) + keystone_dma_pfn_offset;
>> +}
>> +
>> +static void *keystone_dma_to_virt(struct device *dev, dma_addr_t addr)
>> +{
>> + return phys_to_virt(addr + PFN_PHYS(keystone_dma_pfn_offset));
>> +}
>> +
>> +static dma_addr_t keystone_virt_to_dma(struct device *dev, void *addr)
>> +{
>> + return virt_to_phys(addr) - PFN_PHYS(keystone_dma_pfn_offset);
>> +}
>> +
>> static void __init keystone_init_meminfo(void)
>> {
>> bool lpae = IS_ENABLED(CONFIG_ARM_LPAE);
>> @@ -89,6 +112,14 @@ static void __init keystone_init_meminfo(void)
>> /* Populate the arch idmap hook */
>> arch_virt_to_idmap = keystone_virt_to_idmap;
>>
>> + /* Populate the arch DMA hooks */
>> + keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
>> + KEYSTONE_LOW_PHYS_START);
>> + __arch_pfn_to_dma = keystone_pfn_to_dma;
>> + __arch_dma_to_pfn = keystone_dma_to_pfn;
>> + __arch_dma_to_virt = keystone_dma_to_virt;
>> + __arch_virt_to_dma = keystone_virt_to_dma;
>
> Is this truly a static window, or is it going through an IOMMU that
> just happens to have an identity mapping setup per default?
>
Its true physical static window hardwired in Hardware. No IOMMU
involvement.
> PPC servers use "ibm,dma-window" to describe the assigned dma address
> space for busses/devices, but the window itself doesn't contain any
> information about the physical address mapping (since it goes through
> an iommu after that). It likely doesn't fit this particular use case,
> but it's something we should look at as a base in case we need to
> start looking at bindings for this instead of coding it per SoC. We'll
> know more once we've seen what a few of the implementations out there
> are.
>
Understood.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
From: Rob Herring @ 2014-02-04 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506890-7335-3-git-send-email-thomas.ab@samsung.com>
On Tue, Feb 4, 2014 at 3:41 AM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> Certain CPUs or devices can support optional boost operating modes. Add a new
> binding to list OPPs to be additionally made available in boost operating modes.
>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> Documentation/devicetree/bindings/power/opp.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
> index 74499e5..4df5cca 100644
> --- a/Documentation/devicetree/bindings/power/opp.txt
> +++ b/Documentation/devicetree/bindings/power/opp.txt
> @@ -10,6 +10,10 @@ Properties:
> freq: clock frequency in kHz
> vol: voltage in microvolt
>
> +Optional Properties:
> +- boost-opp: Similar to "operating-points" property but usable only in
> + optional boost operating modes.
> +
> Examples:
>
> cpu at 0 {
> @@ -22,4 +26,9 @@ cpu at 0 {
> 396000 950000
> 198000 850000
> >;
> + boost-opp = <
> + /* kHz uV */
> + 1500000 1350000
> + 1400000 1285000
> + >;
This looks like an example of needing to add more properties to the
OPP table. There are ongoing discussions on how to extend OPP table
and map to C states. This should be part of that discussion.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: i.MX51 babbage: Support diagnostic LED
From: Liu Ying @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
The D25 LED controlled by gpio on the i.MX51 babbage
board is a diagnostic LED according to the board design.
This patch adds the relevant device tree nodes to the
i.MX51 babbage device tree file to support this LED.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
arch/arm/boot/dts/imx51-babbage.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index be1407c..8d6a74b 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -81,6 +81,17 @@
};
};
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pin_gpio2_6>;
+
+ led-diagnostic {
+ label = "diagnostic";
+ gpios = <&gpio2 6 0>;
+ };
+ };
+
sound {
compatible = "fsl,imx51-babbage-sgtl5000",
"fsl,imx-audio-sgtl5000";
@@ -280,6 +291,12 @@
MX51_PAD_CSPI1_RDY__GPIO4_26 0x80000000
>;
};
+
+ led_pin_gpio2_6: led_gpio2_6 {
+ fsl,pins = <
+ MX51_PAD_EIM_D22__GPIO2_6 0x80000000
+ >;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Rob Herring @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 4, 2014 at 3:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
>> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
>> without clearly specifying exactly how PCI is suppose to work is
>> completely bonkers.
>>
>> What is needed is a spec that says:
>> 1) Here is how you generate config TLPs. A MMIO region that
>> conforms to the already specified x86 ECAM would
>> be perfect
>> 2) Here is a dword by dword break down of the entire config space in
>> a SOC. Here is where a on-board AHCI controller must show up in
>> config space. Here is how an external PCI-E port must show
>> up. Etc. Most of this is already specified, but it clearly needs
>> to be layed out explicitly for ARM SOCs to actually follow it.
>> 3) Here is how you specify the aperture(s) associated with PCI BAR's
>> and bridge windows in config space. And yes: The CONFIG SPACE
>> BARS MUST WORK.
>> 4) Here is how MSI works, these are the values you put in the
>> address/data and here is how you collect the interrupt.
>> 5) Here is how Legacy INTx must be mapped into the GIC.
>>
>> This is what x86 does, and they have been doing it well for 10
>> years. If you want to play in the server game you have to properly
>> implement PCI.
>
> I'm pretty sure the authors of the SBSA actually thought that was
> what they wrote, by referring to external specifications (pci-3.0,
> ehci, ahci, ...). However, it seems they were either foolish enough
> to believe that hardware designers would follow these specs, or
> they were intentionally misled and got talked into putting ambiguous
> terminology in because there were already hardware designs that
> are not exactly in line with the spirit of the SBSA but can be
> argued to be conforming to the text for a lax interpretation.
>
> I think EHCI is a much better example than PCI here, because the
> spec has exactly one line to say about it, where it spends a whole
> chapter on PCI.
>
> Here is how a sane person would read SBSA to create a compliant
> implementation:
s/sane/software/
>
> I have to use EHCI version 1.1 to provide USB-2.0 support. EHCI
> is a PCI device, so I'll put it behind a PCIe port that complies
> to the PCIe section of the SBSA. Since EHCI by itself only provides
> high-speed USB, and USB-2.0 mandates I provide low-speed and
> full-speed as well, I have to add a USB hub device. It would have
> been easier to just use OHCI for these, but SBSA says I can't.
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
> look exactly as if it was on an external card, I just have to
> ensure the boot loader correctly sets up the clocks and the phy
> before an SBSA compliant OS gets loaded, all runtime power
> management will get handled through the EHCI-1.1 energy-efficiency
> extensions.
>
> Here is how a crazy person would read the same sentence in the SBSA:
s/crazy/hardware/
>
> I have an IP block that implements the EHCI register set, that
> should be good enough. It's not a fast device, so I can put it
> on a non-coherent bus. Since the SoC will be used for networking,
> I'll put the registers into big-endian configuration to make it
> easier for the OS to access. I'm not allowed to have USB-1.1
> according to SBSA, so I can get away without a hub or an extra
> OHCI. I can't support MSI because it's not a PCI device, and
> the GIC is pretty full, so I'll just connect the IRQ line to
> the GPIO controller. In order to do better power management,
> I'll design a fancy PHY that the device driver will manage
> for implementing autosuspend. I should also give the OS
> fine-grained control over the clocks, but it will have to share
> the clock domain with the other devices on the same edge of the
> chip. The EHCI device is not part of PCI, which measn I don't
> have to use the standard SMMU. However, my EHCI implementation
> can only do 32-bit DMA, and I'll have to design my own IOMMU
> to let it access the entire memory range. USB-OTG is a great
> feature and we already paid for having this in our EHCI
> implementation, better make sure it comes up in endpoint mode
> after waking up from power saving.
My money is on the latter. I think non-PCI implementations of xHCI
interfaces will be common. This was certainly the case at Calxeda in
what was believed to be a SBSA compliant SOC. However, I think PCI
device or not is the least of the issues and all the other examples
you list are the difficult ones to deal with.
Rob
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0A7F5.6070201@overkiz.com>
Hello, Mike,
Please do not take this patch: the work of JJ to fix the prog clk
prepare bug
will remove the irq handling from the prog clk driver, as a result, we won't
have to request the irq anymore.
Sorry for the inconvenience.
Best Regards,
Boris
On 04/02/2014 09:42, Boris BREZILLON wrote:
> Hello JJ,
>
> Sorry for the noise (I added Mike in the CC list).
>
> BTW, thanks for fixing this bug.
>
> Mike, could you take this bug fix for the next 3.14 release ?
>
> Best Regards,
>
> Boris
>
> On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
>> The name provided to request_irq() must be valid until the irq is
>> released.
>> This patch stores the name in the internal data structure.
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>> drivers/clk/at91/clk-programmable.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/at91/clk-programmable.c
>> b/drivers/clk/at91/clk-programmable.c
>> index 8e242c7..799b75c 100644
>> --- a/drivers/clk/at91/clk-programmable.c
>> +++ b/drivers/clk/at91/clk-programmable.c
>> @@ -44,6 +44,7 @@ struct clk_programmable {
>> u8 css;
>> u8 pres;
>> u8 slckmck;
>> + char irq_name[11];
>> const struct clk_programmable_layout *layout;
>> };
>> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc
>> *pmc, unsigned int irq,
>> struct clk_programmable *prog;
>> struct clk *clk = NULL;
>> struct clk_init_data init;
>> - char irq_name[11];
>> if (id > PROG_ID_MAX)
>> return ERR_PTR(-EINVAL);
>> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc
>> *pmc, unsigned int irq,
>> prog->irq = irq;
>> init_waitqueue_head(&prog->wait);
>> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
>> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
>> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
>> ret = request_irq(prog->irq, clk_programmable_irq_handler,
>> - IRQF_TRIGGER_HIGH, irq_name, prog);
>> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
>> if (ret)
>> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH 0/3] clk: at91: various fixes and improvements
From: Boris BREZILLON @ 2014-02-04 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-1-git-send-email-b.brezillon@overkiz.com>
Hello, Mike,
Please do not take this series: the prog clk driver is still buggy (this was
reported by Jean-Jacques Hiblot).
Jean-Jacques is preparing a new series to fix these bugs, and I'll rebase
patch 2 and 3 of this series on top of his work.
Sorry for the inconvenience.
Best Regards,
Boris
On 03/02/2014 12:25, Boris BREZILLON wrote:
> Hello Mike,
>
> This series fixes a bug in the prog clk prepare function (the platform hangs
> when preparing a prog clk).
>
> It also implements the determine_rate callback for these prog clks and allow
> system clk to propagate the rate change to its parent.
>
> These modifications are needed to get the atmel_wm8904 driver working (this
> driver make use of prog clks), and if possible, should be merged in the next
> 3.14 release (at least the first patch of this series).
>
> Let me know if this is not possible.
>
> Thanks.
>
> Best Regards,
>
> Boris
>
> Boris BREZILLON (3):
> clk: at91: fix programmable clk irq handling
> clk: at91: replace prog clk round_rate with determine_rate
> clk: at91: propagate rate change on system clks
>
> drivers/clk/at91/clk-programmable.c | 61 ++++++++++++++++++-----------------
> drivers/clk/at91/clk-system.c | 3 +-
> 2 files changed, 34 insertions(+), 30 deletions(-)
>
^ permalink raw reply
* [PATCH 0/6] BCM59056 PMU regulator support
From: Lee Jones @ 2014-02-04 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
> The BCM59056 is a multi-function power management unit used with the
> BCM281xx family of SoCs. This series adds an MFD and voltage regulator
> driver to support the BCM59056. The bcm28155-ap DT support is updated
> to enable use of regulators on the otg and sdhci peripherals.
>
> Matt Porter (6):
> i2c: bcm-kona: register with subsys_initcall
> regulator: add bcm59056 pmu DT binding
> mfd: add bcm59056 pmu driver
> regulator: add bcm59056 regulator driver
> ARM: configs: bcm_defconfig: enable bcm59056 regulator support
> ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
>
> .../devicetree/bindings/regulator/bcm59056.txt | 37 ++
> arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
> arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
> arch/arm/configs/bcm_defconfig | 7 +
> drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
> drivers/mfd/Kconfig | 8 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/bcm59056.c | 119 ++++++
> drivers/regulator/Kconfig | 8 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
> include/linux/mfd/bcm59056.h | 35 ++
> 12 files changed, 873 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
> create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
> create mode 100644 drivers/mfd/bcm59056.c
> create mode 100644 drivers/regulator/bcm59056-regulator.c
> create mode 100644 include/linux/mfd/bcm59056.h
FYI: Mark's email address is not correct. Not sure where you pulled
this one up from, but he doesn't have access to it anymore.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [alsa-devel] [PATCH v3 2/5] ASoC: tda998x: add a codec driver for the TDA998x
From: Lars-Peter Clausen @ 2014-02-04 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204133014.GA22609@sirena.org.uk>
On 02/04/2014 02:30 PM, Mark Brown wrote:
[...]
>
> What does this actually do? No information is being passed in to the
> core function here, not even any information on if it's starting or
> stopping. Looking at the rest of the code I can't help thinking it
> might be clearer to inline this possibly with a lookup helper, the code
> is very small and the lack of parameters makes it hard to follow.
>
>> +static const struct snd_soc_dapm_route tda_routes[] = {
>> + { "hdmi-out", NULL, "HDMI I2S Playback" },
>> + { "hdmi-out", NULL, "HDMI SPDIF Playback" },
>> +};
>
> S/PDIF.
Won't this cause issues with the debugfs widget entries? It's fixable by
escaping it (replace it by a dash or something) in the debugfs widget
filename, but I don't think we do this right now.
- Lars
^ permalink raw reply
* [PATCH v3 2/5] ASoC: tda998x: add a codec driver for the TDA998x
From: Mark Brown @ 2014-02-04 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae68394f080f0ea5acaf3377cb1d18f29e42c646.1391274628.git.moinejf@free.fr>
On Sun, Jan 26, 2014 at 07:45:36PM +0100, Jean-Francois Moine wrote:
> + /* load the optional CODEC */
> + of_platform_populate(np, NULL, NULL, &client->dev);
> +
Why is this using of_platform_populate()? That's a very odd way of
doing things.
> +config SND_SOC_TDA998X
> + tristate
> + depends on OF
> + default y if DRM_I2C_NXP_TDA998X=y
> + default m if DRM_I2C_NXP_TDA998X=m
> +
Make this visible if it can be selected from DT so it can be used with
generic cards.
> +static int tda_get_encoder(struct tda_priv *priv)
> +{
> + struct snd_soc_codec *codec = priv->codec;
> + struct device_node *np;
> +
> + /* get the parent tda998x device */
> + np = of_get_parent(codec->dev->of_node);
> + if (!np || !of_device_is_compatible(np, "nxp,tda998x")) {
> + dev_err(codec->dev, "no or bad parent!\n");
> + return -EINVAL;
> + }
> + priv->i2c_client = of_find_i2c_device_by_node(np);
> + of_node_put(np);
> + return 0;
> +}
Why does this need to be checked like this? We don't normally have this
sort of code to check that the parent is correct.
> +static int tda_start_stop(struct tda_priv *priv)
> +{
> + int port;
> +
> + /* give the audio parameters to the HDMI encoder */
> + if (priv->dai_id == AFMT_I2S)
> + port = priv->ports[0];
> + else
> + port = priv->ports[1];
> + tda998x_audio_update(priv->i2c_client, priv->dai_id, port);
> + return 0;
> +}
What does this actually do? No information is being passed in to the
core function here, not even any information on if it's starting or
stopping. Looking at the rest of the code I can't help thinking it
might be clearer to inline this possibly with a lookup helper, the code
is very small and the lack of parameters makes it hard to follow.
> +static const struct snd_soc_dapm_route tda_routes[] = {
> + { "hdmi-out", NULL, "HDMI I2S Playback" },
> + { "hdmi-out", NULL, "HDMI SPDIF Playback" },
> +};
S/PDIF.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/c0356e5e/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-4-git-send-email-mporter@linaro.org>
> Add a driver for the BCM59056 PMU multi-function device. The driver
> initially supports regmap initialization and instantiation of the
> voltage regulator device function of the PMU.
>
> Signed-off-by: Matt Porter <mporter@linaro.org>
> Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
> Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
> ---
> drivers/mfd/Kconfig | 8 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/bcm59056.h | 35 +++++++++++++
> 4 files changed, 163 insertions(+)
> create mode 100644 drivers/mfd/bcm59056.c
> create mode 100644 include/linux/mfd/bcm59056.h
<snip>
> +static struct mfd_cell bcm59056s[] = {
> + {
> + .name = "bcm59056-pmu",
If you plan to use *->of_node in the PMU driver, which it looks like
you do, you should set the compatible string here.
> + },
> +};
> +
> +static const struct regmap_config bcm59056_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = BCM59056_MAX_REGISTER - 1,
If you've just set this manually i.e. it's not part of an enum table,
can't you set it a value you don't need to do math on? It's not used
anywhere else is it?
> + .cache_type = REGCACHE_RBTREE,
> +};
> +
> +static int bcm59056_i2c_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +{
> + struct bcm59056 *bcm59056;
> + int chip_id = id->driver_data;
I thought this was a DT only driver? If so, you probably want to use
of_match_device() instead.
> + int ret = 0;
> +
> + bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
> + if (!bcm59056)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(i2c, bcm59056);
> + bcm59056->dev = &i2c->dev;
> + bcm59056->i2c_client = i2c;
> + bcm59056->id = chip_id;
> +
> + bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
> + if (IS_ERR(bcm59056->regmap)) {
> + ret = PTR_ERR(bcm59056->regmap);
> + dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = mfd_add_devices(bcm59056->dev, -1,
> + bcm59056s, ARRAY_SIZE(bcm59056s),
> + NULL, 0, NULL);
Are you sure you need all of your #includes?
I notice that irqdomain is there, but you don't actually have one?
> + if (ret < 0)
> + dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
What if we change the name of the function? Probably better to say
something like "device registration failed" or thelike.
> + return ret;
> +}
> +
> +static int bcm59056_i2c_remove(struct i2c_client *i2c)
> +{
> + struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
> +
> + mfd_remove_devices(bcm59056->dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id bcm59056_of_match[] = {
> + { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
You've gone to the trouble of setting a device version here, but you
don't seem to use it?
> + { }
> +};
> +
> +static const struct i2c_device_id bcm59056_i2c_id[] = {
> + { "bcm59056", BCM59056 },
> + { }
> +};
Ah, I guess this is where id->driver comes from.
It's pretty silly that the I2C subsystem demands the presence of this
table, despite not using it if an of_device_id table is present.
> +MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
> +
> +static struct i2c_driver bcm59056_i2c_driver = {
> + .driver = {
> + .name = "bcm59056",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(bcm59056_of_match),
No need to use of_match_ptr() here.
> + },
> + .probe = bcm59056_i2c_probe,
> + .remove = bcm59056_i2c_remove,
> + .id_table = bcm59056_i2c_id,
*grumble*
> +};
> +
> +static int __init bcm59056_init(void)
> +{
> + return i2c_add_driver(&bcm59056_i2c_driver);
> +}
> +subsys_initcall(bcm59056_init);
Really? :(
Maybe you'll want to comment this, in case people do not know the back
ground and attempts to clean it up.
> +static void __exit bcm59056_exit(void)
> +{
> + i2c_del_driver(&bcm59056_i2c_driver);
> +}
> +module_exit(bcm59056_exit);
<snip>
> +/* chip id */
> +#define BCM59056 0
Lonely, oh so lonely!
> +/* max register address */
> +#define BCM59056_MAX_REGISTER 0xe8
Don't you have a table of registers which you care about?
> +/* bcm59056 chip access */
Superfluous comment? Don't we all know what these containers do?
> +struct bcm59056 {
> + struct device *dev;
> + struct i2c_client *i2c_client;
> + struct regmap *regmap;
> + unsigned int id;
> +};
> +
> +#endif /* __LINUX_MFD_BCM59056_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/2] ARM: atomics: implement a better __atomic_add_unless for v6+
From: Will Deacon @ 2014-02-04 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391520525-14903-1-git-send-email-will.deacon@arm.com>
Looking at perf profiles of multi-threaded hackbench runs, a significant
performance hit appears to manifest from the cmpxchg loop used to
implement the 32-bit atomic_add_unless function. This can be mitigated
by writing a direct implementation of __atomic_add_unless which doesn't
require iteration outside of the atomic operation.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/atomic.h | 35 +++++++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 6e410090896e..9a92fd7864a8 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -141,6 +141,33 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
return oldval;
}
+static inline int __atomic_add_unless(atomic_t *v, int a, int u)
+{
+ int oldval, newval;
+ unsigned long tmp;
+
+ smp_mb();
+ prefetchw(&v->counter);
+
+ __asm__ __volatile__ ("@ atomic_add_unless\n"
+"1: ldrex %0, [%4]\n"
+" teq %0, %5\n"
+" beq 2f\n"
+" add %1, %0, %6\n"
+" strex %2, %1, [%4]\n"
+" teq %2, #0\n"
+" bne 1b\n"
+"2:"
+ : "=&r" (oldval), "=&r" (newval), "=&r" (tmp), "+Qo" (v->counter)
+ : "r" (&v->counter), "r" (u), "r" (a)
+ : "cc");
+
+ if (oldval != u)
+ smp_mb();
+
+ return oldval;
+}
+
#else /* ARM_ARCH_6 */
#ifdef CONFIG_SMP
@@ -189,10 +216,6 @@ static inline int atomic_cmpxchg(atomic_t *v, int old, int new)
return ret;
}
-#endif /* __LINUX_ARM_ARCH__ */
-
-#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
-
static inline int __atomic_add_unless(atomic_t *v, int a, int u)
{
int c, old;
@@ -203,6 +226,10 @@ static inline int __atomic_add_unless(atomic_t *v, int a, int u)
return c;
}
+#endif /* __LINUX_ARM_ARCH__ */
+
+#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+
#define atomic_inc(v) atomic_add(1, v)
#define atomic_dec(v) atomic_sub(1, v)
--
1.8.2.2
^ permalink raw reply related
* [PATCH 1/2] ARM: prefetch: add prefetchw invocations for barriered atomics
From: Will Deacon @ 2014-02-04 13:28 UTC (permalink / raw)
To: linux-arm-kernel
After a bunch of benchmarking on the interaction between dmb and pldw,
it turns out that issuing the pldw *after* the dmb instruction can
give modest performance gains (~3% atomic_add_return improvement on a
dual A15).
This patch adds prefetchw invocations to our barriered atomic operations
including cmpxchg, test_and_xxx and futexes.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/include/asm/atomic.h | 9 +++++++++
arch/arm/include/asm/cmpxchg.h | 6 ++++++
arch/arm/include/asm/futex.h | 3 +++
arch/arm/lib/bitops.h | 5 +++++
4 files changed, 23 insertions(+)
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 62d2cb53b069..6e410090896e 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -60,6 +60,7 @@ static inline int atomic_add_return(int i, atomic_t *v)
int result;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic_add_return\n"
"1: ldrex %0, [%3]\n"
@@ -99,6 +100,7 @@ static inline int atomic_sub_return(int i, atomic_t *v)
int result;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic_sub_return\n"
"1: ldrex %0, [%3]\n"
@@ -121,6 +123,7 @@ static inline int atomic_cmpxchg(atomic_t *ptr, int old, int new)
unsigned long res;
smp_mb();
+ prefetchw(&ptr->counter);
do {
__asm__ __volatile__("@ atomic_cmpxchg\n"
@@ -299,6 +302,7 @@ static inline long long atomic64_add_return(long long i, atomic64_t *v)
unsigned long tmp;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic64_add_return\n"
"1: ldrexd %0, %H0, [%3]\n"
@@ -340,6 +344,7 @@ static inline long long atomic64_sub_return(long long i, atomic64_t *v)
unsigned long tmp;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic64_sub_return\n"
"1: ldrexd %0, %H0, [%3]\n"
@@ -364,6 +369,7 @@ static inline long long atomic64_cmpxchg(atomic64_t *ptr, long long old,
unsigned long res;
smp_mb();
+ prefetchw(&ptr->counter);
do {
__asm__ __volatile__("@ atomic64_cmpxchg\n"
@@ -388,6 +394,7 @@ static inline long long atomic64_xchg(atomic64_t *ptr, long long new)
unsigned long tmp;
smp_mb();
+ prefetchw(&ptr->counter);
__asm__ __volatile__("@ atomic64_xchg\n"
"1: ldrexd %0, %H0, [%3]\n"
@@ -409,6 +416,7 @@ static inline long long atomic64_dec_if_positive(atomic64_t *v)
unsigned long tmp;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic64_dec_if_positive\n"
"1: ldrexd %0, %H0, [%3]\n"
@@ -436,6 +444,7 @@ static inline int atomic64_add_unless(atomic64_t *v, long long a, long long u)
int ret = 1;
smp_mb();
+ prefetchw(&v->counter);
__asm__ __volatile__("@ atomic64_add_unless\n"
"1: ldrexd %0, %H0, [%4]\n"
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index df2fbba7efc8..abb2c3769b01 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -2,6 +2,7 @@
#define __ASM_ARM_CMPXCHG_H
#include <linux/irqflags.h>
+#include <linux/prefetch.h>
#include <asm/barrier.h>
#if defined(CONFIG_CPU_SA1100) || defined(CONFIG_CPU_SA110)
@@ -35,6 +36,7 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size
#endif
smp_mb();
+ prefetchw((const void *)ptr);
switch (size) {
#if __LINUX_ARM_ARCH__ >= 6
@@ -138,6 +140,8 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
{
unsigned long oldval, res;
+ prefetchw((const void *)ptr);
+
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
@@ -230,6 +234,8 @@ static inline unsigned long long __cmpxchg64(unsigned long long *ptr,
unsigned long long oldval;
unsigned long res;
+ prefetchw(ptr);
+
__asm__ __volatile__(
"1: ldrexd %1, %H1, [%3]\n"
" teq %1, %4\n"
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index 2aff798fbef4..53e69dae796f 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -23,6 +23,7 @@
#define __futex_atomic_op(insn, ret, oldval, tmp, uaddr, oparg) \
smp_mb(); \
+ prefetchw(uaddr); \
__asm__ __volatile__( \
"1: ldrex %1, [%3]\n" \
" " insn "\n" \
@@ -46,6 +47,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
return -EFAULT;
smp_mb();
+ /* Prefetching cannot fault */
+ prefetchw(uaddr);
__asm__ __volatile__("@futex_atomic_cmpxchg_inatomic\n"
"1: ldrex %1, [%4]\n"
" teq %1, %2\n"
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index 52886b89706c..9f12ed1eea86 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -37,6 +37,11 @@ UNWIND( .fnstart )
add r1, r1, r0, lsl #2 @ Get word offset
mov r3, r2, lsl r3 @ create mask
smp_dmb
+#if __LINUX_ARM_ARCH__ >= 7 && defined(CONFIG_SMP)
+ .arch_extension mp
+ ALT_SMP(W(pldw) [r1])
+ ALT_UP(W(nop))
+#endif
1: ldrex r2, [r1]
ands r0, r2, r3 @ save old value of bit
\instr r2, r2, r3 @ toggle bit
--
1.8.2.2
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Andrew Murray @ 2014-02-04 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204122951.GC27975@e106497-lin.cambridge.arm.com>
On 4 February 2014 12:29, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> On Mon, Feb 03, 2014 at 10:34:40PM +0000, Andrew Murray wrote:
>> On 3 February 2014 18:43, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> > index 4cc813e..ce5bad2 100644
>> > --- a/arch/arm64/include/asm/io.h
>> > +++ b/arch/arm64/include/asm/io.h
>> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> > /*
>> > * I/O port access primitives.
>> > */
>> > +#define arch_has_dev_port() (0)
>> > #define IO_SPACE_LIMIT 0xffff
>> > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
>> >
>> > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
>> > +#define ioport_unmap(addr)
>>
>> I'm not sure that this will work. The in[bwl], out[bwl] macros in
>> arch/arm64/include/asm/io.h already add the PCI_IOBASE offset.
>>
>> Instead of these two #defines, why not just enforce that
>> GENERIC_PCI_IOMAP is enabled? Or at least wrap these defines with 'if
>> (!config_enabled(CONFIG_GENERIC_PCI_IOMAP))' or similar.
>
> GENERIC_PCI_IOMAP *is* enabled for AArch64. We have select GENERIC_IOMAP in
> arch/arm64/Kconfig which in turn selects GENERIC_PCI_IOMAP in lib/Kconfig.
Sorry, it was intent to suggest using the ioport_[map|unmap] functions
in lib/iomap.c instead of defining something similar here. I guess you
will also need to also define CONFIG_HAS_IOPORT for this to happen.
Andrew Murray
>
> Best regards,
> Liviu
>
>>
>> > +
>> > static inline u8 inb(unsigned long addr)
>> > {
>> > return readb(addr + PCI_IOBASE);
>>
>>
>> Andrew Murray
>>
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ?\_(?)_/?
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
>
^ permalink raw reply
* [PATCH v2 3/5] char: ti-usim: Add driver for USIM module on AM43xx
From: Roger Quadros @ 2014-02-04 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390192434-19386-4-git-send-email-satish.patel@ti.com>
Hi Satish,
On 01/20/2014 06:33 AM, Satish Patel wrote:
> TI-USIM driver is a platform driver that provides a character
> driver interface to user applications.
>
> It allows user applications to call IOCTL's to
> perform smart card operations.
>
> Driver currently supports
> - ATR
> - T=0 & T=1 protocol
> - clock stop mode
> - smart card clock configuration
> - Tx/Rx application data units (APDU) to smart card
> - Interface to PHY using DT & phy interface
>
> Validation is done with ACOS3 smart cards
>
> Signed-off-by: Satish Patel <satish.patel@ti.com>
> ---
> .../devicetree/bindings/ti-usim/ti-usim.txt | 31 +
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 1 +
> drivers/char/ti-usim-hw.h | 863 +++++++++
> drivers/char/ti-usim.c | 1859 ++++++++++++++++++++
ti-usim.c is a very large driver that does everything but looks like limited to TI hardware.
How about splitting it into generic stuff and hw specific glue logic so that most of the generic stuff
could be used by different hardware types.
> include/linux/ti-usim.h | 98 +
> 6 files changed, 2859 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt
> create mode 100644 drivers/char/ti-usim-hw.h
> create mode 100644 drivers/char/ti-usim.c
> create mode 100644 include/linux/ti-usim.h
>
cheers,
-roger
^ permalink raw reply
* 'unannotated irqs-on' lockdep warning
From: Uwe Kleine-König @ 2014-02-04 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9NwWdb0fGQTtss2JzXP16jfCJMG6fCkJQBiy6yiOQ5y30kHA@mail.gmail.com>
On Tue, Feb 04, 2014 at 11:02:16AM +0100, Christian Gmeiner wrote:
> Hi
>
> 2014-01-30 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Thu, Jan 30, 2014 at 03:31:46PM +0100, Christian Gmeiner wrote:
> >> [ 19.859234] CPU: 0 PID: 1848 Comm: mkdir Not tainted 3.12.4 #44
> >> [ 19.865190] [<c0013900>] (unwind_backtrace+0x0/0xe0) from
> >> [<c00113b8>] (show_stack+0x10/0x14)
> >> [ 19.873739] [<c00113b8>] (show_stack+0x10/0x14) from [<c044e040>]
> >> (dump_stack+0x64/0xa4)
> >> [ 19.881851] [<c044e040>] (dump_stack+0x64/0xa4) from [<c0022718>]
> >> (warn_slowpath_common+0x64/0x84)
> >> [ 19.890828] [<c0022718>] (warn_slowpath_common+0x64/0x84) from
> >> [<c00227b8>] (warn_slowpath_fmt+0x2c/0x3c)
> >> [ 19.900413] [<c00227b8>] (warn_slowpath_fmt+0x2c/0x3c) from
> >> [<c0076c84>] (check_flags.part.26+0xb4/0x1e4)
> >> [ 19.910001] [<c0076c84>] (check_flags.part.26+0xb4/0x1e4) from
> >> [<c0079654>] (lock_release+0x3c/0x100)
> >> [ 19.919243] [<c0079654>] (lock_release+0x3c/0x100) from
> >> [<c00485b4>] (lg_local_unlock+0x18/0x6c)
> >> [ 19.928055] [<c00485b4>] (lg_local_unlock+0x18/0x6c) from
> >> [<c012a2cc>] (free_fs_struct+0x18/0x30)
> >> [ 19.936947] [<c012a2cc>] (free_fs_struct+0x18/0x30) from
> >> [<c0024e24>] (do_exit+0x2ac/0x3f0)
> >> [ 19.945316] [<c0024e24>] (do_exit+0x2ac/0x3f0) from [<c002501c>]
> >> (do_group_exit+0x88/0xb4)
> >> [ 19.953596] [<c002501c>] (do_group_exit+0x88/0xb4) from
> >> [<c0025058>] (__wake_up_parent+0x0/0x18)
> >> [ 19.962391] ---[ end trace 98a70b5cdc7b49fe ]---
> >> [ 19.967017] possible reason: unannotated irqs-on.
> >> [ 19.971729] irq event stamp: 2910
> >> [ 19.975050] hardirqs last enabled at (2909): [<c044a160>]
> >> __slab_free+0x1c0/0x390
> >> [ 19.982661] hardirqs last disabled at (2910): [<c0456d14>]
> >> __dabt_svc+0x34/0x60
> >
> > So, I wonder how we got from __dabt_svc to __wake_up_parent. It looks
> > like the unwinder has failed to do a proper job of unwinding, which
> > makes this undebuggable.
> >
> > Can you rebuild in ARM mode with frame pointers enabled please?
> >
>
> Maybe i am blind but I can not find that option via make menuconfig. hmmm
config FRAME_POINTER
bool
depends on !THUMB2_KERNEL
default y if !ARM_UNWIND || FUNCTION_GRAPH_TRACER
so disable THUMB2_KERNEL and ARM_UNWIND.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] backlight: add PWM dependencies
From: Linus Walleij @ 2014-02-04 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In some compilations the LM3630A and LP855X backlight drivers
fail like this:
drivers/built-in.o: In function `lm3630a_pwm_ctrl':
drivers/video/backlight/lm3630a_bl.c:168: undefined reference to `pwm_config'
drivers/video/backlight/lm3630a_bl.c:172: undefined reference to `pwm_disable'
drivers/video/backlight/lm3630a_bl.c:170: undefined reference to `pwm_enable'
drivers/built-in.o: In function `lp855x_pwm_ctrl':
drivers/video/backlight/lp855x_bl.c:249: undefined reference to `pwm_config'
drivers/video/backlight/lp855x_bl.c:253: undefined reference to `pwm_disable'
drivers/video/backlight/lp855x_bl.c:251: undefined reference to `pwm_enable'
This is because both drivers depend on the PWM framework, so
add this dependency to their Kconfig entries.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/video/backlight/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5a3eb2ecb525..0604c3348761 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -371,6 +371,7 @@ config BACKLIGHT_AAT2870
config BACKLIGHT_LM3630A
tristate "Backlight Driver for LM3630A"
depends on BACKLIGHT_CLASS_DEVICE && I2C
+ depends on PWM
select REGMAP_I2C
help
This supports TI LM3630A Backlight Driver
@@ -387,6 +388,7 @@ config BACKLIGHT_LM3639
config BACKLIGHT_LP855X
tristate "Backlight driver for TI LP855X"
depends on BACKLIGHT_CLASS_DEVICE && I2C
+ depends on PWM
help
This supports TI LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
LP8557 backlight driver.
--
1.8.5.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox