headers
Josh Boyer | 1 Sep 2011 02:18
Picon

Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data

On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg <at> kroah.com> wrote:
> On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
>> <-----Original Message-----
>> <From: Pratyush Anand [mailto:pratyush.anand <at> st.com]
>> <Sent: Tuesday, August 30, 2011 4:58 AM
>> <To: linux-usb <at> vger.kernel.org
>> <Cc: tmarri <at> apm.com; linuxppc-dev <at> lists.ozlabs.org; fchen <at> apm.com;
>> <mmiesfeld <at> apm.com; shiraz.hashim <at> st.com; deepak.sikri <at> st.com;
>> <vipulkumar.samar <at> st.com; rajeev-dlh.kumar <at> st.com; vipin.kumar <at> st.com;
>> <bhupesh.sharma <at> st.com; viresh.kumar <at> st.com; Amit.VIRDI <at> st.com; Pratyush
>> <Anand
>> <Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
>> <
>> <There are some DWC OTG parameters which might be passed by a platform.
>> <Declaration for structure of those parameters have been provided in this
>> <include file.
>> <
>> <Signed-off-by: Pratyush Anand <pratyush.anand <at> st.com>
>> <---
>> < include/linux/usb/dwc_otg.h |  274
>>
>> [Tirumala Marri] I am not sure how to separate your changes. But we need
>> More time as our initial patches are still pending.
>
> pending where?  Have you submitted them for inclusion?
>

13 times in fact.  Each time, more comments and fixes need.  Par for
the course with a vendor driver, but in this case Pratyush thought the
APM guys had let it die and tried to carry it forward.  I guess APM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Sep 2011 03:37
Gravatar

Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data

On Wed, Aug 31, 2011 at 08:18:12PM -0400, Josh Boyer wrote:
> On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg <at> kroah.com> wrote:
> > On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
> >> <-----Original Message-----
> >> <From: Pratyush Anand [mailto:pratyush.anand <at> st.com]
> >> <Sent: Tuesday, August 30, 2011 4:58 AM
> >> <To: linux-usb <at> vger.kernel.org
> >> <Cc: tmarri <at> apm.com; linuxppc-dev <at> lists.ozlabs.org; fchen <at> apm.com;
> >> <mmiesfeld <at> apm.com; shiraz.hashim <at> st.com; deepak.sikri <at> st.com;
> >> <vipulkumar.samar <at> st.com; rajeev-dlh.kumar <at> st.com; vipin.kumar <at> st.com;
> >> <bhupesh.sharma <at> st.com; viresh.kumar <at> st.com; Amit.VIRDI <at> st.com; Pratyush
> >> <Anand
> >> <Subject: [PATCH 02/14] dwc/otg: Structure declaration for shared data
> >> <
> >> <There are some DWC OTG parameters which might be passed by a platform.
> >> <Declaration for structure of those parameters have been provided in this
> >> <include file.
> >> <
> >> <Signed-off-by: Pratyush Anand <pratyush.anand <at> st.com>
> >> <---
> >> < include/linux/usb/dwc_otg.h |  274
> >>
> >> [Tirumala Marri] I am not sure how to separate your changes. But we need
> >> More time as our initial patches are still pending.
> >
> > pending where?  Have you submitted them for inclusion?
> >
> 
> 13 times in fact.  Each time, more comments and fixes need.  Par for
> the course with a vendor driver, but in this case Pratyush thought the
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Gibson | 1 Sep 2011 06:10
Picon

Re: VFIO v2 design plan

On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
> On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote:
> > On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote:
> > > On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote:
> > > > On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote:
[snip]
> > > > >  Once the group is viable, the user may bind the
> > > > > group to another group, retrieve the iommu fd, or retrieve device fds.
> > > > > Internally, each of these operations will result in an iommu domain
> > > > > being allocated and all of the devices attached to the domain.
> > > > > 
> > > > > The purpose of binding groups is to share the iommu domain.  Groups
> > > > > making use of incompatible iommu domains will fail to bind.  Groups
> > > > > making use of different mm's will fail to bind.  The vfio driver may
> > > > > reject some binding based on domain capabilities, but final veto power
> > > > > is left to the iommu driver[1].  If a user makes use of a group
> > > > > independently and later wishes to bind it to another group, all the
> > > > > device fds and the iommu fd must first be closed.  This prevents using a
> > > > > stale iommu fd or accessing devices while the iommu is being switched.
> > > > > Operations on any group fds of a merged group are performed globally on
> > > > > the group (ie. enumerating the devices lists all devices in the merged
> > > > > group, retrieving the iommu fd from any group fd results in the same fd,
> > > > > device fds from any group can be retrieved from any group fd[2]).
> > > > > Groups can be merged and unmerged dynamically.  Unmerging a group
> > > > > requires the device fds for the outgoing group are closed.  The iommu fd
> > > > > will remain persistent for the remaining merged group.
> > > > 
> > > > As I've said I prefer a persistent group model, rather than this
> > > > transient group model, but it's not a dealbreaker by itself.  How are
> > > > unmerges specified?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kumar Gala | 1 Sep 2011 06:42
Favicon

