Re: [PATCH 0/4] powerpc/crypto: IBM Power7+ in-Nest compression support

[Herbert Xu]

On Thu, Jul 19, 2012 at 09:42:37AM -0500, Seth Jennings wrote:
> This is a continuation of support for the Power7+ in-Nest
> hardware accelerator.
> 
> https://lkml.org/lkml/2012/4/12/223
> 
> This patchset adds the hardware driver and the cryptographic
> driver for hardware accelerated compression, which uses a
> hardware-optimized algorithm named 842.
> 
> The hardware driver has limits on generic compression and is
> geared toward compressing units that are of PAGE_SIZE for
> in-kernel memory compression.
> 
> Based on linux-next (20120717)
> 
> Seth Jennings (4):

All applied.  Thanks Seth.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/4] powerpc/crypto: add 842 hardware compression driver

[Michael Ellerman]

On Fri, 2012-07-20 at 09:01 -0500, Seth Jennings wrote:
> On 07/20/2012 12:33 AM, Michael Ellerman wrote:
> > On Thu, 2012-07-19 at 09:42 -0500, Seth Jennings wrote:
> >> This patch adds the driver for interacting with the 842
> >> compression accelerator on IBM Power7+ systems.
> > 
> > ...
> > 
> >> +struct nx842_slentry {
> >> +  unsigned long ptr; /* Absolute address (use virt_to_abs()) */
> >> /+ unsigned long len;
> >> +};
> > 
> > These days virt_to_abs() is just __pa() - ie. convert to a real address.
> 
> Thanks, I'll make that change.
> 
> Is it a blocker to the code being pulled in though? I'm
> hoping to get this in ASAP for the 3.6 merge window.  As
> this isn't a functional defect (I assume __pa() and
> virt_to_abs() still achieve the same result), can I get an
> OK from you that this isn't a blocker to the code being
> accepted?

Sorry I missed your reply. No it's not a blocker, just ugly.

I have sent a series to Ben which removes virt_to_abs() entirely, so
we'll want to make sure we fixup the nx driver before that goes in.

cheers

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Jia Hongtao-B38951]

> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Friday, July 27, 2012 8:47 PM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
> 
> 
> On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> >> Sent: Friday, July 27, 2012 2:15 AM
> >> To: Jia Hongtao-B38951
> >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
> >> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> >> initialization code
> >>
> >>
> >> On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
> >>
> >>> We unified the Freescale pci/pcie initialization by changing the
> >> fsl_pci
> >>> to a platform driver. In previous PCI code architecture the
> >> initialization
> >>> routine is called at board_setup_arch stage. Now the initialization
> is
> >> done
> >>> in probe function which is architectural better. Also It's convenient
> >> for
> >>> adding PM support for PCI controller in later patch.
> >>>
> >>> One issue introduced by this architecture is the timing of
> swiotlb_init.
> >>> During PCI initialization the need of swiotlb is determined and this
> >> should
> >>> be done before swiotlb_init. So a new function to determine swiotlb
> by
> >>> parsing pci ranges is made. This function is called at
> board_setup_arch
> >>> stage which is earlier than swiotlb_init.
> >>>
> >>> Signed-off-by: Jia Hongtao 
> >>> Signed-off-by: Li Yang 
> >>> ---
> >>> Changed for V3:
> >>> - Rebase the patch set on the latest tree
> >>> - merge PCI unify and swiotlb patch into one
> >>>
> >>> arch/powerpc/sysdev/fsl_pci.c |  155
> --
> >> ---
> >>> arch/powerpc/sysdev/fsl_pci.h |9 +--
> >>> 2 files changed, 125 insertions(+), 39 deletions(-)
> >>
> >> I'd like the SWIOTLB refactoring as a separate patch.  Additionally,
> the
> >> order of patches should be as follows:
> >>
> >> 1. refactor PCI node parsing code
> >> 2. add pci_determine_swiotlb (should rename to
> fsl_pci_determine_swiotlb)
> >> 3. Determine primary bus by looking for ISA node
> >> 4. convert all boards over to fsl_pci_init
> >> 5. convert fsl pci to platform driver (edac and other fixes should be
> >> merged in here)
> >> 6. PM support
> >>
> >> - k
> >
> > Should I convert all boards over to fsl_pci_init first and then convert
> them
> > over to platform driver again or just convert them direct to platform
> driver?
> 
> Yes do the fsl_pci_init conversion first.  The reason is we should NOT
> break functionality from one patch to another.
> 
> - k


Actually, the functionality is not broken, other boards just use the old
Way to init pci controller and it still works.

-Hongtao.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/1] booke/wdt: fix incorrect WDIOC_GETSUPPORT return path

[Tiejun Chen]

We miss that correct WDIOC_GETSUPPORT return path when perform
copy_to_user() properly.

Signed-off-by: Tiejun Chen 
---
 drivers/watchdog/booke_wdt.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3fe82d0..2be7f29 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -162,12 +162,13 @@ static long booke_wdt_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
 {
u32 tmp = 0;
-   u32 __user *p = (u32 __user *)arg;
+   void __user *argp = (u32 __user *)arg;
+   u32 __user *p = argp;
 
switch (cmd) {
case WDIOC_GETSUPPORT:
-   if (copy_to_user((void *)arg, &ident, sizeof(ident)))
-   return -EFAULT;
+   return copy_to_user(argp, &ident,
+   sizeof(ident)) ? -EFAULT : 0;
case WDIOC_GETSTATUS:
return put_user(0, p);
case WDIOC_GETBOOTSTATUS:
-- 
1.5.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Jia Hongtao-B38951]

> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Saturday, July 28, 2012 5:17 AM
> To: Wood Scott-B07421
> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
> 
> 
> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
> 
> > On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
> >> Hi kumar,
> >>
> >> I know "duplicate code from pci_process_bridge_OF_ranges()" is
> >> hard to accept but "refactor the code to have a shared function"
> >> is knotty. Actually this is the reason I didn't do the refactor.
> >
> > Maybe we should keep doing the init early?  We could still have a
> > platform device for the PM stuff, but some init would be done before
> probe.
> >
> > Another possibility is to try to handle swiotlb init later -- possibly
> > by reserving memory for it if the platform indicates it's a possibility
> > that it will be needed, then freeing the memory if it's not needed.
> >
> > -Scott
> 
> I think the first option seems reasonable.  Can we leave fsl_pci_init()
> as we now have it and just have the platform driver deal with PM restore
> via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
> handle restore case, but seems like minor changes]
> 
> - k
> 


I think the second option is better if it's hard to decouple swiotlb
determination from pci init. I believe the better architecture that
PCI init in probe function of platform driver will bring us considerable
advantage. I really like to keep the completion of pci controller
platform driver not only for PM support but also for pci init.

-Hongtao. 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Aggrwal Poonam-B10812]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
> KH
> Sent: Friday, July 27, 2012 11:30 PM
> To: Singh Sandeep-B37400
> Cc: de...@driverdev.osuosl.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org
> Subject: Re: [2/3][PATCH][v2] TDM Framework
> 
> On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> > +/* Data structures required for sysfs */ static struct tdm_sysfs attr
> > += {
> > +   .attr.name = "use_latest_data",
> > +   .attr.mode = 0664,
> > +   .cmd_type = TDM_LATEST_DATA,
> > +};
> 
> What is this for?
This knob is to control the behavior of the TDM framework with respect to 
handling the received TDM frames.
The framework layer receives the TDM frames from the TDM adapter driver, 
de-interleaves the data and sends to respective client modules.
In the case when the TDM client module has not consumed the data and emptied 
the Buffer, this flag decides whether to discard the un-fetched data, or 
discard the latest received data.

> 
> > +int tdm_sysfs_init(void)
> > +{
> > +   struct kobject *tdm_kobj;
> > +   int err = 1;
> > +   tdm_kobj = kzalloc(sizeof(*tdm_kobj), GFP_KERNEL);
> > +   if (tdm_kobj) {
> > +   kobject_init(tdm_kobj, &tdm_type);
> > +   if (kobject_add(tdm_kobj, NULL, "%s", "tdm")) {
> > +   pr_err("tdm: Sysfs creation failed\n");
> > +   kobject_put(tdm_kobj);
> > +   err = -EINVAL;
> > +   goto out;
> > +   }
> > +   } else {
> > +   pr_err("tdm: Unable to allocate tdm_kobj\n");
> > +   err = -ENOMEM;
> > +   goto out;
> > +   }
> > +
> > +out:
> > +   return err;
> > +}
> 
> You just leaked memory, what are you trying to do here?
> 
> And why are you using "raw" kobjects?  That's a sure sign that something
> is really wrong.
Will refer the documentation. Not very experienced on this stuff. Thanks for 
the comment.
> 
> Your code doesn't look like it is tied into the driver model at all, why
> not?  What are you trying to do here?
This is a framework layer, not associated to a particular device. TDM adapter 
drivers will register to this framework.
We got this comment in internal freescale review list also.
> 
> Also, when creating new sysfs entries, like you are attempting to do here
> (unsuccessfully I might add), you must create Documentation/ABI/ files as
> well.
Ok.
> 
> And, to top it all off, you do realize you are asking us to do code
> review in the middle of the merge window, when we are all busy doing
> other things?
Apologize for asking a review in the merge window time frame.
Are there any guidelines when to send something for a review? We will be 
careful next time.

Regards
Poonam
> 
> greg k-h
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Aggrwal Poonam-B10812]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
> KH
> Sent: Friday, July 27, 2012 11:42 PM
> To: Singh Sandeep-B37400
> Cc: de...@driverdev.osuosl.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org
> Subject: Re: [2/3][PATCH][v2] TDM Framework
> 
> On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> > +static struct kobj_type tdm_type = {
> > +   .sysfs_ops = &tdm_ops,
> > +   .default_attrs = tdm_attr,
> > +};
> 
> Ah, also, as per the documentation in the kernel (go look, it's there), I
> now get to publicly mock you for ignoring the error messages that the
> kernel is giving you when you try to shut down your code path.
> 
> Well, to be fair, you are leaking memory like a sieve, so I doubt you
> ever saw those error messages because you never cleaned up after
> yourself, so perhaps I can forgive you, but your users can't, sorry.
> They like to rely on the fact that Linux is a reliable operating system,
> don't cause them to doubt that.
> 
> Please fix this code, it's horribly broken.  Read
> Documentation/kobject.txt for why.  That file was written for a reason,
> and not just because we like writing documentation (hint, we hate to...)
To be honest we are not sysfs experts. Thanks for pointing to the documentation.
We will rework the stuff.

Regards
Poonam
> 
> Ugh,
> 
> greg k-h
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Singh Sandeep-B37400]

-Original Message-
From: John Stoffel [mailto:j...@stoffel.org] 
Sent: 27 July 2012 19:42
To: Singh Sandeep-B37400
Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; 
ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; 
de...@driverdev.osuosl.org
Subject: Re: [2/3][PATCH][v2] TDM Framework


> From: Sandeep Singh  TDM Framework is an 
> attempt to provide a platform independent layer which can offer a 
> standard interface  for TDM access to different client modules.

Please don't use TLAs (Three Letter Acronyms) like TDM without explaining the 
clearly and up front.  It makes it hard for anyone else who doens't know your 
code to look it over without having to spend lots of time poking around to 
figure it out from either context or somewhere else.
[Sandeep] Patch for documentation for TDM is present in this patch set, which 
explains TDM in detail. Should we do this in commit message too??
Link too documentation patch: http://patchwork.ozlabs.org/patch/173680/

John


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Singh Sandeep-B37400]

Thanks for your comments. Please find replies inline.

Regards,
Sandeep

-Original Message-
From: Francois Romieu [mailto:rom...@fr.zoreil.com] 
Sent: 27 July 2012 20:56
To: Singh Sandeep-B37400
Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; 
ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; 
de...@driverdev.osuosl.org
Subject: Re: [2/3][PATCH][v2] TDM Framework

sand...@freescale.com  :
[...]
> The main functions of this Framework are:
>  - provides interface to TDM clients to access TDM functionalities.
>  - provides standard interface for TDM drivers to hook with the framework.
>  - handles various data handling stuff and buffer management.
> 
> In future this Framework will be extended to provide Interface for Line 
> control devices also. For example SLIC, E1/T1 Framers etc.
> 
> Presently the framework supports only Single Port channelised mode.
> Also the configurability options are limited which will be extended later on.
> Only kernel mode TDM clients are supported currently. Support for User mode 
> clients will be added later.

1. You should send some kernel mode TDM clients. Without those the framework
   is pretty useless.
[Sandeep] We do have a test client but not good enough to be pushed in open 
source, should we add it to documentation?? 

2. It would probably make sense to Cc: netdev and serial. There may be
   some kernel client network integration from the start.
[Sandeep] Ok. 

3. Where is the userspace configuration interface ?
[Sandeep] TDM framework right now supports only kernel mode clients. It has 
been tested with the client module that I mentioned above. Both the framework 
and test client are a part of Freescale BSP.

[...]
> Based on: git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git
[Sandeep] Please try below mentioned link. The above one is Freescale's 
internal mirror of:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git 

$ git clone git://git.am.freescale.net/gitolite/mirrors/galak-powerpc.git
Cloning into 'galak-powerpc'...
fatal: Unable to look up git.am.freescale.net (port 9418) (No address 
associated with hostname)

-- 
Ueimor


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()

[Heiko Carstens]

On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote:
> We don't call __add_pages() directly in the function add_memory()
> because some other architecture related things need to be done
> before or after calling __add_pages(). So we should introduce
> a new function arch_remove_memory() to revert the things
> done in arch_add_memory().
> 
> Note: the function for s390 is not implemented(I don't know how to
> implement it for s390).

There is no hardware or firmware interface which could trigger a
hot memory remove on s390. So there is nothing that needs to be
implemented.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH v5 12/19] memory-hotplug: introduce new function arch_remove_memory()

[Wen Congyang]

At 07/30/2012 06:23 PM, Heiko Carstens Wrote:
> On Fri, Jul 27, 2012 at 06:32:15PM +0800, Wen Congyang wrote:
>> We don't call __add_pages() directly in the function add_memory()
>> because some other architecture related things need to be done
>> before or after calling __add_pages(). So we should introduce
>> a new function arch_remove_memory() to revert the things
>> done in arch_add_memory().
>>
>> Note: the function for s390 is not implemented(I don't know how to
>> implement it for s390).
> 
> There is no hardware or firmware interface which could trigger a
> hot memory remove on s390. So there is nothing that needs to be
> implemented.

Thanks for providing this information.

According to this, arch_remove_memory() for s390 can just return -EBUSY.

Thanks
Wen Congyang

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 02/13] arch/powerpc: Simplify hpte_decode

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

This patch simplify hpte_decode for easy switching of virtual address to
virtual page number in the later patch

