Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 07/12/14 18:03, Nishanth Menon wrote: Marc, On 11:16-20141207, Nishanth Menon wrote: On 13:46-20141206, Marc Zyngier wrote: After my series removing the gic_arch_extn hack, I figured that the next step was to expunge the GIC driver of the routable domain horror. There is a few reasons for this: - The allocation of interrupts in this domain is fairly similar to what we do for MSI (see the GICv2m driver), and stacked domains have proved to be a fitting solution. - The current description in DT is currently entierely inaccurate, and as we already broke it for the OMAP WUGEN block, we might as well do it again for the TI crossbar. - The way crossbar, WUGEN and GIC interract is quite complex (this is effectively a stack of three interrupt controllers with interesting exceptions and braindead routing), and stacked domains are the right abstraction for that. - Other platforms (Freescale Vybrid) are starting to come up with the same type of things, and it'd be good to avoid them following the same broken model. - It removes a few lines from the code base so it can't completely be a bad idea! So this patch series does exactly that: make the crossbar a stacked interrupt controller that only takes care of setting up the routing, fix the DTs to represent the actual HW, and remove a bit of the craziness from the GIC code. As for the previous series: - I haven't been able to test this at all, I don't have access to the HW. TI people, please test and post fixes, as I expect I introduced a few bugs. - This actively *breaks* existing setups. If you boot a new kernel with an old DT, interrupt routing *will* be broken. Old kernels on a new DT won't boot either! You've been warned. This really outline the necessity of actually describing the HW in device trees... As for the patches, they are on top of 3.18-rc7 + tip/irq/irqdomain-arm + the gic_arch_extn removal series. I've pushed the code to: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/die-gic-arch-extn-die-die-die Comments welcome, M. Marc Zyngier (5): genirq: Add irqchip_set_wake_parent irqchip: crossbar: convert dra7 crossbar to stacked domains DT: update ti,irq-crossbar binding irqchip: GIC: get rid of routable domain DT: arm,gic: kill arm,routable-irqs Documentation/devicetree/bindings/arm/gic.txt | 6 - .../devicetree/bindings/arm/omap/crossbar.txt | 18 +- arch/arm/boot/dts/dra7.dtsi| 10 +- arch/arm/boot/dts/dra72x.dtsi | 3 +- arch/arm/boot/dts/dra74x.dtsi | 5 +- arch/arm/mach-omap2/omap4-common.c | 4 - drivers/irqchip/irq-crossbar.c | 202 - drivers/irqchip/irq-gic.c | 59 +- include/linux/irq.h| 1 + include/linux/irqchip/arm-gic.h| 6 - include/linux/irqchip/irq-crossbar.h | 11 -- kernel/irq/chip.c | 16 ++ 12 files changed, 153 insertions(+), 188 deletions(-) delete mode 100644 include/linux/irqchip/irq-crossbar.h -- 2.1.3 Patches are available here: https://patchwork.kernel.org/patch/5449231/ https://patchwork.kernel.org/patch/5449241/ https://patchwork.kernel.org/patch/5449271/ https://patchwork.kernel.org/patch/5449261/ https://patchwork.kernel.org/patch/5449251/ dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP Would you want me to debug more - dts changes perhaps? Yes, it would be useful to find out. One thing that strikes me is that the kernel boots all the way, so I assume IRQs are actually up and running. One thing though. The irq branch shows this: [ 15.359025] pbias_mmc_omap5: disabling and the MMC subsystem never initializes. I'm pretty sure this is related. Config option? Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On Saturday 06 December 2014 08:20 AM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under arch/arm/ (the defconfig files will be modified later). Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) which is only in linux-next at the moment (via the linux-pm tree). Please let me know if it is OK to take this one into linux-pm. --- arch/arm/kernel/perf_event.c |2 +- arch/arm/mach-davinci/pm_domain.c |2 +- Acked-by: Sekhar Nori nsek...@ti.com for the mach-davinci change. I have nothing conflicting queued, so feel free to take this through your tree. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: On Fri, Dec 05, 2014 at 10:13:51AM -0600, Nishanth Menon wrote: On 12/05/2014 10:10 AM, Nishanth Menon wrote: Case #2: Reverting the following allows boot. From next-20141204 10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings revert this - boot still fails d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL revert this - boot still fails 46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C revert this - boot still fails c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like revert this - boot passed (first bad commit). + linux-samsung soc and updated Thomaz's mail ID (gmail now). Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. Or a fix could be queued on top of this. Since (I believe) this series has been queued for 3.19, we have 6 or 7 RC releases ahead, which could be used for the purpose of fixing things (as they are supposed to?). I think we need 8208/1 split up into smaller changes so that the cause of this regression can be found. I'm afraid we need more than that. First of all, this series has been in the wild for more than 3 months already, without any serious changes. Need not to mention that mailing lists and maintainers of all potentially affected platforms had been added. It had been noted in cover letter that the only platform I (and Marek later) could test on was Exynos and that it would be good if somebody working with other platforms could test the patches. Looks like nobody cared back then, so why should we care that much now, especially that we have several RC releases ahead and we can still fix this? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. Or a fix could be queued on top of this. Since (I believe) this series has been queued for 3.19, we have 6 or 7 RC releases ahead, which could be used for the purpose of fixing things (as they are supposed to?). They were merged on 27th November, so they would've been in linux-next from about last Monday. Nishanth reported a failure on Friday, the last week day before the merge window opens. There's no time to try and fix this before the merge window, which is why I decided to drop it. They have already been dropped. They were dropped immediately after my message on Friday was sent. So they've not been in linux-next over this past weekend. We don't push known broken code in during the merge window. The merge window is the exact time when subtle bugs are likely to be introduced, and is the exact time that you want bisect to work. If we push known broken patches into the kernel during that period, we break the ability to use bisect to find problems, especially where it causes a platform to become unbootable. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On 6 December 2014 at 03:50, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under arch/arm/ (the defconfig files will be modified later). Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) which is only in linux-next at the moment (via the linux-pm tree). Please let me know if it is OK to take this one into linux-pm. --- arch/arm/kernel/perf_event.c |2 +- arch/arm/mach-davinci/pm_domain.c |2 +- arch/arm/mach-keystone/pm_domain.c |2 +- arch/arm/mach-omap1/pm_bus.c |4 ++-- arch/arm/mach-omap2/io.c |2 +- arch/arm/mach-omap2/omap_device.c |2 +- 6 files changed, 7 insertions(+), 7 deletions(-) There are a bunch of Kconfig options that selects/depends on PM_RUNTIME. I suppose you should change them into PM as well. Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file
On Thu, Nov 27, 2014 at 12:41:31PM +0200, Peter Ujfalusi wrote: include/linux/platform_data/ is not a correct place to keep the API definitions for edma, it is meant to be only for the pdata for the device. Clean up this by moving the API to include/linux/edma.h Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 +- arch/arm/mach-davinci/devices.c| 1 + arch/arm/mach-davinci/include/mach/da8xx.h | 1 + drivers/dma/edma.c | 2 +- include/linux/edma.h | 153 + include/linux/platform_data/edma.h | 148 ++-- sound/soc/davinci/davinci-pcm.h| 1 + 7 files changed, 165 insertions(+), 144 deletions(-) create mode 100644 include/linux/edma.h I was hoping that this will have delete for platform_data/edma.h, do we still need that and why shouldn't we get rid of this :) -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: edma: Split up header file to platform_data and API file
On Monday 08 December 2014 18:19:17 Vinod Koul wrote: On Thu, Nov 27, 2014 at 12:41:31PM +0200, Peter Ujfalusi wrote: include/linux/platform_data/ is not a correct place to keep the API definitions for edma, it is meant to be only for the pdata for the device. Clean up this by moving the API to include/linux/edma.h Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 +- arch/arm/mach-davinci/devices.c| 1 + arch/arm/mach-davinci/include/mach/da8xx.h | 1 + drivers/dma/edma.c | 2 +- include/linux/edma.h | 153 + include/linux/platform_data/edma.h | 148 ++-- sound/soc/davinci/davinci-pcm.h| 1 + 7 files changed, 165 insertions(+), 144 deletions(-) create mode 100644 include/linux/edma.h I was hoping that this will have delete for platform_data/edma.h, do we still need that and why shouldn't we get rid of this I think the platform_data/edma.h file is needed for as long as we have mach-davinci systems that are not converted to boot using DT. At the current pace of development in that area, I would expect that to take a few more years at least: da850 support is slowly proceeding (since 2012), da830 should be fairly straightforward to add once da850 is done, but I haven't seen anybody start working on the dm* socs for DT. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] usb: dwc3: add DWC3_SKIP_USB3PHY and DWC3_SKIP_USB2_PHY quirks
Hi list, On platforms which has native usb hosts/phys and pci-dwc3 controller, the dwc3 core may get the wrong usb2_phy and usb3_phy by devm_usb_get_phy(). It depends on which usb phy driver is initialized firstly, the usb_phy_generic or the native/real usb phy driver. Before all old USB phy library usage removed, the solution I can have is to add DWC3_SKIP_USB3PHY and DWC3_SKIP_USB2_PHY quirks and set them in dwc3-pci. Could such modification can be accepted? If not, could you please give alternative suggestions? Thanks, Jisheng -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On 12/08/2014 06:22 AM, Russell King - ARM Linux wrote: On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. Or a fix could be queued on top of this. Since (I believe) this series has been queued for 3.19, we have 6 or 7 RC releases ahead, which could be used for the purpose of fixing things (as they are supposed to?). They were merged on 27th November, so they would've been in linux-next from about last Monday. Nishanth reported a failure on Friday, the For what ever it is worth, the l2c changes actually appeared on Thursday CST (next-20141204). Found the regression against next-20141203 tag and it took me a day to track it down (after looking at a few other regressions as well).. Anyways... -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Mon, Dec 08, 2014 at 07:54:08AM -0600, Nishanth Menon wrote: On 12/08/2014 06:22 AM, Russell King - ARM Linux wrote: On Mon, Dec 08, 2014 at 08:54:18PM +0900, Tomasz Figa wrote: 2014-12-06 1:23 GMT+09:00 Russell King - ARM Linux li...@arm.linux.org.uk: Given where we are in the cycle (-final likely this weekend) the only thing we can do right now is to drop the patch set; exynos (and mvebu) will have to wait another cycle until this patch set (hopefully in a revised form) can be merged. Or a fix could be queued on top of this. Since (I believe) this series has been queued for 3.19, we have 6 or 7 RC releases ahead, which could be used for the purpose of fixing things (as they are supposed to?). They were merged on 27th November, so they would've been in linux-next from about last Monday. Nishanth reported a failure on Friday, the For what ever it is worth, the l2c changes actually appeared on Thursday CST (next-20141204). Found the regression against next-20141203 tag and it took me a day to track it down (after looking at a few other regressions as well).. I wonder if that's because I didn't push my tree out until Tuesday-ish. It takes around 48 hours between when I push stuff out to it appearing in linux-next, which is not particularly desirable, but unavoidable due to timezone differences. I did decide that I wouldn't push it out the same day I merged it because I wanted it to run through my build/boot system, which it did successfully, but then my OMAP4 build doesn't have CPU idle enabled (and as you've identified, when CPU idle is disabled, it works.) The problem there is that if I decide not to push some merged changes out, it takes several days before I get around to touching the kernel tree again. Hence why it took from Thursday until Tuesday for it to eventually get pushed out. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 1/5] Documentation: dt: add common bindings for hwspinlock
On Wed, Nov 12, 2014 at 9:08 AM, Suman Anna s-a...@ti.com wrote: Kumar, Mark, Rob, On 11/12/2014 09:14 AM, Ohad Ben-Cohen wrote: Hi Suman, On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna s-a...@ti.com wrote: This patch adds the generic common bindings used to represent a hwlock device and use/request locks in a device-tree build. ... Cc: Rob Herring robh...@kernel.org Signed-off-by: Suman Anna s-a...@ti.com Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- .../devicetree/bindings/hwlock/hwlock.txt | 55 ++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt Please ask a DT maintainer to ACK this - otherwise I can't send this to Linus. Can one of you ack this patch and the next patch [1] so that Ohad can pick up the series for 3.19? This series has been in works for quite some time now and was reviewed by each of you at some point of time (thanks!!), the cover letter [2] has the history of the changes. Could we please have a statement from a DT maintainer so we could move forward with this? Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On 12/5/2014 6:50 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere in the code under arch/arm/ (the defconfig files will be modified later). Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com --- Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) which is only in linux-next at the moment (via the linux-pm tree). Please let me know if it is OK to take this one into linux-pm. --- arch/arm/mach-keystone/pm_domain.c |2 +- Looks fine to me. For keystone parts. Acked-by: Santosh Shilimkar ssant...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
nokia_h4p on 3.16+
Hi! It seems commit: commit bd5dc09f557547399cd44d0a1224df7ff64e4a6b Author: Felipe Balbi ba...@ti.com Date: Wed Apr 23 09:58:28 2014 -0500 serial: fix UART_IIR_ID UART IRQ Identification bitfield is 3 bits long (bits 3:1) but current mask only masks 2 bits. Fix it. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org breaks bluetooth driver on n900. (drivers/staging/nokia_h4p). Pali, you may want to revert the patch. That is good news, because reverting it on 3.18-rcX brings h4p back, too (and as machine boots on nfsroot, debugging should be possible.) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nokia_h4p on 3.16+
On Monday 08 December 2014 21:47:35 Pavel Machek wrote: Hi! It seems commit: commit bd5dc09f557547399cd44d0a1224df7ff64e4a6b Author: Felipe Balbi ba...@ti.com Date: Wed Apr 23 09:58:28 2014 -0500 serial: fix UART_IIR_ID UART IRQ Identification bitfield is 3 bits long (bits 3:1) but current mask only masks 2 bits. Fix it. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org breaks bluetooth driver on n900. (drivers/staging/nokia_h4p). Pali, you may want to revert the patch. That is good news, because reverting it on 3.18-rcX brings h4p back, too (and as machine boots on nfsroot, debugging should be possible.) Best regards, Pavel Hi! this is good news. CCing new freemangordon's @gmail address. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Mainline kernel really hates bateries in N900
Hi! So... I thought leaving N900 with mainline kernel on USB connection was bad... (end result was battery at 2.97V). Well... now I left the machine idle without the charger ... and result was 2.85V on battery. Li-ion batteries should not be discharged below 3.4V. As may batteries are already reported as 5mAh total capacity from time to time, I'll just have to get new ones... but perhaps you should not repeat those experiments. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nokia_h4p on 3.16+
On Monday 08 December 2014 21:47:35 Pavel Machek wrote: Hi! It seems commit: commit bd5dc09f557547399cd44d0a1224df7ff64e4a6b Author: Felipe Balbi ba...@ti.com Date: Wed Apr 23 09:58:28 2014 -0500 serial: fix UART_IIR_ID UART IRQ Identification bitfield is 3 bits long (bits 3:1) but current mask only masks 2 bits. Fix it. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org breaks bluetooth driver on n900. (drivers/staging/nokia_h4p). Pali, you may want to revert the patch. That is good news, because reverting it on 3.18-rcX brings h4p back, too (and as machine boots on nfsroot, debugging should be possible.) Best regards, Pavel Reverted in linux-n900 git tree in v3.18-rc6-n900 branch. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: nokia_h4p on 3.16+
On Monday 08 December 2014 21:47:35 Pavel Machek wrote: Hi! It seems commit: commit bd5dc09f557547399cd44d0a1224df7ff64e4a6b Author: Felipe Balbi ba...@ti.com Date: Wed Apr 23 09:58:28 2014 -0500 serial: fix UART_IIR_ID UART IRQ Identification bitfield is 3 bits long (bits 3:1) but current mask only masks 2 bits. Fix it. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org breaks bluetooth driver on n900. (drivers/staging/nokia_h4p). Pali, you may want to revert the patch. That is good news, because reverting it on 3.18-rcX brings h4p back, too (and as machine boots on nfsroot, debugging should be possible.) Best regards, Pavel Pavel, maybe there is some unhandled iir value in function static irqreturn_t hci_h4p_interrupt(int irq, void *data) which cause that driver is not working? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 0/5] irqchip: kill the GIC routable domain
On 09:10-20141208, Marc Zyngier wrote: On 07/12/14 18:03, Nishanth Menon wrote: [..] dra7xx-evm(3.18-rc7): Boot PASS: http://slexy.org/raw/s2PXWFB47A dra7xx-evm(irq branch): Boot FAIL: http://slexy.org/raw/s2xMgD4zkP Would you want me to debug more - dts changes perhaps? Yes, it would be useful to find out. One thing that strikes me is that the kernel boots all the way, so I assume IRQs are actually up and running. Nope, we dont usually need peripheral interrupts untill we use them.. mmc is the first to use it, followed by serial port of course :).. One thing though. The irq branch shows this: [ 15.359025] pbias_mmc_omap5: disabling and the MMC subsystem never initializes. I'm pretty sure this is related. Config option? nope. just the request mmc card was never detected (crossbar was misconfigured) Anyways.. The following diff[1] on top of your branch makes DRA7 work - I assume you will squash as needed and repost with linux-omap mailing list in CC. I increased the scope of testing knowing that WUGEN is present in many A9 based TI platforms as well.. and at least OMAP4 showed flakiness in my testing.. Also a few notes: Stuff like: am437x is a bit questionable (interrupt-parent probably should be wugen?) 175: 0 GIC 39 tps65218 OMAP5: (should be wugen?) 308: 4323 0 GIC 106 OMAP UART2 411: 0 0 GIC 151 twl6040 405: 1 0 GIC 39 palmas OMAP4 serial port is flaky - not sure if it is due to routing of GIC to UART2 and not via WUGEN IRQ branch: with my fix applied: - 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2aN42JkKi 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21w2OG3hL 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21Tlp6ZLq 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21Vqp6P1B 5: am437x-sk: Boot PASS: http://slexy.org/raw/s2UhY45mJc 6: am43xx-epos: Boot PASS: http://slexy.org/raw/s20l5l2fj4 7: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2aRwhAtau 8: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2GbGmM7xU 9: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s209bMoHPd 10: beaglebone-black: Boot PASS: http://slexy.org/raw/s2IzmRPyVI 11: beaglebone: Boot PASS: http://slexy.org/raw/s2053lNp5G 12: craneboard: Boot PASS: http://slexy.org/raw/s2kKkEoR4A 13: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21jb0oCBm (this one is known - mmc node is missing) 14: dra7xx-evm: Boot PASS: http://slexy.org/raw/s2ho2KH2rh 15: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s21U4McCJp 16: n900: Boot PASS: http://slexy.org/raw/s2Np9wQrYd 17: omap5-evm: Boot PASS: http://slexy.org/raw/s21Dd4tS2M 18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not expected) 19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not expected) 20:sdp2430: Boot PASS: http://slexy.org/raw/s21AygxGRg 21:sdp3430: Boot PASS: http://slexy.org/raw/s207290wN9 TOTAL = 21 boards, Booted Boards = 18, No Boot boards = 3 comparitive reference v3.18-rc7: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2ASdqrwQx 2: am335x-sk: Boot PASS: http://slexy.org/raw/s208zUIeql 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20dx70o4a 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20qKJVqIQ (ignore this: board farm issue/PMIC power script issue - unrelated and known). 5: am437x-sk: Boot PASS: http://slexy.org/raw/s20K8unGsM 6: am43xx-epos: Boot PASS: http://slexy.org/raw/s21hPfz6DC 7: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2voHleSYO 8: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s208GPH7nx 9: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20jOW13Ig 10: beaglebone-black: Boot PASS: http://slexy.org/raw/s2I60jGnCI 11: beaglebone: Boot PASS: http://slexy.org/raw/s29u4NiShX 12: craneboard: Boot PASS: http://slexy.org/raw/s2T7etBuGm 13: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21dmHgoXn (known issue - mmc node is missing) 14: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21cFgrB0f 15: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s2FBPPQ3ML 16: n900: Boot PASS: http://slexy.org/raw/s2RmlkVWvN 17: omap5-evm: Boot PASS: http://slexy.org/raw/s2YKl1szpz 18: pandaboard-es: Boot PASS: http://slexy.org/raw/s2hvXLDMoS 19: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s2056IOHsT 20:sdp2430: Boot PASS: http://slexy.org/raw/s2PYPNr7jm 21:sdp3430: Boot PASS: http://slexy.org/raw/s2Iyc9K8I6 TOTAL = 21 boards, Booted Boards = 19, No Boot boards = 2 I suggest skipping 3.19 if possible and giving it a more detailed time in linux-next with omap4 etc being more thoroughly being tested before letting it through, if possible. [1] - diff arch/arm/boot/dts/dra7-evm.dts |2 +- arch/arm/boot/dts/dra7.dtsi| 23 +-- drivers/irqchip/irq-crossbar.c |4 ++-- 3 files
OMAP baseline test results for v3.18
Here are some basic OMAP test results for Linux v3.18. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18/20141208144211/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc7 (009d0431c3914de64666bec0d350e54fdd59df6a)): text data bsstotal kernel -700 -7 omap1_defconfig +5700 +57 omap1_defconfig_1510innovator_only -700 -7 omap1_defconfig_5912osk_only -87 -80 -95 multi_v7_defconfig -59 -80 -67 omap2plus_defconfig -91 -160 -107 omap2plus_defconfig_2430sdp_only -123 -80 -131 omap2plus_defconfig_am33xx_only -63 -160 -79 omap2plus_defconfig_am43xx_only -59 +160 -43 omap2plus_defconfig_cpupm -127 -80 -135 omap2plus_defconfig_dra7xx_only -67 -160 -83 omap2plus_defconfig_n800_multi_omap2xxx -35 -160 -51 omap2plus_defconfig_n800_only_a -123 +240 -99 omap2plus_defconfig_no_pm -59 +160 -43 omap2plus_defconfig_omap2_4_only -123 -160 -139 omap2plus_defconfig_omap3_4_only -63 -160 -79 omap2plus_defconfig_omap5_only -132 -16 +16 -132 rmk_omap3430_ldp_allnoconfig -103 +80 -95 rmk_omap3430_ldp_oldconfig -132 -12 +16 -128 rmk_omap4430_sdp_allnoconfig +3993 +80+4001 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc7 (009d0431c3914de64666bec0d350e54fdd59df6a)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