Re: [PATCH 3/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay


On Aug 26, 2011, at 2:55 AM, Chunhe Lan wrote:

> The mmc_delay() is a wrapper function for mdelay() and msleep().
> 
>    o mdelay() -- block the system when busy-waiting.
>    o msleep() -- suspend the currently running task to enable CPU
>                  to process other tasks, so it is non-blocking
>                  regarding the whole system.
> 
> When the desired delay time is more than a period of timer interrupt,
> just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
> CPU when busy wait.
> 
> Signed-off-by: Shengzhou Liu <b36685 <at> freescale.com>
> Signed-off-by: Chunhe Lan <Chunhe.Lan <at> freescale.com>
> Cc: Chris Ball <cjb <at> laptop.org>
> ---
> drivers/mmc/host/sdhci.c |   10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)

It might be good to either merge patch 2/3 & 3/3 or rename them since they have same commit message.

Chris,

Any comments on closing on these patches?

- k
Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Sep 2011 07:35

Re: [PATCH 2/4] dma-mapping: add get_required_mask if arch overrides default

On Wed, 2011-06-29 at 17:19 +0900, FUJITA Tomonori wrote:
> On Fri, 24 Jun 2011 12:05:23 -0700
> Nishanth Aravamudan <nacc <at> us.ibm.com> wrote:
> 
> > From: Milton Miller <miltonm <at> bga.com>
> > 
> > If an architecture sets ARCH_HAS_DMA_GET_REQUIRED_MASK and has settable
> > dma_map_ops, the required mask may change by the ops implementation.
> > For example, a system that always has an mmu inline may only require 32
> > bits while a swiotlb would desire bits to cover all of memory.
> > 
> > Therefore add the field if the architecture does not use the generic
> > definition of dma_get_required_mask. The first use will by by powerpc.
> > Note that this does add some dependency on the order in which files are
> > visible here.

 .../...

> If you add get_required_mask to dma_map_ops, we should clean up ia64
> too and implement the generic proper version in
> dma-mapping-common.h. Then we kill ARCH_HAS_DMA_GET_REQUIRED_MASK
> ifdef hack. Otherwise, I don't think it makes sense to add this to
> dma_map_ops.

In the meantime, can I have an ack so I can include this along with the
rest of Milton's patches ? It's been around for a while now :-)

I'm a bit late for producing a powerpc-next (due to travelling).

Cheers,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Benjamin Herrenschmidt | 1 Sep 2011 08:02

Re: [PATCH 3/7] serial/8250: move UPIO_TSI to powerpc

On Mon, 2011-06-27 at 23:45 +0200, Arnd Bergmann wrote:
> This iotype is only used by the legacy_serial code in powerpc, so the
> code should live there, rather than be compiled in for every 8250
> driver.

Obviously untested :-)

Misses the definition of UART_IIR etc...

I'm committing a fixed version in my tree

Cheers.
Ben.

> Signed-off-by: Arnd Bergmann <arnd <at> arndb.de>
> Cc: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
> Cc: linuxppc-dev <at> lists.ozlabs.org
> Cc: Greg Kroah-Hartman <gregkh <at> suse.de>
> Cc: linux-serial <at> vger.kernel.org
> ---
>  arch/powerpc/kernel/legacy_serial.c |   24 ++++++++++++++++++++++++
>  drivers/tty/serial/8250.c           |   23 -----------------------
>  2 files changed, 24 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index 2b97b80..b229e1e 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
>  <at>  <at>  -47,6 +47,24  <at>  <at>  static struct __initdata of_device_id legacy_serial_parents[] = {
>  static unsigned int legacy_serial_count;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kumar Gala | 1 Sep 2011 08:27

Re: [PATCH] powerpc/time: When starting the decrementer don't zero the other bits in TCR


On Aug 25, 2011, at 7:19 AM, Laurentiu Tudor wrote:

> Clearing the other TCR bits might break code that sets them (e.g. to setup
> the watchdog or fixed interval timer) before start_cpu_decrementer() gets
> called.

Can you be more specific about the case you're concerned about.  I'm not sure we want to leave the FIT enabled
if it was previously.  Watchdog I could possibly see leaving alone.
> 
> Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor <at> freescale.com>
> ---
> arch/powerpc/kernel/time.c |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 03b29a6..e8b5cdc 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
>  <at>  <at>  -721,7 +721,7  <at>  <at>  void start_cpu_decrementer(void)
> 	mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
> 
> 	/* Enable decrementer interrupt */
> -	mtspr(SPRN_TCR, TCR_DIE);
> +	mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_DIE);
> #endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */
> }
> 
> -- 
> 1.7.1
(Continue reading)

