* [PATCH 11/18] extcon: max14577: Add max14577 prefix to muic_irqs
From: Lee Jones @ 2014-02-05 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391596810.3726.5.camel@AMDC1943>
> > Following patch has conflict on extcon-next branch(Linus 3.14-rc1)
> > when apply patchset by using git am.
> >
> > [PATCH 11/18] extcon: max14577: Add max14577 prefix to muic_irqs
> > [PATCH 12/18] extcon: max14577: Choose muic_irqs according to device type
> > [PATCH 14/18] extcon: max14577: Add support for max77836
> >
> > The base commit of this patchset isn't mainline. You need to rebase this patchset
> > on extcon-next branch and please resend this patchset.
<snip>
> This patch patch (along with other) depends on previous rename patches
> from this patchset:
> [PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols to prepare
> for max77836
> http://article.gmane.org/gmane.linux.kernel/1636674
>
> I can resolve the conflict but then they will return on applying patch
> 7/18.
>
> I think this patch may wait for a little until the rename-like patches
> will be accepted.
>
> Can you ACK other patches touch extcon?
> - [PATCH 07/18] mfd: max14577: Rename and add MAX14577 symbols...
> - [PATCH 08/18] mfd: max14577: Rename state container to maxim_core
> - [PATCH 09/18] mfd: max14577: Add "muic" suffix to regmap and irq_chip
If you can obtain Acks for all of the patches, I can apply the entire
patch-set to an immutable branch and issue a pull-request for the
other maintainers to pull from.
> > On 01/28/2014 09:18 PM, Krzysztof Kozlowski wrote:
> > > Add max14577 prefix to muic_irqs array. This prepares for max77836
> > > support in this extcon driver.
> > >
> > > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > ---
> > > drivers/extcon/extcon-max14577.c | 12 ++++++------
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
> > > index fd48b4909470..fb343f4042d2 100644
> > > --- a/drivers/extcon/extcon-max14577.c
> > > +++ b/drivers/extcon/extcon-max14577.c
> > > @@ -85,7 +85,7 @@ struct max14577_muic_irq {
> > > unsigned int virq;
> > > };
> > >
> > > -static struct max14577_muic_irq muic_irqs[] = {
> > > +static struct max14577_muic_irq max14577_muic_irqs[] = {
> > > { MAXIM_IRQ_INT1_ADC, "muic-ADC" },
> > > { MAXIM_IRQ_INT1_ADCLOW, "muic-ADCLOW" },
> > > { MAXIM_IRQ_INT1_ADCERR, "muic-ADCError" },
> > > @@ -541,9 +541,9 @@ static irqreturn_t max14577_muic_irq_handler(int irq, void *data)
> > > * However we only need to know whether it was ADC, charger
> > > * or both interrupts so decode IRQ and turn on proper flags.
> > > */
> > > - for (i = 0; i < ARRAY_SIZE(muic_irqs); i++)
> > > - if (irq == muic_irqs[i].virq)
> > > - irq_type = muic_irqs[i].irq;
> > > + for (i = 0; i < ARRAY_SIZE(max14577_muic_irqs); i++)
> > > + if (irq == max14577_muic_irqs[i].virq)
> > > + irq_type = max14577_muic_irqs[i].irq;
> > >
> > > switch (irq_type) {
> > > case MAXIM_IRQ_INT1_ADC:
> > > @@ -647,8 +647,8 @@ static int max14577_muic_probe(struct platform_device *pdev)
> > > INIT_WORK(&info->irq_work, max14577_muic_irq_work);
> > >
> > > /* Support irq domain for max14577 MUIC device */
> > > - for (i = 0; i < ARRAY_SIZE(muic_irqs); i++) {
> > > - struct max14577_muic_irq *muic_irq = &muic_irqs[i];
> > > + for (i = 0; i < ARRAY_SIZE(max14577_muic_irqs); i++) {
> > > + struct max14577_muic_irq *muic_irq = &max14577_muic_irqs[i];
> > > unsigned int virq = 0;
> > >
> > > virq = regmap_irq_get_virq(maxim_core->irq_data_muic,
> > >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Mike Turquette @ 2014-02-05 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390673950-4521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Quoting Sebastian Hesselbarth (2014-01-25 10:19:06)
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> registered before core clocks driver. Unfortunately, we cannot
> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> init order for our drivers is always core clocks before clock gating,
> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> init function that will register core clocks before clock gating
> driver.
>
> This patch is based on pre-v3.14-rc1 mainline and should go in as
> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> I suggest Jason picks it up as a topic branch.
Sebastian,
These patches look OK to me. I'd rather take Gregory Clement's "respect
the clock dependencies in of_clk_init" patch towards 3.15, so this fix
will still be necessary for the current -rc's.
Jason, will you be sending a PR?
Thanks,
Mike
>
> The patches have been boot tested on Dove and compile-tested only
> for Kirkwood, Armada 370 and XP.
>
> Sebastian Hesselbarth (4):
> clk: mvebu: armada-370: maintain clock init order
> clk: mvebu: armada-xp: maintain clock init order
> clk: mvebu: dove: maintain clock init order
> clk: mvebu: kirkwood: maintain clock init order
>
> drivers/clk/mvebu/armada-370.c | 21 ++++++++++-----------
> drivers/clk/mvebu/armada-xp.c | 20 +++++++++-----------
> drivers/clk/mvebu/dove.c | 19 +++++++++----------
> drivers/clk/mvebu/kirkwood.c | 34 ++++++++++++++++------------------
> 4 files changed, 44 insertions(+), 50 deletions(-)
>
> ---
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> --
> 1.8.5.2
>
^ permalink raw reply
* [alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-02-05 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F23D1D.7040804@metafoo.de>
On Wed, Feb 05, 2014 at 02:31:09PM +0100, Lars-Peter Clausen wrote:
> On 02/05/2014 12:18 PM, Mark Brown wrote:
> >...as previously requested. I know there was some discusion of broader
> >moves to factor this stuff out but it'd still be good to keep it
> >separated out even prior to a final non-EDID based solution so it's
> >easier to refactor.
> I think it will always be EDID (or ELD) based. As I understood it
> the re-factoring Takashi was talking about is related to how this
> data is passed from the graphics driver to the audio driver. The way
Right, the data of course has to come from there originally, it's about
how we pass the data and updates to it around.
-------------- 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/5244a05d/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/5] binfmt_elf: add ELF_HWCAP2 to compat auxv entries
From: Ard Biesheuvel @ 2014-02-05 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387807592-26375-3-git-send-email-ard.biesheuvel@linaro.org>
Hello Al,
May we please have your Ack on this patch so it can go through one of
the ARM trees?
Thank you,
Ard.
On 23 December 2013 15:06, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Add ELF_HWCAP2 to the set of auxv entries that is passed to
> a 32-bit ELF program running in 32-bit compat mode under a
> 64-bit kernel.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> fs/compat_binfmt_elf.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/compat_binfmt_elf.c b/fs/compat_binfmt_elf.c
> index a81147e..4d24d17 100644
> --- a/fs/compat_binfmt_elf.c
> +++ b/fs/compat_binfmt_elf.c
> @@ -88,6 +88,11 @@ static void cputime_to_compat_timeval(const cputime_t cputime,
> #define ELF_HWCAP COMPAT_ELF_HWCAP
> #endif
>
> +#ifdef COMPAT_ELF_HWCAP2
> +#undef ELF_HWCAP2
> +#define ELF_HWCAP2 COMPAT_ELF_HWCAP2
> +#endif
> +
> #ifdef COMPAT_ARCH_DLINFO
> #undef ARCH_DLINFO
> #define ARCH_DLINFO COMPAT_ARCH_DLINFO
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Nishanth Menon @ 2014-02-05 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391608084-12665-1-git-send-email-ml@embed.me.uk>
On 02/05/2014 07:48 AM, Jack Mitchell wrote:
> From: Jack Mitchell <jack@embed.me.uk>
>
> Devicetree include file for setting up the am335x mcasp bus, i2c-2
> bus, and audio codec required for a functioning BeagleBone Audio Cape.
>
> Signed-off-by: Jack Mitchell <jack@embed.me.uk>
> Signed-off-by: Matt Porter <mporter@linaro.org>
> ---
> arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +++++++++++++++++++++
> arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
> 2 files changed, 138 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
>
> diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> new file mode 100644
> index 0000000..b8ec3dc
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> @@ -0,0 +1,124 @@
> +/*
> + * Copyright (C) 2014 Jack Mitchell <jack@embed.me.uk>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * In order to enable the BeagleBone Audio Cape this dtsi must be
> + * incuded in the top level dts. On BeagleBone Black hardware the
> + * status of the HDMI dts node must also be set to "disabled".
> + *
> + * --- a/arch/arm/boot/dts/am335x-bone.dts
> + * +++ b/arch/arm/boot/dts/am335x-bone.dts
> + * @@ -9,6 +9,7 @@
> + *
> + * #include "am33xx.dtsi"
> + * #include "am335x-bone-common.dtsi"
> + * +#include "am335x-bone-audio-cape-reva.dtsi"
> + *
> + * &ldo3_reg {
> + * regulator-min-microvolt = <1800000>;
> + *
> + * On BeagleBone Black hardware the status of the HDMI dts node must
> + * also be set to "disabled"
> + *
> + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
> + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> + * @@ -73,6 +74,6 @@
> + * pinctrl-names = "default", "off";
> + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> + * - status = "okay";
> + * + status = "disabled";
> + * };
> + * };
> + */
> +
how about making the audio-cape-reva.dts which includes and overrides
parameters of boneblack.dts?
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?
> +/ {
> + sound {
> + compatible = "ti,da830-evm-audio";
> + ti,model = "AM335x BeagleBone Audio Cape Rev. A";
> + ti,audio-codec = <&tlv320aic3106>;
> + ti,mcasp-controller = <&mcasp0>;
> + ti,codec-clock-rate = <12000000>;
> + ti,audio-routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT",
> + "LINE1L", "Line In",
> + "LINE1R", "Line In";
> + };
> +
> + audio-cape-gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&bone_audio_cape_led_pins>;
> +
> + audio-led0 {
> + label = "audio:green:usr0";
> + gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + audio-led1 {
> + label = "audio:green:usr1";
> + gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> + };
> +};
> +
> +&am33xx_pinmux {
> + bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
> + pinctrl-single,pins = <
> + 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a2.gpio1_18 */
> + 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a3.gpio1_19 */
> + >;
> + };
> +
> + bone_audio_cape_pins: bone_audio_cape_pins {
> + pinctrl-single,pins = <
> + 0x190 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
> + 0x194 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
> + 0x19c (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
> + 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkx.mcasp0_axr3 */
> + >;
> + };
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins>;
> +
> + status = "okay";
> + clock-frequency = <100000>;
> +
> + tlv320aic3106: tlv320aic3106 at 1b {
> + compatible = "ti,tlv320aic3106";
> + reg = <0x1b>;
> + status = "okay";
> +
> + /* Regulators */
> + AVDD-supply = <&vmmcsd_fixed>;
> + IOVDD-supply = <&vmmcsd_fixed>;
> + DRVDD-supply = <&vmmcsd_fixed>;
> + DVDD-supply = <&vdd1v8_fixed>;
> + };
> +};
> +
> +&mcasp0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&bone_audio_cape_pins>;
> +
> + status = "okay";
> +
> + op-mode = <0>; /* MCASP_IIS_MODE */
> + tdm-slots = <2>;
> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
> + 0 0 2 1
> + >;
> + tx-num-evt = <1>;
> + rx-num-evt = <1>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index e3f27ec..c1c0f74 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -62,12 +62,26 @@
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> };
> +
> + vdd1v8_fixed: fixedregulator at 1 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd1v8_fixed";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> };
>
> &am33xx_pinmux {
> pinctrl-names = "default";
> pinctrl-0 = <&clkout2_pin>;
>
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_ctsn.i2c2_sda */
> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_rtsn.i2c2_scl */
> + >;
> + };
> +
> user_leds_s0: user_leds_s0 {
> pinctrl-single,pins = <
> 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a5.gpio1_21 */
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Balaji T K @ 2014-02-05 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F104B7.6040606@ti.com>
On Tuesday 04 February 2014 08:48 PM, Nishanth Menon wrote:
> On 02/04/2014 06:44 AM, Balaji T K wrote:
>> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
>>> When device is booted using devicetree, platforms impacted by
>>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>>> indicates that the module cannot do multi-block transfers.
>>>
>>> Handle this by providing a boolean flag to indicate to driver that it is
>>> working on a hardware with mentioned limitation.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>>
>>> This explains the logs I see:
>>> OMAP3430 LDP (ES2.2):
>>> uImage only boot: http://slexy.org/raw/s2YrbMAi7c
>>> uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
>>>
>>> With the following flag set, device is now able to consistently boot with
>>> device tree supported uImage+dtb concat boot.
>>>
>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 ++
>>> drivers/mmc/host/omap_hsmmc.c | 3 +++
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> index 8c8908a..ab36f8b 100644
>>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> @@ -26,6 +26,8 @@ specifier is required.
>>> dma-names: List of DMA request names. These strings correspond
>>> 1:1 with the DMA specifiers listed in dmas. The string naming is
>>> to be "rx" and "tx" for RX and TX DMA requests, respectively.
>>> +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
>>> +multiblock reads
>>
>> Rather than ti,errata.. specific property, something like
>> caps no/disable multiblock read is more readable in my opinion, Otherwise
>
> Is'nt the better definition to state i have quirk X and allow the
> driver to do the necessary thing/things needed to handle quirk X? in
> this case, there is just one thing to do: broken multi_block_read, in
> the case of other quirks, there might be more than 1 thing to do.. let
> driver figure that out, dts just states the h/w capabilty or in this
> case, the quirk capability.
>
But in this case there is only one. disable multi block read is more readable
than the errata reference, No strong feelings though.
>>
>> Acked-by: Balaji T K <balajitk@ti.com>
>>
>>>
>>> Examples:
>>>
>>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>>> index 014bfe5..f2d5940 100644
>>> --- a/drivers/mmc/host/omap_hsmmc.c
>>> +++ b/drivers/mmc/host/omap_hsmmc.c
>>> @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
>>> if (of_find_property(np, "ti,dual-volt", NULL))
>>> pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
>>>
>>> + if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
>>> + pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
>>> +
>>> /* This driver only supports 1 slot */
>>> pdata->nr_slots = 1;
>>> pdata->slots[0].switch_pin = cd_gpio;
>>>
>>
>
>
^ permalink raw reply
* [PATCH V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
From: Sricharan R @ 2014-02-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F23887.9060209@ti.com>
Tony,
On Wednesday 05 February 2014 06:41 PM, Sricharan R wrote:
> On Tuesday 04 February 2014 09:44 PM, Thomas Gleixner wrote:
>> On Mon, 3 Feb 2014, Sricharan R wrote:
>>>> I already have your reviewed-by tag for the first patch in this series.
>>>>
>>>> Kevin was pointing out that irqchip maintainer tag is needed for this patch as well
>>>> to be merged. We are planning to take this series through arm-soc tree.
>>>>
>>>> Can i please have your tag for this patch as well ?
>>
>> Acked-by-me
>> --
>> 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
>
> Thanks Thomas.
>
> Kevin,
> I will re-send a branch based on rc1 for this.
>
I have pushed a branch based on mainline,
git://github.com/Sricharanti/sricharan.git
branch: crossbar_3.14_rc1
Regards,
Sricharan
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
From: Nishanth Menon @ 2014-02-05 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F2465A.6060804@ti.com>
On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
> On Tuesday 04 February 2014 08:48 PM, Nishanth Menon wrote:
>> On 02/04/2014 06:44 AM, Balaji T K wrote:
>>> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote:
>>>> When device is booted using devicetree, platforms impacted by
>>>> Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum
>>>> indicates that the module cannot do multi-block transfers.
>>>>
>>>> Handle this by providing a boolean flag to indicate to driver that it is
>>>> working on a hardware with mentioned limitation.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> ---
>>>>
>>>> This explains the logs I see:
>>>> OMAP3430 LDP (ES2.2):
>>>> uImage only boot: http://slexy.org/raw/s2YrbMAi7c
>>>> uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0
>>>>
>>>> With the following flag set, device is now able to consistently boot with
>>>> device tree supported uImage+dtb concat boot.
>>>>
>>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 2 ++
>>>> drivers/mmc/host/omap_hsmmc.c | 3 +++
>>>> 2 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> index 8c8908a..ab36f8b 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> @@ -26,6 +26,8 @@ specifier is required.
>>>> dma-names: List of DMA request names. These strings correspond
>>>> 1:1 with the DMA specifiers listed in dmas. The string naming is
>>>> to be "rx" and "tx" for RX and TX DMA requests, respectively.
>>>> +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
>>>> +multiblock reads
>>>
>>> Rather than ti,errata.. specific property, something like
>>> caps no/disable multiblock read is more readable in my opinion, Otherwise
>>
>> Is'nt the better definition to state i have quirk X and allow the
>> driver to do the necessary thing/things needed to handle quirk X? in
>> this case, there is just one thing to do: broken multi_block_read, in
>> the case of other quirks, there might be more than 1 thing to do.. let
>> driver figure that out, dts just states the h/w capabilty or in this
>> case, the quirk capability.
>>
>
> But in this case there is only one. disable multi block read is more readable
> than the errata reference, No strong feelings though.
Considering this might set an precedence for other quirk description,
I'd like to leave it as it stands.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 05/17] mmc: mmci: Put the device into low power state at system suspend
From: Mark Brown @ 2014-02-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZt5+t7b0_a__2kJP4V9PS2cyXmguWrST+fzbKCnosi7g@mail.gmail.com>
On Wed, Feb 05, 2014 at 01:49:49PM +0100, Linus Walleij wrote:
> On Tue, Feb 4, 2014 at 8:22 PM, Kevin Hilman <khilman@linaro.org> wrote:
> > I'm trying to thing of a good reason to not make PM_SLEEP depend on
> > PM_RUNTIME for platforms like this.
> Isn't the typical Android platform using PM_SLEEP without using
> PM_RUNTIME?
No, not at all. Android does make aggressive use of sleep but it's also
highly desirable to use runtime PM - for example you don't want to have
to power up the entire SoC simply because the system is getting a new
e-mail pushed to it or location updates, most of the hardware is doing
nothing.
-------------- 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/9d95bf3e/attachment.sig>
^ permalink raw reply
* [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Ezequiel Garcia @ 2014-02-05 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F23DF4.7010901@gmail.com>
Hi Grant, Boris:
(BTW, dropped Russell, Rob Landley and some unrelated mailing lists from Cc,
and added Thomas, Gregory and Rob Herring).
On Wed, Feb 05, 2014 at 02:34:44PM +0100, Boris BREZILLON wrote:
> On 05/02/2014 12:15, Grant Likely wrote:
> > On Wed, 29 Jan 2014 14:53:32 -0300, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> wrote:
[..]
> >>
> >> Maybe we can discuss about it now?
> >>
> >> nand-ecc-strength : integer ECC required strength.
> >> nand-ecc-size : integer step size associated to the ECC strength.
> > I'm okay with either, but the above binding is indeed more readable.
>
> That's fine by me, if everybody agrees, let's go for the
> nand-ecc-strength/nand-ecc-size couple then.
>
Great. So, if some DT dictator^C^Cmaintainers can Ack this binding,
I can send a new patchset, with pxa3xx-nand using it...
> I'll rebase next version of my series on Ezequiel's patch providing
> these OF helpers.
>
... and then you can base on it?
This is the original patchset:
http://permalink.gmane.org/gmane.linux.drivers.devicetree/58764
http://permalink.gmane.org/gmane.linux.drivers.devicetree/58763
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Russell King - ARM Linux @ 2014-02-05 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391608993.2538.74.camel@joe-AO722>
On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote:
> On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
> > > On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> > > > > Apparently, people just convert stupidly large udelay()s
> > > > > to mdelay and not be bothered.
> > > >
> > > > And that's the correct answer. Having udelay(10000) rather than mdelay(10)
> > > > is a sign that they weren't paying that much attention when writing the
> > > > code.
> > >
> > > Not really.
> []
> > > It's not so much not paying attention as not
> > > knowing ARM is broken for large udelay().
> >
> > And now read my suggestion about how to avoid the "not knowing" problem. :)
>
> I'd read it already. I didn't and don't disagree.
Please explain /why/ you don't agree.
> I still think adding a #warning on large static udelay()s
> would be sensible. Maybe adding another option like
> #define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME
> guard to avoid seeing the #warning when there's no other
> option.
How does that help? It's /not/ a warning situation - if you ask for
udelay(10000) on ARM, you will /not/ get a 10ms delay. You'll instead
get something much shorter because the arithmetic will overflow.
Now, you could argue that maybe ARM's udelay() implementation should
know about this and implement a loop around the underlying udelay()
implementation to achieve it, and I might agree with you - but I
don't for one very simple reason: we /already/ have such an
implementation. It's called mdelay():
#ifndef mdelay
#define mdelay(n) (\
(__builtin_constant_p(n) && (n)<=MAX_UDELAY_MS) ? udelay((n)*1000) : \
({unsigned long __ms=(n); while (__ms--) udelay(1000);}))
#endif
So, the right answer is /not/ do duplicate this, but to /use/ the
appropriate facilities provided by the kernel.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>
From: Paul Gortmaker @ 2014-02-05 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205064150.GA31568@gmail.com>
[Re: [GIT PULL] tree-wide: clean up no longer required #include <linux/init.h>] On 05/02/2014 (Wed 07:41) Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Ingo,
> >
> > On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > So, if you meant Linus to pull it, you probably want to cite a real
> > > Git URI along the lines of:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
> >
> > Paul provided the proper git url further down in the mail along with the
> > usual pull request message (I guess he should have put that bit at the
> > top).
>
> Yeah, indeed, and it even comes with a signed tag, which is an extra
> nice touch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git tags/init-cleanup
>
> (I guess the https was mentioned first to lower expectations.)
Just to clarify, the init.git was the repo of raw commits+series file
that was used for testing on linux next; now useless, except for showing
the last several weeks of history (hence the visual http link). The
signed tag [separate repo] is the application of those commits against
the 3.14-rc1 tag, which was the end goal from the beginning.
Does history matter? In the case of a cleanup like this, it does only
in the immediate context of this pull request; to help distinguish this
work from some short lived half baked idea that also had its testing
invalidated by arbitrarily rebasing onto the latest shiny tag.
I wouldn't have even mentioned the patch repo, except for the fact that
I know how Linus loves arbitrary rebases [and malformed pull requests] :)
Thanks,
Paul.
--
>
> Thanks,
>
> Ingo
^ permalink raw reply
* [PATCH 11/17] i2c: nomadik: Convert to devm functions
From: Linus Walleij @ 2014-02-05 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-12-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Use devm_* functions to simplify code and error handling.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
However make sure this (and the rest) applies on top of this patch:
http://marc.info/?l=linux-i2c&m=139142325809973&w=2
Because I expect that to be applied first.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Linus Walleij @ 2014-02-05 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-15-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> Since the device is active while a successful probe has been completed,
> the reference counting for the clock will be screwed up and never reach
> zero.
>
> The issue is resolved by implementing runtime PM callbacks and let them
> handle the resources accordingly, including the clock.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Hm do I read it right as patch 13 breaks runtime PM by leaving
the device active after probe() and this patch
14 fixes it again? Maybe these two patches should be squashed
then.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Matt Porter @ 2014-02-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F2460C.3080908@ti.com>
On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote:
> On 02/05/2014 07:48 AM, Jack Mitchell wrote:
> > From: Jack Mitchell <jack@embed.me.uk>
> >
> > Devicetree include file for setting up the am335x mcasp bus, i2c-2
> > bus, and audio codec required for a functioning BeagleBone Audio Cape.
> >
> > Signed-off-by: Jack Mitchell <jack@embed.me.uk>
> > Signed-off-by: Matt Porter <mporter@linaro.org>
> > ---
> > arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +++++++++++++++++++++
> > arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
> > 2 files changed, 138 insertions(+)
> > create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> > new file mode 100644
> > index 0000000..b8ec3dc
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> > @@ -0,0 +1,124 @@
> > +/*
> > + * Copyright (C) 2014 Jack Mitchell <jack@embed.me.uk>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * In order to enable the BeagleBone Audio Cape this dtsi must be
> > + * incuded in the top level dts. On BeagleBone Black hardware the
> > + * status of the HDMI dts node must also be set to "disabled".
> > + *
> > + * --- a/arch/arm/boot/dts/am335x-bone.dts
> > + * +++ b/arch/arm/boot/dts/am335x-bone.dts
> > + * @@ -9,6 +9,7 @@
> > + *
> > + * #include "am33xx.dtsi"
> > + * #include "am335x-bone-common.dtsi"
> > + * +#include "am335x-bone-audio-cape-reva.dtsi"
> > + *
> > + * &ldo3_reg {
> > + * regulator-min-microvolt = <1800000>;
> > + *
> > + * On BeagleBone Black hardware the status of the HDMI dts node must
> > + * also be set to "disabled"
> > + *
> > + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
> > + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> > + * @@ -73,6 +74,6 @@
> > + * pinctrl-names = "default", "off";
> > + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> > + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> > + * - status = "okay";
> > + * + status = "disabled";
> > + * };
> > + * };
> > + */
> > +
> how about making the audio-cape-reva.dts which includes and overrides
> parameters of boneblack.dts?
Yeah, that might be a little cleaner. Black makes things unfortunately
messy for these capes that were really intended for BBW :(
> Further, I see a bunch of capes in
> http://elinux.org/Beagleboard:BeagleBone_Capes
>
> Assuming that we dont want to discuss capebus all over again, is this
> the approach we'd like to consider in the interim?
I think that's a fair assumption...I'll note that there is work slowly
in progress on a very minimal implementation DT overlays upstream. But
that doesn't exist. We are simply interested in a sane way to use the
hardware we own in mainline and this approach makes it possible to build
a kernel+dtb from mainline that works for this configuration. If
there's a better way to support this hardware *today* let's discuss it.
One of the big benefits to having this upstream is that it's no longer
out of sight out of mind. It should be managed alongside all the other
am335x dts data.
Incidentally, I'm hoping to contribute a similar patch for the DVI cape
I have here.
-Matt
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Rob Herring @ 2014-02-05 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391608060-10760-3-git-send-email-ivan.khoronzhuk@ti.com>
On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
> This patch provides bindings for the 64-bit timer in the KeyStone
> architecture devices. The timer can be configured as a general-purpose 64-bit
> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or independently
> (unchained mode) of each other.
This is software configurable or h/w design time configurations?
Rob
>
> It is global timer is a free running up-counter and can generate interrupt
> when the counter reaches preset counter values.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> .../bindings/timer/ti,keystone-timer.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> new file mode 100644
> index 0000000..5fbe361
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> @@ -0,0 +1,29 @@
> +* Device tree bindings for Texas instruments Keystone timer
> +
> +This document provides bindings for the 64-bit timer in the KeyStone
> +architecture devices. The timer can be configured as a general-purpose 64-bit
> +timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> +timers, each half can operate in conjunction (chain mode) or independently
> +(unchained mode) of each other.
> +
> +It is global timer is a free running up-counter and can generate interrupt
> +when the counter reaches preset counter values.
> +
> +Documentation:
> +http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
> +
> +Required properties:
> +
> +- compatible : should be "ti,keystone-timer".
> +- reg : specifies base physical address and count of the registers.
> +- interrupts : interrupt generated by the timer.
> +- clocks : the clock feeding the timer clock.
> +
> +Example:
> +
> +timer at 22f0000 {
> + compatible = "ti,keystone-timer";
> + reg = <0x022f0000 0x80>;
> + interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clktimer15>;
> +};
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Mike Turquette @ 2014-02-05 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15127900.Wy8QsPfEr8@avalon>
Quoting Laurent Pinchart (2014-02-05 02:31:41)
> Mike,
>
> Ping ?
>
> v3.14-rc1 is out, and those are bug fixes.
>
> On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> > On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > > Geert, could you please verify that the series fixes your QSPI clock
> > > > issues with the Koelsch board ?
> > > >
> > > > Laurent Pinchart (2):
> > > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > > clk: shmobile: rcar-gen2: Fix qspi divisor
> > >
> > > Thanks, both:
> > >
> > > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thank you.
> >
> > Mike, could you please pick those patches up for v3.14 ?
Taken into clk-fixes.
Thanks!
Mike
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH 14/17] i2c: nomadik: Fixup deployment of runtime PM
From: Fabio Estevam @ 2014-02-05 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-15-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 4, 2014 at 1:58 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> +static int nmk_i2c_runtime_resume(struct device *dev)
> +{
> + struct amba_device *adev = to_amba_device(dev);,
> + struct nmk_i2c_dev *nmk_i2c = amba_get_drvdata(adev);
> +
> + clk_prepare_enable(nmk_i2c->clk);
Previously the code was checking the return value from
clk_prepare_enable(). You should keep the check here.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Gregory CLEMENT @ 2014-02-05 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391593680-9388-1-git-send-email-b.brezillon@overkiz.com>
Hi Boris,
On 05/02/2014 10:48, Boris BREZILLON wrote:
> The parent dependency check is only available on the first parent of a given
> clk.
>
> Add support for strict dependency check: all parents of a given clk must be
> initialized.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>
> Hello Gregory,
>
> This patch adds support for strict check on clk dependencies (check if all
> parents specified by an DT clk node are initialized).
>
> I'm not sure this is what you were expecting (maybe testing the first parent
> is what you really want), so please feel free to tell me if I'm wrong.
>
> Best Regards,
>
> Boris
>
> drivers/clk/clk.c | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index beb0f8b..6849769 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
> {
> struct of_phandle_args clkspec;
> struct of_clk_provider *provider;
> + int num_parents;
> + bool found;
> + int i;
>
> /*
> * If there is no clock parent, no need to wait for them, then
> * we can consider their absence as being ready
> */
> - if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
> - &clkspec))
> + num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
> + if (num_parents <= 0)
> return 1;
>
> - /* Check if we have such a provider in our array */
> - list_for_each_entry(provider, &of_clk_providers, link) {
> - if (provider->node == clkspec.np)
> + for (i = 0; i < num_parents; i++) {
> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
> + &clkspec))
> return 1;
> +
> + /* Check if we have such a provider in our array */
> + found = false;
> + list_for_each_entry(provider, &of_clk_providers, link) {
> + if (provider->node == clkspec.np) {
> + found = true;
> + break;
Hum this means that as soon as you have one parent then you consider it
as ready. It is better of what I have done because I only test the 1st
parent. However I wondered if we should go further by ensuring all the
parents are ready.
If I am right, there is more than one parent only for the muxer. In this
case is it really expected that all the parent are ready?
Thanks,
Gregory
> + }
> + }
> +
> + if (!found)
> + return 0;
> }
>
> - return 0;
> + return 1;
> }
>
> /**
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] clk: Fix notifier documentation
From: Mike Turquette @ 2014-02-05 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c0808b4-aac3-4add-a5dd-1a69ee815f4b@CO9EHSMHS003.ehs.local>
Quoting S?ren Brinkmann (2014-02-03 08:36:57)
> On Fri, Jan 31, 2014 at 10:01:27PM -0800, Mike Turquette wrote:
> > On Fri, Jan 31, 2014 at 5:49 PM, S?ren Brinkmann
> > <soren.brinkmann@xilinx.com> wrote:
> > > ping?
> >
> > Hi Soren,
> >
> > I'm a bit slow to review patches during the merge window. Thanks for
> > the doc update. I'll take it in after -rc1 drops.
>
> Sorry for my impatience. Thank you!
Taken into clk-next.
Regards,
Mike
>
> S?ren
>
>
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Rob Herring @ 2014-02-05 14:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <robh@kernel.org>
earlyprintk is broken with 64KB pages. The problem is pgprot_default
is not yet initialized when early_io_map is called, so the pte does not
get marked as valid. Set the necessary page and access permission bits.
Cc: Mark Salter <msalter@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
I'm not sure this is really the best fix. Perhaps pgprot_default can be
statically initialized to something useful instead?
Rob
arch/arm64/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f557ebb..c41daa6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -284,7 +284,7 @@ void __iomem * __init early_io_map(phys_addr_t phys, unsigned long virt)
if (pmd_none(*pmd))
return NULL;
pte = pte_offset_kernel(pmd, virt);
- set_pte(pte, __pte((phys & mask) | PROT_DEVICE_nGnRE));
+ set_pte(pte, __pte((phys & mask) | PTE_TYPE_PAGE | PTE_AF | PROT_DEVICE_nGnRE));
} else {
set_pmd(pmd, __pmd((phys & mask) | PROT_SECT_DEVICE_nGnRE));
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 1/5] clk: sunxi: Add support for PLL6 on the A31
From: Mike Turquette @ 2014-02-05 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391605507-30981-2-git-send-email-maxime.ripard@free-electrons.com>
Quoting Maxime Ripard (2014-02-05 05:05:03)
> The A31 has a slightly different PLL6 clock. Add support for this new clock in
> our driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good to me.
Regards,
Mike
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 45 +++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c2cb762..954845c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -11,6 +11,7 @@ Required properties:
> "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> "allwinner,sun4i-pll5-clk" - for the PLL5 clock
> "allwinner,sun4i-pll6-clk" - for the PLL6 clock
> + "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
> "allwinner,sun4i-axi-clk" - for the AXI clock
> "allwinner,sun4i-axi-gates-clk" - for the AXI gates
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index abb6c5a..0c05c2d 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32 parent_rate,
> *n = DIV_ROUND_UP(div, (*k+1));
> }
>
> +/**
> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
> + * PLL6 rate is calculated as follows
> + * rate = parent_rate * n * (k + 1) / 2
> + * parent_rate is always 24Mhz
> + */
> +
> +static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
> + u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> + u8 div;
> +
> + /*
> + * We always have 24MHz / 2, so we can just say that our
> + * parent clock is 12MHz.
> + */
> + parent_rate = parent_rate / 2;
> +
> + /* Normalize value to a parent_rate multiple (24M / 2) */
> + div = *freq / parent_rate;
> + *freq = parent_rate * div;
> +
> + /* we were called to round the frequency, we can now return */
> + if (n == NULL)
> + return;
> +
> + *k = div / 32;
> + if (*k > 3)
> + *k = 3;
>
> + *n = DIV_ROUND_UP(div, (*k+1));
> +}
>
> /**
> * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> @@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
> .kwidth = 2,
> };
>
> +static struct clk_factors_config sun6i_a31_pll6_config = {
> + .nshift = 8,
> + .nwidth = 5,
> + .kshift = 4,
> + .kwidth = 2,
> +};
> +
> static struct clk_factors_config sun4i_apb1_config = {
> .mshift = 0,
> .mwidth = 5,
> @@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data __initconst = {
> .getter = sun4i_get_pll5_factors,
> };
>
> +static const struct factors_data sun6i_a31_pll6_data __initconst = {
> + .enable = 31,
> + .table = &sun6i_a31_pll6_config,
> + .getter = sun6i_a31_get_pll6_factors,
> +};
> +
> static const struct factors_data sun4i_apb1_data __initconst = {
> .table = &sun4i_apb1_config,
> .getter = sun4i_get_apb1_factors,
> @@ -972,6 +1016,7 @@ free_clkdata:
> static const struct of_device_id clk_factors_match[] __initconst = {
> {.compatible = "allwinner,sun4i-pll1-clk", .data = &sun4i_pll1_data,},
> {.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
> + {.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
> {.compatible = "allwinner,sun4i-apb1-clk", .data = &sun4i_apb1_data,},
> {.compatible = "allwinner,sun4i-mod0-clk", .data = &sun4i_mod0_data,},
> {.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
> --
> 1.8.4.2
>
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: Will Deacon @ 2014-02-05 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391611829-7824-1-git-send-email-robherring2@gmail.com>
Hi Rob,
On Wed, Feb 05, 2014 at 02:50:29PM +0000, Rob Herring wrote:
> From: Rob Herring <robh@kernel.org>
>
> earlyprintk is broken with 64KB pages. The problem is pgprot_default
> is not yet initialized when early_io_map is called, so the pte does not
> get marked as valid. Set the necessary page and access permission bits.
>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
I thought we fixed this in 4ce00dfcf19c by reverting the use of
pgprot_default?
Will
^ permalink raw reply
* v3.14-rc1 locking bug in system suspend
From: Shawn Guo @ 2014-02-05 14:54 UTC (permalink / raw)
To: linux-arm-kernel
I start seeing the following locking bug on IMX6 with suspend operation
after moving to v3.14-rc1. Before I start looking into the issue, I
would like to confirm if it's an IMX specific problem or one seen on
other platforms. Please ask if you need more info.
Shawn
root at arm:~# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e624 removed
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
PM: Entering mem sleep
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1849 Comm: bash Not tainted 3.14.0-rc1+ #1648
Backtrace:
[<80012144>] (dump_backtrace) from [<800122e4>] (show_stack+0x18/0x1c)
r6:808c48a0 r5:00000000 r4:00000000 r3:00000000
[<800122cc>] (show_stack) from [<80637ac0>] (dump_stack+0x78/0x94)
[<80637a48>] (dump_stack) from [<80064fa0>] (__lock_acquire+0x18f4/0x1ce0)
r4:00000002 r3:bda3f200
[<800636ac>] (__lock_acquire) from [<80065894>] (lock_acquire+0x68/0x7c)
r10:bd906000 r9:bda3f200 r8:00000000 r7:00000000 r6:60000013 r5:bd906000
r4:00000000
[<8006582c>] (lock_acquire) from [<8063c938>] (mutex_lock_nested+0x5c/0x3b8)
r7:00000000 r6:80dfc78c r5:804be444 r4:bf122928
[<8063c8dc>] (mutex_lock_nested) from [<804be444>] (snd_soc_suspend+0x34/0x42c)
r10:00000000 r9:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:be8fd150
r4:be8fd010
[<804be410>] (snd_soc_suspend) from [<8034392c>] (platform_pm_suspend+0x34/0x64)
r10:00000000 r8:00000000 r7:bf1c4444 r6:bf1c4410 r5:803438f8 r4:bf1c4410
[<803438f8>] (platform_pm_suspend) from [<80348e18>] (dpm_run_callback.isra.7+0x34/0x6c)
[<80348de4>] (dpm_run_callback.isra.7) from [<80349354>] (__device_suspend+0x10c/0x220)
r9:808dd974 r8:808c4a5c r6:00000002 r5:80e5001c r4:bf1c4410
[<80349248>] (__device_suspend) from [<8034a338>] (dpm_suspend+0x60/0x220)
r7:bf1c4410 r6:808dd90c r5:80e5001c r4:bf1c44c0
[<8034a2d8>] (dpm_suspend) from [<8034a790>] (dpm_suspend_start+0x60/0x68)
r10:8079a818 r9:00000000 r8:00000004 r7:80dfbe90 r6:80641eec r5:00000000
r4:00000002
[<8034a730>] (dpm_suspend_start) from [<8006a788>] (suspend_devices_and_enter+0x74/0x318)
r4:00000003 r3:80dfbe98
[<8006a714>] (suspend_devices_and_enter) from [<8006abd8>] (pm_suspend+0x1ac/0x244)
r10:8079a818 r8:00000004 r7:00000003 r6:80641eec r5:00000000 r4:00000003
[<8006aa2c>] (pm_suspend) from [<80069a4c>] (state_store+0x70/0xc0)
r5:00000003 r4:be9c7680
[<800699dc>] (state_store) from [<80294034>] (kobj_attr_store+0x1c/0x28)
r10:bd99cb88 r8:00000000 r7:bd907f78 r6:be9c7680 r5:00000004 r4:bd99cb80
[<80294018>] (kobj_attr_store) from [<80140f90>] (sysfs_kf_write+0x54/0x58)
[<80140f3c>] (sysfs_kf_write) from [<8014474c>] (kernfs_fop_write+0xc4/0x160)
r6:be9c7680 r5:bd99cb80 r4:00000004 r3:80140f3c
[<80144688>] (kernfs_fop_write) from [<800dfa14>] (vfs_write+0xbc/0x184)
r10:00000000 r9:00000000 r8:00000000 r7:bd907f78 r6:00281c08 r5:00000004
r4:bda1bd00
[<800df958>] (vfs_write) from [<800dfe00>] (SyS_write+0x48/0x70)
r10:00000000 r8:00000000 r7:00000004 r6:00281c08 r5:00000000 r4:bda1bd00
[<800dfdb8>] (SyS_write) from [<8000e800>] (ret_fast_syscall+0x0/0x48)
r9:bd906000 r8:8000e9c4 r7:00000004 r6:00281c08 r5:00000004 r4:76f575e0
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=2104 jiffies, g=576, c=575, q=2)
Task dump for CPU 0:
bash R running 0 1849 1848 0x00000002
Backtrace:
[<80065894>] (lock_acquire) from [<80061410>] (trace_hardirqs_off+0x14/0x18)
Backtrace aborted due to bad frame pointer <bd907b3c>
INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 1, t=8424 jiffies, g=576, c=575, q=3)
Task dump for CPU 0:
bash R running 0 1849 1848 0x00000002
Backtrace:
[<80065894>] (lock_acquire) from [<80061410>] (trace_hardirqs_off+0x14/0x18)
Backtrace aborted due to bad frame pointer <bd907b3c>
^ permalink raw reply
* [PATCH] arm64: fix early_io_map for 64K pages
From: 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
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