* [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
* [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] 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] 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 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 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 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] 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] 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: 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
* [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] ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
From: Illia Smyrnov @ 2014-02-05 15:06 UTC (permalink / raw)
To: linux-arm-kernel
Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
softreset bit cleaning right after set one. It is caused L3 error for
OMAP4 ISS because ISS register write occurs when ISS reset process is in
progress. Avoid this situation by cleaning softreset bit later, when reset
process is successfully finished.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 42d8188..1f33f5d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1947,29 +1947,31 @@ static int _ocp_softreset(struct omap_hwmod *oh)
goto dis_opt_clks;
_write_sysconfig(v, oh);
- ret = _clear_softreset(oh, &v);
- if (ret)
- goto dis_opt_clks;
-
- _write_sysconfig(v, oh);
if (oh->class->sysc->srst_udelay)
udelay(oh->class->sysc->srst_udelay);
c = _wait_softreset_complete(oh);
- if (c == MAX_MODULE_SOFTRESET_WAIT)
+ if (c == MAX_MODULE_SOFTRESET_WAIT) {
pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
oh->name, MAX_MODULE_SOFTRESET_WAIT);
- else
+ ret = -ETIMEDOUT;
+ goto dis_opt_clks;
+ } else {
pr_debug("omap_hwmod: %s: softreset in %d usec\n", oh->name, c);
+ }
+
+ ret = _clear_softreset(oh, &v);
+ if (ret)
+ goto dis_opt_clks;
+
+ _write_sysconfig(v, oh);
/*
* XXX add _HWMOD_STATE_WEDGED for modules that don't come back from
* _wait_target_ready() or _reset()
*/
- ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
-
dis_opt_clks:
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
_disable_optional_clocks(oh);
--
1.8.5.3
^ permalink raw reply related
* [PATCH] clk: add strict of_clk_init dependency check
From: Boris BREZILLON @ 2014-02-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F25324.90108@free-electrons.com>
On 05/02/2014 16:05, Gregory CLEMENT wrote:
> 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.
That's fine by me.
>
>> 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;
>>> }
>>>
>>> /**
>>>
>>
>
^ permalink raw reply
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-05 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205090818.GA2614@katana>
On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
>
> > Voltage regulators are needed very early due to deferred probe
> > being incompatible with built-in USB gadget drivers.
>
> What does it need to fix those instead?
[added Alan/Felipe for more insight]
Discussion on that topic came about from this submission:
http://www.spinics.net/lists/linux-usb/msg94217.html
End of it is:
http://www.spinics.net/lists/linux-usb/msg94731.html
We can either add to the many drivers that already do subsys_initcall()
for similar reasons...or I can drop this from the series and add gadget
probe ordering to my TODO list.
In short, it can't be a late_initcall() hack like the original post and
really could be solved by converting to a real bus (and letting
deferred probe do its job)..but Alan voiced concerns about that.
-Matt
^ permalink raw reply
* [PATCH v2 0/5] Split mach-msm into legacy and mach-qcom (multiplatform)
From: Kumar Gala @ 2014-02-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205004732.GB12815@codeaurora.org>
On Feb 4, 2014, at 6:47 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 02/04, Kumar Gala wrote:
>> This is the splits the Qualcomm MSM platform into legacy support that we will
>> not try and convert to multiplatform and multiplatform support.
>>
>> - k
>>
>> Changes from v1:
>> * Added patch to remove hotplug.c
>> * Added patch to rename msm_ to qcom_
>> * Changes the Kconfig to drop CPU_V7
>> * used wfi() in cpu_die function
>> * Added git tree to MAINTAINERS file
>
> What's the plan for this series combined with my SMP series? It
> looks like this isn't based on those patches, so we'll have some
> conflicts with the msm to qcom rename but it should be fairly
> minor.
I?ve rebased the smp patch series on top of this set, so will post the new version short (hopefully once we close on these).
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Matt Porter @ 2014-02-05 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F25122.50400@ti.com>
On Wed, Feb 05, 2014 at 08:56:34AM -0600, Nishanth Menon wrote:
> 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?
Well covered in the original discussion. gcl summarizes options in
https://lkml.org/lkml/2012/11/5/615
Since then, the basic overlay support for the kernel is pretty much a
done deal. It has a wide variety of users (FPGA folks) beyond this board
specific case. The problem you describe about resource management and
conflicts would probably need to be built on top of that. Pantelis
had a PoC implementation with capebus/not-a-capebus but that's not part
of what is being upstreamed. I'm not sure if there's anybody with enough
time out of the Beagleboard community to upstream a resource manager on
top of the basic overlay support that's in progress. However, it might
make a nice GSoC2014 project. :)
-Matt
^ permalink raw reply
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Alan Stern @ 2014-02-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205151826.GC22153@beef>
On Wed, 5 Feb 2014, Matt Porter wrote:
> On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> > On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> >
> > > Voltage regulators are needed very early due to deferred probe
> > > being incompatible with built-in USB gadget drivers.
> >
> > What does it need to fix those instead?
>
> [added Alan/Felipe for more insight]
>
> Discussion on that topic came about from this submission:
> http://www.spinics.net/lists/linux-usb/msg94217.html
>
> End of it is:
> http://www.spinics.net/lists/linux-usb/msg94731.html
>
> We can either add to the many drivers that already do subsys_initcall()
> for similar reasons...or I can drop this from the series and add gadget
> probe ordering to my TODO list.
>
> In short, it can't be a late_initcall() hack like the original post and
> really could be solved by converting to a real bus (and letting
> deferred probe do its job)..but Alan voiced concerns about that.
Don't worry too much about what I said. If adding a "gadget" bus will
solve the problem in an appropriate way, and if nobody else objects
(particularly Felipe, who is on vacation now), then go for it.
Alan Stern
^ permalink raw reply
* [PATCH] ARM: zynq: Move of_clk_init from clock driver
From: Sören Brinkmann @ 2014-02-05 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <572af6e4eaaaa1c74ea62364f8fa7ac5834cc754.1391612175.git.michal.simek@xilinx.com>
On Wed, Feb 05, 2014 at 03:56:37PM +0100, Michal Simek wrote:
> Move of_clk_init() from clock driver to enable
> options not to use zynq clock driver.
> Use for example fixed clock setting.
What is the use-case? Zynq w/o this driver makes no sense, IMHO. And
even if you wanna fake clocks, why would this driver prevent it? Just
replace all the input clocks with different ones and don't care about
what this driver does?
>
> 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);
Now you have two clock init functions...
S?ren
^ permalink raw reply
* [PATCH] mvebu : pcie: dt: potential issue in range parsing
From: Thomas Petazzoni @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389349431-7997-1-git-send-email-jjhiblot@traphandler.com>
Dear Jean-Jacques Hiblot,
On Fri, 10 Jan 2014 11:23:51 +0100, Jean-Jacques Hiblot wrote:
> The second parameter of of_read_number is not the index, but a size.
> As it happens, in this case it may work just fine because of the the conversion
> to u32 and the favorable endianness on this architecture.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> drivers/pci/host/pci-mvebu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index c269e43..877e8ce 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -768,7 +768,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
>
> for (i = 0; i < nranges; i++) {
> u32 flags = of_read_number(range, 1);
> - u32 slot = of_read_number(range, 2);
> + u32 slot = of_read_number(range + 1, 1);
> u64 cpuaddr = of_read_number(range + na, pna);
> unsigned long rtype;
>
Sorry for the long delay, and thanks for the fix!
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(on Armada 370, with PCIe cards plugged in)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.
Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Changes in v4:
- rebased on top of v3.14 +
[patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 48 ++++++++++++++++----
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index b0e98d3..5c97f61 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,6 +37,8 @@ struct davinci_gpio_regs {
u32 intstat;
};
+typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
#define chip2controller(chip) \
@@ -413,6 +415,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -434,6 +456,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
int irq;
+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ gpio_get_irq_chip_cb_t gpio_get_irq_chip;
+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -490,8 +524,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;
@@ -500,10 +532,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -512,7 +543,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
@@ -555,7 +586,8 @@ done:
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: Hans de Goede @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1676482.sbjAhaSLaV@dizzy-6.o2s.ch>
Hi David,
On 02/05/2014 02:01 PM, David Lanzend?rfer wrote:
> Hi Maxime
>> I have four comments here:
>> - Read Documentation/SubmittingPatches, especially Section 5 and 12
>> (hints, you forgot the clock maintainers for your clock patches
>> and you didn't put any signed-off-by tags)
> Oops. I added signed-offs now
>> - You ignored pretty much all the comments that were made during the
>> review of the first version. Go through
> Uh? I just fixed the commits and squashed them together for easier handling.
> I'm even using mmc_of_parse now...
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.
>> html and address the comments that were made.
>> - Each of your patches should compile. Fix the order of your
>> patches.
> Done.
>> - Submit a v3, with the changes you made. Otherwise we have no way
>> of knowing what have been fixed and what didn't
> Too many patches would be bloaty.
> That's why I've squashed them into small and corrected patches.
The squashing is fine, what Maxime means is that normally you would include
a changelog in the coverletter (the [patch 0/x] mail) documenting changes
done since the previous posting of the patchset, so for v3 that would have been
something like:
Changes since v1:
-use mmc_of_parse instead of diy dt parsing
-add nodes for all mmc controller to the dtsi files, including sofar unused
controllers
Changes since v2:
-Add missing Signed-off-by tags
-stop using __raw_readl / __raw_writel so that barriers are properly used
I've probably forgotten a few things, it would be good if you could send
a reply to the:
"[PATCH v3 0/7] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs"
mail with the above changelog, amended with whatever I've forgotten to add
to the above changelog
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: zynq: Move of_clk_init from clock driver
From: Michal Simek @ 2014-02-05 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e03e3ec-2fc7-40fc-a2cc-4a6c64379559@CO1EHSMHS025.ehs.local>
On 02/05/2014 04:41 PM, S?ren Brinkmann wrote:
> On Wed, Feb 05, 2014 at 03:56:37PM +0100, Michal Simek wrote:
>> Move of_clk_init() from clock driver to enable
>> options not to use zynq clock driver.
>> Use for example fixed clock setting.
> What is the use-case? Zynq w/o this driver makes no sense, IMHO. And
> even if you wanna fake clocks, why would this driver prevent it? Just
> replace all the input clocks with different ones and don't care about
> what this driver does?
One case is supervisor for example.
>
>>
>> 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);
> Now you have two clock init functions...
If I have two clock init functions now, what I had before?
You were calling of_clk_init from zynq_clock_init.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/a4179396/attachment.sig>
^ permalink raw reply
* [GIT PULLv3] clk: socfpga: Clean-ups for 3.14
From: Mike Turquette @ 2014-02-05 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389788321-11260-1-git-send-email-dinguyen@altera.com>
Quoting dinguyen at altera.com (2014-01-15 04:18:41)
> Hi Mike,
>
> Please pull in these patches that cleans up the SOCFPGA clock driver. This is
> v3 of the pull request that includes 3 patches from Steffen Trumtrar. I have
> squashed the compiler error fix patch into the patch that introduced the error.
> Bisectability should now be fix.
Thanks for the rework. Can you rebase this onto 3.14-rc1 and send it
again?
Regards,
Mike
>
> Thanks,
> Dinh
>
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga-clk-for-3.14_v3
>
> for you to fetch changes up to 5710d11ab5230dce43e5edc09d9d5506d3d49663:
>
> clk: socfpga: split clk code (2014-01-15 05:56:07 -0600)
>
> ----------------------------------------------------------------
> v3: SOCFPGA clk cleanups for 3.14
>
> ----------------------------------------------------------------
> Dinh Nguyen (3):
> clk: socfpga: Map the clk manager base address in the clock driver
> clk: socfpga: Look for the GPIO_DB_CLK by its offset
> clk: socfpga: Remove socfpga_init_clocks
>
> Steffen Trumtrar (3):
> clk: socfpga: remove unused field
> clk: socfpga: fix define typo
> clk: socfpga: split clk code
>
> arch/arm/mach-socfpga/socfpga.c | 5 -
> drivers/clk/socfpga/Makefile | 3 +
> drivers/clk/socfpga/clk-gate.c | 195 ++++++++++++++++++++++
> drivers/clk/socfpga/clk-periph.c | 94 +++++++++++
> drivers/clk/socfpga/clk-pll.c | 111 +++++++++++++
> drivers/clk/socfpga/clk.c | 328 ++------------------------------------
> drivers/clk/socfpga/clk.h | 57 +++++++
> 7 files changed, 472 insertions(+), 321 deletions(-)
> create mode 100644 drivers/clk/socfpga/clk-gate.c
> create mode 100644 drivers/clk/socfpga/clk-periph.c
> create mode 100644 drivers/clk/socfpga/clk-pll.c
> create mode 100644 drivers/clk/socfpga/clk.h
>
^ permalink raw reply
* [PATCHv9 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"
From: Mike Turquette @ 2014-02-05 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D680E4.6090608@gmail.com>
Quoting Dinh Nguyen (2014-01-15 04:36:52)
> Hi Mike,
>
> Can you apply this to your clk tree?
The patch looks good to me, but I think it depends on your pending pull
request. Can you add this to that pull request and rebase it to
3.14-rc1?
Thanks,
Mike
>
> Thanks,
> Dinh
>
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKVc2fdg1Q+TH6ro9kpJmUYyHw8FCwhORfm2_oj6GYM2Q@mail.gmail.com>
On 02/05/2014 04:39 PM, Rob Herring wrote:
> 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
>
This is h/w design time configurations
--
Regards,
Ivan Khoronzhuk
^ 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