Permalink | Reply | 8 comments |
headers
Tudor Laurentiu | 1 Sep 2011 10:31
Favicon

Re: [PATCH] powerpc/time: When starting the decrementer don't zero the other bits in TCR

On 9/1/2011 9:27 AM, Kumar Gala wrote:
>
> On Aug 25, 2011, at 7:19 AM, Laurentiu Tudor wrote:
>
>> Clearing the other TCR bits might break code that sets them (e.g. to setup
>> the watchdog or fixed interval timer) before start_cpu_decrementer() gets
>> called.
>
> Can you be more specific about the case you're concerned about.  I'm not sure we want to leave the FIT enabled
if it was previously.  Watchdog I could possibly see leaving alone.

My particular case was this: I was experimenting with having the 
watchdog enabled during the boot process, in case something goes wrong 
before the normal watchdog mechanism kicks in. That didn't work without 
making this modification.
Then, thinking that having a function start_cpu_decrementer() touching 
the other timers and not only the decrementer as its name implies might 
not be good. So I submitted this patch to the public mailing list to let 
the community decide if it's useful.

>> Signed-off-by: Laurentiu Tudor<Laurentiu.Tudor <at> freescale.com>
>> ---
>> arch/powerpc/kernel/time.c |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index 03b29a6..e8b5cdc 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>>  <at>  <at>  -721,7 +721,7  <at>  <at>  void start_cpu_decrementer(void)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Arnd Bergmann | 1 Sep 2011 10:28
Picon
Gravatar

Re: [PATCH 3/7] serial/8250: move UPIO_TSI to powerpc

On Thursday 01 September 2011 16:02:06 Benjamin Herrenschmidt wrote:
> On Mon, 2011-06-27 at 23:45 +0200, Arnd Bergmann wrote:
> > This iotype is only used by the legacy_serial code in powerpc, so the
> > code should live there, rather than be compiled in for every 8250
> > driver.
> 
> Obviously untested 
> 
> Misses the definition of UART_IIR etc...
> 
> I'm committing a fixed version in my tree

Ok, thank you!

	Arnd
Permalink | Reply | 0 comments |
headers
LiuShuo | 1 Sep 2011 11:41
Favicon

Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

于 2011年08月25日 19:25, Matthieu CASTET 写道:
> Hi,
>
> LiuShuo a écrit :
>> 于 2011年08月23日 18:02, Matthieu CASTET 写道:
>>> LiuShuo a écrit :
>>>> 于 2011年08月19日 00:25, Scott Wood 写道:
>>>>> On 08/17/2011 09:33 PM, b35362 <at> freescale.com wrote:
>>>>>> From: Liu Shuo<b35362 <at> freescale.com>
>>>>>>
>>>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>>>>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>>>>> we divide a page into multi-2K pages for MTD layer driver. In that case,
>>>>>> we force to set the page size to 2K bytes. We convert the page address of
>>>>>> MTD layer driver to a real page address in flash chips and a column index
>>>>>> in fsl_elbc driver. We can issue any column address by UA instruction of
>>>>>> elbc controller.
>>>>>>
>>>>>> NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
>>>>>> the Same Page (NOP)', the flash chip which is supported by this workaround
>>>>>> have to meet below conditions.
>>>>>> 	1. page size is not greater than 4KB
>>>>>> 	2.	1) if main area and spare area have independent NOPs:
>>>>>> 			  main  area NOP    :>=3
>>>>>> 			  spare area NOP    :>=2?
>>>>> How often are the NOPs split like this?
>>>>>
>>>>>> 		2) if main area and spare area have a common NOP:
>>>>>> 			  NOP               :>=4
>>>>> This depends on how the flash is used.  If you treat it as a NOP1 flash
(Continue reading)

Permalink | Reply | 0 comments |

Gmane