* [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
From: Florian Vaussard @ 2013-02-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=k_gwB3ExQYUeappDZ6FE4L7x8Acer4ZQpDH09BL6LG0Q@mail.gmail.com>
Hi Javier,
On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
> Hi Florian,
>
> On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
> <florian.vaussard@epfl.ch> wrote:
>> Add device-tree support for the GPMC controller on the OMAP3.
>>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>> ---
>> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 6c63118..2ddae38 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -403,5 +403,16 @@
>> ti,timer-alwon;
>> ti,timer-secure;
>> };
>> +
>> + gpmc: gpmc at 6e000000 {
>> + compatible = "ti,omap3430-gpmc";
>> + ti,hwmods = "gpmc";
>> + reg = <0x6e000000 0x1000000>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + };
>> };
>> };
>
> I had the same patch on a tree I was working on to add DT support for
> gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
> to hit mainline before sending the RFC. So please feel free to add:
>
> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>
Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
do you have a public git for this, so I can test your work on my setup?
For the GPMC support, I will have to make a few more more as discussed with
Tony, and as I will be away for more than 2 weeks, feel free to go ahead
before me. This patchset was only at an RFC stage.
Regards,
Florian
^ permalink raw reply
* [PATCH v5 04/10] clk: tegra: Add new fields and PLL types for Tegra114
From: Peter De Schrijver @ 2013-02-04 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F56B1.5060409@nvidia.com>
On Mon, Feb 04, 2013 at 07:35:29AM +0100, Prashant Gaikwad wrote:
> On Saturday 02 February 2013 01:10 AM, Rhyland Klein wrote:
> > On 2/1/2013 5:18 AM, Peter De Schrijver wrote:
> >> Tegra114 introduces new PLL types. This requires new clocktypes as well
> >> as some new fields in the pll structure.
> >>
> >> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> >> ---
> >> drivers/clk/tegra/clk-pll.c | 719 +++++++++++++++++++++++++++++++++++++++++++
> >> drivers/clk/tegra/clk.h | 47 +++
> >> 2 files changed, 766 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
> >> index 87d2f34..50114b7 100644
> >> --- a/drivers/clk/tegra/clk-pll.c
> >> +++ b/drivers/clk/tegra/clk-pll.c
> >> [snip]
> >> +struct clk *tegra_clk_register_pllxc(const char *name, const char *parent_name,
> >> + void __iomem *clk_base, void __iomem *pmc,
> >> + unsigned long flags, unsigned long fixed_rate,
> >> + struct tegra_clk_pll_params *pll_params,
> >> + u32 pll_flags,
> >> + struct tegra_clk_pll_freq_table *freq_table,
> >> + spinlock_t *lock)
> >> +{
> >> + if (!pll_params->pdiv_tohw)
> >> + return -EINVAL;
> >> +
> > This will cause the following warning:
> > warning: return makes pointer from integer without a cast
> >
> > Same with occurrences in tegra_clk_register_pllm and
> > tegra_clk_register_pllc.
> >
> > Should this instead be returning NULL?
>
> return ERR_PTR(-EINVAL)
>
Indeed. I noticed that only after I sent this patchset. Already fixed in
my own tree.
Cheers,
Peter.
^ permalink raw reply
* [PATCH v5 09/10] clk: tegra: Implement clocks for Tegra114
From: Peter De Schrijver @ 2013-02-04 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F5E87.90801@nvidia.com>
On Mon, Feb 04, 2013 at 08:08:55AM +0100, Prashant Gaikwad wrote:
...
> > +#define RST_DEVICES_L 0x004
> > +#define RST_DEVICES_H 0x008
> > +#define RST_DEVICES_U 0x00C
> > +#define RST_DEVICES_V 0x358
> > +#define RST_DEVICES_W 0x35C
> > +#define RST_DEVICES_X 0x28C
> > +#define RST_DEVICES_SET_L 0x300
> > +#define RST_DEVICES_CLR_L 0x304
> > +#define RST_DEVICES_SET_H 0x308
> > +#define RST_DEVICES_CLR_H 0x30c
> > +#define RST_DEVICES_SET_U 0x310
> > +#define RST_DEVICES_CLR_U 0x314
> > +#define RST_DEVICES_SET_V 0x430
> > +#define RST_DEVICES_CLR_V 0x434
> > +#define RST_DEVICES_SET_W 0x438
> > +#define RST_DEVICES_CLR_W 0x43c
> > +#define RST_DEVICES_NUM 5
>
> RST_DEVICES_SET/CLR_X?
>
For all I can see (from the not yet public TRM), this is not actually used?
So I decided to not mention it here.
> > +
> > +#define CLK_OUT_ENB_L 0x010
> > +#define CLK_OUT_ENB_H 0x014
> > +#define CLK_OUT_ENB_U 0x018
> > +#define CLK_OUT_ENB_V 0x360
> > +#define CLK_OUT_ENB_W 0x364
> > +#define CLK_OUT_ENB_X 0x280
> > +#define CLK_OUT_ENB_SET_L 0x320
> > +#define CLK_OUT_ENB_CLR_L 0x324
> > +#define CLK_OUT_ENB_SET_H 0x328
> > +#define CLK_OUT_ENB_CLR_H 0x32c
> > +#define CLK_OUT_ENB_SET_U 0x330
> > +#define CLK_OUT_ENB_CLR_U 0x334
> > +#define CLK_OUT_ENB_SET_V 0x440
> > +#define CLK_OUT_ENB_CLR_V 0x444
> > +#define CLK_OUT_ENB_SET_W 0x448
> > +#define CLK_OUT_ENB_CLR_W 0x44c
> > +#define CLK_OUT_ENB_SET_X 0x284
> > +#define CLK_OUT_ENB_CLR_X 0x288
> > +#define CLK_OUT_ENB_NUM 6
>
> <snip>
>
> > +
> > + /* dsia */
> > + clk = clk_register_mux(NULL, "dsia_mux", mux_plld_out0_plld2_out0,
> > + ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
> > + clk_base + PLLD_BASE, 25, 1, 0, &pll_d_lock);
> > + clks[dsia_mux] = clk;
> > + clk = tegra_clk_register_periph_gate("dsia", "dsia_mux", 0, clk_base,
> > + 0, 48, &periph_h_regs,
> > + periph_clk_enb_refcnt);
> > + clk_register_clkdev(clk, "dsia", "tegradc.0");
> > + clks[dsia] = clk;
> > +
> > + /* dsib */
> > + clk = clk_register_mux(NULL, "dsib_mux", mux_plld_out0_plld2_out0,
> > + ARRAY_SIZE(mux_plld_out0_plld2_out0), 0,
> > + clk_base + PLLD2_BASE, 25, 1, 0, &pll_d2_lock);
> > + clks[dsib_mux] = clk;
> > + clk = tegra_clk_register_periph_gate("dsib", "dsib_mux", 0, clk_base,
> > + 0, 82, &periph_u_regs,
> > + periph_clk_enb_refcnt);
> > + clk_register_clkdev(clk, "dsib", "tegradc.1");
> > + clks[dsib] = clk;
> > +
>
> Can we use periph no div clock here for dsia and dsib?
>
Will check.
> > + /* xusb_hs_src */
> > + val = readl(clk_base + CLK_SOURCE_XUSB_SS_SRC);
> > + val |= BIT(25); /* always select PLLU_60M */
> > + writel(val, clk_base + CLK_SOURCE_XUSB_SS_SRC);
> > +
> > + clk = clk_register_fixed_factor(NULL, "xusb_hs_src", "pll_u_60M", 0,
> > + 1, 1);
> > + clks[xusb_hs_src] = clk;
> > +
>
> With device tree we can directly use pll_u_60M, no need to register
> clock with fixed factor 1.
This is true for now. In the future these clocks will need to be dvfs aware
though. I think it makes sense to have a separate clock then?
> Same comment for dis1-fixed, dsi2-fixed and mipi-cal-fast clocks.
>
Those might not need to become dvfs aware.
> > + /* xusb_host */
> > + clk = tegra_clk_register_periph_gate("xusb_host", "xusb_host_src", 0,
> > + clk_base, 0, 89, &periph_u_regs,
> > + periph_clk_enb_refcnt);
> > + clk_register_clkdev(clk, "tegra_xhci", "host");
> > + clks[xusb_host] = clk;
> > +
> > + /* xusb_ss */
> > + clk = tegra_clk_register_periph_gate("xusb_ss", "xusb_ss_src", 0,
> > + clk_base, 0, 156, &periph_w_regs,
> > + periph_clk_enb_refcnt);
> > + clk_register_clkdev(clk, "tegra_xhci", "ss");
> > + clks[xusb_host] = clk;
> > +
> > + /* xusb_dev */
> > + clk = tegra_clk_register_periph_gate("xusb_dev", "xusb_dev_src", 0,
> > + clk_base, 0, 95, &periph_u_regs,
> > + periph_clk_enb_refcnt);
> > + clk_register_clkdev(clk, "tegra_xhci", "dev");
>
> clks[xusb_dev] = clk;
>
Missing indeed.
Cheers,
Peter.
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Russell King - ARM Linux @ 2013-02-04 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F16C9.2060901@oberhumer.com>
On Mon, Feb 04, 2013 at 03:02:49AM +0100, Markus F.X.J. Oberhumer wrote:
> At least akpm did approve the LZO update for inclusion into 3.7, but the code
> still has not been merged into the main tree.
> > On 2012-10-09 21:26, Andrew Morton wrote:
> > [...]
> > The changes look OK to me. Please ask Stephen to include the tree in
> > linux-next, for a 3.7 merge.
>
> Well, this probably means I have done a rather poor marketing.
I assume this code is sitting in *your* tree? How do you think it gets
into mainline?
There is no automatic way that code from linux-next gets merged into
mainline. That is up to the tree owner to make happen, either by getting
their tree into a parent maintainers tree, or if there is none, asking
Linus to pull your tree at the appropriate time.
^ permalink raw reply
* [PATCH 1/2] ARM: tegra: Fix build error for gic update
From: Hiroshi Doyu @ 2013-02-04 11:08 UTC (permalink / raw)
To: linux-arm-kernel
Fix build error in board-dt-tegra114.c(next-20130204)
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
Reported-by: Sami Liedes<sliedes@nvidia.com>
---
arch/arm/mach-tegra/board-dt-tegra114.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board-dt-tegra114.c b/arch/arm/mach-tegra/board-dt-tegra114.c
index 3ed17ce..72598e2 100644
--- a/arch/arm/mach-tegra/board-dt-tegra114.c
+++ b/arch/arm/mach-tegra/board-dt-tegra114.c
@@ -19,7 +19,6 @@
#include <linux/clocksource.h>
#include <asm/mach/arch.h>
-#include <asm/hardware/gic.h>
#include "board.h"
#include "common.h"
@@ -39,7 +38,6 @@ DT_MACHINE_START(TEGRA114_DT, "NVIDIA Tegra114 (Flattened Device Tree)")
.map_io = tegra_map_common_io,
.init_early = tegra30_init_early,
.init_irq = tegra_dt_init_irq,
- .handle_irq = gic_handle_irq,
.init_time = clocksource_of_init,
.init_machine = tegra114_dt_init,
.init_late = tegra_init_late,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] regmap: Fix build error next-20130204
From: Hiroshi Doyu @ 2013-02-04 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359976100-28871-1-git-send-email-hdoyu@nvidia.com>
In function 'regmap_async_complete_cb':
1656:3: error: 'TASK_NORMAL' undeclared (first use in this function)
In function 'regmap_async_complete':
1688:2: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function)
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
drivers/base/regmap/regmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index bee8560..49ec460 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -16,6 +16,8 @@
#include <linux/mutex.h>
#include <linux/err.h>
#include <linux/rbtree.h>
+#include <linux/sched.h>
+#include <linux/wait.h>
#define CREATE_TRACE_POINTS
#include <trace/events/regmap.h>
--
1.7.9.5
^ permalink raw reply related
* Fwd: [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
From: YUVARAJ CD @ 2013-02-04 11:09 UTC (permalink / raw)
To: linux-arm-kernel
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130204/55a41f98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file0.gif
Type: image/gif
Size: 14036 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130204/55a41f98/attachment-0001.gif>
^ permalink raw reply
* [PATCH v4] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses
From: R Sricharan @ 2013-02-04 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F3CA3.7080604@ti.com>
Hi,
On Monday 04 February 2013 10:14 AM, R Sricharan wrote:
> On Monday 04 February 2013 10:10 AM, R Sricharan wrote:
>> Hi Catalin,
>>
>> [ snip..]
>>>
>>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>>> index 9f06102..47154f3 100644
>>> --- a/arch/arm/mm/mmu.c
>>> +++ b/arch/arm/mm/mmu.c
>>> @@ -581,34 +581,36 @@ static void __init alloc_init_section(pud_t
>>> *pud, unsigned long addr,
>>> const struct mem_type *type)
>>> {
>>> pmd_t *pmd = pmd_offset(pud, addr);
>>> + unsigned long next;
>>>
>>> - /*
>>> - * Try a section mapping - end, addr and phys must all be aligned
>>> - * to a section boundary. Note that PMDs refer to the individual
>>> - * L1 entries, whereas PGDs refer to a group of L1 entries making
>>> - * up one logical pointer to an L2 table.
>>> - */
>>> - if (type->prot_sect && ((addr | end | phys) & ~SECTION_MASK) ==
>>> 0) {
>>> - pmd_t *p = pmd;
>>> + do {
>>> + next = pmd_addr_end(addr, end);
>>> +
>>> + /*
>>> + * Try a section mapping - next, addr and phys must all be
>>> + * aligned to a section boundary. Note that PMDs refer to the
>>> + * individual L1 entries, whereas PGDs refer to a group of L1
>>> + * entries making up one logical pointer to an L2 table.
>>> + */
>>> + if (((addr | next | phys) & ~SECTION_MASK) == 0) {
>>> + pmd_t *p = pmd;
>>>
>> There is a need to do page mappings even when all the addresses
>> are aligned. This was added with CMA, which required the initial
>> mappings to be set with 2 level tables.
>>
> Sorry, i wanted to ask type->prot_sect is removed here and is that
> intentional?
Tested this patch on OMAP5. The type->prot_sect check is
required, without which mappings are not even created for CMA.
(ie) type->prot_sect is not set when this function is called
in CMA context, thus no valid mapping is created.
After fixing this, the LPAE + CMA enabled combination booted
fine on OMAP5.
Regards,
Sricharan
^ permalink raw reply
* [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
From: Yuvaraj Kumar @ 2013-02-04 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359968595-21291-1-git-send-email-yuvaraj.cd@samsung.com>
Below are the links on multi master bus arbitration where it has been
discussing.
http://comments.gmane.org/gmane.linux.kernel/1410276
http://www.kernelhub.org/?msg=179505&p=2
On Mon, Feb 4, 2013 at 2:33 PM, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote:
> This RFC patch is w.r.t multimaster bus arbitration which is already
> being discussing in the mainline.
> This patch provides hooks for the i2c multimaster bus arbitration
> and to have the arbitration parameters.
>
> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
> ---
> drivers/i2c/i2c-core.c | 13 ++++++++++++-
> include/linux/i2c.h | 12 ++++++++++++
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index e388590..ed89fc8 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1408,18 +1408,29 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> (msgs[ret].flags & I2C_M_RECV_LEN) ? "+" : "");
> }
> #endif
> + if (adap->mm_arbit_algo) {
> + ret = adap->mm_arbit_algo->i2c_mm_bus_get(adap);
> + if (ret)
> + /* I2C bus under control of another master. */
> + return -EAGAIN;
> + }
>
> if (in_atomic() || irqs_disabled()) {
> ret = i2c_trylock_adapter(adap);
> - if (!ret)
> + if (!ret && adap->mm_arbit_algo) {
> + adap->mm_arbit_algo->i2c_mm_bus_release(adap);
> +
> /* I2C activity is ongoing. */
> return -EAGAIN;
> + }
> } else {
> i2c_lock_adapter(adap);
> }
>
> ret = __i2c_transfer(adap, msgs, num);
> i2c_unlock_adapter(adap);
> + if (adap->mm_arbit_algo)
> + adap->mm_arbit_algo->i2c_mm_bus_release(adap);
>
> return ret;
> } else {
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index d0c4db7..61fbfe3 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -371,6 +371,17 @@ struct i2c_algorithm {
> };
>
> /*
> + *This struct provides hooks for i2c multi-master arbitration needs.
> + */
> +struct i2c_mm_arbitration {
> + void *arbitration_data;
> +
> + /* Should return 0 if mastership could be successfully established */
> + int (*i2c_mm_bus_get)(struct i2c_adapter *adap);
> + void (*i2c_mm_bus_release)(struct i2c_adapter *adap);
> +};
> +
> +/*
> * i2c_adapter is the structure used to identify a physical i2c bus along
> * with the access algorithms necessary to access it.
> */
> @@ -393,6 +404,7 @@ struct i2c_adapter {
>
> struct mutex userspace_clients_lock;
> struct list_head userspace_clients;
> + struct i2c_mm_arbitration *mm_arbit_algo;
> };
> #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
>
> --
> 1.7.9.5
>
^ permalink raw reply
* sg_is_chain() call in coh901318_lli_fill_sg()
From: Bart Van Assche @ 2013-02-04 11:33 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm trying to understand how coh901318_lli_fill_sg() works by studying
the source code of that function. In that function I found the following
code:
for_each_sg(sgl, sg, nents, i) {
if (sg_is_chain(sg)) {
[ ... ]
Can anyone explain me why that construct makes sense ? As far as I can
see in lib/scatterlist.c sg_next() ensures that the for_each_sg() skips
those elements for which sg_is_chain(sg) == true. Does that mean that
sg_is_chain(sg) always evaluates to false in the above loop ?
Thanks,
Bart.
^ permalink raw reply
* [BUG] kernel oops in pin_request
From: Jack Mitchell @ 2013-02-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
I am developing a driver located at [1]. The driver has two devices on a
single SPI bus. When the devices are probed the pins for the SPI bus get
requested twice, as so:
pinctrl = devm_pinctrl_get_select_default(&spi->dev);
if (IS_ERR(pinctrl))
{
pr_debug("%s: Setting pins failed: %d\n", __func__, (s32) pinctrl);
}
The driver is DT only, and as such gets it's pins and setup from the DT
[2]. When the second request happens I get the following output the
kernel log:
Jan 25 15:04:54 beaglebone user.err kernel: [ 67.319188]
pinctrl-single 44e10800.pinmux: pin 44e1099c already requested by
48030000.spi; cannot claim for spi2.1
Jan 25 15:04:54 beaglebone user.err kernel: [ 67.330496]
pinctrl-single 44e10800.pinmux: pin-103 (spi2.1) status -22
Jan 25 15:04:54 beaglebone user.err kernel: [ 67.337555]
pinctrl-single 44e10800.pinmux: could not request pin 103 on device
pinctrl-single
Which I guess is ok as the first probe already setup the pins,
everything then works as it should. Now, when I come to unload + reload
the module I get an oops regarding the strmcmp() in pin_request:
Jan 25 15:13:25 beaglebone user.debug kernel: [ 578.600746]
r0005spi_probe: SPI Bus 2 probed
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.605991] Unable to
handle kernel NULL pointer dereference at virtual address 00000000
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.614641] pgd = cf570000
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.617578] [00000000]
*pgd=8d93a831, *pte=00000000, *ppte=00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.624347] Internal
error: Oops: 17 [#1] SMP ARM
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.629303] Modules
linked in: r0005spi(O+) [last unloaded: r0005spi]
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.636135] CPU: 0
Tainted: G O (3.8.0-rc5-00538-g2431418-dirty #7)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.644031] PC is at
strcmp+0x4/0x3c
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.647807] LR is at
pin_request+0xb0/0x1e8
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] pc :
[<c0295ac0>] lr : [<c02a94fc>] psr: a0000013
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] sp :
cf4dfd38 ip : 00000000 fp : ffffffff
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.664290] r10:
00000000 r9 : 00000000 r8 : 00000059
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.669792] r7 :
cf33fe00 r6 : c08413f0 r5 : cf0bb680 r4 : cf0a2280
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.676659] r3 :
00000000 r2 : 00000000 r1 : cf33fe00 r0 : 00000000
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.683531] Flags: NzCv
IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.691038] Control:
10c5387d Table: 8f570019 DAC: 00000015
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.697087] Process
insmod (pid: 566, stack limit = 0xcf4de240)
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.703318] Stack:
(0xcf4dfd38 to 0xcf4e0000)
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.708307] fd20:
cf0a2280 00000059
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.717039] fd40:
cf33fe00 00000000 cf0a2280 cf52ebc0 c0af6010 c08413f0 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.725735] fd60:
00000001 c02a99d8 cf756e90 00000003 cf4dfda0 cf52ebc0 cf52ed0c cf756cc0
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.734427] fd80:
c0af6010 cf52ed00 bf005650 c02a8018 cf5dfac0 c08411c4 cf756cc0 cf52ed00
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.743121] fda0:
c0af6010 c02a8074 cf756c00 cf756cc0 cf335600 bf005218 cf335600 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.751862] fdc0:
cf335600 bf005b8c bf005b8c c031e1c0 00000001 c037e678 c037e660 c031dfac
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.764322] fde0:
bf005b8c cf335600 cf335600 cf335634 bf005b8c c031e228 00000000 cf4dfe08
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.773168] fe00:
bf005b8c c031c53c cf0b5478 cf334880 bf005b8c bf005b8c c0852258 cf4155c0
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.781877] fe20:
00000000 c031d5c4 bf00594c cf0a2488 bf005b8c cf4dff58 00000000 bf005d3c
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.790570] fe40:
00000001 c031e71c 00000000 bf005d30 cf4dff58 00000000 bf005d3c 00000001
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.799262] fe60:
bf005650 c0008878 bf005650 00000000 00000001 bf005d30 bf005d30 cf4dff58
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.817450] fe80:
00000000 bf005d3c 00000001 cf6e9880 bf005d78 c008b928 bf005d3c 00007fff
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.826624] fea0:
c02a5ed0 00000053 c0875738 0000001c 00000000 c0088aac c07fab0c bf005e84
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.835756] fec0:
c0534e14 d09f6970 cf4dfee4 00022008 20000013 c0753164 cf4dff14 c0529a18
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.844875] fee0:
d09f9000 b6fca000 00000751 00000000 00000000 00000000 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.853984] ff00:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.863087] ff20:
00000000 00000000 000000d2 b6fc0000 0000a7d1 00022008 00000080 c000e364
Jan 25 15:13:25 beaglebone user.debug kernel: [ 578.600746]
r0005spi_probe: SPI Bus 2 probed
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.605991] Unable to
handle kernel NULL pointer dereference at virtual address 00000000
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.614641] pgd = cf570000
Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.617578] [00000000]
*pgd=8d93a831, *pte=00000000, *ppte=00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.624347] Internal
error: Oops: 17 [#1] SMP ARM
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.629303] Modules
linked in: r0005spi(O+) [last unloaded: r0005spi]
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.636135] CPU: 0
Tainted: G O (3.8.0-rc5-00538-g2431418-dirty #7)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.644031] PC is at
strcmp+0x4/0x3c
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.647807] LR is at
pin_request+0xb0/0x1e8
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] pc :
[<c0295ac0>] lr : [<c02a94fc>] psr: a0000013
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] sp :
cf4dfd38 ip : 00000000 fp : ffffffff
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.664290] r10:
00000000 r9 : 00000000 r8 : 00000059
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.669792] r7 :
cf33fe00 r6 : c08413f0 r5 : cf0bb680 r4 : cf0a2280
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.676659] r3 :
00000000 r2 : 00000000 r1 : cf33fe00 r0 : 00000000
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.683531] Flags: NzCv
IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.691038] Control:
10c5387d Table: 8f570019 DAC: 00000015
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.697087] Process
insmod (pid: 566, stack limit = 0xcf4de240)
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.703318] Stack:
(0xcf4dfd38 to 0xcf4e0000)
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.708307] fd20:
cf0a2280 00000059
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.717039] fd40:
cf33fe00 00000000 cf0a2280 cf52ebc0 c0af6010 c08413f0 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.725735] fd60:
00000001 c02a99d8 cf756e90 00000003 cf4dfda0 cf52ebc0 cf52ed0c cf756cc0
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.734427] fd80:
c0af6010 cf52ed00 bf005650 c02a8018 cf5dfac0 c08411c4 cf756cc0 cf52ed00
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.743121] fda0:
c0af6010 c02a8074 cf756c00 cf756cc0 cf335600 bf005218 cf335600 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.751862] fdc0:
cf335600 bf005b8c bf005b8c c031e1c0 00000001 c037e678 c037e660 c031dfac
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.764322] fde0:
bf005b8c cf335600 cf335600 cf335634 bf005b8c c031e228 00000000 cf4dfe08
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.773168] fe00:
bf005b8c c031c53c cf0b5478 cf334880 bf005b8c bf005b8c c0852258 cf4155c0
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.781877] fe20:
00000000 c031d5c4 bf00594c cf0a2488 bf005b8c cf4dff58 00000000 bf005d3c
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.790570] fe40:
00000001 c031e71c 00000000 bf005d30 cf4dff58 00000000 bf005d3c 00000001
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.799262] fe60:
bf005650 c0008878 bf005650 00000000 00000001 bf005d30 bf005d30 cf4dff58
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.817450] fe80:
00000000 bf005d3c 00000001 cf6e9880 bf005d78 c008b928 bf005d3c 00007fff
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.826624] fea0:
c02a5ed0 00000053 c0875738 0000001c 00000000 c0088aac c07fab0c bf005e84
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.835756] fec0:
c0534e14 d09f6970 cf4dfee4 00022008 20000013 c0753164 cf4dff14 c0529a18
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.844875] fee0:
d09f9000 b6fca000 00000751 00000000 00000000 00000000 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.853984] ff00:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.863087] ff20:
00000000 00000000 000000d2 b6fc0000 0000a7d1 00022008 00000080 c000e364
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.872190] ff40:
cf4de000 00000000 00000000 c008bce8 00000002 c0529780 d09ef000 0000a7d1
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.881468] ff60:
d09f6420 d09f62c8 d09f92f8 00000e98 00001218 bf005bc8 0000000f 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.890834] ff80:
00000022 00000023 0000000e 00000009 00000007 00000000 00000000 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.899961] ffa0:
00022da8 c000e1e0 00000000 00000000 b6fc0000 0000a7d1 00022008 00022da8
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.909073] ffc0:
00000000 00000000 00022da8 00000080 00022098 0000a7d1 00022008 00000000
Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.918243] ffe0:
4ff71978 bed65ba8 4ff60790 4fe2e870 60000010 b6fc0000 00000000 00000000
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.927032] [<c0295ac0>]
(strcmp+0x4/0x3c) from [<c02a94fc>] (pin_request+0xb0/0x1e8)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.935371] [<c02a94fc>]
(pin_request+0xb0/0x1e8) from [<c02a99d8>]
(pinmux_enable_setting+0x74/0x1a4)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.945369] [<c02a99d8>]
(pinmux_enable_setting+0x74/0x1a4) from [<c02a8018>]
(pinctrl_select_state_locked+0xb8/0xf0)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.956637] [<c02a8018>]
(pinctrl_select_state_locked+0xb8/0xf0) from [<c02a8074>]
(pinctrl_select_state+0x24/0x3c)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.967743] [<c02a8074>]
(pinctrl_select_state+0x24/0x3c) from [<bf005218>]
(r0005spi_probe+0xfc/0x310 [r0005spi])
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.978751] [<bf005218>]
(r0005spi_probe+0xfc/0x310 [r0005spi]) from [<c037e678>]
(spi_drv_probe+0x18/0x1c)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.989093] [<c037e678>]
(spi_drv_probe+0x18/0x1c) from [<c031dfac>]
(driver_probe_device+0x11c/0x330)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.998970] [<c031dfac>]
(driver_probe_device+0x11c/0x330) from [<c031e228>]
(__driver_attach+0x68/0x8c)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.009125] [<c031e228>]
(__driver_attach+0x68/0x8c) from [<c031c53c>] (bus_for_each_dev+0x48/0x80)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.018774] [<c031c53c>]
(bus_for_each_dev+0x48/0x80) from [<c031d5c4>] (bus_add_driver+0xf0/0x248)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.028379] [<c031d5c4>]
(bus_add_driver+0xf0/0x248) from [<c031e71c>] (driver_register+0x9c/0x12c)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.037982] [<c031e71c>]
(driver_register+0x9c/0x12c) from [<c0008878>] (do_one_initcall+0x90/0x160)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.047681] [<c0008878>]
(do_one_initcall+0x90/0x160) from [<c008b928>] (load_module+0x1b64/0x1e28)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.057284] [<c008b928>]
(load_module+0x1b64/0x1e28) from [<c008bce8>] (sys_init_module+0xfc/0x11c)
Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.066891] [<c008bce8>]
(sys_init_module+0xfc/0x11c) from [<c000e1e0>] (ret_fast_syscall+0x0/0x30)
The pin_request portion of that driver where the traceback points to is
as so:
dev_dbg(pctldev->dev, "request pin %d (%s) for %s\n",
pin, desc->name, owner);
if (gpio_range) {
/* There's no need to support multiple GPIO requests */
if (desc->gpio_owner) {
dev_err(pctldev->dev,
"pin %s already requested by %s; cannot claim for %s\n",
desc->name, desc->gpio_owner, owner);
goto out;
}
desc->gpio_owner = owner;
} else {
if (desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
dev_err(pctldev->dev,
"pin %s already requested by %s; cannot claim for %s\n",
desc->name, desc->mux_owner, owner);
goto out;
}
desc->mux_usecount++;
if (desc->mux_usecount > 1)
return 0;
desc->mux_owner = owner;
}
From what I can gather that means that desc->mux_owner or owner must be
an invalid pointer. Is this a bug, or am I abusing the interface in some
subtle way?
[1] https://pastee.org/vyaz4
[2] https://pastee.org/6e2nt
Regards,
Jack.
--
Jack Mitchell (jack at embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry
From: Sekhar Nori @ 2013-02-04 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359016695-10362-3-git-send-email-anilkumar.v@ti.com>
Hi Anil,
On 1/24/2013 2:08 PM, Kumar, Anil wrote:
> Add OF_DEV_AUXDATA for wdt driver in da850 board dt
> file to use wdt clock.
>
> Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
> ---
> :100644 100644 37c27af... 1b295d2... M arch/arm/mach-davinci/da8xx-dt.c
> arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index 37c27af..1b295d2 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
> of_irq_init(da8xx_irq_match);
> }
>
> +struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
Auxdata is not evm specific. This can instead be called da850_auxdata_lookup[].
Also, I dont think it is necessary to add auxdata in a separate patch
from dt nodes. So, I fixed these issues and came up with below patch. I
tested basic wdt reboot. reboot command is still broken (with or
without this patch). Can you please look at that?
Thanks,
Sekhar
----8<----
From: "Kumar, Anil" <anilkumar.v@ti.com>
Date: Thu, 24 Jan 2013 14:08:14 +0530
Subject: [PATCH 1/1] ARM: davinci: da850: add wdt DT node
Add da850 wdt DT node.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 5 +++++
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index fa04152..cc777dc 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -30,6 +30,9 @@
rtc0: rtc at 1c23000 {
status = "okay";
};
+ wdt: wdt at 1c21000 {
+ status = "okay";
+ };
};
nand_cs3 at 62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8dd15c0..2800090 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -88,6 +88,11 @@
19>;
status = "disabled";
};
+ wdt: wdt at 1c21000 {
+ compatible = "ti,davinci-wdt";
+ reg = <0x21000 0xfff>;
+ status = "disabled";
+ };
};
nand_cs3 at 62000000 {
compatible = "ti,davinci-nand";
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..90c3c69 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "watchdog", NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
From: Javier Martinez Canillas @ 2013-02-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F8F49.9020800@epfl.ch>
On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Hi Javier,
>
>
Hi Florian,
> On 02/04/2013 10:27 AM, Javier Martinez Canillas wrote:
>>
>> Hi Florian,
>>
>> On Mon, Jan 28, 2013 at 6:54 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>>
>>> Add device-tree support for the GPMC controller on the OMAP3.
>>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>>> ---
>>> arch/arm/boot/dts/omap3.dtsi | 11 +++++++++++
>>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>>> index 6c63118..2ddae38 100644
>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>> @@ -403,5 +403,16 @@
>>> ti,timer-alwon;
>>> ti,timer-secure;
>>> };
>>> +
>>> + gpmc: gpmc at 6e000000 {
>>> + compatible = "ti,omap3430-gpmc";
>>> + ti,hwmods = "gpmc";
>>> + reg = <0x6e000000 0x1000000>;
>>> + interrupts = <20>;
>>> + gpmc,num-cs = <8>;
>>> + gpmc,num-waitpins = <4>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + };
>>> };
>>> };
>>
>>
>> I had the same patch on a tree I was working on to add DT support for
>> gpmc-smsc911x on an OMAP3 board but I was waiting for Daniel's patches
>> to hit mainline before sending the RFC. So please feel free to add:
>>
>> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>
> Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
> do you have a public git for this, so I can test your work on my setup?
>
Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]
That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
linux-omap-dt/for_3.9/dts
plus these patches:
Javier Martinez Canillas (4):
ARM: OMAP: gpmc-smsc911x: add DT dev node init function
ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
ARM: dts: OMAP: Add an GPMC node for OMAP3
ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
You can browse these patches here [2].
With these patches I have ethernet working on my IGEPv2 but this board
uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
poll mode.
For some reasons I still couldn't figure out (I'm still learning about
Device Trees) adding:
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
didn't have a functional effect and I had to initialize the defined
pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
instead of pmc_smsc911x at 0 as I do for other devices (mmc, uarts, etc).
So I just removed the devm_pinctrl_get_select_default() call in
gpmc_smsc911x_init_dt() in for this RFC.
I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
not a real platform driver (is just a wrapper/helper function) and
doesn't have a probe function.
Which brings me to the question if my approach of adding a binding for
gpmc-smsc911x is correct or if we should extend/use the binding that
already exist for smsc911x
(Documentation/devicetree/bindings/net/smsc911x.txt).
> For the GPMC support, I will have to make a few more more as discussed with
> Tony, and as I will be away for more than 2 weeks, feel free to go ahead
> before me. This patchset was only at an RFC stage.
>
> Regards,
>
> Florian
>
Yes, I saw on the list that Tony asked you too extend the GPMC DT
support. Flash support is on my TODO list too but I don't know if I'm
going to have time to work on this in the next few weeks.
Since you are thinking to change the binding, there is something I
want to discuss with you.
We have two different version for each IGEP board, one that uses NAND
memory and another that has OneNAND.
With board files this is easy because the flash memory type is
hardcoded (in hardware) using sysboot pins [3]. So we check the
sysboot value and call board_nand_init() or board_onenand_init()
accordingly and pass the same static struct mtd_partition
igep_flash_partitions[] in both cases.
But with DT this is a little bit trickier since you have to define
either a nand at 0 or onenand at 0 child node for the gpmc device node. So,
we will have to create lots of dts and dtsi to handle each combination
(IGEPv2 + NAND, IGEPv2 + OneNAND, IGEP COM + NAND, etc).
I wonder if we could just have a generic gpmc-flash binding and maybe
use a "gpmc, flash_type" property or something like that to decide if
gpmc_onenand_init() or gpmc_nand_init() has to be called.
Thanks a lot and best regards,
Javier
[1]: git://github.com/martinezjavier/linux.git
[2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip
[3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins
^ permalink raw reply
* [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
From: Jonathan Austin @ 2013-02-04 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201181854.GU23505@n2100.arm.linux.org.uk>
Hi Russell,
On 01/02/13 18:18, Russell King - ARM Linux wrote:
> On Fri, Feb 01, 2013 at 04:43:31PM +0000, Jonathan Austin wrote:
>> Code that needs to access anything global will need to derive the location
>> of the GOT for itself, but there's a possible upside there that there's an
>> extra free register (r9 can be used as a general purpose register...)
>>
>> The patch would look like:
>> -----8<-------
>> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> index 5cad8a6..afed28e 100644
>> --- a/arch/arm/boot/compressed/Makefile
>> +++ b/arch/arm/boot/compressed/Makefile
>> @@ -120,7 +120,7 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
>> KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
>> endif
>> -ccflags-y := -fpic -fno-builtin -I$(obj)
>> +ccflags-y := -fpic -mno-single-pic-base -fno-builtin -I$(obj)
>> asflags-y := -Wa,-march=all -DZIMAGE
>> # Supply kernel BSS size to the decompressor via a linker symbol.
>> ------>8---------
>>
>>
>> I did a fairly crude benchmark - count how many instructions we need in
>> order to finish decompressing the kernel...
>>
>> Setup r9 correctly: 129,976,282
>> Use -mno-single-pic-base: 124,826,778
>>
>> (this was done using an R-class model and a magic semi-hosting call to pause
>> the model at the end of the decompress_kernel function)
>>
>> So, it seems like the extra register means there's actually a 4% *win*
>> in instruction terms from using -mno-single-pic-base
>
> Hmm. This is the opposite of what I'd expect. -msingle-pic-base says:
>
> Treat the register used for PIC addressing as read-only, rather
> than loading it in the prologue for each function. The run-time
> system is responsible for initializing this register with an
> appropriate value before execution begins.
>
> which implies that we should be able to load it before calling the C
> code (as you're doing) and then the compiler won't issue instructions
> to reload that register.
>
> Giving -mno-single-pic-base suggests that it would turn _off_ this
> behaviour (which afaik - sensibly - is not by default enabled.)
>
> So, I'm not sure I fully understand what's going on here.
You seem to have understood! Specifying -mno-single-pic-base
means the compiler *won't* expect r9 to point to the GOT, but also
means r9 is free as a general purpose register, the effect that I
believe gives the performance improvement in the decompresser.
Perhaps the context missing is that these are two independent patch
suggestions that achieve the same thing in different ways (that is,
they stop the decompresser running off to some incorrect memory location
because r9 isn't set-up). The -mno-single-pic base patch does it by not
using r9 as a PIC offset, and the 'initialise r9' patch does what it says
on the tin.
As you see, I benchmarked them and got the opposite result to what I
expected (IE -mno-songle-pic-base is quicker), so, based also on
Nicolas's Ack, would now champion a different patch to the original one
that I posted...
This is probably overkill, but here's a simple C example for comparison:
$cat pic.c
----------------
int foo;
int ret_foo()
{
return foo;
}
----------------
$arm-none-uclinux-uclibceabi-gcc -O2 -fPIC -S pic.c -o pic.s
$cat pic.s
-------------
[...]
ret_foo:
ldr r3, .L2
ldr r3, [r9, r3]
ldr r0, [r3, #0]
bx lr
.L3:
.align 2
.L2:
.word foo(GOT)
.size ret_foo, .-ret_foo
[...]
-------------
$arm-none-uclinux-uclibceabi-gcc -O2 -fPIC -mno-single-pic-base -S pic.c -o no-single-pic-base.s
$cat no-single-pic-base.s
-------------
[...]
ret_foo:
ldr r3, .L2
ldr r2, .L2+4
.LPIC0:
add r3, pc, r3
ldr r3, [r3, r2]
ldr r0, [r3, #0]
bx lr
.L3:
.align 2
.L2:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+8)
.word foo(GOT)
[...]
-----------
So we have a 'penalty' of an extra ldr and add when we don't use a read-only
PIC base, but the win of a register free seems to trump that in the decompresser.
Does that clear things up, or did I miss the point of what wasn't clear to you?
Jonny
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry
From: Sergei Shtylyov @ 2013-02-04 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510FA09F.7030604@ti.com>
Hello.
On 04-02-2013 15:50, Sekhar Nori wrote:
> Auxdata is not evm specific. This can instead be called da850_auxdata_lookup[].
> Also, I dont think it is necessary to add auxdata in a separate patch
> from dt nodes. So, I fixed these issues and came up with below patch. I
> tested basic wdt reboot. reboot command is still broken (with or
> without this patch). Can you please look at that?
> Thanks,
> Sekhar
> ----8<----
> From: "Kumar, Anil" <anilkumar.v@ti.com>
> Date: Thu, 24 Jan 2013 14:08:14 +0530
> Subject: [PATCH 1/1] ARM: davinci: da850: add wdt DT node
> Add da850 wdt DT node.
> Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[...]
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 8dd15c0..2800090 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -88,6 +88,11 @@
> 19>;
> status = "disabled";
> };
> + wdt: wdt at 1c21000 {
> + compatible = "ti,davinci-wdt";
> + reg = <0x21000 0xfff>;
Not 0x1000? This is region size, not upper limit.
WBR, Sergei
^ permalink raw reply
* [GIT PULL 0/4] ARM: mvebu: changes for v3.9
From: Jason Cooper @ 2013-02-04 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F7156.70005@free-electrons.com>
On Mon, Feb 04, 2013 at 09:29:10AM +0100, Gregory CLEMENT wrote:
> Hi Jason,
>
> On 02/01/2013 04:51 PM, Jason Cooper wrote:
> > The following changes since commit 19d23dac1b8f95e4a960fcbbb5687c33b9a2cd01:
> >
> > Merge branch 'fixes' into for-next
> >
> > are available in the git repository at:
> >
> > git://git.infradead.org/users/jcooper/linux.git mvebu/for-next
> >
> > for you to fetch changes up to 7d8a7dce24f76242daf1c469878597b8acc4f78f:
> >
> > Merge tag 'tags/dt_for_v3.9' into mvebu/for-next
> >
> > Jason Cooper (5):
> > Merge tag 'tags/mvebu_fixes_for_v3.8-rc6' into mvebu/for-next
> > Merge tag 'tags/cleanup_for_v3.9_round2' into mvebu/for-next
> > Merge tag 'tags/drivers_for_v3.9' into mvebu/for-next
> > Merge tag 'tags/boards_for_v3.9' into mvebu/for-next
> > Merge tag 'tags/dt_for_v3.9' into mvebu/for-next
>
> I didn't see anything about the USB support for Armada370/XP sent
> by Ezequiel. Is there any reason to not have it? Or do you plan
> to send a new pull request soon with his patch set?
Yes, this is a redo of the first series of requests I sent out. I had
to move mvsdio out to the appropriate maintainer tree and depend on it.
As soon as this gets pulled in, I have another round with everything but
Thomas' pci work. His will most likely be a separate pr series.
> PS: I noticed that there are a some files not related to mvebu at all
> (such as the arch/parisc/... for example), but I guess it is due to some
> dependencies.
Yeah, I'm working on that. It's purely in the diffstat, so it's not a
show stopper. It's much cleaner than the first time around, which is an
improvement.
thx,
Jason.
^ permalink raw reply
* [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
From: Russell King - ARM Linux @ 2013-02-04 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510FA2C0.3020505@arm.com>
On Mon, Feb 04, 2013 at 12:00:00PM +0000, Jonathan Austin wrote:
> You seem to have understood! Specifying -mno-single-pic-base
> means the compiler *won't* expect r9 to point to the GOT, but also
> means r9 is free as a general purpose register, the effect that I
> believe gives the performance improvement in the decompresser.
>
> Perhaps the context missing is that these are two independent patch
> suggestions that achieve the same thing in different ways (that is,
> they stop the decompresser running off to some incorrect memory location
> because r9 isn't set-up). The -mno-single-pic base patch does it by not
> using r9 as a PIC offset, and the 'initialise r9' patch does what it says
> on the tin.
>
> As you see, I benchmarked them and got the opposite result to what I
> expected (IE -mno-songle-pic-base is quicker), so, based also on
> Nicolas's Ack, would now champion a different patch to the original one
> that I posted...
>
> This is probably overkill, but here's a simple C example for comparison:
> $cat pic.c
> ----------------
> int foo;
> int ret_foo()
> {
> return foo;
> }
> ----------------
> $arm-none-uclinux-uclibceabi-gcc -O2 -fPIC -S pic.c -o pic.s
> $cat pic.s
> -------------
> [...]
> ret_foo:
> ldr r3, .L2
> ldr r3, [r9, r3]
> ldr r0, [r3, #0]
> bx lr
> .L3:
> .align 2
> .L2:
> .word foo(GOT)
> .size ret_foo, .-ret_foo
Ah, so the problem is that the default for single-pic-base is different
with uclinux compilers from other compilers. Other compilers will
default to -mno-single-pic-base, but what your build above shows is that
for your compiler, your default is -msingle-pic-base.
So, passing -mno-single-pic-base means that you're actually _restoring_
the compiler behaviour that we're expecting for the decompressor.
^ permalink raw reply
* [BUG] kernel oops in pin_request
From: Jack Mitchell @ 2013-02-04 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510F9D44.2000700@communistcode.co.uk>
On 04/02/13 11:36, Jack Mitchell wrote:
> I am developing a driver located at [1]. The driver has two devices on
> a single SPI bus. When the devices are probed the pins for the SPI bus
> get requested twice, as so:
>
> pinctrl = devm_pinctrl_get_select_default(&spi->dev);
> if (IS_ERR(pinctrl))
> {
> pr_debug("%s: Setting pins failed: %d\n", __func__, (s32)
> pinctrl);
> }
>
> The driver is DT only, and as such gets it's pins and setup from the
> DT [2]. When the second request happens I get the following output the
> kernel log:
>
> Jan 25 15:04:54 beaglebone user.err kernel: [ 67.319188]
> pinctrl-single 44e10800.pinmux: pin 44e1099c already requested by
> 48030000.spi; cannot claim for spi2.1
> Jan 25 15:04:54 beaglebone user.err kernel: [ 67.330496]
> pinctrl-single 44e10800.pinmux: pin-103 (spi2.1) status -22
> Jan 25 15:04:54 beaglebone user.err kernel: [ 67.337555]
> pinctrl-single 44e10800.pinmux: could not request pin 103 on device
> pinctrl-single
>
> Which I guess is ok as the first probe already setup the pins,
> everything then works as it should. Now, when I come to unload +
> reload the module I get an oops regarding the strmcmp() in pin_request:
>
> Jan 25 15:13:25 beaglebone user.debug kernel: [ 578.600746]
> r0005spi_probe: SPI Bus 2 probed
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.605991] Unable to
> handle kernel NULL pointer dereference at virtual address 00000000
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.614641] pgd =
> cf570000
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.617578]
> [00000000] *pgd=8d93a831, *pte=00000000, *ppte=00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.624347] Internal
> error: Oops: 17 [#1] SMP ARM
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.629303] Modules
> linked in: r0005spi(O+) [last unloaded: r0005spi]
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.636135] CPU: 0
> Tainted: G O (3.8.0-rc5-00538-g2431418-dirty #7)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.644031] PC is at
> strcmp+0x4/0x3c
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.647807] LR is at
> pin_request+0xb0/0x1e8
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] pc :
> [<c0295ac0>] lr : [<c02a94fc>] psr: a0000013
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] sp :
> cf4dfd38 ip : 00000000 fp : ffffffff
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.664290] r10:
> 00000000 r9 : 00000000 r8 : 00000059
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.669792] r7 :
> cf33fe00 r6 : c08413f0 r5 : cf0bb680 r4 : cf0a2280
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.676659] r3 :
> 00000000 r2 : 00000000 r1 : cf33fe00 r0 : 00000000
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.683531] Flags:
> NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.691038] Control:
> 10c5387d Table: 8f570019 DAC: 00000015
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.697087] Process
> insmod (pid: 566, stack limit = 0xcf4de240)
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.703318] Stack:
> (0xcf4dfd38 to 0xcf4e0000)
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.708307] fd20:
> cf0a2280 00000059
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.717039] fd40:
> cf33fe00 00000000 cf0a2280 cf52ebc0 c0af6010 c08413f0 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.725735] fd60:
> 00000001 c02a99d8 cf756e90 00000003 cf4dfda0 cf52ebc0 cf52ed0c cf756cc0
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.734427] fd80:
> c0af6010 cf52ed00 bf005650 c02a8018 cf5dfac0 c08411c4 cf756cc0 cf52ed00
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.743121] fda0:
> c0af6010 c02a8074 cf756c00 cf756cc0 cf335600 bf005218 cf335600 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.751862] fdc0:
> cf335600 bf005b8c bf005b8c c031e1c0 00000001 c037e678 c037e660 c031dfac
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.764322] fde0:
> bf005b8c cf335600 cf335600 cf335634 bf005b8c c031e228 00000000 cf4dfe08
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.773168] fe00:
> bf005b8c c031c53c cf0b5478 cf334880 bf005b8c bf005b8c c0852258 cf4155c0
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.781877] fe20:
> 00000000 c031d5c4 bf00594c cf0a2488 bf005b8c cf4dff58 00000000 bf005d3c
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.790570] fe40:
> 00000001 c031e71c 00000000 bf005d30 cf4dff58 00000000 bf005d3c 00000001
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.799262] fe60:
> bf005650 c0008878 bf005650 00000000 00000001 bf005d30 bf005d30 cf4dff58
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.817450] fe80:
> 00000000 bf005d3c 00000001 cf6e9880 bf005d78 c008b928 bf005d3c 00007fff
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.826624] fea0:
> c02a5ed0 00000053 c0875738 0000001c 00000000 c0088aac c07fab0c bf005e84
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.835756] fec0:
> c0534e14 d09f6970 cf4dfee4 00022008 20000013 c0753164 cf4dff14 c0529a18
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.844875] fee0:
> d09f9000 b6fca000 00000751 00000000 00000000 00000000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.853984] ff00:
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.863087] ff20:
> 00000000 00000000 000000d2 b6fc0000 0000a7d1 00022008 00000080 c000e364
> Jan 25 15:13:25 beaglebone user.debug kernel: [ 578.600746]
> r0005spi_probe: SPI Bus 2 probed
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.605991] Unable to
> handle kernel NULL pointer dereference at virtual address 00000000
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.614641] pgd =
> cf570000
> Jan 25 15:13:25 beaglebone user.alert kernel: [ 578.617578]
> [00000000] *pgd=8d93a831, *pte=00000000, *ppte=00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.624347] Internal
> error: Oops: 17 [#1] SMP ARM
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.629303] Modules
> linked in: r0005spi(O+) [last unloaded: r0005spi]
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.636135] CPU: 0
> Tainted: G O (3.8.0-rc5-00538-g2431418-dirty #7)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.644031] PC is at
> strcmp+0x4/0x3c
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.647807] LR is at
> pin_request+0xb0/0x1e8
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] pc :
> [<c0295ac0>] lr : [<c02a94fc>] psr: a0000013
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.652224] sp :
> cf4dfd38 ip : 00000000 fp : ffffffff
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.664290] r10:
> 00000000 r9 : 00000000 r8 : 00000059
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.669792] r7 :
> cf33fe00 r6 : c08413f0 r5 : cf0bb680 r4 : cf0a2280
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.676659] r3 :
> 00000000 r2 : 00000000 r1 : cf33fe00 r0 : 00000000
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.683531] Flags:
> NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.691038] Control:
> 10c5387d Table: 8f570019 DAC: 00000015
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.697087] Process
> insmod (pid: 566, stack limit = 0xcf4de240)
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.703318] Stack:
> (0xcf4dfd38 to 0xcf4e0000)
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.708307] fd20:
> cf0a2280 00000059
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.717039] fd40:
> cf33fe00 00000000 cf0a2280 cf52ebc0 c0af6010 c08413f0 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.725735] fd60:
> 00000001 c02a99d8 cf756e90 00000003 cf4dfda0 cf52ebc0 cf52ed0c cf756cc0
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.734427] fd80:
> c0af6010 cf52ed00 bf005650 c02a8018 cf5dfac0 c08411c4 cf756cc0 cf52ed00
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.743121] fda0:
> c0af6010 c02a8074 cf756c00 cf756cc0 cf335600 bf005218 cf335600 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.751862] fdc0:
> cf335600 bf005b8c bf005b8c c031e1c0 00000001 c037e678 c037e660 c031dfac
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.764322] fde0:
> bf005b8c cf335600 cf335600 cf335634 bf005b8c c031e228 00000000 cf4dfe08
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.773168] fe00:
> bf005b8c c031c53c cf0b5478 cf334880 bf005b8c bf005b8c c0852258 cf4155c0
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.781877] fe20:
> 00000000 c031d5c4 bf00594c cf0a2488 bf005b8c cf4dff58 00000000 bf005d3c
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.790570] fe40:
> 00000001 c031e71c 00000000 bf005d30 cf4dff58 00000000 bf005d3c 00000001
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.799262] fe60:
> bf005650 c0008878 bf005650 00000000 00000001 bf005d30 bf005d30 cf4dff58
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.817450] fe80:
> 00000000 bf005d3c 00000001 cf6e9880 bf005d78 c008b928 bf005d3c 00007fff
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.826624] fea0:
> c02a5ed0 00000053 c0875738 0000001c 00000000 c0088aac c07fab0c bf005e84
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.835756] fec0:
> c0534e14 d09f6970 cf4dfee4 00022008 20000013 c0753164 cf4dff14 c0529a18
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.844875] fee0:
> d09f9000 b6fca000 00000751 00000000 00000000 00000000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.853984] ff00:
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.863087] ff20:
> 00000000 00000000 000000d2 b6fc0000 0000a7d1 00022008 00000080 c000e364
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.872190] ff40:
> cf4de000 00000000 00000000 c008bce8 00000002 c0529780 d09ef000 0000a7d1
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.881468] ff60:
> d09f6420 d09f62c8 d09f92f8 00000e98 00001218 bf005bc8 0000000f 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.890834] ff80:
> 00000022 00000023 0000000e 00000009 00000007 00000000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.899961] ffa0:
> 00022da8 c000e1e0 00000000 00000000 b6fc0000 0000a7d1 00022008 00022da8
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.909073] ffc0:
> 00000000 00000000 00022da8 00000080 00022098 0000a7d1 00022008 00000000
> Jan 25 15:13:25 beaglebone user.emerg kernel: [ 578.918243] ffe0:
> 4ff71978 bed65ba8 4ff60790 4fe2e870 60000010 b6fc0000 00000000 00000000
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.927032]
> [<c0295ac0>] (strcmp+0x4/0x3c) from [<c02a94fc>] (pin_request+0xb0/0x1e8)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.935371]
> [<c02a94fc>] (pin_request+0xb0/0x1e8) from [<c02a99d8>]
> (pinmux_enable_setting+0x74/0x1a4)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.945369]
> [<c02a99d8>] (pinmux_enable_setting+0x74/0x1a4) from [<c02a8018>]
> (pinctrl_select_state_locked+0xb8/0xf0)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.956637]
> [<c02a8018>] (pinctrl_select_state_locked+0xb8/0xf0) from [<c02a8074>]
> (pinctrl_select_state+0x24/0x3c)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.967743]
> [<c02a8074>] (pinctrl_select_state+0x24/0x3c) from [<bf005218>]
> (r0005spi_probe+0xfc/0x310 [r0005spi])
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.978751]
> [<bf005218>] (r0005spi_probe+0xfc/0x310 [r0005spi]) from [<c037e678>]
> (spi_drv_probe+0x18/0x1c)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.989093]
> [<c037e678>] (spi_drv_probe+0x18/0x1c) from [<c031dfac>]
> (driver_probe_device+0x11c/0x330)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 578.998970]
> [<c031dfac>] (driver_probe_device+0x11c/0x330) from [<c031e228>]
> (__driver_attach+0x68/0x8c)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.009125]
> [<c031e228>] (__driver_attach+0x68/0x8c) from [<c031c53c>]
> (bus_for_each_dev+0x48/0x80)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.018774]
> [<c031c53c>] (bus_for_each_dev+0x48/0x80) from [<c031d5c4>]
> (bus_add_driver+0xf0/0x248)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.028379]
> [<c031d5c4>] (bus_add_driver+0xf0/0x248) from [<c031e71c>]
> (driver_register+0x9c/0x12c)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.037982]
> [<c031e71c>] (driver_register+0x9c/0x12c) from [<c0008878>]
> (do_one_initcall+0x90/0x160)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.047681]
> [<c0008878>] (do_one_initcall+0x90/0x160) from [<c008b928>]
> (load_module+0x1b64/0x1e28)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.057284]
> [<c008b928>] (load_module+0x1b64/0x1e28) from [<c008bce8>]
> (sys_init_module+0xfc/0x11c)
> Jan 25 15:13:25 beaglebone user.warn kernel: [ 579.066891]
> [<c008bce8>] (sys_init_module+0xfc/0x11c) from [<c000e1e0>]
> (ret_fast_syscall+0x0/0x30)
>
> The pin_request portion of that driver where the traceback points to
> is as so:
>
> dev_dbg(pctldev->dev, "request pin %d (%s) for %s\n",
> pin, desc->name, owner);
>
> if (gpio_range) {
> /* There's no need to support multiple GPIO requests */
> if (desc->gpio_owner) {
> dev_err(pctldev->dev,
> "pin %s already requested by %s; cannot claim for %s\n",
> desc->name, desc->gpio_owner, owner);
> goto out;
> }
>
> desc->gpio_owner = owner;
> } else {
> if (desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
> dev_err(pctldev->dev,
> "pin %s already requested by %s; cannot claim for %s\n",
> desc->name, desc->mux_owner, owner);
> goto out;
> }
>
> desc->mux_usecount++;
> if (desc->mux_usecount > 1)
> return 0;
>
> desc->mux_owner = owner;
> }
>
> From what I can gather that means that desc->mux_owner or owner must
> be an invalid pointer. Is this a bug, or am I abusing the interface in
> some subtle way?
>
> [1] https://pastee.org/vyaz4
> [2] https://pastee.org/6e2nt
>
> Regards,
> Jack.
>
Please ignore this, I was inadvertently re-using a pin of the spi parent
which was causing all the issues. Apologies for the time wasted!
--
Jack Mitchell (jack at embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
^ permalink raw reply
* [PATCH v6] cpufreq: add imx6q-cpufreq driver
From: Rafael J. Wysocki @ 2013-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359956789-17918-1-git-send-email-shawn.guo@linaro.org>
On Monday, February 04, 2013 01:46:29 PM Shawn Guo wrote:
> Add an imx6q-cpufreq driver for Freescale i.MX6Q SoC to handle the
> hardware specific frequency and voltage scaling requirements.
>
> The driver supports module build and is instantiated by the platform
> device/driver mechanism, so that it will not be instantiated on other
> platforms, as IMX is built with multiplatform support.
Am I supposed to take it this time? :-)
Rafael
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Changes since v5:
> * Update clock tranistion code to make keep use count correct
>
> drivers/cpufreq/Kconfig.arm | 9 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/imx6q-cpufreq.c | 336 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 346 insertions(+)
> create mode 100644 drivers/cpufreq/imx6q-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index ffe55b8..c65226c 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
> This adds the CPUFreq driver for Samsung EXYNOS5250
> SoC.
>
> +config ARM_IMX6Q_CPUFREQ
> + tristate "Freescale i.MX6Q cpufreq support"
> + depends on SOC_IMX6Q
> + depends on REGULATOR_ANATOP
> + help
> + This adds cpufreq driver support for Freescale i.MX6Q SOC.
> +
> + If in doubt, say N.
> +
> config ARM_SPEAR_CPUFREQ
> bool "SPEAr CPUFreq support"
> depends on PLAT_SPEAR
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index e2a5da7..93610b2 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
> obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
> +obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
>
> ##################################################################################
> # PowerPC platform drivers
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> new file mode 100644
> index 0000000..d6b6ef3
> --- /dev/null
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -0,0 +1,336 @@
> +/*
> + * Copyright (C) 2013 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/cpufreq.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/opp.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define PU_SOC_VOLTAGE_NORMAL 1250000
> +#define PU_SOC_VOLTAGE_HIGH 1275000
> +#define FREQ_1P2_GHZ 1200000000
> +
> +static struct regulator *arm_reg;
> +static struct regulator *pu_reg;
> +static struct regulator *soc_reg;
> +
> +static struct clk *arm_clk;
> +static struct clk *pll1_sys_clk;
> +static struct clk *pll1_sw_clk;
> +static struct clk *step_clk;
> +static struct clk *pll2_pfd2_396m_clk;
> +
> +static struct device *cpu_dev;
> +static struct cpufreq_frequency_table *freq_table;
> +static unsigned int transition_latency;
> +
> +static int imx6q_verify_speed(struct cpufreq_policy *policy)
> +{
> + return cpufreq_frequency_table_verify(policy, freq_table);
> +}
> +
> +static unsigned int imx6q_get_speed(unsigned int cpu)
> +{
> + return clk_get_rate(arm_clk) / 1000;
> +}
> +
> +static int imx6q_set_target(struct cpufreq_policy *policy,
> + unsigned int target_freq, unsigned int relation)
> +{
> + struct cpufreq_freqs freqs;
> + struct opp *opp;
> + unsigned long freq_hz, volt, volt_old;
> + unsigned int index, cpu;
> + int ret;
> +
> + ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
> + relation, &index);
> + if (ret) {
> + dev_err(cpu_dev, "failed to match target frequency %d: %d\n",
> + target_freq, ret);
> + return ret;
> + }
> +
> + freqs.new = freq_table[index].frequency;
> + freq_hz = freqs.new * 1000;
> + freqs.old = clk_get_rate(arm_clk) / 1000;
> +
> + if (freqs.old == freqs.new)
> + return 0;
> +
> + for_each_online_cpu(cpu) {
> + freqs.cpu = cpu;
> + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> + }
> +
> + rcu_read_lock();
> + opp = opp_find_freq_ceil(cpu_dev, &freq_hz);
> + if (IS_ERR(opp)) {
> + rcu_read_unlock();
> + dev_err(cpu_dev, "failed to find OPP for %ld\n", freq_hz);
> + return PTR_ERR(opp);
> + }
> +
> + volt = opp_get_voltage(opp);
> + rcu_read_unlock();
> + volt_old = regulator_get_voltage(arm_reg);
> +
> + dev_dbg(cpu_dev, "%u MHz, %ld mV --> %u MHz, %ld mV\n",
> + freqs.old / 1000, volt_old / 1000,
> + freqs.new / 1000, volt / 1000);
> +
> + /* scaling up? scale voltage before frequency */
> + if (freqs.new > freqs.old) {
> + ret = regulator_set_voltage_tol(arm_reg, volt, 0);
> + if (ret) {
> + dev_err(cpu_dev,
> + "failed to scale vddarm up: %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Need to increase vddpu and vddsoc for safety
> + * if we are about to run at 1.2 GHz.
> + */
> + if (freqs.new == FREQ_1P2_GHZ / 1000) {
> + regulator_set_voltage_tol(pu_reg,
> + PU_SOC_VOLTAGE_HIGH, 0);
> + regulator_set_voltage_tol(soc_reg,
> + PU_SOC_VOLTAGE_HIGH, 0);
> + }
> + }
> +
> + /*
> + * The setpoints are selected per PLL/PDF frequencies, so we need to
> + * reprogram PLL for frequency scaling. The procedure of reprogramming
> + * PLL1 is as below.
> + *
> + * - Enable pll2_pfd2_396m_clk and reparent pll1_sw_clk to it
> + * - Reprogram pll1_sys_clk and reparent pll1_sw_clk back to it
> + * - Disable pll2_pfd2_396m_clk
> + */
> + clk_prepare_enable(pll2_pfd2_396m_clk);
> + clk_set_parent(step_clk, pll2_pfd2_396m_clk);
> + clk_set_parent(pll1_sw_clk, step_clk);
> + if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
> + clk_set_rate(pll1_sys_clk, freqs.new * 1000);
> + /*
> + * If we are leaving 396 MHz set-point, we need to enable
> + * pll1_sys_clk and disable pll2_pfd2_396m_clk to keep
> + * their use count correct.
> + */
> + if (freqs.old * 1000 <= clk_get_rate(pll2_pfd2_396m_clk)) {
> + clk_prepare_enable(pll1_sys_clk);
> + clk_disable_unprepare(pll2_pfd2_396m_clk);
> + }
> + clk_set_parent(pll1_sw_clk, pll1_sys_clk);
> + clk_disable_unprepare(pll2_pfd2_396m_clk);
> + } else {
> + /*
> + * Disable pll1_sys_clk if pll2_pfd2_396m_clk is sufficient
> + * to provide the frequency.
> + */
> + clk_disable_unprepare(pll1_sys_clk);
> + }
> +
> + /* Ensure the arm clock divider is what we expect */
> + ret = clk_set_rate(arm_clk, freqs.new * 1000);
> + if (ret) {
> + dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
> + regulator_set_voltage_tol(arm_reg, volt_old, 0);
> + return ret;
> + }
> +
> + /* scaling down? scale voltage after frequency */
> + if (freqs.new < freqs.old) {
> + ret = regulator_set_voltage_tol(arm_reg, volt, 0);
> + if (ret)
> + dev_warn(cpu_dev,
> + "failed to scale vddarm down: %d\n", ret);
> +
> + if (freqs.old == FREQ_1P2_GHZ / 1000) {
> + regulator_set_voltage_tol(pu_reg,
> + PU_SOC_VOLTAGE_NORMAL, 0);
> + regulator_set_voltage_tol(soc_reg,
> + PU_SOC_VOLTAGE_NORMAL, 0);
> + }
> + }
> +
> + for_each_online_cpu(cpu) {
> + freqs.cpu = cpu;
> + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> + }
> +
> + return 0;
> +}
> +
> +static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
> +{
> + int ret;
> +
> + ret = cpufreq_frequency_table_cpuinfo(policy, freq_table);
> + if (ret) {
> + dev_err(cpu_dev, "invalid frequency table: %d\n", ret);
> + return ret;
> + }
> +
> + policy->cpuinfo.transition_latency = transition_latency;
> + policy->cur = clk_get_rate(arm_clk) / 1000;
> + cpumask_setall(policy->cpus);
> + cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
> +
> + return 0;
> +}
> +
> +static int imx6q_cpufreq_exit(struct cpufreq_policy *policy)
> +{
> + cpufreq_frequency_table_put_attr(policy->cpu);
> + return 0;
> +}
> +
> +static struct freq_attr *imx6q_cpufreq_attr[] = {
> + &cpufreq_freq_attr_scaling_available_freqs,
> + NULL,
> +};
> +
> +static struct cpufreq_driver imx6q_cpufreq_driver = {
> + .verify = imx6q_verify_speed,
> + .target = imx6q_set_target,
> + .get = imx6q_get_speed,
> + .init = imx6q_cpufreq_init,
> + .exit = imx6q_cpufreq_exit,
> + .name = "imx6q-cpufreq",
> + .attr = imx6q_cpufreq_attr,
> +};
> +
> +static int imx6q_cpufreq_probe(struct platform_device *pdev)
> +{
> + struct device_node *np;
> + struct opp *opp;
> + unsigned long min_volt, max_volt;
> + int num, ret;
> +
> + cpu_dev = &pdev->dev;
> +
> + np = of_find_node_by_path("/cpus/cpu at 0");
> + if (!np) {
> + dev_err(cpu_dev, "failed to find cpu0 node\n");
> + return -ENOENT;
> + }
> +
> + cpu_dev->of_node = np;
> +
> + arm_clk = devm_clk_get(cpu_dev, "arm");
> + pll1_sys_clk = devm_clk_get(cpu_dev, "pll1_sys");
> + pll1_sw_clk = devm_clk_get(cpu_dev, "pll1_sw");
> + step_clk = devm_clk_get(cpu_dev, "step");
> + pll2_pfd2_396m_clk = devm_clk_get(cpu_dev, "pll2_pfd2_396m");
> + if (IS_ERR(arm_clk) || IS_ERR(pll1_sys_clk) || IS_ERR(pll1_sw_clk) ||
> + IS_ERR(step_clk) || IS_ERR(pll2_pfd2_396m_clk)) {
> + dev_err(cpu_dev, "failed to get clocks\n");
> + ret = -ENOENT;
> + goto put_node;
> + }
> +
> + arm_reg = devm_regulator_get(cpu_dev, "arm");
> + pu_reg = devm_regulator_get(cpu_dev, "pu");
> + soc_reg = devm_regulator_get(cpu_dev, "soc");
> + if (!arm_reg || !pu_reg || !soc_reg) {
> + dev_err(cpu_dev, "failed to get regulators\n");
> + ret = -ENOENT;
> + goto put_node;
> + }
> +
> + /* We expect an OPP table supplied by platform */
> + num = opp_get_opp_count(cpu_dev);
> + if (num < 0) {
> + ret = num;
> + dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
> + goto put_node;
> + }
> +
> + ret = opp_init_cpufreq_table(cpu_dev, &freq_table);
> + if (ret) {
> + dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
> + goto put_node;
> + }
> +
> + if (of_property_read_u32(np, "clock-latency", &transition_latency))
> + transition_latency = CPUFREQ_ETERNAL;
> +
> + /*
> + * OPP is maintained in order of increasing frequency, and
> + * freq_table initialised from OPP is therefore sorted in the
> + * same order.
> + */
> + rcu_read_lock();
> + opp = opp_find_freq_exact(cpu_dev,
> + freq_table[0].frequency * 1000, true);
> + min_volt = opp_get_voltage(opp);
> + opp = opp_find_freq_exact(cpu_dev,
> + freq_table[--num].frequency * 1000, true);
> + max_volt = opp_get_voltage(opp);
> + rcu_read_unlock();
> + ret = regulator_set_voltage_time(arm_reg, min_volt, max_volt);
> + if (ret > 0)
> + transition_latency += ret * 1000;
> +
> + /* Count vddpu and vddsoc latency in for 1.2 GHz support */
> + if (freq_table[num].frequency == FREQ_1P2_GHZ / 1000) {
> + ret = regulator_set_voltage_time(pu_reg, PU_SOC_VOLTAGE_NORMAL,
> + PU_SOC_VOLTAGE_HIGH);
> + if (ret > 0)
> + transition_latency += ret * 1000;
> + ret = regulator_set_voltage_time(soc_reg, PU_SOC_VOLTAGE_NORMAL,
> + PU_SOC_VOLTAGE_HIGH);
> + if (ret > 0)
> + transition_latency += ret * 1000;
> + }
> +
> + ret = cpufreq_register_driver(&imx6q_cpufreq_driver);
> + if (ret) {
> + dev_err(cpu_dev, "failed register driver: %d\n", ret);
> + goto free_freq_table;
> + }
> +
> + of_node_put(np);
> + return 0;
> +
> +free_freq_table:
> + opp_free_cpufreq_table(cpu_dev, &freq_table);
> +put_node:
> + of_node_put(np);
> + return ret;
> +}
> +
> +static int imx6q_cpufreq_remove(struct platform_device *pdev)
> +{
> + cpufreq_unregister_driver(&imx6q_cpufreq_driver);
> + opp_free_cpufreq_table(cpu_dev, &freq_table);
> +
> + return 0;
> +}
> +
> +static struct platform_driver imx6q_cpufreq_platdrv = {
> + .driver = {
> + .name = "imx6q-cpufreq",
> + .owner = THIS_MODULE,
> + },
> + .probe = imx6q_cpufreq_probe,
> + .remove = imx6q_cpufreq_remove,
> +};
> +module_platform_driver(imx6q_cpufreq_platdrv);
> +
> +MODULE_AUTHOR("Shawn Guo <shawn.guo@linaro.org>");
> +MODULE_DESCRIPTION("Freescale i.MX6Q cpufreq driver");
> +MODULE_LICENSE("GPL");
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
From: Jonathan Austin @ 2013-02-04 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130204120708.GB17786@n2100.arm.linux.org.uk>
On 04/02/13 12:07, Russell King - ARM Linux wrote:
> On Mon, Feb 04, 2013 at 12:00:00PM +0000, Jonathan Austin wrote:
>> You seem to have understood! Specifying -mno-single-pic-base
>> means the compiler *won't* expect r9 to point to the GOT, but also
>> means r9 is free as a general purpose register, the effect that I
>> believe gives the performance improvement in the decompresser.
>>
>> Perhaps the context missing is that these are two independent patch
>> suggestions that achieve the same thing in different ways (that is,
>> they stop the decompresser running off to some incorrect memory location
>> because r9 isn't set-up). The -mno-single-pic base patch does it by not
>> using r9 as a PIC offset, and the 'initialise r9' patch does what it says
>> on the tin.
>>
>> As you see, I benchmarked them and got the opposite result to what I
>> expected (IE -mno-songle-pic-base is quicker), so, based also on
>> Nicolas's Ack, would now champion a different patch to the original one
>> that I posted...
>>
>> This is probably overkill, but here's a simple C example for comparison:
>> $cat pic.c
>> ----------------
>> int foo;
>> int ret_foo()
>> {
>> return foo;
>> }
>> ----------------
>> $arm-none-uclinux-uclibceabi-gcc -O2 -fPIC -S pic.c -o pic.s
>> $cat pic.s
>> -------------
>> [...]
>> ret_foo:
>> ldr r3, .L2
>> ldr r3, [r9, r3]
>> ldr r0, [r3, #0]
>> bx lr
>> .L3:
>> .align 2
>> .L2:
>> .word foo(GOT)
>> .size ret_foo, .-ret_foo
>
> Ah, so the problem is that the default for single-pic-base is different
> with uclinux compilers from other compilers. Other compilers will
> default to -mno-single-pic-base, but what your build above shows is that
> for your compiler, your default is -msingle-pic-base.
>
> So, passing -mno-single-pic-base means that you're actually _restoring_
> the compiler behaviour that we're expecting for the decompressor.
>
Ahh, I see.
My experience is that my toolchain behaves much like most other uclinux
toolchains - I've just checked:
- Codesourcery
- A Pengutronix one for the M3
- An ARM one
And they all default to using r9.
So shall I put the -m*no*-single-pic-base one in to the patch system?
Jonny
^ permalink raw reply
* [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
From: Russell King - ARM Linux @ 2013-02-04 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510FA7A4.5030409@arm.com>
On Mon, Feb 04, 2013 at 12:20:52PM +0000, Jonathan Austin wrote:
> My experience is that my toolchain behaves much like most other uclinux
> toolchains - I've just checked:
> - Codesourcery
> - A Pengutronix one for the M3
> - An ARM one
>
> And they all default to using r9.
>
> So shall I put the -m*no*-single-pic-base one in to the patch system?
Yup, though I don't think I'll be pushing it until the next merge window.
^ permalink raw reply
* [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders
From: Rajendra Nayak @ 2013-02-04 12:24 UTC (permalink / raw)
To: linux-arm-kernel
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: R Sricharan <r.sricharan@ti.com>
---
arch/arm/mach-omap2/pm44xx.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..45ca053 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -77,8 +77,18 @@ static int omap4_pm_suspend(void)
omap_set_pwrdm_state(pwrst->pwrdm, pwrst->saved_state);
pwrdm_set_logic_retst(pwrst->pwrdm, pwrst->saved_logic_state);
}
- if (ret)
+ if (ret) {
pr_crit("Could not enter target state in pm_suspend\n");
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ * Warn the user about the bootloader version being one of the
+ * possible causes.
+ */
+ pr_warn("One of the possible cause could be an old bootloder\n"
+ "Use version v2012.07 (or later)\n");
+ }
else
pr_info("Successfully put all powerdomains to target state\n");
@@ -146,6 +156,12 @@ int __init omap4_pm_init(void)
}
pr_err("Power Management for TI OMAP4.\n");
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ */
+ pr_warn("Use Bootloader version v2012.07 (or later) for full PM support\n");
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH] rtc: pl031: fix the missing operation on enable
From: Linus Walleij @ 2013-02-04 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359507865-29808-1-git-send-email-haojian.zhuang@linaro.org>
Hi Haojian, sorry for taking too long to reply...
On Wed, Jan 30, 2013 at 2:04 AM, Haojian Zhuang
<haojian.zhuang@linaro.org> wrote:
> RTC control register should be enabled in the process of initliazing.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
(...)
> + data = readl(ldata->base + RTC_CR);
> /* Enable the clockwatch on ST Variants */
> if (vendor->clockwatch)
> - writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
> - ldata->base + RTC_CR);
> + data |= RTC_CR_CWEN;
> + writel(data | RTC_CR_EN, ldata->base + RTC_CR);
This last line is *not* OK on the ST Variant. In our hardware that bit
is part of the clock divider, which means it will affect our timekeeping.
Do you want me to submit a follow-up patch?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] rtc: pl031: fix the missing operation on enable
From: Haojian Zhuang @ 2013-02-04 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda_0Uat=Qs3ty38Ygbsucx6dL0J+PmxVq7N_gRzQsEhbw@mail.gmail.com>
On 4 February 2013 20:25, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hi Haojian, sorry for taking too long to reply...
>
> On Wed, Jan 30, 2013 at 2:04 AM, Haojian Zhuang
> <haojian.zhuang@linaro.org> wrote:
>
>> RTC control register should be enabled in the process of initliazing.
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
>
> (...)
>> + data = readl(ldata->base + RTC_CR);
>> /* Enable the clockwatch on ST Variants */
>> if (vendor->clockwatch)
>> - writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
>> - ldata->base + RTC_CR);
>> + data |= RTC_CR_CWEN;
>> + writel(data | RTC_CR_EN, ldata->base + RTC_CR);
>
> This last line is *not* OK on the ST Variant. In our hardware that bit
> is part of the clock divider, which means it will affect our timekeeping.
>
> Do you want me to submit a follow-up patch?
>
> Yours,
> Linus Walleij
I prefer you can submit a follow up patch. And I think that you can
use a compatible
name to distinguish from original "arm,rtc-pl031". Then we can get two
branches to
handle the difference in the probe function. What's your opinion?
Regards
Haojian
^ permalink raw reply
* [PATCH] rtc: pl031: fix the missing operation on enable
From: Linus Walleij @ 2013-02-04 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6h2NQ6M6hmPE2anH2jkhBtc5HfQXLMxJTtLQEh9p8V1kNMhQ@mail.gmail.com>
On Mon, Feb 4, 2013 at 1:34 PM, Haojian Zhuang
<haojian.zhuang@linaro.org> wrote:
> I prefer you can submit a follow up patch.
OK!
> And I think that you can
> use a compatible
> name to distinguish from original "arm,rtc-pl031". Then we can get two
> branches to
> handle the difference in the probe function. What's your opinion?
No that is wrong for PrimeCells.
PrimeCells have special ID numbers that we use to identify the
different variants already.
Yours,
Linus Walleij
^ 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