* [RFC PATCH 09/15] ARM: uncompress: Introduce ucuart as low-level serial port driver
From: Russell King - ARM Linux @ 2011-10-24 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319404245-12740-9-git-send-email-zoss@devai.org>
On Sun, Oct 23, 2011 at 11:10:39PM +0200, Zoltan Devai wrote:
> +struct uncompress_uart {
> + void __iomem *base;
> + int reg_shift;
> + enum ucuart_iotypes iotype;
> + int tx_regoff;
> + int txfree_regoff;
> + int txfree_mask;
> + int txfree_val;
> + int flush_regoff;
> + int flush_mask;
> + int flush_val;
The values and masks should be unsigned.
> +};
> +
> +void ucuart_init(int base, int regshift, enum ucuart_iotypes iotype,
> + int tx_regoff, int txfree_regoff, int txfree_mask,
> + int txfree_val, int flush_regoff, int flush_mask,
> + int flush_val);
Ditto.
> +#include <linux/io.h>
I don't like this - this is *not* part of the kernel, it's part of a
separate execution environment which may not contain everything required
for a functional macros in this header file.
^ permalink raw reply
* Re: [PATCH 0/2] MMC: disable multiblock reads on controllers that don't support them
From: Chris Ball @ 2011-10-24 9:27 UTC (permalink / raw)
To: Paul Walmsley; +Cc: linux-omap, linux-mmc, linux-arm-kernel, sakoman, dhylands
In-Reply-To: <20111006205002.7083.94088.stgit@dusk>
Hi Paul,
On Thu, Oct 06 2011, Paul Walmsley wrote:
> Some MMC controller instances integrated on older OMAP34xx/35xx chips
> don't work correctly with multiple-block reads, due to a hardware bug.
> This series fixes the problem by adding an MMC capability flag for this
> case and making the appropriate changes to the MMC core code and OMAP HSMMC
> driver to support this.
>
> Once this series is merged, a subsequent patch will be needed by us OMAP
> folks to pass the appropriate device data via hwmod - this will be posted
> separately.
Thanks, both pushed to mmc-next for 3.2.
We've run out of MMC caps nad moved onto CAPS2, so I modified these patches
to define and test MMC_CAP2_NO_MULTI_READ instead of MMC_CAP_NO_MULTI_READ:
http://dev.laptop.org/git/users/cjb/mmc/commit/?h=mmc-next&id=a4b35b6acf2e9edc52132d34015f0a90b02e2df2
http://dev.laptop.org/git/users/cjb/mmc/commit/?h=mmc-next&id=6d621423128909f09072835445ce36dd357a758a
(This shouldn't affect your hwmod patch, since that just uses an
OMAP-internal flag.)
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH 0/2] MMC: disable multiblock reads on controllers that don't support them
From: Chris Ball @ 2011-10-24 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006205002.7083.94088.stgit@dusk>
Hi Paul,
On Thu, Oct 06 2011, Paul Walmsley wrote:
> Some MMC controller instances integrated on older OMAP34xx/35xx chips
> don't work correctly with multiple-block reads, due to a hardware bug.
> This series fixes the problem by adding an MMC capability flag for this
> case and making the appropriate changes to the MMC core code and OMAP HSMMC
> driver to support this.
>
> Once this series is merged, a subsequent patch will be needed by us OMAP
> folks to pass the appropriate device data via hwmod - this will be posted
> separately.
Thanks, both pushed to mmc-next for 3.2.
We've run out of MMC caps nad moved onto CAPS2, so I modified these patches
to define and test MMC_CAP2_NO_MULTI_READ instead of MMC_CAP_NO_MULTI_READ:
http://dev.laptop.org/git/users/cjb/mmc/commit/?h=mmc-next&id=a4b35b6acf2e9edc52132d34015f0a90b02e2df2
http://dev.laptop.org/git/users/cjb/mmc/commit/?h=mmc-next&id=6d621423128909f09072835445ce36dd357a758a
(This shouldn't affect your hwmod patch, since that just uses an
OMAP-internal flag.)
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH RFC V2 2/5] debugfs: Renaming of xen functions and change unsigned to u32
From: Raghavendra K T @ 2011-10-24 9:28 UTC (permalink / raw)
To: Greg KH
Cc: Raghavendra K T, KVM, Konrad Rzeszutek Wilk, Sedat Dilek,
Virtualization, Jeremy Fitzhardinge, x86, H. Peter Anvin,
Dave Jiang, Thomas Gleixner, Stefano Stabellini, Gleb Natapov,
Yinghai Lu, Marcelo Tosatti, Ingo Molnar, Avi Kivity,
Rik van Riel, Xen, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra
In-Reply-To: <20111023221920.GA591@suse.de>
On 10/24/2011 03:49 AM, Greg KH wrote:
> On Mon, Oct 24, 2011 at 12:34:59AM +0530, Raghavendra K T wrote:
>> Renaming of xen functions and change unsigned to u32.
>
> Why not just rename when you move the functions? Why the extra step?
>
Intention was only clarity. Yes, if this patch is an overhead, I 'll
combine both the patches.
> greg k-h
>
^ permalink raw reply
* Re: Sysprof build error
From: Jack Mitchell @ 2011-10-24 9:28 UTC (permalink / raw)
Cc: yocto@yoctoproject.org
In-Reply-To: <CAMKF1spiM4Hrz=GWBK=MF3JHhKkLy55vX8HKsu3cFdo7+P9d7A@mail.gmail.com>
On 20/10/2011 22:10, Khem Raj wrote:
> On Thu, Oct 20, 2011 at 6:45 AM, Jack Mitchell<ml@communistcode.co.uk> wrote:
>> I have tried cleaning and recompiling glib-2.0 due to this error:
>>
>> |
>> mnt/yocto/poky/qemuarm-toolchain/tmp/sysroots/qemuarm/usr/lib/libgtk-x11-2.0.so:
>> undefined reference to `g_datalist_get_data'
>>
>> Which I believe is glib related, however this might not be the fundamental
>> error?
>>
> This means you need to rebuild glib-2.0 along with libgtk-x11
> bitbake -ccleansstate glib-2.0
> bitbake sysprof
This was my first point of call, which didn't fix it. I re-build with a
fresh build directory and it built fine.
^ permalink raw reply
* [RFC PATCH 13/15] ARM: uncompress.h: Cleanup header guards and banners
From: Russell King - ARM Linux @ 2011-10-24 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319404245-12740-13-git-send-email-zoss@devai.org>
On Sun, Oct 23, 2011 at 11:10:43PM +0200, Zoltan Devai wrote:
> Bring some standard into the files:
> - uncompress.h should only be included once, don't hide an
> error with the header guards
> - If the copyright banner is longer than the real content,
> or the file has been mostly rewritten, just stick
> a short-form GPl notice on top
This changes the license terms on these files, some of them are GPL2+
and you're changing them to be GPL2. You don't have the right to make
that change.
^ permalink raw reply
* Re: [PATCH RFC V2 1/5] debugfs: Add support to print u32 array in debugfs
From: Raghavendra K T @ 2011-10-24 9:30 UTC (permalink / raw)
To: Greg KH
Cc: Raghavendra K T, Virtualization, Gleb Natapov, H. Peter Anvin,
Jeremy Fitzhardinge, x86, KVM, Dave Jiang, Thomas Gleixner,
Stefano Stabellini, LKML, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Avi Kivity, Rik van Riel, Xen,
Konrad Rzeszutek Wilk, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra
In-Reply-To: <20111023222012.GB591@suse.de>
On 10/24/2011 03:50 AM, Greg KH wrote:
> On Mon, Oct 24, 2011 at 12:34:04AM +0530, Raghavendra K T wrote:
>> Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
>> to make the code common for other users as well.
>
> You forgot the kerneldoc for the function explaining what it is and how
> to use it, and the EXPORT_SYMBOL_GPL() marking for the global function
> as that's the only way it will be able to be used, right?
>
Greg right. Thanks for finding this. I 'll update the patch for that.
> thanks,
>
> greg k-h
>
^ permalink raw reply
* [RFC PATCH 14/15] ARM: uncompress: Get decompress UART info from DT
From: Russell King - ARM Linux @ 2011-10-24 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319404245-12740-14-git-send-email-zoss@devai.org>
On Sun, Oct 23, 2011 at 11:10:44PM +0200, Zoltan Devai wrote:
> Allow the static decompress UART setup in uncompress.h
> files to be overridden with an ucuart description in DT.
>
> At a later stage, this may also allow to skip the
> inclusion of uncompress.h files on arches which are DT-only,
> to get rid of these files completely.
This needs to be reviewed by DT people.
^ permalink raw reply
* [U-Boot] [PATCH] Fix compile issue in arch/arm/lib/board.c
From: Marek Vasut @ 2011-10-24 9:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA52F0C.3090609@denx.de>
On Monday, October 24, 2011 11:25:32 AM Heiko Schocher wrote:
> Hello Marek,
>
> Marek Vasut wrote:
> > The commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 breaks the build of
> > U-Boot if CONFIG_CMD_NET is enabled.
> >
> > arm: Use getenv_ulong() in place of getenv(), strtoul
> >
> > This changes the board code to use the new getenv_ulong() function.
> >
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> > ---
> >
> > arch/arm/lib/board.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> > index c764844..558e973 100644
> > --- a/arch/arm/lib/board.c
> > +++ b/arch/arm/lib/board.c
> > @@ -566,7 +566,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
> >
> > /* Initialize from environment */
> > load_addr = getenv_ulong("loadaddr", 16, load_addr);
> >
> > #if defined(CONFIG_CMD_NET)
> >
> > - s = getenv("bootfile");
> > + char *s = getenv("bootfile");
>
> Did you compiled this? I think, this should generate a compiler warning.
>
> > if (s != NULL)
> >
> > copy_filename(BootFile, s, sizeof(BootFile));
> >
> > #endif
>
> bye,
> Heiko
Hey Heiko,
I did and it does not. I found that on a phycore pcm037 with ELDK5. But I just
replied your patch should be used ;-)
Cheers
^ permalink raw reply
* Re: [PATCH 5/6] xen/netback: Enable netback on HVM guests
From: Ian Campbell @ 2011-10-24 9:31 UTC (permalink / raw)
To: Daniel De Graaf, David Miller
Cc: konrad.wilk@oracle.com, David Vrabel,
xen-devel@lists.xensource.com, netdev
In-Reply-To: <1319124957-32269-6-git-send-email-dgdegra@tycho.nsa.gov>
On Thu, 2011-10-20 at 16:35 +0100, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Normally netback patches would go in via the networking subsystem
maintainer's tree but since this depends on core Xen patches from this
series and is unlikely to conflict with anything in the net-next tree I
suspect it would make more sense for Konrad to take this one.
David (Miller) does that work for you?
Ian.
> ---
> drivers/net/xen-netback/netback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 3af2924..9d80f99 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1626,7 +1626,7 @@ static int __init netback_init(void)
> int rc = 0;
> int group;
>
> - if (!xen_pv_domain())
> + if (!xen_domain())
> return -ENODEV;
>
> xen_netbk_group_nr = num_online_cpus();
^ permalink raw reply
* Re: [PATCH 5/6] xen/netback: Enable netback on HVM guests
From: Ian Campbell @ 2011-10-24 9:31 UTC (permalink / raw)
To: Daniel De Graaf, David Miller
Cc: konrad.wilk@oracle.com, David Vrabel,
xen-devel@lists.xensource.com, netdev
In-Reply-To: <1319124957-32269-6-git-send-email-dgdegra@tycho.nsa.gov>
On Thu, 2011-10-20 at 16:35 +0100, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Normally netback patches would go in via the networking subsystem
maintainer's tree but since this depends on core Xen patches from this
series and is unlikely to conflict with anything in the net-next tree I
suspect it would make more sense for Konrad to take this one.
David (Miller) does that work for you?
Ian.
> ---
> drivers/net/xen-netback/netback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 3af2924..9d80f99 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1626,7 +1626,7 @@ static int __init netback_init(void)
> int rc = 0;
> int group;
>
> - if (!xen_pv_domain())
> + if (!xen_domain())
> return -ENODEV;
>
> xen_netbk_group_nr = num_online_cpus();
^ permalink raw reply
* [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes
From: Detlev Zundel @ 2011-10-24 9:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CANJuy2LDoPtHC_37=rkR3pvHmPFJvUnsM+==YxgaDpVoo5sT1A@mail.gmail.com>
Hi Che-liang,
> I am working on an open source secure bootloader based on U-Boot.
> Mostly I wrote boot logic (by boot logic I mean prompting user and
> listing available devices sort of things). If you see U-Boot as a
> platform, you can think of my project as an application running on top
> of U-Boot, except that my application is statically linked with
> U-Boot.
Usually the (old or new) API is used to separate the application from
the GPLed U-Boot codebase to allow for proprietary applications. If you
plan to link your application statically to U-Boot anyway, then I think
that using the (external) API is not a good way to move forward.
> The boot logic is running on ARM and x86. Through the project I have
> learned that certain APIs would be helpful, such as enumerating all
> available block device and drawing bitmaps on screen regardless of
> which driver (video or LCD) you are using.
Yes, I think what you actually are looking for is a proper device model
in U-Boot. Actually we are in dire need for something like this in the
whole of U-Boots codebase and we talk about it for a very long time (see
for example [1]). This would ease progress in multiple
areas, where currently we hack around this. See for example the
SERIAL_MULTI code base or NET_MULTI. Both are isolated solutions for
the same problem. As you note, video and block devices will also
profit - USB will be another instance.
> It was probably a misleading finding when I searched the code base: I
> saw only the external apps API implemented an API for enumerating
> available block device. So I thought improving the external apps API
> was the right place to go.
>
> Alternatively (if not go the external apps API), we could have like
> common/cmd_enum_block_dev.c that does what I am planning to do, and I
> am happy to do this. What do you think?
I think we should aim at a pretty generic device interface. Currently I
would think that this also needs to fit into the "configure U-Boot
through the device tree" topic. The one will profit from the other.
As far as I know, Marek (on CC) is working towards this device tree
model also. Coordinating the efforts will be a good thing.
Thanks!
Detlev
--
Perfecting oneself is as much unlearning as it is learning.
-- Edsger Dijkstra
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Kevin Wolf @ 2011-10-24 9:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA52F2E.4000302@redhat.com>
Am 24.10.2011 11:26, schrieb Paolo Bonzini:
> On 10/24/2011 10:54 AM, Kevin Wolf wrote:
>>> I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in
>>> the generic code sounds like a layering violation. Perhaps what you're
>>> after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync? Then
>>> BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only
>>> inhibit the latter.
>>
>> Why? All other cache related BDRV_O_* flags are interpreted by the block
>> drivers, so why should BDRV_O_NO_FLUSH be special?
>
> You're changing the API and asking for possibly non-trivial changes in
> all protocol drivers, in order to accomodate semantics that all format
> drivers potentially could desire. So I wonder if the problem is simply
> that the current API is not expressive enough.
Can you think of any cases where a caller would want to invoke
bdrv_flush, but not bdrv_fsync? (The other way round it makes even less
sense)
Kevin
^ permalink raw reply
* Re: [PATCH RFC V2 5/5] kvm guest : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Raghavendra K T @ 2011-10-24 9:33 UTC (permalink / raw)
To: Sasha Levin
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Yinghai Lu, Sedat Dilek,
Ingo Molnar, Marcelo Tosatti, Xen, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra <peter
In-Reply-To: <1319450514.5660.7.camel@lappy>
On 10/24/2011 03:31 PM, Sasha Levin wrote:
> On Mon, 2011-10-24 at 00:37 +0530, Raghavendra K T wrote:
>> +#else /* CONFIG_PARAVIRT_SPINLOCKS */
>> +#define kvm_guest_early_init() do { } while (0)
>
> This should be defined as an empty function.
>
Yes Agree, I 'll change to an empty function.
- Raghu
^ permalink raw reply
* Re: [PATCH RFC V2 5/5] kvm guest : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Raghavendra K T @ 2011-10-24 9:33 UTC (permalink / raw)
To: Sasha Levin
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Yinghai Lu, Sedat Dilek,
Ingo Molnar, Marcelo Tosatti, Xen, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra <peter>
In-Reply-To: <1319450514.5660.7.camel@lappy>
On 10/24/2011 03:31 PM, Sasha Levin wrote:
> On Mon, 2011-10-24 at 00:37 +0530, Raghavendra K T wrote:
>> +#else /* CONFIG_PARAVIRT_SPINLOCKS */
>> +#define kvm_guest_early_init() do { } while (0)
>
> This should be defined as an empty function.
>
Yes Agree, I 'll change to an empty function.
- Raghu
^ permalink raw reply
* Re: [PATCH RFC V2 5/5] kvm guest : pv-ticketlocks support for linux guests running on KVM hypervisor
From: Raghavendra K T @ 2011-10-24 9:33 UTC (permalink / raw)
To: Sasha Levin
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Yinghai Lu, Sedat Dilek,
Ingo Molnar, Marcelo Tosatti, Xen, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra
In-Reply-To: <1319450514.5660.7.camel@lappy>
On 10/24/2011 03:31 PM, Sasha Levin wrote:
> On Mon, 2011-10-24 at 00:37 +0530, Raghavendra K T wrote:
>> +#else /* CONFIG_PARAVIRT_SPINLOCKS */
>> +#define kvm_guest_early_init() do { } while (0)
>
> This should be defined as an empty function.
>
Yes Agree, I 'll change to an empty function.
- Raghu
^ permalink raw reply
* [PATCH v4 1/2] dmaengine: at_hdmac: platform data move to use .id_table
From: Grant Likely @ 2011-10-24 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7cc84d91b280c5dde075c39de4feae5a6e6603a6.1318855784.git.nicolas.ferre@atmel.com>
On Mon, Oct 17, 2011 at 02:56:40PM +0200, Nicolas Ferre wrote:
> We remove the use of platform data from DMA controller driver.
> We now use of .id_table to distinguish between compatible
> types. The two implementations allow to determine the
> number of channels and the capabilities of the controller.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/dma/at_hdmac.c | 48 ++++++++++++++++++++++++++++++++++---------
> drivers/dma/at_hdmac_regs.h | 8 +++++++
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index fcfa0a8..d1869c5 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -1175,6 +1175,18 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>
> /*-- Module Management -----------------------------------------------*/
>
> +static struct platform_device_id atdma_devtypes[] = {
> + {
> + .name = "at91sam9rl_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9RL,
> + }, {
> + .name = "at91sam9g45_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9G45,
> + }, {
> + /* sentinel */
> + }
> +};
> +
> /**
> * at_dma_off - disable DMA controller
> * @atdma: the Atmel HDAMC device
> @@ -1193,18 +1205,32 @@ static void at_dma_off(struct at_dma *atdma)
>
> static int __init at_dma_probe(struct platform_device *pdev)
> {
> - struct at_dma_platform_data *pdata;
> struct resource *io;
> struct at_dma *atdma;
> size_t size;
> int irq;
> int err;
> int i;
> + u32 nr_channels;
> + dma_cap_mask_t cap_mask = {};
> + enum atdma_devtype atdmatype;
> +
> + dma_cap_set(DMA_MEMCPY, cap_mask);
> +
> + /* get DMA parameters from controller type */
> + atdmatype = platform_get_device_id(pdev)->driver_data;
>
> - /* get DMA Controller parameters from platform */
> - pdata = pdev->dev.platform_data;
> - if (!pdata || pdata->nr_channels > AT_DMA_MAX_NR_CHANNELS)
> + switch (atdmatype) {
> + case ATDMA_DEVTYPE_SAM9RL:
> + nr_channels = 2;
> + break;
> + case ATDMA_DEVTYPE_SAM9G45:
> + nr_channels = 8;
> + dma_cap_set(DMA_SLAVE, cap_mask);
> + break;
> + default:
> return -EINVAL;
Instead of this song and dance, why not make a configuration structure
and embed that into the platform_device_id table? Like this:
struct at_dma_platform_data at91sam9rl_config {
.nr_channels = 2;
.cap_mask = 0;
};
struct at_dma_platform_data at91samg45_config {
.nr_channels = 8;
.cap_mask = DMA_SLAVE;
};
static struct platform_device_id atdma_devtypes[] = {
{
.name = "at91sam9rl_dma",
.driver_data = (unsigned long) at91sam9rl_config,
/*
* Yes, I know, ugly cast; but one case will be needed
* regardless when the of_device_id table is added.
* It's due to the platform_device_id not using a
* void*
*/
}, {
.name = "at91sam9g45_dma",
.driver_data = (unsigned long) at91sam9g45_config,
}, {
/* sentinel */
}
};
And then the enum can be eliminated entirely.
> + }
>
> io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!io)
> @@ -1215,14 +1241,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
> return irq;
>
> size = sizeof(struct at_dma);
> - size += pdata->nr_channels * sizeof(struct at_dma_chan);
> + size += nr_channels * sizeof(struct at_dma_chan);
> atdma = kzalloc(size, GFP_KERNEL);
> if (!atdma)
> return -ENOMEM;
>
> - /* discover transaction capabilites from the platform data */
> - atdma->dma_common.cap_mask = pdata->cap_mask;
> - atdma->all_chan_mask = (1 << pdata->nr_channels) - 1;
> + /* discover transaction capabilities */
> + atdma->dma_common.cap_mask = cap_mask;
> + atdma->all_chan_mask = (1 << nr_channels) - 1;
> + atdma->devtype = atdmatype;
>
> size = resource_size(io);
> if (!request_mem_region(io->start, size, pdev->dev.driver->name)) {
> @@ -1268,7 +1295,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
>
> /* initialize channels related values */
> INIT_LIST_HEAD(&atdma->dma_common.channels);
> - for (i = 0; i < pdata->nr_channels; i++) {
> + for (i = 0; i < nr_channels; i++) {
> struct at_dma_chan *atchan = &atdma->chan[i];
>
> atchan->chan_common.device = &atdma->dma_common;
> @@ -1313,7 +1340,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel AHB DMA Controller ( %s%s), %d channels\n",
> dma_has_cap(DMA_MEMCPY, atdma->dma_common.cap_mask) ? "cpy " : "",
> dma_has_cap(DMA_SLAVE, atdma->dma_common.cap_mask) ? "slave " : "",
> - pdata->nr_channels);
> + nr_channels);
>
> dma_async_device_register(&atdma->dma_common);
>
> @@ -1495,6 +1522,7 @@ static const struct dev_pm_ops at_dma_dev_pm_ops = {
> static struct platform_driver at_dma_driver = {
> .remove = __exit_p(at_dma_remove),
> .shutdown = at_dma_shutdown,
> + .id_table = atdma_devtypes,
> .driver = {
> .name = "at_hdmac",
> .pm = &at_dma_dev_pm_ops,
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index aa4c9ae..d7d6737 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -248,9 +248,16 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
>
> /*-- Controller ------------------------------------------------------*/
>
> +enum atdma_devtype {
> + ATDMA_DEVTYPE_UNDEFINED = 0,
> + ATDMA_DEVTYPE_SAM9RL, /* compatible with SAM9RL DMA controller */
> + ATDMA_DEVTYPE_SAM9G45, /* compatible with SAM9G45 DMA controller */
> +};
> +
> /**
> * struct at_dma - internal representation of an Atmel HDMA Controller
> * @chan_common: common dmaengine dma_device object members
> + * @atdma_devtype: identifier of DMA controller compatibility
> * @ch_regs: memory mapped register base
> * @clk: dma controller clock
> * @save_imr: interrupt mask register that is saved on suspend/resume cycle
> @@ -260,6 +267,7 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
> */
> struct at_dma {
> struct dma_device dma_common;
> + enum atdma_devtype devtype;
> void __iomem *regs;
> struct clk *clk;
> u32 save_imr;
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dmaengine: at_hdmac: platform data move to use .id_table
From: Grant Likely @ 2011-10-24 9:34 UTC (permalink / raw)
To: Nicolas Ferre
Cc: vinod.koul, devicetree-discuss, linux-kernel, linux-arm-kernel
In-Reply-To: <7cc84d91b280c5dde075c39de4feae5a6e6603a6.1318855784.git.nicolas.ferre@atmel.com>
On Mon, Oct 17, 2011 at 02:56:40PM +0200, Nicolas Ferre wrote:
> We remove the use of platform data from DMA controller driver.
> We now use of .id_table to distinguish between compatible
> types. The two implementations allow to determine the
> number of channels and the capabilities of the controller.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/dma/at_hdmac.c | 48 ++++++++++++++++++++++++++++++++++---------
> drivers/dma/at_hdmac_regs.h | 8 +++++++
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index fcfa0a8..d1869c5 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -1175,6 +1175,18 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>
> /*-- Module Management -----------------------------------------------*/
>
> +static struct platform_device_id atdma_devtypes[] = {
> + {
> + .name = "at91sam9rl_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9RL,
> + }, {
> + .name = "at91sam9g45_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9G45,
> + }, {
> + /* sentinel */
> + }
> +};
> +
> /**
> * at_dma_off - disable DMA controller
> * @atdma: the Atmel HDAMC device
> @@ -1193,18 +1205,32 @@ static void at_dma_off(struct at_dma *atdma)
>
> static int __init at_dma_probe(struct platform_device *pdev)
> {
> - struct at_dma_platform_data *pdata;
> struct resource *io;
> struct at_dma *atdma;
> size_t size;
> int irq;
> int err;
> int i;
> + u32 nr_channels;
> + dma_cap_mask_t cap_mask = {};
> + enum atdma_devtype atdmatype;
> +
> + dma_cap_set(DMA_MEMCPY, cap_mask);
> +
> + /* get DMA parameters from controller type */
> + atdmatype = platform_get_device_id(pdev)->driver_data;
>
> - /* get DMA Controller parameters from platform */
> - pdata = pdev->dev.platform_data;
> - if (!pdata || pdata->nr_channels > AT_DMA_MAX_NR_CHANNELS)
> + switch (atdmatype) {
> + case ATDMA_DEVTYPE_SAM9RL:
> + nr_channels = 2;
> + break;
> + case ATDMA_DEVTYPE_SAM9G45:
> + nr_channels = 8;
> + dma_cap_set(DMA_SLAVE, cap_mask);
> + break;
> + default:
> return -EINVAL;
Instead of this song and dance, why not make a configuration structure
and embed that into the platform_device_id table? Like this:
struct at_dma_platform_data at91sam9rl_config {
.nr_channels = 2;
.cap_mask = 0;
};
struct at_dma_platform_data at91samg45_config {
.nr_channels = 8;
.cap_mask = DMA_SLAVE;
};
static struct platform_device_id atdma_devtypes[] = {
{
.name = "at91sam9rl_dma",
.driver_data = (unsigned long) at91sam9rl_config,
/*
* Yes, I know, ugly cast; but one case will be needed
* regardless when the of_device_id table is added.
* It's due to the platform_device_id not using a
* void*
*/
}, {
.name = "at91sam9g45_dma",
.driver_data = (unsigned long) at91sam9g45_config,
}, {
/* sentinel */
}
};
And then the enum can be eliminated entirely.
> + }
>
> io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!io)
> @@ -1215,14 +1241,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
> return irq;
>
> size = sizeof(struct at_dma);
> - size += pdata->nr_channels * sizeof(struct at_dma_chan);
> + size += nr_channels * sizeof(struct at_dma_chan);
> atdma = kzalloc(size, GFP_KERNEL);
> if (!atdma)
> return -ENOMEM;
>
> - /* discover transaction capabilites from the platform data */
> - atdma->dma_common.cap_mask = pdata->cap_mask;
> - atdma->all_chan_mask = (1 << pdata->nr_channels) - 1;
> + /* discover transaction capabilities */
> + atdma->dma_common.cap_mask = cap_mask;
> + atdma->all_chan_mask = (1 << nr_channels) - 1;
> + atdma->devtype = atdmatype;
>
> size = resource_size(io);
> if (!request_mem_region(io->start, size, pdev->dev.driver->name)) {
> @@ -1268,7 +1295,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
>
> /* initialize channels related values */
> INIT_LIST_HEAD(&atdma->dma_common.channels);
> - for (i = 0; i < pdata->nr_channels; i++) {
> + for (i = 0; i < nr_channels; i++) {
> struct at_dma_chan *atchan = &atdma->chan[i];
>
> atchan->chan_common.device = &atdma->dma_common;
> @@ -1313,7 +1340,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel AHB DMA Controller ( %s%s), %d channels\n",
> dma_has_cap(DMA_MEMCPY, atdma->dma_common.cap_mask) ? "cpy " : "",
> dma_has_cap(DMA_SLAVE, atdma->dma_common.cap_mask) ? "slave " : "",
> - pdata->nr_channels);
> + nr_channels);
>
> dma_async_device_register(&atdma->dma_common);
>
> @@ -1495,6 +1522,7 @@ static const struct dev_pm_ops at_dma_dev_pm_ops = {
> static struct platform_driver at_dma_driver = {
> .remove = __exit_p(at_dma_remove),
> .shutdown = at_dma_shutdown,
> + .id_table = atdma_devtypes,
> .driver = {
> .name = "at_hdmac",
> .pm = &at_dma_dev_pm_ops,
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index aa4c9ae..d7d6737 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -248,9 +248,16 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
>
> /*-- Controller ------------------------------------------------------*/
>
> +enum atdma_devtype {
> + ATDMA_DEVTYPE_UNDEFINED = 0,
> + ATDMA_DEVTYPE_SAM9RL, /* compatible with SAM9RL DMA controller */
> + ATDMA_DEVTYPE_SAM9G45, /* compatible with SAM9G45 DMA controller */
> +};
> +
> /**
> * struct at_dma - internal representation of an Atmel HDMA Controller
> * @chan_common: common dmaengine dma_device object members
> + * @atdma_devtype: identifier of DMA controller compatibility
> * @ch_regs: memory mapped register base
> * @clk: dma controller clock
> * @save_imr: interrupt mask register that is saved on suspend/resume cycle
> @@ -260,6 +267,7 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
> */
> struct at_dma {
> struct dma_device dma_common;
> + enum atdma_devtype devtype;
> void __iomem *regs;
> struct clk *clk;
> u32 save_imr;
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [PATCH 5/6] xen/netback: Enable netback on HVM guests
From: David Miller @ 2011-10-24 9:34 UTC (permalink / raw)
To: Ian.Campbell; +Cc: netdev, dgdegra, xen-devel, david.vrabel, konrad.wilk
In-Reply-To: <1319448669.3385.161.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 24 Oct 2011 10:31:08 +0100
> On Thu, 2011-10-20 at 16:35 +0100, Daniel De Graaf wrote:
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Normally netback patches would go in via the networking subsystem
> maintainer's tree but since this depends on core Xen patches from this
> series and is unlikely to conflict with anything in the net-next tree I
> suspect it would make more sense for Konrad to take this one.
>
> David (Miller) does that work for you?
Yes, it does.
^ permalink raw reply
* Re: [PATCH v4 1/2] dmaengine: at_hdmac: platform data move to use .id_table
From: Grant Likely @ 2011-10-24 9:34 UTC (permalink / raw)
To: Nicolas Ferre
Cc: vinod.koul, linux-arm-kernel, linux-kernel, robherring2,
devicetree-discuss
In-Reply-To: <7cc84d91b280c5dde075c39de4feae5a6e6603a6.1318855784.git.nicolas.ferre@atmel.com>
On Mon, Oct 17, 2011 at 02:56:40PM +0200, Nicolas Ferre wrote:
> We remove the use of platform data from DMA controller driver.
> We now use of .id_table to distinguish between compatible
> types. The two implementations allow to determine the
> number of channels and the capabilities of the controller.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/dma/at_hdmac.c | 48 ++++++++++++++++++++++++++++++++++---------
> drivers/dma/at_hdmac_regs.h | 8 +++++++
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index fcfa0a8..d1869c5 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -1175,6 +1175,18 @@ static void atc_free_chan_resources(struct dma_chan *chan)
>
> /*-- Module Management -----------------------------------------------*/
>
> +static struct platform_device_id atdma_devtypes[] = {
> + {
> + .name = "at91sam9rl_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9RL,
> + }, {
> + .name = "at91sam9g45_dma",
> + .driver_data = ATDMA_DEVTYPE_SAM9G45,
> + }, {
> + /* sentinel */
> + }
> +};
> +
> /**
> * at_dma_off - disable DMA controller
> * @atdma: the Atmel HDAMC device
> @@ -1193,18 +1205,32 @@ static void at_dma_off(struct at_dma *atdma)
>
> static int __init at_dma_probe(struct platform_device *pdev)
> {
> - struct at_dma_platform_data *pdata;
> struct resource *io;
> struct at_dma *atdma;
> size_t size;
> int irq;
> int err;
> int i;
> + u32 nr_channels;
> + dma_cap_mask_t cap_mask = {};
> + enum atdma_devtype atdmatype;
> +
> + dma_cap_set(DMA_MEMCPY, cap_mask);
> +
> + /* get DMA parameters from controller type */
> + atdmatype = platform_get_device_id(pdev)->driver_data;
>
> - /* get DMA Controller parameters from platform */
> - pdata = pdev->dev.platform_data;
> - if (!pdata || pdata->nr_channels > AT_DMA_MAX_NR_CHANNELS)
> + switch (atdmatype) {
> + case ATDMA_DEVTYPE_SAM9RL:
> + nr_channels = 2;
> + break;
> + case ATDMA_DEVTYPE_SAM9G45:
> + nr_channels = 8;
> + dma_cap_set(DMA_SLAVE, cap_mask);
> + break;
> + default:
> return -EINVAL;
Instead of this song and dance, why not make a configuration structure
and embed that into the platform_device_id table? Like this:
struct at_dma_platform_data at91sam9rl_config {
.nr_channels = 2;
.cap_mask = 0;
};
struct at_dma_platform_data at91samg45_config {
.nr_channels = 8;
.cap_mask = DMA_SLAVE;
};
static struct platform_device_id atdma_devtypes[] = {
{
.name = "at91sam9rl_dma",
.driver_data = (unsigned long) at91sam9rl_config,
/*
* Yes, I know, ugly cast; but one case will be needed
* regardless when the of_device_id table is added.
* It's due to the platform_device_id not using a
* void*
*/
}, {
.name = "at91sam9g45_dma",
.driver_data = (unsigned long) at91sam9g45_config,
}, {
/* sentinel */
}
};
And then the enum can be eliminated entirely.
> + }
>
> io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!io)
> @@ -1215,14 +1241,15 @@ static int __init at_dma_probe(struct platform_device *pdev)
> return irq;
>
> size = sizeof(struct at_dma);
> - size += pdata->nr_channels * sizeof(struct at_dma_chan);
> + size += nr_channels * sizeof(struct at_dma_chan);
> atdma = kzalloc(size, GFP_KERNEL);
> if (!atdma)
> return -ENOMEM;
>
> - /* discover transaction capabilites from the platform data */
> - atdma->dma_common.cap_mask = pdata->cap_mask;
> - atdma->all_chan_mask = (1 << pdata->nr_channels) - 1;
> + /* discover transaction capabilities */
> + atdma->dma_common.cap_mask = cap_mask;
> + atdma->all_chan_mask = (1 << nr_channels) - 1;
> + atdma->devtype = atdmatype;
>
> size = resource_size(io);
> if (!request_mem_region(io->start, size, pdev->dev.driver->name)) {
> @@ -1268,7 +1295,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
>
> /* initialize channels related values */
> INIT_LIST_HEAD(&atdma->dma_common.channels);
> - for (i = 0; i < pdata->nr_channels; i++) {
> + for (i = 0; i < nr_channels; i++) {
> struct at_dma_chan *atchan = &atdma->chan[i];
>
> atchan->chan_common.device = &atdma->dma_common;
> @@ -1313,7 +1340,7 @@ static int __init at_dma_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel AHB DMA Controller ( %s%s), %d channels\n",
> dma_has_cap(DMA_MEMCPY, atdma->dma_common.cap_mask) ? "cpy " : "",
> dma_has_cap(DMA_SLAVE, atdma->dma_common.cap_mask) ? "slave " : "",
> - pdata->nr_channels);
> + nr_channels);
>
> dma_async_device_register(&atdma->dma_common);
>
> @@ -1495,6 +1522,7 @@ static const struct dev_pm_ops at_dma_dev_pm_ops = {
> static struct platform_driver at_dma_driver = {
> .remove = __exit_p(at_dma_remove),
> .shutdown = at_dma_shutdown,
> + .id_table = atdma_devtypes,
> .driver = {
> .name = "at_hdmac",
> .pm = &at_dma_dev_pm_ops,
> diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
> index aa4c9ae..d7d6737 100644
> --- a/drivers/dma/at_hdmac_regs.h
> +++ b/drivers/dma/at_hdmac_regs.h
> @@ -248,9 +248,16 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
>
> /*-- Controller ------------------------------------------------------*/
>
> +enum atdma_devtype {
> + ATDMA_DEVTYPE_UNDEFINED = 0,
> + ATDMA_DEVTYPE_SAM9RL, /* compatible with SAM9RL DMA controller */
> + ATDMA_DEVTYPE_SAM9G45, /* compatible with SAM9G45 DMA controller */
> +};
> +
> /**
> * struct at_dma - internal representation of an Atmel HDMA Controller
> * @chan_common: common dmaengine dma_device object members
> + * @atdma_devtype: identifier of DMA controller compatibility
> * @ch_regs: memory mapped register base
> * @clk: dma controller clock
> * @save_imr: interrupt mask register that is saved on suspend/resume cycle
> @@ -260,6 +267,7 @@ static inline struct at_dma_chan *to_at_dma_chan(struct dma_chan *dchan)
> */
> struct at_dma {
> struct dma_device dma_common;
> + enum atdma_devtype devtype;
> void __iomem *regs;
> struct clk *clk;
> u32 save_imr;
> --
> 1.7.5.4
>
^ permalink raw reply
* Re: [Qemu-devel] [Spice-devel] Possible SPICE/QEMU deadlock on fast client reconnect
From: Daniel P. Berrange @ 2011-10-24 9:35 UTC (permalink / raw)
To: Yonit Halperin; +Cc: spice-devel, qemu-devel
In-Reply-To: <4EA3C457.2060500@redhat.com>
On Sun, Oct 23, 2011 at 09:37:59AM +0200, Yonit Halperin wrote:
> Hi,
>
> Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=746950 and
> https://bugs.freedesktop.org/show_bug.cgi?id=41858
> Alon's patch:
> http://lists.freedesktop.org/archives/spice-devel/2011-September
> /005369.html
> Should solve it.
Yes, testing with that patch applied resolves the deadlock I see.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 9:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Lee Jones, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Sebastian Rasmussen
In-Reply-To: <20111024090432.GA9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 10:05:30AM +0200, Ulf Hansson wrote:
>> Sebastian Rasmussen wrote:
>>> Hi!
>>>
>>>> Err, no. You're not allowed to power down the card between commands
>>>> unless the card has been removed or been has finished with.
>>>>
>>>> If you power down the card (which you _are_ doing by writing zero to
>>>> the MMCIPOWER register), then you have to do a full setup of the card
>>>> when you resume.
>>> MCIPower is according to ARM PL180 TRM signalling to an external power
>>> supply to turn on/off (MCIPWR), whether to use open-drain (MCIROD),
>>> what voltage to use (MCIVDD) and whether the card is clocked (MCICLK).
>>>
>>> According ST-Ericsson's public PL180 derivative spec[1] it seems to work
>>> roughly in same way (but renaming the register SDI_PWR and the signals
>>> SDIPWR & SDICLK). However, there is no SDIVDD as the derivative can not
>>> signal desired voltage level externally (there are no bits in SDI_PWR for this).
>>> This makes it plausible that SDIPWR may not be routed externally either.
>>> Can you verify this as there are no signal routing diagrams in the spec..?
>>>
>> The hole idea with this PM patch is to make sure the vcore regulator and
>> the clock are disabled in runtime_suspend to be able to save a huge
>> amount of current in "idle" mode.
>>
>> Disabling the vcore regulator will sooner or later (depending on your
>> regulator tree) mean that that power to the controller is actually cut,
>> which then means that all registers will be "cleared" including the
>> MCIPWR. So the actual reason for clearing the registers in the
>> runtime_suspend function is because of two reasons.
>>
>> 1. Set the controller in a known state so no "magic" things happens when
>> we are runtime suspended, for example getting an IRQ.
>>
>> 2. Save power by disabling the clock etc. The actual power to the
>> controller does not have to be cut just because we have disabled the
>> vore regulator.
>>
>> If the ARM PL180 TRM prevent us from from doing this kind of operations
>> in runtime_suspend, we must think of an alternative solution which just
>> apply for ST-Ericssons derivative of PL180. THIS IS VERY IMPORTANT to be
>> able to implement a proper power management solution.
>>
>> Please check this Russell, this is VERY IMPORTANT!
>
> I repeat: if you cut power to the card, you have to re-initialize it.
> Re-initialization takes quite a bit of time to re-detect and setup
> the card. You'd also need to re-configure things like the transfer
> mode and so forth.
Right now host->vcc (vmmc) regulator is controlling the power to card.
Not the MCIPWR register!
It is possible for ARM PL180 trm (not for STE version) to use MCIPWR to
control some external regulator. But right now, this is not used
according the code and it also feels like a very strange setup.
I would be very surprised if any hardware has this kind of setup, that
the PL180 itself controls a regulator.
>
> The other problem is if you're doing runtime-pm between commands,
> the re-initialization takes multiple commands - we don't want to be
> in the middle of a reinitialization while we're also doing something
> with runtime-pm - nested initialization would not be a nice problem
> to solve.
>
You do not have to re-init the card as long at is still powered. It is
just a matter of restoring register values. This is really quick. But at
the same time, we do not want to do it for every request thus we use
timeout of 50 ms.
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024090432.GA9893@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Mon, Oct 24, 2011 at 10:05:30AM +0200, Ulf Hansson wrote:
>> Sebastian Rasmussen wrote:
>>> Hi!
>>>
>>>> Err, no. You're not allowed to power down the card between commands
>>>> unless the card has been removed or been has finished with.
>>>>
>>>> If you power down the card (which you _are_ doing by writing zero to
>>>> the MMCIPOWER register), then you have to do a full setup of the card
>>>> when you resume.
>>> MCIPower is according to ARM PL180 TRM signalling to an external power
>>> supply to turn on/off (MCIPWR), whether to use open-drain (MCIROD),
>>> what voltage to use (MCIVDD) and whether the card is clocked (MCICLK).
>>>
>>> According ST-Ericsson's public PL180 derivative spec[1] it seems to work
>>> roughly in same way (but renaming the register SDI_PWR and the signals
>>> SDIPWR & SDICLK). However, there is no SDIVDD as the derivative can not
>>> signal desired voltage level externally (there are no bits in SDI_PWR for this).
>>> This makes it plausible that SDIPWR may not be routed externally either.
>>> Can you verify this as there are no signal routing diagrams in the spec..?
>>>
>> The hole idea with this PM patch is to make sure the vcore regulator and
>> the clock are disabled in runtime_suspend to be able to save a huge
>> amount of current in "idle" mode.
>>
>> Disabling the vcore regulator will sooner or later (depending on your
>> regulator tree) mean that that power to the controller is actually cut,
>> which then means that all registers will be "cleared" including the
>> MCIPWR. So the actual reason for clearing the registers in the
>> runtime_suspend function is because of two reasons.
>>
>> 1. Set the controller in a known state so no "magic" things happens when
>> we are runtime suspended, for example getting an IRQ.
>>
>> 2. Save power by disabling the clock etc. The actual power to the
>> controller does not have to be cut just because we have disabled the
>> vore regulator.
>>
>> If the ARM PL180 TRM prevent us from from doing this kind of operations
>> in runtime_suspend, we must think of an alternative solution which just
>> apply for ST-Ericssons derivative of PL180. THIS IS VERY IMPORTANT to be
>> able to implement a proper power management solution.
>>
>> Please check this Russell, this is VERY IMPORTANT!
>
> I repeat: if you cut power to the card, you have to re-initialize it.
> Re-initialization takes quite a bit of time to re-detect and setup
> the card. You'd also need to re-configure things like the transfer
> mode and so forth.
Right now host->vcc (vmmc) regulator is controlling the power to card.
Not the MCIPWR register!
It is possible for ARM PL180 trm (not for STE version) to use MCIPWR to
control some external regulator. But right now, this is not used
according the code and it also feels like a very strange setup.
I would be very surprised if any hardware has this kind of setup, that
the PL180 itself controls a regulator.
>
> The other problem is if you're doing runtime-pm between commands,
> the re-initialization takes multiple commands - we don't want to be
> in the middle of a reinitialization while we're also doing something
> with runtime-pm - nested initialization would not be a nice problem
> to solve.
>
You do not have to re-init the card as long at is still powered. It is
just a matter of restoring register values. This is really quick. But at
the same time, we do not want to do it for every request thus we use
timeout of 50 ms.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (sparc, ptrace trees related)
From: Stephen Rothwell @ 2011-10-24 9:36 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: David Miller, linux-next, linux-kernel, matt.fleming, tj
In-Reply-To: <20111014190950.GA10791@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
Hi Oleg,
On Fri, 14 Oct 2011 21:09:50 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 10/14, David Miller wrote:
> >
> > Now you guys are creating conflicts against those fixed up patches in
> > another non-sparc tree, and adding new kinds of build failures as
> > well.
> >
> > This doesn't work.
>
> Sorry David and Stephen.
>
> Stephen, could you please temporary remove ptrace from linux-next?
OK, I have removed it until you tell me otherwise.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Russell King - ARM Linux @ 2011-10-24 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAgDR1OT=+xgQTNwmTz=9XwzpbhjeZ6F-mxnVGhOAPSAR3JiFQ@mail.gmail.com>
On Sun, Oct 23, 2011 at 02:31:39AM +0200, Sebastian Rasmussen wrote:
> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
> this on my Snowball dev board yet.
There's also the issue that the specs call for the clock to run after
a command has completed for a certain number of cycles, and that the
clock must continue to run until the card reports not-busy after a
programming or erase cycle has completed - that can be long after the
previous command has 'completed'.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.