* [PATCH] arm: omap: Fix build break in drm.c
From: Archit Taneja @ 2013-01-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
Building omapdrm leads to a build break because of a missing include needed
for the macro GET_OMAP_REVISION(). Add the missing inlclude.
Signed-off-by: Archit Taneja <archit@ti.com>
---
arch/arm/mach-omap2/drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 4c7566c..6b1a8df 100644
--- a/arch/arm/mach-omap2/drm.c
+++ b/arch/arm/mach-omap2/drm.c
@@ -25,6 +25,7 @@
#include <linux/dma-mapping.h>
#include <linux/platform_data/omap_drm.h>
+#include "soc.h"
#include "omap_device.h"
#include "omap_hwmod.h"
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2] ARM: imx27: add a clock gate to activate SPLL clock
From: gwenhael.goavec @ 2013-01-22 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358086501-44408-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Ping?
Gwenhael
On Sun, 13 Jan 2013 15:15:01 +0100
Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com> wrote:
> A clock gate is mandatory to activate SPLL clock needed, at least, for usb.
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> ---
> V2: - Suppress patch about ehci-mxc.c.
>
> arch/arm/mach-imx/clk-imx27.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 4c1d1e4..4f066d13 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -62,7 +62,7 @@ static const char *clko_sel_clks[] = {
> "32k", "usb_div", "dptc",
> };
>
> -static const char *ssi_sel_clks[] = { "spll", "mpll", };
> +static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
>
> enum mx27_clks {
> dummy, ckih, ckil, mpll, spll, mpll_main2, ahb, ipg, nfc_div, per1_div,
> @@ -82,7 +82,7 @@ enum mx27_clks {
> csi_ahb_gate, brom_ahb_gate, ata_ahb_gate, wdog_ipg_gate, usb_ipg_gate,
> uart6_ipg_gate, uart5_ipg_gate, uart4_ipg_gate, uart3_ipg_gate,
> uart2_ipg_gate, uart1_ipg_gate, ckih_div1p5, fpm, mpll_osc_sel,
> - mpll_sel, clk_max
> + mpll_sel, spll_gate, clk_max
> };
>
> static struct clk *clk[clk_max];
> @@ -104,6 +104,7 @@ int __init mx27_clocks_init(unsigned long fref)
> ARRAY_SIZE(mpll_sel_clks));
> clk[mpll] = imx_clk_pllv1("mpll", "mpll_sel", CCM_MPCTL0);
> clk[spll] = imx_clk_pllv1("spll", "ckih", CCM_SPCTL0);
> + clk[spll_gate] = imx_clk_gate("spll_gate", "spll", CCM_CSCR, 1);
> clk[mpll_main2] = imx_clk_fixed_factor("mpll_main2", "mpll", 2, 3);
>
> if (mx27_revision() >= IMX_CHIP_REVISION_2_0) {
> @@ -121,7 +122,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk[per4_div] = imx_clk_divider("per4_div", "mpll_main2", CCM_PCDR1, 24, 6);
> clk[vpu_sel] = imx_clk_mux("vpu_sel", CCM_CSCR, 21, 1, vpu_sel_clks, ARRAY_SIZE(vpu_sel_clks));
> clk[vpu_div] = imx_clk_divider("vpu_div", "vpu_sel", CCM_PCDR0, 10, 6);
> - clk[usb_div] = imx_clk_divider("usb_div", "spll", CCM_CSCR, 28, 3);
> + clk[usb_div] = imx_clk_divider("usb_div", "spll_gate", CCM_CSCR, 28, 3);
> clk[cpu_sel] = imx_clk_mux("cpu_sel", CCM_CSCR, 15, 1, cpu_sel_clks, ARRAY_SIZE(cpu_sel_clks));
> clk[clko_sel] = imx_clk_mux("clko_sel", CCM_CCSR, 0, 5, clko_sel_clks, ARRAY_SIZE(clko_sel_clks));
> if (mx27_revision() >= IMX_CHIP_REVISION_2_0)
> --
> 1.7.12.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/4] ARM: cache-l2x0: Manage the errata at run time
From: Santosh Shilimkar @ 2013-01-22 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121160833.GQ23505@n2100.arm.linux.org.uk>
On Monday 21 January 2013 09:38 PM, Russell King - ARM Linux wrote:
> On Mon, Jan 21, 2013 at 06:44:53PM +0530, srinidhi kasagar wrote:
>> +/*
>> + * Identify ther RTL releases of l2x0 - This might help in applying
>> + * the l2x0 errata's dynamically rather compile time options
>> + */
>> +asmlinkage u32 l2x0_get_rtl_release(void)
>
> Why asmlinkage?
>
>> +{
>> + return readl_relaxed(l2x0_base + L2X0_CACHE_ID) &
>> + L2X0_CACHE_ID_RTL_MASK;
>> +}
>> +
>> static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
>> {
>> /* wait for cache operation by line or way to complete */
>> @@ -87,46 +97,41 @@ static inline void l2x0_inv_line(unsigned long addr)
>> writel_relaxed(addr, base + L2X0_INV_LINE_PA);
>> }
>>
>> -#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
>> -static inline void debug_writel(unsigned long val)
>> +static void debug_writel(unsigned long val)
>> {
>> - if (outer_cache.set_debug)
>> - outer_cache.set_debug(val);
>> + u32 l2x0_revision = l2x0_get_rtl_release();
>> +
>> + if (l2x0_revision == L2X0_CACHE_ID_RTL_R3P0 ||
>> + l2x0_revision == L2X0_CACHE_ID_RTL_R2P0 ||
>> + l2x0_revision == L2X0_CACHE_ID_RTL_R1P0 ||
>> + l2x0_revision == L2X0_CACHE_ID_RTL_R0P0)
>> + if (outer_cache.set_debug)
>> + outer_cache.set_debug(val);
>
> This needs comments from the TI folk. Also, change this around - if
> there's no setting for 'set_debug' there's no point reading the rtl
> release and checking it against a set of values. Added Santosh.
>
Thanks Russell for looping me. 588369 is fixed in r3p0 but 727915
is present. Both has same work around so the version checks are
fine. I agree that moving the version check inside .set_debug check.
Regards
Santosh
^ permalink raw reply
* [PATCH 16/24] ab8500-bm: Flush all work queues before suspending
From: Lee Jones @ 2013-01-22 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121191411.GA16177@lizard.mcd01528.sjc.wayport.net>
On Mon, 21 Jan 2013, Anton Vorontsov wrote:
> On Mon, Jan 21, 2013 at 12:03:52PM +0000, Lee Jones wrote:
> > From: Jonas Aaberg <jonas.aberg@stericsson.com>
> >
> > Flush all workqueues at suspend time to avoid suspending during work.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
> > Reviewed-by: Marcus COOPER <marcus.xm.cooper@stericsson.com>
> > Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/61915
>
> I do remeber I was commenting on that patch, and I was asking to merge the
> changes into the patches that introduce the workqueues (aka problems).
>
> Now I see that "ab8500_charger: Detect charger removal" commit already in
> the mainline, i.e. I merged the patch with the *known* possible
> regression. The issue was known to me during the first review cycle, and I
> pointed you to my review comments. But the patch sneaked in anyway...
I assure you I didn't _sneak_ any patch in. I'm working on small, simplified
patch-sets for your convenience. I didn't look at the review comments
for this patch until I placed it in this patch-set. By the time I did
look, the offending patch was already in -next. To solve this type of
situation, I can either send you the whole lot in one go with
everything fixed-up and squashed, or we can continue dealing with more
manageable patch-sets where situations like this are bound to happen
occasionally.
Even when working directly with Mainline, we still have patches which
fixup issues which were introduced earlier in the development
cycle. I'm not sure on your view of it exactly, but I don't think it's
the end of the world?
> > ---
> > drivers/power/ab8500_charger.c | 11 +++++++++++
> > drivers/power/ab8500_fg.c | 5 +++++
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/power/ab8500_charger.c b/drivers/power/ab8500_charger.c
> > index da965ee..a632b94 100644
> > --- a/drivers/power/ab8500_charger.c
> > +++ b/drivers/power/ab8500_charger.c
> > @@ -2866,6 +2866,17 @@ static int ab8500_charger_suspend(struct platform_device *pdev,
> > if (delayed_work_pending(&di->check_hw_failure_work))
> > cancel_delayed_work(&di->check_hw_failure_work);
> >
> > + flush_delayed_work(&di->attach_work);
> > + flush_delayed_work(&di->usb_charger_attached_work);
> > + flush_delayed_work(&di->ac_charger_attached_work);
> > + flush_delayed_work(&di->check_usbchgnotok_work);
> > + flush_delayed_work(&di->check_vbat_work);
> > + flush_delayed_work(&di->kick_wd_work);
> > +
> > + flush_work(&di->usb_link_status_work);
> > + flush_work(&di->ac_work);
> > + flush_work(&di->detect_usb_type_work);
> > +
> > return 0;
> > }
> > #else
> > diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
> > index 0378aab..1a78116 100644
> > --- a/drivers/power/ab8500_fg.c
> > +++ b/drivers/power/ab8500_fg.c
> > @@ -2410,6 +2410,11 @@ static int ab8500_fg_suspend(struct platform_device *pdev,
> > struct ab8500_fg *di = platform_get_drvdata(pdev);
> >
> > flush_delayed_work(&di->fg_periodic_work);
> > + flush_work(&di->fg_work);
> > + flush_work(&di->fg_acc_cur_work);
> > + flush_delayed_work(&di->fg_reinit_work);
> > + flush_delayed_work(&di->fg_low_bat_work);
> > + flush_delayed_work(&di->fg_check_hw_failure_work);
> >
> > /*
> > * If the FG is enabled we will disable it before going to suspend
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 23/24] ab8500-bm: Fix minor niggles experienced during testing
From: Lee Jones @ 2013-01-22 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121191324.GA15037@lizard.mcd01528.sjc.wayport.net>
On Mon, 21 Jan 2013, Anton Vorontsov wrote:
> On Mon, Jan 21, 2013 at 12:03:59PM +0000, Lee Jones wrote:
> > When compile testing the new AB8500 Battery Management changes
> > due for inclusion into upstream, there were a few minor niggles
> > which required repairing, or adapting for use against the
> > Mainline kernel. This patch is a collection of them all.
>
> No. This is the third time I'm saying it: the last time I checked, this is
> not how we do development in the mainline.
>
> 1. One logical change at a time;
> 2. Every patch in a sequence must be bisectable, compilable;
> 3. The patches must not "break things temporary" 'because it is easier to
> do development that way'. If you introduce a new feature, make all
> possible to not introduce regressions.
Okay, I'll fix them up instead.
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/power/ab8500_fg.h | 6 ++++--
> > drivers/power/abx500_chargalg.c | 4 ++--
> > drivers/power/pm2301_charger.c | 4 ++--
> > 3 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/power/ab8500_fg.h b/drivers/power/ab8500_fg.h
> > index 946840b..bb78dc9 100644
> > --- a/drivers/power/ab8500_fg.h
> > +++ b/drivers/power/ab8500_fg.h
> > @@ -182,6 +182,7 @@ struct ab8500_fg_test {
> > * @fg_check_hw_failure_work: Work for checking HW state
> > * @cc_lock: Mutex for locking the CC
> > * @fg_kobject: Structure of type kobject
> > + * @test: Structure of type ab8500_fg_test for test purpose
> > */
> > struct ab8500_fg {
> > struct device *dev;
> > @@ -224,6 +225,7 @@ struct ab8500_fg {
> > struct delayed_work fg_check_hw_failure_work;
> > struct mutex cc_lock;
> > struct kobject fg_kobject;
> > + struct ab8500_fg_test test;
>
> You are introducing it, but I don't see any users.
>
> > };
> >
> > extern char *discharge_state[];
> > @@ -232,8 +234,8 @@ extern char *charge_state[];
> > int ab8500_fg_coulomb_counter(struct ab8500_fg *di, bool enable);
> > void ab8500_fg_charge_state_to(struct ab8500_fg *di,
> > enum ab8500_fg_charge_state new_state);
> > -void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> > - enum ab8500_fg_charge_state new_state);
> > +static void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> > + enum ab8500_fg_discharge_state new_state);
> > /* test initialization */
> > #ifdef CONFIG_AB8500_BM_DEEP_DEBUG
> > void ab8500_fg_test_init(struct ab8500_fg *di);
> > diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c
> > index 694f592..cacf512 100644
> > --- a/drivers/power/abx500_chargalg.c
> > +++ b/drivers/power/abx500_chargalg.c
> > @@ -1664,8 +1664,8 @@ static int abx500_chargalg_get_property(struct power_supply *psy,
> > static ssize_t ab8500_chargalg_sysfs_show(struct kobject *kobj,
> > struct attribute *attr, char *buf)
> > {
> > - struct ab8500_chargalg *di = container_of(kobj,
> > - struct ab8500_chargalg, chargalg_kobject);
> > + struct abx500_chargalg *di = container_of(kobj,
> > + struct abx500_chargalg, chargalg_kobject);
>
> Spaces.
>
> >
> > return sprintf(buf, "%d\n",
> > di->susp_status.ac_suspended &&
> > diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
> > index 14e37b2..5ebae88 100644
> > --- a/drivers/power/pm2301_charger.c
> > +++ b/drivers/power/pm2301_charger.c
> > @@ -22,8 +22,8 @@
> > #include <linux/i2c.h>
> > #include <linux/workqueue.h>
> > #include <linux/kobject.h>
> > -#include <linux/mfd/ab8500.h>
> > #include <linux/mfd/abx500.h>
> > +#include <linux/mfd/abx500/ab8500.h>
> > #include <linux/mfd/abx500/ab8500-bm.h>
> > #include <linux/mfd/abx500/ab8500-gpadc.h>
> > #include <linux/mfd/abx500/ux500_chargalg.h>
> > @@ -867,7 +867,7 @@ static int __devinit pm2xxx_wall_charger_probe(struct i2c_client *i2c_client,
> >
> > /* get parent data */
> > pm2->dev = &i2c_client->dev;
> > - pm2->gpadc = ab8500_gpadc_get();
> > + pm2->gpadc = ab8500_gpadc_get("ab8500-gpadc.0");
>
> Was the driver even compilable before? You've just introduced the new
> driver in this exact series. :-/
>
> Since pm2301 is a new driver, please merge all pm2301 stuff into one
> patch.
>
> Or, if you want to preserve the development history of the new driver,
> this is also fine, but then I'd prefer to take it via a pull-request with
> only this driver.
>
> Thanks,
> Anton
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/8] mmc: mmci: Move ios_handler functionality into the driver
From: Lee Jones @ 2013-01-22 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoNXNj=9mG0sR7=g12MJ1xLuRMLqReY7mCEVSBYGvRPhQ@mail.gmail.com>
On Mon, 21 Jan 2013, Ulf Hansson wrote:
> On 21 January 2013 15:06, Lee Jones <lee.jones@linaro.org> wrote:
> > On Thu, 13 Dec 2012, Lee Jones wrote:
> >
> >> There are currently two instances of the ios_handler being used.
> >> Both of which mearly toy with some regulator settings. Now there
> >> is a GPIO regulator API, we can use that instead, and lessen the
> >> per platform burden. By doing this, we also become more Device
> >> Tree compatible.
> >>
> >> Cc: Chris Ball <cjb@laptop.org>
> >> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> >> Acked-by: Ulf Hansson <ulf.hansson@stericsson.com>
> >> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > Any more news on this one?
>
> Not exactly this version of the patch, but another one has has been
> merged through Russell's patch tracker. Available for 3.9.
Nice. Thanks for the update.
> >> drivers/mmc/host/mmci.c | 22 ++++++++++++++++++++++
> >> drivers/mmc/host/mmci.h | 1 +
> >> 2 files changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> >> index edc3e9b..d45c931 100644
> >> --- a/drivers/mmc/host/mmci.c
> >> +++ b/drivers/mmc/host/mmci.c
> >> @@ -1091,6 +1091,16 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> >> case MMC_POWER_OFF:
> >> if (host->vcc)
> >> ret = mmc_regulator_set_ocr(mmc, host->vcc, 0);
> >> +
> >> + if (host->vqmmc) {
> >> + if (regulator_is_enabled(host->vqmmc)) {
> >> + ret = regulator_disable(host->vqmmc);
> >> + if (ret < 0)
> >> + dev_warn(mmc_dev(mmc),
> >> + "unable to disable vmmc-ios\n");
> >> + }
> >> + }
> >> +
> >> break;
> >> case MMC_POWER_UP:
> >> if (host->vcc) {
> >> @@ -1115,6 +1125,14 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> >>
> >> break;
> >> case MMC_POWER_ON:
> >> + if (host->vqmmc)
> >> + if (!regulator_is_enabled(host->vqmmc)) {
> >> + ret = regulator_enable(host->vqmmc);
> >> + if (ret < 0)
> >> + dev_warn(mmc_dev(mmc),
> >> + "unable to enable vmmc-ios\n");
> >> + }
> >> +
> >> pwr |= MCI_PWR_ON;
> >> break;
> >> }
> >> @@ -1379,6 +1397,10 @@ static int __devinit mmci_probe(struct amba_device *dev,
> >> "(using regulator instead)\n");
> >> }
> >> }
> >> +
> >> + host->vqmmc = regulator_get(&dev->dev, "vqmmc");
> >> + if (IS_ERR(host->vqmmc))
> >> + host->vqmmc = NULL;
> >> #endif
> >> /* Fall back to platform data if no regulator is found */
> >> if (host->vcc == NULL)
> >> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> >> index d437ccf..b87d9e2 100644
> >> --- a/drivers/mmc/host/mmci.h
> >> +++ b/drivers/mmc/host/mmci.h
> >> @@ -194,6 +194,7 @@ struct mmci_host {
> >> struct sg_mapping_iter sg_miter;
> >> unsigned int size;
> >> struct regulator *vcc;
> >> + struct regulator *vqmmc;
> >>
> >> #ifdef CONFIG_DMA_ENGINE
> >> /* DMA stuff */
> >
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Peter Korsgaard @ 2013-01-22 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301220213390.25789@utopia.booyaka.com>
>>>>> "Paul" == Paul Walmsley <paul@pwsan.com> writes:
Paul> Hi guys,
Paul> Regarding the AM33xx test failures with appended DTBs, it would
Paul> be very helpful if especially the TI people could try reproducing
Paul> the problem. Otherwise it's going to cause problems with merging
Paul> any new AM33xx patches, since I won't be able to test them
Paul> without additional work. Plus, this is something that used to
Paul> work up until d01e4afd, so something isn't right.
Paul> You'll need to use the bootloader that TI originally shipped with
Paul> the BeagleBones:
Paul> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
FYI, my beaglebone came with a slightly different U-Boot:
U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14)
But I have the same behaviour. Recent kernels work with a modern U-Boot,
but not the original. The build I'm doing is very similar to yours:
git describe
v3.8-rc4-71-g9a92841
make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
echo CONFIG_ARM_APPENDED_DTB=y >> .config
echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config
yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig
make ARCH=arm CROSS_COMPILE=arm-linux-
cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage
make ARCH=arm CROSS_COMPILE=arm-linux- uImage
# old u-boot (ethernet not stable here, so load from sd)
U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14)
Texas Instruments Revision detection unimplemented
No AC power, disabling frequency switch
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2011.09-00000-gf63b270-dirty (Nov 14 2011 - 10:37:14)
I2C: ready
DRAM: 256 MiB
No daughter card present
NAND: HW ECC Hamming Code selected
nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10
No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot# mmc rescan
U-Boot# fatload mmc 0:1 0x80200000 uImage.new
reading uImage.new
3945127 bytes read
U-Boot# setenv bootargs console=$console
U-Boot# bootm 0x80200000
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.8.0-rc4-00071-g9a92841
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3945063 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
And it hangs. With a reasonably modern U-Boot it works:
U-Boot SPL 2012.10 (Oct 29 2012 - 23:39:02)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2012.10 (Oct 29 2012 - 23:39:02)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot# dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.2
Using cpsw device
TFTP from server 172.16.1.1; our IP address is 172.16.1.2
Filename 'uImage'.
Load address: 0x80200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#########
done
Bytes transferred = 3945127 (3c32a7 hex)
U-Boot# setenv bootargs console=$console
U-Boot# bootm
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-3.8.0-rc4-00071-g9a92841
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3945063 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc4-00071-g9a92841 (peko at dell) (gcc version 3
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335e
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
...
For the failing case, __log_buf doesn't contain anything sensible so I
guess it crashes early:
grep __log_buf System.map
c07cc450 b __log_buf
U-Boot# md 807cc450
807cc450: e5749fbf ef220eff 3df957df acebffbd ..t..."..W.=....
807cc460: 61dfffff 7e93c5ef ddbafdfd bb2ac2fd ...a...~......*.
807cc470: 7ffffff1 f7fafd7f 717ddf7f 3feecfbc ..........}q...?
807cc480: bddb573d beeaba9b c57f7b99 f77dfbfe =W.......{....}.
807cc490: 6b7dde97 ebffcfaf fdf62df5 77e5f7bb ..}k.....-.....w
807cc4a0: 5fdffdf5 7bc2d8be 7d977ddd feafafff ..._...{.}.}....
807cc4b0: f7429df5 76e2fd6d dedffd3d cf6769ff ..B.m..v=....ig.
807cc4c0: fb5644dd bdcf3a69 ffbfffd9 befff9ae .DV.i:..........
807cc4d0: f7537fd7 feafe2f2 f37c7c2f fe5ffded ..S...../||..._.
807cc4e0: d757dcff 4aefffbf f5dfdbdf febccbef ..W....J........
807cc4f0: 0efff5fd 9effca7a f757ffff 07fffeff ....z.....W.....
807cc500: deffd1db edbe5ef7 d5e7e579 bf63deef .....^..y.....c.
807cc510: edbece57 7cfdebbf f5371f9e f0ffffb3 W......|..7.....
807cc520: 3fa4ffdf cae9fd66 f6f71d4f ab777d5f ...?f...O..._}w.
807cc530: ed9df97d f7fcfeee dff7fb7c 3dbacafe }.......|......=
807cc540: 47effd7c b9f9b78e ddc5f7b7 fe2f2bea |..G.........+/.
Any ideas?
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Linus Walleij @ 2013-01-22 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FB8986.9010205@nvidia.com>
On Sun, Jan 20, 2013 at 7:07 AM, Alex Courbot <acourbot@nvidia.com> wrote:
> Actually the question of switching to GPIOlib is only worth being asked if
> you are making use of drivers that require GENERIC_GPIO. If this is not the
> case and your GPIOs are only used by your own platform code, you can always
> give up using defining GENERIC_GPIO and continue implementing them your own
> way.
Agreed. The problem can be summed up like this:
#include <linux/gpio.h>
Considered ambiguous.
#include <asm/foo/bar/baz-gpio.h>
OK with me.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver
From: Lee Jones @ 2013-01-22 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355495429-12510-3-git-send-email-ulf.hansson@stericsson.com>
> From: Lee Jones <lee.jones@linaro.org>
>
> There are currently two instances of the ios_handler being used.
> Both of which mearly toy with some regulator settings. Now there
> is a GPIO regulator API, we can use that instead, and lessen the
> per platform burden. By doing this, we also become more Device
> Tree compatible.
Russell,
Why is this patch in your tree with Ulf as the Author?
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mmc/host/mmci.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 9da5f24..e56655a 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1097,6 +1097,11 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> case MMC_POWER_OFF:
> if (!IS_ERR(mmc->supply.vmmc))
> mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> + if (!IS_ERR(mmc->supply.vqmmc) &&
> + regulator_is_enabled(mmc->supply.vqmmc))
> + regulator_disable(mmc->supply.vqmmc);
> +
> break;
> case MMC_POWER_UP:
> if (!IS_ERR(mmc->supply.vmmc))
> @@ -1111,6 +1116,10 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>
> break;
> case MMC_POWER_ON:
> + if (!IS_ERR(mmc->supply.vqmmc) &&
> + !regulator_is_enabled(mmc->supply.vqmmc))
> + regulator_enable(mmc->supply.vqmmc);
> +
> pwr |= MCI_PWR_ON;
> break;
> }
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/6] arm: mvebu: Add support for local interrupt
From: Gregory CLEMENT @ 2013-01-22 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121232637.GA3412@localhost>
On 01/22/2013 12:26 AM, Ezequiel Garcia wrote:
> Hi Thomas and Gregory,
>
> On Mon, Jan 21, 2013 at 11:07:10PM +0100, Gregory CLEMENT wrote:
>> On 01/21/2013 07:17 PM, Thomas Petazzoni wrote:
>>>> + irq_set_percpu_devid(virq);
>>>> + irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
>>>> + handle_percpu_devid_irq);
>>>> +
>>>> + } else {
>>>> + irq_set_chip_and_handler(virq, &armada_370_xp_irq_chip,
>>>> + handle_level_irq);
>>>> + }
>>>
>>> Braces useless since there is only one statement in the else.
>>>
>
> IMHO, this is an exception to the rule.
> Since the first block is more than one line,
> we usually put braces on the single line block too.
> (or at least that's what Documentation/CodingStyle says).
>
You're right!
I would have liked to say I have done it on purpose, but in fact these
braces are here only because during development I had had multiples lines
inside the else.
However, as you pointed it, I will keep it.
> Regards,
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v7 08/15] gpio: pl061: bind pinctrl by gpio request
From: Linus Walleij @ 2013-01-22 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6h2NQm+VoUv9tDSoHv3Xs8RtuCt5A+_DCBx6bh-d3WP3PK=w@mail.gmail.com>
On Mon, Jan 21, 2013 at 4:45 PM, Haojian Zhuang
<haojian.zhuang@linaro.org> wrote:
>> > + pinctrl_request_gpio(gpio);
>>
>> Handling of error code?
>>
>> (Maybe I should add a __must_check on this function.)
>>
> My case is a little special. I don't want to check return value because some
> gpio pins don't have pinmux registers in Hisilicon SoC.
> So pinctrl_request_gpio() will always return error for these special pins in
> Hisilicon SoC.
>
> If we must check the return value, maybe we need append a dummy pinctrl driver
> for those special gpio pins. How do you think about it? Of course, I
> need to evaluate
> whether it's possible to implement.
Hm. A dummy pinctrl back-end is not very elegant.
It's better if the GPIO driver (gpio-pl061) keep track of the ranges that
are connected to the pinctrl.
If the ranges are encoded in the device tree (as I guess you want to do
in this case) then the GPIO driver need to check these ranges to see if
it uses a pinctrl backend. Magic behind-the-scenes is very hard to
understand for people reading this code later.
What about this:
In gpiolib.c, function gpiochip_add_pin_range(), we save a copy of
each range in &chip->pin_ranges.
Add a function to gpiolib.c to check if a certain gpio is in the range
of the current chip.
Then use that:
if (gpio_in_pinrange(gpio))
pinctrl_request_gpio(gpio);
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 7/7] clk: vexpress: Use common of_clk_init() function
From: Linus Walleij @ 2013-01-22 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118175827.3982.65450@quantum>
On Fri, Jan 18, 2013 at 6:58 PM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Prashant Gaikwad (2013-01-03 23:00:58)
>> Use common of_clk_init() function for clock initialization.
>>
>> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
>
> Pawel or Linus,
>
> Can I get a Tested-by before I take this series into clk-next?
For this specific patch, I don't have a vexpress board, sorry...
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Nomadik devicetree and cleanups
From: Linus Walleij @ 2013-01-22 9:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC guys,
This patch series converts the Nomadik to use Device Tree.
Changes outside of the subsystem are constrained to pinctrl (my subsystem
and thus OK:ed) and a oneline in drivers/mtd/nand/fsmc_nand.c adding
a new compatible value.
The MTD maintainers have had time enough to ACK that oneliner and it
shouldn't be a big issue, so:
Please pull this into your tree.
Yours,
Linus Walleij
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/nomadik-devicetree
for you to fetch changes up to bf82c67edcc8751903bdd7e45626c47cd2cc7834:
ARM: nomadik: get rid of <mach/hardware.h> (2013-01-22 08:45:36 +0100)
----------------------------------------------------------------
This patch set converts the Nomadik (mach-nomadik) to
Device Tree and delete the old board files, paving the
road for single zImage.
----------------------------------------------------------------
Linus Walleij (11):
ARM: nomadik: move last custom calls to pinctrl
ARM: nomadik: initial devicetree support
ARM: nomadik: move pin maps to cpu file
ARM: nomadik: move remaining PrimeCells to device tree
ARM: nomadik: add FSMC NAND
ARM: nomadik: move GPIO and pinctrl to device tree
ARM: nomadik: convert SMSC91x ethernet to device tree
ARM: nomadik: migrate MMC/SD card support to device tree
ARM: nomadik: add I2C devices to the device tree
ARM: nomadik: delete old board files
ARM: nomadik: get rid of <mach/hardware.h>
.../devicetree/bindings/arm/ste-nomadik.txt | 27 ++
.../devicetree/bindings/mtd/fsmc-nand.txt | 2 +-
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ste-nomadik-s8815.dts | 30 ++
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 256 ++++++++++++++
arch/arm/mach-nomadik/Kconfig | 10 +-
arch/arm/mach-nomadik/Makefile | 6 -
arch/arm/mach-nomadik/board-nhk8815.c | 359 --------------------
arch/arm/mach-nomadik/cpu-8815.c | 370 +++++++++++++++------
arch/arm/mach-nomadik/cpu-8815.h | 4 -
arch/arm/mach-nomadik/i2c-8815nhk.c | 88 -----
arch/arm/mach-nomadik/include/mach/hardware.h | 90 -----
arch/arm/mach-nomadik/include/mach/irqs.h | 2 -
arch/arm/mach-nomadik/include/mach/uncompress.h | 1 -
drivers/mtd/nand/fsmc_nand.c | 1 +
drivers/pinctrl/pinctrl-nomadik.c | 4 +
17 files changed, 601 insertions(+), 652 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/ste-nomadik.txt
create mode 100644 arch/arm/boot/dts/ste-nomadik-s8815.dts
create mode 100644 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
delete mode 100644 arch/arm/mach-nomadik/board-nhk8815.c
delete mode 100644 arch/arm/mach-nomadik/cpu-8815.h
delete mode 100644 arch/arm/mach-nomadik/i2c-8815nhk.c
delete mode 100644 arch/arm/mach-nomadik/include/mach/hardware.h
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC v3.9
From: Paul Mundt @ 2013-01-22 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122082123.GA28100@quad.lixom.net>
On Tue, Jan 22, 2013 at 12:21:23AM -0800, Olof Johansson wrote:
> On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> > Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline,
> > then push 7 through the pinctrl tree, wait until it reaches mainline, push 8
> > through the SH tree and 9 through the ARM tree, wait until they reach
> > mainline, and finally push 10 through the pinctrl tree again. We could even
> > push each branch through the tree it belongs to, but I doubt we'll be able to
> > push everything during a single merge window.
>
> Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
> can do so, I was of the initial impression from Simon's cover letter
> that the arch/sh branches would also go through the SH tree.
>
> This seems to be a particularly hairy conversion, given that it touches two
> architectures that need to be updated in lockstep. I guess we might be just as
> well off pulling it in as-is (with below exceptions) to get it in.
>
> If you need the same contents in the SH tree due to dependencies and
> later development, let me know and we can agree on a stable branch that
> we both pick up in either tree that has all contents.
>
There isn't anything at the moment pending for the SH tree that cares
about or conflicts with any of this work, so it's ok with me if this all
goes through arm-soc. If there is any fallout we can take care of it
later on in the merge window. This would seem to be a saner option than
attempting to merge half a dozen branches with dependencies on each other
in precise order, which doesn't leave a lot of time for fixing up
any residual merge window damage.
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Jan Lübbe @ 2013-01-22 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301220213390.25789@utopia.booyaka.com>
On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote:
> Regarding the AM33xx test failures with appended DTBs, it would be very
> helpful if especially the TI people could try reproducing the problem.
> Otherwise it's going to cause problems with merging any new AM33xx
> patches, since I won't be able to test them without additional work.
> Plus, this is something that used to work up until d01e4afd, so something
> isn't right.
Just a guess, but there can be problems when the appended DTB crosses an
1MB boundary. See this mail for details and a patch:
http://www.spinics.net/lists/arm-kernel/msg216898.html
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 23/24] ab8500-bm: Fix minor niggles experienced during testing
From: Lee Jones @ 2013-01-22 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121191324.GA15037@lizard.mcd01528.sjc.wayport.net>
On Mon, 21 Jan 2013, Anton Vorontsov wrote:
> On Mon, Jan 21, 2013 at 12:03:59PM +0000, Lee Jones wrote:
> > When compile testing the new AB8500 Battery Management changes
> > due for inclusion into upstream, there were a few minor niggles
> > which required repairing, or adapting for use against the
> > Mainline kernel. This patch is a collection of them all.
>
> No. This is the third time I'm saying it: the last time I checked, this is
> not how we do development in the mainline.
Okay, all of these changes have now been fixed-up into the patches
which caused the issues. I have also added Stable to the patch you
requested it on.
How would you like to proceed? Do you want a pull-request, or for me
to send the patches to the list again?
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > drivers/power/ab8500_fg.h | 6 ++++--
> > drivers/power/abx500_chargalg.c | 4 ++--
> > drivers/power/pm2301_charger.c | 4 ++--
> > 3 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/power/ab8500_fg.h b/drivers/power/ab8500_fg.h
> > index 946840b..bb78dc9 100644
> > --- a/drivers/power/ab8500_fg.h
> > +++ b/drivers/power/ab8500_fg.h
> > @@ -182,6 +182,7 @@ struct ab8500_fg_test {
> > * @fg_check_hw_failure_work: Work for checking HW state
> > * @cc_lock: Mutex for locking the CC
> > * @fg_kobject: Structure of type kobject
> > + * @test: Structure of type ab8500_fg_test for test purpose
> > */
> > struct ab8500_fg {
> > struct device *dev;
> > @@ -224,6 +225,7 @@ struct ab8500_fg {
> > struct delayed_work fg_check_hw_failure_work;
> > struct mutex cc_lock;
> > struct kobject fg_kobject;
> > + struct ab8500_fg_test test;
>
> You are introducing it, but I don't see any users.
>
> > };
> >
> > extern char *discharge_state[];
> > @@ -232,8 +234,8 @@ extern char *charge_state[];
> > int ab8500_fg_coulomb_counter(struct ab8500_fg *di, bool enable);
> > void ab8500_fg_charge_state_to(struct ab8500_fg *di,
> > enum ab8500_fg_charge_state new_state);
> > -void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> > - enum ab8500_fg_charge_state new_state);
> > +static void ab8500_fg_discharge_state_to(struct ab8500_fg *di,
> > + enum ab8500_fg_discharge_state new_state);
> > /* test initialization */
> > #ifdef CONFIG_AB8500_BM_DEEP_DEBUG
> > void ab8500_fg_test_init(struct ab8500_fg *di);
> > diff --git a/drivers/power/abx500_chargalg.c b/drivers/power/abx500_chargalg.c
> > index 694f592..cacf512 100644
> > --- a/drivers/power/abx500_chargalg.c
> > +++ b/drivers/power/abx500_chargalg.c
> > @@ -1664,8 +1664,8 @@ static int abx500_chargalg_get_property(struct power_supply *psy,
> > static ssize_t ab8500_chargalg_sysfs_show(struct kobject *kobj,
> > struct attribute *attr, char *buf)
> > {
> > - struct ab8500_chargalg *di = container_of(kobj,
> > - struct ab8500_chargalg, chargalg_kobject);
> > + struct abx500_chargalg *di = container_of(kobj,
> > + struct abx500_chargalg, chargalg_kobject);
>
> Spaces.
>
> >
> > return sprintf(buf, "%d\n",
> > di->susp_status.ac_suspended &&
> > diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
> > index 14e37b2..5ebae88 100644
> > --- a/drivers/power/pm2301_charger.c
> > +++ b/drivers/power/pm2301_charger.c
> > @@ -22,8 +22,8 @@
> > #include <linux/i2c.h>
> > #include <linux/workqueue.h>
> > #include <linux/kobject.h>
> > -#include <linux/mfd/ab8500.h>
> > #include <linux/mfd/abx500.h>
> > +#include <linux/mfd/abx500/ab8500.h>
> > #include <linux/mfd/abx500/ab8500-bm.h>
> > #include <linux/mfd/abx500/ab8500-gpadc.h>
> > #include <linux/mfd/abx500/ux500_chargalg.h>
> > @@ -867,7 +867,7 @@ static int __devinit pm2xxx_wall_charger_probe(struct i2c_client *i2c_client,
> >
> > /* get parent data */
> > pm2->dev = &i2c_client->dev;
> > - pm2->gpadc = ab8500_gpadc_get();
> > + pm2->gpadc = ab8500_gpadc_get("ab8500-gpadc.0");
>
> Was the driver even compilable before? You've just introduced the new
> driver in this exact series. :-/
>
> Since pm2301 is a new driver, please merge all pm2301 stuff into one
> patch.
>
> Or, if you want to preserve the development history of the new driver,
> this is also fine, but then I'd prefer to take it via a pull-request with
> only this driver.
>
> Thanks,
> Anton
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
From: Roger Quadros @ 2013-01-22 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301211502190.8450@utopia.booyaka.com>
On 01/21/2013 05:03 PM, Paul Walmsley wrote:
> Hi
>
> On Mon, 21 Jan 2013, Roger Quadros wrote:
>
>> On 01/18/2013 10:27 PM, Paul Walmsley wrote:
>>> On Fri, 18 Jan 2013, Roger Quadros wrote:
>>>
>>>> We don't need multiple aliases for the OMAP USB host clocks and neither
>>>> the dummy clocks so remove them.
>>>>
>>>> CC: Paul Walmsley <paul@pwsan.com>
>>>> CC: Rajendra Nayak <rnayak@ti.com>
>>>> CC: Benoit Cousson <b-cousson@ti.com>
>>>> CC: Mike Turquette <mturquette@linaro.com>
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> Reviewed-by: Felipe Balbi <balbi@ti.com>
>>>> Acked-by: Paul Walmsley <paul@pwsan.com>
>>>
>>> Per Tony's earlier request, you can drop this patch and patch 20 from your
>>> series now. I've got them queued for 3.10 or late 3.9 merge window.
>>>
>>
>> Should have mentioned it earlier, but just this patch without the rest
>> of the cleanup patches will break USB Host on OMAP3, as the old driver
>> bails out if optional clock nodes are missing.
>>
>> Including patch 20 doesn't seem to cause a problem with OMAP4 though.
>
> I've got these two patches queued for merging after your other patches go
> upstream -- e.g., probably 3.10. Do you foresee any problems with that?
>
That should be fine. Thanks :).
--
cheers,
-roger
^ permalink raw reply
* ARM: hw_breakpoint mismatch breakpoint behaves unexpectedly like a match breakpoint on ARM_DEBUG_ARCH_V7_ECP14
From: Will Deacon @ 2013-01-22 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPfQmKJaYf6M4iHKuNcHgYZi5R8M7fXdXta34Q=1C0cHKimkyQ@mail.gmail.com>
On Tue, Jan 22, 2013 at 04:28:35AM +0000, Valentin Pistol wrote:
> Hi Will,
Hi Valentin,
> I am trying to single-step each instruction in a target process by
> using the hardware breakpoints with the mismatch set (bit 22) and I am
> experiencing unexpected behavior: with mismatch set it behaves as a
> match breakpoint.
> I checked that my Debug Arch ARM_DEBUG_ARCH_V7_ECP14 has mismatch
> breakpoint support.
> The BCR (0x4001e5) value and DSCR (0x3070002) seem to be correct
> according to the manual, so I am confused what is causing the odd
> behavior.
[...]
> I should note that I am able to set a match breakpoint using the
> ptrace interface, have it trigger a SIGTRAP and capture it in my own
> user space handler. When attempting to use mismatch instead, the
> behavior appears to be same as a match breakpoint: breaks on the
> specified PC value.
The ptrace interface doesn't support mismatch breakpoints, and ignores those
bits in the user request, hence why you see a normal breakpoint being
created. Note that mismatch breakpoints are used internally for stepping
over breakpoints set by perf.
If you wanted to add single-step using mismatch breakpoints, I think we'd be
better off re-introducing the SINGLESTEP ptrace request for ARM to use
hw_breakpoints.
Will
^ permalink raw reply
* [PATCH v3 4/8] MFD: ti_am335x_tscadc: add device tree binding information
From: Patil, Rachna @ 2013-01-22 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FB1DFE.6090805@metafoo.de>
Hi,
On Sun, Jan 20, 2013 at 03:58:14, Lars-Peter Clausen wrote:
> Hi,
>
> On 01/18/2013 11:48 AM, Patil, Rachna wrote:
> > From: "Patil, Rachna" <rachna@ti.com>
> >
> > Signed-off-by: Patil, Rachna <rachna@ti.com>
> > ---
> > .../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 35 ++++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > new file mode 100644
> > index 0000000..c13c492
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > @@ -0,0 +1,35 @@
> > +Texas Instruments - TSC / ADC multi-functional device
> > +
> > +ti_tscadc is a multi-function device with touchscreen and ADC on chip.
> > +This document describes the binding for mfd device.
> > +
> > +Required properties:
> > +- compatible: "ti,ti-tscadc"
> > +- reg: Specifies the address of MFD block
> > +- interrupts: IRQ line connected to the main SoC
> > +- interrupt-parent: The parent interrupt controller
>
> The subnodes and their properties also need documentation.
Ok. I Will add this.
>
> > +
> > +Optional properties:
> > +- ti,hwmods: Hardware information related to TSC/ADC MFD device
> > +
> > +Example:
> > +
> > + tscadc: tscadc at 44e0d000 {
> > + compatible = "ti,ti-tscadc";
> > + reg = <0x44e0d000 0x1000>;
> > +
> > + interrupt-parent = <&intc>;
> > + interrupts = <16>;
> > + ti,hwmods = "adc_tsc";
> > +
> > + tsc {
> > + wires = <4>;
> > + x-plate-resistance = <200>;
> > + steps-to-configure = <5>;
> > + wire-config = <0x00 0x11 0x22 0x33>;
>
> Non-standard properties should have a vendor prefix.
Ok. I will fix this in the next version of the patch set.
Regards,
Rachna
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Arnd Bergmann @ 2013-01-22 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE307F.9000701@ti.com>
On Tuesday 22 January 2013, Santosh Shilimkar wrote:
> On Tuesday 22 January 2013 04:53 AM, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [130121 13:07]:
> >>
> >> As for Samsung and the rest I can't comment. The original reason OMAP
> >> used this though was because the 32768Hz counter can't produce 100Hz
> >> without a .1% error - too much error under pre-clocksource
> >> implementations for timekeeping. Whether that's changed with the
> >> clocksource/clockevent support needs to be checked.
> >
> > Yes that's why HZ was originally set to 128. That value (or some multiple)
> > still makes sense when the 32 KiHZ clock source is being used. Of course
> > we should rely on the local timer when running for the SoCs that have
> > them.
> >
> This is right. It was only because of the drift associated when clocked
> with 32KHz. Even on SOCs where local timers are available for power
> management reasons we need to switch to 32KHz clocked device in
> low power states. Hence the HZ value should be multiple of 32 on
> OMAP.
I need some help understanding what the two of you are saying, because
it sounds to me that you imply we cannot have a multiplatform kernel
that includes OMAP and another platform that needs (or wants) a different
HZ value.
However, I also thought that when using a proper clocksource driver,
the HZ setting has absolutely no impact on the drift of the wall clock,
because those two are decoupled.
Even when using the HZ based clocksource (for whatever reason you
would want to do that), I thought there should be no drift as long
as the CLOCK_TICK_RATE (in older kernels) or the register_refined_jiffies()
(in older kernels) setting matches the hardware timer frequency.
What am I missing?
Arnd
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Peter Korsgaard @ 2013-01-22 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358846666.3996.3.camel@coredoba.hi.pengutronix.de>
>>>>> "Jan" == Jan L?bbe <jlu@pengutronix.de> writes:
Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote:
>> Regarding the AM33xx test failures with appended DTBs, it would be very
>> helpful if especially the TI people could try reproducing the problem.
>> Otherwise it's going to cause problems with merging any new AM33xx
>> patches, since I won't be able to test them without additional work.
>> Plus, this is something that used to work up until d01e4afd, so something
>> isn't right.
Jan> Just a guess, but there can be problems when the appended DTB
Jan> crosses an 1MB boundary. See this mail for details and a patch:
Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html
True, but that doesn't seem to be the case here:
ls -la arch/arm/boot/uImage
-rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage
E.G. far from the 1MB boundary.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Linus Walleij @ 2013-01-22 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358785488.6590.33.camel@hornet>
On Mon, Jan 21, 2013 at 5:24 PM, Pawel Moll <pawel.moll@arm.com> wrote:
> Hm. Doesn't this make the MMCI probing depending on the module_init
> order? As in: wouldn't it make the mmci probe completely fail (not even
> defer it) if it was called before the pl061? In that case even your,
> Linus, hack with inverting the CD status wouldn't work...
According to Haojian it works, but for sure the MMCI driver *should*
(on the eternal list of SHOULDDO) bail out and return any
-EPROBE_DEFER up to the AMBA bus core properly so it
will be tried again later if this happens.
AFAICT gpio_request() will return -EPROBE_DEFER if the GPIO
cannot be located.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] ARM: apply the l2x0 Errata 769419 at run time
From: Russell King - ARM Linux @ 2013-01-22 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122055916.GA22429@bnru10>
On Tue, Jan 22, 2013 at 11:29:17AM +0530, Srinidhi Kasagar wrote:
> On Mon, Jan 21, 2013 at 17:12:02 +0100, Russell King - ARM Linux wrote:
> > Is it really worth this hastle, or would it just be better to keep the
> > ifdef there, using the configuration symbol as a way to indicate whether
> > we want this work-around included in the kernel, and always have the
> > wmb() there if the symbol is enabled?
> We can keep the ifdef there, my idea was to completely eliminate these
> CONFIG_PL310_ERRATA_*. The problem comes when you have a single defconfig
> for two platforms (ex, ST-E's 8500 and 8540) where one platform needs
> this and the other don't.
And the answer is... if you don't need it at all in the kernel, because
none of your platforms need it, you can eliminate it. If one of your
platforms needs it, it's probably best to compile it in and make it
unconditional there.
^ permalink raw reply
* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Linus Walleij @ 2013-01-22 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358799606.3592.14.camel@linux-builds1>
On Mon, Jan 21, 2013 at 9:20 PM, Dinh Nguyen <dinguyen@altera.com> wrote:
>> > Pawel, Dinh: are you OK with this change?
>
> Still works ok on mach-socfpga.
Thanks! Adding your Tested-by tag, OK?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Linus Walleij @ 2013-01-22 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358494279-16503-10-git-send-email-haojian.zhuang@linaro.org>
On Fri, Jan 18, 2013 at 8:31 AM, Haojian Zhuang
<haojian.zhuang@linaro.org> wrote:
> Replace subsys initcall by module initcall level. Since pinctrl
> driver is already launched before gpio driver. It's unnecessary
> to set gpio driver in subsys init call level.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
OK some consensus that this works, and moving initcalls to module_init()
should be encouraged, so applied this and thrown at linux-next for
testing. No pain no gain.
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