* [PATCH v7 0/4] Add ethernet support for r7s72100
From: Simon Horman @ 2014-01-17 0:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this series adds ethernet support to sh-pfc for the r7s72100 SoC.
This series is based on a merge of:
* The topic/r7s72100-v3.13-rc8-20140115 tag in my renesas tree
* net-next
- Head revision: 08c93cd99b2f31ba9
("Merge branch 'for-davem' of git://gitorious.org/linux-can/linux-can-next")
The first two patches, targeted at net-next, also applies cleanly there.
Changes since v6
* Update change log of:
- sh_eth: Use bool as return type of sh_eth_is_gether()
Changes since v5
* Address feedback from Joe Perches and Sergei Shtylyov as detailed
in the changelogs of:
- sh_eth: Use bool as return type of sh_eth_is_gether()
- sh_eth: Add support for r7s72100
Changes since v4
* Addressed feedback from Sergei Shtylyov as detailed in the changelog
of "sh_eth: Add support for r7s72100"
* Rebase
Changes since v3
* Use bool as return type of sh_eth_is_gether()
and sh_eth_is_rz_fast_ether()
* Correct coding style in sh_eth_get_stats()
Changes since v2
* Trivial rebase
* Dropped "RFC" from subject
Changes since v1 are noted in the changelog of each patch.
Simon Horman (4):
sh_eth: Use bool as return type of sh_eth_is_gether()
sh_eth: Add support for r7s72100
ARM: shmobile: r7s72100: Add clock for r7s72100-ether
ARM: shmobile: genmai: Enable r7s72100-ether
arch/arm/mach-shmobile/board-genmai.c | 21 +++++
arch/arm/mach-shmobile/clock-r7s72100.c | 4 +
drivers/net/ethernet/renesas/sh_eth.c | 131 +++++++++++++++++++++++++++++---
drivers/net/ethernet/renesas/sh_eth.h | 3 +-
4 files changed, 146 insertions(+), 13 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
From: Bjorn Andersson @ 2014-01-17 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115164604.GI14405@codeaurora.org>
On Wed 15 Jan 08:46 PST 2014, Stephen Boyd wrote:
> On 01/13, Bjorn Andersson wrote:
> > +/*
> > + * QUP driver for Qualcomm MSM platforms
> > + *
> > + */
>
> This comment seems redundant, we know what file we're looking at.
>
Indeed.
> > +
> > +struct qup_i2c_dev {
> > + struct device *dev;
> > + void __iomem *base;
> > + struct pinctrl *pctrl;
>
> This is unused.
>
Removed.
> > + int irq;
> > + struct clk *clk;
> > + struct clk *pclk;
> > + struct i2c_adapter adap;
> > +
> > + int clk_freq;
>
> This is only ever used in probe, so why do we need to store it
> away?
>
Moved to probe()
> > + int clk_ctl;
> > + int one_bit_t;
> > + int out_fifo_sz;
> > + int in_fifo_sz;
> > + int out_blk_sz;
> > + int in_blk_sz;
> > + unsigned long xfer_time;
> > + unsigned long wait_idle;
> > +
> > + struct i2c_msg *msg;
> > + /* Current possion in user message buffer */
>
> s/possion/position/?
>
Thanks.
> > + int pos;
> > + /* Keep number of bytes left to be transmitted */
> > + int cnt;
> > + /* I2C protocol errors */
> > + u32 bus_err;
> > + /* QUP core errors */
> > + u32 qup_err;
> > + /*
> > + * maximum bytes that could be send (per iterration). could be
>
> s/iterration/iteration/?
>
Thanks
> > + * equal of fifo size or block size (in block mode)
> > + */
> > + int chunk_sz;
> > + struct completion xfer;
> > +};
> > +
> > +static irqreturn_t qup_i2c_interrupt(int irq, void *dev)
> > +{
> > + struct qup_i2c_dev *qup = dev;
> > + u32 bus_err;
> > + u32 qup_err;
> > + u32 opflags;
> > +
> [...]
> > +
> > + if (opflags & QUP_OUT_SVC_FLAG)
> > + writel(QUP_OUT_SVC_FLAG, qup->base + QUP_OPERATIONAL);
> > +
> > + if (!(qup->msg->flags == I2C_M_RD))
>
> Should this be?
>
> if (!(qup->msg->flags & I2C_M_RD))
>
> Otherwise it should be
>
> if (qup->msg->flags != I2C_M_RD)
>
In the codeaurora implementation this seem to be:
if (qup->msg->flags == I2C_M_RD) {
if ((opflags & QUP_MX_INPUT_DONE) || (opflags & QUP_IN_SVC_FLAG))
writel(QUP_IN_SVC_FLAG, qup->base + QUP_OPERATIONAL);
else
return IRQ_HANDLED;
}
So, do not complete the xfer unless there's something for us.
I'll verify this and update the next version.
Thanks.
> > + return IRQ_HANDLED;
> > +
> > + if ((opflags & QUP_MX_INPUT_DONE) || (opflags & QUP_IN_SVC_FLAG))
> > + writel(QUP_IN_SVC_FLAG, qup->base + QUP_OPERATIONAL);
> > +
> > +done:
> > + qup->qup_err = qup_err;
> > + qup->bus_err = bus_err;
> > + complete(&qup->xfer);
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int
> > +qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state, bool only_valid)
> > +{
> > + int retries = 0;
> > + u32 state;
> > +
> > + do {
> > + state = readl(qup->base + QUP_STATE);
> > +
> > + /*
> > + * If only valid bit needs to be checked, requested state is
> > + * 'don't care'
> > + */
>
> It looks like req_state == 0 means only_valid == true. Can we
> drop the only_valid argument to this function?
>
In all cases but the reset in the beginning of qup_i2c_xfer, so it seems that
it has to stay.
> > + if (state & QUP_STATE_VALID) {
> > + if (only_valid)
> > + return 0;
> > + if ((req_state & QUP_I2C_MAST_GEN)
> > + && (state & QUP_I2C_MAST_GEN))
> > + return 0;
> > + if ((state & QUP_STATE_MASK) == req_state)
> > + return 0;
> > + }
> > +
> > + if (retries++ == 1000)
> > + udelay(100);
> > +
> > + } while (retries != 2000);
>
> Please makes #defines for 1000 and 2000.
>
This retry loop looks completely arbitrary to me now that you say it. I'll
revise this.
> > +
> > + return -ETIMEDOUT;
> > +}
> > +
> [...]
> > +static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
> > +{
> > + u32 addr = msg->addr << 1;
> > + u32 val, qup_tag;
> > + int idx, entries;
> > +
> > + if (qup->pos == 0) {
> > + val = QUP_OUT_START | addr;
> > + } else {
> > + /*
> > + * Avoid setup time issue by adding 1 NOP when number of bytes
> > + * are more than FIFO/BLOCK size. setup time issue can't appear
> > + * otherwise since next byte to be written will always be ready
> > + */
> > + val = (QUP_OUT_NOP | 1);
> > + }
> > +
> > + entries = qup->cnt + 1;
> > +
> > + if (entries > qup->chunk_sz)
> > + entries = qup->chunk_sz;
> > +
> > + qup_tag = QUP_OUT_DATA;
> > +
> > + /* Reserve one entry for STOP */
> > + for (idx = 1; idx < (entries - 1); idx++, qup->pos++) {
>
> Unnecessary () here around entries.
>
Sure.
> > +
> > + if (idx & 1) {
> > + val |= (qup_tag | msg->buf[qup->pos]) << QUP_MSW_SHIFT;
> > + writel(val, qup->base + QUP_OUT_FIFO_BASE);
> > + } else {
> > + val = qup_tag | msg->buf[qup->pos];
> > + }
> [...]
> > +
> > +#ifdef CONFIG_PM
>
> This ifdef is probably wrong considering that you can disable
> CONFIG_PM_RUNTIME without disabling CONFIG_PM and then these
> runtime PM functions would be unused.
>
Will fix.
> > +static int qup_i2c_pm_suspend_runtime(struct device *device)
> > +{
> > + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> > +
> > + dev_dbg(device, "pm_runtime: suspending...\n");
> > + qup_i2c_disable_clocks(qup);
> > + return 0;
> > +}
> > +
> > +static int qup_i2c_pm_resume_runtime(struct device *device)
> > +{
> > + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> > +
> > + dev_dbg(device, "pm_runtime: resuming...\n");
> > + qup_i2c_enable_clocks(qup);
> > + return 0;
> > +}
> > +
> > +static int qup_i2c_suspend(struct device *device)
> > +{
> > + dev_dbg(device, "system suspend");
> > + qup_i2c_pm_suspend_runtime(device);
> > + return 0;
> > +}
> > +
> > +static int qup_i2c_resume(struct device *device)
> > +{
> > + dev_dbg(device, "system resume");
> > + qup_i2c_pm_resume_runtime(device);
> > + pm_runtime_mark_last_busy(device);
> > + pm_request_autosuspend(device);
> > + return 0;
> > +}
> > +#endif /* CONFIG_PM */
> > +
> > +static const struct dev_pm_ops qup_i2c_qup_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(
> > + qup_i2c_suspend,
> > + qup_i2c_resume)
> > + SET_RUNTIME_PM_OPS(
> > + qup_i2c_pm_suspend_runtime,
> > + qup_i2c_pm_resume_runtime,
> > + NULL)
> > +};
> > +
> > +static struct of_device_id qup_i2c_dt_match[] = {
>
> const?
>
Sure
> > + {.compatible = "qcom,i2c-qup"},
> > + {}
> > +};
>
> MODULE_DEVICE_TABLE(of, qup_i2c_dt_match)?
>
OK
Thanks Stephen!
// Bjorn
^ permalink raw reply
* [PATCH] arm64: fix strnlen_user when count <= strlen
From: Kyle McMartin @ 2014-01-16 23:48 UTC (permalink / raw)
To: linux-arm-kernel
I received a bug report about the ruby test-suite failing on AArch64 when
attempting to pass MAX_ARG_STRLEN sized args to execv[1]. It was
expecting an E2BIG returned, but instead was receiving ENOMEM, and
concatenating the argument strings in funky ways.
The problem appeared to be in __strnlen_user on arm64, as when
instrumenting fs/exec.c to compare the results of the asm-generic
strnlen_user, I noticed an off-by-one on the result:
long-param-test: optimized strnlen_user (131072) and naive (131073) disagree!
As a result, fix strnlen_user to match expected behaviour as documented
in lib/strnlen_user.c, and return count+1 when count would be exceeded.
I didn't feel comfortable prodding the assembler, so I just worked
around it in the wrapper.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
1. https://bugzilla.redhat.com/show_bug.cgi?id=1038676
---
I tested that this behaves the same as the lib/strnlen_user.c version
with some hacked together code here:
http://kyle.fedorapeople.org/strnlen_user-test.tar.xz
{master}kmcmarti ~/strnlen_user-test $ ./test
=== count = 0 ===
strnlen_user = 0
__strnlen_user = 0
fixed__strnlen_user = 0
=== count < strlen ===
strnlen_user = 7
__strnlen_user = 6
fixed__strnlen_user = 7
=== count = strlen ===
strnlen_user = 13
__strnlen_user = 12
fixed__strnlen_user = 13
=== count > strlen ===
strnlen_user = 13
__strnlen_user = 13
fixed__strnlen_user = 13
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -290,9 +290,15 @@ static inline long __must_check strnlen_user(const char __user *s, long n)
{
unsigned long res = 0;
+ if (unlikely(n <= 0))
+ return 0;
+
if (__addr_ok(s))
res = __strnlen_user(s, n);
+ if (unlikely(res >= n))
+ return n + 1;
+
return res;
}
^ permalink raw reply
* [PATCH v2 1/2] i2c: qup: Add device tree bindings information
From: Bjorn Andersson @ 2014-01-16 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389689841.2794.8.camel@iivanov-dev.int.mm-sol.com>
On Tue 14 Jan 00:57 PST 2014, Ivan T. Ivanov wrote:
>
> Thanks Bjorn,
>
> I have prepared second version, but never send it out :-).
> One thing suggested by Mark was missed in this version.
Yeah, Mattew told me you we're assigned to other things and asked me to send
out an update as I had gotten it to work on our boards.
I did modify the wording of most of these to match how it is written in the
other Qualcomm definitions.
@Mark, would you rather have me change this to your suggested wording?
>
>
> On Mon, 2014-01-13 at 16:30 -0800, Bjorn Andersson wrote:
> > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> >
[snip]
> > + - clocks: Should contain the core clock and the AHB clock.
>
> + - clocks: a list of phandle + clock-specifier pairs for each entry in
> + clock-names
>
This is in line with how it's written in other drivers, so if the DT
maintainers doesn't disagree I would like to keep phandles out of the
description. This specific line is a verbatime copy of the msm_serial
documentation (same block, different mode)...
> > + - clock-names: Should be "core" for the core clock and "iface" for the
> > + AHB clock.
> > +
> > + - #address-cells: Should be <1> Address cells for i2c device address
> > + - #size-cells: Should be <0> as i2c addresses have no size component
> > +
> > +Optional properties:
> > + - clock-frequency: Should specify the desired i2c bus clock frequency in Hz,
> > + default is 100kHz if omitted.
> > +
> > +Child nodes should conform to i2c bus binding.
> > +
> > +Example:
> > +
> > + i2c2: i2c at f9924000 {
> > + compatible = "qcom,i2c-qup";
> > + reg = <0xf9924000 0x1000>;
> > + interrupts = <0 96 0>;
> > +
> > + clocks = <&gcc_blsp1_qup2_i2c_apps_clk>, <&gcc_blsp1_ahb_clk>;
>
> In the light of the latest patches from Stephen, this could be
>
> + clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
Yes, that's exactly what I have in my dts. However as this is just an example
I didn't feel it was worth tainting the documentation with all those capital
letters ;)
So unless DT maintainers disagree I would like to just keep it as an example.
Regards,
Bjorn
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-16 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116213954.4167.37071@quantum>
On 01/16/2014 03:39 PM, Mike Turquette wrote:
> Quoting Tony Lindgren (2014-01-15 11:35:48)
>> * Mike Turquette <mturquette@linaro.org> [140115 11:25]:
>>> Quoting Tony Lindgren (2014-01-15 09:13:23)
>>>> * Mike Turquette <mturquette@linaro.org> [140114 19:52]:
>>>>>>
>>>>>> These 40 patches apply very cleanly on top of clk-next with 2
>>>>>> exceptions:
>>>>>>
>>>>>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
>>>>>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
>>>>>> on 3.13-rc1).
>>>>>>
>>>>>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
>>>>>> resolved correctly but would like verification.
>>>>>>
>>>>>> I'd prefer to simply merge these patches into clk-next, which is the
>>>>>> most straightforward route. Any ideas on how to handle the missing
>>>>>> AM35xx dtsi data? It can always go as a separate fix after this stuff
>>>>>> gets merged which, ironically, is how that file was created in the first
>>>>>> place.
>>>>
>>>> You could do something like this to take advantage of fast forward and
>>>> not have to do a merge back from mainline:
>>>>
>>>> $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
>>>> $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
>>>> $ git am am3517-clk-patch
>>>> $ git checkout clk-next
>>>> $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc
>>>
>>> That makes sense, but is there anything bad about doing that for a
>>> branch you intend to send as a pull request? I don't see how any of the
>>> commits get re-written or anything... I just wonder if there is some
>>> subtlety that I am not accounting for that makes this approach bad for
>>> sending to Linus.
>>
>> No there should not be any issues. That's the preferred way to keep
>> development branches updated and pullable in long term without any need
>> to rebase.
>>
>> Note that there will be only a merge commit if there is a conflict,
>> otherwise the fast forward will be transparent. So the trick to avoiding
>> rebasing and back merges is to apply patches against what they need in a
>> local branch, then after testing merge that local branch into the development
>> branch. Then for the upsteam pull request, you just need to make it against
>> the -rc you merged in.
>>
>> AFAIK what Linus does not like is doing a back merge to a development
>> branch from mainline, probably as it adds a pointless commit. Or rebasing
>> a branch as that way it won't stay pullable.
>
> Hi all,
>
> I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
> Tero's series. This includes the AM3517 bits now. I've pushed this
> branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
> final sanity test before I merge this into clk-next?
multi_v7_defconfig:
1: am335x-evm: Boot FAIL: http://slexy.org/raw/s25jHnIctr
mmc/regulator missing stuff
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2e9oDkTbD
mmc/regulator missing stuff
3: am3517-evm: Boot PASS: http://slexy.org/raw/s2KL4qBOM6
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20jAHD1DE
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21vXGDma7
6: beag: Boot PASS: http://slexy.org/raw/s25ZJgkM9q
7: bone: Boot PASS: http://slexy.org/raw/s21U0U2lVW
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s24d4sXtTh
CONFIG_SOC_DRA7XX not present in multi_v7
10: ldp: No Image built - Missing platform support?:
11: panda: Boot PASS: http://slexy.org/raw/s21KrJmEWB
12: sdp2430: No Image built - Missing platform support?:
13: sdp3430: Boot PASS: http://slexy.org/raw/s21uwA3Swz
14: sdp4430: Boot PASS: http://slexy.org/raw/s21GE8FOPC
15: uevm: Boot FAIL: http://slexy.org/raw/s2E3NAziyb
mmc/regulator missing stuff
TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7
omap2plus_defconfig:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2euW1YeS0
2: am335x-sk: Boot PASS: http://slexy.org/raw/s2nxn1i5Ea
3: am3517-evm: Boot PASS: http://slexy.org/raw/s20knQQExn
4: am37x-evm: Boot PASS: http://slexy.org/raw/s21L1hfSHF
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2EpSMvtnF
6: beag: Boot PASS: http://slexy.org/raw/s21Z8ytsMS
7: bone: Boot PASS: http://slexy.org/raw/s21ZpxRieJ
8: crane: No Image built - Missing platform support?:
9: dra7: Boot PASS: http://slexy.org/raw/s2owXcv5DW
10: ldp: No Image built - Missing platform support?:
11: panda: Boot PASS: http://slexy.org/raw/s215rSL4p0
12: sdp2430: No Image built - Missing platform support?:
13: sdp3430: Boot PASS: http://slexy.org/raw/s21dxlFJn7
14: sdp4430: Boot PASS: http://slexy.org/raw/s20WIfzRqi
15: uevm: Boot PASS: http://slexy.org/raw/s20Ba9mBTv
TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3
the 3 no image built boards have pending dts patches in for-next from
Tony and Benoit. So, linux-next should eventually be good.
As far as I see: the test results are equivalent to the branch that
Tero posted.
Thanks for the patience and effort :).
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] pinctrl: capri: add dependency on OF
From: Linus Walleij @ 2014-01-16 22:45 UTC (permalink / raw)
To: linux-arm-kernel
As this driver is using pinconf_generic_dt_node_to_map_pin() it
needs to depend on OF so as not to cause build problems on
archs that do not support OF.
Cc: Sherman Yin <syin@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index f1dda4d9de13..be361b7cd30f 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -106,6 +106,7 @@ config PINCTRL_BCM2835
config PINCTRL_CAPRI
bool "Broadcom Capri pinctrl driver"
+ depends on OF
select PINMUX
select PINCONF
select GENERIC_PINCONF
--
1.8.4.2
^ permalink raw reply related
* [GIT PULL] DaVinci watchdog change for v3.14
From: Kevin Hilman @ 2014-01-16 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CE8B05.2040800@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> Hi Arnd, Olof, Kevin,
>
> Can you please pull the following patch. It has been acked by Wim.
> There are some other davinci_wdt.c patches Wim has queued in his
> tree, but a test merge of this patch with latest linux-next does
> not throw any conflicts.
>
> Thanks,
> Sekhar
>
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/watchdog
>
> for you to fetch changes up to 843748123d95ae77a489b41f2f193e8502fc7ea8:
>
> watchdog: davinci: rename platform driver to davinci-wdt (2014-01-09 16:48:31 +0530)
>
> ----------------------------------------------------------------
> This patch updates the davinci watchdog
> platform device name from generic "watchdog"
> to something more specific.
>
> ----------------------------------------------------------------
Pulled into next/drivers,
Thanks,
Kevin
^ permalink raw reply
* [PATCH] cpuidle: don't use modular platform register in non-modular ARM drivers
From: Paul Gortmaker @ 2014-01-16 22:19 UTC (permalink / raw)
To: linux-arm-kernel
These two drivers are configured with Kconfig options that are
both declared as bool. Hence it is not possible for the code
to be built as modular. However the code is currently using the
module_platform_driver() macro for driver registration.
While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'll be forced
to do, pending some upcoming code relocation from init.h into
module.h. So we fix it now by using the non-modular equivalent.
With some macro detangulation, and a little help from cpp, we can
see that module_platform_driver(calxeda_cpuidle_plat_driver) gets
roughly translated into:
static int __init calxeda_cpuidle_plat_driver_init(void)
{
return platform_driver_register(&calxeda_cpuidle_plat_driver);
}
module_init(calxeda_cpuidle_plat_driver_init);
static void __exit calxeda_cpuidle_plat_driver_exit(void)
{
platform_driver_unregister(&calxeda_cpuidle_plat_driver);
}
module_exit(calxeda_cpuidle_plat_driver_exit);
[and similarly for the other file, cpuidle-zynq.c]
And since we've already established that the code is non-modular,
we can completely drop any code relating to module_exit. For non
modular code, module_init beomes __initcall. But direct use of
__initcall is discouraged, vs. one of the priority categorized
subgroups. As __initcall gets mapped onto device_initcall, our
use of device_initcall directly in this change means that the
runtime impact is zero -- they will remain at level 6 in the
initcall ordering.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: linux-pm at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/cpuidle/cpuidle-calxeda.c b/drivers/cpuidle/cpuidle-calxeda.c
index 6e51114057d0..631e2cd9bce6 100644
--- a/drivers/cpuidle/cpuidle-calxeda.c
+++ b/drivers/cpuidle/cpuidle-calxeda.c
@@ -78,4 +78,8 @@ static struct platform_driver calxeda_cpuidle_plat_driver = {
.probe = calxeda_cpuidle_probe,
};
-module_platform_driver(calxeda_cpuidle_plat_driver);
+static int __init calxeda_cpuidle_plat_driver_init(void)
+{
+ return platform_driver_register(&calxeda_cpuidle_plat_driver);
+}
+device_initcall(calxeda_cpuidle_plat_driver_init);
diff --git a/drivers/cpuidle/cpuidle-zynq.c b/drivers/cpuidle/cpuidle-zynq.c
index aded75928028..a1aae519a573 100644
--- a/drivers/cpuidle/cpuidle-zynq.c
+++ b/drivers/cpuidle/cpuidle-zynq.c
@@ -85,4 +85,8 @@ static struct platform_driver zynq_cpuidle_driver = {
.probe = zynq_cpuidle_probe,
};
-module_platform_driver(zynq_cpuidle_driver);
+static int __init zynq_cpuidle_driver_init(void)
+{
+ return platform_driver_register(&zynq_cpuidle_driver);
+}
+device_initcall(zynq_cpuidle_driver_init);
--
1.8.5.2
^ permalink raw reply related
* How to support SDIO wifi/bt in DT
From: Marcel Holtmann @ 2014-01-16 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74872027.r5ouCtzAgs@wuerfel>
Hi Arnd,
>>> b) We need to add a way to attach a device_node to an sdio_func,
>>> so that a function driver can find additional DT properties.
>>> This part should be relatively simple once (a) is done and
>>> should only need a little code but no new binding. The code
>>> would be similar to what we do for amba, i2c or spi devices.
>>
>> This isn't actually needed for this functionality, but might be needed
>> for other things...
>>
>
> There is at least one sdio driver (cw1200) that needs to get
> a MAC address from DT and has the same kind of hack that
> you mention to work around it at the moment (actually worse,
> it's not even using auxdata). The MAC address is certainly
> a property of the device, not the host. This is of course
> the same problem that we have on various development boards
> with USB ethernet controllers lacking an EEPROM.
there are plenty of these devices. It is not just Ethernet or WiFi. You can add Bluetooth devices addresses to this as well. The Nokia N900 drivers for example. Even the Nexus 4 devices are in this boat as well.
The addresses are either stored in some magic place or plain simple on the host filesystem. Maybe this whole magic persistent IEEE addresses thing need its own subsystem. So drivers needing an address can just request it from the subsystem and the subsystem deals with the nasty storage details on how to get the addresses into the kernel in the first place. Currently it is a big mess.
I have seen nasty workaround with delayed initialization from probe or other crazy sysfs settings to just make this work.
Regards
Marcel
^ permalink raw reply
* [GIT PULL] A DaVinci SoC update for v3.14
From: Kevin Hilman @ 2014-01-16 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CFD8F5.5010100@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/soc
>
> for you to fetch changes up to 4408c26bc37fa8ada493ad41a6c7659b76fff483:
>
> ARM: davinci: clock: return 0 upon error from clk_round_rate() (2013-11-27 14:48:33 +0530)
>
> ----------------------------------------------------------------
> A patch to fix the return value of clk_round_rate()
>
> ----------------------------------------------------------------
Pulled into next/soc,
Thanks,
Kevin
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Olof Johansson @ 2014-01-16 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74872027.r5ouCtzAgs@wuerfel>
On Thu, Jan 16, 2014 at 1:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 16 January 2014 09:15:17 Olof Johansson wrote:
>>
>> > b) We need to add a way to attach a device_node to an sdio_func,
>> > so that a function driver can find additional DT properties.
>> > This part should be relatively simple once (a) is done and
>> > should only need a little code but no new binding. The code
>> > would be similar to what we do for amba, i2c or spi devices.
>>
>> This isn't actually needed for this functionality, but might be needed
>> for other things...
>>
>
> There is at least one sdio driver (cw1200) that needs to get
> a MAC address from DT and has the same kind of hack that
> you mention to work around it at the moment (actually worse,
> it's not even using auxdata). The MAC address is certainly
> a property of the device, not the host. This is of course
> the same problem that we have on various development boards
> with USB ethernet controllers lacking an EEPROM.
Yeah, definitely overlap with the on-board usb ethernet adapters where
the vendor hasn't bothered with an eeprom.
> Getting the device to probe in the first place is more important,
> and this is a much simpler problem though.
Yes, agreed -- both needs solving but they're separate issues.
-Olof
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Arnd Bergmann @ 2014-01-16 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgzi5Buduo2pd0PP8CvKVir69yZ-jjX0Gbda871GiD8rg@mail.gmail.com>
On Thursday 16 January 2014 09:15:17 Olof Johansson wrote:
>
> > b) We need to add a way to attach a device_node to an sdio_func,
> > so that a function driver can find additional DT properties.
> > This part should be relatively simple once (a) is done and
> > should only need a little code but no new binding. The code
> > would be similar to what we do for amba, i2c or spi devices.
>
> This isn't actually needed for this functionality, but might be needed
> for other things...
>
There is at least one sdio driver (cw1200) that needs to get
a MAC address from DT and has the same kind of hack that
you mention to work around it at the moment (actually worse,
it's not even using auxdata). The MAC address is certainly
a property of the device, not the host. This is of course
the same problem that we have on various development boards
with USB ethernet controllers lacking an EEPROM.
Getting the device to probe in the first place is more important,
and this is a much simpler problem though.
Arnd
^ permalink raw reply
* [GIT PULL] DaVinci DT updates for v3.14
From: Kevin Hilman @ 2014-01-16 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CFC2CB.3050909@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
>
> Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/dt
>
> for you to fetch changes up to 3a9574f2aa4ffd9b867321a1f298893410bd3718:
>
> ARM: davinci: da850 evm: add GPIO pinumux entries DT node (2013-12-15 18:40:49 +0530)
>
> ----------------------------------------------------------------
> DaVinci device tree file updates to add GPIO
> support.
>
> ----------------------------------------------------------------
Pulled into next/dt.
Thanks,
Kevin
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Mike Turquette @ 2014-01-16 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115193547.GF7993@atomide.com>
Quoting Tony Lindgren (2014-01-15 11:35:48)
> * Mike Turquette <mturquette@linaro.org> [140115 11:25]:
> > Quoting Tony Lindgren (2014-01-15 09:13:23)
> > > * Mike Turquette <mturquette@linaro.org> [140114 19:52]:
> > > > >
> > > > > These 40 patches apply very cleanly on top of clk-next with 2
> > > > > exceptions:
> > > > >
> > > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
> > > > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
> > > > > on 3.13-rc1).
> > > > >
> > > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
> > > > > resolved correctly but would like verification.
> > > > >
> > > > > I'd prefer to simply merge these patches into clk-next, which is the
> > > > > most straightforward route. Any ideas on how to handle the missing
> > > > > AM35xx dtsi data? It can always go as a separate fix after this stuff
> > > > > gets merged which, ironically, is how that file was created in the first
> > > > > place.
> > >
> > > You could do something like this to take advantage of fast forward and
> > > not have to do a merge back from mainline:
> > >
> > > $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
> > > $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
> > > $ git am am3517-clk-patch
> > > $ git checkout clk-next
> > > $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc
> >
> > That makes sense, but is there anything bad about doing that for a
> > branch you intend to send as a pull request? I don't see how any of the
> > commits get re-written or anything... I just wonder if there is some
> > subtlety that I am not accounting for that makes this approach bad for
> > sending to Linus.
>
> No there should not be any issues. That's the preferred way to keep
> development branches updated and pullable in long term without any need
> to rebase.
>
> Note that there will be only a merge commit if there is a conflict,
> otherwise the fast forward will be transparent. So the trick to avoiding
> rebasing and back merges is to apply patches against what they need in a
> local branch, then after testing merge that local branch into the development
> branch. Then for the upsteam pull request, you just need to make it against
> the -rc you merged in.
>
> AFAIK what Linus does not like is doing a back merge to a development
> branch from mainline, probably as it adds a pointless commit. Or rebasing
> a branch as that way it won't stay pullable.
Hi all,
I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
Tero's series. This includes the AM3517 bits now. I've pushed this
branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
final sanity test before I merge this into clk-next?
Thanks!
Mike
>
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH 3/4] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-01-16 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116194003.GN17314@sirena.org.uk>
Hi Mark,
On Thu, Jan 16, 2014 at 07:40:03PM +0000, Mark Brown wrote:
> On Thu, Jan 16, 2014 at 06:11:24PM +0100, Maxime Ripard wrote:
>
> Looks pretty clean, a few fairly small things below.
>
> > +- clocks: phandle to the clocks feeding the SPI controller. Two are
> > + needed:
> > + - "ahb": the gated AHB parent clock
> > + - "mod": the parent module clock
>
> I guess you should specify that this needs to be done with clock-names
> too then?
Yep, right.
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -69,6 +69,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
> > obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
> > obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
> > obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
> > +obj-$(CONFIG_ARCH_SUNXI) += spi-sun6i.o
>
> I would expect a new Kconfig symbol for this.
Hmmm, yeah, sorry, some hacky leftover.
> > +static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
> > +{
> > + u32 reg, cnt;
> > + u8 byte;
> > +
> > + /* See how much data are available */
>
> data is available.
>
> > + while (len--) {
> > + byte = readb(sspi->base_addr + SUN6I_RXDATA_REG);
> > + if (sspi->rx_buf)
> > + *sspi->rx_buf++ = byte;
> > + }
>
> It seems like this hardware is only able to handle bidirectional
> operation - this is actually quite common and isn't always as simple as
> it is here. Can I persuade you to put something in the core which
> provides dummy data buffers for this case? I was thinking flags like
> must_tx and must_rx or something but didn't get around to this yet.
I'm pretty sure It can support unidirectionnal operations as well. I
just didn't found out how yet. There's actually three counters to set
whenever I setup the transfer, two of them seem to be to set the
number of bytes to send, and the last one the overall number of bursts
to set on the clock line, so I guess that we can either set it only in
RX (with the first two to 0, the last one to spi_transfer->len), only
in TX or both (by programming all three to spi_transfer->len).
> > +static int sun6i_spi_finish_transfer(struct spi_device *spi,
> > + struct spi_transfer *tfr,
> > + bool cs_change)
> > +{
> > + struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
> > +
> > + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
> > +
> > + if (tfr->delay_usecs)
> > + udelay(tfr->delay_usecs);
>
> If you implement this using transfer_one() (as you should) the core will
> do this for you.
Oh, nice. I overlooked it.
> > + if (status & SUN6I_INT_CTL_RF_OVF) {
> > + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
> > + sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_OVF);
> > + return IRQ_HANDLED;
> > + }
>
> This looks like an overflow - a log message would be helpful for users
> and you should possibly be flagging an error on the current transfer.
Hmmm, that was an attempt at receiving more bytes than the FIFO can
handle, but I guess the FIFO full interrupt would be more appropriate
for this.
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + sspi->base_addr = devm_request_and_ioremap(&pdev->dev, res);
> > + if (!sspi->base_addr) {
> > + dev_err(&pdev->dev, "Unable to remap IO\n");
> > + ret = -ENXIO;
> > + goto err;
> > + }
>
> devm_ioremap_resource() is nicer in that it returns an error and then
> you don't need to log either since it's noisy itself.
Ack.
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0) {
> > + dev_err(&pdev->dev, "No spi IRQ specified\n");
> > + ret = -ENXIO;
>
> Don't overwrite the error code.
Ack.
> > + ret = clk_set_rate(sspi->mclk, 100000000);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't change module clock rate\n");
> > + goto err2;
> > + }
>
> Does this really need to be fatal (or done at all)? There seems to be
> another reasonably flexible divider in the IP and it's more common to
> either set this per transfer to something that rounds nicely or just use
> the default and rely on the dividers.
The default parent of the module clock runs at 24MHz, that means that
we won't be able to reach a spi clock higher than 12MHz, which seems
quite low. We can always change the rate in the transfer setup code
though, if needs be.
> > + ret = clk_prepare_enable(sspi->mclk);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't enable clock 'ahb spi'\n");
> > + goto err2;
> > + }
>
> I would recommend moving these to runtime PM so the clocks are only
> active when the device is actually in use, the core will do the runtime
> PM management if you set auto_runtime_pm so it's really easy to
> implement.
Ok, nice.
> > + ret = reset_control_deassert(sspi->rstc);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't deassert the device from reset\n");
> > + goto err3;
> > + }
> > +
> > + sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG,
> > + SUN6I_GBL_CTL_BUS_ENABLE | SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
>
> Similarly here the IP could be kept in reset when not in use.
Ok.
Thanks a lot!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140116/59276491/attachment-0001.sig>
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Russell King - ARM Linux @ 2014-01-16 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjZzwuOvt3iV+CDXZr5-hWvay_xaO-RH5syB1D-zGVu+A@mail.gmail.com>
On Thu, Jan 16, 2014 at 12:00:47PM -0800, Olof Johansson wrote:
> On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
> >> We've dealt with it with local code in our tree for Chrome OS, and I
> >> suspect everyone else has too. It's definitely time to solve
> >> generically.
> >
> > As there's no code for any Cubox-i or Hummingboard (they're both purely
> > DT), what this means is that the answer to Wifi/BT support in mainline is
> > that this is "impossible at the moment"...
> >
> > I guess this is becoming a higher priority issue which really needs to be
> > solved somehow. :)
>
> I'm looking at it right now actually, might as well sort it out while
> people are paying attention. Patches a little later today unless I get
> distrac^Winterrupted. :)
I'll look forward to them, but I may not be able to do much more this
evening.
--
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
* How to support SDIO wifi/bt in DT
From: Olof Johansson @ 2014-01-16 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116195819.GY15937@n2100.arm.linux.org.uk>
On Thu, Jan 16, 2014 at 11:58 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
>> We've dealt with it with local code in our tree for Chrome OS, and I
>> suspect everyone else has too. It's definitely time to solve
>> generically.
>
> As there's no code for any Cubox-i or Hummingboard (they're both purely
> DT), what this means is that the answer to Wifi/BT support in mainline is
> that this is "impossible at the moment"...
>
> I guess this is becoming a higher priority issue which really needs to be
> solved somehow. :)
I'm looking at it right now actually, might as well sort it out while
people are paying attention. Patches a little later today unless I get
distrac^Winterrupted. :)
-Olof
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Russell King - ARM Linux @ 2014-01-16 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgzi5Buduo2pd0PP8CvKVir69yZ-jjX0Gbda871GiD8rg@mail.gmail.com>
On Thu, Jan 16, 2014 at 09:15:17AM -0800, Olof Johansson wrote:
> We've dealt with it with local code in our tree for Chrome OS, and I
> suspect everyone else has too. It's definitely time to solve
> generically.
As there's no code for any Cubox-i or Hummingboard (they're both purely
DT), what this means is that the answer to Wifi/BT support in mainline is
that this is "impossible at the moment"...
I guess this is becoming a higher priority issue which really needs to be
solved somehow. :)
--
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
* [PATCH 3/4] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Mark Brown @ 2014-01-16 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389892285-11745-4-git-send-email-maxime.ripard@free-electrons.com>
On Thu, Jan 16, 2014 at 06:11:24PM +0100, Maxime Ripard wrote:
Looks pretty clean, a few fairly small things below.
> +- clocks: phandle to the clocks feeding the SPI controller. Two are
> + needed:
> + - "ahb": the gated AHB parent clock
> + - "mod": the parent module clock
I guess you should specify that this needs to be done with clock-names
too then?
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
> obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
> obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
> obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
> +obj-$(CONFIG_ARCH_SUNXI) += spi-sun6i.o
I would expect a new Kconfig symbol for this.
> +static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
> +{
> + u32 reg, cnt;
> + u8 byte;
> +
> + /* See how much data are available */
data is available.
> + while (len--) {
> + byte = readb(sspi->base_addr + SUN6I_RXDATA_REG);
> + if (sspi->rx_buf)
> + *sspi->rx_buf++ = byte;
> + }
It seems like this hardware is only able to handle bidirectional
operation - this is actually quite common and isn't always as simple as
it is here. Can I persuade you to put something in the core which
provides dummy data buffers for this case? I was thinking flags like
must_tx and must_rx or something but didn't get around to this yet.
> +static int sun6i_spi_finish_transfer(struct spi_device *spi,
> + struct spi_transfer *tfr,
> + bool cs_change)
> +{
> + struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
> +
> + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
> +
> + if (tfr->delay_usecs)
> + udelay(tfr->delay_usecs);
If you implement this using transfer_one() (as you should) the core will
do this for you.
> + if (status & SUN6I_INT_CTL_RF_OVF) {
> + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
> + sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_OVF);
> + return IRQ_HANDLED;
> + }
This looks like an overflow - a log message would be helpful for users
and you should possibly be flagging an error on the current transfer.
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + sspi->base_addr = devm_request_and_ioremap(&pdev->dev, res);
> + if (!sspi->base_addr) {
> + dev_err(&pdev->dev, "Unable to remap IO\n");
> + ret = -ENXIO;
> + goto err;
> + }
devm_ioremap_resource() is nicer in that it returns an error and then
you don't need to log either since it's noisy itself.
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(&pdev->dev, "No spi IRQ specified\n");
> + ret = -ENXIO;
Don't overwrite the error code.
> + ret = clk_set_rate(sspi->mclk, 100000000);
> + if (ret) {
> + dev_err(&pdev->dev, "Couldn't change module clock rate\n");
> + goto err2;
> + }
Does this really need to be fatal (or done at all)? There seems to be
another reasonably flexible divider in the IP and it's more common to
either set this per transfer to something that rounds nicely or just use
the default and rely on the dividers.
> + ret = clk_prepare_enable(sspi->mclk);
> + if (ret) {
> + dev_err(&pdev->dev, "Couldn't enable clock 'ahb spi'\n");
> + goto err2;
> + }
I would recommend moving these to runtime PM so the clocks are only
active when the device is actually in use, the core will do the runtime
PM management if you set auto_runtime_pm so it's really easy to
implement.
> + ret = reset_control_deassert(sspi->rstc);
> + if (ret) {
> + dev_err(&pdev->dev, "Couldn't deassert the device from reset\n");
> + goto err3;
> + }
> +
> + sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG,
> + SUN6I_GBL_CTL_BUS_ENABLE | SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
Similarly here the IP could be kept in reset when not in use.
-------------- 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/20140116/523e5d60/attachment.sig>
^ permalink raw reply
* [PATCH] aarch64: always map VDSO at worst case alignment
From: Will Deacon @ 2014-01-16 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116192841.GN18705@redacted.bos.redhat.com>
On Thu, Jan 16, 2014 at 07:28:42PM +0000, Kyle McMartin wrote:
> On Thu, Jan 16, 2014 at 12:53:18PM -0500, Kyle McMartin wrote:
> > I'll reboot a machine with this fix to test it as soon as possible.
> >
> > Acked-by: Kyle McMartin <kyle@redhat.com>
> >
>
> Yeah, looks to work properly, although I didn't test 64K pages in the
> simulator.
No problem. I did try testing 64k pages in the simulator, and found that
earlyprintk is broken (now fixed).
Cheers,
Will
^ permalink raw reply
* [PATCH v3] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Will Deacon @ 2014-01-16 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1401161622570.21510@kaball.uk.xensource.com>
Hi Stefano,
On Thu, Jan 16, 2014 at 04:27:55PM +0000, Stefano Stabellini wrote:
> On Thu, 9 Jan 2014, Will Deacon wrote:
> > Ok, thanks for the explanation. Looking at the patch, I wonder whether it's
> > not cleaner just to implement xchg code separately for Xen? The Linux code
> > isn't always sufficient (due to the GENERIC_ATOMIC64 stuff) and most of the
> > churn coming out of this patch is an attempt to provide some small code
> > reuse at the cost of code readability.
> >
> > What do others think?
>
> I am OK with that, in fact my first version of the patch did just that:
>
> http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2
>
> Is that what you had in mind?
For the xchg part, yes, that looks a lot better. I don't like the #undef
CONFIG_CPU_V6 though, can that be rewritten to use __LINUX_ARM_ARCH__?
Will
^ permalink raw reply
* [PATCH] aarch64: always map VDSO at worst case alignment
From: Kyle McMartin @ 2014-01-16 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116175318.GK18705@redacted.bos.redhat.com>
On Thu, Jan 16, 2014 at 12:53:18PM -0500, Kyle McMartin wrote:
> I'll reboot a machine with this fix to test it as soon as possible.
>
> Acked-by: Kyle McMartin <kyle@redhat.com>
>
Yeah, looks to work properly, although I didn't test 64K pages in the
simulator.
--Kyle
^ permalink raw reply
* [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller
From: Mike Turquette @ 2014-01-16 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389811654-21397-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-15 10:47:20)
> The first breaks a reset-controller include ordering requirement. It got
> an ack so I think we're ok for it to go through the clock tree.
>
> The next patch adds support for setting the rate and the parent at the
> same time based on patches from James Hogan's remuxing set_rate series.
>
> After that we add MSM clock hardware support and SoC specific drivers. The DT
> node additions will be sent through the MSM maintainers once these patches are
> accepted.
Hi Stephen,
These patches look great and I've taken them into clk-next for testing.
They should get pushed out to my Linaro mirror later today and will go
in for 3.14. Thanks for spinning the revisions to this series so
quickly.
There might still be some way to share the regmap helpers in the future,
and getting these patches merged is a good starting point.
Regards,
Mike
>
> Changes since v4:
> * Moved regmap code out of the core into drivers/clk/qcom/
> * Reworked to use a wrapper clk_regmap struct
>
> Changes since v3:
> * Moved binding include to clock/
> * New patch for 8660 GCC driver
> * Renamed directory to qcom to match vendor prefix
> * Added some missing clocks in 8974 GCC driver
> * New patch for 8974 MMCC driver
>
> Changes since v2:
>
> * Completed 8960 and 8974 GCC data & dt-bindings
> * Added support for reset controllers
> * Squashed some bugs in 8974 gcc clocks
> * New patch to fix clk NULL pointer deref
> * New patch to fix #include requirement for reset-controller.h
>
> Changes since v1:
>
> * Rewrote binding to use #clock-cells=1
> * Reworked library components (pll, rcg, branch) to use regmap
> * Dropped common clock framework patches that did DT parsing
> * New patches for regmap support in common clock framework
>
> Stephen Boyd (14):
> reset: Silence warning in reset-controller.h
> clk: Add set_rate_and_parent() op
> clk: qcom: Add a regmap type clock struct
> clk: qcom: Add support for phase locked loops (PLLs)
> clk: qcom: Add support for root clock generators (RCGs)
> clk: qcom: Add support for branches/gate clocks
> clk: qcom: Add reset controller support
> clk: qcom: Add support for MSM8960's global clock controller (GCC)
> clk: qcom: Add support for MSM8960's multimedia clock controller
> (MMCC)
> clk: qcom: Add support for MSM8974's global clock controller (GCC)
> clk: qcom: Add support for MSM8974's multimedia clock controller
> (MMCC)
> clk: qcom: Add support for MSM8660's global clock controller (GCC)
> devicetree: bindings: Document qcom,gcc
> devicetree: bindings: Document qcom,mmcc
>
> Documentation/clk.txt | 3 +
> .../devicetree/bindings/clock/qcom,gcc.txt | 21 +
> .../devicetree/bindings/clock/qcom,mmcc.txt | 21 +
> drivers/clk/Kconfig | 2 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk.c | 78 +-
> drivers/clk/qcom/Kconfig | 47 +
> drivers/clk/qcom/Makefile | 14 +
> drivers/clk/qcom/clk-branch.c | 159 ++
> drivers/clk/qcom/clk-branch.h | 56 +
> drivers/clk/qcom/clk-pll.c | 222 ++
> drivers/clk/qcom/clk-pll.h | 66 +
> drivers/clk/qcom/clk-rcg.c | 517 ++++
> drivers/clk/qcom/clk-rcg.h | 159 ++
> drivers/clk/qcom/clk-rcg2.c | 291 ++
> drivers/clk/qcom/clk-regmap.c | 114 +
> drivers/clk/qcom/clk-regmap.h | 45 +
> drivers/clk/qcom/gcc-msm8660.c | 2819 ++++++++++++++++++
> drivers/clk/qcom/gcc-msm8960.c | 2993 ++++++++++++++++++++
> drivers/clk/qcom/gcc-msm8974.c | 2694 ++++++++++++++++++
> drivers/clk/qcom/mmcc-msm8960.c | 2321 +++++++++++++++
> drivers/clk/qcom/mmcc-msm8974.c | 2625 +++++++++++++++++
> drivers/clk/qcom/reset.c | 63 +
> drivers/clk/qcom/reset.h | 37 +
> include/dt-bindings/clock/qcom,gcc-msm8660.h | 276 ++
> include/dt-bindings/clock/qcom,gcc-msm8960.h | 313 ++
> include/dt-bindings/clock/qcom,gcc-msm8974.h | 320 +++
> include/dt-bindings/clock/qcom,mmcc-msm8960.h | 137 +
> include/dt-bindings/clock/qcom,mmcc-msm8974.h | 161 ++
> include/dt-bindings/reset/qcom,gcc-msm8660.h | 134 +
> include/dt-bindings/reset/qcom,gcc-msm8960.h | 118 +
> include/dt-bindings/reset/qcom,gcc-msm8974.h | 96 +
> include/dt-bindings/reset/qcom,mmcc-msm8960.h | 93 +
> include/dt-bindings/reset/qcom,mmcc-msm8974.h | 62 +
> include/linux/clk-provider.h | 15 +
> include/linux/reset-controller.h | 1 +
> 36 files changed, 17075 insertions(+), 19 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc.txt
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,mmcc.txt
> create mode 100644 drivers/clk/qcom/Kconfig
> create mode 100644 drivers/clk/qcom/Makefile
> create mode 100644 drivers/clk/qcom/clk-branch.c
> create mode 100644 drivers/clk/qcom/clk-branch.h
> create mode 100644 drivers/clk/qcom/clk-pll.c
> create mode 100644 drivers/clk/qcom/clk-pll.h
> create mode 100644 drivers/clk/qcom/clk-rcg.c
> create mode 100644 drivers/clk/qcom/clk-rcg.h
> create mode 100644 drivers/clk/qcom/clk-rcg2.c
> create mode 100644 drivers/clk/qcom/clk-regmap.c
> create mode 100644 drivers/clk/qcom/clk-regmap.h
> create mode 100644 drivers/clk/qcom/gcc-msm8660.c
> create mode 100644 drivers/clk/qcom/gcc-msm8960.c
> create mode 100644 drivers/clk/qcom/gcc-msm8974.c
> create mode 100644 drivers/clk/qcom/mmcc-msm8960.c
> create mode 100644 drivers/clk/qcom/mmcc-msm8974.c
> create mode 100644 drivers/clk/qcom/reset.c
> create mode 100644 drivers/clk/qcom/reset.h
> create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8660.h
> create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8960.h
> create mode 100644 include/dt-bindings/clock/qcom,gcc-msm8974.h
> create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8960.h
> create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8974.h
> create mode 100644 include/dt-bindings/reset/qcom,gcc-msm8660.h
> create mode 100644 include/dt-bindings/reset/qcom,gcc-msm8960.h
> create mode 100644 include/dt-bindings/reset/qcom,gcc-msm8974.h
> create mode 100644 include/dt-bindings/reset/qcom,mmcc-msm8960.h
> create mode 100644 include/dt-bindings/reset/qcom,mmcc-msm8974.h
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH v5 2/4] devicetree: bindings: Document Krait CPU/L1 EDAC
From: Stephen Boyd @ 2014-01-16 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116183326.GG25540@e102568-lin.cambridge.arm.com>
On 01/16, Lorenzo Pieralisi wrote:
> On Thu, Jan 16, 2014 at 06:05:05PM +0000, Stephen Boyd wrote:
> > On 01/16, Lorenzo Pieralisi wrote:
> > > Do we really want to do that ? I am not sure. A cpus node is supposed to
> > > be a container node, we should not define this binding just because we
> > > know the kernel creates a platform device for it then.
> >
> > This is just copying more of the ePAPR spec into this document.
> > It just so happens that having a compatible field here allows a
> > platform device to be created. I don't see why that's a problem.
>
> I do not see why you cannot define a node like pmu or arch-timer and stick
> a compatible property in there. cpus node does not represent a device, and
> must not be created as a platform device, that's my opinion.
>
I had what you're suggesting before in the original revision of
this patch. Please take a look at the original patch series[1]. I
suppose it could be tweaked slightly to still have a cache node
for the L2 interrupt and the next-level-cache pointer from the
CPUs.
> What would you do for big.LITTLE systems ? We are going to create two
> cpus node because we need two platform devices ? I really think there
> must be a better way to implement this, but I will let DT maintainers
> make a decision.
There is no such thing as big.LITTLE for Krait, so this is not a
concern.
>
> > > interrupts is a cpu node property and I think it should be kept as such.
> > >
> > > I know it will be duplicated and I know you can't rely on a platform
> > > device for probing (since if I am not mistaken, removing a compatible
> > > string from cpus prevents its platform device creation), but that's an issue
> > > related to how the kernel works, you should not define DT bindings to solve
> > > that IMHO.
> >
> > The interrupts property is also common for all cpus so it seems
> > fine to collapse the value down into a PPI specifier indicating
> > that all CPUs get the interrupt, similar to how we compress the
> > information about the compatible string.
>
> I think it is nicer to create a device node (as I said, like a pmu or an
> arch-timer) and define interrupts there along with a proper compatible
> property. This would serve the same purpose without adding properties in
> the cpus node.
>
> cpu-edac {
> compatible = "qcom,cpu-edac";
> interrupts = <...>;
> };
Yes, please see the original thread.
[1] https://lkml.org/lkml/2013/10/29/134
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [GIT PULL] arm64 revert for 3.13
From: Catalin Marinas @ 2014-01-16 18:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
If there's still time for 3.13, could you please pull the one-line
revert below? We noticed that it breaks ioremap (and earlyprintk) with
64K page configuration. Thanks.
The following changes since commit cdc27c27843248ae7eb0df5fc261dd004eaa5670:
arm64: ptrace: avoid using HW_BREAKPOINT_EMPTY for disabled events (2013-12-19 17:41:25 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to 4ce00dfcf19c473f3dbf23d5b1372639f0c334f6:
Revert "arm64: Fix memory shareability attribute for ioremap_wc/cache" (2014-01-16 18:32:25 +0000)
----------------------------------------------------------------
Revert "arm64: Fix memory shareability attribute for ioremap_wc/cache"
----------------------------------------------------------------
Catalin Marinas (1):
Revert "arm64: Fix memory shareability attribute for ioremap_wc/cache"
arch/arm64/include/asm/io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ 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