* [Patch v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
From: Hebbar Gururaja @ 2013-01-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359642327-5542-1-git-send-email-gururaja.hebbar@ti.com>
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
---
Change in v2:
- No change
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
^ permalink raw reply related
* [Patch v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
From: Hebbar Gururaja @ 2013-01-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359642327-5542-1-git-send-email-gururaja.hebbar@ti.com>
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
---
Change in v2:
- new patch
:100644 100644 646c14d... 1ab693e... M arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = "wkup_m3",
.class = &am33xx_wkup_m3_hwmod_class,
.clkdm_name = "l4_wkup_aon_clkdm",
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = "dpll_core_m4_div2_ck",
.prcm = {
--
1.7.9.5
^ permalink raw reply related
* [Patch v2 0/2] ARM: OMAP2+: AM33xx: fix hwmod & Clock Control Module
From: Hebbar Gururaja @ 2013-01-31 14:25 UTC (permalink / raw)
To: linux-arm-kernel
1. Add add missing HWMOD_NO_IDLEST flags
2. Fix "register offset NULL check" bug
Changes in v2:
- As per Paul's suggestion 1st add HWMOD_NO_IDLEST flag where
it is necessary and then correct the clock control register
offset check bug.
Hebbar Gururaja (2):
ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
ARM: OMAP2: am33xx-hwmod: Fix "register offset NULL check" bug
arch/arm/mach-omap2/cm33xx.c | 3 ---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 3 ++-
2 files changed, 2 insertions(+), 4 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/4] drm/i2c: nxp-tda998x (v3)
From: Rob Clark @ 2013-01-31 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5109D5BA.2030801@gmail.com>
On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
<sebastian.hesselbarth@gmail.com> wrote:
> On 01/29/2013 06:23 PM, Rob Clark wrote:
>>
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>
>
> Rob,
>
> good to see a driver for TDA998x comming! I'd love to test
> it on CuBox (mach-dove) but there is no gpu driver I can hook up,
> yet. Anyway, I will make some comments how I think the driver
> should be improved.
>
>
>> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
>> index 1611836..4d341db 100644
>> --- a/drivers/gpu/drm/i2c/Kconfig
>> +++ b/drivers/gpu/drm/i2c/Kconfig
>> @@ -19,4 +19,10 @@ config DRM_I2C_SIL164
>> when used in pairs) TMDS transmitters, used in some nVidia
>> video cards.
>>
>> +config DRM_I2C_NXP_TDA998X
>> + tristate "NXP Semiconductors TDA998X HDMI encoder"
>> + default m if DRM_TILCDC
>> + help
>> + Support for NXP Semiconductors TDA998X HDMI encoders.
>
>
> Maybe nit-picking but later down you actually support TDA9989,
> TDA19988, and TDA19989. The latter ones don't fit in TDA998x,
> so at least the Kconfig entry should reflect TDA9989/TDA1998x.
yeah, it is a bit weird naming scheme, but I'm just copying NXP in
referring to the whole family as TDA998x
>> [...]
>>
>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>> new file mode 100644
>> index 0000000..e68b58a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>> @@ -0,0 +1,906 @@
>> +/*
>> + * Copyright (C) 2012 Texas Instruments
>> + * Author: Rob Clark<robdclark@gmail.com>
>> + *
>> +
>> [...]
>>
>> +
>> +/* The TDA9988 series of devices use a paged register scheme.. to
>> simplify
>> + * things we encode the page # in upper bits of the register #. To read/
>> + * write a given register, we need to make sure CURPAGE register is set
>> + * appropriately. Which implies reads/writes are not atomic. Fun!
>> + */
>
>
> Please have a look at regmap-i2c, it also supports paged i2c registers
> and will save you _a lot_ of the i2c handling.
Yeah, I have looked at it, and will eventually convert over to using
it. The problems at the moment are that I don't really have enough
documentation about the chip at the register level to properly use the
caching modes, and from my digging through the regmap code it looked
like paged regmap + non-caching will result in writes to the page
register for every transaction. That, and a bit of docs or few more
examples of using the paging support in regmap would be nice. For
now, I am punting on regmap conversion.
>> [...]
>>
>> +
>> +/* Device versions: */
>> +#define TDA9989N2 0x0101
>> +#define TDA19989 0x0201
>> +#define TDA19989N2 0x0202
>> +#define TDA19988 0x0301
>
>
> Maybe split this into device_version/revision? What does N2 stand for
> or is this the name NXP uses for that device?
The register names are based on the names used in the NXP out-of-tree
driver (the 50kloc monstrosity, if you've seen it).. that was pretty
much all the register level documentation I had.
>> [...]
>
>> +static void
>> +cec_write(struct drm_encoder *encoder, uint16_t addr, uint8_t val)
>> +{
>> + struct i2c_client *client = to_tda998x_priv(encoder)->cec;
>> + uint8_t buf[] = {addr, val};
>> + int ret;
>> +
>> + ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
>> + if (ret< 0)
>> + dev_err(&client->dev, "Error %d writing to cec:0x%x\n",
>> ret, addr);
>> +}
>
>
> Has there been any decision on how to split/integrate cec from drm?
> Or is there display stuff located in cec i2c slave (I see HPD in
> ..._detect below)?
not sure, but at least in this case it can't really be decoupled. I
need to use the CEC interface for HPD (as you noticed) and also to
power up the HDMI bits..
>> [...]
>>
>> +static void
>> +tda998x_encoder_save(struct drm_encoder *encoder)
>> +{
>> + DBG("");
>> +}
>> +
>> +static void
>> +tda998x_encoder_restore(struct drm_encoder *encoder)
>> +{
>> + DBG("");
>> +}
>
>
> Hmmm, these DBG("") shouldn't be in upstream kernel code?
>
yeah, I suppose these traces don't add too much value, I can remove them
>> +static bool
>> +tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> + return true;
>> +}
>> +
>> +static int
>> +tda998x_encoder_mode_valid(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode)
>> +{
>> + return MODE_OK;
>> +}
>
>
> At least a note would be helpful to see what callbacks are
> not yet done. I guess there will be some kind of mode check
> someday?
Well, some of these drm will assume the fxn ptrs are not null, so we
need something even if it is empty.
I suppose there are must be some upper bounds on pixel clock
supported, which could perhaps be added some day in _mode_valid(). On
the device I am working on, the limiting factor is the crtc (upstream
of the encoder), so I haven't really needed this yet. I expect that
as people start using this on some other devices, we'll come across
some enhancements needed, some places where we need to add some
configuration, etc. I cannot really predict exactly what is needed,
so I prefer just to put the driver out there in some form, and then
add it it as needed. So, I wouldn't really say that these functions
are "TODO", but I also wouldn't say that we won't find some reason to
add some code there at some point.
>> [...]
>>
>> +static enum drm_connector_status
>> +tda998x_encoder_detect(struct drm_encoder *encoder,
>> + struct drm_connector *connector)
>> +{
>> + uint8_t val = cec_read(encoder, REG_CEC_RXSHPDLEV);
>> + return (val& CEC_RXSHPDLEV_HPD) ? connector_status_connected :
>> + connector_status_disconnected;
>> +}
>
>
> This is where cec slave gets called from hdmi i2c driver. Any chance
> there is HPD status in hdmi registers, too?
Not that I know of. But like I mentioned, we also need to use the CEC
interface just to talk to the HDMI interface. Before setting ENAMODS
reg via cec address, the hdmi address won't even show up (for ex, on
i2cdetect).
Maybe there is some way that this code should register some interface
with CEC driver/subsystem? (Is there such a thing? I am not really
CEC expert.) But I don't think there is any way to completely split
it out.
>
>> +/* I2C driver functions */
>> +
>> +static int
>> +tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
>> +{
>> + return 0;
>> +}
>> +
>> +static int
>> +tda998x_remove(struct i2c_client *client)
>> +{
>> + return 0;
>> +}
>
>
> Hmm, empty _probe and _remove? Maybe these should get some code
> from _init below?
naw, they aren't really used for drm i2c encoder slaves.
>> +static int
>> +tda998x_encoder_init(struct i2c_client *client,
>> + struct drm_device *dev,
>> + struct drm_encoder_slave *encoder_slave)
>> +{
>> + struct drm_encoder *encoder =&encoder_slave->base;
>>
>> + struct tda998x_priv *priv;
>> +
>> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + priv->current_page = 0;
>> + priv->cec = i2c_new_dummy(client->adapter, 0x34);
>> + priv->dpms = DRM_MODE_DPMS_OFF;
>> +
>> + encoder_slave->slave_priv = priv;
>> + encoder_slave->slave_funcs =&tda998x_encoder_funcs;
>> +
>> + /* wake up the device: */
>> + cec_write(encoder, REG_CEC_ENAMODS,
>> + CEC_ENAMODS_EN_RXSENS | CEC_ENAMODS_EN_HDMI);
>> +
>> + tda998x_reset(encoder);
>> +
>> + /* read version: */
>> + priv->rev = reg_read(encoder, REG_VERSION_LSB) |
>> + reg_read(encoder, REG_VERSION_MSB)<< 8;
>> +
>> + /* mask off feature bits: */
>> + priv->rev &= ~0x30; /* not-hdcp and not-scalar bit */
>
>
> If revision register contains features, why not save them for later
> driver improvements?
>
can be added later if the need arises. I prefer to leave out code
that only might be used later.. otherwise it is a good way to
accumulate cruft.
>
>> + switch (priv->rev) {
>> + case TDA9989N2: dev_info(dev->dev, "found TDA9989 n2"); break;
>> + case TDA19989: dev_info(dev->dev, "found TDA19989"); break;
>> + case TDA19989N2: dev_info(dev->dev, "found TDA19989 n2"); break;
>> + case TDA19988: dev_info(dev->dev, "found TDA19988"); break;
>> + default:
>> + DBG("found unsupported device: %04x", priv->rev);
>> + goto fail;
>> + }
>
>
> I think printing revision is sufficient, no user will care about the
> actual device or revision.
>
>
>> + /* after reset, enable DDC: */
>> + reg_write(encoder, REG_DDC_DISABLE, 0x00);
>> +
>> + /* set clock on DDC channel: */
>> + reg_write(encoder, REG_TX3, 39);
>
>
> This should be kept disabled as long as there is no monitor attached
> (HPD!)
>
The sequence is based on NXP's driver.. I'll have to go back and
check, but IIRC there were a few things I had to turn on just to make
HPD work in the first place.
Ofc, if there were actually some decent docs about the part, it would
be a bit easier to know what is actually required and what is not. So
I don't claim everything in it's current form is optimal.
>
>> + /* if necessary, disable multi-master: */
>> + if (priv->rev == TDA19989)
>> + reg_set(encoder, REG_I2C_MASTER, I2C_MASTER_DIS_MM);
>> +
>> + cec_write(encoder, REG_CEC_FRO_IM_CLK_CTRL,
>> + CEC_FRO_IM_CLK_CTRL_GHOST_DIS |
>> CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
>> +
>> + return 0;
>> +
>> +fail:
>> + /* if encoder_init fails, the encoder slave is never registered,
>> + * so cleanup here:
>> + */
>> + if (priv->cec)
>> + i2c_unregister_device(priv->cec);
>> + kfree(priv);
>> + encoder_slave->slave_priv = NULL;
>> + encoder_slave->slave_funcs = NULL;
>> + return -ENXIO;
>> +}
>> +
>> +static struct i2c_device_id tda998x_ids[] = {
>> + { "tda998x", 0 },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, tda998x_ids);
>
>
> Shouldn't the above carry the hdmi core i2c address at least?
>
no, it should come from the user of the encoder slave. Actually the
CEC address should too, but current drm i2c encoder slave code sort of
assumes the device just has a single address
BR,
-R
>
>> +static struct drm_i2c_encoder_driver tda998x_driver = {
>> + .i2c_driver = {
>> + .probe = tda998x_probe,
>> + .remove = tda998x_remove,
>> + .driver = {
>> + .name = "tda998x",
>> + },
>> + .id_table = tda998x_ids,
>> + },
>> + .encoder_init = tda998x_encoder_init,
>> +};
>> +
>> +/* Module initialization */
>> +
>> +static int __init
>> +tda998x_init(void)
>> +{
>> + DBG("");
>> + return drm_i2c_encoder_register(THIS_MODULE,&tda998x_driver);
>> +}
>> +
>> +static void __exit
>> +tda998x_exit(void)
>> +{
>> + DBG("");
>> + drm_i2c_encoder_unregister(&tda998x_driver);
>> +}
>> +
>> +MODULE_AUTHOR("Rob Clark<robdclark@gmail.com");
>> +MODULE_DESCRIPTION("NXP Semiconductors TDA998X HDMI Encoder");
>> +MODULE_LICENSE("GPL");
>
>
> Maybe stick to one version of "TDA998X" or "TDA998x" ?
>
> Regards,
> Sebastian
^ permalink raw reply
* Failure to boot...
From: Santosh Shilimkar @ 2013-01-31 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131141635.GR2637@n2100.arm.linux.org.uk>
On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote:
>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote:
>>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
>>> The pull request from Tony [1] fixed the multi-platform boot issue
>>> for OMAP.
>>>
>>> Now trying to merge your for-next and test.
>>
>> Well, my tip (which is based on Linus' 6abb7c25) also builds and
>> boots fine.
>>
>> Hang on...
>>
>> # CONFIG_ARCH_OMAP2PLUS is not set
>> CONFIG_ARCH_VEXPRESS=y
>>
>> which of course won't boot, and this happens on both oldconfigs because
>> of the change to multiplatform support.
>
> And no, the instructions given last time around to add:
>
> # 13 Jan 2013: Update for OMAP moving to multiplatform
> CONFIG_ARCH_MULTIPLATFORM=y
> CONFIG_ARCH_MULTI_V7=y
>
> don't fix it either, it needs more options defined...
>
Linus' tip + Tony's pull [1] request also makes things work
on OMAP.
Regards,
Santosh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83084.html
^ permalink raw reply
* [GIT PULL] ARM: mvebu cleanup for v3.9 round2
From: Jason Cooper @ 2013-01-31 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301311411.33125.arnd@arndb.de>
On Thu, Jan 31, 2013 at 02:11:32PM +0000, Arnd Bergmann wrote:
> On Thursday 31 January 2013, Jason Cooper wrote:
> > Arnd, Olof,
> >
> > Please don't pull this yet. The nsa310 patch built fine at the tip of
> > my for-next, but didn't do so well when applied to mvebu/cleanup.
> >
> > I'll redo and resubmit the whole series of pr's.
>
>
> FWIW, when I was building all defconfigs for for-next yesterday, I needed
> this patch, but nothing else for mvebu or kirkwood.
Yep, that was it. Thanks! in mvebu/dt we init i2c via DT, and
mvebu/cleanup is before that.
thx,
Jason.
> index 61c4b18..970174a 100644
> --- a/arch/arm/mach-kirkwood/board-nsa310.c
> +++ b/arch/arm/mach-kirkwood/board-nsa310.c
> @@ -11,6 +11,7 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/gpio.h>
> +#include <linux/i2c.h>
> #include <mach/kirkwood.h>
> #include <linux/of.h>
> #include "common.h"
^ permalink raw reply
* Failure to boot...
From: Russell King - ARM Linux @ 2013-01-31 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131141320.GQ2637@n2100.arm.linux.org.uk>
On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote:
> > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
> > The pull request from Tony [1] fixed the multi-platform boot issue
> > for OMAP.
> >
> > Now trying to merge your for-next and test.
>
> Well, my tip (which is based on Linus' 6abb7c25) also builds and
> boots fine.
>
> Hang on...
>
> # CONFIG_ARCH_OMAP2PLUS is not set
> CONFIG_ARCH_VEXPRESS=y
>
> which of course won't boot, and this happens on both oldconfigs because
> of the change to multiplatform support.
And no, the instructions given last time around to add:
# 13 Jan 2013: Update for OMAP moving to multiplatform
CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARCH_MULTI_V7=y
don't fix it either, it needs more options defined...
^ permalink raw reply
* [RFC] ARM i.MX: rtc: change interrupt handling for DryIce
From: Steffen Trumtrar @ 2013-01-31 14:16 UTC (permalink / raw)
To: linux-arm-kernel
di_write_wait uses a very short timeout of 1ms for the wait_queue.
This may lead to write errors to some registers. Write errors to DCAMR and
DSR_CAF where the only one observed, though:
Tue Jan 14 15:32:23 2014 -0.985304 seconds
Tue Jan 14 15:32:24 2014 -0.985236 seconds
Tue Jan 14 15:32:25 2014 -0.986601 seconds
imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588a reg = 0x00000008
Tue Jan 14 15:32:26 2014 -0.983772 seconds
Tue Jan 14 15:32:27 2014 -0.983594 seconds
imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588c reg = 0x00000008
Tue Jan 14 15:32:28 2014 -0.983596 seconds
imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588d reg = 0x00000008
Tue Jan 14 15:32:29 2014 -0.983300 seconds
Tue Jan 14 15:32:30 2014 -0.982809 seconds
Just increasing this timeout leads to a race condition in the interrupt handler.
After a couple minutes of running
while true; do hwclock; done
the interrupt isn't handled by the driver and disabled in the process.
This seems to be because of the waitqueue check and then returning out of the
handler, as there is no other handler that takes over.
Use wait_event_interruptible without a timeout instead and do not leave the
interrupt handler in case of an empty waitqueue, but handle the actual irq case.
As before, nothing is done in that case though.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/rtc/rtc-imxdi.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index 75d307a..b3bb69f 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -66,6 +66,7 @@
#define DIER_WCIE (1 << 8) /* Write Complete Interrupt Enable */
#define DIER_WEIE (1 << 7) /* Write Error Interrupt Enable */
#define DIER_CAIE (1 << 4) /* Clock Alarm Interrupt Enable */
+#define DIER_SVIE (1 << 0) /* Security-violation interrupt */
/**
* struct imxdi_dev - private imxdi rtc data
@@ -160,7 +161,7 @@ static int di_write_wait(struct imxdi_dev *imxdi, u32 val, int reg)
mutex_lock(&imxdi->write_mutex);
/* enable the write-complete interrupt */
- di_int_enable(imxdi, DIER_WCIE);
+ di_int_enable(imxdi, DIER_WCIE | DIER_WEIE);
imxdi->dsr = 0;
@@ -168,15 +169,18 @@ static int di_write_wait(struct imxdi_dev *imxdi, u32 val, int reg)
__raw_writel(val, imxdi->ioaddr + reg);
/* wait for the write to finish */
- ret = wait_event_interruptible_timeout(imxdi->write_wait,
- imxdi->dsr & (DSR_WCF | DSR_WEF), msecs_to_jiffies(1));
- if (ret < 0) {
+ ret = wait_event_interruptible(imxdi->write_wait, imxdi->dsr &
+ (DSR_WCF | DSR_WEF));
+
+ if (ret <= 0) {
rc = ret;
goto out;
- } else if (ret == 0) {
+ } else if (ret > 0) {
dev_warn(&imxdi->pdev->dev,
"Write-wait timeout "
"val = 0x%08x reg = 0x%08x\n", val, reg);
+ rc = -ERESTARTSYS;
+ goto out;
}
/* check for write error */
@@ -313,18 +317,12 @@ static irqreturn_t dryice_norm_irq(int irq, void *dev_id)
dier = __raw_readl(imxdi->ioaddr + DIER);
/* handle write complete and write error cases */
- if ((dier & DIER_WCIE)) {
- /*If the write wait queue is empty then there is no pending
- operations. It means the interrupt is for DryIce -Security.
- IRQ must be returned as none.*/
- if (list_empty_careful(&imxdi->write_wait.task_list))
- return rc;
-
+ if ((dier & (DIER_WCIE | DIER_WEIE))) {
/* DSR_WCF clears itself on DSR read */
dsr = __raw_readl(imxdi->ioaddr + DSR);
if ((dsr & (DSR_WCF | DSR_WEF))) {
/* mask the interrupt */
- di_int_disable(imxdi, DIER_WCIE);
+ di_int_disable(imxdi, DIER_WCIE | DIER_WEIE);
/* save the dsr value for the wait queue */
imxdi->dsr |= dsr;
@@ -347,6 +345,14 @@ static irqreturn_t dryice_norm_irq(int irq, void *dev_id)
rc = IRQ_HANDLED;
}
}
+
+ /* handle security violations */
+ if (dier & DIER_SVIE) {
+ /* FIXME: with the current implementation, SVIE is never set */
+ /* failure states would be handled here */
+ return IRQ_HANDLED;
+ }
+
return rc;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
From: Florian Fainelli @ 2013-01-31 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359641286-18182-2-git-send-email-gregory.clement@free-electrons.com>
On 01/31/2013 03:08 PM, Gregory CLEMENT wrote:
> This is the new Armada XP evaluation board from Marvell. It comes with
> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
> Gigabit links.
>
> Support for USB (Host and device), SDIO, PCIe will be added as drivers
> when they become available for Armada XP in mainline.
>
> Tested-by: Simon Guinot <simon.guinot@sequanux.org>
> Tested-by: Florian Fainelli <florian@openwrt.org>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 102 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5ebb44f..51aab4b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> armada-xp-db.dtb \
> + armada-xp-gp.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> imx53-ard.dtb \
> diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
> new file mode 100644
> index 0000000..50e44e7
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Device Tree file for Marvell Armada XP development board
> + * (DB-MV784MP-GP)
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * Lior Amsalem <alior@marvell.com>
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-xp-mv78460.dtsi"
> +
> +/ {
> + model = "Marvell Armada XP Development Board: DB-MV784MP-GP";
I noticed this just now, please do not use ":" for consistency with the
other DTS files for Armada XP/370.
--
Florian
^ permalink raw reply
* [PATCH 1/2] USB mxs-phy: Register phy with framework
From: kishon @ 2013-01-31 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359631937-26646-2-git-send-email-s.hauer@pengutronix.de>
On Thursday 31 January 2013 05:02 PM, Sascha Hauer wrote:
> We now have usb_add_phy_dev(), so use it to register with the framework
> to be able to find the phy from the USB driver.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/otg/mxs-phy.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
> index 5158332..5b39885 100644
> --- a/drivers/usb/otg/mxs-phy.c
> +++ b/drivers/usb/otg/mxs-phy.c
> @@ -127,6 +127,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
> void __iomem *base;
> struct clk *clk;
> struct mxs_phy *mxs_phy;
> + int ret;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -166,11 +167,19 @@ static int mxs_phy_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, &mxs_phy->phy);
>
> + ret = usb_add_phy_dev(&mxs_phy->phy);
> + if (ret)
> + return ret;
> +
> return 0;
> }
>
> static int mxs_phy_remove(struct platform_device *pdev)
> {
> + struct mxs_phy *mxs_phy = platform_get_drvdata(pdev);
> +
> + usb_remove_phy(&mxs_phy->phy);
> +
> platform_set_drvdata(pdev, NULL);
>
> return 0;
>
^ permalink raw reply
* [PATCH 2/2] USB chipidea i.MX: use devm_usb_get_phy_by_phandle to get phy
From: kishon @ 2013-01-31 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359631937-26646-3-git-send-email-s.hauer@pengutronix.de>
Hi,
On Thursday 31 January 2013 05:02 PM, Sascha Hauer wrote:
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Some maintainers don't accept patches without a commit message.
Apart from that you can add,
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Thanks
Kishon
^ permalink raw reply
* Failure to boot...
From: Russell King - ARM Linux @ 2013-01-31 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A78E1.8010308@ti.com>
On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote:
> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
> The pull request from Tony [1] fixed the multi-platform boot issue
> for OMAP.
>
> Now trying to merge your for-next and test.
Well, my tip (which is based on Linus' 6abb7c25) also builds and
boots fine.
Hang on...
# CONFIG_ARCH_OMAP2PLUS is not set
CONFIG_ARCH_VEXPRESS=y
which of course won't boot, and this happens on both oldconfigs because
of the change to multiplatform support.
^ permalink raw reply
* [GIT PULL] ARM: mvebu cleanup for v3.9 round2
From: Arnd Bergmann @ 2013-01-31 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131125116.GC7717@titan.lakedaemon.net>
On Thursday 31 January 2013, Jason Cooper wrote:
> Arnd, Olof,
>
> Please don't pull this yet. The nsa310 patch built fine at the tip of
> my for-next, but didn't do so well when applied to mvebu/cleanup.
>
> I'll redo and resubmit the whole series of pr's.
FWIW, when I was building all defconfigs for for-next yesterday, I needed
this patch, but nothing else for mvebu or kirkwood.
Arnd
index 61c4b18..970174a 100644
--- a/arch/arm/mach-kirkwood/board-nsa310.c
+++ b/arch/arm/mach-kirkwood/board-nsa310.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/gpio.h>
+#include <linux/i2c.h>
#include <mach/kirkwood.h>
#include <linux/of.h>
#include "common.h"
^ permalink raw reply related
* Failure to boot...
From: Santosh Shilimkar @ 2013-01-31 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A78E1.8010308@ti.com>
On Thursday 31 January 2013 07:30 PM, Santosh Shilimkar wrote:
> On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote:
>> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote:
>>> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote:
>>>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux
>>>> wrote:
>>>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote:
>>>>>> Better yet (IMHO): just enable the zboot command in U-Boot to let you
>>>>>> boot a zImage binary directly.
>>>>>
>>>>> I wish it were that easy but it isn't. I've no idea where to get a
>>>>> version of uboot for my boards which supports that; TI have always
>>>>> supplied updates to uboot for me, and with the current state of TI
>>>>> being afaict in chaos.
>>>>>
>>>>> TI have always supplied a replacement X-Loader with each uboot update.
>>>>> I've no idea what X-Loader is or why both get updated together, but...
>>>>>
>>>>> Moreover, I doubt that the 3430LDP, of which there are multiple
>>>>> versions,
>>>>> will ever see a uboot update. It already suffers from a lack of
>>>>> correct
>>>>> kernel support due to random wiring changes between these versions
>>>>> (the
>>>>> keypad doesn't work correctly) and I've yet to indentify which version
>>>>> it is despite downloading the circuits. So trying to locate the right
>>>>> uboot will be impossible there.
>>>>>
>>>>> So, I'm _stuck_ with uImages for these platforms.
>>>>
>>>> Right, so I'm now passing LOADADDR= which allows this to work - and the
>>>> latest OMAP4430SDP boot result shows almost the same sad broken story.
>>>>
>>> I just tried latest mainline (commit: 04c2eee5) and default config
>>> just boots fine.
>>
>> Please read the notes at the bottom of the page, specifically:
>> * Build tree is currently created on an ad-hoc basis from Linus'
>> tip, rmk's
>> development tip and arm-soc for-next branches.
>>
>> This system does *not* build and boot vanilla mainline kernels. It is
>> (as the above says):
>>
>> - Linus' tip
>> - My for-next plus a few other bits
>> - arm-soc for-next
>>
>> all merged together.
>>
> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
> The pull request from Tony [1] fixed the multi-platform boot issue
> for OMAP.
>
> Now trying to merge your for-next and test.
>
This is fine as well. I think the issue is the way uImage is created.
'make LOADADDRESS=XXXX uImage' actually doesn't work. Am using below
method to create an uImage.
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n
"Linux" -d zImage uImage
Will you be able to try this out please ?
Regards,
Santosh
^ permalink raw reply
* IPC SHM alignment on ARMv7
From: Alexander Kartashov @ 2013-01-31 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131134747.GY23505@n2100.arm.linux.org.uk>
On 01/31/2013 05:47 PM, Russell King - ARM Linux wrote:
> Err, no. Try again - this is the mainline kernel:
I'm sorry, I forgot to note that it's very old code,
it's from the tglx/history.git that you may find here:
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=4197692eef113eeb8e3e413cc70993a5e667e5b8
The piece of code I'm telling about hasn't changed
very much since then, it looks in the following way
in that commit:
25 unsigned long
26 arch_get_unmapped_area(struct file *filp, unsigned long addr,
27 unsigned long len, unsigned long pgoff, unsigned long flags)
28 {
29 struct mm_struct *mm = current->mm;
30 struct vm_area_struct *vma;
31 unsigned long start_addr;
32 #ifdef CONFIG_CPU_V6
33 unsigned int cache_type;
34 int do_align = 0, aliasing = 0;
35
36 /*
37 * We only need to do colour alignment if either the I or D
38 * caches alias. This is indicated by bits 9 and 21 of the
39 * cache type register.
40 */
41 cache_type = read_cpuid(CPUID_CACHETYPE);
42 if (cache_type != read_cpuid(CPUID_ID)) {
43 aliasing = (cache_type | cache_type >> 12) & (1 << 9);
44 if (aliasing)
45 do_align = filp || flags & MAP_SHARED;
46 }
The last commit that touches the file is
394ef6403abc36900d9303395a49a72d32666f2a
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=394ef6403abc36900d9303395a49a72d32666f2a)
and currently the lines look in the following way:
[arch/arm/mm/mmap.c]
[...]
54 unsigned long
55 arch_get_unmapped_area(struct file *filp, unsigned long addr,
56 unsigned long len, unsigned long pgoff, unsigned long
flags)
57 {
58 struct mm_struct *mm = current->mm;
59 struct vm_area_struct *vma;
60 int do_align = 0;
61 int aliasing = cache_is_vipt_aliasing();
62 struct vm_unmapped_area_info info;
63
64 /*
65 * We only need to do colour alignment if either the I or D
66 * caches alias.
67 */
68 if (aliasing)
69 do_align = filp || (flags & MAP_SHARED);
Particularly, the lines
68 if (aliasing)
69 do_align = filp || (flags & MAP_SHARED);
hasn't changed since then.
I intentionally provided a reference to a historical branch
to point out that this code hasn't changed.
--
Sincerely yours,
Alexander Kartashov
Intern
Core team
www.parallels.com
Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com
^ permalink raw reply
* [PATCH v2] arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
From: Gregory CLEMENT @ 2013-01-31 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359641286-18182-1-git-send-email-gregory.clement@free-electrons.com>
This is the new Armada XP evaluation board from Marvell. It comes with
a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
Gigabit links.
Support for USB (Host and device), SDIO, PCIe will be added as drivers
when they become available for Armada XP in mainline.
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..51aab4b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -78,6 +78,7 @@ dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-xp-db.dtb \
+ armada-xp-gp.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
new file mode 100644
index 0000000..50e44e7
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -0,0 +1,101 @@
+/*
+ * Device Tree file for Marvell Armada XP development board
+ * (DB-MV784MP-GP)
+ *
+ * Copyright (C) 2013 Marvell
+ *
+ * Lior Amsalem <alior@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-xp-mv78460.dtsi"
+
+/ {
+ model = "Marvell Armada XP Development Board: DB-MV784MP-GP";
+ compatible = "marvell,axp-db", "marvell,armadaxp-mv78460", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+
+ /*
+ * 4 GB of plug-in RAM modules by default but only 3GB
+ * are visible, the amount of memory available can be
+ * changed by he bootloader according the size of the
+ * module actually pluged
+ */
+ reg = <0x00000000 0xC0000000>;
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012200 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012300 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+
+ sata at d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <16>;
+ };
+
+ phy1: ethernet-phy at 1 {
+ reg = <17>;
+ };
+
+ phy2: ethernet-phy at 2 {
+ reg = <18>;
+ };
+
+ phy3: ethernet-phy at 3 {
+ reg = <19>;
+ };
+ };
+
+ ethernet at d0070000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0074000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0030000 {
+ status = "okay";
+ phy = <&phy2>;
+ phy-mode = "rgmii-id";
+ };
+ ethernet at d0034000 {
+ status = "okay";
+ phy = <&phy3>;
+ phy-mode = "rgmii-id";
+ };
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] Adding support for the new Armada XP development board from Marvell
From: Gregory CLEMENT @ 2013-01-31 14:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is the second version of a single patch to add the dts support
for new Armada XP development board from Marvell called
DB-MV784MP-GP.
Simon Guinot and Florian Fainelli tested it successfully the issue I
get with Ethernet so it should be hardware related.
Since the first version, beside adding the tested-by flag, I also
fixed the name for the board. The name of this board start by DB for
development board so let's use it!
The other change was about the memory node: I had some comments to
emphasize that the amount of memory may change.
Thanks,
Gregory CLEMENT (1):
arm: mvebu: support for the new Armada XP development
board(DB-MV784MP-GP)
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-xp-gp.dts | 101 ++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: Mugunthan V N @ 2013-01-31 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C92BBC79-6B63-482D-8431-4812823920B9@antoniou-consulting.com>
Pantelis
On 1/31/2013 4:52 PM, Pantelis Antoniou wrote:
> Hi
> On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:
>
>> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>>>
>>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>>> used for rx and tx respectively.
>>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
>> Existing driver implementation is also complies with TRM. What Pantelis added
>> additionally are non-napi implementation, handled cpdma processed tx and rx
>> processing separately and renamed wr_reg as per TRM naming convention.. Also he
>> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
>> is required only when using multichannel for data transfer. Current implementation
>> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
>> and reading stat doesn't gets any effect in interrupt acknowledgment.
>>
>> Since both tx and rx are processed in same napi api, so i have added interrupt
>> acknowledgment to the same existing api.
>>
>
> First of all, this method of not needing to read the stat registers besides when
> using multichannel for data transfers is never described anywhere in any manual,
> or in the driver sources.
>
> Secondly, I find the method of ack-ing all interrupt sources problematic.
> Consider the following sequence
>
> Rx-interrupt ---> | |
> | IRQ handler |
> | schedules NAPI |
> | disables interrupts --> | cpsw_poll()
> | | handle Rx
> Tx-interrupt ---> |-------------------------|-------------
> | | ack Rx & Tx IRQ
> | | enable interrupts
>
> When will the Tx interrupt get handled? Is it guaranteed that the DMA
> logic will assert the Tx interrupt when the interrupts are enabled, even
> though the interrupt was previously acked? It is not clear in the TRM.
Need to check with the IP owner with this corner case. Simulating this
will be difficult
because even if driver misses the interrupt in next rx/tx interrupt it
will be serviced.
>
> Another problem that I see is that the other interrupts (MISC) are not supposed
> to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path
> as far as I know.
I agree that napi should not be used for MISC interrupts.
Regards
Mugunthan V N
>
>
>> Regards
>> Mugunthan V N
> Regards
>
> -- Pantelis
>
^ permalink raw reply
* Failure to boot...
From: Santosh Shilimkar @ 2013-01-31 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131130437.GP2637@n2100.arm.linux.org.uk>
On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote:
>> On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote:
>>> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote:
>>>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote:
>>>>> Better yet (IMHO): just enable the zboot command in U-Boot to let you
>>>>> boot a zImage binary directly.
>>>>
>>>> I wish it were that easy but it isn't. I've no idea where to get a
>>>> version of uboot for my boards which supports that; TI have always
>>>> supplied updates to uboot for me, and with the current state of TI
>>>> being afaict in chaos.
>>>>
>>>> TI have always supplied a replacement X-Loader with each uboot update.
>>>> I've no idea what X-Loader is or why both get updated together, but...
>>>>
>>>> Moreover, I doubt that the 3430LDP, of which there are multiple versions,
>>>> will ever see a uboot update. It already suffers from a lack of correct
>>>> kernel support due to random wiring changes between these versions (the
>>>> keypad doesn't work correctly) and I've yet to indentify which version
>>>> it is despite downloading the circuits. So trying to locate the right
>>>> uboot will be impossible there.
>>>>
>>>> So, I'm _stuck_ with uImages for these platforms.
>>>
>>> Right, so I'm now passing LOADADDR= which allows this to work - and the
>>> latest OMAP4430SDP boot result shows almost the same sad broken story.
>>>
>> I just tried latest mainline (commit: 04c2eee5) and default config
>> just boots fine.
>
> Please read the notes at the bottom of the page, specifically:
> * Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's
> development tip and arm-soc for-next branches.
>
> This system does *not* build and boot vanilla mainline kernels. It is
> (as the above says):
>
> - Linus' tip
> - My for-next plus a few other bits
> - arm-soc for-next
>
> all merged together.
>
Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well.
The pull request from Tony [1] fixed the multi-platform boot issue
for OMAP.
Now trying to merge your for-next and test.
Regards,
Santosh
[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg83084.html
^ permalink raw reply
* [REGRESSION+BISECT] imx6: 3.8+: sata failure with 24d340ac "ARM i.MX6: Fix ethernet PLL clocks"
From: Paolo Pisati @ 2013-01-31 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131133054.GD2735@S2101-09.ap.freescale.net>
On Thu, Jan 31, 2013 at 09:30:56PM +0800, Shawn Guo wrote:
>
> Can you please try to see if the following change bring that SATA back
> to work?
>
> Shawn
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index c0c4e72..8f756af 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -436,6 +436,9 @@ int __init mx6q_clocks_init(void)
> for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> clk_prepare_enable(clk[clks_init_on[i]]);
>
> + if (IS_ENABLED(CONFIG_SATA_AHCI_PLATFORM))
> + clk_prepare_enable(clk[sata_ref_100m]);
> +
> /* Set initial power mode */
> imx6q_set_lpm(WAIT_CLOCKED);
yes, it fixes SATA.
Tested-by: <p.pisati@gmail.com>
--
bye,
p.
^ permalink raw reply
* IPC SHM alignment on ARMv7
From: Russell King - ARM Linux @ 2013-01-31 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A7262.4060307@parallels.com>
On Thu, Jan 31, 2013 at 05:32:18PM +0400, Alexander Kartashov wrote:
> Dear colleagues,
>
> It tuned out that IPC SHM works in a bit strange way on ARMv7:
> the syscall sys_shmat() requires the argument shmaddr to be SHMLBA-aligned:
>
> [ipc/shm.c]
> [...]
> 979 else if ((addr = (ulong)shmaddr)) {
> 980 if (addr & (shmlba - 1)) {
> 981 if (shmflg & SHM_RND)
> 982 addr &= ~(shmlba - 1); /* round down */
> 983 else
> 984 #ifndef __ARCH_FORCE_SHMLBA
> 985 if (addr & ~PAGE_MASK)
> 986 #endif
> 987 goto out;
> 988 }
> 989 flags = MAP_SHARED | MAP_FIXED;
> [...]
>
> since macro __ARCH_FORCE_SHMLBA is unconditionally defined for the ARM
> architecture. However it uses the function arch_get_unmapped_area()
> introduced in the commit 4197692eef113eeb8e3e413cc70993a5e667e5b8
> in the mainstream kernel to allocate memory for a SHM segment.
Err, no. Try again - this is the mainline kernel:
$ git log 4197692eef113eeb8e3e413cc70993a5e667e5b8
fatal: bad object 4197692eef113eeb8e3e413cc70993a5e667e5b8
Would this be in linux-next? Maybe it's a patch which someone else has
applied which isn't in Linus' kernel?
With just the commit ID and no description (we're *constantly* harping
on about that on this list, especially in commit comments: ALWAYS provide
the description as well) it's much harder to do anything with your report.
Please try again.
Thanks.
^ permalink raw reply
* IPC SHM alignment on ARMv7
From: Alexander Kartashov @ 2013-01-31 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Dear colleagues,
It tuned out that IPC SHM works in a bit strange way on ARMv7:
the syscall sys_shmat() requires the argument shmaddr to be SHMLBA-aligned:
[ipc/shm.c]
[...]
979 else if ((addr = (ulong)shmaddr)) {
980 if (addr & (shmlba - 1)) {
981 if (shmflg & SHM_RND)
982 addr &= ~(shmlba - 1); /* round down */
983 else
984 #ifndef __ARCH_FORCE_SHMLBA
985 if (addr & ~PAGE_MASK)
986 #endif
987 goto out;
988 }
989 flags = MAP_SHARED | MAP_FIXED;
[...]
since macro __ARCH_FORCE_SHMLBA is unconditionally defined for the ARM
architecture. However it uses the function arch_get_unmapped_area()
introduced in the commit 4197692eef113eeb8e3e413cc70993a5e667e5b8
in the mainstream kernel to allocate memory for a SHM segment.
However the function allocates SHMLBA-aligned memory only if
I or D caches alias as the following comment reads:
[arch/arm/mm/mmap.c]
[...]
54 unsigned long
55 arch_get_unmapped_area(struct file *filp, unsigned long addr,
56 unsigned long len, unsigned long pgoff, unsigned long flags)
57 {
58 struct mm_struct *mm = current->mm;
59 struct vm_area_struct *vma;
60 int do_align = 0;
61 int aliasing = cache_is_vipt_aliasing();
62 struct vm_unmapped_area_info info;
63
64 /*
65 * We only need to do colour alignment if either the I or D
66 * caches alias.
67 */
68 if (aliasing)
69 do_align = filp || (flags & MAP_SHARED);
[...]
So a SHM segment isn't always SHMLBA-aligned.
This results in the following inconvenience: the address returned
by the syscall sys_shmat() may not be passed as its argument
later. This is however crucial for implementing IPC SHM
checkpoint/restore for the ARM architecture I'm currently working on.
As far as I can see from the commit c0e9587841a0fd79bbf8296034faefb9afe72fb4
in the mainstream kernel:
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 1939c90..5b121d8 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -67,6 +67,8 @@ unsigned int processor_id;
EXPORT_SYMBOL(processor_id);
unsigned int __machine_arch_type;
EXPORT_SYMBOL(__machine_arch_type);
+unsigned int cacheid;
+EXPORT_SYMBOL(cacheid);
unsigned int __atags_pointer __initdata;
@@ -229,6 +231,25 @@ int cpu_architecture(void)
return cpu_arch;
}
+static void __init cacheid_init(void)
+{
+ unsigned int cachetype = read_cpuid_cachetype();
+ unsigned int arch = cpu_architecture();
+
+ if (arch >= CPU_ARCH_ARMv7) {
+ cacheid = CACHEID_VIPT_NONALIASING;
+ if ((cachetype & (3 << 14)) == 1 << 14)
+ cacheid |= CACHEID_ASID_TAGGED;
+ } else if (arch >= CPU_ARCH_ARMv6) {
+ if (cachetype & (1 << 23))
+ cacheid = CACHEID_VIPT_ALIASING;
+ else
+ cacheid = CACHEID_VIPT_NONALIASING;
+ } else {
+ cacheid = CACHEID_VIVT;
+ }
+}
+
/*
* These functions re-use the assembly code in head.S, which
the flag CACHEID_VIPT_ALIASING is never set for ARMv7
so it's impossible to guarantee that a IPC SHM segment
is always SHMLBA-aligned.
Is it true that the desired SHM alignment is impossible
to be achieved on the ARMv7 architecture?
--
Sincerely yours,
Alexander Kartashov
Intern
Core team
www.parallels.com
Skype: aleksandr.kartashov
Email: alekskartashov@parallels.com
^ permalink raw reply related
* [REGRESSION+BISECT] imx6: 3.8+: sata failure with 24d340ac "ARM i.MX6: Fix ethernet PLL clocks"
From: Shawn Guo @ 2013-01-31 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131113627.GA5452@luxor.wired.org>
On Thu, Jan 31, 2013 at 12:36:27PM +0100, Paolo Pisati wrote:
> Hi,
>
> sata doesn't work anymore in 3.8rcX (while it was ok in 3.7 + 1 patch[1]) and i've bisected
> it down to:
>
Technically, it's not a regression since vanilla 3.7 kernel does not
have SATA work out of box. So we do not have to maintain the function
when changing clock code.
Can you please try to see if the following change bring that SATA back
to work?
Shawn
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index c0c4e72..8f756af 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -436,6 +436,9 @@ int __init mx6q_clocks_init(void)
for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
clk_prepare_enable(clk[clks_init_on[i]]);
+ if (IS_ENABLED(CONFIG_SATA_AHCI_PLATFORM))
+ clk_prepare_enable(clk[sata_ref_100m]);
+
/* Set initial power mode */
imx6q_set_lpm(WAIT_CLOCKED);
^ permalink raw reply related
* [PATCH v4] cpufreq: add imx6q-cpufreq driver
From: Rafael J. Wysocki @ 2013-01-31 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131034148.GB17607@S2101-09.ap.freescale.net>
On Thursday, January 31, 2013 11:41:50 AM Shawn Guo wrote:
> On Tue, Jan 29, 2013 at 10:56:54AM +0800, Shawn Guo wrote:
> > On Sat, Jan 26, 2013 at 11:31:43PM +0800, 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.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> > > Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > Rafael,
> >
> > I think the patch needs to go via cpufreq tree, as it has dependency
> > on Nishanth's "PM / OPP : export symbol consolidation" series.
>
> Rafael,
>
> Please hold off this one. I plan to send v5 to handle regulator
> latency through regulator API, since my colleague is pushing patches
> to take care of voltage ramping time in anatop regulator driver.
OK
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Question: Way to add missing pads & pins into pinctrl driver
From: Alexander Shiyan @ 2013-01-31 13:15 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
I have found some missing pads and pins definitions in the pinctrl-imx51 driver.
Appending in sort order will break current devicetree configurations, so I want
to know better way for add these definitions. Of course I can just append
at the end, but this will break sort order. How to do it better?
Thanks.
---
^ 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