* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Peter Chen @ 2013-01-31 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130140015.GZ1906@pengutronix.de>
On Wed, Jan 30, 2013 at 03:00:15PM +0100, Sascha Hauer wrote:
> On Wed, Jan 30, 2013 at 10:06:28AM +0800, Peter Chen wrote:
> > On Tue, Jan 29, 2013 at 01:55:04PM +0200, Alexander Shishkin wrote:
> > > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > >
> > > > From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > >
> > > > This adds two little devicetree helper functions for determining the
> > > > dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> > > > the devicetree.
> > > >
> > > > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> > > > ---
> > > >
> > > > The properties and their values have been taken from the fsl-mph-dr driver.
> > > > This binding is also documented (though currently not used) for the tegra
> > > > ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> > > > This is a first attempt to parse these bindings at a common place so that
> > > > others can make use of it.
> > > >
> > > > Basically I want to know whether this binding is recommended for new drivers
> > > > since normally the devicetree uses '-' instead of '_', and maybe there are
> > > > other problems with it.
> > > >
> > > > I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> > > > driver also really handles a chipidea core.
> > >
> > > As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
> > > probably confirm.
> >
> > The fsl-mph-dr can't be used for chipdiea as it handles three platform
> > drivers for three roles (peripheral , host, otg). But chipidea only has
> > two platform drivers, one is the chipidea core, the other is related
> > controller wrapper.
>
> What do you mean by 'three platform drivers'? That's only how the driver
> is built, no? I was talking about the hardware the fsl-mph-dr driver
> handles which definitely smells like chipidea.
It creates host/device/otg platform device according to dr_mode from
the device tree.
>
> Sascha
>
> --
> 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 |
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Kim Phillips @ 2013-01-31 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359541333.3529.186.camel@shinybook.infradead.org>
On Wed, 30 Jan 2013 10:22:15 +0000
"Woodhouse, David" <david.woodhouse@intel.com> wrote:
> On Tue, 2013-01-29 at 19:10 +0100, Borislav Petkov wrote:
> > So, IMHO it sounds to me like we want to explicitly state for each arch
> > separately that it is ok to use the __builtin_bswapXX things. This also
> > takes care of the case where the compiler is doing something suboptimal
> > by excluding the affected versions.
>
> Well, if it really does end up being different for every architecture,
> then that means I probably made the wrong decision when I chose to make
> it "generic", and override the __arch_swabXX() macros. I could have just
> pushed all the architectures to use the builtins in their __arch_swabXX
> macros instead, as appropriate.
>
> Let's see how many special cases we actually end up with, and perhaps
> we'll end up switching that round. For now, let's just make ARM set
> __HAVE_BUILTIN_BSWAPxx__ for the appropriate sizes in <asm/swab.h>,
> according to whatever criteria it needs.
thanks - I've attempted to do this - see v2 patch below.
> It's not entirely clear how much of a win it is on ARM anyway; we don't
> have load-and-swap or store-and-swap instructions so there are only a
> few added opportunities for optimisation that we get by letting the
> compiler see what's going on.
I've added some text size figures to the patch description.
They are indeed very small, but it should help drivers for
big-endian devices.
>From 31df859be202f00d017b707649e7709281994d15 Mon Sep 17 00:00:00 2001
From: Kim Phillips <kim.phillips@freescale.com>
Date: Mon, 28 Jan 2013 19:30:33 -0600
Subject: [PATCH] arm: use built-in byte swap function
Enable the compiler intrinsic for byte swapping on arch ARM. This
allows the compiler to detect and be able to optimize out byte
swappings, e.g. in big endian to big endian moves.
AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
and for the 16-bit version in 4.8.
This has a tiny benefit on vmlinux text size:
multi_v7_defconfig:
text data bss dec hex filename
3135208 188396 203344 3526948 35d124 vmlinux
multi_v7_defconfig with builtin_bswap:
3135112 188396 203344 3526852 35d0c4 vmlinux
exynos_defconfig:
text data bss dec hex filename
4286605 360564 223172 4870341 4a50c5 vmlinux
exynos_defconfig with builtin_bswap:
text data bss dec hex filename
4286405 360564 223172 4870141 4a4ffd vmlinux
The savings come mostly from device-tree related code, and some
from drivers.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
based on linux-next-20130128. Depends on commit "compiler-gcc{3,4}.h:
Use GCC_VERSION macro" by Daniel Santos <daniel.santos@pobox.com>,
currently in the akpm branch.
v2:
- at91 and lpd270 builds fixed by limiting to ARMv6 and above
(i.e., ARM cores that have support for the 'rev' instruction).
Otherwise, the compiler emits calls to libgcc's __bswapsi2 on
these ARMv4/v5 builds (and arch ARM doesn't link with libgcc).
All ARM defconfigs now have the same build status as they did
without this patch (some are broken on linux-next).
- move ARM check from generic compiler.h to arch ARM's swab.h.
- pretty sure it should be limited to __KERNEL__ builds
- add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
- if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
- not too sure about this having to be a new CONFIG_, but it's hard
to find a place for it given linux/compiler.h doesn't include any
arch-specific files.
- move new selects to end of CONFIG_ARM's Kconfig select list,
as is done in David Woodhouse's original patchseries for ppc/x86.
arch/Kconfig | 10 ++++++++++
arch/arm/Kconfig | 2 ++
arch/arm/include/uapi/asm/swab.h | 10 ++++++++++
include/linux/compiler-gcc4.h | 3 ++-
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 40e2b12..c8798b9 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -141,6 +141,16 @@ config ARCH_USE_BUILTIN_BSWAP
instructions should set this. And it shouldn't hurt to set it
on architectures that don't have such instructions.
+config ARCH_DEFINES_BUILTIN_BSWAP
+ depends on ARCH_USE_BUILTIN_BSWAP
+ bool
+ help
+ ARCH selects this when it wants to control HAVE_BUILTIN_BSWAPxx
+ definitions over those in the generic compiler headers. It
+ can be dependent on a combination of byte swapping instruction
+ availability, the instruction set version, and the state
+ of support in different compiler versions.
+
config HAVE_SYSCALL_WRAPPERS
bool
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73027aa..b5868c2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -57,6 +57,8 @@ config ARM
select CLONE_BACKWARDS
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+ select ARCH_USE_BUILTIN_BSWAP
+ select ARCH_DEFINES_BUILTIN_BSWAP
help
The ARM series is a line of low-power-consumption RISC chip designs
licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/include/uapi/asm/swab.h b/arch/arm/include/uapi/asm/swab.h
index 6fcb32a..5d86ed0 100644
--- a/arch/arm/include/uapi/asm/swab.h
+++ b/arch/arm/include/uapi/asm/swab.h
@@ -50,4 +50,14 @@ static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
#endif
+#if defined(__KERNEL__) && __LINUX_ARM_ARCH__ >= 6
+#if GCC_VERSION >= 40600
+#define __HAVE_BUILTIN_BSWAP32__
+#define __HAVE_BUILTIN_BSWAP64__
+#endif
+#if GCC_VERSION >= 40800
+#define __HAVE_BUILTIN_BSWAP16__
+#endif
+#endif
+
#endif /* _UAPI__ASM_ARM_SWAB_H */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 68b162d..fce39cb 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -66,7 +66,8 @@
#endif
-#ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
+#if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && \
+ !defined(CONFIG_ARCH_DEFINES_BUILTIN_BSWAP)
#if GCC_VERSION >= 40400
#define __HAVE_BUILTIN_BSWAP32__
#define __HAVE_BUILTIN_BSWAP64__
--
1.7.9.7
^ permalink raw reply related
* [PATCH 1/6] USB: move bulk of otg/otg.c to phy/phy.c
From: Peter Chen @ 2013-01-31 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359559782-14552-2-git-send-email-s.hauer@pengutronix.de>
On Wed, Jan 30, 2013 at 04:29:37PM +0100, Sascha Hauer wrote:
> Most of otg/otg.c is not otg specific, but phy specific, so move it
> to the phy directory.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
Good catch, you can add Felipe Balbi <balbi@ti.com> to list, he is
the maintainer of USB PHY.
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 2/4] drm/i2c: nxp-tda998x (v3)
From: Sebastian Hesselbarth @ 2013-01-31 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359480184-9168-3-git-send-email-robdclark@gmail.com>
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.
> [...]
> 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.
> [...]
> +
> +/* 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?
> [...]
> +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)?
> [...]
> +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?
> +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?
> [...]
> +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?
> +/* 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?
> +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?
> + 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!)
> + /* 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?
> +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
* [PATCH 2/6] usb: add devicetree helpers for determining dr_mode and phy_type
From: Peter Chen @ 2013-01-31 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359559782-14552-3-git-send-email-s.hauer@pengutronix.de>
On Wed, Jan 30, 2013 at 04:29:38PM +0100, Sascha Hauer wrote:
> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>
> This adds two little devicetree helper functions for determining the
> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> the devicetree.
>
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/usb-common.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/of.h | 27 ++++++++++++++++++
> include/linux/usb/otg.h | 7 +++++
> include/linux/usb/phy.h | 9 ++++++
> 4 files changed, 112 insertions(+)
> create mode 100644 include/linux/usb/of.h
>
> diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
> index d29503e..1c0292c 100644
> --- a/drivers/usb/usb-common.c
> +++ b/drivers/usb/usb-common.c
> @@ -14,6 +14,9 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/usb/ch9.h>
> +#include <linux/of.h>
> +#include <linux/usb/of.h>
> +#include <linux/usb/otg.h>
>
> const char *usb_speed_string(enum usb_device_speed speed)
> {
> @@ -32,4 +35,70 @@ const char *usb_speed_string(enum usb_device_speed speed)
> }
> EXPORT_SYMBOL_GPL(usb_speed_string);
>
> +#ifdef CONFIG_OF
> +static const char *usb_dr_modes[] = {
> + [USB_DR_MODE_UNKNOWN] = "",
> + [USB_DR_MODE_HOST] = "host",
> + [USB_DR_MODE_PERIPHERAL] = "peripheral",
> + [USB_DR_MODE_OTG] = "otg",
> +};
> +
> +/**
> + * of_usb_get_dr_mode - Get dual role mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'dr_mode',
> + * and returns the correspondig enum usb_phy_dr_mode
> + */
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
The word "phy" at usb_phy_dr_mode may cause misunderstand, just usb_dr_mode
is ok
> +{
> + const char *dr_mode;
> + int err, i;
> +
> + err = of_property_read_string(np, "dr_mode", &dr_mode);
> + if (err < 0)
> + return USB_DR_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> + if (!strcasecmp(dr_mode, usb_dr_modes[i]))
> + return i;
Just curious, why not using strcmp?
> +
> + return USB_DR_MODE_UNKNOWN;
> +}
> +
> +#ifdef CONFIG_OF
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np);
> +#else
> +static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> +{
> + return USBPHY_INTERFACE_MODE_NA;
> +}
> +
> +static inline enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
> +{
> + return USB_DR_MODE_UNKNOWN;
> +}
For, dr_mode, if value has not existed, you use *_UNKNOWN, why
for usbphy, you use *_NA. It is better uniform.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 1/2] ASoC: tlv320aic3x: Convert mic bias to a supply widget
From: Mark Brown @ 2013-01-31 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359552155-17426-1-git-send-email-gururaja.hebbar@ti.com>
On Wed, Jan 30, 2013 at 06:52:35PM +0530, Hebbar Gururaja wrote:
> Convert MicBias widgets to supply widget.
> On tlv320aic3x, Mic bias power on/off shares the same register bits
> with output mic bias voltage. So, when power on mic bias, we need
> reclaim it to voltage value.
This should update machine drivers that use the CODEC too.
> +- ai3x-micbias-vg - MicBias Voltage required.
> + 1 - MICBIAS output is powered to 2.0V,
> + 2 - MICBIAS output is powered to 2.5V,
> + 3 - MICBIAS output is connected to AVDD,
> + If this node is not mentioned or if the value is incorrect, then MicBias
> + is powered down.
Would 2.0V not be a more sensible default (it is the lowest voltage so
is unlikely to cause hardware damage if it's wrong)?
Otherwise this looks good.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130131/c8628dbd/attachment.sig>
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Kumar, Anil @ 2013-01-31 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359536770.14894.38.camel@cumari.coelho.fi>
On Wed, Jan 30, 2013 at 14:36:10, Coelho, Luciano wrote:
> On Wed, 2013-01-30 at 14:18 +0530, Santosh Shilimkar wrote:
> > On Wednesday 30 January 2013 02:13 PM, Kumar, Anil wrote:
> > > Hi Sourav,
> > >
> > > On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote:
> > >> Hi Luciano,
> > >> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote:
> > >>> Hi Sourav,
> > >>>
> > >>> On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote:
> > >>>> Booting 3.8-rc4 om omap 4430sdp results in the following error
> > >>>>
> > >>>> omap_i2c 48070000.i2c: did not get pins for i2c error: -19
> > >>>> [ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
> > >>>> [ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
> > >>>> [ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
> > >>>> [ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
> > >>>> [ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
> > >>>> [ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
> > >>>> [ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
> > >>>>
> > >>>> This happens because omap4 dts file is not adapted to use i2c through pinctrl
> > >>>> framework. Populating i2c pinctrl data to get rid of the error.
> > >>>>
> > >>>> Tested on omap4430 sdp with 3.8-rc4 kernel.
> > >>>>
> > >>>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> > >>>> Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > >>>> ---
> > >>> Could you do the same thing for panda? I'm getting the same kind of
> > >>> errors with it:
> > >
> > > omap4 uses pinctrl-single driver for pinmux with DT. Currently
> > > pinctrl-single driver is getting up after I2C driver. So I2c cannot
> > > use pinctrl. The below patch solve this issue
> > >
> > > http://www.gossamer-threads.com/lists/linux/kernel/1669067
> > >
> > > Can you try with this ? it may solve it.
> > >
> > OMAP i2c driver already takes care of -EPROBE_DEFER. The issue
> > as you see from the log is not probe failure but missing the
> > pin information in DT blob. And thats what patch does.
>
> Yes, Santosh is right. I tried this patch, but it didn't fix the
> warnings.
Sorry, I misunderstood this issue.
Anil
^ permalink raw reply
* Failure to boot...
From: Olof Johansson @ 2013-01-31 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131014912.GM2637@n2100.arm.linux.org.uk>
On Thu, Jan 31, 2013 at 01:49:12AM +0000, Russell King - ARM Linux wrote:
> Having spent today sorting out the Realview EB boot, the last thing
> I expected to find was that both my OMAP platforms are unbootable
> to the point that absolutely nothing happens after the boot loader
> transfers control.
>
> I've not been running the boots for about a month, so I'm not sure
> when this breakage crept in.
>
> You can see the results in the boot logs on the website. Please
> investigate. And I'll try without arm-soc tomorrow.
>
> Very disappointed that the ARM kernel seems to be rather screwed at
> the moment across multiple sub-arches.
My Panda ES works with omap2plus_defconfig, but I just noticed that the
in-kernel uImage target will use a bad load/entry address so loading and
booting that uImage will hang u-boot:
Image Name: Linux-3.8.0-rc5-00389-g120d4a8
Created: Wed Jan 30 18:30:39 2013
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3843912 Bytes = 3753.82 kB = 3.67 MB
Load Address: fffffff2
Entry Point: fffffff2
Looking at the latest build and boot log for SDP (oldconfig) on your build
status site verifies that you hit that case too. :(
Wrapping by hand (which my scripts already do) produces a bootable image; just
verified both with and without device-tree on my panda.
git bisect points at a069486162a59513053cf772515217ca61727704 (ARM: OMAP2+:
Enable ARCH_MULTIPLATFORM support)
Hmm. This happens because nothing sources arch/arm/mach-*/Makefile.boot for
CONFIG_ARCH_MULTIPLATFORM builds, even if only a single platform is enabled,
since $MACHINE is empty.
It seems like most of the available options to deal with this are bad. One
thing we should never do though, is to pretend to make a working uImage
when we're not. Maybe abort building just like in the case of multiple
load addresses?
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index abfce28..71768b8 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -68,8 +68,8 @@ else
endif
check_for_multiple_loadaddr = \
-if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \
- echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \
+if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \
+ echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \
echo 'This is incompatible with uImages'; \
echo 'Specify LOADADDR on the commandline to build an uImage'; \
false; \
-Olof
^ permalink raw reply related
* [PATCH 4/6] usb: chipidea: add PTW and PTS handling
From: Peter Chen @ 2013-01-31 3:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359559782-14552-5-git-send-email-s.hauer@pengutronix.de>
On Wed, Jan 30, 2013 at 04:29:40PM +0100, Sascha Hauer wrote:
> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>
> +static void hw_phymode_configure(struct ci13xxx *ci)
> +{
> + u32 portsc;
> +
> + /*
> + * The lpm version has the corresponding bits in the devlc register.
> + * Currently not implemented.
> + */
> + if (ci->hw_bank.lpm)
> + return;
> +
> + switch (ci->platdata->phy_mode) {
> + case USBPHY_INTERFACE_MODE_UTMI:
> + portsc = PORTSC_PTS_PTW_UTMI;
> + break;
> + case USBPHY_INTERFACE_MODE_UTMIW:
> + portsc = PORTSC_PTS_PTW_UTMIW;
> + break;
> + case USBPHY_INTERFACE_MODE_ULPI:
> + portsc = PORTSC_PTS_PTW_ULPI;
> + break;
> + case USBPHY_INTERFACE_MODE_SERIAL:
> + portsc = PORTSC_PTS_PTW_SERIAL;
> + break;
> + case USBPHY_INTERFACE_MODE_HSIC:
> + portsc = PORTSC_PTS_PTW_HSIC;
> + break;
> + default:
> + return;
> + }
> +
> + hw_write(ci, OP_PORTSC, PORTSC_PTS_PTW, portsc);
> +
> + mdelay(10);
Please use usleep_range, can we recall which platform needs it?
As we as I know, there is no such delay at FSL internal release
code.
--
Best Regards,
Peter Chen
^ permalink raw reply
* Sound/ARM/i.MX/SSI: fix SDMA starvation
From: Shawn Guo @ 2013-01-31 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301301444.25814.jbe@pengutronix.de>
Thanks for the fix, Juergen.
The patch subject could be written in a better form with a proper
prefix added. "git log sound/soc/fsl/fsl_ssi.c" should give example.
To have the patch get in sooner, you should copy Mark Brown on it.
Also MAINTAINERS file gives the following, so you still do not have
the right list copied.
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)
M: Liam Girdwood <lrg@ti.com>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
L: alsa-devel at alsa-project.org (moderated for non-subscribers)
W: http://alsa-project.org/main/index.php/ASoC
S: Supported
F: sound/soc/
F: include/sound/soc*
On Wed, Jan 30, 2013 at 02:44:25PM +0100, Juergen Beisert wrote:
> Juergen Beisert wrote:
> > In cases when capturing is already running and someone enables also
> > playback, the SDMA unit of the i.MX SoC does not see an edge on its TX DMA
> > request line. This is due to the TX FIFOs are empty, and this request line
> > is active all the time, when the CCSR_SSI_SIER_TDMAE bit is set.
> > In this case also the TX FIFO underrun interrupt will flood the system
> > forever.
> >
> > To ensure the first edge happens after enabling the TX side of the SSI unit
> > and to trigger the SDMA unit successfully enable the CCSR_SSI_SIER_TDMAE on
> > demand only. To be sure, this patch does the same for the
> > CCSR_SSI_SIER_RDMAE (RX side) bit.
> >
> > Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
I can see the patch does fix the problem. A small comment below,
otherwise
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> >
> > ---
> > sound/soc/fsl/fsl_ssi.c | 24 ++++++++++++++++--------
> > 1 file changed, 16 insertions(+), 8 deletions(-)
> >
> > Index: linux.git/sound/soc/fsl/fsl_ssi.c
> > ===================================================================
> > --- linux.git.orig/sound/soc/fsl/fsl_ssi.c
> > +++ linux.git/sound/soc/fsl/fsl_ssi.c
> > @@ -86,10 +86,9 @@ static inline void write_ssi_mask(u32 __
> > #endif
> >
> > /* SIER bitflag of interrupts to enable */
> > -#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TDMAE | \
> > - CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TUE0_EN | \
> > - CCSR_SSI_SIER_TUE1_EN | CCSR_SSI_SIER_RFRC_EN | \
> > - CCSR_SSI_SIER_RDMAE | CCSR_SSI_SIER_RIE | \
> > +#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TIE | \
> > + CCSR_SSI_SIER_TUE0_EN | CCSR_SSI_SIER_TUE1_EN | \
> > + CCSR_SSI_SIER_RFRC_EN | CCSR_SSI_SIER_RIE | \
It takes me sometime to see the real change here is to remove flags
CCSR_SSI_SIER_TDMAE and CCSR_SSI_SIER_RDMAE. Then the changes below
should look less dramatic and ease the reviewers a little bit, I think.
Shawn
--8<---
@@ -86,10 +86,9 @@ static inline void write_ssi_mask(u32 __iomem *addr, u32 clear, u32 set)
#endif
/* SIER bitflag of interrupts to enable */
-#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TDMAE | \
+#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_RIE | \
CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TUE0_EN | \
CCSR_SSI_SIER_TUE1_EN | CCSR_SSI_SIER_RFRC_EN | \
- CCSR_SSI_SIER_RDMAE | CCSR_SSI_SIER_RIE | \
CCSR_SSI_SIER_ROE0_EN | CCSR_SSI_SIER_ROE1_EN)
> > CCSR_SSI_SIER_ROE0_EN | CCSR_SSI_SIER_ROE1_EN)
> >
> > /**
> > @@ -489,6 +488,9 @@ static int fsl_ssi_hw_params(struct snd_
> > *
> > * The DMA channel is in external master start and pause mode, which
> > * means the SSI completely controls the flow of data.
> > + *
> > + * To use the i.MX's SDMA unit it is important to create an edge on the
> > + * corresponding request line. Otherwise the request will be ignored!
> > */
> > static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
> > struct snd_soc_dai *dai)
> > @@ -500,20 +502,26 @@ static int fsl_ssi_trigger(struct snd_pc
> > switch (cmd) {
> > case SNDRV_PCM_TRIGGER_START:
> > case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> > - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> > write_ssi_mask(&ssi->scr, 0,
> > CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_TE);
> > - else
> > + write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TDMAE);
> > + } else {
> > write_ssi_mask(&ssi->scr, 0,
> > CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_RE);
> > + write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RDMAE);
> > + }
> > break;
> >
> > case SNDRV_PCM_TRIGGER_STOP:
> > case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> > - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> > write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TE, 0);
> > - else
> > + write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TDMAE, 0);
> > + } else {
> > write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
> > + write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RDMAE, 0);
> > + }
> > break;
> >
> > default:
>
> Any comments on this patch?
>
> jbe
>
> --
> Pengutronix e.K. | Juergen Beisert |
> Linux Solutions for Science and Industry | Phone: +49-5121-206917-5128 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
>
> _______________________________________________
> 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 v4] cpufreq: add imx6q-cpufreq driver
From: Shawn Guo @ 2013-01-31 3:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129025652.GB11546@S2101-09.ap.freescale.net>
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.
Shawn
^ permalink raw reply
* [PATCH 0/4] ASoC: atmel: fixes for working as module
From: Bo Shen @ 2013-01-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
The following patches fixes the audio part when working as module
Bo Shen (4):
ASoC: atmel_pcm: make it buildable as module
ASoC: atmel_ssc_dai: remove error set private data
ASoC: atmel_ssc_dai: correct sequence when unload
ASoC: sam9g20_wm8731: disable clock and correct sequence when unload
sound/soc/atmel/atmel-pcm.h | 6 ++++--
sound/soc/atmel/atmel_ssc_dai.c | 12 +-----------
sound/soc/atmel/sam9g20_wm8731.c | 6 +++---
3 files changed, 8 insertions(+), 16 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/4] ASoC: atmel_pcm: make it buildable as module
From: Bo Shen @ 2013-01-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359604420-15171-1-git-send-email-voice.shen@atmel.com>
When build as module, it reports following error, using this patch
fix it
sound/soc/atmel/atmel-pcm-pdc.c:387: error: redefinition of 'atmel_pcm_pdc_platform_register'
sound/soc/atmel/atmel-pcm.h:95: note: previous definition of 'atmel_pcm_pdc_platform_register' was here
sound/soc/atmel/atmel-pcm-pdc.c:393: error: redefinition of 'atmel_pcm_pdc_platform_unregister'
sound/soc/atmel/atmel-pcm.h:99: note: previous definition of 'atmel_pcm_pdc_platform_unregister' was here
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
sound/soc/atmel/atmel-pcm.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/atmel/atmel-pcm.h b/sound/soc/atmel/atmel-pcm.h
index bb45d20..12ae814 100644
--- a/sound/soc/atmel/atmel-pcm.h
+++ b/sound/soc/atmel/atmel-pcm.h
@@ -88,7 +88,8 @@ void atmel_pcm_free(struct snd_pcm *pcm);
int atmel_pcm_mmap(struct snd_pcm_substream *substream,
struct vm_area_struct *vma);
-#ifdef CONFIG_SND_ATMEL_SOC_PDC
+#if defined(CONFIG_SND_ATMEL_SOC_PDC) || \
+ defined(CONFIG_SND_ATMEL_SOC_PDC_MODULE)
int atmel_pcm_pdc_platform_register(struct device *dev);
void atmel_pcm_pdc_platform_unregister(struct device *dev);
#else
@@ -101,7 +102,8 @@ static inline void atmel_pcm_pdc_platform_unregister(struct device *dev)
}
#endif
-#ifdef CONFIG_SND_ATMEL_SOC_DMA
+#if defined(CONFIG_SND_ATMEL_SOC_DMA) || \
+ defined(CONFIG_SND_ATMEL_SOC_DMA_MODULE)
int atmel_pcm_dma_platform_register(struct device *dev);
void atmel_pcm_dma_platform_unregister(struct device *dev);
#else
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ASoC: atmel_ssc_dai: remove error set private data
From: Bo Shen @ 2013-01-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359604420-15171-1-git-send-email-voice.shen@atmel.com>
ssc private data has been set in ssc driver, this cause the error
private data set to ssc, remove it
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
sound/soc/atmel/atmel_ssc_dai.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 1c76634..2763aea 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -679,15 +679,6 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai)
# define atmel_ssc_resume NULL
#endif /* CONFIG_PM */
-static int atmel_ssc_probe(struct snd_soc_dai *dai)
-{
- struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
-
- snd_soc_dai_set_drvdata(dai, ssc_p);
-
- return 0;
-}
-
#define ATMEL_SSC_RATES (SNDRV_PCM_RATE_8000_96000)
#define ATMEL_SSC_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |\
@@ -703,7 +694,6 @@ static const struct snd_soc_dai_ops atmel_ssc_dai_ops = {
};
static struct snd_soc_dai_driver atmel_ssc_dai = {
- .probe = atmel_ssc_probe,
.suspend = atmel_ssc_suspend,
.resume = atmel_ssc_resume,
.playback = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ASoC: atmel_ssc_dai: correct sequence when unload
From: Bo Shen @ 2013-01-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359604420-15171-1-git-send-email-voice.shen@atmel.com>
correct the sequence when unload this module
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
sound/soc/atmel/atmel_ssc_dai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 2763aea..1fab8d5 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -780,8 +780,8 @@ void atmel_ssc_put_audio(int ssc_id)
{
struct ssc_device *ssc = ssc_info[ssc_id].ssc;
- ssc_free(ssc);
asoc_ssc_exit(&ssc->pdev->dev);
+ ssc_free(ssc);
}
EXPORT_SYMBOL_GPL(atmel_ssc_put_audio);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ASoC: sam9g20_wm8731: disable clock and correct sequence when unload
From: Bo Shen @ 2013-01-31 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359604420-15171-1-git-send-email-voice.shen@atmel.com>
disable clock and correct sequence when unload
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
sound/soc/atmel/sam9g20_wm8731.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c
index da97629..2d6fbd0 100644
--- a/sound/soc/atmel/sam9g20_wm8731.c
+++ b/sound/soc/atmel/sam9g20_wm8731.c
@@ -305,10 +305,10 @@ static int at91sam9g20ek_audio_remove(struct platform_device *pdev)
{
struct snd_soc_card *card = platform_get_drvdata(pdev);
- atmel_ssc_put_audio(0);
- snd_soc_unregister_card(card);
- clk_put(mclk);
+ clk_disable(mclk);
mclk = NULL;
+ snd_soc_unregister_card(card);
+ atmel_ssc_put_audio(0);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
From: Patil, Rachna @ 2013-01-31 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A9839AA2-ABCD-4642-9766-D56824AC27AD@dominion.thruhere.net>
On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
>
> Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" <rachna@ti.com> het volgende geschreven:
>
> > From: "Patil, Rachna" <rachna@ti.com>
> >
> > Make changes to add DT support in the MFD core driver.
> >
> > Signed-off-by: Patil, Rachna <rachna@ti.com>
> > ---
> > Changes in v4:
> > Non-standard properties prefixed with vendor name.
> >
> > drivers/mfd/ti_am335x_tscadc.c | 28 +++++++++++++++++++++++-----
> > 1 file changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mfd/ti_am335x_tscadc.c
> > b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
> > --- a/drivers/mfd/ti_am335x_tscadc.c
> > +++ b/drivers/mfd/ti_am335x_tscadc.c
> > @@ -22,6 +22,8 @@
> > #include <linux/regmap.h>
> > #include <linux/mfd/core.h>
> > #include <linux/pm_runtime.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> >
> > #include <linux/mfd/ti_am335x_tscadc.h> #include
> > <linux/input/ti_am335x_tsc.h>
> > @@ -64,20 +66,31 @@ static int ti_tscadc_probe(struct platform_device *pdev)
> > struct resource *res;
> > struct clk *clk;
> > struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> > + struct device_node *node = pdev->dev.of_node;
> > struct mfd_cell *cell;
> > int err, ctrl;
> > int clk_value, clock_rate;
> > - int tsc_wires, adc_channels = 0, total_channels;
> > + int tsc_wires = 0, adc_channels = 0, total_channels;
> >
> > - if (!pdata) {
> > + if (!pdata && !pdev->dev.of_node) {
> > dev_err(&pdev->dev, "Could not find platform data\n");
> > return -EINVAL;
> > }
> >
> > - if (pdata->adc_init)
> > - adc_channels = pdata->adc_init->adc_channels;
> > + if (pdev->dev.platform_data) {
> > + if (pdata->tsc_init)
> > + tsc_wires = pdata->tsc_init->wires;
> > +
> > + if (pdata->adc_init)
> > + adc_channels = pdata->adc_init->adc_channels;
> > + } else {
> > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > +
> > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> > + }
>
> Since AM335x is DT only, why is there a platform data codepath and why is it the first branch it tries? And I guess the next question is related to the first: why doesn't it work when used with DT? When I copy over the nodes from the evm.dts to my board I get "tsc tsc: Missing platform data" in dmesg.
This IP came up 1st on AM335x, but it is not platform dependent. The driver can be used on other platforms where-in DT is not supported.
According to the maintainers platform data takes precedence over DT. Hence the order.
I do not see "Missing platform data" error msg in the latest driver. I am not able to trace from where this got populated.
>
> What are the chances this driver will work when applied on top of 3.8-rcX? Has it even been tested with that? Has it been tested at all?
This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
Regards,
Rachna
^ permalink raw reply
* Failure to boot...
From: Nicolas Pitre @ 2013-01-31 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131030203.GA8374@quad.lixom.net>
On Wed, 30 Jan 2013, Olof Johansson wrote:
> My Panda ES works with omap2plus_defconfig, but I just noticed that the
> in-kernel uImage target will use a bad load/entry address so loading and
> booting that uImage will hang u-boot:
>
> Image Name: Linux-3.8.0-rc5-00389-g120d4a8
> Created: Wed Jan 30 18:30:39 2013
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3843912 Bytes = 3753.82 kB = 3.67 MB
> Load Address: fffffff2
> Entry Point: fffffff2
>
> Looking at the latest build and boot log for SDP (oldconfig) on your build
> status site verifies that you hit that case too. :(
>
> Wrapping by hand (which my scripts already do) produces a bootable image; just
> verified both with and without device-tree on my panda.
>
> git bisect points at a069486162a59513053cf772515217ca61727704 (ARM: OMAP2+:
> Enable ARCH_MULTIPLATFORM support)
>
> Hmm. This happens because nothing sources arch/arm/mach-*/Makefile.boot for
> CONFIG_ARCH_MULTIPLATFORM builds, even if only a single platform is enabled,
> since $MACHINE is empty.
The uImage format is incompatible with multi-platform builds, period.
The uImage wrapping should be done at kernel _installation_ time, not at
_build_ time. That is, people shoud get into the habit of distributing
a zImage binary, and the installation procedure on a particular platform
should take care of running mkimage on it.
Better yet (IMHO): just enable the zboot command in U-Boot to let you
boot a zImage binary directly.
> It seems like most of the available options to deal with this are bad. One
> thing we should never do though, is to pretend to make a working uImage
> when we're not. Maybe abort building just like in the case of multiple
> load addresses?
Absolutely.
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index abfce28..71768b8 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -68,8 +68,8 @@ else
> endif
>
> check_for_multiple_loadaddr = \
> -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \
> - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \
> +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \
> + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \
> echo 'This is incompatible with uImages'; \
> echo 'Specify LOADADDR on the commandline to build an uImage'; \
> false; \
Acked-by: Nicolas Pitre <nico@linaro.org>
Nicolas
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Viresh Kumar @ 2013-01-31 4:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1887364.fvxYYNb7Mm@amdc1227>
On Tue, Nov 13, 2012 at 2:56 PM, Tomasz Figa <t.figa@samsung.com> wrote:
> On Exynos SoCs all cores share the same frequency setting, so changing
> frequency of one core will affect rest of cores.
>
> This patch modifies the exynos-cpufreq driver to inform cpufreq core
> about this behavior and broadcast frequency change notifications for all
> cores.
> /* When the new frequency is lower than current frequency */
> if ((freqs.new < freqs.old) ||
> @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
> cpumask_copy(policy->related_cpus, cpu_possible_mask);
> cpumask_copy(policy->cpus, cpu_online_mask);
> } else {
> + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> cpumask_setall(policy->cpus);
I couldn't understand the use of this change. Can you please explain ?
^ permalink raw reply
* [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
From: Hiremath, Vaibhav @ 2013-01-31 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CE347531D4CA947960AF71FF095B9323E9B1EE9@DBDE01.ent.ti.com>
On Thu, Jan 31, 2013 at 09:41:11, Patil, Rachna wrote:
> On Wed, Jan 30, 2013 at 16:10:09, Koen Kooi wrote:
> >
> > Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" <rachna@ti.com> het volgende geschreven:
> >
> > > From: "Patil, Rachna" <rachna@ti.com>
> > >
> > > Make changes to add DT support in the MFD core driver.
> > >
> > > Signed-off-by: Patil, Rachna <rachna@ti.com>
> > > ---
> > > Changes in v4:
> > > Non-standard properties prefixed with vendor name.
> > >
> > > drivers/mfd/ti_am335x_tscadc.c | 28 +++++++++++++++++++++++-----
> > > 1 file changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/mfd/ti_am335x_tscadc.c
> > > b/drivers/mfd/ti_am335x_tscadc.c index e9f3fb5..87b446b 100644
> > > --- a/drivers/mfd/ti_am335x_tscadc.c
> > > +++ b/drivers/mfd/ti_am335x_tscadc.c
> > > @@ -22,6 +22,8 @@
> > > #include <linux/regmap.h>
> > > #include <linux/mfd/core.h>
> > > #include <linux/pm_runtime.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > >
> > > #include <linux/mfd/ti_am335x_tscadc.h> #include
> > > <linux/input/ti_am335x_tsc.h>
> > > @@ -64,20 +66,31 @@ static int ti_tscadc_probe(struct platform_device *pdev)
> > > struct resource *res;
> > > struct clk *clk;
> > > struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> > > + struct device_node *node = pdev->dev.of_node;
> > > struct mfd_cell *cell;
> > > int err, ctrl;
> > > int clk_value, clock_rate;
> > > - int tsc_wires, adc_channels = 0, total_channels;
> > > + int tsc_wires = 0, adc_channels = 0, total_channels;
> > >
> > > - if (!pdata) {
> > > + if (!pdata && !pdev->dev.of_node) {
> > > dev_err(&pdev->dev, "Could not find platform data\n");
> > > return -EINVAL;
> > > }
> > >
> > > - if (pdata->adc_init)
> > > - adc_channels = pdata->adc_init->adc_channels;
> > > + if (pdev->dev.platform_data) {
> > > + if (pdata->tsc_init)
> > > + tsc_wires = pdata->tsc_init->wires;
> > > +
> > > + if (pdata->adc_init)
> > > + adc_channels = pdata->adc_init->adc_channels;
> > > + } else {
> > > + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> > > + of_property_read_u32(node, "ti,wires", &tsc_wires);
> > > +
> > > + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> > > + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> > > + }
> >
> > Since AM335x is DT only, why is there a platform data codepath and why is it the first branch it tries? And I guess the next question is related to the first: why doesn't it work when used with DT? When I copy over the nodes from the evm.dts to my board I get "tsc tsc: Missing platform data" in dmesg.
>
> This IP came up 1st on AM335x, but it is not platform dependent. The driver can be used on other platforms where-in DT is not supported.
> According to the maintainers platform data takes precedence over DT. Hence the order.
>
Rachana,
I see no point adding support for platform_data when you know that none of
older platforms are going to use this driver and all future platforms _must_
follow device-tree model.
So I agree that you should remove board file dependency from the driver.
> I do not see "Missing platform data" error msg in the latest driver. I am not able to trace from where this got populated.
>
Can you share the branch which you have tested?
Thanks,
Vaibhav
> >
> > What are the chances this driver will work when applied on top of 3.8-rcX? Has it even been tested with that? Has it been tested at all?
>
> This driver has been tested on top of v3.8-rc3 on a AM335x EVM.
>
> Regards,
> Rachna
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* [PATCH v2] ARM: OMAP2: hwmod: Fix "register offset NULL check" bug
From: Hebbar, Gururaja @ 2013-01-31 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301301634310.17105@utopia.booyaka.com>
On Wed, Jan 30, 2013 at 22:09:51, Paul Walmsley wrote:
> On Wed, 30 Jan 2013, Hebbar, Gururaja wrote:
>
> > On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote:
> > > On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
> > >
> > > > On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
> > > >
> > > > > We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
> > > > > listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
> > > > > What's going to happen in those cases?
> > > >
> > > > Hmm. This is a special case to me. Let me go back and do some review.
> > > > Will be back with some more details.
> > >
> > > Probably what needs to happen is that those hwmods need to be marked with
> > > HWMOD_NO_IDLEST, in a separate patch before yours. As far as I can tell,
> > > that's how they should have been marked initially. Then your patch should
> > > be fine.
> >
> > Looking at latest kernel v3.8-rc5, there is separate cm33xx.c file which
> > handles module ready checking for am33xx platform. So I will update this
> > patch to work on this file instead of touching omap4 related file
> > (cminst44xx.c)
>
> The same problem still exists. According to the TRM, there's at least one
> AM335x CLKCTRL register that doesn't have IDLEST bits. So to avoid
> reading reserved bits, either this patch or a preceding patch should
> mark those hwmods with HWMOD_NO_IDLEST.
Ok. I will look into this now.
>
>
> - Paul
>
Regards,
Gururaja
^ permalink raw reply
* [PATCH 1/2] ASoC: tlv320aic3x: Convert mic bias to a supply widget
From: Hebbar, Gururaja @ 2013-01-31 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131023221.GA6027@opensource.wolfsonmicro.com>
On Thu, Jan 31, 2013 at 08:02:25, Mark Brown wrote:
> On Wed, Jan 30, 2013 at 06:52:35PM +0530, Hebbar Gururaja wrote:
>
> > Convert MicBias widgets to supply widget.
>
> > On tlv320aic3x, Mic bias power on/off shares the same register bits
> > with output mic bias voltage. So, when power on mic bias, we need
> > reclaim it to voltage value.
>
> This should update machine drivers that use the CODEC too.
Yes. I have that patch ready. Once this is accepted, I will send all
the patch as a series
>
> > +- ai3x-micbias-vg - MicBias Voltage required.
> > + 1 - MICBIAS output is powered to 2.0V,
> > + 2 - MICBIAS output is powered to 2.5V,
> > + 3 - MICBIAS output is connected to AVDD,
> > + If this node is not mentioned or if the value is incorrect, then MicBias
> > + is powered down.
>
> Would 2.0V not be a more sensible default (it is the lowest voltage so
> is unlikely to cause hardware damage if it's wrong)?
The only reason I made this choice was because none of the existing platforms
using this codec are setting the MicBias.
>
> Otherwise this looks good.
Ok. I will send all the patch as a series now.
>
Regards,
Gururaja
^ permalink raw reply
* [PATCH 2/6] usb: add devicetree helpers for determining dr_mode and phy_type
From: kishon @ 2013-01-31 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359559782-14552-3-git-send-email-s.hauer@pengutronix.de>
Hi,
On Wednesday 30 January 2013 08:59 PM, Sascha Hauer wrote:
> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>
> This adds two little devicetree helper functions for determining the
> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> the devicetree.
>
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/usb-common.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb/of.h | 27 ++++++++++++++++++
> include/linux/usb/otg.h | 7 +++++
> include/linux/usb/phy.h | 9 ++++++
> 4 files changed, 112 insertions(+)
> create mode 100644 include/linux/usb/of.h
>
> diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
> index d29503e..1c0292c 100644
> --- a/drivers/usb/usb-common.c
> +++ b/drivers/usb/usb-common.c
> @@ -14,6 +14,9 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/usb/ch9.h>
> +#include <linux/of.h>
> +#include <linux/usb/of.h>
> +#include <linux/usb/otg.h>
>
> const char *usb_speed_string(enum usb_device_speed speed)
> {
> @@ -32,4 +35,70 @@ const char *usb_speed_string(enum usb_device_speed speed)
> }
> EXPORT_SYMBOL_GPL(usb_speed_string);
>
> +#ifdef CONFIG_OF
> +static const char *usb_dr_modes[] = {
> + [USB_DR_MODE_UNKNOWN] = "",
> + [USB_DR_MODE_HOST] = "host",
> + [USB_DR_MODE_PERIPHERAL] = "peripheral",
> + [USB_DR_MODE_OTG] = "otg",
> +};
> +
> +/**
> + * of_usb_get_dr_mode - Get dual role mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'dr_mode',
> + * and returns the correspondig enum usb_phy_dr_mode
> + */
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
> +{
> + const char *dr_mode;
> + int err, i;
> +
> + err = of_property_read_string(np, "dr_mode", &dr_mode);
> + if (err < 0)
> + return USB_DR_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> + if (!strcasecmp(dr_mode, usb_dr_modes[i]))
> + return i;
> +
> + return USB_DR_MODE_UNKNOWN;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_dr_mode);
> +
> +static const char *usbphy_modes[] = {
> + [USBPHY_INTERFACE_MODE_NA] = "",
> + [USBPHY_INTERFACE_MODE_UTMI] = "utmi",
> + [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
> + [USBPHY_INTERFACE_MODE_ULPI] = "ulpi",
> + [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
> + [USBPHY_INTERFACE_MODE_HSIC] = "hsic",
> +};
> +
> +/**
> + * of_get_usbphy_mode - Get phy mode for given device_node
%s/of_get_usbphy_mode/of_usb_get_phy_mode
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'phy_type',
> + * and returns the correspondig enum usb_phy_interface
> + */
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> +{
You agreed to move this function inside usb/phy.. no?
Thanks
Kishon
^ permalink raw reply
* [PATCH] arm: dts: omap4-panda: Add I2c pinctrl data
From: Sourav Poddar @ 2013-01-31 6:23 UTC (permalink / raw)
To: linux-arm-kernel
Booting 3.8-rc4 on omap4 panda results in the following error
[ 0.444427] omap_i2c 48070000.i2c: did not get pins for i2c error: -19
[ 0.445770] omap_i2c 48070000.i2c: bus 0 rev0.11 at 400 kHz
[ 0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[ 0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
[ 0.474822] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
[ 0.476379] omap_i2c 48060000.i2c: bus 2 rev0.11 at 100 kHz
[ 0.477294] omap_i2c 48350000.i2c: did not get pins for i2c error: -19
[ 0.477996] omap_i2c 48350000.i2c: bus 3 rev0.11 at 400 kHz
[ 0.483398] Switching to clocksource 32k_counter
This happens because omap4 panda dts file is not adapted to use i2c through
pinctrl framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4460 panda with 3.8-rc4 kernel.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reported-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 40 +++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..f951e6b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -110,9 +110,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN | MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118 /* i2c1_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xe4 0x118 /* i2c1_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0xe6 0x118 /* i2c2_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xe8 0x118 /* i2c2_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118 /* i2c3_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118 /* i2c4_scl PULLUP | INPUTENABLE | MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0 */
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <400000>;
twl: twl at 48 {
@@ -139,10 +170,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <400000>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <100000>;
/*
@@ -156,6 +193,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <400000>;
};
--
1.7.1
^ permalink raw reply related
* [GIT PULL] Renesas ARM-based SoC for v3.9 #2
From: Simon Horman @ 2013-01-31 6:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
The following changes since commit 42dd581bc4dba82e8756bb881fa974742250b4c6:
ARM: shmobile: Include sh73a0 DTSI in kzm9g (2013-01-25 09:26:33 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards2-for-v3.9
for you to fetch changes up to 2f27c40656fecba44e839c77910f75ee1024df62:
ARM: shmobile: armadillo800eva: set clock rates before timer init (2013-01-30 13:24:07 +0900)
----------------------------------------------------------------
Second round of Renesas ARM-based SoC board changes for v3.9
* Fix to correct timer initialisation on the armadillo 800 eva board
from Hideki EIRAKU
* The remaining of the changes relate to updating boards to
make use of gpio_request_one(). These changes are from Laurent Pinchart.
----------------------------------------------------------------
Hideki EIRAKU (1):
ARM: shmobile: armadillo800eva: set clock rates before timer init
Laurent Pinchart (8):
ARM: shmobile: ag5evm: Use gpio_request_one()
ARM: shmobile: ap4evb: Use gpio_request_one()
ARM: shmobile: armadillo800eva: Use gpio_request_one()
ARM: shmobile: armadillo800eva: Use gpio_set_value() to set GPIO value
ARM: shmobile: kota2: Use gpio_request_one()
ARM: shmobile: bonito: Use gpio_request_one()
ARM: shmobile: kzm9g: Use gpio_request_one()
ARM: shmobile: mackerel: Use gpio_request_one()
arch/arm/mach-shmobile/board-ag5evm.c | 22 ++++-----
arch/arm/mach-shmobile/board-ap4evb.c | 33 ++++----------
arch/arm/mach-shmobile/board-armadillo800eva.c | 57 +++++++++---------------
arch/arm/mach-shmobile/board-bonito.c | 7 ++-
arch/arm/mach-shmobile/board-kota2.c | 9 ++--
arch/arm/mach-shmobile/board-kzm9g.c | 18 +++-----
arch/arm/mach-shmobile/board-mackerel.c | 16 +++----
7 files changed, 57 insertions(+), 105 deletions(-)
^ 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