Re: [PATCH v2] powerpc, 5200: add support for charon board
Is it possible to add to the mpc5200_defconfig, what is needed for this board to compile a kernel which contains all features it needs? Just add it as modules. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
Hello. On 09-12-2010 3:32, tma...@apm.com wrote: From: Tirumala Marritma...@apm.com Enable gadget support Signed-off-by: Tirumala R Marritma...@apm.com Signed-off-by: Fushen Chenfc...@apm.com Signed-off-by: Mark Miesfeldmmiesf...@apm.com [...] diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 747b0d3..b2bcc4e 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC [...] +config USB_OTG + boolean OTG Support This symbol is already defined in drivers/usb/core/Kconfig. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
Hi Heiko, On Thu, Dec 09, 2010 at 07:49:45AM +0100, Heiko Schocher wrote: Hello Paul, Paul Mundt wrote: On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote: - add binding to OF, compatible name smi,sm501 [...] Documentation/kernel-parameters.txt |7 + Documentation/powerpc/dts-bindings/sm501.txt | 30 +++ drivers/mfd/sm501.c | 141 -- drivers/video/sm501fb.c | 264 +- include/linux/sm501.h|8 + 5 files changed, 299 insertions(+), 151 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt Given that this is all SM501 dependent, is there some particular reason why you neglected to Cc the author or the MFD folks? Hups, sorry! No, there is no reason, thanks for detecting this. Hmm.. couldn;t find a MFD maillinglist? We use lkml. Could you please re-send the patch to me ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 6/7 v2] ppc/iommu: pass phb only to iommu_table_setparms_lpar
On 09.12.2010 [15:24:39 +1100], Benjamin Herrenschmidt wrote:
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
iommu_table_setparms_lpar needs either the phb or the subbusnumber
(not both), pass the phb to make it similar to iommu_table_setparms.
Note: In cases where a caller was passing bus-number previously to
iommu_table_setparms_lpar() rather than phb-bus-number, this can lead
to a different value in tbl-it_busno. The only example of this was the
removed pci_dma_dev_setup_pSeriesLP(), removed in ppc/iommu: remove
unneeded pci_dma_dev_setup_pSeriesLP.
Signed-off-by: Milton Miller milt...@bga.com
Signed-off-by: Nishanth Aravamudan n...@us.ibm.com
---
arch/powerpc/platforms/pseries/iommu.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 9d564b9..45c6865 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -323,14 +323,13 @@ static void iommu_table_setparms(struct
pci_controller *phb,
static void iommu_table_setparms_lpar(struct pci_controller *phb,
struct device_node *dn,
struct iommu_table *tbl,
- const void *dma_window,
- int bussubno)
+ const void *dma_window)
{
unsigned long offset, size;
- tbl-it_busno = bussubno;
of_parse_dma_window(dn, dma_window, tbl-it_index, offset, size);
+ tbl-it_busno = phb-bus-number;
tbl-it_base = 0;
tbl-it_blocksize = 16;
tbl-it_type = TCE_PCI;
@@ -534,8 +533,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev
*dev)
if (!pci-iommu_table) {
tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
pci-phb-node);
- iommu_table_setparms_lpar(pci-phb, pdn, tbl, dma_window,
- pci-phb-bus-number);
+ iommu_table_setparms_lpar(pci-phb, pdn, tbl, dma_window);
pci-iommu_table = iommu_init_table(tbl, pci-phb-node);
pr_debug( created table: %p\n, pci-iommu_table);
} else {
There's another caller :-) I've fixed that up locally and will push with
the fix.
Shoot! Thanks for catching that.
-Nish
--
Nishanth Aravamudan n...@us.ibm.com
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
Much nicer, thanks. Do you wish for me to apply this to the tree if it passes review? thanks, greg k-h Yes, please. Thanks, marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
On Thu, Dec 9, 2010 at 5:24 AM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. On 09-12-2010 3:32, tma...@apm.com wrote: From: Tirumala Marritma...@apm.com Enable gadget support Signed-off-by: Tirumala R Marritma...@apm.com Signed-off-by: Fushen Chenfc...@apm.com Signed-off-by: Mark Miesfeldmmiesf...@apm.com [...] diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 747b0d3..b2bcc4e 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC [...] +config USB_OTG + boolean OTG Support This symbol is already defined in drivers/usb/core/Kconfig. WBR, Sergei Sure I will fix that. Thx, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
On 09.12.2010 [15:17:06 +1100], Benjamin Herrenschmidt wrote:
On Tue, 2010-10-26 at 20:35 -0700, Nishanth Aravamudan wrote:
No much comments... I'm amazed how complex he firmware folks managed to
make this ...
static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned
long action, void *node)
{
int err = NOTIFY_OK;
struct device_node *np = node;
struct pci_dn *pci = PCI_DN(np);
+ struct direct_window *window;
switch (action) {
case PSERIES_RECONFIG_REMOVE:
if (pci pci-iommu_table)
iommu_free_table(pci-iommu_table, np-full_name);
+
+ spin_lock(direct_window_list_lock);
+ list_for_each_entry(window, direct_window_list, list) {
+ if (window-device == np) {
+ list_del(window-list);
+ break;
+ }
+ }
+ spin_unlock(direct_window_list_lock);
Should you also kfree the window ?
Yeah, looks like I should. I have a few other questions due to testing,
but I'll reply to my original e-mail with those.
Thanks for the review!
Nish
--
Nishanth Aravamudan n...@us.ibm.com
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
On 26.10.2010 [20:35:17 -0700], Nishanth Aravamudan wrote:
If firmware allows us to map all of a partition's memory for DMA on a
particular bridge, create a 1:1 mapping of that memory. Add hooks for
dealing with hotplug events. Dyanmic DMA windows can use larger than the
default page size, and we use the largest one possible.
Not-yet-signed-off-by: Nishanth Aravamudan n...@us.ibm.com
---
I've tested this briefly on a machine with suitable firmware/hardware.
Things seem to work well, but I want to do more exhaustive I/O testing
before asking for upstream merging. I would really appreciate any
feedback on the updated approach.
Specific questions:
Ben, did I hook into the dma_set_mask() platform callback as you
expected? Anything I can do better or which perhaps might lead to
gotchas later?
I've added a disable_ddw option, but perhaps it would be better to
just disable the feature if iommu=force?
So for the final version, I probably should document this option in
kernel-parameters.txt w/ the patch, right?
snip
+static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
+ unsigned long num_pfn, const void *arg)
+{
+ const struct dynamic_dma_window_prop *maprange = arg;
+ int rc;
+ u64 tce_size, num_tce, dma_offset, next;
+ u32 tce_shift;
+ long limit;
+
+ tce_shift = be32_to_cpu(maprange-tce_shift);
+ tce_size = 1ULL tce_shift;
+ next = start_pfn PAGE_SHIFT;
+ num_tce = num_pfn PAGE_SHIFT;
+
+ /* round back to the beginning of the tce page size */
+ num_tce += next (tce_size - 1);
+ next = ~(tce_size - 1);
+
+ /* covert to number of tces */
+ num_tce |= tce_size - 1;
+ num_tce = tce_shift;
+
+ do {
+ /*
+ * Set up the page with TCE data, looping through and setting
+ * the values.
+ */
+ limit = min_t(long, num_tce, 512);
+ dma_offset = next + be64_to_cpu(maprange-dma_base);
+
+ rc = plpar_tce_stuff(be64_to_cpu(maprange-liobn),
+ (u64)dma_offset,
+ 0, limit);
+ num_tce -= limit;
+ } while (num_tce 0 !rc);
+
+ return rc;
+}
There is a bit of a typo here, the liobn is a 32-bit value. I've fixed
this is up locally and will update it when I send out the final version
of this patch.
I'm finding that on dlpar remove of adapters running in slots supporting
64-bit DMA, that the plpar_tce_stuff is failing. Can you think of a
reason why? It looks basically the same as the put_indirect below...
+static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
+ unsigned long num_pfn, const void *arg)
+{
+ const struct dynamic_dma_window_prop *maprange = arg;
+ u64 *tcep, tce_size, num_tce, dma_offset, next, proto_tce, liobn;
+ u32 tce_shift;
+ u64 rc = 0;
+ long l, limit;
+
+ local_irq_disable();/* to protect tcep and the page behind it */
+ tcep = __get_cpu_var(tce_page);
+
+ if (!tcep) {
+ tcep = (u64 *)__get_free_page(GFP_ATOMIC);
+ if (!tcep) {
+ local_irq_enable();
+ return -ENOMEM;
+ }
+ __get_cpu_var(tce_page) = tcep;
+ }
+
+ proto_tce = TCE_PCI_READ | TCE_PCI_WRITE;
+
+ liobn = (u64)be32_to_cpu(maprange-liobn);
+ tce_shift = be32_to_cpu(maprange-tce_shift);
+ tce_size = 1ULL tce_shift;
+ next = start_pfn PAGE_SHIFT;
+ num_tce = num_pfn PAGE_SHIFT;
+
+ /* round back to the beginning of the tce page size */
+ num_tce += next (tce_size - 1);
+ next = ~(tce_size - 1);
+
+ /* covert to number of tces */
+ num_tce |= tce_size - 1;
+ num_tce = tce_shift;
+
+ /* We can map max one pageful of TCEs at a time */
+ do {
+ /*
+ * Set up the page with TCE data, looping through and setting
+ * the values.
+ */
+ limit = min_t(long, num_tce, 4096/TCE_ENTRY_SIZE);
+ dma_offset = next + be64_to_cpu(maprange-dma_base);
+
+ for (l = 0; l limit; l++) {
+ tcep[l] = proto_tce | next;
+ next += tce_size;
+ }
+
+ rc = plpar_tce_put_indirect(liobn,
+ (u64)dma_offset,
+ (u64)virt_to_abs(tcep),
+ limit);
+
+ num_tce -= limit;
+ } while (num_tce 0 !rc);
+printk(plpar_tce_put_indirect for offset 0x%llx and tcep[0]
0x%llx returned %llu\n,
+(u64)dma_offset, tcep[0], rc);
+
I'll cleanup the debugging on the final version too.
snip
+static void remove_ddw(struct
Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
Yes please. Regards, Marri On Wed, Dec 8, 2010 at 10:47 PM, Greg KH g...@kroah.com wrote: On Wed, Dec 08, 2010 at 04:28:59PM -0800, tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com v6: 1. Replaced register definitions and bit fields with macros. 2. Replace printks with dev_dbg or dev_err functions. 3. Cleanup some assignments. 4. Remove chip specific selections in Kconfig file. Much nicer, thanks. Do you wish for me to apply this to the tree if it passes review? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with MPC8536 and external IRQs when using a loadable kernel module
I have a curious problem. This is on a MPC8636 based platform with 36-bit address space (that may or may not be important). I have a very simple driver that registers for one of the external IRQs with a trivial interrupt handler. It works great when built in as part of the kernel. However, if I make it a loadable module I get the crash shown below (blade_irq is my IRQ handler). -Console capture Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0xf31200f8 Oops: Kernel access of bad area, sig: 11 [#1] COMPASS Modules linked in: blade_pnic blade_irq_drv blade_cpld_mmap_drv NIP: f31200f8 LR: c006a26c CTR: f31200f8 REGS: c057bdd0 TRAP: 0400 Not tainted (2.6.32.12-131) MSR: 00029000 EE,ME,CE CR: 24024048 XER: TASK = c0544318[0] 'swapper' THREAD: c057a000 GPR00: c057be80 c0544318 0012 08f9cac0 c058177c ef82 GPR08: 0200 c04a f31200f8 c058a368 2dc6c000 1012b250 3ffbd200 GPR16: 3ff91140 3ffb22f8 GPR24: 1600 c049fe4c 0012 ea7975c0 NIP [f31200f8] blade_irq+0x0/0x110 [blade_irq_drv] LR [c006a26c] handle_IRQ_event+0x64/0x13c Call Trace: [c057be80] [c0547b80] 0xc0547b80 (unreliable) [c057bea0] [c006c41c] handle_fasteoi_irq+0x68/0xf4 [c057beb0] [c0004da0] do_IRQ+0x98/0xb4 [c057bed0] [c000fe0c] ret_from_except+0x0/0x18 [c057bf90] [c0008168] cpu_idle+0x50/0xd8 [c057bfb0] [c000237c] rest_init+0x5c/0x70 [c057bfc0] [c0516850] start_kernel+0x238/0x2c4 [c057bff0] [c39c] skpinv+0x2b4/0x2f0 Instruction dump: 7d6903a6 4e800420 3d60c007 396bb59c 7d6903a6 4e800420 3800 3860 90040068 4e800020 3860 4e800020 9421fff0 7c0802a6 3d20f312 bfc10008 Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 180 seconds.. - End of Console capture I've done a few things - Verified the symbol address and the NIP match. They seem correct - Removed all code from the IRQ handler and just return IRQ_HANDLED. Still crashes - Put an infinite loop at the start of the IRQ handler - loop isn't hit and still crashes so I assume the handler itself is never run. - I'm able to call my IRQ handler from the module init code and it runs successfully. The problem is only when running in an interrupt context. - I also as a somewhat stupid test passed the physical address rather than the virtual address when registering the handler. Still crashes (not sure if that's a valid thing to do to be honest, but I figured it might be a virtual memory paging issue...grasping at straws.). I do have a ticket in with Freescale support but they suggested I post here for quicker and wider responses and if there are any ideas out there I'd really appreciate them. Any chance anyone else has hit this and knows a workaround or solution? Are there any examples of working driver modules that use interrupts on the 8536 out there in case I've done something really goofy in my code? Any suggestions of things to try? Thanks in advance Mark Confidentiality Notice: This message and any attachments may contain privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with MPC8536 and external IRQs when using a loadable kernel module
On Thu, 2010-12-09 at 12:45 -0800, Mark Pearson wrote: I have a curious problem. This is on a MPC8636 based platform with 36-bit address space (that may or may not be important). I have a very simple driver that registers for one of the external IRQs with a trivial interrupt handler. It works great when built in as part of the kernel. However, if I make it a loadable module I get the crash shown below (blade_irq is my IRQ handler). -Console capture Unable to handle kernel paging request for instruction fetch ^ Your interrupt handler isn't mapped executable? Something wrong with module loading? Do you need 78e2e68a2b79f394b7cd61e07987a8a89af907f7 ? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
Magical - thank you very very much. The patch fixes the problem Really appreciate the quick response - and I would never have found that in a million years. Mark -Original Message- From: Michael Ellerman [mailto:mich...@ellerman.id.au] Sent: Thursday, December 09, 2010 6:33 PM To: Mark Pearson Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: Problem with MPC8536 and external IRQs when using a loadable kernel module On Thu, 2010-12-09 at 12:45 -0800, Mark Pearson wrote: I have a curious problem. This is on a MPC8636 based platform with 36-bit address space (that may or may not be important). I have a very simple driver that registers for one of the external IRQs with a trivial interrupt handler. It works great when built in as part of the kernel. However, if I make it a loadable module I get the crash shown below (blade_irq is my IRQ handler). -Console capture Unable to handle kernel paging request for instruction fetch ^ Your interrupt handler isn't mapped executable? Something wrong with module loading? Do you need 78e2e68a2b79f394b7cd61e07987a8a89af907f7 ? cheers Confidentiality Notice: This message and any attachments may contain privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
On Thu, 2010-12-09 at 17:20 -0800, Mark Pearson wrote: Magical - thank you very very much. The patch fixes the problem Really appreciate the quick response - and I would never have found that in a million years. No worries. Looks like someone should send 78e2e68a2b to the stable crew. FSL guys? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
Hi, В Wed, 8 Dec 2010 16:28:59 -0800 tmarri at apm.com (tmarri at apm.com) пишет: From: Tirumala Marri tmarri at apm.com v6: 1. Replaced register definitions and bit fields with macros. 2. Replace printks with dev_dbg or dev_err functions. 3. Cleanup some assignments. 4. Remove chip specific selections in Kconfig file. Thanks for the update! I'm currently working on USB support for Ralink RT3050 (mipsel) boards which have the same USB OTG controller. I've based my work on the previous version of your patchset. The were several arch-specific issues that I'd like to be fixed here before it hits mainline (BTW, is it going to be mainlined?). I'll reply to the subsequent e-mails about the specific issues. Is this ok? Also I'd like to note that s3c-hsotg driver that is already in the kernel seems to be quite similar from the register definitions at least. It handles gadget mode only and the code looks different. I think it should be replaced somehow by this new driver (which is based on the official driver). -- Alexander signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
On Thu, Dec 9, 2010 at 8:52 PM, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: Hi, В Wed, 8 Dec 2010 16:28:59 -0800 tmarri at apm.com (tmarri at apm.com) пишет: From: Tirumala Marri tmarri at apm.com v6: 1. Replaced register definitions and bit fields with macros. 2. Replace printks with dev_dbg or dev_err functions. 3. Cleanup some assignments. 4. Remove chip specific selections in Kconfig file. Thanks for the update! I'm currently working on USB support for Ralink RT3050 (mipsel) boards which have the same USB OTG controller. I've based my work on the previous version of your patchset. The were several arch-specific issues that I'd like to be fixed here before it hits mainline (BTW, is it going to be mainlined?). I'll reply to the subsequent e-mails about the specific issues. Is this ok? Yes the idea is to push into main line. I am not sure if it is good idea to push all the changes in one go. I would wait for this patch to be accepted first and add your changes on top of that. Also I'd like to note that s3c-hsotg driver that is already in the kernel seems to be quite similar from the register definitions at least. It handles gadget mode only and the code looks different. I think it should be replaced somehow by this new driver (which is based on the official driver). It sound similar to gadget portion of this OTG driver. After this patch accepted I will take a look and see if we can completely eliminate s3c-hsotg . Thanks, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
