* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Joe Perches @ 2014-02-05 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205142126.GR26684@n2100.arm.linux.org.uk>
On Wed, 2014-02-05 at 14:21 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote:
> > On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote:
> > > On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
> > > > On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
> > > > > On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> > > > > > Apparently, people just convert stupidly large udelay()s
> > > > > > to mdelay and not be bothered.
> > > > >
> > > > > And that's the correct answer. Having udelay(10000) rather than mdelay(10)
> > > > > is a sign that they weren't paying that much attention when writing the
> > > > > code.
> > > >
> > > > Not really.
> > []
> > > > It's not so much not paying attention as not
> > > > knowing ARM is broken for large udelay().
> > >
> > > And now read my suggestion about how to avoid the "not knowing" problem. :)
> >
> > I'd read it already. I didn't and don't disagree.
>
> Please explain /why/ you don't agree.
Please reread what I wrote.
We agree a lot more than you seem to think.
> > I still think adding a #warning on large static udelay()s
> > would be sensible. Maybe adding another option like
> > #define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME
> > guard to avoid seeing the #warning when there's no other
> > option.
>
> How does that help? It's /not/ a warning situation - if you ask for
> udelay(10000) on ARM, you will /not/ get a 10ms delay. You'll instead
> get something much shorter because the arithmetic will overflow.
> Now, you could argue that maybe ARM's udelay() implementation should
> know about this and implement a loop around the underlying udelay()
> implementation to achieve it,
I suggested something like that was possible.
> and I might agree with you - but I
> don't for one very simple reason: we /already/ have such an
> implementation. It's called mdelay():
I think mdelay should be for the case where the range
is too big for a udelay. I think arm's 11 bit range
is unfortunately small.
I think we agree be nice to get a generic compiler
#warning when a __builtin_constant_p value is too large
and a ratelimited dmesg/warning for the runtime case.
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Rob Herring @ 2014-02-05 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205145250.GC28140@mudshark.cambridge.arm.com>
On Wed, Feb 5, 2014 at 8:52 AM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Rob,
>
> On Wed, Feb 05, 2014 at 02:50:29PM +0000, Rob Herring wrote:
>> From: Rob Herring <robh@kernel.org>
>>
>> earlyprintk is broken with 64KB pages. The problem is pgprot_default
>> is not yet initialized when early_io_map is called, so the pte does not
>> get marked as valid. Set the necessary page and access permission bits.
>>
>> Cc: Mark Salter <msalter@redhat.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Rob Herring <robh@kernel.org>
>> ---
>
> I thought we fixed this in 4ce00dfcf19c by reverting the use of
> pgprot_default?
Ah crap. I only checked the history on mmu.c and missed that fix. And
I was so happy I found a kernel issue with qemu.
Rob
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Gregory CLEMENT @ 2014-02-05 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F24F4F.8000901@free-electrons.com>
On 05/02/2014 15:48, Gregory CLEMENT wrote:
> Hi Boris,
>
> On 05/02/2014 10:48, Boris BREZILLON wrote:
>> The parent dependency check is only available on the first parent of a given
>> clk.
>>
>> Add support for strict dependency check: all parents of a given clk must be
>> initialized.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>
>> Hello Gregory,
>>
>> This patch adds support for strict check on clk dependencies (check if all
>> parents specified by an DT clk node are initialized).
>>
>> I'm not sure this is what you were expecting (maybe testing the first parent
>> is what you really want), so please feel free to tell me if I'm wrong.
>>
>> Best Regards,
>>
>> Boris
>>
>> drivers/clk/clk.c | 27 +++++++++++++++++++++------
>> 1 file changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index beb0f8b..6849769 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
>> {
>> struct of_phandle_args clkspec;
>> struct of_clk_provider *provider;
>> + int num_parents;
>> + bool found;
>> + int i;
>>
>> /*
>> * If there is no clock parent, no need to wait for them, then
>> * we can consider their absence as being ready
>> */
>> - if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
>> - &clkspec))
>> + num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>> + if (num_parents <= 0)
>> return 1;
>>
>> - /* Check if we have such a provider in our array */
>> - list_for_each_entry(provider, &of_clk_providers, link) {
>> - if (provider->node == clkspec.np)
>> + for (i = 0; i < num_parents; i++) {
>> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
>> + &clkspec))
>> return 1;
>> +
>> + /* Check if we have such a provider in our array */
>> + found = false;
>> + list_for_each_entry(provider, &of_clk_providers, link) {
>> + if (provider->node == clkspec.np) {
>> + found = true;
>> + break;
>
> Hum this means that as soon as you have one parent then you consider it
> as ready. It is better of what I have done because I only test the 1st
> parent. However I wondered if we should go further by ensuring all the
> parents are ready.
My bad, I read the code too fast. Your code already checks that all the
parents are ready.
So if you agree I will merge your code with mine and send a new patch.
>
> If I am right, there is more than one parent only for the muxer. In this
> case is it really expected that all the parent are ready?
>
> Thanks,
>
> Gregory
>
>> + }
>> + }
>> +
>> + if (!found)
>> + return 0;
>> }
>>
>> - return 0;
>> + return 1;
>> }
>>
>> /**
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Mark Salter @ 2014-02-05 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391611829-7824-1-git-send-email-robherring2@gmail.com>
On Wed, 2014-02-05 at 08:50 -0600, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> earlyprintk is broken with 64KB pages. The problem is pgprot_default
> is not yet initialized when early_io_map is called, so the pte does not
> get marked as valid. Set the necessary page and access permission bits.
>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>
FWIW, I had a patch in my early_ioremap series which initialized
pgprot_default earlier in boot:
http://www.spinics.net/lists/arm-kernel/msg299656.html
(which reminds me to get v4 of that series out this week)
^ permalink raw reply
* [PATCH 03/18] arm64: boot protocol documentation update for GICv3
From: Catalin Marinas @ 2014-02-05 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391607050-540-4-git-send-email-marc.zyngier@arm.com>
On Wed, Feb 05, 2014 at 01:30:35PM +0000, Marc Zyngier wrote:
> Linux has some requirements that must be satisfied in order to boot
> on a system built with a GICv3.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
There are some patches I haven't acked in this series, so here it goes:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v4 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Mark Brown @ 2014-02-05 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391605507-30981-4-git-send-email-maxime.ripard@free-electrons.com>
On Wed, Feb 05, 2014 at 02:05:05PM +0100, Maxime Ripard wrote:
> The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
> SoCs.
Looks good - applied, thanks!
-------------- 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/20140205/85418d03/attachment.sig>
^ permalink raw reply
* [PATCH 13/18] mfd: max77836: Add max77836 support to max14577 driver
From: Krzysztof Kozlowski @ 2014-02-05 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203102213.GL13529@lee--X1>
On Mon, 2014-02-03 at 10:22 +0000, Lee Jones wrote:
> On Tue, 28 Jan 2014, Krzysztof Kozlowski wrote:
>
> > Add Maxim 77836 support to max14577 driver. The chipsets have same MUIC
> > component so the extcon, charger and regulators are almost the same. The
> > max77836 however has also PMIC and Fuel Gauge.
> >
> > The MAX77836 uses three I2C slave addresses and has additional interrupts
> > (related to PMIC and Fuel Gauge). It has also Interrupt Source register,
> > just like MAX77686 and MAX77693.
> >
> > The MAX77836 PMIC's TOPSYS and INTSRC interrupts are reported in the
> > PMIC block. The PMIC block has different I2C slave address and uses own
> > regmap so another regmap_irq_chip is needed.
> >
> > Since we have two regmap_irq_chip, use shared interrupts on MAX77836.
> >
> > This patch adds additional defines and functions to the max14577 MFD core
> > driver so the driver will handle both chipsets.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/mfd/max14577.c | 215 ++++++++++++++++++++++++++++++++--
> > include/linux/mfd/max14577-private.h | 85 +++++++++++++-
> > include/linux/mfd/max14577.h | 7 +-
> > 3 files changed, 296 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/mfd/max14577.c b/drivers/mfd/max14577.c
> > index 224aba8c5b3f..5b10f6f89834 100644
> > --- a/drivers/mfd/max14577.c
> > +++ b/drivers/mfd/max14577.c
> > @@ -1,7 +1,7 @@
> > /*
> > - * max14577.c - mfd core driver for the Maxim 14577
> > + * max14577.c - mfd core driver for the Maxim 14577/77836
>
> We may wish to consider changing the name of this file at a later
> date.
I agree, maybe "maxim-pmic.c"? The 14577 is a MUIC/charger, 77836 is a
MUIC/charger/mini-PMIC. However other max-like chipsets (77693, 77686)
have full PMIC capabilities, so the name change could be introduced when
support for these devices would be added.
> > - * Copyright (C) 2013 Samsung Electrnoics
> > + * Copyright (C) 2013,2014 Samsung Electrnoics
>
> You can remove the the '2013' completely now.
Shouldn't it contain the date of first publication?
> > * Chanwoo Choi <cw00.choi@samsung.com>
> > * Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > *
> > @@ -37,11 +37,31 @@ static struct mfd_cell max14577_devs[] = {
> > { .name = "max14577-charger", },
> > };
> >
> > +static struct mfd_cell max77836_devs[] = {
> > + {
> > + .name = "max77836-muic",
> > + .of_compatible = "maxim,max77836-muic",
> > + },
> > + {
> > + .name = "max77836-regulator",
> > + .of_compatible = "maxim,max77836-regulator",
> > + },
> > + { .name = "max77836-charger", },
>
> Why doesn't the charger require a compatible string?
Currently the charger driver doesn't use DT and does not require it. The
device type is taken from parent's MFD of_compatible.
I'll add the compatible anyway because but during review of other
charger patch it was pointed that the charger should be configurable.
>
> > + {
> > + .name = "max77836-battery",
> > + .of_compatible = "maxim,max77836-battery",
> > + },
> > +};
> > +
> > @@ -56,6 +76,29 @@ static bool max14577_muic_volatile_reg(struct device *dev, unsigned int reg)
> > return false;
> > }
> >
> > +static bool max77836_muic_volatile_reg(struct device *dev, unsigned int reg)
> > +{
> > + /* Any max14577 volatile registers are also max77836 volatile. */
> > + if (max14577_muic_volatile_reg(dev, reg))
> > + return true;
>
> New line here please.
OK
>
> > + switch (reg) {
> > + case MAX77836_FG_REG_VCELL_MSB ... MAX77836_FG_REG_SOC_LSB:
> > + case MAX77836_FG_REG_CRATE_MSB ... MAX77836_FG_REG_CRATE_LSB:
> > + case MAX77836_FG_REG_STATUS_H ... MAX77836_FG_REG_STATUS_L:
> > + /* fall through */
>
> It's okay not to have these here. We know how switch statements
> work. ;)
Checkpatch complained about lack of this...
> > + case MAX77836_PMIC_REG_INTSRC:
> > + /* fall through */
> > + case MAX77836_PMIC_REG_TOPSYS_INT:
> > + /* fall through */
> > + case MAX77836_PMIC_REG_TOPSYS_STAT:
> > + return true;
> > + default:
> > + break;
> > + }
> > + return false;
> > +}
> > +
> > +
>
> Superfluous new line here.
OK
> > +static const struct regmap_irq_chip max77836_muic_irq_chip = {
> > + .name = "max77836-muic",
> > + .status_base = MAXIM_MUIC_REG_INT1,
> > + .mask_base = MAXIM_MUIC_REG_INTMASK1,
> > + .mask_invert = 1,
>
> I'd prefer the use of 'true' or 'false' for bools.
OK
> > + .num_regs = 3,
> > + .irqs = max77836_muic_irqs,
> > + .num_irqs = ARRAY_SIZE(max77836_muic_irqs),
> > +};
> > +
>
> <snip>
>
> > +static const struct regmap_irq_chip max77836_pmic_irq_chip = {
> > + .name = "max77836-pmic",
> > + .status_base = MAX77836_PMIC_REG_TOPSYS_INT,
> > + .mask_base = MAX77836_PMIC_REG_TOPSYS_INT_MASK,
> > + .mask_invert = 0,
>
> 'false' please.
OK
> > + .num_regs = 1,
> > + .irqs = max77836_pmic_irqs,
> > + .num_irqs = ARRAY_SIZE(max77836_pmic_irqs),
> > +};
> > +
>
> <snip>
>
> > +static int max77836_init(struct maxim_core *maxim_core)
> > +{
> > + int ret;
> > + u8 intsrc_mask;
> > +
> > + maxim_core->i2c_pmic = i2c_new_dummy(maxim_core->i2c->adapter,
> > + I2C_ADDR_PMIC);
> > + if (!maxim_core->i2c_pmic) {
> > + dev_err(maxim_core->dev, "Failed to register PMIC I2C device\n");
> > + return -EPERM;
>
> Not sure this is the best errno to return.
>
> Perhaps -ENODEV would be more suitable?
Hmmm... I am not sure. The i2c_new_dummy() returns NULL when:
- kzalloc fails,
- I2C address is wrong (EINVAL),
- I2C device is busy,
- device_add fails.
For me none of them matches but I don't mind returning ENODEV.
> <snip>
>
> > #define MAXIM_STATUS2_CHGTYP_MASK (0x7 << MAXIM_STATUS2_CHGTYP_SHIFT)
> > #define MAXIM_STATUS2_CHGDETRUN_MASK (0x1 << MAXIM_STATUS2_CHGDETRUN_SHIFT)
> > #define MAXIM_STATUS2_DCDTMR_MASK (0x1 << MAXIM_STATUS2_DCDTMR_SHIFT)
> > #define MAXIM_STATUS2_DBCHG_MASK (0x1 << MAXIM_STATUS2_DBCHG_SHIFT)
> > #define MAXIM_STATUS2_VBVOLT_MASK (0x1 << MAXIM_STATUS2_VBVOLT_SHIFT)
> > +#define MAX77836_STATUS2_VIDRM_MASK (0x1 << MAX77836_STATUS2_VIDRM_SHIFT)
>
> It's up to you, but all of these "0x1 <<"s can be replaced with the
> BIT() macro if you so wished.
OK
>
> > /* MAX14577 STATUS3 register */
> > #define MAXIM_STATUS3_EOC_SHIFT 0
> > @@ -232,6 +242,70 @@ enum maxim_muic_charger_type {
> >
> >
> >
>
> Do all of these extra new lines really exist, or is it just a patch
> thing? If they do, can you get rid of them please?
Sure.
> > +/* Slave addr = 0x46: PMIC */
> > +enum max77836_pmic_reg {
> > + MAX77836_COMP_REG_COMP1 = 0x60,
> > +
> > + MAX77836_LDO_REG_CNFG1_LDO1 = 0x51,
> > + MAX77836_LDO_REG_CNFG2_LDO1 = 0x52,
> > + MAX77836_LDO_REG_CNFG1_LDO2 = 0x53,
> > + MAX77836_LDO_REG_CNFG2_LDO2 = 0x54,
> > + MAX77836_LDO_REG_CNFG_LDO_BIAS = 0x55,
> > +
> > + MAX77836_PMIC_REG_PMIC_ID = 0x20,
> > + MAX77836_PMIC_REG_PMIC_REV = 0x21,
> > + MAX77836_PMIC_REG_INTSRC = 0x22,
> > + MAX77836_PMIC_REG_INTSRC_MASK = 0x23,
> > + MAX77836_PMIC_REG_TOPSYS_INT = 0x24,
> > + MAX77836_PMIC_REG_TOPSYS_INT_MASK = 0x26,
> > + MAX77836_PMIC_REG_TOPSYS_STAT = 0x28,
> > + MAX77836_PMIC_REG_MRSTB_CNTL = 0x2A,
> > + MAX77836_PMIC_REG_LSCNFG = 0x2B,
> > +
> > + MAX77836_PMIC_REG_END,
> > +};
>
> Any reason why these aren't in numerical order?
I'll fix this.
>
> <snip>
>
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Catalin Marinas @ 2014-02-05 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LRH.2.02.1402060100590.24936@tundra.namei.org>
On Wed, Feb 05, 2014 at 02:02:22PM +0000, James Morris wrote:
> On Wed, 5 Feb 2014, Catalin Marinas wrote:
>
> > On Tue, Feb 04, 2014 at 02:15:32AM +0000, Colin Cross wrote:
> > > Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
> > > selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
> > > prevent selinux failures launching 32-bit static executables that
> > > are mapped at 0x8000.
> > >
> > > Signed-off-by: Colin Cross <ccross@android.com>
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Acked-by: James Morris <james.l.morris@oracle.com>
>
> Probably makes sense to push this through the arm tree.
With your ack, I'm happy to take it ;)
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] ARM: zynq: Move of_clk_init from clock driver
From: Michal Simek @ 2014-02-05 14:56 UTC (permalink / raw)
To: linux-arm-kernel
Move of_clk_init() from clock driver to enable
options not to use zynq clock driver.
Use for example fixed clock setting.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Based on http://www.spinics.net/lists/arm-kernel/msg298287.html
series
---
arch/arm/mach-zynq/common.c | 1 +
drivers/clk/zynq/clkc.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 93ea19b..8df35f3 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -68,6 +68,7 @@ static void __init zynq_timer_init(void)
zynq_early_slcr_init();
zynq_clock_init();
+ of_clk_init(NULL);
clocksource_of_init();
}
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index 03052d6..c812b93 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -602,8 +602,6 @@ void __init zynq_clock_init(void)
of_node_put(slcr);
of_node_put(np);
- of_clk_init(NULL);
-
return;
np_err:
--
1.8.2.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/55aa2bd7/attachment.sig>
^ permalink raw reply related
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Nishanth Menon @ 2014-02-05 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205143800.GB22153@beef>
On 02/05/2014 08:38 AM, Matt Porter wrote:
> On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote:
>> On 02/05/2014 07:48 AM, Jack Mitchell wrote:
[...]
>>> + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
>>> + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
>>> + * @@ -73,6 +74,6 @@
>>> + * pinctrl-names = "default", "off";
>>> + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
>>> + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
>>> + * - status = "okay";
>>> + * + status = "disabled";
>>> + * };
>>> + * };
>>> + */
>>> +
>> how about making the audio-cape-reva.dts which includes and overrides
>> parameters of boneblack.dts?
>
> Yeah, that might be a little cleaner. Black makes things unfortunately
> messy for these capes that were really intended for BBW :(
yes indeed - we might have to live with more dts in such a case.
>
>> Further, I see a bunch of capes in
>> http://elinux.org/Beagleboard:BeagleBone_Capes
>>
>> Assuming that we dont want to discuss capebus all over again, is this
>> the approach we'd like to consider in the interim?
>
> I think that's a fair assumption...I'll note that there is work slowly
> in progress on a very minimal implementation DT overlays upstream. But
> that doesn't exist. We are simply interested in a sane way to use the
> hardware we own in mainline and this approach makes it possible to build
> a kernel+dtb from mainline that works for this configuration. If
> there's a better way to support this hardware *today* let's discuss it.
> One of the big benefits to having this upstream is that it's no longer
> out of sight out of mind. It should be managed alongside all the other
> am335x dts data.
>
> Incidentally, I'm hoping to contribute a similar patch for the DVI cape
> I have here.
If I am not mistaken, the capes are stackable (within reason), and are
not exactly hotpluggable.. question pops up as to how do we handle
multiple cape descriptions on the same board without having the user
to create custom dts which includes each relevant cape dts he has on
his/her bone? I wonder(without proper research, just thinking aloud)
if u-boot can do some sort of merge of dtbs - assuming ofcourse eeprom
data is used to detect the capes plugged on board?
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Catalin Marinas @ 2014-02-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205145250.GC28140@mudshark.cambridge.arm.com>
On Wed, Feb 05, 2014 at 02:52:51PM +0000, Will Deacon wrote:
> On Wed, Feb 05, 2014 at 02:50:29PM +0000, Rob Herring wrote:
> > From: Rob Herring <robh@kernel.org>
> >
> > earlyprintk is broken with 64KB pages. The problem is pgprot_default
> > is not yet initialized when early_io_map is called, so the pte does not
> > get marked as valid. Set the necessary page and access permission bits.
> >
> > Cc: Mark Salter <msalter@redhat.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
>
> I thought we fixed this in 4ce00dfcf19c by reverting the use of
> pgprot_default?
Indeed. We still need to fix the ioremap_cache() case where the
shareability isn't set but I haven't yet decided what we do for
SMP-on-UP in arm64 (if we always assume SMP, I would just get rid of
pgprot_default entirely).
--
Catalin
^ permalink raw reply
* v3.14-rc1 locking bug in system suspend
From: Shawn Guo @ 2014-02-05 14:54 UTC (permalink / raw)
To: linux-arm-kernel
I start seeing the following locking bug on IMX6 with suspend operation
after moving to v3.14-rc1. Before I start looking into the issue, I
would like to confirm if it's an IMX specific problem or one seen on
other platforms. Please ask if you need more info.
Shawn
root at arm:~# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e624 removed
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
PM: Entering mem sleep
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1849 Comm: bash Not tainted 3.14.0-rc1+ #1648
Backtrace:
[<80012144>] (dump_backtrace) from [<800122e4>] (show_stack+0x18/0x1c)
r6:808c48a0 r5:00000000 r4:00000000 r3:00000000
[<800122cc>] (show_stack) from [<80637ac0>] (dump_stack+0x78/0x94)
[<80637a48>] (dump_stack) from [<80064fa0>] (__lock_acquire+0x18f4/0x1ce0)
r4:00000002 r3:bda3f200
[<800636ac>] (__lock_acquire) from [<80065894>] (lock_acquire+0x68/0x7c)
r10:bd906000 r9:bda3f200 r8:00000000 r7:00000000 r6:60000013 r5:bd906000
r4:00000000
[<8006582c>] (lock_acquire) from [<8063c938>] (mutex_lock_nested+0x5c/0x3b8)
r7:00000000 r6:80dfc78c r5:804be444 r4:bf122928
[<8063c8dc>] (mutex_lock_nested) from [<804be444>] (snd_soc_suspend+0x34/0x42c)
r10:00000000 r9:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:be8fd150
r4:be8fd010
[<804be410>] (snd_soc_suspend) from [<8034392c>] (platform_pm_suspend+0x34/0x64)
r10:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:803438f8 r4:bf1c4410
[<803438f8>] (platform_pm_suspend) from [<80348e18>] (dpm_run_callback.isra.7+0x34/0x6c)
[<80348de4>] (dpm_run_callback.isra.7) from [<80349354>] (__device_suspend+0x10c/0x220)
r9:808dd974 r8:808c4a5c r6:00000002 r5:80e5001c r4:bf1c4410
[<80349248>] (__device_suspend) from [<8034a338>] (dpm_suspend+0x60/0x220)
r7:bf1c4410 r6:808dd90c r5:80e5001c r4:bf1c44c0
[<8034a2d8>] (dpm_suspend) from [<8034a790>] (dpm_suspend_start+0x60/0x68)
r10:8079a818 r9:00000000 r8:00000004 r7:80dfbe90 r6:80641eec r5:00000000
r4:00000002
[<8034a730>] (dpm_suspend_start) from [<8006a788>] (suspend_devices_and_enter+0x74/0x318)
r4:00000003 r3:80dfbe98
[<8006a714>] (suspend_devices_and_enter) from [<8006abd8>] (pm_suspend+0x1ac/0x244)
r10:8079a818 r8:00000004 r7:00000003 r6:80641eec r5:00000000 r4:00000003
[<8006aa2c>] (pm_suspend) from [<80069a4c>] (state_store+0x70/0xc0)
r5:00000003 r4:be9c7680
[<800699dc>] (state_store) from [<80294034>] (kobj_attr_store+0x1c/0x28)
r10:bd99cb88 r8:00000000 r7:bd907f78 r6:be9c7680 r5:00000004 r4:bd99cb80
[<80294018>] (kobj_attr_store) from [<80140f90>] (sysfs_kf_write+0x54/0x58)
[<80140f3c>] (sysfs_kf_write) from [<8014474c>] (kernfs_fop_write+0xc4/0x160)
r6:be9c7680 r5:bd99cb80 r4:00000004 r3:80140f3c
[<80144688>] (kernfs_fop_write) from [<800dfa14>] (vfs_write+0xbc/0x184)
r10:00000000 r9:00000000 r8:00000000 r7:bd907f78 r6:00281c08 r5:00000004
r4:bda1bd00
[<800df958>] (vfs_write) from [<800dfe00>] (SyS_write+0x48/0x70)
r10:00000000 r8:00000000 r7:00000004 r6:00281c08 r5:00000000 r4:bda1bd00
[<800dfdb8>] (SyS_write) from [<8000e800>] (ret_fast_syscall+0x0/0x48)
r9:bd906000 r8:8000e9c4 r7:00000004 r6:00281c08 r5:00000004 r4:76f575e0
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=2104 jiffies, g=576, c=575, q=2)
Task dump for CPU 0:
bash R running 0 1849 1848 0x00000002
Backtrace:
[<80065894>] (lock_acquire) from [<80061410>] (trace_hardirqs_off+0x14/0x18)
Backtrace aborted due to bad frame pointer <bd907b3c>
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=8424 jiffies, g=576, c=575, q=3)
Task dump for CPU 0:
bash R running 0 1849 1848 0x00000002
Backtrace:
[<80065894>] (lock_acquire) from [<80061410>] (trace_hardirqs_off+0x14/0x18)
Backtrace aborted due to bad frame pointer <bd907b3c>
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Will Deacon @ 2014-02-05 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391611829-7824-1-git-send-email-robherring2@gmail.com>
Hi Rob,
On Wed, Feb 05, 2014 at 02:50:29PM +0000, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> earlyprintk is broken with 64KB pages. The problem is pgprot_default
> is not yet initialized when early_io_map is called, so the pte does not
> get marked as valid. Set the necessary page and access permission bits.
>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
I thought we fixed this in 4ce00dfcf19c by reverting the use of
pgprot_default?
Will
^ permalink raw reply
* [PATCH v4 1/5] clk: sunxi: Add support for PLL6 on the A31
From: Mike Turquette @ 2014-02-05 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391605507-30981-2-git-send-email-maxime.ripard@free-electrons.com>
Quoting Maxime Ripard (2014-02-05 05:05:03)
> The A31 has a slightly different PLL6 clock. Add support for this new clock in
> our driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good to me.
Regards,
Mike
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 45 +++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c2cb762..954845c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -11,6 +11,7 @@ Required properties:
> "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> "allwinner,sun4i-pll5-clk" - for the PLL5 clock
> "allwinner,sun4i-pll6-clk" - for the PLL6 clock
> + "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
> "allwinner,sun4i-axi-clk" - for the AXI clock
> "allwinner,sun4i-axi-gates-clk" - for the AXI gates
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index abb6c5a..0c05c2d 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32 parent_rate,
> *n = DIV_ROUND_UP(div, (*k+1));
> }
>
> +/**
> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
> + * PLL6 rate is calculated as follows
> + * rate = parent_rate * n * (k + 1) / 2
> + * parent_rate is always 24Mhz
> + */
> +
> +static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
> + u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> + u8 div;
> +
> + /*
> + * We always have 24MHz / 2, so we can just say that our
> + * parent clock is 12MHz.
> + */
> + parent_rate = parent_rate / 2;
> +
> + /* Normalize value to a parent_rate multiple (24M / 2) */
> + div = *freq / parent_rate;
> + *freq = parent_rate * div;
> +
> + /* we were called to round the frequency, we can now return */
> + if (n == NULL)
> + return;
> +
> + *k = div / 32;
> + if (*k > 3)
> + *k = 3;
>
> + *n = DIV_ROUND_UP(div, (*k+1));
> +}
>
> /**
> * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> @@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
> .kwidth = 2,
> };
>
> +static struct clk_factors_config sun6i_a31_pll6_config = {
> + .nshift = 8,
> + .nwidth = 5,
> + .kshift = 4,
> + .kwidth = 2,
> +};
> +
> static struct clk_factors_config sun4i_apb1_config = {
> .mshift = 0,
> .mwidth = 5,
> @@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data __initconst = {
> .getter = sun4i_get_pll5_factors,
> };
>
> +static const struct factors_data sun6i_a31_pll6_data __initconst = {
> + .enable = 31,
> + .table = &sun6i_a31_pll6_config,
> + .getter = sun6i_a31_get_pll6_factors,
> +};
> +
> static const struct factors_data sun4i_apb1_data __initconst = {
> .table = &sun4i_apb1_config,
> .getter = sun4i_get_apb1_factors,
> @@ -972,6 +1016,7 @@ free_clkdata:
> static const struct of_device_id clk_factors_match[] __initconst = {
> {.compatible = "allwinner,sun4i-pll1-clk", .data = &sun4i_pll1_data,},
> {.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
> + {.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
> {.compatible = "allwinner,sun4i-apb1-clk", .data = &sun4i_apb1_data,},
> {.compatible = "allwinner,sun4i-mod0-clk", .data = &sun4i_mod0_data,},
> {.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
> --
> 1.8.4.2
>
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Rob Herring @ 2014-02-05 14:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
earlyprintk is broken with 64KB pages. The problem is pgprot_default
is not yet initialized when early_io_map is called, so the pte does not
get marked as valid. Set the necessary page and access permission bits.
Cc: Mark Salter <msalter@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
I'm not sure this is really the best fix. Perhaps pgprot_default can be
statically initialized to something useful instead?
Rob
arch/arm64/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f557ebb..c41daa6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -284,7 +284,7 @@ void __iomem * __init early_io_map(phys_addr_t phys, unsigned long virt)
if (pmd_none(*pmd))
return NULL;
pte = pte_offset_kernel(pmd, virt);
- set_pte(pte, __pte((phys & mask) | PROT_DEVICE_nGnRE));
+ set_pte(pte, __pte((phys & mask) | PTE_TYPE_PAGE | PTE_AF | PROT_DEVICE_nGnRE));
} else {
set_pmd(pmd, __pmd((phys & mask) | PROT_SECT_DEVICE_nGnRE));
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH] clk: Fix notifier documentation
From: Mike Turquette @ 2014-02-05 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c0808b4-aac3-4add-a5dd-1a69ee815f4b@CO9EHSMHS003.ehs.local>
Quoting S?ren Brinkmann (2014-02-03 08:36:57)
> On Fri, Jan 31, 2014 at 10:01:27PM -0800, Mike Turquette wrote:
> > On Fri, Jan 31, 2014 at 5:49 PM, S?ren Brinkmann
> > <soren.brinkmann@xilinx.com> wrote:
> > > ping?
> >
> > Hi Soren,
> >
> > I'm a bit slow to review patches during the merge window. Thanks for
> > the doc update. I'll take it in after -rc1 drops.
>
> Sorry for my impatience. Thank you!
Taken into clk-next.
Regards,
Mike
>
> S?ren
>
>
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Gregory CLEMENT @ 2014-02-05 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391593680-9388-1-git-send-email-b.brezillon@overkiz.com>
Hi Boris,
On 05/02/2014 10:48, Boris BREZILLON wrote:
> The parent dependency check is only available on the first parent of a given
> clk.
>
> Add support for strict dependency check: all parents of a given clk must be
> initialized.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>
> Hello Gregory,
>
> This patch adds support for strict check on clk dependencies (check if all
> parents specified by an DT clk node are initialized).
>
> I'm not sure this is what you were expecting (maybe testing the first parent
> is what you really want), so please feel free to tell me if I'm wrong.
>
> Best Regards,
>
> Boris
>
> drivers/clk/clk.c | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index beb0f8b..6849769 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
> {
> struct of_phandle_args clkspec;
> struct of_clk_provider *provider;
> + int num_parents;
> + bool found;
> + int i;
>
> /*
> * If there is no clock parent, no need to wait for them, then
> * we can consider their absence as being ready
> */
> - if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
> - &clkspec))
> + num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> + if (num_parents <= 0)
> return 1;
>
> - /* Check if we have such a provider in our array */
> - list_for_each_entry(provider, &of_clk_providers, link) {
> - if (provider->node == clkspec.np)
> + for (i = 0; i < num_parents; i++) {
> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
> + &clkspec))
> return 1;
> +
> + /* Check if we have such a provider in our array */
> + found = false;
> + list_for_each_entry(provider, &of_clk_providers, link) {
> + if (provider->node == clkspec.np) {
> + found = true;
> + break;
Hum this means that as soon as you have one parent then you consider it
as ready. It is better of what I have done because I only test the 1st
parent. However I wondered if we should go further by ensuring all the
parents are ready.
If I am right, there is more than one parent only for the muxer. In this
case is it really expected that all the parent are ready?
Thanks,
Gregory
> + }
> + }
> +
> + if (!found)
> + return 0;
> }
>
> - return 0;
> + return 1;
> }
>
> /**
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Fabio Estevam @ 2014-02-05 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-15-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 1:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> +static int nmk_i2c_runtime_resume(struct device *dev)
> +{
> + struct amba_device *adev = to_amba_device(dev);,
> + struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
> +
> + clk_prepare_enable(nmk_i2c->clk);
Previously the code was checking the return value from
clk_prepare_enable(). You should keep the check here.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Mike Turquette @ 2014-02-05 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15127900.Wy8QsPfEr8@avalon>
Quoting Laurent Pinchart (2014-02-05 02:31:41)
> Mike,
>
> Ping ?
>
> v3.14-rc1 is out, and those are bug fixes.
>
> On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> > On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > > Geert, could you please verify that the series fixes your QSPI clock
> > > > issues with the Koelsch board ?
> > > >
> > > > Laurent Pinchart (2):
> > > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > > clk: shmobile: rcar-gen2: Fix qspi divisor
> > >
> > > Thanks, both:
> > >
> > > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thank you.
> >
> > Mike, could you please pick those patches up for v3.14 ?
Taken into clk-fixes.
Thanks!
Mike
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Rob Herring @ 2014-02-05 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391608060-10760-3-git-send-email-ivan.khoronzhuk@ti.com>
On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
> This patch provides bindings for the 64-bit timer in the KeyStone
> architecture devices. The timer can be configured as a general-purpose 64-bit
> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or independently
> (unchained mode) of each other.
This is software configurable or h/w design time configurations?
Rob
>
> It is global timer is a free running up-counter and can generate interrupt
> when the counter reaches preset counter values.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> .../bindings/timer/ti,keystone-timer.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> new file mode 100644
> index 0000000..5fbe361
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> @@ -0,0 +1,29 @@
> +* Device tree bindings for Texas instruments Keystone timer
> +
> +This document provides bindings for the 64-bit timer in the KeyStone
> +architecture devices. The timer can be configured as a general-purpose 64-bit
> +timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> +timers, each half can operate in conjunction (chain mode) or independently
> +(unchained mode) of each other.
> +
> +It is global timer is a free running up-counter and can generate interrupt
> +when the counter reaches preset counter values.
> +
> +Documentation:
> +http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
> +
> +Required properties:
> +
> +- compatible : should be "ti,keystone-timer".
> +- reg : specifies base physical address and count of the registers.
> +- interrupts : interrupt generated by the timer.
> +- clocks : the clock feeding the timer clock.
> +
> +Example:
> +
> +timer at 22f0000 {
> + compatible = "ti,keystone-timer";
> + reg = <0x022f0000 0x80>;
> + interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clktimer15>;
> +};
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Matt Porter @ 2014-02-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F2460C.3080908@ti.com>
On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote:
> On 02/05/2014 07:48 AM, Jack Mitchell wrote:
> > From: Jack Mitchell <jack@embed.me.uk>
> >
> > Devicetree include file for setting up the am335x mcasp bus, i2c-2
> > bus, and audio codec required for a functioning BeagleBone Audio Cape.
> >
> > Signed-off-by: Jack Mitchell <jack@embed.me.uk>
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > ---
> > arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +++++++++++++++++++++
> > arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
> > 2 files changed, 138 insertions(+)
> > create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> > new file mode 100644
> > index 0000000..b8ec3dc
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> > @@ -0,0 +1,124 @@
> > +/*
> > + * Copyright (C) 2014 Jack Mitchell <jack@embed.me.uk>
> > + *
> > + * 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.
> > + *
> > + * In order to enable the BeagleBone Audio Cape this dtsi must be
> > + * incuded in the top level dts. On BeagleBone Black hardware the
> > + * status of the HDMI dts node must also be set to "disabled".
> > + *
> > + * --- a/arch/arm/boot/dts/am335x-bone.dts
> > + * +++ b/arch/arm/boot/dts/am335x-bone.dts
> > + * @@ -9,6 +9,7 @@
> > + *
> > + * #include "am33xx.dtsi"
> > + * #include "am335x-bone-common.dtsi"
> > + * +#include "am335x-bone-audio-cape-reva.dtsi"
> > + *
> > + * &ldo3_reg {
> > + * regulator-min-microvolt = <1800000>;
> > + *
> > + * On BeagleBone Black hardware the status of the HDMI dts node must
> > + * also be set to "disabled"
> > + *
> > + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
> > + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> > + * @@ -73,6 +74,6 @@
> > + * pinctrl-names = "default", "off";
> > + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> > + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> > + * - status = "okay";
> > + * + status = "disabled";
> > + * };
> > + * };
> > + */
> > +
> how about making the audio-cape-reva.dts which includes and overrides
> parameters of boneblack.dts?
Yeah, that might be a little cleaner. Black makes things unfortunately
messy for these capes that were really intended for BBW :(
> Further, I see a bunch of capes in
> http://elinux.org/Beagleboard:BeagleBone_Capes
>
> Assuming that we dont want to discuss capebus all over again, is this
> the approach we'd like to consider in the interim?
I think that's a fair assumption...I'll note that there is work slowly
in progress on a very minimal implementation DT overlays upstream. But
that doesn't exist. We are simply interested in a sane way to use the
hardware we own in mainline and this approach makes it possible to build
a kernel+dtb from mainline that works for this configuration. If
there's a better way to support this hardware *today* let's discuss it.
One of the big benefits to having this upstream is that it's no longer
out of sight out of mind. It should be managed alongside all the other
am335x dts data.
Incidentally, I'm hoping to contribute a similar patch for the DVI cape
I have here.
-Matt
^ permalink raw reply
* [PATCH 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Linus Walleij @ 2014-02-05 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-15-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Since the device is active while a successful probe has been completed,
> the reference counting for the clock will be screwed up and never reach
> zero.
>
> The issue is resolved by implementing runtime PM callbacks and let them
> handle the resources accordingly, including the clock.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Hm do I read it right as patch 13 breaks runtime PM by leaving
the device active after probe() and this patch
14 fixes it again? Maybe these two patches should be squashed
then.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 11/17] i2c: nomadik: Convert to devm functions
From: Linus Walleij @ 2014-02-05 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-12-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Use devm_* functions to simplify code and error handling.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
However make sure this (and the rest) applies on top of this patch:
http://marc.info/?l=linux-i2c&m=139142325809973&w=2
Because I expect that to be applied first.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-02-05 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205064150.GA31568@gmail.com>
[Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>] On 05/02/2014 (Wed 07:41) Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Ingo,
> >
> > On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > So, if you meant Linus to pull it, you probably want to cite a real
> > > Git URI along the lines of:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
> >
> > Paul provided the proper git url further down in the mail along with the
> > usual pull request message (I guess he should have put that bit at the
> > top).
>
> Yeah, indeed, and it even comes with a signed tag, which is an extra
> nice touch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git tags/init-cleanup
>
> (I guess the https was mentioned first to lower expectations.)
Just to clarify, the init.git was the repo of raw commits+series file
that was used for testing on linux next; now useless, except for showing
the last several weeks of history (hence the visual http link). The
signed tag [separate repo] is the application of those commits against
the 3.14-rc1 tag, which was the end goal from the beginning.
Does history matter? In the case of a cleanup like this, it does only
in the immediate context of this pull request; to help distinguish this
work from some short lived half baked idea that also had its testing
invalidated by arbitrarily rebasing onto the latest shiny tag.
I wouldn't have even mentioned the patch repo, except for the fact that
I know how Linus loves arbitrary rebases [and malformed pull requests] :)
Thanks,
Paul.
--
>
> Thanks,
>
> Ingo
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Russell King - ARM Linux @ 2014-02-05 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391608993.2538.74.camel@joe-AO722>
On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote:
> On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
> > > On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> > > > > Apparently, people just convert stupidly large udelay()s
> > > > > to mdelay and not be bothered.
> > > >
> > > > And that's the correct answer. Having udelay(10000) rather than mdelay(10)
> > > > is a sign that they weren't paying that much attention when writing the
> > > > code.
> > >
> > > Not really.
> []
> > > It's not so much not paying attention as not
> > > knowing ARM is broken for large udelay().
> >
> > And now read my suggestion about how to avoid the "not knowing" problem. :)
>
> I'd read it already. I didn't and don't disagree.
Please explain /why/ you don't agree.
> I still think adding a #warning on large static udelay()s
> would be sensible. Maybe adding another option like
> #define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME
> guard to avoid seeing the #warning when there's no other
> option.
How does that help? It's /not/ a warning situation - if you ask for
udelay(10000) on ARM, you will /not/ get a 10ms delay. You'll instead
get something much shorter because the arithmetic will overflow.
Now, you could argue that maybe ARM's udelay() implementation should
know about this and implement a loop around the underlying udelay()
implementation to achieve it, and I might agree with you - but I
don't for one very simple reason: we /already/ have such an
implementation. It's called mdelay():
#ifndef mdelay
#define mdelay(n) (\
(__builtin_constant_p(n) && (n)<=MAX_UDELAY_MS) ? udelay((n)*1000) : \
({unsigned long __ms=(n); while (__ms--) udelay(1000);}))
#endif
So, the right answer is /not/ do duplicate this, but to /use/ the
appropriate facilities provided by the kernel.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox