* [GIT PULL] ARM: mvebu: defconfig changes for v3.17 (round 2)
From: Olof Johansson @ 2014-07-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718221351.GN24496@titan.lakedaemon.net>
On Fri, Jul 18, 2014 at 06:13:51PM -0400, Jason Cooper wrote:
> All,
>
> Here's all the defconfig changes we have for mvebu this time around.
> The big one is the removal of kirkwood_defconfig, cooresponding to the
> mach-kirkwood/ removal in mvebu/soc.
>
> This is an incremental pull request from tags/mvebu-defconfig-3.17 up to
> tags/mvebu-defconfig-3.17-2 on the mvebu/defconfig branch.
>
> Please pull.
>
> thx,
>
> Jason.
>
> The following changes since commit 5658d58545388850c77a070fb3b882ddd958eb88:
>
> ARM: multi_v5: Enable LaCie 2Big and 5Big Network v2 (2014-06-20 20:50:23 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig-3.17-2
>
> for you to fetch changes up to c1eed8d2ff67b18f3892016f40ad6899ac6cf477:
>
> ARM: mvebu: update mvebu_v7_defconfig with cpufreq support (2014-07-16 12:51:39 +0000)
>
> ----------------------------------------------------------------
> mvebu defconfig changes for v3.17 (round 2)
>
> - mvebu
> - Add appended_dtb support
> - Add devtmpfs support
> - Add 375 network driver
> - Add cpuidle support
> - Add cpufreq support
>
> - kirkwood
> - Remove kirkwood_defconfig
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Steven Rostedt @ 2014-07-19 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-RZ4s+33LVOK3eTrvb3ig0YXmNwT0-3GS2-WuvThyXTg@mail.gmail.com>
On Sat, 19 Jul 2014 22:50:16 +0200
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> OK, so if the general case has been fixed, perhaps we should ask Paul
> to drop my patch?
>
No, for a few reasons. One, this patch still needs to get in to fix the
problem for RCU. Two, RCU basically open codes the creation of the
string, thus this wont solve it for RCU.
-- Steve
^ permalink raw reply
* [GIT PULL 1/5] Samsung non-critical-fixes for v3.17
From: Olof Johansson @ 2014-07-19 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9C121.6090403@samsung.com>
On Sat, Jul 19, 2014 at 09:51:45AM +0900, Kukjin Kim wrote:
> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>
> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/fixes-for-3.17
>
> for you to fetch changes up to 042b687f880adcca77847688aac35e2e16927944:
>
> ARM: EXYNOS: Fix build breakge with PM_SLEEP=n (2014-07-19
> 04:45:02 +0900)
>
> ----------------------------------------------------------------
> Samsung non critical fixes for v3.17
> - update exynos_defconfig for remove outdated configs and
> enable most of the configs used on latest exynos platforms
> - fix build breakge for exynos_defconfig with PM_SLEEP=n
Hi,
We now separate out defconfigs (as you might have noticed if you looked
at our tree). I don't see any dependencies between these changes and
the rest so I'll cherry-pick the patches into fixes-non-critical (for
the build fix) and defconfig for that patch.
-Olof
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-19 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_71vJFf3aUZso1X7m7fULUMhxj+MZVYq+LGNRLJvGyAA@mail.gmail.com>
On Sat, 19 Jul 2014, Ard Biesheuvel wrote:
> On 18 July 2014 23:22, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> > Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >
> >>
> >> Here's the patch I have at the head of the series now, with the above
> >> ugliness changed to an unconditional __tracepoint_string attribute.
> >>
> >
> > I was thinking of something like this. Feel free to add this to your
> > series.
> >
> > -- Steve
> >
>
> Nico,
>
> If this patch addresses the issue where 3 RCU related tracepoint
> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
> patch queued up here
>
> http://marc.info/?l=linux-kernel&m=140518452623148&w=2
No, that doesn't help my case. Please see the initial comment from
Steven in this thread and you'll understand.
Nicolas
^ permalink raw reply
* [GIT PULL 2/5] Samsung cleanup for v3.17
From: Olof Johansson @ 2014-07-19 22:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9C139.9090304@samsung.com>
On Sat, Jul 19, 2014 at 09:52:09AM +0900, Kukjin Kim wrote:
> Note that this is based on 3.16-rc5 because of dependency with
> previous samsung fixes already merged in mainline during -rc.
>
> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>
> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/samsung-cleanup
>
> for you to fetch changes up to fce9e5bb25264153f9f002eada41757118d25ba9:
>
> ARM: EXYNOS: Add support for mapping PMU base address via DT
> (2014-07-15 08:40:32 +0900)
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] Samsung exynos cpuidle update for v3.17
From: Olof Johansson @ 2014-07-19 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9C159.4070305@samsung.com>
On Sat, Jul 19, 2014 at 09:52:41AM +0900, Kukjin Kim wrote:
> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>
> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/exynos-cpuidle
>
> for you to fetch changes up to fc2cac41ebbfb16da8b036cba6ec6714ab780a6d:
>
> ARM: EXYNOS: populate suspend and powered_up callbacks for mcpm
> (2014-07-19 03:36:00 +0900)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/5] Samsung exynos_mct update for v3.17
From: Olof Johansson @ 2014-07-19 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9C164.9030404@samsung.com>
On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote:
> Note that this is also based on 3.16-rc5 because of dependency with
> previous samsung fixes including exynos_mct already merged in
> mainline during -rc.
>
> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>
> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/exynos-mct
>
> for you to fetch changes up to 1a631118c1d085fe162f3b6d44f710c72206ef2d:
>
> clocksource: exynos_mct: Only use 32-bits where possible
> (2014-07-19 03:07:52 +0900)
>
> ----------------------------------------------------------------
> exynos_mct update for v3.17
> - only use 32-bit access for performance benefits on exynos
> 32-bit system and this means ARCH timer should be supported
> on exynos 64-bit system instead of current MCT.
> - use readl_relaxed/writel_relaxed to consistently use the
> proper functions in exynos_mct.
There's no reason for these to go through arm-soc, is there? They should
go through the clocksource tree (Daniel Lezcano / Thomas Gleixner). They
also lack acks from them if they for some reason need to go through arm-soc.
-Olof
^ permalink raw reply
* [GIT PULL 5/5] Samsung DT updates for v3.17
From: Olof Johansson @ 2014-07-19 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C9C171.4090208@samsung.com>
On Sat, Jul 19, 2014 at 09:53:05AM +0900, Kukjin Kim wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/samsung-dt
>
> for you to fetch changes up to ccaba4527156da1619a23bafcb944e8e029d0573:
>
> ARM: dts: Add I2S dt node for exynos3250 (2014-07-19 04:10:44 +0900)
Merged, thanks.
-Olof
^ permalink raw reply
* bios32.c: Fix me in pci_fixup_it8152
From: Nick Krause @ 2014-07-19 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Hey Russell and others,
Before I clean this fix me up I wanted to known how to define the values
as stated in the fix me in this function or if this is invalid as of the latest
kernel trees.
Cheers Nick
^ permalink raw reply
* bios32.c: Fix me in pci_fixup_it8152
From: Russell King - ARM Linux @ 2014-07-19 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDOMVibN_jYoxHyaE1sRXj6garOmKvFoMXGV62B4FONTgJGMQ@mail.gmail.com>
On Sat, Jul 19, 2014 at 06:47:37PM -0400, Nick Krause wrote:
> Hey Russell and others,
> Before I clean this fix me up I wanted to known how to define the values
> as stated in the fix me in this function or if this is invalid as of the
> latest kernel trees.
If you would like to fix it properly, then that's fine. The comment
there says:
/* FIXME: add defines for class 0x68000 and 0x80103 */
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_HOST ||
dev->class == 0x68000 ||
dev->class == 0x80103) {
The thing that's slightly confusing here is that dev->class contains
the class in bits 24..8, but also the programming interface in bits
7..0.
So, the comment is slightly wrong in that it's actually meaning
class 0x0680 with a programming interface of 0x00, and a class of
0x0801 with a programming interface of 0x03.
Your challenge is to _not_ add defines for these, but to use the
existing defines for these classes, and modify the code to use those
defines /without/ changing the effect of the checks. Ignore that
there's no definitions of the programming interfaces - they can
stay as raw numbers.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v3 0/3] Clean up ACPI core to prepare for running ACPI on ARM64
From: Rafael J. Wysocki @ 2014-07-19 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405677774-16787-1-git-send-email-hanjun.guo@linaro.org>
On Friday, July 18, 2014 06:02:51 PM Hanjun Guo wrote:
> This patch set have no function change for x86 and ia64 and
> just do some clean up to prepare for running ACPI on ARM64.
>
> This patch set is splited out from the patch set [1]
> "[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it
> can be merged first before ARM64 ACPI core patches.
>
> [1]: https://lkml.org/lkml/2014/6/26/627
>
> update from v2:
> Don not select ACPI_LEGACY_TABLES_LOOKUP on IA64 which
> is catched by Peter.
>
> update from v1:
> 1. Drop "Make EC debugfs depend on X86 || IA64 in Kconfig";
> 2. Rename ACPI_SCAN_BIOS_NOT_EFI to ACPI_LEGACY_TABLES_LOOKUP
> suggested by Rafael;
> 3. Rename ARCH_HAS_ACPI_PDC to ARCH_MIGHT_HAVE_ACPI_PDC suggested by Rafael;
> 4. Remove the help for ARCH_MIGHT_HAVE_ACPI_PDC because it can't be selected;
> 5. Rename acpi_arch_is_smp() to acpi_has_cpu_in_madt() to be more
> explicit and easy understanding.
>
> Graeme Gregory (2):
> ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
> ACPI: Don't use acpi_lapic in ACPI core code
>
> Hanjun Guo (1):
> ACPI / processor: Introduce ARCH_HAS_ACPI_PDC
Series queued up for 3.17 with minor changes of patch subjects. Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 1/3] pinctrl: rockchip: set is_generic in pinconf_ops
From: Heiko Stübner @ 2014-07-19 23:48 UTC (permalink / raw)
To: linux-arm-kernel
The rockchip pinctrl driver implements the generic pinconfig, therefore
also state this, so that the default pinconf dump functions work.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/pinctrl/pinctrl-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 169c3db..37339a1 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -946,6 +946,7 @@ static int rockchip_pinconf_get(struct pinctrl_dev *pctldev, unsigned int pin,
static const struct pinconf_ops rockchip_pinconf_ops = {
.pin_config_get = rockchip_pinconf_get,
.pin_config_set = rockchip_pinconf_set,
+ .is_generic = true,
};
static const struct of_device_id rockchip_bank_match[] = {
--
1.9.0
^ permalink raw reply related
* [PATCH 2/3] pinctrl: rockchip: add separate type for rk3288
From: Heiko Stübner @ 2014-07-19 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3086962.49c4Dnm508@diego>
An upcoming pinctrl function of the rk3288 differs again from everything else,
so we'll need a separate type for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/pinctrl/pinctrl-rockchip.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 37339a1..58c4647 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -62,6 +62,7 @@ enum rockchip_pinctrl_type {
RK2928,
RK3066B,
RK3188,
+ RK3288,
};
/**
@@ -597,7 +598,8 @@ static int rockchip_get_pull(struct rockchip_pin_bank *bank, int pin_num)
return !(data & BIT(bit))
? PIN_CONFIG_BIAS_PULL_PIN_DEFAULT
: PIN_CONFIG_BIAS_DISABLE;
case RK3188:
+ case RK3288:
data >>= bit;
data &= (1 << RK3188_PULL_BITS_PER_PIN) - 1;
@@ -651,6 +653,7 @@ static int rockchip_set_pull(struct rockchip_pin_bank *bank,
spin_unlock_irqrestore(&bank->slock, flags);
break;
case RK3188:
+ case RK3288:
spin_lock_irqsave(&bank->slock, flags);
/* enable the write to the equivalent lower bits */
@@ -830,6 +833,7 @@ static bool rockchip_pinconf_pull_valid(struct rockchip_pin_ctrl *ctrl,
case RK3066B:
return pull ? false : true;
case RK3188:
+ case RK3288:
return (pull != PIN_CONFIG_BIAS_PULL_PIN_DEFAULT);
}
@@ -1864,7 +1868,7 @@ static struct rockchip_pin_ctrl rk3288_pin_ctrl = {
.pin_banks = rk3288_pin_banks,
.nr_banks = ARRAY_SIZE(rk3288_pin_banks),
.label = "RK3288-GPIO",
- .type = RK3188,
+ .type = RK3288,
.grf_mux_offset = 0x0,
.pmu_mux_offset = 0x84,
.pull_calc_reg = rk3288_calc_pull_reg_and_bit,
--
1.9.0
^ permalink raw reply related
* [PATCH 3/3] pinctrl: rockchip: add drive-strength control for rk3288
From: Heiko Stübner @ 2014-07-19 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3086962.49c4Dnm508@diego>
The rk3288 is the first Rockchip soc handling the drive strength on a per-pin
basis, while the older ones can set the drive-strength only for specific
pin-groups. Therefore limit setting the drive-strength to this soc for now.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
drivers/pinctrl/pinctrl-rockchip.c | 112 +++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index 58c4647..c15f7f9 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -573,6 +573,98 @@ static void rk3288_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
}
}
+#define RK3288_DRV_PMU_OFFSET 0x70
+#define RK3288_DRV_GRF_OFFSET 0x1c0
+#define RK3288_DRV_BITS_PER_PIN 2
+#define RK3288_DRV_PINS_PER_REG 8
+#define RK3288_DRV_BANK_STRIDE 16
+static int rk3288_drv_list[] = { 2, 4, 8, 12 };
+
+static void rk3288_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
+ int pin_num, struct regmap **regmap,
+ int *reg, u8 *bit)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+
+ /* The first 24 pins of the first bank are located in PMU */
+ if (bank->bank_num == 0) {
+ *regmap = info->regmap_pmu;
+ *reg = RK3288_DRV_PMU_OFFSET;
+
+ *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
+ *bit = pin_num % RK3288_DRV_PINS_PER_REG;
+ *bit *= RK3288_DRV_BITS_PER_PIN;
+ } else {
+ *regmap = info->regmap_base;
+ *reg = RK3288_DRV_GRF_OFFSET;
+
+ /* correct the offset, as we're starting with the 2nd bank */
+ *reg -= 0x10;
+ *reg += bank->bank_num * RK3288_DRV_BANK_STRIDE;
+ *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
+
+ *bit = (pin_num % RK3288_DRV_PINS_PER_REG);
+ *bit *= RK3288_DRV_BITS_PER_PIN;
+ }
+}
+
+static int rk3288_get_drive(struct rockchip_pin_bank *bank, int pin_num)
+{
+ struct regmap *regmap;
+ int reg, ret;
+ u32 data;
+ u8 bit;
+
+ rk3288_calc_drv_reg_and_bit(bank, pin_num, ®map, ®, &bit);
+
+ ret = regmap_read(regmap, reg, &data);
+ if (ret)
+ return ret;
+
+ data >>= bit;
+ data &= (1 << RK3288_DRV_BITS_PER_PIN) - 1;
+
+ return rk3288_drv_list[data];
+}
+
+static int rk3288_set_drive(struct rockchip_pin_bank *bank, int pin_num,
+ int strength)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+ struct regmap *regmap;
+ unsigned long flags;
+ int reg, ret, i;
+ u32 data;
+ u8 bit;
+
+ rk3288_calc_drv_reg_and_bit(bank, pin_num, ®map, ®, &bit);
+
+ ret = -EINVAL;
+ for (i = 0; i < ARRAY_SIZE(rk3288_drv_list); i++) {
+ if (rk3288_drv_list[i] == strength) {
+ ret = i;
+ break;
+ }
+ }
+
+ if (ret < 0) {
+ dev_err(info->dev, "unsupported driver strength %d\n",
+ strength);
+ return ret;
+ }
+
+ spin_lock_irqsave(&bank->slock, flags);
+
+ /* enable the write to the equivalent lower bits */
+ data = ((1 << RK3288_DRV_BITS_PER_PIN) - 1) << (bit + 16);
+ data |= (ret << bit);
+
+ ret = regmap_write(regmap, reg, data);
+ spin_unlock_irqrestore(&bank->slock, flags);
+
+ return ret;
+}
+
static int rockchip_get_pull(struct rockchip_pin_bank *bank, int pin_num)
{
struct rockchip_pinctrl *info = bank->drvdata;
@@ -888,6 +980,15 @@ static int rockchip_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
if (rc)
return rc;
break;
+ case PIN_CONFIG_DRIVE_STRENGTH:
+ /* rk3288 is the first with per-pin drive-strength */
+ if (info->ctrl->type != RK3288)
+ return -ENOTSUPP;
+
+ rc = rk3288_set_drive(bank, pin - bank->pin_base, arg);
+ if (rc < 0)
+ return rc;
+ break;
default:
return -ENOTSUPP;
break;
@@ -937,6 +1038,17 @@ static int rockchip_pinconf_get(struct pinctrl_dev *pctldev, unsigned int pin,
arg = rc ? 1 : 0;
break;
+ case PIN_CONFIG_DRIVE_STRENGTH:
+ /* rk3288 is the first with per-pin drive-strength */
+ if (info->ctrl->type != RK3288)
+ return -ENOTSUPP;
+
+ rc = rk3288_get_drive(bank, pin - bank->pin_base);
+ if (rc < 0)
+ return rc;
+
+ arg = rc;
+ break;
default:
return -ENOTSUPP;
break;
--
1.9.0
^ permalink raw reply related
* [GIT PULL] ARM: imx: SoC changes for 3.17
From: Shawn Guo @ 2014-07-20 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140719191152.GD4265@quad.lixom.net>
On Sat, Jul 19, 2014 at 12:11:52PM -0700, Olof Johansson wrote:
> Nice diffstat. I would have liked to see the cleanups split off in a separate
> preceding branch (and the soc updates build on top if needed), so please keep
> that in mind in the future.
Okay, noted.
> The slightly bigger hassle is the defconfig update, since you touched
> multi_v7_defconfig: we tend to want to merge or apply that separately since
> they tend to cause a lot of conflicts between our branches.
Yes, I should have asked people to submit multi_v7_defconfig change
separately to you guys.
> Still, I'll give you a pass this time, it's a small change so we can manage it.
> Please separate more in the future though.
>
> Merged.
Thanks, Olof.
Shawn
^ permalink raw reply
* FEC driver hangs hardware on i.MX6SX
From: Shawn Guo @ 2014-07-20 2:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Fugang,
Your commit e8fcfcd5684a (net: fec: optimize the clock management to
save power) landed on mainline with v3.16-rc1. It causes a hardware
hang on i.MX6SX, if the rootfs is not on NFS but something else like
MMC.
I think the cause is that PTP is still accessing registers after FEC
driver calls fec_enet_clk_enable(ndev, false) to disable FEC clocks.
Can you please try to provide a fix for this regression soon?
Shawn
^ permalink raw reply
* [PATCH -next] ASoC: samsung: Fix return value check in s3c24xx_iis_dev_probe()
From: weiyj_lk at 163.com @ 2014-07-20 3:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove redundant return value check of
platform_get_resource().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
sound/soc/samsung/s3c24xx-i2s.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/sound/soc/samsung/s3c24xx-i2s.c b/sound/soc/samsung/s3c24xx-i2s.c
index e87d9a2..36dbc17 100644
--- a/sound/soc/samsung/s3c24xx-i2s.c
+++ b/sound/soc/samsung/s3c24xx-i2s.c
@@ -456,13 +456,9 @@ static int s3c24xx_iis_dev_probe(struct platform_device *pdev)
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Can't get IO resource.\n");
- return -ENOENT;
- }
s3c24xx_i2s.regs = devm_ioremap_resource(&pdev->dev, res);
- if (s3c24xx_i2s.regs == NULL)
- return -ENXIO;
+ if (IS_ERR(s3c24xx_i2s.regs))
+ return PTR_ERR(s3c24xx_i2s.regs);
s3c24xx_i2s_pcm_stereo_out.dma_addr = res->start + S3C2410_IISFIFO;
s3c24xx_i2s_pcm_stereo_in.dma_addr = res->start + S3C2410_IISFIFO;
^ permalink raw reply related
* [PATCH -next] ASoC: samsung: Fix return value check in s3c2412_iis_dev_probe()
From: weiyj_lk at 163.com @ 2014-07-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove redundant return value check of
platform_get_resource().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
sound/soc/samsung/s3c2412-i2s.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 9180310..27b339c 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -154,13 +154,9 @@ static int s3c2412_iis_dev_probe(struct platform_device *pdev)
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Can't get IO resource.\n");
- return -ENOENT;
- }
s3c2412_i2s.regs = devm_ioremap_resource(&pdev->dev, res);
- if (s3c2412_i2s.regs == NULL)
- return -ENXIO;
+ if (IS_ERR(s3c2412_i2s.regs))
+ return PTR_ERR(s3c2412_i2s.regs);
s3c2412_i2s_pcm_stereo_out.dma_addr = res->start + S3C2412_IISTXD;
s3c2412_i2s_pcm_stereo_in.dma_addr = res->start + S3C2412_IISRXD;
^ permalink raw reply related
* [PATCH] arm: Fix me in bios32.c
From: Nicholas Krause @ 2014-07-20 4:06 UTC (permalink / raw)
To: linux-arm-kernel
This fixs a fix me in bios32.c for pci_fixup_it8152 as this if
statement is incorrect needs to be checked against the class bits
not the whole address for the two or conditions and since they don't
have define statements outside of their numeratical value.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
arch/arm/kernel/bios32.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 17a26c1..b2217af 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -254,11 +254,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CONTAQ, PCI_DEVICE_ID_CONTAQ_82C693, pci_
static void pci_fixup_it8152(struct pci_dev *dev)
{
int i;
- /* fixup for ITE 8152 devices */
- /* FIXME: add defines for class 0x68000 and 0x80103 */
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_HOST ||
- dev->class == 0x68000 ||
- dev->class == 0x80103) {
+ (dev->class >> 8) == 0x680 ||
+ (dev->class >> 8) == 0x801) {
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
dev->resource[i].start = 0;
dev->resource[i].end = 0;
--
1.9.1
^ permalink raw reply related
* [linux-sunxi] GSoC 2014 #1 status report - Improving Allwinner SoC support
From: Chen-Yu Tsai @ 2014-07-20 4:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CAC9ED.9080302@elopez.com.ar>
Hi Emilio,
On Sun, Jul 20, 2014 at 3:41 AM, Emilio L?pez <emilio@elopez.com.ar> wrote:
> Hi everyone,
>
> Here's this week's update on my GSoC project; if you missed the first issue
> or you want a refresher of what this is about, you can read it on the list
> archives[0]
>
> A couple of days after the last report, and with the help of Jon Smirl, I
> got the hardware working on mainline Linux, first on only 16 bit stereo
> mode, then mono as well, and later on, also on 24 bit mode. The first thing
> I had to do was rework the cyclic DMA code to make it perform decently and
> avoid underruns. The rest took a bit of playing with values and reading the
> Allwinner documentation. There is one unresolved issue with 24 bit audio
> still - for some reason, the volume is really low compared to the same track
> played on 16 bit. Unfortunately the SDK driver doesn't support 24 bit, so
> it's hard to compare with anything else.
So I have not experimented on this, it's just a hunch:
Could it be that the 24bit audio samples you're sending to the audio codec
is aligned incorrectly? So the sample is actually seen as down-shifted by
8 bits, resulting in the low volume?
I'll grab your tree and test 24bit tomorrow. (Good thing I have 24 bit
music files.) :)
> Aside from the audio stuff, I worked a bit on the DMA driver, after
> realizing memcpy could be optimized a fair bit. By using proper alignment
> and choosing the best bus width and as big a burst as possible, I was able
> to go from a totally unscientifically measured ~3MB/s to ~13MB/s on a single
> thread, single channel, 1000 iterations dmatest run with noverify=0. I will
> be sending a v3 with these new changes as well as addressing comments I
> received in the next few days.
This still seems quite slow? I think there was a discussion about this
on IRC, you included? Any followups there?
> To round up on this week's developments, I also worked on the audio clock
> representation, involving PLL2, the codec clock gate and "module 1" clocks
> (AC97, SPDIF, IIS) to enable Jon to work on IIS. Patches for these clocks
> will be out in the list soon as well.
Thanks! I look forward to them.
Cheers
ChenYu
> You can expect the next status report in about a week's time.
>
> Cheers!
>
> Emilio
>
> [0]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html
^ permalink raw reply
* Edma.c: Fix Mes
From: Nick Krause @ 2014-07-20 4:27 UTC (permalink / raw)
To: linux-arm-kernel
Hey Russell and others,
Sorry to bug you again but I have a fix questions before I clean up
the fix mes in this file.
Is edma_clean_channel needed or is edma_stop good enough? And do we
CCERR.BIT(16)
need to write this bit or not?
Cheers Nick
^ permalink raw reply
* [PATCH] ARM: Don't oops when userspace executes kgdb break instructions.
From: Omar Sandoval @ 2014-07-20 5:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718225049.GA11937@mew.guest.dropbox.com>
On Fri, Jul 18, 2014 at 03:51:31PM -0700, Omar Sandoval wrote:
> Don't break into kgdb when userspace executes the kernel break instructions
> (KGDB_BREAKINST and KGDB_COMPILED_BREAK). The kernel will oops in
> kgdb_handle_exception.
>
> Signed-off-by: Omar Sandoval <osandov@osandov.com>
> ---
> The following program will immediately cause a kernel oops:
> .globl _start
> _start:
> udf #65006 @ KGDB_BREAKINST
>
> arch/arm/kernel/kgdb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
> index 778c2f7..a74b53c 100644
> --- a/arch/arm/kernel/kgdb.c
> +++ b/arch/arm/kernel/kgdb.c
> @@ -160,12 +160,16 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, unsigned int instr)
> static struct undef_hook kgdb_brkpt_hook = {
> .instr_mask = 0xffffffff,
> .instr_val = KGDB_BREAKINST,
> + .cpsr_mask = MODE_MASK,
> + .cpsr_val = SVC_MODE,
> .fn = kgdb_brk_fn
> };
>
> static struct undef_hook kgdb_compiled_brkpt_hook = {
> .instr_mask = 0xffffffff,
> .instr_val = KGDB_COMPILED_BREAK,
> + .cpsr_mask = MODE_MASK,
> + .cpsr_val = SVC_MODE,
> .fn = kgdb_compiled_brk_fn
> };
>
> --
> 2.0.1
--
Following up/clarifying this. This only happens when the kernel is compiled
with CONFIG_KGDB. When a userspace program executes KGDB_BREAKINST or
KGDB_COMPILED_BREAK, the undef_hook for kgdb catches it. The reason in kdb_stub
defaults to KDB_REASON_OOPS, so the bug manifests itself as an oops caused by
userspace (a better description for the patch would be "Don't enter KGDB when
userspace executes kgdb break instructions"). This means that a buggy/malicious
program can take down the system just by executing an instruction.
ARM64 might have the same issue, but I don't have a board to test that on.
I verified that breaking normally (e.g., with kgdbwait or through
/proc/sysrq-trigger) still works.
?
Omar
^ permalink raw reply
* FEC driver hangs hardware on i.MX6SX
From: Richard Cochran @ 2014-07-20 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720025732.GF8537@dragon>
On Sun, Jul 20, 2014 at 10:57:33AM +0800, Shawn Guo wrote:
>
> I think the cause is that PTP is still accessing registers after FEC
> driver calls fec_enet_clk_enable(ndev, false) to disable FEC clocks.
> Can you please try to provide a fix for this regression soon?
What do you mean by, "PTP is still accessing registers"?
The only access to any register is through the driver, and the driver
can and should make sure all register accesses are safe.
Thanks,
Richard
^ permalink raw reply
* FEC driver hangs hardware on i.MX6SX
From: fugang.duan at freescale.com @ 2014-07-20 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720025732.GF8537@dragon>
Hi, Shawn,
>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at freescale.com]
>Sent: Sunday, July 20, 2014 10:58 AM
>To: Duan Fugang-B38611
>Cc: Li Frank-B20596; David S. Miller; Guo Shawn-R65073;
>netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org
>Subject: FEC driver hangs hardware on i.MX6SX
>
>Hi Fugang,
>
>Your commit e8fcfcd5684a (net: fec: optimize the clock management to save
>power) landed on mainline with v3.16-rc1. It causes a hardware hang on
>i.MX6SX, if the rootfs is not on NFS but something else like MMC.
>
>I think the cause is that PTP is still accessing registers after FEC
>driver calls fec_enet_clk_enable(ndev, false) to disable FEC clocks.
>Can you please try to provide a fix for this regression soon?
>
Yes, you analyze is right. We had the related patch on internal trees since imx6sx bringup.
I will try to move the patch to upstream.
Thanks,
Andy
^ permalink raw reply
* [linux-sunxi] GSoC 2014 #1 status report - Improving Allwinner SoC support
From: Julian Calaby @ 2014-07-20 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CAC9ED.9080302@elopez.com.ar>
Hi Emilio,
On Sun, Jul 20, 2014 at 5:41 AM, Emilio L?pez <emilio@elopez.com.ar> wrote:
> Hi everyone,
>
> Here's this week's update on my GSoC project; if you missed the first issue
> or you want a refresher of what this is about, you can read it on the list
> archives[0]
>
> A couple of days after the last report, and with the help of Jon Smirl, I
> got the hardware working on mainline Linux, first on only 16 bit stereo
> mode, then mono as well, and later on, also on 24 bit mode. The first thing
> I had to do was rework the cyclic DMA code to make it perform decently and
> avoid underruns. The rest took a bit of playing with values and reading the
> Allwinner documentation. There is one unresolved issue with 24 bit audio
> still - for some reason, the volume is really low compared to the same track
> played on 16 bit. Unfortunately the SDK driver doesn't support 24 bit, so
> it's hard to compare with anything else.
It might be worth trying to generate some 24 bit audio samples that
only exercise one bit, then check that playing them produces output,
because it sounds to me (and Chen-Yu) that there's something in your
code that's shifting or clipping the samples.
Thanks,
--
Julian Calaby
Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ 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