Reviewed-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/hash_native_64.c |   49 ++
 1 file changed, 28 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 90039bc..660b8bb 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -351,9 +351,10 @@ static void native_hpte_invalidate(unsigned long slot, 
unsigned long va,
 static void hpte_decode(struct hash_pte *hpte, unsigned long slot,
int *psize, int *ssize, unsigned long *va)
 {
+   unsigned long avpn, pteg, vpi;
unsigned long hpte_r = hpte->r;
unsigned long hpte_v = hpte->v;
-   unsigned long avpn;
+   unsigned long vsid, seg_off;
int i, size, shift, penc;
 
if (!(hpte_v & HPTE_V_LARGE))
@@ -380,32 +381,38 @@ static void hpte_decode(struct hash_pte *hpte, unsigned 
long slot,
}
 
/* This works for all page sizes, and for 256M and 1T segments */
+   *ssize = hpte_v >> HPTE_V_SSIZE_SHIFT;
shift = mmu_psize_defs[size].shift;
-   avpn = (HPTE_V_AVPN_VAL(hpte_v) & ~mmu_psize_defs[size].avpnm) << 23;
-
-   if (shift < 23) {
-   unsigned long vpi, vsid, pteg;
 
-   pteg = slot / HPTES_PER_GROUP;
-   if (hpte_v & HPTE_V_SECONDARY)
-   pteg = ~pteg;
-   switch (hpte_v >> HPTE_V_SSIZE_SHIFT) {
-   case MMU_SEGSIZE_256M:
-   vpi = ((avpn >> 28) ^ pteg) & htab_hash_mask;
-   break;
-   case MMU_SEGSIZE_1T:
-   vsid = avpn >> 40;
+   avpn = (HPTE_V_AVPN_VAL(hpte_v) & ~mmu_psize_defs[size].avpnm);
+   pteg = slot / HPTES_PER_GROUP;
+   if (hpte_v & HPTE_V_SECONDARY)
+   pteg = ~pteg;
+
+   switch (*ssize) {
+   case MMU_SEGSIZE_256M:
+   /* We only have 28 - 23 bits of seg_off in avpn */
+   seg_off = (avpn & 0x1f) << 23;
+   vsid=  avpn >> 5;
+   /* We can find more bits from the pteg value */
+   if (shift < 23) {
+   vpi = (vsid ^ pteg) & htab_hash_mask;
+   seg_off |= vpi << shift;
+   }
+   *va = vsid << SID_SHIFT | seg_off;
+   case MMU_SEGSIZE_1T:
+   /* We only have 40 - 23 bits of seg_off in avpn */
+   seg_off = (avpn & 0x1) << 23;
+   vsid= avpn >> 17;
+   if (shift < 23) {
vpi = (vsid ^ (vsid << 25) ^ pteg) & htab_hash_mask;
-   break;
-   default:
-   avpn = vpi = size = 0;
+   seg_off |= vpi << shift;
}
-   avpn |= (vpi << mmu_psize_defs[size].shift);
+   *va = vsid << SID_SHIFT_1T | seg_off;
+   default:
+   *va = size = 0;
}
-
-   *va = avpn;
*psize = size;
-   *ssize = hpte_v >> HPTE_V_SSIZE_SHIFT;
 }
 
 /*
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 13/13] arch/powerpc: Update VSID allocation documentation

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

This update the proto-VSID and VSID scramble related information
to be more generic by using names instead of current values.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h |   36 -
 1 file changed, 13 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index 8e97715..1a44550 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -330,51 +330,41 @@ extern void slb_set_size(u16 size);
 #endif /* __ASSEMBLY__ */
 
 /*
- * VSID allocation
+ * VSID allocation (256MB segment)
  *
- * We first generate a 36-bit "proto-VSID".  For kernel addresses this
- * is equal to the ESID, for user addresses it is:
- * (context << 15) | (esid & 0x7fff)
+ * We first generate a 38-bit "proto-VSID".  For kernel addresses this
+ * is equal to the ESID | 1 << 37, for user addresses it is:
+ * (context << USER_ESID_BITS) | (esid & (1U << USER_ESID_BITS))
  *
- * The two forms are distinguishable because the top bit is 0 for user
- * addresses, whereas the top two bits are 1 for kernel addresses.
- * Proto-VSIDs with the top two bits equal to 0b10 are reserved for
- * now.
+ * This splits the proto-VSID into the below range
+ *  0 - (2^(CONTEXT_BITS + USER_ESID_BITS) - 1) : User proto-VSID range
+ *  2^(CONTEXT_BITS + USER_ESID_BITS) - 2^(VSID_BITS) : Kernel proto-VSID range
  *
  * The proto-VSIDs are then scrambled into real VSIDs with the
  * multiplicative hash:
  *
  * VSID = (proto-VSID * VSID_MULTIPLIER) % VSID_MODULUS
- * where   VSID_MULTIPLIER = 268435399 = 0xFC7
- * VSID_MODULUS = 2^36-1 = 0xF
  *
- * This scramble is only well defined for proto-VSIDs below
- * 0xF, so both proto-VSID and actual VSID 0xF are
- * reserved.  VSID_MULTIPLIER is prime, so in particular it is
+ * VSID_MULTIPLIER is prime, so in particular it is
  * co-prime to VSID_MODULUS, making this a 1:1 scrambling function.
  * Because the modulus is 2^n-1 we can compute it efficiently without
  * a divide or extra multiply (see below).
  *
  * This scheme has several advantages over older methods:
  *
- * - We have VSIDs allocated for every kernel address
+ * - We have VSIDs allocated for every kernel address
  * (i.e. everything above 0xC000), except the very top
  * segment, which simplifies several things.
  *
- * - We allow for 16 significant bits of ESID and 19 bits of
- * context for user addresses.  i.e. 16T (44 bits) of address space for
- * up to half a million contexts.
+ * - We allow for USER_ESID_BITS significant bits of ESID and
+ * CONTEXT_BITS  bits of context for user addresses.
+ *  i.e. 64T (46 bits) of address space for up to half a million contexts.
  *
- * - The scramble function gives robust scattering in the hash
+ * - The scramble function gives robust scattering in the hash
  * table (at least based on some initial results).  The previous
  * method was more susceptible to pathological cases giving excessive
  * hash collisions.
  */
-/*
- * WARNING - If you change these you must make sure the asm
- * implementations in slb_allocate (slb_low.S), do_stab_bolted
- * (head.S) and ASM_VSID_SCRAMBLE (below) are changed accordingly.
- */
 
 /*
  * This should be computed such that protovosid * vsid_mulitplier
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 0/13] arch/powerpc: Add 64TB support to ppc64

[Aneesh Kumar K.V]

Hi,

This patchset include patches for supporting 64TB with ppc64. I haven't booted
this on hardware with 64TB memory yet. But they boot fine on real hardware with
less memory. Changes extend VSID bits to 38 bits for a 256MB segment
and 26 bits for 1TB segments. 

Changes from v4:
 * Drop patch "arch/powerpc: properly offset the context bits for 1T segemnts"
   based on review feedback
 * split CONTEX_BITS related changes from patch 12
 * Add a new doc update patch

Changes from v3:
 * Address review comments.
 * Added new patch to ensure proto-VSID isolation between kernel and user space

Changes from V2:
 * Fix few FIXMEs in the patchset. I have added them as separate patch for
   easier review. That should help us to drop those changes if we don't agree.

Changes from V1:
* Drop the usage of structure (struct virt_addr) to carry virtual address.
  We now represent virtual address via vpn which is virtual address shifted 
  right 12 bits.

Thanks,
-aneesh


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 05/13] arch/powerpc: Make KERN_VIRT_SIZE not dependend on PGTABLE_RANGE

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

As we keep increasing PGTABLE_RANGE we need not increase the virual
map area for kernel.

Reviewed-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/pgtable-ppc64.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
b/arch/powerpc/include/asm/pgtable-ppc64.h
index c420561..8af1cf2 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -41,7 +41,7 @@
 #else
 #define KERN_VIRT_START ASM_CONST(0xD000)
 #endif
-#define KERN_VIRT_SIZE PGTABLE_RANGE
+#define KERN_VIRT_SIZE ASM_CONST(0x1000)
 
 /*
  * The vmalloc space starts at the beginning of that region, and
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 10/13] arch/powerpc: Add 64TB support

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

Increase max addressable range to 64TB. This is not tested on
real hardware yet.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h|   14 +-
 arch/powerpc/include/asm/pgtable-ppc64-4k.h  |2 +-
 arch/powerpc/include/asm/pgtable-ppc64-64k.h |2 +-
 arch/powerpc/include/asm/processor.h |4 ++--
 arch/powerpc/include/asm/sparsemem.h |4 ++--
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index d24d484..daa3e4b 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -376,17 +376,21 @@ extern void slb_set_size(u16 size);
  * (head.S) and ASM_VSID_SCRAMBLE (below) are changed accordingly.
  */
 
-#define VSID_MULTIPLIER_256M   ASM_CONST(200730139)/* 28-bit prime */
-#define VSID_BITS_256M 36
+/*
+ * This should be computed such that protovosid * vsid_mulitplier
+ * doesn't overflow 64 bits. It should also be co-prime to vsid_modulus
+ */
+#define VSID_MULTIPLIER_256M   ASM_CONST(12538073) /* 24-bit prime */
+#define VSID_BITS_256M 38
 #define VSID_MODULUS_256M  ((1UL

[PATCH -V5 09/13] arch/powerpc: Use 32bit array for slb cache

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

With larger vsid we need to track more bits of ESID in slb cache
for slb invalidate.

Reviewed-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/paca.h |2 +-
 arch/powerpc/mm/slb_low.S   |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index daf813f..3e7abba 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -100,7 +100,7 @@ struct paca_struct {
/* SLB related definitions */
u16 vmalloc_sllp;
u16 slb_cache_ptr;
-   u16 slb_cache[SLB_CACHE_ENTRIES];
+   u32 slb_cache[SLB_CACHE_ENTRIES];
 #endif /* CONFIG_PPC_STD_MMU_64 */
 
 #ifdef CONFIG_PPC_BOOK3E
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index 8e5c9bd..db2cb3f 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -273,10 +273,10 @@ _GLOBAL(slb_compare_rr_to_size)
bge 1f
 
/* still room in the slb cache */
-   sldir11,r3,1/* r11 = offset * sizeof(u16) */
-   rldicl  r10,r10,36,28   /* get low 16 bits of the ESID */
-   add r11,r11,r13 /* r11 = (u16 *)paca + offset */
-   sth r10,PACASLBCACHE(r11)   /* paca->slb_cache[offset] = esid */
+   sldir11,r3,2/* r11 = offset * sizeof(u32) */
+   srdir10,r10,28  /* get the 36 bits of the ESID */
+   add r11,r11,r13 /* r11 = (u32 *)paca + offset */
+   stw r10,PACASLBCACHE(r11)   /* paca->slb_cache[offset] = esid */
addir3,r3,1 /* offset++ */
b   2f
 1: /* offset >= SLB_CACHE_ENTRIES */
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 11/13] arch/powerpc: properly isolate kernel and user proto-VSID

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

The proto-VSID space is divided into two class
User:   0 to 2^(CONTEXT_BITS + USER_ESID_BITS) -1
kernel: 2^(CONTEXT_BITS + USER_ESID_BITS) to 2^(VSID_BITS) - 1

With KERNEL_START at 0xc000, the proto vsid for
the kernel ends up with 0xc (36 bits). With 64TB
patchset we need to have kernel proto-VSID in the
[2^37 to 2^38 - 1] range due to the increased USER_ESID_BITS.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h |   16 +---
 arch/powerpc/kernel/exceptions-64s.S  |4 +++-
 arch/powerpc/mm/slb_low.S |   16 
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index daa3e4b..8e97715 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -516,9 +516,19 @@ typedef struct {
 /* This is only valid for addresses >= PAGE_OFFSET */
 static inline unsigned long get_kernel_vsid(unsigned long ea, int ssize)
 {
-   if (ssize == MMU_SEGSIZE_256M)
-   return vsid_scramble(ea >> SID_SHIFT, 256M);
-   return vsid_scramble(ea >> SID_SHIFT_1T, 1T);
+   unsigned long proto_vsid;
+   /*
+* We need to make sure proto_vsid for the kernel is
+* >= 2^(CONTEXT_BITS + USER_ESID_BITS[_1T])
+*/
+   if (ssize == MMU_SEGSIZE_256M) {
+   proto_vsid = ea >> SID_SHIFT;
+   proto_vsid |= (1UL << (CONTEXT_BITS + USER_ESID_BITS));
+   return vsid_scramble(proto_vsid, 256M);
+   }
+   proto_vsid = ea >> SID_SHIFT_1T;
+   proto_vsid |= (1UL << (CONTEXT_BITS + USER_ESID_BITS_1T));
+   return vsid_scramble(proto_vsid, 1T);
 }
 
 /* Returns the segment size indicator for a user address */
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 1c06d29..40ed208 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -958,7 +958,9 @@ _GLOBAL(do_stab_bolted)
rldimi  r10,r11,7,52/* r10 = first ste of the group */
 
/* Calculate VSID */
-   /* This is a kernel address, so protovsid = ESID */
+   /* This is a kernel address, so protovsid = ESID | 1 << 37 */
+   li  r9,0x1
+   rldimi  r11,r9,(CONTEXT_BITS + USER_ESID_BITS),0
ASM_VSID_SCRAMBLE(r11, r9, 256M)
rldic   r9,r11,12,16/* r9 = vsid << 12 */
 
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index db2cb3f..405d380 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -57,8 +57,16 @@ _GLOBAL(slb_allocate_realmode)
 _GLOBAL(slb_miss_kernel_load_linear)
li  r11,0
 BEGIN_FTR_SECTION
+   li  r9,0x1
+   rldimi  r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
b   slb_finish_load
 END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
+   li  r9,0x1
+   /*
+* shift 12 bits less here, slb_finish_load_1T will do
+* the necessary shits
+*/
+   rldimi  r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
b   slb_finish_load_1T
 
 1:
@@ -86,8 +94,16 @@ _GLOBAL(slb_miss_kernel_load_vmemmap)
li  r11,0
 6:
 BEGIN_FTR_SECTION
+   li  r9,0x1
+   rldimi  r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
b   slb_finish_load
 END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
+   li  r9,0x1
+   /*
+* shift 12 bits less here, slb_finish_load_1T will do
+* the necessary shits
+*/
+   rldimi  r10,r9,(CONTEXT_BITS + USER_ESID_BITS),0
b   slb_finish_load_1T
 
 0: /* user address: proto-VSID = context << 15 | ESID. First check
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 12/13] arch/powerpc: Replace open coded CONTEXT_BITS value

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

To clarify the meaning for future readers, replace the open coded
19 with CONTEXT_BITS

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/mmu_context_hash64.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/mmu_context_hash64.c 
b/arch/powerpc/mm/mmu_context_hash64.c
index 40677aa..daa076c 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -34,7 +34,7 @@ static DEFINE_IDA(mmu_context_ida);
  * Each segment contains 2^28 bytes.  Each context maps 2^44 bytes,
  * so we can support 2^19-1 contexts (19 == 35 + 28 - 44).
  */
-#define MAX_CONTEXT((1UL << 19) - 1)
+#define MAX_CONTEXT((1UL << CONTEXT_BITS) - 1)
 
 int __init_new_context(void)
 {
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 06/13] arch/powerpc: Increase the slice range to 64TB

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

This patch makes the high psizes mask as an unsigned char array
so that we can have more than 16TB. Currently we support upto
64TB

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h |6 ++-
 arch/powerpc/include/asm/page_64.h|6 ++-
 arch/powerpc/mm/hash_utils_64.c   |   15 +++---
 arch/powerpc/mm/slb_low.S |   35 
 arch/powerpc/mm/slice.c   |   95 +
 5 files changed, 107 insertions(+), 50 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index e5af632..fe865fe 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -466,7 +466,11 @@ typedef struct {
 
 #ifdef CONFIG_PPC_MM_SLICES
u64 low_slices_psize;   /* SLB page size encodings */
-   u64 high_slices_psize;  /* 4 bits per slice for now */
+   /*
+* Right now we support 64TB and 4 bits for each
+* 1TB slice we need 32 bytes for 64TB.
+*/
+   unsigned char high_slices_psize[32];  /* 4 bits per slice for now */
 #else
u16 sllp;   /* SLB page size encoding */
 #endif
diff --git a/arch/powerpc/include/asm/page_64.h 
b/arch/powerpc/include/asm/page_64.h
index fed85e6..6c9bef4 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -82,7 +82,11 @@ extern u64 ppc64_pft_size;
 
 struct slice_mask {
u16 low_slices;
-   u16 high_slices;
+   /*
+* This should be derived out of PGTABLE_RANGE. For the current
+* max 64TB, u64 should be ok.
+*/
+   u64 high_slices;
 };
 
 struct mm_struct;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 74c5479..13e0ccf 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -804,16 +804,19 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp, 
pte_t pte, int trap)
 #ifdef CONFIG_PPC_MM_SLICES
 unsigned int get_paca_psize(unsigned long addr)
 {
-   unsigned long index, slices;
+   u64 lpsizes;
+   unsigned char *hpsizes;
+   unsigned long index, mask_index;
 
if (addr < SLICE_LOW_TOP) {
-   slices = get_paca()->context.low_slices_psize;
+   lpsizes = get_paca()->context.low_slices_psize;
index = GET_LOW_SLICE_INDEX(addr);
-   } else {
-   slices = get_paca()->context.high_slices_psize;
-   index = GET_HIGH_SLICE_INDEX(addr);
+   return (lpsizes >> (index * 4)) & 0xF;
}
-   return (slices >> (index * 4)) & 0xF;
+   hpsizes = get_paca()->context.high_slices_psize;
+   index = GET_HIGH_SLICE_INDEX(addr);
+   mask_index = index & 0x1;
+   return (hpsizes[index >> 1] >> (mask_index * 4)) & 0xF;
 }
 
 #else
diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index b9ee79ce..c355af6 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -108,17 +108,34 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_1T_SEGMENT)
 * between 4k and 64k standard page size
 */
 #ifdef CONFIG_PPC_MM_SLICES
+   /* r10 have esid */
cmpldi  r10,16
-
-   /* Get the slice index * 4 in r11 and matching slice size mask in r9 */
-   ld  r9,PACALOWSLICESPSIZE(r13)
-   sldir11,r10,2
+   /* below SLICE_LOW_TOP */
blt 5f
-   ld  r9,PACAHIGHSLICEPSIZE(r13)
-   srdir11,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT - 2)
-   andi.   r11,r11,0x3c
-
-5: /* Extract the psize and multiply to get an array offset */
+   /*
+* Handle hpsizes,
+* r9 is get_paca()->context.high_slices_psize[index], r11 is mask_index
+* We use r10 here, later we restore it to esid.
+* Can we use other register instead of r10 ?
+*/
+   srdir10,r10,(SLICE_HIGH_SHIFT - SLICE_LOW_SHIFT) /* index */
+   srdir11,r10,1   /* r11 is array index */
+   addir9,r11,PACAHIGHSLICEPSIZE
+   lbzxr9,r9,r13   /* r9 is hpsizes[r11] */
+   sldir11,r11,1
+   subfr11,r11,r10 /* mask_index = index - (array_index << 1) */
+   srdir10,r3,28   /* restore r10 with esid */
+   b   6f
+5:
+   /*
+* Handle lpsizes
+* r9 is get_paca()->context.low_slices_psize, r11 is index
+*/
+   ld  r9,PACALOWSLICESPSIZE(r13)
+   mr  r11,r10
+6:
+   sldir11,r11,2  /* index * 4 */
+   /* Extract the psize and multiply to get an array offset */
srd r9,r9,r11
andi.   r9,r9,0xf
mulli   r9,r9,MMUPSIZEDEFSIZE
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 73709f7..0136040 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -42,7 +42,7 @@ int _slice_debug = 1;
 
 static void slice_print_mask(const char *label, 

[PATCH -V5 03/13] arch/powerpc: Convert virtual address to vpn

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

This patch convert different functions to take virtual page number
instead of virtual address. Virtual page number is virtual address
shifted right by VPN_SHIFT (12) bits. This enable us to have an
address range of upto 76 bits.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h |   73 ++
 arch/powerpc/include/asm/pte-hash64-64k.h |   18 +++---
 arch/powerpc/kvm/book3s_32_mmu_host.c |2 +-
 arch/powerpc/kvm/book3s_64_mmu_host.c |2 +-
 arch/powerpc/mm/hash_low_64.S |   97 ++---
 arch/powerpc/mm/hash_native_64.c  |   46 ++
 arch/powerpc/mm/hash_utils_64.c   |6 +-
 arch/powerpc/mm/hugetlbpage-hash64.c  |2 +-
 arch/powerpc/mm/tlb_hash64.c  |2 +-
 arch/powerpc/platforms/cell/beat_htab.c   |2 +-
 arch/powerpc/platforms/pseries/lpar.c |   20 +-
 11 files changed, 176 insertions(+), 94 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index 1c65a59..60f8596 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -15,6 +15,10 @@
 #include 
 #include 
 
+#ifndef __ASSEMBLY__
+#include 
+#endif
+
 /*
  * Segment table
  */
@@ -154,9 +158,25 @@ struct mmu_psize_def
 #define MMU_SEGSIZE_256M   0
 #define MMU_SEGSIZE_1T 1
 
+/*
+ * encode page number shift.
+ * in order to fit the 78 bit va in a 64 bit variable we shift the va by
+ * 12 bits. This enable us to address upto 76 bit va.
+ * For hpt hash from a va we can ignore the page size bits of va and for
+ * hpte encoding we ignore up to 23 bits of va. So ignoring lower 12 bits 
ensure
+ * we work in all cases including 4k page size.
+ */
+#define VPN_SHIFT  12
 
 #ifndef __ASSEMBLY__
 
+static inline int segment_shift(int ssize)
+{
+   if (ssize == MMU_SEGSIZE_256M)
+   return SID_SHIFT;
+   return SID_SHIFT_1T;
+}
+
 /*
  * The current system page and segment sizes
  */
@@ -180,6 +200,30 @@ extern unsigned long tce_alloc_start, tce_alloc_end;
 extern int mmu_ci_restrictions;
 
 /*
+ * This computes the AVPN and B fields of the first dword of a HPTE,
+ * for use when we want to match an existing PTE.  The bottom 7 bits
+ * of the returned value are zero.
+ */
+static inline unsigned long hpte_encode_avpn(unsigned long vpn, int psize,
+int ssize)
+{
+   unsigned long v;
+   /*
+* The AVA field omits the low-order 23 bits of the 78 bits VA.
+* These bits are not needed in the PTE, because the
+* low-order b of these bits are part of the byte offset
+* into the virtual page and, if b < 23, the high-order
+* 23-b of these bits are always used in selecting the
+* PTEGs to be searched
+*/
+   BUILD_BUG_ON(VPN_SHIFT > 23);
+   v = (vpn >> (23 - VPN_SHIFT)) & ~(mmu_psize_defs[psize].avpnm);
+   v <<= HPTE_V_AVPN_SHIFT;
+   v |= ((unsigned long) ssize) << HPTE_V_SSIZE_SHIFT;
+   return v;
+}
+
+/*
  * This function sets the AVPN and L fields of the HPTE  appropriately
  * for the page size
  */
@@ -187,11 +231,9 @@ static inline unsigned long hpte_encode_v(unsigned long 
va, int psize,
  int ssize)
 {
unsigned long v;
-   v = (va >> 23) & ~(mmu_psize_defs[psize].avpnm);
-   v <<= HPTE_V_AVPN_SHIFT;
+   v = hpte_encode_avpn(va, psize, ssize);
if (psize != MMU_PAGE_4K)
v |= HPTE_V_LARGE;
-   v |= ((unsigned long) ssize) << HPTE_V_SSIZE_SHIFT;
return v;
 }
 
@@ -216,14 +258,16 @@ static inline unsigned long hpte_encode_r(unsigned long 
pa, int psize)
 }
 
 /*
- * Build a VA given VSID, EA and segment size
+ * Build a VPN_SHIFT bit shifted va given VSID, EA and segment size.
  */
-static inline unsigned long hpt_va(unsigned long ea, unsigned long vsid,
+static inline unsigned long hpt_vpn(unsigned long ea, unsigned long vsid,
   int ssize)
 {
-   if (ssize == MMU_SEGSIZE_256M)
-   return (vsid << 28) | (ea & 0xfffUL);
-   return (vsid << 40) | (ea & 0xffUL);
+   unsigned long mask;
+   int s_shift = segment_shift(ssize);
+
+   mask = (1ul << (s_shift - VPN_SHIFT)) - 1;
+   return (vsid << (s_shift - VPN_SHIFT)) | ((ea >> VPN_SHIFT) & mask);
 }
 
 /*
@@ -233,13 +277,20 @@ static inline unsigned long hpt_va(unsigned long ea, 
unsigned long vsid,
 static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
 int ssize)
 {
+   int mask;
unsigned long hash, vsid;
 
+   BUG_ON(shift < VPN_SHIFT);
+
if (ssize == MMU_SEGSIZE_256M) {
-   hash = (va >> 28) ^ ((va & 0x0fffUL) >> shift);
+   mask = (1ul << (SID_SHIFT - VPN_SHIFT)) - 1;
+   hash = ((va >> (SI

[PATCH -V5 07/13] arch/powerpc: Make some of the PGTABLE_RANGE dependency explicit

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

slice array size and slice mask size depend on PGTABLE_RANGE. We
can't directly include pgtable.h in these header because there is
a circular dependency. So add compile time check for these values.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/mmu-hash64.h|   13 -
 arch/powerpc/include/asm/page_64.h   |   16 
 arch/powerpc/include/asm/pgtable-ppc64.h |8 
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index fe865fe..d24d484 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -422,6 +422,13 @@ extern void slb_set_size(u16 size);
srdirx,rx,VSID_BITS_##size; /* extract 2^VSID_BITS bit */   \
add rt,rt,rx
 
+/* 4 bits per slice and we have one slice per 1TB */
+#if 0 /* We can't directly include pgtable.h hence this hack */
+#define SLICE_ARRAY_SIZE  (PGTABLE_RANGE >> 41)
+#else
+/* Right now we only support 64TB */
+#define SLICE_ARRAY_SIZE  32
+#endif
 
 #ifndef __ASSEMBLY__
 
@@ -466,11 +473,7 @@ typedef struct {
 
 #ifdef CONFIG_PPC_MM_SLICES
u64 low_slices_psize;   /* SLB page size encodings */
-   /*
-* Right now we support 64TB and 4 bits for each
-* 1TB slice we need 32 bytes for 64TB.
-*/
-   unsigned char high_slices_psize[32];  /* 4 bits per slice for now */
+   unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
 #else
u16 sllp;   /* SLB page size encoding */
 #endif
diff --git a/arch/powerpc/include/asm/page_64.h 
b/arch/powerpc/include/asm/page_64.h
index 6c9bef4..5635acb 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -78,14 +78,22 @@ extern u64 ppc64_pft_size;
 #define GET_LOW_SLICE_INDEX(addr)  ((addr) >> SLICE_LOW_SHIFT)
 #define GET_HIGH_SLICE_INDEX(addr) ((addr) >> SLICE_HIGH_SHIFT)
 
+/* 1 bit per slice and we have one slice per 1TB */
+#if 0 /* We can't directly include pgtable.h hence this hack */
+#define SLICE_MASK_SIZE (PGTABLE_RANG >> 43)
+#else
+/*
+ * Right now we support only 64TB.
+ * IF we change this we will have to change the type
+ * of high_slices
+ */
+#define SLICE_MASK_SIZE 8
+#endif
+
 #ifndef __ASSEMBLY__
 
 struct slice_mask {
u16 low_slices;
-   /*
-* This should be derived out of PGTABLE_RANGE. For the current
-* max 64TB, u64 should be ok.
-*/
u64 high_slices;
 };
 
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h 
b/arch/powerpc/include/asm/pgtable-ppc64.h
index 8af1cf2..dea953f 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -32,6 +32,14 @@
 #endif
 #endif
 
+#if (PGTABLE_RANGE >> 41) > SLICE_ARRAY_SIZE
+#error PGTABLE_RANGE exceeds SLICE_ARRAY_SIZE
+#endif
+
+#if (PGTABLE_RANGE >> 43) > SLICE_MASK_SIZE
+#error PGTABLE_RANGE exceeds slice_mask high_slices size
+#endif
+
 /*
  * Define the address range of the kernel non-linear virtual area
  */
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 01/13] arch/powerpc: Use hpt_va to compute virtual address

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

Don't open code the same

Reviewed-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/platforms/cell/beat_htab.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/cell/beat_htab.c 
b/arch/powerpc/platforms/cell/beat_htab.c
index 943c9d3..b83077e 100644
--- a/arch/powerpc/platforms/cell/beat_htab.c
+++ b/arch/powerpc/platforms/cell/beat_htab.c
@@ -259,7 +259,7 @@ static void beat_lpar_hpte_updateboltedpp(unsigned long 
newpp,
u64 dummy0, dummy1;
 
vsid = get_kernel_vsid(ea, MMU_SEGSIZE_256M);
-   va = (vsid << 28) | (ea & 0x0fff);
+   va = hpt_va(ea, vsid, MMU_SEGSIZE_256M);
 
raw_spin_lock(&beat_htab_lock);
slot = beat_lpar_hpte_find(va, psize);
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 08/13] arch/powerpc: Use the rquired number of VSID bits in slbmte

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

ASM_VSID_SCRAMBLE can leave non-zero bits in the high 28 bits of the result
for 256MB segment (40 bits for 1T segment). Properly mask them before using
the values in slbmte

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/slb_low.S |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S
index c355af6..8e5c9bd 100644
--- a/arch/powerpc/mm/slb_low.S
+++ b/arch/powerpc/mm/slb_low.S
@@ -226,7 +226,11 @@ _GLOBAL(slb_allocate_user)
  */
 slb_finish_load:
ASM_VSID_SCRAMBLE(r10,r9,256M)
-   rldimi  r11,r10,SLB_VSID_SHIFT,16   /* combine VSID and flags */
+   /*
+* bits above VSID_BITS_256M need to be ignored from r10
+* also combine VSID and flags
+*/
+   rldimi  r11,r10,SLB_VSID_SHIFT,(64 - (SLB_VSID_SHIFT + VSID_BITS_256M))
 
/* r3 = EA, r11 = VSID data */
/*
@@ -290,7 +294,11 @@ _GLOBAL(slb_compare_rr_to_size)
 slb_finish_load_1T:
srdir10,r10,40-28   /* get 1T ESID */
ASM_VSID_SCRAMBLE(r10,r9,1T)
-   rldimi  r11,r10,SLB_VSID_SHIFT_1T,16/* combine VSID and flags */
+   /*
+* bits above VSID_BITS_1T need to be ignored from r10
+* also combine VSID and flags
+*/
+   rldimi  r11,r10,SLB_VSID_SHIFT_1T,(64 - (SLB_VSID_SHIFT_1T + 
VSID_BITS_1T))
li  r10,MMU_SEGSIZE_1T
rldimi  r11,r10,SLB_VSID_SSIZE_SHIFT,0  /* insert segment size */
 
-- 
1.7.10

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH -V5 04/13] arch/powerpc: Rename va to vpn

[Aneesh Kumar K.V]

From: "Aneesh Kumar K.V" 

Rename the variable to better reflect the values. No functional change
in this patch.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_book3s.h   |2 +-
 arch/powerpc/include/asm/machdep.h  |6 +--
 arch/powerpc/include/asm/mmu-hash64.h   |   23 
 arch/powerpc/include/asm/tlbflush.h |4 +-
 arch/powerpc/kvm/book3s_32_mmu_host.c   |8 +--
 arch/powerpc/kvm/book3s_64_mmu_host.c   |   17 +++---
 arch/powerpc/kvm/trace.h|   14 ++---
 arch/powerpc/mm/hash_native_64.c|   88 ---
 arch/powerpc/mm/hash_utils_64.c |   30 +--
 arch/powerpc/mm/hugetlbpage-hash64.c|   15 +++---
 arch/powerpc/mm/tlb_hash64.c|   11 ++--
 arch/powerpc/platforms/cell/beat_htab.c |   45 
 arch/powerpc/platforms/ps3/htab.c   |   22 
 arch/powerpc/platforms/pseries/lpar.c   |   60 +++--
 14 files changed, 177 insertions(+), 168 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index f0e0c6a..7aefdb3 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -59,7 +59,7 @@ struct hpte_cache {
struct hlist_node list_vpte;
struct hlist_node list_vpte_long;
struct rcu_head rcu_head;
-   u64 host_va;
+   u64 host_vpn;
u64 pfn;
ulong slot;
struct kvmppc_pte pte;
diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 42ce570..cd63f1a 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -34,19 +34,19 @@ struct machdep_calls {
char*name;
 #ifdef CONFIG_PPC64
void(*hpte_invalidate)(unsigned long slot,
-  unsigned long va,
+  unsigned long vpn,
   int psize, int ssize,
   int local);
long(*hpte_updatepp)(unsigned long slot, 
 unsigned long newpp, 
-unsigned long va,
+unsigned long vpn,
 int psize, int ssize,
 int local);
void(*hpte_updateboltedpp)(unsigned long newpp, 
   unsigned long ea,
   int psize, int ssize);
long(*hpte_insert)(unsigned long hpte_group,
-  unsigned long va,
+  unsigned long vpn,
   unsigned long prpn,
   unsigned long rflags,
   unsigned long vflags,
diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index 60f8596..e5af632 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -227,11 +227,11 @@ static inline unsigned long hpte_encode_avpn(unsigned 
long vpn, int psize,
  * This function sets the AVPN and L fields of the HPTE  appropriately
  * for the page size
  */
-static inline unsigned long hpte_encode_v(unsigned long va, int psize,
- int ssize)
+static inline unsigned long hpte_encode_v(unsigned long vpn,
+ int psize, int ssize)
 {
unsigned long v;
-   v = hpte_encode_avpn(va, psize, ssize);
+   v = hpte_encode_avpn(vpn, psize, ssize);
if (psize != MMU_PAGE_4K)
v |= HPTE_V_LARGE;
return v;
@@ -260,8 +260,8 @@ static inline unsigned long hpte_encode_r(unsigned long pa, 
int psize)
 /*
  * Build a VPN_SHIFT bit shifted va given VSID, EA and segment size.
  */
-static inline unsigned long hpt_vpn(unsigned long ea, unsigned long vsid,
-  int ssize)
+static inline unsigned long hpt_vpn(unsigned long ea,
+   unsigned long vsid, int ssize)
 {
unsigned long mask;
int s_shift = segment_shift(ssize);
@@ -273,9 +273,8 @@ static inline unsigned long hpt_vpn(unsigned long ea, 
unsigned long vsid,
 /*
  * This hashes a virtual address
  */
-
-static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
-int ssize)
+static inline unsigned long hpt_hash(unsigned long vpn,
+unsigned int shift, int ssize)
 {
int mask;
unsigned long hash, vsid;
@@ -284,13 +283,13 @@ static inline unsigned long hpt_hash(unsigned long va, 
unsigned int shift,
 
if (ssize == MMU_SEGSIZE_256M) {
mask = (1ul << (SID_SHIF

RE: [2/3][PATCH][v2] TDM Framework

[Singh Sandeep-B37400]

Thanks for your comments.
Please find my response inline.

Regards,
Sandeep


-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Friday, July 27, 2012 8:22 PM
To: Singh Sandeep-B37400
Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; 
de...@driverdev.osuosl.org; ga...@kernel.crashing.org; 
linux-ker...@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework

On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> +static DEFINE_MUTEX(tdm_core_lock);
> +static DEFINE_IDR(tdm_adapter_idr);
> +/* List of TDM adapters registered with TDM framework */ 
> +LIST_HEAD(adapter_list);
> +
> +/* List of TDM clients registered with TDM framework */ 
> +LIST_HEAD(driver_list);

These two are far too generic to be public.  Have you checked your code with 
sparse?  I think not.
[Sandeep] Will changes the name to be more appropriate. Right, I haven't 
checked with sparse.

> +
> +/*
> + * In case the previous data is not fetched by the client driver, the
> + * de-interleaving function will  discard the old data and rewrite 
> +the
> + * new data
> + */
> +
> +static int use_latest_tdm_data = 1;
> +
> +/* Data structures required for sysfs */ static struct tdm_sysfs attr 
> += {
> + .attr.name = "use_latest_data",
> + .attr.mode = 0664,
> + .cmd_type = TDM_LATEST_DATA,
> +};
> +
> +static struct attribute *tdm_attr[] = {
> + &attr.attr,
> + NULL
> +};
> +
> +const struct sysfs_ops tdm_ops = {
> + .show = tdm_show_sysfs,
> + .store = tdm_store_sysfs,
> +};

Again, lack of static.
[Sandeep] Ok

> +
> +static struct kobj_type tdm_type = {
> + .sysfs_ops = &tdm_ops,
> + .default_attrs = tdm_attr,
> +};
> +
> +/* tries to match client driver with the adapter */ static int 
> +tdm_device_match(struct tdm_driver *driver, struct tdm_adapter *adap) 
> +{
> + /* match on an id table if there is one */
> + if (driver->id_table && driver->id_table->name[0]) {
> + if (!(strcmp(driver->id_table->name, adap->name)))
> + return (int)driver->id_table;

Casting a pointer to 'int' is not a good thing to do.  Please fix this.
[Sandeep] Will fix this.

> + }
> + return 0;
> +}
> +
> +static int tdm_attach_driver_adap(struct tdm_driver *driver,
> + struct tdm_adapter *adap)
> +{
> + int ret = 0;
> + /* if driver is already attached to any other adapter, return*/
> + if (driver->adapter && (driver->adapter != adap))

Additional parens not required.
[Sandeep] Ok

> + return 0;
> +
> + driver->adapter = adap;
> +
> + if (driver->attach_adapter) {
> + ret = driver->attach_adapter(adap);
> + if (ret < 0) {
> + pr_err("tdm: attach_adapter failed for driver [%s]"
> + "err:%d\n", driver->name, ret);
> + return ret;
> + }
> + }
> + adap->drv_count++;
> +
> + if (!adap->tasklet_conf) {
> + tdm_sysfs_init();
> + tasklet_init(&adap->tdm_data_tasklet, tdm_data_tasklet_fn,
> + (unsigned long)adap);

Why not init this tasklet when the struct tdm_adapter is first created?
Why do you need to wait, and then have state tracking for this?
[Sandeep] Ok, will take care

> + adap->tasklet_conf = 1;
> + }
> +
> + return ret;
> +}
> +
> +/* Detach client driver and adapter */ static int 
> +tdm_detach_driver_adap(struct tdm_driver *driver,
> + struct tdm_adapter *adap)
> +{
> + int res = 0;
> +
> + if (!driver->adapter || (driver->adapter != adap))

Additional parens not required.
[Sandeep] Ok.

> + return 0;
> +
> + adap->drv_count--;
> +
> + /* If no more driver is registed with the adapter*/
> + if (!adap->drv_count && adap->tasklet_conf) {
> + tasklet_disable(&adap->tdm_data_tasklet);
> + tasklet_kill(&adap->tdm_data_tasklet);
> + adap->tasklet_conf = 0;
> + }
> +
> + if (driver->detach_adapter) {
> + if (driver->detach_adapter(adap))
> + pr_err("tdm: detach_adapter failed for driver [%s]\n",
> + driver->name);
> + }
> +
> + driver->adapter = NULL;
> + return res;
> +}
> +
> +/* TDM adapter Registration/De-registration with TDM framework */
> +
> +static int tdm_register_adapter(struct tdm_adapter *adap) {
> + int res = 0;
> + struct tdm_driver *driver, *next;
> +
> + mutex_init(&adap->adap_lock);
> + INIT_LIST_HEAD(&adap->myports);
> + spin_lock_init(&adap->portlist_lock);
> +
> + adap->drv_count = 0;
> + adap->tasklet_conf = 0;
> +
> + list_add_tail(&adap->list, &adapter_list);

What protects this list?
[Sandeep] Ok, will take care

> +
> + /* initialization of driver by framework in default configuration */
> + init_config_adapter(adap);
> +
> + /*

RE: [2/3][PATCH][v2] TDM Framework

[John Stoffel]

> "Singh" == Singh Sandeep-B37400  writes:

Singh> -Original Message-
Singh> From: John Stoffel [mailto:j...@stoffel.org] 
Singh> Sent: 27 July 2012 19:42
Singh> To: Singh Sandeep-B37400
Singh> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; 
ga...@kernel.crashing.org; linux-ker...@vger.kernel.org; 
de...@driverdev.osuosl.org
Singh> Subject: Re: [2/3][PATCH][v2] TDM Framework


>> From: Sandeep Singh  TDM Framework is an 
>> attempt to provide a platform independent layer which can offer a 
>> standard interface  for TDM access to different client modules.

Singh> Please don't use TLAs (Three Letter Acronyms) like TDM without 
explaining the clearly and up front.  It makes it hard for anyone else who 
doens't know your code to look it over without having to spend lots of time 
poking around to figure it out from either context or somewhere else.

Singh> [Sandeep] Patch for documentation for TDM is present in this
Singh> patch set, which explains TDM in detail. Should we do this in
Singh> commit message too??  Link too documentation patch:
Singh> http://patchwork.ozlabs.org/patch/173680/

You should put the expansion of TDM into the initial commit message,
and also into the Kconfig text, so that someone configuring the kernel
has a clue what you're talking about.  

Try to approach this as a brandnew user who doesn't have your
knowledge of the software.  Write for the un-initiated if at all
possible.

John


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Kumar Gala]

On Jul 30, 2012, at 3:07 AM, Jia Hongtao-B38951 wrote:

>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Friday, July 27, 2012 8:47 PM
>> To: Jia Hongtao-B38951
>> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>> initialization code
>> 
>> 
>> On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
>> 
>>> 
>>> 
 -Original Message-
 From: Kumar Gala [mailto:ga...@kernel.crashing.org]
 Sent: Friday, July 27, 2012 2:15 AM
 To: Jia Hongtao-B38951
 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
 Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
 initialization code
 
 
 On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
 
> We unified the Freescale pci/pcie initialization by changing the
 fsl_pci
> to a platform driver. In previous PCI code architecture the
 initialization
> routine is called at board_setup_arch stage. Now the initialization
>> is
 done
> in probe function which is architectural better. Also It's convenient
 for
> adding PM support for PCI controller in later patch.
> 
> One issue introduced by this architecture is the timing of
>> swiotlb_init.
> During PCI initialization the need of swiotlb is determined and this
 should
> be done before swiotlb_init. So a new function to determine swiotlb
>> by
> parsing pci ranges is made. This function is called at
>> board_setup_arch
> stage which is earlier than swiotlb_init.
> 
> Signed-off-by: Jia Hongtao 
> Signed-off-by: Li Yang 
> ---
> Changed for V3:
> - Rebase the patch set on the latest tree
> - merge PCI unify and swiotlb patch into one
> 
> arch/powerpc/sysdev/fsl_pci.c |  155
>> --
 ---
> arch/powerpc/sysdev/fsl_pci.h |9 +--
> 2 files changed, 125 insertions(+), 39 deletions(-)
 
 I'd like the SWIOTLB refactoring as a separate patch.  Additionally,
>> the
 order of patches should be as follows:
 
 1. refactor PCI node parsing code
 2. add pci_determine_swiotlb (should rename to
>> fsl_pci_determine_swiotlb)
 3. Determine primary bus by looking for ISA node
 4. convert all boards over to fsl_pci_init
 5. convert fsl pci to platform driver (edac and other fixes should be
 merged in here)
 6. PM support
 
 - k
>>> 
>>> Should I convert all boards over to fsl_pci_init first and then convert
>> them
>>> over to platform driver again or just convert them direct to platform
>> driver?
>> 
>> Yes do the fsl_pci_init conversion first.  The reason is we should NOT
>> break functionality from one patch to another.
>> 
>> - k
> 
> 
> Actually, the functionality is not broken, other boards just use the old
> Way to init pci controller and it still works.

How do you figure?  The platform driver is going to get called on boards not 
yet converted.  So than you will get 2 different inits of PCI going on.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Kumar Gala]

On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:

> 
> 
>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Saturday, July 28, 2012 5:17 AM
>> To: Wood Scott-B07421
>> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
>> Li Yang-R58472
>> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>> initialization code
>> 
>> 
>> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
>> 
>>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
 Hi kumar,
 
 I know "duplicate code from pci_process_bridge_OF_ranges()" is
 hard to accept but "refactor the code to have a shared function"
 is knotty. Actually this is the reason I didn't do the refactor.
>>> 
>>> Maybe we should keep doing the init early?  We could still have a
>>> platform device for the PM stuff, but some init would be done before
>> probe.
>>> 
>>> Another possibility is to try to handle swiotlb init later -- possibly
>>> by reserving memory for it if the platform indicates it's a possibility
>>> that it will be needed, then freeing the memory if it's not needed.
>>> 
>>> -Scott
>> 
>> I think the first option seems reasonable.  Can we leave fsl_pci_init()
>> as we now have it and just have the platform driver deal with PM restore
>> via calling setup_pci_atmu() [probably need to update setup_pci_atmu to
>> handle restore case, but seems like minor changes]
>> 
>> - k
>> 
> 
> 
> I think the second option is better if it's hard to decouple swiotlb
> determination from pci init. I believe the better architecture that
> PCI init in probe function of platform driver will bring us considerable
> advantage. I really like to keep the completion of pci controller
> platform driver not only for PM support but also for pci init.
> 
> -Hongtao. 
> 

Shifting of swiotlb init has a lot more issues.  Why do we need to do the PCI 
init in probe?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [2/3][PATCH][v2] TDM Framework

[Greg KH]

On Mon, Jul 30, 2012 at 09:10:48AM +, Aggrwal Poonam-B10812 wrote:
> 
> 
> > -Original Message-
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Greg
> > KH
> > Sent: Friday, July 27, 2012 11:30 PM
> > To: Singh Sandeep-B37400
> > Cc: de...@driverdev.osuosl.org; linuxppc-dev@lists.ozlabs.org; linux-arm-
> > ker...@lists.infradead.org; linux-ker...@vger.kernel.org
> > Subject: Re: [2/3][PATCH][v2] TDM Framework
> > 
> > On Fri, Jul 27, 2012 at 07:35:38PM +0530, sand...@freescale.com wrote:
> > > +/* Data structures required for sysfs */ static struct tdm_sysfs attr
> > > += {
> > > + .attr.name = "use_latest_data",
> > > + .attr.mode = 0664,
> > > + .cmd_type = TDM_LATEST_DATA,
> > > +};
> > 
> > What is this for?
> This knob is to control the behavior of the TDM framework with respect
> to handling the received TDM frames.

How will userspace know how to use this?  Who will use this?

> The framework layer receives the TDM frames from the TDM adapter
> driver, de-interleaves the data and sends to respective client
> modules.

Why would userspace care about this then?

> In the case when the TDM client module has not consumed the data and
> emptied the Buffer, this flag decides whether to discard the
> un-fetched data, or discard the latest received data.

Again, why let userspace make this decision?  How will it know to do
this or not?

Don't add options for things that don't need options.

> > > +int tdm_sysfs_init(void)
> > > +{
> > > + struct kobject *tdm_kobj;
> > > + int err = 1;
> > > + tdm_kobj = kzalloc(sizeof(*tdm_kobj), GFP_KERNEL);
> > > + if (tdm_kobj) {
> > > + kobject_init(tdm_kobj, &tdm_type);
> > > + if (kobject_add(tdm_kobj, NULL, "%s", "tdm")) {
> > > + pr_err("tdm: Sysfs creation failed\n");
> > > + kobject_put(tdm_kobj);
> > > + err = -EINVAL;
> > > + goto out;
> > > + }
> > > + } else {
> > > + pr_err("tdm: Unable to allocate tdm_kobj\n");
> > > + err = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > +out:
> > > + return err;
> > > +}
> > 
> > You just leaked memory, what are you trying to do here?
> > 
> > And why are you using "raw" kobjects?  That's a sure sign that something
> > is really wrong.
> Will refer the documentation. Not very experienced on this stuff. Thanks for 
> the comment.
> > 
> > Your code doesn't look like it is tied into the driver model at all, why
> > not?  What are you trying to do here?
> This is a framework layer, not associated to a particular device.

Not true, you have a parent pointer already, so you are hooked up to the
device tree.

> TDM adapter drivers will register to this framework.

Then you had better be part of the kernel driver model.

> We got this comment in internal freescale review list also.

Why did you ignore that feedback and make us ask the same thing?

> > Also, when creating new sysfs entries, like you are attempting to do here
> > (unsuccessfully I might add), you must create Documentation/ABI/ files as
> > well.
> Ok.
> > 
> > And, to top it all off, you do realize you are asking us to do code
> > review in the middle of the merge window, when we are all busy doing
> > other things?
> Apologize for asking a review in the merge window time frame.
> Are there any guidelines when to send something for a review? We will
> be careful next time.

Anytime not in the merge window is usually good, also the week before
the merge window is usually busy as well.

greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [2/3][PATCH][v2] TDM Framework

[Mark Brown]

On Fri, Jul 27, 2012 at 05:25:42PM +0200, Francois Romieu wrote:

> 2. It would probably make sense to Cc: netdev and serial. There may be
>some kernel client network integration from the start.

Plus audio, quite a few of the buses mentioned as examples of use cases
for the hardware are audio ones.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [2/3][PATCH][v2] TDM Framework

[Greg KH]

On Mon, Jul 30, 2012 at 09:50:57AM +, Singh Sandeep-B37400 wrote:
> 1. You should send some kernel mode TDM clients. Without those the framework
>is pretty useless.
> [Sandeep] We do have a test client but not good enough to be pushed in
> open source, should we add it to documentation?? 

Then how do you know if the framework is "correct" and good enough for
real clients?  We don't add frameworks, or apis, to the kernel without
users, so you will have to come up with some users before we can accept
it.

greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [linuxppc-release] [PATCH v4 7/7] fsl-dma: add memcpy self test interface

[Timur Tabi]

qiang@freescale.com wrote:
> 
> Add memory copy self test when probe device, fsl-dma will be disabled
> if self test failed.

Is this a real problem that can occur?  The DMA driver used to have a
self-test, but I removed it a long time ago because it was pointless.  I
don't see why we need to add another one back in.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [linuxppc-release] [PATCH v4 7/7] fsl-dma: add memcpy self test interface

[Ira W. Snyder]

On Mon, Jul 30, 2012 at 12:48:41PM -0500, Timur Tabi wrote:
> qiang@freescale.com wrote:
> > 
> > Add memory copy self test when probe device, fsl-dma will be disabled
> > if self test failed.
> 
> Is this a real problem that can occur?  The DMA driver used to have a
> self-test, but I removed it a long time ago because it was pointless.  I
> don't see why we need to add another one back in.
> 
> -- 
> Timur Tabi
> Linux kernel developer at Freescale
> 

I made a comment that a test suite for the async_tx API would be very
helpful in diagnosing similar problems in this and other DMA drivers.
Something standalone, similar to the drivers/dma/dmatest.c driver, using
the async_tx API.

I think this was misinterpreted into me asking that the driver have a
built-in self test.

Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic

[Olaf Hering]

On Mon, Jul 30, Benjamin Herrenschmidt wrote:

> On Wed, 2012-07-18 at 18:49 +0200, o...@aepfle.de wrote:
> > From: Olaf Hering 
> > 
> > The driver is named ibmvscsic, at runtime it its name is advertised as
> > ibmvscsi. For this reason mkinitrd wont pickup the driver properly.
> > Reported by IBM during SLES11 beta testing:
> > 
> > https://bugzilla.novell.com/show_bug.cgi?id=459933
> > LTC50724
> 
> So while this would work, I do wonder however whether we could instead
> fix it by simplifying the whole thing as follow since iSeries is now
> gone and so we don't need split backends anymore:
> 
> scsi/ibmvscsi: Remove backend abstraction

I cant that these things myself anymore.

Olaf
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 3/7] fsl-dma: change release process of dma descriptor for supporting async_tx

[Ira W. Snyder]

On Fri, Jul 27, 2012 at 05:16:09PM +0800, qiang@freescale.com wrote:
> From: Qiang Liu 
> 
> Fix the potential risk when enable config NET_DMA and ASYNC_TX.
> Async_tx is lack of support in current release process of dma descriptor,
> all descriptors will be released whatever is acked or no-acked by async_tx,
> so there is a potential race condition when dma engine is uesd by others
> clients (e.g. when enable NET_DMA to offload TCP).
> 
> In our case, a race condition which is raised when use both of talitos
> and dmaengine to offload xor is because napi scheduler will sync all
> pending requests in dma channels, it affects the process of raid operations
> due to ack_tx is not checked in fsl dma. The no-acked descriptor is freed
> which is submitted just now, as a dependent tx, this freed descriptor trigger
> BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
> 

I'm preparing an alternative version of this patch that I think is
easier to understand (it is much shorter). I'll post it up here as soon
as I finish testing.

It would be nice to know how to easily reproduce this bug, without
needing to set up a RAID system. I don't have access to any such
hardware. A driver similar to drivers/dma/dmatest.c (using the async_tx
API instead) would be wonderful.

Thanks,
Ira

> TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
> GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4  
> 0001
> GPR08:  a7a7a7a7 0001 045/92002 42028042 100a38d4 ed576d98 
> 
> GPR16: ed5a11b0  2b162000 0200 046/92000 2d555000 ed3015e8 
> c15a7aa0
> GPR24:  c155fc40  ecb63220 ecf41d28 e47/92f640bb0 ef640c30 
> ecf41ca0
> NIP [c02b048c] async_tx_submit+0x6c/0x2b4
> LR [c02b068c] async_tx_submit+0x26c/0x2b4
> Call Trace:
> [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
> [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
> [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
> [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> [ecf41f90] [c008277c] kthread+0x8c/0x90
> [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
> 
> Cc: Dan Williams 
> Cc: Vinod Koul 
> Cc: Li Yang 
> Cc: Ira W. Snyder 
> Signed-off-by: Qiang Liu 
> ---
>  drivers/dma/fsldma.c |  242 
> +++---
>  drivers/dma/fsldma.h |1 +
>  2 files changed, 172 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 4f2f212..87f52c0 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -400,6 +400,125 @@ out_splice:
>   list_splice_tail_init(&desc->tx_list, &chan->ld_pending);
>  }
> 
> +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan);
> +static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan);
> +
> +/**
> + * fsldma_clean_completed_descriptor - free all descriptors which
> + * has been completed and acked
> + * @chan: Freescale DMA channel
> + *
> + * This function is used on all completed and acked descriptors.
> + * All descriptors should only be freed in this function.
> + */
> +static int
> +fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
> +{
> + struct fsl_desc_sw *desc, *_desc;
> +
> + /* Run the callback for each descriptor, in order */
> + list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node) {
> +
> + if (async_tx_test_ack(&desc->async_tx)) {
> + /* Remove from the list of transactions */
> + list_del(&desc->node);
> +#ifdef FSL_DMA_LD_DEBUG
> + chan_dbg(chan, "LD %p free\n", desc);
> +#endif
> + dma_pool_free(chan->desc_pool, desc,
> + desc->async_tx.phys);
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * fsldma_run_tx_complete_actions - cleanup and free a single link descriptor
> + * @chan: Freescale DMA channel
> + * @desc: descriptor to cleanup and free
> + * @cookie: Freescale DMA transaction identifier
> + *
> + * This function is used on a descriptor which has been executed by the DMA
> + * controller. It will run any callbacks, submit any dependencies.
> + */
> +static dma_cookie_t fsldma_run_tx_complete_actions(struct fsl_desc_sw *desc,
> + struct fsldma_chan *chan, dma_cookie_t cookie)
> +{
> + struct dma_async_tx_descriptor *txd = &desc->async_tx;
> + struct device *dev = chan->common.device->dev;
> + dma_addr_t src = get_desc_src(chan, desc);
> + dma_addr_t dst = get_desc_dst(chan, desc);
> + u32 len = get_desc_cnt(chan, desc);
> +
> + BUG_ON(txd->cookie < 0);
> +
> + if (txd->cookie > 0) {
> + cookie = txd->cookie;
> +
> + /* Run the link descriptor callback function */
> + if (txd->callback) {
> +#ifdef FSL_DMA_LD_DEBUG
> 

[PATCH] KVM: PPC: Book3S_32: Fix MTMSR_EERI macro

[Alexander Graf]

Commit b38c77d82e4 moved the MTMSR_EERI macro from the KVM code to generic
ppc_asm.h code. However, while adding it in the headers for the ppc32 case,
it missed out to remove the former definition in the KVM code.

This patch fixes compilation on server type PPC32 targets with CONFIG_KVM
enabled.

Signed-off-by: Alexander Graf 
---
 arch/powerpc/kvm/book3s_rmhandlers.S |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S 
b/arch/powerpc/kvm/book3s_rmhandlers.S
index ab523f3..9ecf6e3 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -67,7 +67,6 @@ kvmppc_skip_Hinterrupt:
 #elif defined(CONFIG_PPC_BOOK3S_32)
 
 #define FUNC(name) name
-#define MTMSR_EERI(reg)mtmsr   (reg)
 
 .macro INTERRUPT_TRAMPOLINE intno
 
-- 
1.6.0.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Jia Hongtao-B38951]

> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Monday, July 30, 2012 10:47 PM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
> 
> 
> On Jul 30, 2012, at 3:07 AM, Jia Hongtao-B38951 wrote:
> 
> >> -Original Message-
> >> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> >> Sent: Friday, July 27, 2012 8:47 PM
> >> To: Jia Hongtao-B38951
> >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
> >> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> >> initialization code
> >>
> >>
> >> On Jul 27, 2012, at 3:35 AM, Jia Hongtao-B38951 wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>  Sent: Friday, July 27, 2012 2:15 AM
>  To: Jia Hongtao-B38951
>  Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Li Yang-R58472
>  Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
>  initialization code
> 
> 
>  On Jul 26, 2012, at 7:30 AM, Jia Hongtao wrote:
> 
> > We unified the Freescale pci/pcie initialization by changing the
>  fsl_pci
> > to a platform driver. In previous PCI code architecture the
>  initialization
> > routine is called at board_setup_arch stage. Now the initialization
> >> is
>  done
> > in probe function which is architectural better. Also It's
> convenient
>  for
> > adding PM support for PCI controller in later patch.
> >
> > One issue introduced by this architecture is the timing of
> >> swiotlb_init.
> > During PCI initialization the need of swiotlb is determined and
> this
>  should
> > be done before swiotlb_init. So a new function to determine swiotlb
> >> by
> > parsing pci ranges is made. This function is called at
> >> board_setup_arch
> > stage which is earlier than swiotlb_init.
> >
> > Signed-off-by: Jia Hongtao 
> > Signed-off-by: Li Yang 
> > ---
> > Changed for V3:
> > - Rebase the patch set on the latest tree
> > - merge PCI unify and swiotlb patch into one
> >
> > arch/powerpc/sysdev/fsl_pci.c |  155
> >> --
>  ---
> > arch/powerpc/sysdev/fsl_pci.h |9 +--
> > 2 files changed, 125 insertions(+), 39 deletions(-)
> 
>  I'd like the SWIOTLB refactoring as a separate patch.  Additionally,
> >> the
>  order of patches should be as follows:
> 
>  1. refactor PCI node parsing code
>  2. add pci_determine_swiotlb (should rename to
> >> fsl_pci_determine_swiotlb)
>  3. Determine primary bus by looking for ISA node
>  4. convert all boards over to fsl_pci_init
>  5. convert fsl pci to platform driver (edac and other fixes should
> be
>  merged in here)
>  6. PM support
> 
>  - k
> >>>
> >>> Should I convert all boards over to fsl_pci_init first and then
> convert
> >> them
> >>> over to platform driver again or just convert them direct to platform
> >> driver?
> >>
> >> Yes do the fsl_pci_init conversion first.  The reason is we should NOT
> >> break functionality from one patch to another.
> >>
> >> - k
> >
> >
> > Actually, the functionality is not broken, other boards just use the
> old
> > Way to init pci controller and it still works.
> 
> How do you figure?  The platform driver is going to get called on boards
> not yet converted.  So than you will get 2 different inits of PCI going
> on.
> 
> - k

In Scott's patch set no platform driver used. fsl_pci_init is just a unified
routine function for all boards to call. Now other boards in which fsl_pci_init
is not called just use the old way to init.

-Hongtao.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [linuxppc-release] [PATCH v4 7/7] fsl-dma: add memcpy self test interface

[Liu Qiang-B32616]

> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Ira W. Snyder
> Sent: Tuesday, July 31, 2012 2:33 AM
> To: Tabi Timur-B04825
> Cc: Liu Qiang-B32616; linux-cry...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Vinod Koul; herb...@gondor.hengli.com.au; Dan
> Williams; Li Yang-R58472; da...@davemloft.net
> Subject: Re: [linuxppc-release] [PATCH v4 7/7] fsl-dma: add memcpy self
> test interface
> 
> On Mon, Jul 30, 2012 at 12:48:41PM -0500, Timur Tabi wrote:
> > qiang@freescale.com wrote:
> > >
> > > Add memory copy self test when probe device, fsl-dma will be disabled
> > > if self test failed.
> >
> > Is this a real problem that can occur?  The DMA driver used to have a
> > self-test, but I removed it a long time ago because it was pointless.
> I
> > don't see why we need to add another one back in.
> >
> > --
> > Timur Tabi
> > Linux kernel developer at Freescale
> >
> 
> I made a comment that a test suite for the async_tx API would be very
> helpful in diagnosing similar problems in this and other DMA drivers.
> Something standalone, similar to the drivers/dma/dmatest.c driver, using
> the async_tx API.
> 
> I think this was misinterpreted into me asking that the driver have a
> built-in self test.
I will drop it in next version. Thanks.

> 
> Ira
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] scsi/ibmvscsi: add module alias for ibmvscsic

[Benjamin Herrenschmidt]

On Mon, 2012-07-30 at 21:06 +0200, Olaf Hering wrote:
> > So while this would work, I do wonder however whether we could
> instead
> > fix it by simplifying the whole thing as follow since iSeries is now
> > gone and so we don't need split backends anymore:
> > 
> > scsi/ibmvscsi: Remove backend abstraction
> 
> I cant that these things myself anymore.

Brian, can somebody from your side own these ?

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 3/7] fsl-dma: change release process of dma descriptor for supporting async_tx

[Liu Qiang-B32616]

> -Original Message-
> From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> Sent: Tuesday, July 31, 2012 5:10 AM
> To: Liu Qiang-B32616
> Cc: linux-cry...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Phillips
> Kim-R1AAHA; herb...@gondor.hengli.com.au; da...@davemloft.net; Dan
> Williams; Vinod Koul; Li Yang-R58472
> Subject: Re: [PATCH v4 3/7] fsl-dma: change release process of dma
> descriptor for supporting async_tx
> 
> On Fri, Jul 27, 2012 at 05:16:09PM +0800, qiang@freescale.com wrote:
> > From: Qiang Liu 
> >
> > Fix the potential risk when enable config NET_DMA and ASYNC_TX.
> > Async_tx is lack of support in current release process of dma
> descriptor,
> > all descriptors will be released whatever is acked or no-acked by
> async_tx,
> > so there is a potential race condition when dma engine is uesd by
> others
> > clients (e.g. when enable NET_DMA to offload TCP).
> >
> > In our case, a race condition which is raised when use both of talitos
> > and dmaengine to offload xor is because napi scheduler will sync all
> > pending requests in dma channels, it affects the process of raid
> operations
> > due to ack_tx is not checked in fsl dma. The no-acked descriptor is
> freed
> > which is submitted just now, as a dependent tx, this freed descriptor
> trigger
> > BUG_ON(async_tx_test_ack(depend_tx)) in async_tx_submit().
> >
> 
> I'm preparing an alternative version of this patch that I think is
> easier to understand (it is much shorter). I'll post it up here as soon
> as I finish testing.
Can you give a simple description/idea about your patch? My patch is for fix the
problems when I build a raid environment with talitos offload xor.
I think the new interface is clear enough and similar with the implement of 
other dma devices.

And do you have any comments about this patch?

> 
> It would be nice to know how to easily reproduce this bug, without
> needing to set up a RAID system. I don't have access to any such
> hardware. A driver similar to drivers/dma/dmatest.c (using the async_tx
> API instead) would be wonderful.
You can refer to raid5.c if you do not want to use hardware. Or you can use
you ram (or other storage devices) to build a raid env to test.
Thanks.

> 
> Thanks,
> Ira
> 
> > TASK = ee1a94a0[1390] 'md0_raid5' THREAD: ecf4 CPU: 0
> > GPR00: 0001 ecf41ca0 ee44/921a94a0 003f 0001 c00593e4
>  0001
> > GPR08:  a7a7a7a7 0001 045/92002 42028042 100a38d4
> ed576d98 
> > GPR16: ed5a11b0  2b162000 0200 046/92000 2d555000
> ed3015e8 c15a7aa0
> > GPR24:  c155fc40  ecb63220 ecf41d28 e47/92f640bb0
> ef640c30 ecf41ca0
> > NIP [c02b048c] async_tx_submit+0x6c/0x2b4
> > LR [c02b068c] async_tx_submit+0x26c/0x2b4
> > Call Trace:
> > [ecf41ca0] [c02b068c] async_tx_submit+0x26c/0x2b448/92 (unreliable)
> > [ecf41cd0] [c02b0a4c] async_memcpy+0x240/0x25c
> > [ecf41d20] [c0421064] async_copy_data+0xa0/0x17c
> > [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> > [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> > [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> > [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> > [ecf41f90] [c008277c] kthread+0x8c/0x90
> > [ecf41ff0] [c0011630] kernel_thread+0x4c/0x68
> >
> > Cc: Dan Williams 
> > Cc: Vinod Koul 
> > Cc: Li Yang 
> > Cc: Ira W. Snyder 
> > Signed-off-by: Qiang Liu 
> > ---
> >  drivers/dma/fsldma.c |  242 +++---
> 
> >  drivers/dma/fsldma.h |1 +
> >  2 files changed, 172 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > index 4f2f212..87f52c0 100644
> > --- a/drivers/dma/fsldma.c
> > +++ b/drivers/dma/fsldma.c
> > @@ -400,6 +400,125 @@ out_splice:
> > list_splice_tail_init(&desc->tx_list, &chan->ld_pending);
> >  }
> >
> > +static void fsldma_cleanup_descriptor(struct fsldma_chan *chan);
> > +static void fsl_chan_xfer_ld_queue(struct fsldma_chan *chan);
> > +
> > +/**
> > + * fsldma_clean_completed_descriptor - free all descriptors which
> > + * has been completed and acked
> > + * @chan: Freescale DMA channel
> > + *
> > + * This function is used on all completed and acked descriptors.
> > + * All descriptors should only be freed in this function.
> > + */
> > +static int
> > +fsldma_clean_completed_descriptor(struct fsldma_chan *chan)
> > +{
> > +   struct fsl_desc_sw *desc, *_desc;
> > +
> > +   /* Run the callback for each descriptor, in order */
> > +   list_for_each_entry_safe(desc, _desc, &chan->ld_completed, node) {
> > +
> > +   if (async_tx_test_ack(&desc->async_tx)) {
> > +   /* Remove from the list of transactions */
> > +   list_del(&desc->node);
> > +#ifdef FSL_DMA_LD_DEBUG
> > +   chan_dbg(chan, "LD %p free\n", desc);
> > +#endif
> > +   dma_pool_free(chan->desc_pool, desc,
> > +   desc->async_tx.phys);
> > +   }
> > +   }
> > +
> > +   return 0;

3.5+: yaboot, Invalid memory access

[Christian Kujau]

Hi,

when trying to upgrade from 3.5 (final) to today's git checkout from 
Linus' tree, yaboot cannot boot and the following is printed:

  [...]
  returning from prom_init
  Invalid memory access at %SRR0: 00c62fd4  %SRR1: 3030

The whole message: http://nerdbynature.de/bits/3.5.0/yaboot/

The Yaboot version is 1.3.16 (from Debian/testing), I haven't tried 1.3.17 
yet, its changelog does not say anything about "newer kernel support" so 
I'm not sure if this would help here.

Any other ideas?

Thanks,
Christian.
-- 
BOFH excuse #389:

/dev/clue was linked to /dev/null
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie initialization code

[Jia Hongtao-B38951]

> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Monday, July 30, 2012 10:47 PM
> To: Jia Hongtao-B38951
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> initialization code
> 
> 
> On Jul 30, 2012, at 3:26 AM, Jia Hongtao-B38951 wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> >> Sent: Saturday, July 28, 2012 5:17 AM
> >> To: Wood Scott-B07421
> >> Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; Wood Scott-
> B07421;
> >> Li Yang-R58472
> >> Subject: Re: [PATCH V3 1/5] powerpc/fsl-pci: Unify pci/pcie
> >> initialization code
> >>
> >>
> >> On Jul 27, 2012, at 3:24 PM, Scott Wood wrote:
> >>
> >>> On 07/27/2012 05:10 AM, Jia Hongtao-B38951 wrote:
>  Hi kumar,
> 
>  I know "duplicate code from pci_process_bridge_OF_ranges()" is
>  hard to accept but "refactor the code to have a shared function"
>  is knotty. Actually this is the reason I didn't do the refactor.
> >>>
> >>> Maybe we should keep doing the init early?  We could still have a
> >>> platform device for the PM stuff, but some init would be done before
> >> probe.
> >>>
> >>> Another possibility is to try to handle swiotlb init later --
> possibly
> >>> by reserving memory for it if the platform indicates it's a
> possibility
> >>> that it will be needed, then freeing the memory if it's not needed.
> >>>
> >>> -Scott
> >>
> >> I think the first option seems reasonable.  Can we leave fsl_pci_init()
> >> as we now have it and just have the platform driver deal with PM
> restore
> >> via calling setup_pci_atmu() [probably need to update setup_pci_atmu
> to
> >> handle restore case, but seems like minor changes]
> >>
> >> - k
> >>
> >
> >
> > I think the second option is better if it's hard to decouple swiotlb
> > determination from pci init. I believe the better architecture that
> > PCI init in probe function of platform driver will bring us
> considerable
> > advantage. I really like to keep the completion of pci controller
> > platform driver not only for PM support but also for pci init.
> >
> > -Hongtao.
> >
> 
> Shifting of swiotlb init has a lot more issues.  Why do we need to do the
> PCI init in probe?
> 
> - k

I investigated the swiotlb init thing and found that in x86 swiotlb init is
done first and free if we don't need it.

-Hongtao.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Singh Sandeep-B37400]

-Original Message-
From: John Stoffel [mailto:j...@stoffel.org] 
Sent: Monday, July 30, 2012 7:40 PM
To: Singh Sandeep-B37400
Cc: John Stoffel; linuxppc-dev@lists.ozlabs.org; 
linux-arm-ker...@lists.infradead.org; ga...@kernel.crashing.org; 
linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org
Subject: RE: [2/3][PATCH][v2] TDM Framework

> "Singh" == Singh Sandeep-B37400  writes:

Singh> -Original Message-
Singh> From: John Stoffel [mailto:j...@stoffel.org]
Singh> Sent: 27 July 2012 19:42
Singh> To: Singh Sandeep-B37400
Singh> Cc: linuxppc-dev@lists.ozlabs.org; 
Singh> linux-arm-ker...@lists.infradead.org; ga...@kernel.crashing.org; 
Singh> linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org
Singh> Subject: Re: [2/3][PATCH][v2] TDM Framework


>> From: Sandeep Singh  TDM Framework is an 
>> attempt to provide a platform independent layer which can offer a 
>> standard interface  for TDM access to different client modules.

Singh> Please don't use TLAs (Three Letter Acronyms) like TDM without 
explaining the clearly and up front.  It makes it hard for anyone else who 
doens't know your code to look it over without having to spend lots of time 
poking around to figure it out from either context or somewhere else.

Singh> [Sandeep] Patch for documentation for TDM is present in this 
Singh> patch set, which explains TDM in detail. Should we do this in 
Singh> commit message too??  Link too documentation patch:
Singh> http://patchwork.ozlabs.org/patch/173680/

You should put the expansion of TDM into the initial commit message, and also 
into the Kconfig text, so that someone configuring the kernel has a clue what 
you're talking about.  
[Sandeep] Thanks for suggestion. Will take care.

Try to approach this as a brandnew user who doesn't have your knowledge of the 
software.  Write for the un-initiated if at all possible.


John




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [2/3][PATCH][v2] TDM Framework

[Singh Sandeep-B37400]

-Original Message-
From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] 
Sent: Monday, July 30, 2012 9:16 PM
To: Francois Romieu
Cc: Singh Sandeep-B37400; de...@driverdev.osuosl.org; 
linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; 
linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org
Subject: Re: [2/3][PATCH][v2] TDM Framework

On Fri, Jul 27, 2012 at 05:25:42PM +0200, Francois Romieu wrote:

> 2. It would probably make sense to Cc: netdev and serial. There may be
>some kernel client network integration from the start.

Plus audio, quite a few of the buses mentioned as examples of use cases for the 
hardware are audio ones.
[Sandeep] Ok


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev