headers
Grant Likely | 1 Nov 2009 02:03
Picon

Re: [PATCH] mpc52xx-psc-spi: refactor probe and remove to make use of of_register_spi_devices()

Hi Wolfram,

Thanks for this work. Comments below.

On Fri, Oct 30, 2009 at 1:44 PM, Wolfram Sang <w.sang <at> pengutronix.de> wrote:
> This driver has a generic part for the probe/remove routines which probably
> used to be called from a platform driver and an of_platform driver. Meanwhile,
> the driver is of_platform only, so there is no need for the generic part
> anymore. Unifying probe/remove finally enables us to call
> of_register_spi_devices(), so spi-device nodes from the device tree will be
> parsed. This was also mentioned by:
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073273.html

I haven't really been happy with any of the patches that added the
of_register_spi_devices() call, but I never got around to dealing with
it properly, or even replying.  I found Jon's patch too invasive, and
the patch referenced above is a little ugly.  Adding the call should
be really simple.  I've drafted a patch to do only that step and
attached it to this mail.  If this one works for you, then I'll merge
it immediately into -next.

> On the way, some patterns have been changed to current best practices (like
> using '!ptr' and 'struct resource'). Also, an older, yet uncommented, patch
> from me has been incorporated to improve the checks if the selected PSC is
> valid:
>
> http://patchwork.ozlabs.org/patch/36780/

There are at least 3 discrete changes here.  I prefer for each to be
provided as a separate patch so I can cherry pick the ones that are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Nov 2009 02:22
Picon

Re: [PATCH] spi/mpc52xx: check for invalid PSC usage

On Fri, Oct 23, 2009 at 5:25 AM, Wolfram Sang <w.sang <at> pengutronix.de> wrote:
> Add checks to allow only PSCs capable of SPI.
> Also turn printk to dev_err while we are here.

Hi Wolfram,

I wouldn't even bother.  It's not actively dangerous to try and use
PSC{4,5} in SPI mode.  It just not going to work.  Besides, the
MPC5200 common code already checks for an invalid PSC number when
setting the clock divisor.

Have you seen cases of users trying to do the wrong thing with the
crippled PSCs?

g.

>
> Signed-off-by: Wolfram Sang <w.sang <at> pengutronix.de>
> Cc: Grant Likely <grant.likely <at> secretlab.ca>
> Cc: David Brownell <dbrownell <at> users.sourceforge.net>
> ---
>
> Grant, if the patch is OK, maybe it can also go via your tree?
>
>  drivers/spi/mpc52xx_psc_spi.c |    9 ++++-----
>  1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
> index 1b74d5c..1d11a6d 100644
> --- a/drivers/spi/mpc52xx_psc_spi.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Nov 2009 07:47
Picon

