* [PATCH v2 8/9] i2c: pxa: configure pinmux
From: Linus Walleij @ 2012-10-23 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-9-git-send-email-haojian.zhuang@gmail.com>
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> Configure pins by pinctrl driver.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
So as I think the distributed approach to this is OK:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Linus Walleij @ 2012-10-23 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350906877-19410-1-git-send-email-balbi@ti.com>
On Mon, Oct 22, 2012 at 1:54 PM, Felipe Balbi <balbi@ti.com> wrote:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is written.
>
> This became an issue on OMAP when we converted omap-i2c.c
> to use threaded IRQs, it turned out that depending on how
> much time we spent on suspend, the I2C IRQ thread would
> end up being rescheduled so far in the future that I2C
> transfers would timeout and, because omap_hsmmc depends
> on an I2C-connected device to detect if an MMC card is
> inserted in the slot, our rootfs would just vanish.
>
> arch/arm/kernel/sched_clock.c already had an optional
> implementation (sched_clock_needs_suspend()) which would
> handle scheduler's requirement properly, what this patch
> does is simply to make that implementation non-optional.
>
> This has been tested with beagleboard XM (OMAP3630) and
> pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
> after this patch.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
After Russell explains so I get it:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Hiremath, Vaibhav @ 2012-10-23 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019061630.GB2983@netboy.at.omicron.at>
On Fri, Oct 19, 2012 at 11:46:30, Richard Cochran wrote:
> On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> >
> > Another important point is, this driver is also required and used for
> > Davinci family of devices (arch/mach/mach-davinci/).
>
> That is really beside the point. If the code isn't ready yet, then
> don't merge it.
>
With respect to AM33xx the driver may not be ready, but that doesn't mean
driver itself is not ready. As I mentioned before, driver is used on davinci
platform and it could be functional there.
In case of AM33xx, where DT only boot mode is supported, you are forced to
migrate driver to DT, which is addition to the driver.
Note that, all the patches you have posted recently are AM33xx SoC
integration specific patches.
> When I asked about the beaglebone, I was given the impression that it
> will be ready for v3.7-rc1. But, as I know realize, at the current
> rate, it might not even be ready for v3.8.
>
I understand, and as you mentioned we are not fully there at v3.7-rc1 with
all the drivers/module support, due to all known reasons. Its good that with
v3.7-rc2, Beaglebone boots up out of box from mainline.
Thanks,
Vaibhav
> I don't mind waiting, but please make sure that whatever lands into a
> release is really, truly working.
>
> Thanks,
> Richard
>
>
>
^ permalink raw reply
* [PATCH 1/4] mtd: nand: omap2: Update nerrors using ecc.strength
From: Philip, Avinash @ 2012-10-23 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87obk3va1j.fsf@macbook.be.48ers.dk>
On Tue, Oct 16, 2012 at 00:26:40, Peter Korsgaard wrote:
> >>>>> Philip, Avinash <avinashphilip@ti.com> writes:
>
> > Update number of errors using nand ecc strength.
> > Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX
>
> > Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
> > ---
> > :100644 100644 5b31386... af511a9... M drivers/mtd/nand/omap2.c
> > drivers/mtd/nand/omap2.c | 12 ++++++++----
> > 1 files changed, 8 insertions(+), 4 deletions(-)
>
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index 5b31386..af511a9 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -111,6 +111,9 @@
> > #define ECCCLEAR 0x100
> > #define ECC1 0x1
>
> > +#define BCH8_MAX_ERROR 8 /* upto 8 bit coorectable */
> > +#define BCH4_MAX_ERROR 4 /* upto 4 bit correctable */
>
> First 'correctable' misspelled.
I will correct it
>
> I don't personally think these defines improve readability very much
> compared to to just using 4/8, though.
Thought of removing magic numbers & provide information also.
Thanks
Avinash
>
> --
> Bye, Peter Korsgaard
>
^ permalink raw reply
* [PATCH 2/4] mtd: devices: elm: Add support for ELM error correction
From: Philip, Avinash @ 2012-10-23 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87hapvv800.fsf@macbook.be.48ers.dk>
On Tue, Oct 16, 2012 at 01:10:47, Peter Korsgaard wrote:
> >>>>> Philip, Avinash <avinashphilip@ti.com> writes:
>
> > Platforms containing the ELM module can be used to correct errors
> > reported by BCH 4, 8 & 16 bit ECC scheme. For now only 4 & 8 bit
> > support is added.
>
> This sounds odd to me. What about something like:
>
> The ELM hardware module can be used to speedup BCH 4/8/16 ECC scheme
> error correction.
>
> For now only 4 & 8 bit support is added.
Ok I will correct it.
>
>
> > +++ b/drivers/mtd/devices/Makefile
> > @@ -17,8 +17,10 @@ obj-$(CONFIG_MTD_LART) += lart.o
> > obj-$(CONFIG_MTD_BLOCK2MTD) += block2mtd.o
> > obj-$(CONFIG_MTD_DATAFLASH) += mtd_dataflash.o
> > obj-$(CONFIG_MTD_M25P80) += m25p80.o
> > +obj-$(CONFIG_MTD_NAND_OMAP2) += elm.o
>
> You seem to only use it in 4/4 if CONFIG_MTD_NAND_OMAP_BCH is set, so it
> probably makes more sense to use that symbol to not needlessly include
> it if it won't be used.
Ok. This been good.
>
>
> > +static void elm_write_reg(void *offset, u32 val)
> > +{
> > + writel(val, offset);
> > +}
> > +
> > +static u32 elm_read_reg(void *offset)
> > +{
> > + return readl(offset);
> > +}
>
> As written these read/write wrappers don't add anything. How about
> passing struct elm_info and offset as an integer so you can drop
> elm_base from all call sites, E.G.:
>
> static void elm_write_reg(struct elm_info *info, int offset, u32 val)
> {
> writel(val, info->elm_base + offset);
> }
>
Ok, this helps to reduce some indentation levels also.
>
> > +void elm_decode_bch_error_page(struct device *dev, u8 *ecc_calc,
> > + struct elm_errorvec *err_vec)
> > +{
> > + int i;
> > + u8 syndrome[BCH_MAX_ECC_BYTES_PER_SECTOR] = {0}, *syn_p;
>
>
> Why do you need to keep the entire syndrome around? You seem to only use
> it between elm_reverse_eccdata() and elm_load_syndrome(), so it could as
> well be BCH8_ECC_OOB_BYTES long (or rather a multiple of sizeof(u32).
>
> It would also be good to do the shuffeling directly in elm_load_syndrome
> so you don't need the extra copy.
I will check.
>
>
> > + */
> > +
> > +#ifndef __ELM_H
> > +#define __ELM_H
> > +
> > +enum bch_ecc {
> > + BCH4_ECC = 0,
> > + BCH8_ECC,
> > + BCH16_ECC,
>
> It probably makes more sense to not provide the enum value for BCH16 as
> you don't support it.
>
Ok I will remove.
>
> > +};
> > +
Thanks
Avinash
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme
From: Philip, Avinash @ 2012-10-23 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vcebvaf5.fsf@macbook.be.48ers.dk>
On Tue, Oct 16, 2012 at 00:18:30, Peter Korsgaard wrote:
> >>>>> Philip, Avinash <avinashphilip@ti.com> writes:
>
> > Add support for BCH ECC scheme to gpmc driver and also enabling multi
> > sector read/write. This helps in doing single shot NAND page read and
> > write.
>
> > ECC engine configurations
> > BCH 4 bit support
> > 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> > 2. read => ECC engine configured in wrap mode 1 and with ecc_size0 as
> > 13 and ecc_size1 as 1.
>
> > BCH 8 bit support
> > 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> > 2. read => ECC engine configured in wrap mode 1 and with ecc_size0 as
> > 26 and ecc_size1 as 2.
>
> > Note: For BCH8 ECC bytes set to 14 to make compatible with RBL.
>
> On what device? In the am335x TRM (spruh73f.pdf) figure 26-15 (pg 4273)
> the rom code is documented to not use any padding on the ECC bytes
> (E.G. oob 2..53):
>
> http://www.ti.com/litv/pdf/spruh73f
>
> I see the driver in the u-boot-am33x tree (ti81xx_nand.c) seems to use
> 4x14 bytes as well though, so perhaps that's a bug in the documentation
> instead?
Yes, RBL uses 4x14 bytes.
Thanks
Avinash
>
> --
> Bye, Peter Korsgaard
>
^ permalink raw reply
* i.MX28 die temperature
From: Peter Turczak @ 2012-10-23 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210231052.39983.marex@denx.de>
Hi Marek,
On Oct 23, 2012, at 10:52 AM, Marek Vasut wrote:
> We have some basic LRADC driver in upstream already, you should use that.
>
> See drivers/staging/iio/adc/mxs-lradc.c
Thanks for the heads-up.
I was referring to this driver (pulled from linus' 3.7rc), it does not currently seem to have a consumer api for use within other kernel modules. Maybe I'm just heading the wrong way now...
Best regards,
Peter
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Gregory CLEMENT @ 2012-10-23 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023100057.GS21164@n2100.arm.linux.org.uk>
On 10/23/2012 12:00 PM, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 11:43:02AM +0200, Gregory CLEMENT wrote:
>> On 10/23/2012 11:01 AM, Russell King - ARM Linux wrote:
>>> On Thu, Sep 27, 2012 at 11:35:23AM +0200, Gregory CLEMENT wrote:
>>>> Aurora Cache Controller was designed to be compatible with the ARM L2
>>>> Cache Controller. It comes with some difference or improvement such
>>>> as:
>>>> - no cache id part number available through hardware (need to get it
>>>> by the DT).
>>>> - always write through mode available.
>>>> - two flavors of the controller outer cache and system cache (meaning
>>>> maintenance operations on L1 are broadcasted to the L2 and L2
>>>> performs the same operation).
>>>> - in outer cache mode, the cache maintenance operations are improved and
>>>> can be done on a range inside a page and are not limited to a cache
>>>> line.
>>>
>>> This adds new build warnings:
>>>
>>> arch/arm/mm/cache-l2x0.c:328:13: warning: 'aurora_inv_range' defined but not used
>>> arch/arm/mm/cache-l2x0.c:347:13: warning: 'aurora_clean_range' defined but not used
>>> arch/arm/mm/cache-l2x0.c:365:13: warning: 'aurora_flush_range' defined but not used
>>>
>>> to the realview build (non-DT). Please investigate, thanks.
>>
>> OK I found the problem: aurora cache support is new so it is only
>> enable with device tree support. I moved all this functions in the
>> under OF_CONFIG (see the patch below). Do you want I submit it on the
>> patch system, or can you get it directly from this email?
>
> Easier by the patch system, and much less likely to get buried and lost
> between now and when I do the update, thanks.
>
OK, the initial patch 7547/1 was superseded by the patch 7547/2 that I have just
pushed in the patch system. I hope I have done it right.
Thanks,
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Thomas Petazzoni @ 2012-10-23 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023100333.GA24418@arwen.pp.htv.fi>
On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> > But it appears that shmobile prefer to get all resources using
> > bus notifiers.
> >
> > So we need to form some kind of consensus ... or live with
> > the fact that different systems do it different ways. Which will
> > explode the day we need to use a driver on two systems,
> > each using the other approach :-)
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
>
> Using bus notifiers for that is quite a hack IMHO.
Agreed. Just like drivers do their ioremap, request_irq and others,
they should also request their pin resources using the pinctrl API.
Hiding this behind a bus notifier is not nice.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-23 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb+f44jw1vTYvJT0bnMOP8XQe8ztDUHiwtS2JHtPWAGXw@mail.gmail.com>
Hi,
On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >
> > On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> >
> >> > But it appears that shmobile prefer to get all resources using
> >> > bus notifiers.
> >> >
> >> > So we need to form some kind of consensus ... or live with
> >> > the fact that different systems do it different ways. Which will
> >> > explode the day we need to use a driver on two systems,
> >> > each using the other approach :-)
> >>
> >> I much prefer having drivers explicitly manage all their resources,
> >> which would mean that pinctrl calls need to be done on probe() and, if
> >> necessary, during suspend()/resume().
> >>
> >> Using bus notifiers for that is quite a hack IMHO.
> >
> > Agreed. Just like drivers do their ioremap, request_irq and others,
> > they should also request their pin resources using the pinctrl API.
> > Hiding this behind a bus notifier is not nice.
>
> So the biggest implementation of the notifier approach to resource
> handling is the SH clock thing:
> drivers/base/power/clock_ops.c
that's different right ? It's just creating the list of clocks, device
drivers still have to call pm_clk_add().
That's ok, I guess, otherwise all struct device would allocate memory
which hardly ever used (so far).
--
balbi
-------------- 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/20121023/73258827/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-23 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023122312.56b23e1c@skate>
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
>
>> > But it appears that shmobile prefer to get all resources using
>> > bus notifiers.
>> >
>> > So we need to form some kind of consensus ... or live with
>> > the fact that different systems do it different ways. Which will
>> > explode the day we need to use a driver on two systems,
>> > each using the other approach :-)
>>
>> I much prefer having drivers explicitly manage all their resources,
>> which would mean that pinctrl calls need to be done on probe() and, if
>> necessary, during suspend()/resume().
>>
>> Using bus notifiers for that is quite a hack IMHO.
>
> Agreed. Just like drivers do their ioremap, request_irq and others,
> they should also request their pin resources using the pinctrl API.
> Hiding this behind a bus notifier is not nice.
So the biggest implementation of the notifier approach to resource
handling is the SH clock thing:
drivers/base/power/clock_ops.c
It's made to be generic but AFAICT only SH is using this.
So according to that paradigm most device resources should
be handled that way if I understand correctly the basic idea.
So let's get Rafael, Paul and Magnus in here to beat us up
a bit :-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Remove wrong I2S0 clock from peril clock
From: Kukjin Kim @ 2012-10-23 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016501cda4fa$caa62dc0$5ff28940$@com>
Sangbeom Kim wrote:
>
> On Friday, Oct 05, 2012 at 4:37 PM, Sangsu Park wrote:
> > Remove I2S0 clk from peril since peril clock doesn't have I2S0 clk for
> EXYNOS4.
> > Audio Subsystem block has I2S0 clk.
> >
> > Signed-off-by: Sangsu Park <sangsu4u.park@samsung.com>
>
> Peril control bit 19 is reserved.
>
> Acked-by: Sangbeom Kim <sbkim73@samsung.com>
>
Applied.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Ulf Hansson @ 2012-10-23 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349452272-4002-2-git-send-email-ulf.hansson@stericsson.com>
It seems like this patch did not get applied together with:
[PATCH 1/2] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
The problem was likely my fault, since there were a lot of resends.
Anyway, it should still be possible to apply.
Kind regards
Ulf Hansson
On 5 October 2012 17:51, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99.
>
> This patch introduced runtime PM issues and is not needed at all.
> Thus we should revert it.
>
> Conflicts:
>
> drivers/spi/spi-pl022.c
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/spi/spi-pl022.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
> index 5cf0643..a1db91a 100644
> --- a/drivers/spi/spi-pl022.c
> +++ b/drivers/spi/spi-pl022.c
> @@ -2186,9 +2186,6 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
> printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
> adev->res.start, pl022->virtbase);
>
> - pm_runtime_enable(dev);
> - pm_runtime_resume(dev);
> -
> pl022->clk = devm_clk_get(&adev->dev, NULL);
> if (IS_ERR(pl022->clk)) {
> status = PTR_ERR(pl022->clk);
> @@ -2293,7 +2290,6 @@ pl022_remove(struct amba_device *adev)
>
> clk_disable(pl022->clk);
> clk_unprepare(pl022->clk);
> - pm_runtime_disable(&adev->dev);
> amba_release_regions(adev);
> tasklet_disable(&pl022->pump_transfers);
> spi_unregister_master(pl022->master);
> --
> 1.7.10
>
^ permalink raw reply
* i.MX28 die temperature
From: Marek Vasut @ 2012-10-23 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81D7F19D-A9F8-4022-81F0-B8A836F7F087@turczak.de>
Dear Peter Turczak,
> Hi Marek,
>
> On Oct 23, 2012, at 10:52 AM, Marek Vasut wrote:
> > We have some basic LRADC driver in upstream already, you should use that.
> >
> > See drivers/staging/iio/adc/mxs-lradc.c
>
> Thanks for the heads-up.
> I was referring to this driver (pulled from linus' 3.7rc), it does not
> currently seem to have a consumer api for use within other kernel modules.
> Maybe I'm just heading the wrong way now...
Ah yes, it doesn't ... feel free to implement it. It can -- though -- read the
CPU die temperature, just sample those two channels, substract one from another
and multiply by the coeficient ... you'll find that in the datasheet.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] ARM: at91: dt: evk-pro3: enable uart0 and uart2
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-23 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350986416-16246-1-git-send-email-fabio.porcedda@gmail.com>
Hi,
You will have to wait a few I prepare a patch series for pinctrl
so most of the current drivers will support pinctrl and requere it
this will availabe rc3 or rc4 max
then I will merge more update and boards
Best Regards,
J.
On 12:00 Tue 23 Oct , Fabio Porcedda wrote:
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
> arch/arm/boot/dts/evk-pro3.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/evk-pro3.dts
> index ce959ee..96e50f5 100644
> --- a/arch/arm/boot/dts/evk-pro3.dts
> +++ b/arch/arm/boot/dts/evk-pro3.dts
> @@ -22,6 +22,14 @@
> status = "okay";
> };
>
> + usart0: serial at fffb0000 {
> + status = "okay";
> + };
> +
> + usart2: serial at fffb8000 {
> + status = "okay";
> + };
> +
> usb1: gadget at fffa4000 {
> atmel,vbus-gpio = <&pioC 5 0>;
> status = "okay";
> --
> 1.7.11.3
>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-23 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZhUwMTg0suqbZiukN7Se6fzdYP3-0Dspm9WF6qZniNVQ@mail.gmail.com>
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock thing:
> >> drivers/base/power/clock_ops.c
> >
> > that's different right ? It's just creating the list of clocks, device
> > drivers still have to call pm_clk_add().
> >
> > That's ok, I guess, otherwise all struct device would allocate memory
> > which hardly ever used (so far).
>
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in <linux/pinctrl/pinctrl-state.h>
> then the PM core can help out in keeping track of the pins
> and states, and the driver will just tell the PM core what
> to do and when.
>
> Would this fit the bill for everyone's code consolidation needs?
> It would sure work for us...
>
> It however require that no custom states are used and that we
> keep to the state semantics I just happen to think is most
> common.
>From a quick read, it looks ok. I guess problems will only how up when
we actually end up with a silicon errata or something similar which
mandates that we change pin's state at a particular location. Not sure
if we have those yet.
--
balbi
-------------- 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/20121023/371d0eb0/attachment-0001.sig>
^ permalink raw reply
* [PATCH 5/5] arm: mvebu: Added SMP support for Armada XP
From: Gregory CLEMENT @ 2012-10-23 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023093029.GY11837@lunn.ch>
On 10/23/2012 11:30 AM, Andrew Lunn wrote:
> On Tue, Oct 23, 2012 at 11:11:53AM +0200, Gregory CLEMENT wrote:
>> On 10/22/2012 08:45 PM, Andrew Lunn wrote:
>>> Hi Gregory
>>>
>>>> +void __init set_secondary_cpus_clock(void)
>>>> +{
>>>> + int cpu;
>>>> + unsigned long rate;
>>>> + struct clk *cpu_clk = NULL;
>>>> + struct device_node *np = NULL;
>>>> +
>>>> + cpu = smp_processor_id();
>>>> + np = of_find_node_by_type(np, "cpu");
>>>> + np = NULL;
>>>> + while ((np = of_find_node_by_type(np, "cpu"))) {
>>>> + const u32 *reg;
>>>> + int len;
>>>> + reg = of_get_property(np, "reg", &len);
>>>> + if (!reg || len != 4) {
>>>> + pr_err("%s missing reg property\n", np->full_name);
>>>> + continue;
>>>> + }
>>>> + if (be32_to_cpup(reg) == cpu) {
>>>> + cpu_clk = of_clk_get(np, 0);
>>>> + break;
>>>> + }
>>>> + }
>>>> + WARN_ON(IS_ERR(cpu_clk));
>>>> + rate = clk_get_rate(cpu_clk);
>>>> +
>>>> + /* set all the other CPU clk to the same rate than the boot CPU */
>>>> + np = NULL;
>>>> + while ((np = of_find_node_by_type(np, "cpu"))) {
>>>> + const u32 *reg;
>>>> + int len;
>>>> + reg = of_get_property(np, "reg", &len);
>>>> + if (!reg || len != 4) {
>>>> + pr_err("%s missing reg property\n", np->full_name);
>>>> + continue;
>>>> + }
>>>> + if (be32_to_cpup(reg) != cpu) {
>>>> + cpu_clk = of_clk_get(np, 0);
>>>> + clk_set_rate(cpu_clk, rate);
>>>> + }
>>>
>>> Maybe its hiding somewhere, but where is the clk_prepare_enable() for
>>> this cpu_clk clock?
>>>
>>
>> Well the clocks are always enable. In the clock framework, the cpu clocks
>> don't provide an enable function.
>
> Is it possible in the hardware to disable them? Turning them off might
> save some power. If these chips end up in some data center server, it
> might be that CPU hotplugging is used.
Well I didn't find anything about it. You can power off a CPU using the
PMSU but not the clock itself. I guess that once you have power off the
CPU the clock will be turned off as well.
>
>> But maybe it is cleaner to call clk_prepare_enable() even if it does
>> nothing except update the usage count.
>
> You also have to watch out for the late_initcall which will disable
> all clocks which are running but nobody has claimed. This will become
> an issue if you do have enable/disable function in later versions of
> the clock functions.
I don't think there will be enable/disable functions for the family
clock currently used (armada-xp-cpu-clockctrl). But in future if a new
version of mvebu SoC will use a new clock family which will have these
functions, then it will be an issue. So to be future proof I will ad
this call in the next version of the patch set.
>
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-23 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023102903.GA24820@arwen.pp.htv.fi>
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>> So the biggest implementation of the notifier approach to resource
>> handling is the SH clock thing:
>> drivers/base/power/clock_ops.c
>
> that's different right ? It's just creating the list of clocks, device
> drivers still have to call pm_clk_add().
>
> That's ok, I guess, otherwise all struct device would allocate memory
> which hardly ever used (so far).
Hm so I have had this idea of runtime PM core helping out
with pins, so I could add something like
pm_pins_fetch()
pm_pins_default()
pm_pins_idle()
pm_pins_sleep()
So if one is using the pin states defined in <linux/pinctrl/pinctrl-state.h>
then the PM core can help out in keeping track of the pins
and states, and the driver will just tell the PM core what
to do and when.
Would this fit the bill for everyone's code consolidation needs?
It would sure work for us...
It however require that no custom states are used and that we
keep to the state semantics I just happen to think is most
common.
Yours,
Linus Walleij
^ permalink raw reply
* IMX breaking Versatile Express build
From: Shawn Guo @ 2012-10-23 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023090805.GQ21164@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 10:08:05AM +0100, Russell King - ARM Linux wrote:
> The latest Versatile Express specific build is failing due to:
>
> arch/arm/mach-imx/built-in.o: In function `imx_cpu_die':
> platform-imx-dma.c:(.text+0x1624): undefined reference to `imx_enable_cpu'
> arch/arm/mach-imx/built-in.o: In function `imx_boot_secondary':
> platform-imx-dma.c:(.cpuinit.text+0x14): undefined reference to `imx_set_cpu_jump'
> platform-imx-dma.c:(.cpuinit.text+0x20): undefined reference to `imx_enable_cpu'
>
We have a fix [1] for that waiting for arm-soc folks to pick up.
Shawn
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/194310
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Mark Brown @ 2012-10-23 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqfE0u2CPzFKeHBE1LMtuetWabR94KuASPNhw4StDCfjw@mail.gmail.com>
On Tue, Oct 23, 2012 at 12:31:06PM +0200, Ulf Hansson wrote:
> It seems like this patch did not get applied together with:
> [PATCH 1/2] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
>
> The problem was likely my fault, since there were a lot of resends.
> Anyway, it should still be possible to apply.
I *really* should not need to remind you to:
- Not top post
- Send patches in a form which can be applied if you want them applying
-------------- 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/20121023/977c8645/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Thomas Petazzoni @ 2012-10-23 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZhUwMTg0suqbZiukN7Se6fzdYP3-0Dspm9WF6qZniNVQ@mail.gmail.com>
On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote:
> Hm so I have had this idea of runtime PM core helping out
> with pins, so I could add something like
>
> pm_pins_fetch()
> pm_pins_default()
> pm_pins_idle()
> pm_pins_sleep()
>
> So if one is using the pin states defined in
> <linux/pinctrl/pinctrl-state.h> then the PM core can help out in
> keeping track of the pins and states, and the driver will just tell
> the PM core what to do and when.
>
> Would this fit the bill for everyone's code consolidation needs?
> It would sure work for us...
That surely would work but is kind of non-obvious when reading a
driver's code: that's the problem with bus notifier, they do things a
bit "behind your back" without you noticing. Having the driver request
its own pinctrl state, and switch between states upon suspend/resume is
a lot more explicit, IMO.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
From: Russell King - ARM Linux @ 2012-10-23 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023111019.GV4477@opensource.wolfsonmicro.com>
On Tue, Oct 23, 2012 at 12:10:19PM +0100, Mark Brown wrote:
> On Tue, Oct 23, 2012 at 12:31:06PM +0200, Ulf Hansson wrote:
> > It seems like this patch did not get applied together with:
> > [PATCH 1/2] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
> >
> > The problem was likely my fault, since there were a lot of resends.
> > Anyway, it should still be possible to apply.
>
> I *really* should not need to remind you to:
>
> - Not top post
> - Send patches in a form which can be applied if you want them applying
How about actually applying the damned patch from the two-part patch set,
rather than only the first, both of which has been around for almost a
month now, and fixes what should never have gone into mainline in the
first place?
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Jason Cooper @ 2012-10-23 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023104534.1d4ff689@skate>
On Tue, Oct 23, 2012 at 10:45:34AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Tue, 23 Oct 2012 10:42:41 +0200, Andrew Lunn wrote:
> > > diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> > > index 49d7915..cd2717b 100644
> > > --- a/arch/arm/mach-mvebu/armada-370-xp.c
> > > +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> > > @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
> > > static const char * const armada_370_xp_dt_board_dt_compat[] = {
> > > "marvell,a370-db",
> > > "marvell,axp-db",
> > > + "plathome,openblocks-ax3",
> > > NULL,
> > > };
> >
> > Hi Thomas
> >
> > You will get less merge conflicts with new boards if you keep this
> > list sorted.
>
> Hum, right, but isn't "plathome" after "marvell" when sorted
> alphabetically? Or maybe I don't get which kind of sorting you are
> referring to?
No, no, no. marvell, /then/ NULL, /then/ plathome. ;-) Right, Andrew?
thx,
Jason.
^ permalink raw reply
* [PATCH v2] ASoC: Samsung: Update Kconfig for Exynos5250 and Exynos4412
From: Kukjin Kim @ 2012-10-23 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50658325.8050704@linaro.org>
Tushar Behera wrote:
>
> On 09/28/2012 03:23 PM, Sangsu Park wrote:
> >
> > On Thu, Sep 27, 2012 at 07:30 PM, Padmavathi Venna wrote:
> >
[...]
> >> @@ -63,7 +63,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
> >>
> >> config SND_SOC_SAMSUNG_SMDK_WM8994
> >> tristate "SoC I2S Audio support for WM8994 on SMDK"
> >> - depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 ||
> >> MACH_SMDK4212)
> >> + depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 ||
> >> MACH_SMDK4212 || MACH_SMDK4412 || MACH_EXYNOS5_DT)
> >> depends on I2C=y && GENERIC_HARDIRQS
> >> select MFD_WM8994
> >> select SND_SOC_WM8994
> >
> > I'm not sure about this since MACH_EXYNOS5_DT can have others instead of
> SMDK.
> >
>
> But there is no other way we can differentiate between two EXYNOS5_DT
> based boards in the kernel. So, support for all possible codecs and
> sound-cards should be enabled in the kernel. The instantiation of the
> drivers should depend on the device-tree entries.
>
Hmm...any idea on this?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
From: Marek Szyprowski @ 2012-10-23 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350909843-5273-1-git-send-email-ming.lei@canonical.com>
Hello,
On 10/22/2012 2:44 PM, Ming Lei wrote:
> Without the patch, kind of below warning will be dumped if DMA-API
> debug is enabled:
>
> [ 11.069763] ------------[ cut here ]------------
> [ 11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
> [ 11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
> check map error[device address=0x0000000
> 0adb78e80] [size=8 bytes] [mapped as single]
> [ 11.095611] Modules linked in:
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Thanks for the patch, I've applied it to my kernel tree.
> ...
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ 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