* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Peter Maydell @ 2013-01-21 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dfd76d65ce8e16c6792a47262d27dda2@localhost>
On 21 January 2013 18:08, Marc Zyngier <marc.zyngier@arm.com> wrote:
> I still have hope for QEMU to move forward and eventually generate a DT
> based on the host capabilities.
We might improve our "modify the DT the user passed us" code, but
I don't currently anticipate "generate a DT from scratch". In
my experience using anything other that the DT which came from
the same tree as the kernel itself is just asking for the kernel
to crash with some really obscure and unhelpful error message,
so QEMU generating a DT is just going to result in a pile of
bugs on the QEMU list where users say "new kernel doesn't boot"...
-- PMM
^ permalink raw reply
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Thomas Abraham @ 2013-01-21 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121121353.GH15707@e106331-lin.cambridge.arm.com>
Hi Mark,
On 21 January 2013 04:13, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Thomas,
>
> This looks really useful, and it's going to conflict with my arch_timer /
> arm_generic driver unification series [1].
>
> I'm happy to take this as part of my series if that's ok with you?
Sure, that's fine. This patch would probably be needed in 3.9 on
Exynos platforms. So you could squash this change into your series.
Thanks,
Thomas.
>
> On Mon, Jan 21, 2013 at 01:22:06AM +0000, Thomas Abraham wrote:
>> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
>> discoverable using call to clocksource_of_init.
>>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> arch/arm/kernel/arch_timer.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
>> index c8ef207..d21aada 100644
>> --- a/arch/arm/kernel/arch_timer.c
>> +++ b/arch/arm/kernel/arch_timer.c
>> @@ -504,6 +504,9 @@ int __init arch_timer_of_register(void)
>>
>> return arch_timer_register();
>> }
>> +#ifdef CONFIG_CLKSRC_OF
>> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer", arch_timer_of_register)
>> +#endif
>>
>> int __init arch_timer_sched_clock_init(void)
>> {
>> --
>> 1.7.5.4
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/142070.html
>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Richard Cochran @ 2013-01-21 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121164510.GA18905@kahuna>
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
> for MMC filesystem - we need the edma series. for a ramdisk, I am able
> to boot up to shell with 3.8-rc4 tag
Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Thanks,
Richard
^ permalink raw reply
* [kvmarm] [PATCH v6 14/15] KVM: ARM: Power State Coordination Interface implementation
From: Christoffer Dall @ 2013-01-21 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dfd76d65ce8e16c6792a47262d27dda2@localhost>
On Mon, Jan 21, 2013 at 1:08 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Mon, 21 Jan 2013 12:54:22 -0500, Christoffer Dall
> <c.dall@virtualopensystems.com> wrote:
>> On Mon, Jan 21, 2013 at 12:43 PM, Marc Zyngier <marc.zyngier@arm.com>
>> wrote:
>>> On Mon, 21 Jan 2013 09:50:18 -0500, Christoffer Dall
>>> <c.dall@virtualopensystems.com> wrote:
>>>> On Mon, Jan 21, 2013 at 5:04 AM, Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>>> On Sun, 20 Jan 2013 18:35:51 -0500, Christoffer Dall
>>>>> <c.dall@virtualopensystems.com> wrote:
>>>>>> On Thu, Jan 17, 2013 at 10:55 AM, Marc Zyngier
> <marc.zyngier@arm.com>
>>>>>> wrote:
>>>>>>> On 16/01/13 17:59, Christoffer Dall wrote:
>>>>>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>>>
>>>>>>>> Implement the PSCI specification (ARM DEN 0022A) to control
>>>>>>>> virtual CPUs being "powered" on or off.
>>>>>>>>
>>>>>>>> PSCI/KVM is detected using the KVM_CAP_ARM_PSCI capability.
>>>>>>>>
>>>>>>>> A virtual CPU can now be initialized in a "powered off" state,
>>>>>>>> using the KVM_ARM_VCPU_POWER_OFF feature flag.
>>>>>>>>
>>>>>>>> The guest can use either SMC or HVC to execute a PSCI function.
>>>>>>>>
>>>>>>>> Reviewed-by: Will Deacon <will.deacon@arm.com>
>>>>>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>>>>> Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
>>>>>>>
>>>>>>> A few bits went wrong when you reworked this patch. See below.
>>>>>
>>>>> [...]
>>>>>
>>>>>>>> @@ -443,13 +445,17 @@ static int handle_hvc(struct kvm_vcpu *vcpu,
>>>>>>>> struct kvm_run *run)
>>>>>>>> trace_kvm_hvc(*vcpu_pc(vcpu), *vcpu_reg(vcpu, 0),
>>>>>>>> vcpu->arch.hsr & HSR_HVC_IMM_MASK);
>>>>>>>>
>>>>>>>> + if (kvm_psci_call(vcpu))
>>>>>>>> + return 1;
>>>>>>>> +
>>>>>>>> return 1;
>>>>>>>
>>>>>>> No undef injection if there is no PSCI match?
>>>>>
>>>>> You haven't addressed this issue in you patch.
>>>>>
>>>> right, well, it's actually quite nice not having it give you an
>>>> undefined exception when it logs the trace event. The psci protocol
>>>> relies on a confirmation in form of a return value anyhow, so it was
>>>> actually on purpose to remove it, so you can do things like easily
>>>> measure exit times or probe places in the guest.
>>>
>>> If that's for tracing purpose, why don't you allocate another
> hypercall?
>>> Returning to the guest without signalling that nothing was executed
> seems
>>> very wrong to me.
>>>
>> hmm, yeah, maybe you're right.
>>
>> I was just debating with myself whether an undefined isn't too rough.
>> It made sense when we didn't have any kind of handling of hvc, but now
>> an hvc isn't really an undefined instruction, and if we assume that we
>> have a series of hypercalls, multiplexed by a number in r0, but you
>> don't really know what's available on your VM host, it also seems very
>> wrong to have an ABI that says, try it, and if it's not implemented
>> handle the undefined exception.... Know what I mean? perhaps we should
>> return -1 in r0 instead or something.
>
> Aside from the API discovery discussion, my thoughts on the HVC semantics:
> The way I see it, HVC effectively becomes an undefined instruction if the
> upper layer doesn't know about the requested service. This is very
> different from "I know what you mean, but I can't do it now". We should
> really tell the guest "I have no clue what you're talking about", because
> something is utterly wrong. This is a case of not being able to give the VM
> the semantics it expects, and trying to paper over it.
>
> Now, returning something in r0 could have been a possibility if it was
> specified in the ARM ARM, and it is not. So we can already forget about it.
>
well if you use an HVC instruction, you're no longer relying on the
ARM ARM concerning the effects of such an instruction, you're relying
on the assumption of a hyper call ABI that we're discussing right now.
And I think that's an important discussion.
If they way forward is, tell the guest which HVCs are available and if
you do anything else than this we're going to shoot you with an undef,
ok, but for an ABI to inform the guest of an unavailable hypercall,
even though the call was valid on some other host, I think that's
equally awful and something we wish to avoid.
Anyway, in no way high priority and at this point it's probably safer
that we yell than ignore it in silence, so I'm going to put the undef
back right away, I just figured the discussion was important, as I
said.
-Christoffer
^ permalink raw reply
* [PATCH] OMAP: omap4-panda: add UART2 muxing for WiLink shared transport
From: Tony Lindgren @ 2013-01-21 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358766852-24503-1-git-send-email-coelho@ti.com>
* Luciano Coelho <coelho@ti.com> [130121 03:18]:
> Add the UART2 muxing data to the board file (this used to be,
> erroneously, done in the bootloader).
>
> Cc: stable <stable@vger.kernel.org> [3.7]
> Signed-off-by: Luciano Coelho <coelho@ti.com>
Thanks applying into omap-for-v3.8-rc4/fixes.
Regards,
Tony
> ---
> arch/arm/mach-omap2/board-omap4panda.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
> index 5c8e9ce..769c1fe 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -397,6 +397,12 @@ static struct omap_board_mux board_mux[] __initdata = {
> OMAP_PULL_ENA),
> OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>
> + /* UART2 - BT/FM/GPS shared transport */
> + OMAP4_MUX(UART2_CTS, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_RTS, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
> + OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
> +
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
>
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: apply the errata at run time rather
From: Tony Lindgren @ 2013-01-21 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121131613.GA29876@bnru10>
* srinidhi kasagar <srinidhi.kasagar@stericsson.com> [130121 05:19]:
Forgot to complete the subject and add the description?
Regards,
Tony
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> ---
> arch/arm/mach-omap2/sleep44xx.S | 25 +++++++++++++++++++++----
> 1 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index 88ff83a..071ca1f 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -157,11 +157,19 @@ skip_scu_gp_set:
> ldrne r0, [r8, #L2X0_SAVE_OFFSET1] @ memory.
> cmp r0, #3
> bne do_WFI
> -#ifdef CONFIG_PL310_ERRATA_727915
> + /* Check for PL310_ERRATA_727915 */
> + bl l2x0_get_rtl_release
> + cmp r0, #0x4
> + beq dosmc
> + cmp r0, #0x5
> + beq dosmc
> + b nosmc
> +dosmc:
> mov r0, #0x03
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> -#endif
> +
> +nosmc:
> bl omap4_get_l2cache_base
> mov r2, r0
> ldr r0, =0xffff
> @@ -171,11 +179,20 @@ wait:
> ldr r1, =0xffff
> ands r0, r0, r1
> bne wait
> -#ifdef CONFIG_PL310_ERRATA_727915
> +
> + /* Check for PL310_ERRATA_727915 */
> + bl l2x0_get_rtl_release
> + cmp r0, #0x4
> + beq dosmc2
> + cmp r0, #0x5
> + beq dosmc2
> + b nosmc2
> +dosmc2:
> mov r0, #0x00
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> -#endif
> +
> +nosmc2:
> l2x_sync:
> bl omap4_get_l2cache_base
> mov r2, r0
> --
> 1.7.2.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 6/6] clocksource: update and move armada-370-xp-timer documentation to timer directory
From: Arnd Bergmann @ 2013-01-21 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-7-git-send-email-gregory.clement@free-electrons.com>
On Monday 21 January 2013, Gregory CLEMENT wrote:
> +
> +Required properties:
> +- compatible: Should be "marvell,armada-370-xp-timer"
> +- interrupts: Should contain the list of Global Timer interrupts and
> + then local timer interrupts
> +- reg: Should contain location and length for timers register. First
> + pair for the Global Timer registers, second pair for the
> + local/private timers.
> +- clocks: clock driving the timer hardware
> +
> +Optional properties:
> +- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
> + Mhz fixed mode (available on Armada XP and not on Armada 370)
This works fine, but I would consider it slightly cleaner to kill
the marvell,timer-25Mhz property and instead have separate
marvell,armada-370-timer and marvell,armada-xp-timer compatible
strings, since the two timers are actually different, rather than wired
differently.
Arnd
^ permalink raw reply
* IMX not ready for multiplatform?
From: Sascha Hauer @ 2013-01-21 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121133835.GI23505@n2100.arm.linux.org.uk>
On Mon, Jan 21, 2013 at 01:38:35PM +0000, Russell King - ARM Linux wrote:
> drivers/usb/gadget/imx_udc.c:39:27: fatal error: mach/hardware.h: No such file or directory
> drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
>
> is rather suggestive in my OMAP4 randconfig build.
>
> Might like to have this fixed before the next merge window, so we don't
> cause regressions.
This is being worked on by Peter Chen (CCed), see
[PATCH v7 0/3] Fix the Build error for fsl_mxc_udc.c
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Matt Porter @ 2013-01-21 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f36acfaf128c4844b8f696ea4440e253@DLEE74.ent.ti.com>
On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote:
> On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
> > for MMC filesystem - we need the edma series. for a ramdisk, I am able
> > to boot up to shell with 3.8-rc4 tag
>
> Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Do you use appended dtb? The only different that jumped out at me first
Paul's reported hang is he uses appended dtb and I boot my boards with a
single uImage and multiple dtbs the traditional DT way.
-Matt
^ permalink raw reply
* [PATCH] mc13892: sanity check num_regulators parsed vs. registered
From: Matt Sealey @ 2013-01-21 18:25 UTC (permalink / raw)
To: linux-arm-kernel
Imagine a situation where a device tree has a few regulators in an
appropriate node:
regulators {
sw1 {
..
};
vvideo {
..
};
:
vfake {
..
};
vtypo {
..
};
};
In the above example, the node name "vfake" is an attempt to match a
regulator name inside the driver which just so happens to not exist. The
node name "vtypo" represents an accidental typographical error in a
regulator name which may have been introduced to a device tree.
In these cases, the number of regulators the mc13892 driver thinks it has
does not match the number of regulators it parsed and registered. Since
it will go over this array based on this number, it will actually
re-register regulator "0" (which happens to be SW1) over and over
again until it reaches the number, resulting in messages on the kernel
log such as these:
SW1: at 1100 mV
VVIDEO: at 2775mV
:
SW1: at 1100 mV
SW1: at 1100 mV
.. up to that number of "mismatched" regulators. Nobody using DT can/will
consume these regulators, so it should not be possible for it to cause any
real regulator problems or driver breakages, but it is an easy thing to
miss in a kernel log and is an immediate indication of a problem with the
device tree authoring.
This patch effectively sanity checks the number of counted children of
the regulators node vs. the number that actually matched driver names,
and sets the appropriate num_regulators value. It also gives a little
warning for device tree authors that they MAY have screwed something up,
such that this patch does not hide the device tree authoring problem.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
Tested-by: Steev Klimaszewski <steev@genesi-usa.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/regulator/mc13892-regulator.c | 39 ++++++++++++++++++++++++++--
drivers/regulator/mc13xxx-regulator-core.c | 10 +++++--
drivers/regulator/mc13xxx.h | 4 +--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/mc13892-regulator.c b/drivers/regulator/mc13892-regulator.c
index e4f2197..7c86040 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -535,15 +535,18 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
struct mc13xxx_regulator_init_data *mc13xxx_data;
struct regulator_config config = { };
int i, ret;
- int num_regulators = 0;
+ int num_regulators = 0, num_parsed;
u32 val;
num_regulators = mc13xxx_get_num_regulators_dt(pdev);
+
if (num_regulators <= 0 && pdata)
num_regulators = pdata->num_regulators;
if (num_regulators <= 0)
return -EINVAL;
+ num_parsed = num_regulators;
+
priv = devm_kzalloc(&pdev->dev, sizeof(*priv) +
num_regulators * sizeof(priv->regulators[0]),
GFP_KERNEL);
@@ -586,7 +589,39 @@ static int mc13892_regulator_probe(struct platform_device *pdev)
= mc13892_vcam_get_mode;
mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13892_regulators,
- ARRAY_SIZE(mc13892_regulators));
+ ARRAY_SIZE(mc13892_regulators),
+ &num_parsed);
+
+ /*
+ * Perform a little sanity check on the regulator tree - if we found
+ * a number of regulators from mc13xxx_get_num_regulators_dt and
+ * then parsed a smaller number in mc13xxx_parse_regulators_dt then
+ * there is a regulator defined in the regulators node which has
+ * not matched any usable regulator in the driver. In this case,
+ * there is one missing and what will happen is the first regulator
+ * will get registered again.
+ *
+ * Fix this by basically making our number of registerable regulators
+ * equal to the number of regulators we parsed. We are allocating
+ * too much memory for priv, but this is unavoidable at this point.
+ *
+ * As an example of how this can happen, try making a typo in your
+ * regulators node (vviohi {} instead of viohi {}) so that the name
+ * does not match..
+ *
+ * The check will basically pass for platform data (non-DT) because
+ * mc13xxx_parse_regulators_dt for !CONFIG_OF will not touch num_parsed.
+ *
+ */
+ if (num_parsed != num_regulators) {
+ dev_warn(&pdev->dev,
+ "parsed %d != regulators %d - check your device tree!\n",
+ num_parsed, num_regulators);
+
+ num_regulators = num_parsed;
+ priv->num_regulators = num_regulators;
+ }
+
for (i = 0; i < num_regulators; i++) {
struct regulator_init_data *init_data;
struct regulator_desc *desc;
diff --git a/drivers/regulator/mc13xxx-regulator-core.c b/drivers/regulator/mc13xxx-regulator-core.c
index 4ed89c6..2ecf1d8 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -181,12 +181,14 @@ EXPORT_SYMBOL_GPL(mc13xxx_get_num_regulators_dt);
struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
struct platform_device *pdev, struct mc13xxx_regulator *regulators,
- int num_regulators)
+ int num_regulators, int *num_parsed)
{
struct mc13xxx_regulator_priv *priv = platform_get_drvdata(pdev);
struct mc13xxx_regulator_init_data *data, *p;
struct device_node *parent, *child;
- int i;
+ int i, parsed = 0;
+
+ *num_parsed = 0;
of_node_get(pdev->dev.parent->of_node);
parent = of_find_node_by_name(pdev->dev.parent->of_node, "regulators");
@@ -203,16 +205,20 @@ struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
for (i = 0; i < num_regulators; i++) {
if (!of_node_cmp(child->name,
regulators[i].desc.name)) {
+
p->id = i;
p->init_data = of_get_regulator_init_data(
&pdev->dev, child);
p->node = child;
p++;
+
+ parsed++;
break;
}
}
}
+ *num_parsed = parsed;
return data;
}
EXPORT_SYMBOL_GPL(mc13xxx_parse_regulators_dt);
diff --git a/drivers/regulator/mc13xxx.h b/drivers/regulator/mc13xxx.h
index 06c8903..007f833 100644
--- a/drivers/regulator/mc13xxx.h
+++ b/drivers/regulator/mc13xxx.h
@@ -39,7 +39,7 @@ extern int mc13xxx_fixed_regulator_set_voltage(struct regulator_dev *rdev,
extern int mc13xxx_get_num_regulators_dt(struct platform_device *pdev);
extern struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
struct platform_device *pdev, struct mc13xxx_regulator *regulators,
- int num_regulators);
+ int num_regulators, int *num_parsed);
#else
static inline int mc13xxx_get_num_regulators_dt(struct platform_device *pdev)
{
@@ -48,7 +48,7 @@ static inline int mc13xxx_get_num_regulators_dt(struct platform_device *pdev)
static inline struct mc13xxx_regulator_init_data *mc13xxx_parse_regulators_dt(
struct platform_device *pdev, struct mc13xxx_regulator *regulators,
- int num_regulators)
+ int num_regulators, int *num_parsed)
{
return NULL;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Marc Zyngier @ 2013-01-21 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD7904.1070201@wwwdotorg.org>
On Mon, 21 Jan 2013 10:21:08 -0700, Stephen Warren <swarren@wwwdotorg.org>
wrote:
> On 01/20/2013 06:22 PM, Thomas Abraham wrote:
>> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
>> discoverable using call to clocksource_of_init.
>
>> diff --git a/arch/arm/kernel/arch_timer.c
b/arch/arm/kernel/arch_timer.c
>
>> +#ifdef CONFIG_CLKSRC_OF
>> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer",
>> arch_timer_of_register)
>> +#endif
>
> I wonder if we shouldn't enhance include/linux/clocksource.h to define
> CLOCKSOURCE_OF_DECLARE even when !CONFIG_CLKSRC_OF; that way, drivers
> wouldn't need that ifdef.
Indeed. That would be a lot nicer.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [PATCH 1/2] net: fec: refactor dt probing
From: Sascha Hauer @ 2013-01-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121174824.GA27956@sapphire.tkos.co.il>
On Mon, Jan 21, 2013 at 07:48:26PM +0200, Baruch Siach wrote:
> Hi Sascha,
>
> On Mon, Jan 21, 2013 at 09:37:54AM +0100, Sascha Hauer wrote:
> > For devicetree parsing only the fec_get_phy_mode_dt() is
> > available. Rename it to fec_probe_dt() to be able to add more devicetree
> > parsing to it.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
>
> [...]
>
> > -static int fec_get_phy_mode_dt(struct platform_device *pdev)
> > +static int fec_probe_dt(struct fec_enet_private *fep)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > + struct device_node *np = fep->pdev->dev.of_node;
> >
> > - if (np)
> > - return of_get_phy_mode(np);
> > + if (!np)
> > + return -ENODEV;
> > +
> > + fep->phy_interface = of_get_phy_mode(np);
> >
> > return -ENODEV;
>
> Maybe return fep->phy_interface?
No, but indeed this should return successfully. I will rework this after
it's clear how we want to proceed with this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [GIT PULL] ARM: OMAP: some clock/hwmod fixes for v3.8-rc
From: Tony Lindgren @ 2013-01-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301211557530.8450@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [130121 08:04]:
> Hi Tony,
>
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>
> Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-v3.8-rc
>
> for you to fetch changes up to bdcc61275232db897ba831f87a16df98ab248571:
>
> ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls (2013-01-18 16:48:16 -0700)
>
> ----------------------------------------------------------------
> A few OMAP integration fixes for v3.8-rc, for OMAP4 audio and OMAP2 reboot.
>
> Basic test logs are available here:
>
> http://www.pwsan.com/omap/testlogs/prcm_fixes_c_v3.8-rc/20130121073904/
Thanks pulling into omap-for-v3.8-rc4/fixes.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq serial changes for v3.9
From: Greg Kroah-Hartman @ 2013-01-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3dJGHK7nO2tx_kUWLwhpgNsCwtnjXAJnRFUOHVx2uE589Q@mail.gmail.com>
On Mon, Jan 21, 2013 at 06:19:03PM +0100, Michal Simek wrote:
> Hi Arnd, Olof and Greg,
>
> I have two patches for xilinx uartps serial driver (the second one fix
> one issue in the first one).
> These patches has been sent to arm mailing list and also to
> device-tree mailing list.
>
> There is a change in zynq dtsi that's why I think it can go through
> arm-soc tree.
> Please let me know if this should go through Greg serial tree.
If they fix serial driver issues, I have no problem taking them through
my serial tree, just send them on as patches and I will be glad to queue
them up.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ARM: architected timers: allow dt based discovery using clocksource_of_init
From: Thomas Abraham @ 2013-01-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FD7904.1070201@wwwdotorg.org>
Hi Stephen,
On 21 January 2013 09:21, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/20/2013 06:22 PM, Thomas Abraham wrote:
>> Add an entry in __clksrc_of_table so that ARMv7 architected timer is
>> discoverable using call to clocksource_of_init.
>
>> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
>
>> +#ifdef CONFIG_CLKSRC_OF
>> +CLOCKSOURCE_OF_DECLARE(armv7_timer, "arm,armv7-timer", arch_timer_of_register)
>> +#endif
>
> I wonder if we shouldn't enhance include/linux/clocksource.h to define
> CLOCKSOURCE_OF_DECLARE even when !CONFIG_CLKSRC_OF; that way, drivers
> wouldn't need that ifdef.
Yes, it will be helpful to have a !CONFIG_CLKSRC_OF version of
CLOCKSOURCE_OF_DECLARE. And can CONFIG_CLKSRC_OF be enabled by default
for all ARM platforms?
Thanks,
Thomas.
^ permalink raw reply
* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Arnd Bergmann @ 2013-01-21 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358790842-2986-4-git-send-email-gregory.clement@free-electrons.com>
On Monday 21 January 2013, Gregory CLEMENT wrote:
> @@ -1624,7 +1624,7 @@ config LOCAL_TIMERS
> bool "Use local timer interrupts"
> depends on SMP
> default y
> - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> + select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)
>
Your change is fine, but I just noticed that this line is asking for trouble
when we enable multipleform support for MSM and/or EXYNOS.
Also, I wonder if we should change this somehow in 3.8, because it seems
that for a multiplatform kernel including armadaxp and e.g. versatile express,
you have no ARM_TWD support in the kernel, which seems wrong. Is there any
reason we can't enable the ARM_TWD code to be built-in on platforms that
don't use it?
Maybe it can be written as
config LOCAL_TIMERS
bool "Use local timer interrupts"
depends on SMP
default y
config HAVE_ARM_TWD
depends on LOCAL_TIMERS
default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
default y
This will still be slightly wrong (generating extra code) on a multiplatform
kernel that has no platform other than MSM or EXYNOS, but the other alternative
would be that each platform with TWD support has to select HAVE_ARM_TWD itself.
Arnd
^ permalink raw reply
* [PATCH] ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
From: Tony Lindgren @ 2013-01-21 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358774834-32463-1-git-send-email-peter.ujfalusi@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [130121 05:30]:
> The pin in question is muxed between GPIO7 and PWM1. For backlight control
> there is a custom code in board-zoom-display to control the backlight.
> No need to request the GPIO7 - which was failing since the way it is
> requested no longer valid: twl's gpio range is allocated dynamically.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> Hi Tony,
>
> This patch is generated on top of my previous series for audio/pwm support:
> http://www.spinics.net/lists/linux-omap/msg85085.html
Can you do a pull request for me for all the arch/arm/*omap* parts
against v3.8-rc4 for the v3.9 merge window?
That way you can also merge the same branch into ASoC tree if needed
as long as you keep your arch/arm/*omap* branch immutable.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
From: Tony Lindgren @ 2013-01-21 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALF0-+VOxtsfQLZCGujvjMrsGacbfVTMytRUX=CfKa3+FgnU1w@mail.gmail.com>
* Ezequiel Garcia <elezegarcia@gmail.com> [130121 09:00]:
> Hi Mark,
>
> On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > [...]
> >
> >> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> >> index 01ce462..f7de9eb 100644
> >> --- a/arch/arm/mach-omap2/gpmc.c
> >> +++ b/arch/arm/mach-omap2/gpmc.c
> >> @@ -39,6 +39,7 @@
> >> #include "omap_device.h"
> >> #include "gpmc.h"
> >> #include "gpmc-nand.h"
> >> +#include "gpmc-onenand.h"
> >>
> >> #define DEVICE_NAME "omap-gpmc"
> >>
> >> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device *pdev,
> >> }
> >> #endif
> >>
> >> +#ifdef CONFIG_MTD_ONENAND
> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
> >> + struct device_node *child)
> >> +{
> >> + u32 val;
> >> + struct omap_onenand_platform_data *gpmc_onenand_data;
> >> +
> >> + if (of_property_read_u32(child, "reg", &val) < 0) {
> >> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> >> + child->full_name);
> >> + return -ENODEV;
> >> + }
> >> +
> >> + gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
> >> + GFP_KERNEL);
> >> + if (!gpmc_onenand_data)
> >> + return -ENOMEM;
> >> +
> >> + gpmc_onenand_data->cs = val;
> >> + gpmc_onenand_data->of_node = child;
> >> + gpmc_onenand_data->dma_channel = -1;
> >> +
> >> + if (!of_property_read_u32(child, "dma-channel", &val))
> >> + gpmc_onenand_data->dma_channel = val;
> >> +
> >> + gpmc_onenand_init(gpmc_onenand_data);
> >> +
> >> + return 0;
> >> +}
> >> +#else
> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
> >> + struct device_node *child)
> >> +{
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >> static int gpmc_probe_dt(struct platform_device *pdev)
> >> {
> >> int ret;
> >> @@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
> >> return ret;
> >> }
> >>
> >
> > This doesn't look right to me:
> >
> >> + for_each_node_by_name(child, "onenand") {
> >> + ret = gpmc_probe_onenand_child(pdev, child);
> >> + of_node_put(child);
> >> + if (ret < 0)
> >> + return ret;
> >> + }
> >
> > for_each_node_by_name automatically calls of_node_put on each node once passed,
> > and as far as I can tell, gpmc_probe_onenand_child doesn't do anything that'd
> > increment a node's refcount.
> >
> > As far as I can see, you only need the of_node_put in the error case:
> >
> > for_each_node_by_name(child, "onenand") {
> > ret = gpmc_probe_onenand_child(pdev, child);
> > if (ret < 0) {
> > of_node_put(child);
> > return ret;
> > }
> > }
> >
> > Have I missed something here?
> >
>
> Mmm... perhaps I've overlooked that code.
>
> After some digging through source and reading for_each_node_by_name()
> it seems to me you're right.
>
> @Daniel: It seems this would also apply to the NAND binding.
> What do you think?
Would prefer this done as a fix against the omap-for-v3.9/gpmc
branch before we apply Ezequiel's patches.
Regards,
Tony
^ permalink raw reply
* [PATCH v4 3/7] ARM: Exynos: add device tree support for MCT controller driver
From: Thomas Abraham @ 2013-01-21 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121134610.GJ15707@e106331-lin.cambridge.arm.com>
Hi Marc,
On 21 January 2013 05:46, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jan 21, 2013 at 10:02:18AM +0000, Thomas Abraham wrote:
>> Allow the MCT controller base address and interrupts to be obtained from
>> device tree and remove unused static definitions of these. The non-dt support
>> for Exynos5250 is removed but retained for Exynos4210 based platforms.
>>
>> Cc: Changhwan Youn <chaos.youn@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> .../bindings/timer/samsung,exynos4210-mct.txt | 68 ++++++++++++++++++++
>> arch/arm/mach-exynos/include/mach/irqs.h | 6 --
>> arch/arm/mach-exynos/mct.c | 49 +++++++++++----
>> 3 files changed, 105 insertions(+), 18 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
>>
>> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
>> new file mode 100644
>> index 0000000..cb47bfb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
>> @@ -0,0 +1,68 @@
>> +Samsung's Multi Core Timer (MCT)
>> +
>> +The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
>> +global timer and CPU local timers. The global timer is a 64-bit free running
>> +up-counter and can generate 4 interrupts when the counter reaches one of the
>> +four preset counter values. The CPU local timers are 32-bit free running
>> +down-counters and generate an interrupt when the counter expires. There is
>> +one CPU local timer instantiated in MCT for every CPU in the system.
>> +
>> +Required properties:
>> +
>> +- compatible: should be "samsung,exynos4210-mct".
>> + (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
>> + (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
>> +
>> +- reg: base address of the mct controller and length of the address space
>> + it occupies.
>> +
>> +- interrupts: the list of interrupts generated by the controller. The following
>> + should be the order of the interrupts specified. The local timer interrupts
>> + should be specified after the four global timer interrupts have been
>> + specified.
>> +
>> + 0: Global Timer Interrupt 0
>> + 1: Global Timer Interrupt 1
>> + 2: Global Timer Interrupt 2
>> + 3: Global Timer Interrupt 3
>> + 4: Local Timer Interrupt 0
>> + 5: Local Timer Interrupt 1
>> + 6: ..
>> + 7: ..
>> + i: Local Timer Interrupt n
>> +
>> +Example 1: In this example, the system uses only the first global timer
>> + interrupt generated by MCT and the remaining three global timer
>> + interrupts are unused. Two local timer interrupts have been
>> + specified.
>> +
>> + mct at 10050000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x10050000 0x800>;
>> + interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
>> + <0 42 0>, <0 48 0>;
>
> Rather than padding the interrupts list with nonexistent interrupts, could you
> not use something like a #global-interrupts property?
>
> That way you don't have to list fake interrupts, you know exactly how many
> global interrupts to expect (so you can sanity-check the list without any
> special knowledge of the interrupt controller), and it's easier to support
> future revisions which could have more interrupts, in a backwards-compatible
> fashion.
Yes, you are right. I will do this change in the next version. Thanks
for your suggestion.
Thanks,
Thomas.
>
>> + };
>> +
>> +Example 2: In this example, the MCT global and local timer interrupts are
>> + connected to two seperate interrupt controllers. Hence, an
>> + interrupt-map is created to map the interrupts to the respective
>> + interrupt controllers.
>> +
>> + mct at 101C0000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x101C0000 0x800>;
>> + interrupt-controller;
>> + #interrups-cells = <2>;
>> + interrupt-parent = <&mct_map>;
>> + interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
>> + <4 0>, <5 0>;
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <2>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0x0 0 &combiner 23 3>,
>> + <0x4 0 &gic 0 120 0>,
>> + <0x5 0 &gic 0 121 0>;
>> + };
>> + };
>
>
> [...]
>
> Thanks,
> Mark.
>
^ permalink raw reply
* [GIT PULL] arm-soc: Xilinx zynq serial changes for v3.9
From: Arnd Bergmann @ 2013-01-21 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3dJGHK7nO2tx_kUWLwhpgNsCwtnjXAJnRFUOHVx2uE589Q@mail.gmail.com>
On Monday 21 January 2013, Michal Simek wrote:
> git://git.xilinx.com/linux-xlnx.git zynq/serial
>
> Josh Cartwright (1):
> serial: xilinx_uartps: get clock rate info from dts
>
> Wei Yongjun (1):
> serial: xilinx_uartps: fix return value check in xuartps_probe()
>
> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
> drivers/tty/serial/xilinx_uartps.c | 34 +++++++++++++++++++---------------
> 2 files changed, 21 insertions(+), 17 deletions(-)
The patches look good, and they should get merged through Greg's tree.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Richard Cochran @ 2013-01-21 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121182419.GE10020@beef>
On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote:
> On Mon, Jan 21, 2013 at 06:20:03PM +0000, Richard Cochran wrote:
> > On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
> > > for MMC filesystem - we need the edma series. for a ramdisk, I am able
> > > to boot up to shell with 3.8-rc4 tag
> >
> > Yep, I also could boot 3.8-rc3 using ramfs, no problem.
>
> Do you use appended dtb? The only different that jumped out at me first
> Paul's reported hang is he uses appended dtb and I boot my boards with a
> single uImage and multiple dtbs the traditional DT way.
No, not appended. I have a u-boot that supports dtb:
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
and using the omap2plus_defconfig, with a minicom script like the one
below, and it works just fine.
HTH,
Richard
verbose on
send setenv ipaddr 192.168.1.77
send setenv serverip 192.168.1.12
send setenv netmask 255.255.255.0
send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=16384 earlyprintk=serial
send tftp 81000000 uImage
expect {
"U-Boot# "
}
send tftp 82000000 beaglebone-initrd.gz
expect {
"U-Boot# "
}
send tftp 80000000 am335x-bone.dtb
expect {
"U-Boot# "
}
send bootm 81000000 - 80000000
^ permalink raw reply
* [PATCH 15/15] staging/omapdrm: don't build on multiplatform
From: Rob Clark @ 2013-01-21 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301211741.11875.arnd@arndb.de>
On 01/21/2013 11:41 AM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Rob Clark wrote:
>> Are you sure OMAP2_DSS requires ARCH_OMAP2PLUS? I don't see this, and
>> it at least used to not depend on ARCH_OMAP2PLUS. If it does now, I
>> think the correct fix would be to remove the dependency in OMAP2_DSS. I
>> don't think removing ARCH_MULTIPLATFORM support in omapdrm is the
>> correct solution.
> At least it says so in drivers/video/omap2/Kconfig, which contains
>
> if ARCH_OMAP2PLUS
> source drivers/video/omap2/dss/Kconfig
> endif
ahh, ok, I see.. the if ARCH_OMAP2PLUS bit looks like it came in
recently (770b6cb)
what about changing this to 'if ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM'?
BR,
-R
> We can probably change this, but until we do, we should not select
> OMAP2_DSS from something that doesn't also depend on ARCH_OMAP2PLUS.
>
>>> drivers/video/omap2/dss/dss.c: In function 'dss_calc_clock_div':
>>> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared (first use in this function)
>>> drivers/video/omap2/dss/dss.c:572:20: note: each undeclared identifier is reported only once for each function it appears in
>>> drivers/staging/omapdrm/omap_connector.c: In function 'omap_connector_dpms':
>>> drivers/staging/omapdrm/omap_connector.c:116:8: error: 'OMAP_DSS_DISPLAY_SUSPENDED' undeclared (first use in this function)
>>> drivers/staging/omapdrm/omap_connector.c:116:8: note: each undeclared identifier is reported only once for each function it appears in
>>
>> This was an unrelated build break which should be fixed in latest master
>> after 'staging: drm/omap: use omapdss low level API'
> Ok, it seems the message is stale then, I created the patch some time ago, but
> only today wrote rest of the explanation for the changeset text.
>
> With all the other patches from my series applied, allyesconfig still gives me
>
> drivers/video/omap2/dss/dss.c:572:20: error: 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK' undeclared
>
> because that symbol is only defined when OMAP2_DSS is enabled rather than
> selected. Changing drivers/video/omap2/Kconfig to not depend on OMAP seems
> to work as well, but that seems a little intrusive for v3.8, because it would
> let a lot of people build that code that have no use for it.
>
> Arnd
^ permalink raw reply
* [PATCH 12/15] USB: gadget/freescale: disable non-multiplatform drivers
From: Felipe Balbi @ 2013-01-21 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-13-git-send-email-arnd@arndb.de>
Hi,
On Mon, Jan 21, 2013 at 05:16:05PM +0000, Arnd Bergmann wrote:
> Both the fsl_mxc gadget and the imx_udc gadget drivers fail to build
> without the mach/hardware.h file that is not available when building
> for multiplatform. Let's disable these drivers for v3.8 in combination
> with CONFIG_ARCH_MULTIPLATFORM, and fix them properly in v3.9 unless
> someone has an better solution.
>
> Without this patch, building allyesconfig results in:
>
> drivers/usb/gadget/fsl_mxc_udc.c:21:27: fatal error: mach/hardware.h: No such file or directory
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
NAK, I prefer to see a real fix for the problem (which in fact is
already in my fixes branch).
Next time, before enabling something by default, check that
allyesconfig, allmodconfig and allnoconfig builds fine, please.
--
balbi
-------------- 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/20130121/e2036f1b/attachment.sig>
^ permalink raw reply
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Felipe Balbi @ 2013-01-21 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358788568-11137-14-git-send-email-arnd@arndb.de>
On Mon, Jan 21, 2013 at 05:16:06PM +0000, Arnd Bergmann wrote:
> In linux-3.8-rc1 it became possible to build the imx and
> mvebu platforms together in a single kernel, which clashes
> in the ehci driver.
>
> Manjunath Goudar is already working on a patch to convert
> both the imx and the mvebu glue drivers (along with all
> the other ARM specific ones) to the new probing method,
> but that will be too late to fix v3.8. This patch instead
> adds yet another hack like the existing ones to allow
> the ehci driver to load both back-ends.
>
> Without this patch, building allyesconfig results in:
>
> drivers/usb/host/ehci-hcd.c:1285:0: error: "PLATFORM_DRIVER" redefined
> drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition
> In file included from drivers/usb/host/ehci-hcd.c:1254:0:
> drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb at vger.kernel.org
> Cc: Manjunath Goudar <manjunath.goudar@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
NAK, should be converted to the new usage of ehci library driver. Alan
Stern already implemented for a few drivers, help is very welcome.
--
balbi
-------------- 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/20130121/bb62631b/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm/dts: Add basic support for gta04 (Openmoko next generation) board.
From: Tony Lindgren @ 2013-01-21 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfyv34ihnwL9JheLzY61zthTkBexTOe3cgkbU4Z+sFG2w1g6g@mail.gmail.com>
* Belisko Marek <marek.belisko@gmail.com> [121115 05:31]:
> CC'ing Tony
>
> On Thu, Nov 15, 2012 at 12:59 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
> > On Wed, 14 Nov 2012 21:26:58 +0100, Belisko Marek <marek.belisko@gmail.com> wrote:
> >> CC' Grant & Rob
> >
> > Hi Marek
> >
> > Since this is an OMAP board, you should send the changes to Tony and
> > they should be merged through the arm-soc tree.
Looks like this one fell through the cracks for v3.8 merge
window. Can you please update it and send it to Benoit with
linux-omap and LAKML lists cc:d?
Now scripts/get_maintainer.pl should do the right trick for
this patch.
Regards,
Tony
> > g.
> >
> >>
> >> On Tue, Oct 30, 2012 at 10:42 PM, Marek Belisko
> >> <marek.belisko@open-nandra.com> wrote:
> >> > Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
> >> > ---
> >> > arch/arm/boot/dts/omap3-gta04.dts | 65 +++++++++++++++++++++++++++++++++++++
> >> > 1 file changed, 65 insertions(+)
> >> > create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
> >> >
> >> > diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
> >> > new file mode 100644
> >> > index 0000000..76efd13
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/omap3-gta04.dts
> >> > @@ -0,0 +1,65 @@
> >> > +/*
> >> > + * Copyright (C) 2012 Marek Belisko <marek.belisko@open-nandra.com>
> >> > + *
> >> > + * Based on omap3-beagle-xm.dts
> >> > + *
> >> > + * 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.
> >> > + */
> >> > +/dts-v1/;
> >> > +
> >> > +/include/ "omap3.dtsi"
> >> > +
> >> > +/ {
> >> > + model = "OMAP3 GTA04";
> >> > + compatible = "ti,omap3-gta04", "ti,omap3";
> >> > +
> >> > + memory {
> >> > + device_type = "memory";
> >> > + reg = <0x80000000 0x20000000>; /* 512 MB */
> >> > + };
> >> > +
> >> > + gpio-keys {
> >> > + compatible = "gpio-keys";
> >> > + #address-cells = <1>;
> >> > + #size-cells = <0>;
> >> > + aux-button {
> >> > + label = "AUX";
> >> > + linux,code = <169>;
> >> > + gpios = <&gpio1 7 1>;
> >> > + gpio-key,wakeup;
> >> > + };
> >> > + };
> >> > +};
> >> > +
> >> > +&i2c1 {
> >> > + clock-frequency = <2600000>;
> >> > +
> >> > + twl: twl at 48 {
> >> > + reg = <0x48>;
> >> > + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> >> > + interrupt-parent = <&intc>;
> >> > + };
> >> > +};
> >> > +
> >> > +/include/ "twl4030.dtsi"
> >> > +
> >> > +&i2c2 {
> >> > + clock-frequency = <400000>;
> >> > + /* Pressure Sensor */
> >> > + bmp085 at 77 {
> >> > + compatible = "bosch,bmp085";
> >> > + reg = <0x77>;
> >> > + };
> >> > +};
> >> > +
> >> > +&i2c3 {
> >> > + clock-frequency = <100000>;
> >> > +};
> >> > +
> >> > +&mmc1 {
> >> > + vmmc-supply = <&vmmc1>;
> >> > + bus-width = <4>;
> >> > +};
> >> > +
> >> > --
> >> > 1.7.9.5
> >> >
> >>
> >>
> >>
> >> --
> >> as simple and primitive as possible
> >> -------------------------------------------------
> >> Marek Belisko - OPEN-NANDRA
> >> Freelance Developer
> >>
> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >> Tel: +421 915 052 184
> >> skype: marekwhite
> >> twitter: #opennandra
> >> web: http://open-nandra.com
> >
> > --
> > Grant Likely, B.Sc, P.Eng.
> > Secret Lab Technologies, Ltd.
>
> Marek
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
^ 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