Re: [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable

On Mon, Oct 5, 2009 at 1:42 PM, Albrecht Dreß <albrecht.dress <at> arcor.de> wrote:
> Am 05.10.09 20:16 schrieb(en) Grant Likely:
>>
>> Hmmm.  I've not been comfortable with this change, but it took me a while
>> to put my finger on exactly why.  In principle, I think it is a good idea.
>>  However, I don't want to merge it without any in-tree users.
>
> I could provide my modified microcode (which differs in two words only), for
> the "standard" task, just with byte swapping for the LPB, but I wonder if it
> is of much use.  No progress with crc32 calculation in BestComm so far...
> :-(
>
>> The other concern is that I don't like that the patch is only applicable
>> to gen_bd tasks.
>
> IMHO the big difference between gen_bd on one hand and ATA and FEC on the
> other is that (afaik) we have *no* other choice than using the implemented
> tasks for the latter two, obviously using the Freescale's example microcode.
>  Gen_bd can apparently be used for a plenty of purposes, including LPB (as
> shown in your driver), maybe PCI (there are examples in Freescale's code),
> PSC, etc.  Thus, the FEC and ATA drivers should not have an option as to
> change the microcode, whereas it is just convenient for gen_bd.

agreed.

>> I've been thinking about this for a while, and I'm not exactly thrilled
>> with the bestcomm layout which keeps the bestcomm firmware separate from the
>> only driver that actually uses it (ie FEC firmware & support code is
>> separate from the FEC driver.  Same for ATA).  I don't like the fact that
>> code which is only ever used by the ATA driver is maintained completely
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Likely | 1 Nov 2009 08:12
Picon

Re: [PATCH 1/1] powerpc/40x: Add new PPC440EPx based board HCU5 of Netstal Maschinen

On Fri, Oct 9, 2009 at 2:11 AM, Niklaus Giger
<niklaus.giger <at> member.fsf.org> wrote:
> Adds support for a HCU5 PPC405EPx based board from Netstal Maschinen AG.
>
> Signed-off-by: Niklaus Giger <niklaus.giger <at> member.fsf.org>
> ---
>  arch/powerpc/boot/dts/hcu5.dts          |  254 +++++++
>  arch/powerpc/configs/44x/hcu5_defconfig | 1166 +++++++++++++++++++++++++++++++

Do you really need your own defconfig?  Can you instead add support
for your board to ppc44x_defconfig?  Josh is the maintainer here, so
it is his decision, but on 5200 stuff I've been pushing back on adding
yet-another-board-specific-defconfig when there isn't a really
compelling reason to do so.  It adds a lot of lines for not a lot of
benefit.  Besides, if you add your board to the ppc44x_defconfig, you
gain the advantage of your code getting compiled by others more
frequently.

g.
Permalink | Reply | 0 comments |
headers
Giuseppe Coviello | 1 Nov 2009 10:17

Fail building 2.6.31.x for CHRP using gcc-4.4.x

Hi, we are having trouble while building kernel 2.6.31.x and also
2.6.32rc for CHRP platforms using gcc-4.4.x, the error that give us
the compilation is:

  CC      arch/powerpc/sysdev/indirect_pci.o
  CC      arch/powerpc/sysdev/i8259.o
  LD      arch/powerpc/sysdev/built-in.o
  CC      arch/powerpc/platforms/chrp/setup.o
cc1: warnings being treated as errors
arch/powerpc/platforms/chrp/setup.c: In function 'chrp_event_scan':
arch/powerpc/platforms/chrp/setup.c:378: error: the frame size of 1040
bytes is larger than 1024 bytes
make[2]: *** [arch/powerpc/platforms/chrp/setup.o] Error 1
make[1]: *** [arch/powerpc/platforms/chrp] Error 2
make: *** [arch/powerpc/platforms] Error

The same kernel, with the same configuration builds fine using gcc-4.3.x.

Regards, Giuseppe
Permalink | Reply | 0 comments |
headers
Segher Boessenkool | 1 Nov 2009 11:07

Re: Accessing flash directly from User Space [SOLVED]

>>>> mmio[0] = address;
>>>> mmio[1] = data;
>>>> mb();

eieio is enough here.

>>>> mmio[3] |= 0x01; /* This triggers an operation -> address=data */
>>>> /* probably also need an mb() here, if the following code
>>>>  * depends on the operation to be triggered. */

No, a sync does not guarantee the device has seen the store yet;
you need something specific to the device to guarantee this.
Usually a load (from the same register!) followed by code that
makes sure the load has finished is sufficient (and necessary).

>>> hmm, the mmio[0] and mmio[1] are written in order I hope?
>>
>> We do not care in this example, as the write to [3] does trigger
>> the device operation. We do only care that [0] and [1] are set
>> when [3] is written. We do not care in what order [0] and [1] are  
>> written.
>
> In this example yes, I was wondering in general.

The writes will not be reordered, but they can be combined,
unless you put an eieio (or sync) inbetween.

> So what does guarded memory mapping on ppc mean really? If I need
> that much mb(), guarded does not seem to do much.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Rothwell | 1 Nov 2009 12:41
Picon
Picon

Re: Fail building 2.6.31.x for CHRP using gcc-4.4.x

Hi Giuseppe,

On Sun, 1 Nov 2009 10:17:00 +0100 Giuseppe Coviello <cjg <at> cruxppc.org> wrote:
>
> Hi, we are having trouble while building kernel 2.6.31.x and also
> 2.6.32rc for CHRP platforms using gcc-4.4.x, the error that give us
> the compilation is:
> 
>   CC      arch/powerpc/sysdev/indirect_pci.o
>   CC      arch/powerpc/sysdev/i8259.o
>   LD      arch/powerpc/sysdev/built-in.o
>   CC      arch/powerpc/platforms/chrp/setup.o
> cc1: warnings being treated as errors
> arch/powerpc/platforms/chrp/setup.c: In function 'chrp_event_scan':
> arch/powerpc/platforms/chrp/setup.c:378: error: the frame size of 1040
> bytes is larger than 1024 bytes
> make[2]: *** [arch/powerpc/platforms/chrp/setup.o] Error 1
> make[1]: *** [arch/powerpc/platforms/chrp] Error 2
> make: *** [arch/powerpc/platforms] Error
> 
> The same kernel, with the same configuration builds fine using gcc-4.3.x.

For now, just enable CONFIG_PPC_DISABLE_WERROR.

--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Neuling
 | 
2 Nov 2009 00:23






Gravatar





Re: [PATCH 08/27] Add SLB switching code for entry/exit


> This is the really low level of guest entry/exit code.
> 
> Book3s_64 has an SLB, which stores all ESID -> VSID mappings we're
> currently aware of.
> 
> The segments in the guest differ from the ones on the host, so we need
> to switch the SLB to tell the MMU that we're in a new context.
> 
> So we store a shadow of the guest's SLB in the PACA, switch to that on
> entry and only restore bolted entries on exit, leaving the rest to the
> Linux SLB fault handler.
> 
> That way we get a really clean way of switching the SLB.
> 
> Signed-off-by: Alexander Graf <agraf <at> suse.de>
> ---
>  arch/powerpc/kvm/book3s_64_slb.S |  277 ++++++++++++++++++++++++++++++++++++
++
>  1 files changed, 277 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/kvm/book3s_64_slb.S
> 
> diff --git a/arch/powerpc/kvm/book3s_64_slb.S b/arch/powerpc/kvm/book3s_64_sl
b.S
> new file mode 100644
> index 0000000..00a8367
> --- /dev/null
> +++ b/arch/powerpc/kvm/book3s_64_slb.S
>  <at>  <at>  -0,0 +1,277  <at>  <at> 
> +/*
> + * This program is free software; you can redistribute it and/or modify

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Neuling
 | 
2 Nov 2009 00:39






Gravatar





Re: [PATCH 11/27] Add book3s_64 Host MMU handling


<snip>
> +static void invalidate_pte(struct hpte_cache *pte)
> +{
> +	dprintk_mmu("KVM: Flushing SPT %d: 0x%llx (0x%llx) -> 0x%llx\n",
> +		    i, pte->pte.eaddr, pte->pte.vpage, pte->host_va);
> +
> +	ppc_md.hpte_invalidate(pte->slot, pte->host_va,
> +			       MMU_PAGE_4K, MMU_SEGSIZE_256M,
> +			       false);

Are we assuming 256M segments here (and elsewhere)?

<snip>
> +static int kvmppc_mmu_next_segment(struct kvm_vcpu *vcpu, ulong esid)
> +{
> +	int i;
> +	int max_slb_size = 64;
> +	int found_inval = -1;
> +	int r;
> +
> +	if (!get_paca()->kvm_slb_max)
> +		get_paca()->kvm_slb_max = 1;
> +
> +	/* Are we overwriting? */
> +	for (i = 1; i < get_paca()->kvm_slb_max; i++) {
> +		if (!(get_paca()->kvm_slb[i].esid & SLB_ESID_V))
> +			found_inval = i;
> +		else if ((get_paca()->kvm_slb[i].esid & ESID_MASK) == esid)
> +			return i;
> +	}

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Benjamin Herrenschmidt
 | 
2 Nov 2009 06:11





[PATCH] powerpc: Avoid giving out RTC dates below EPOCH


Doing so causes xtime to be negative which crashes the timekeeping
code in funny ways when doing suspend/resume

Signed-off-by: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
---

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 92dc844..6a7ce0e 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
 <at>  <at>  -777,7 +777,7  <at>  <at>  int update_persistent_clock(struct timespec now)
 	return ppc_md.set_rtc_time(&tm);
 }

-void read_persistent_clock(struct timespec *ts)
+static void __read_persistent_clock(struct timespec *ts)
 {
 	struct rtc_time tm;
 	static int first = 1;
 <at>  <at>  -800,10 +800,23  <at>  <at>  void read_persistent_clock(struct timespec *ts)
 		return;
 	}
 	ppc_md.get_rtc_time(&tm);
+
 	ts->tv_sec = mktime(tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
 			    tm.tm_hour, tm.tm_min, tm.tm_sec);
 }

+void read_persistent_clock(struct timespec *ts)
+{

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane