Re: [PATCH v3 00/25] irq_domain generalization and refinement
On Jan 28, 2012 11:38 AM, "Rob Herring" wrote: > > On 01/27/2012 03:35 PM, Grant Likely wrote: > > Hey everyone, > > > > This patch series is ready for much wider consumption now. I'd like > > to get it into linux-next ASAP because there will be ARM board support > > depending on it. I'll wait a few days before I ask Stephen to pull > > this in. > > > > Stephen/Milton/Ben, any testing you can help with here would be > > appreciated since you've got access to a wider variety of Power > > machines than I do. > > > > Thomas, I think it makes sense to maintain this in a separate branch > > from other irq changes until the next merge window. If you prefer, > > I'm happy to maintain this branch until then. > > > > I picked up your irqdomain/next branch and it doesn't compile: > > CC kernel/irq/irqdomain.o > kernel/irq/irqdomain.c: In function ‘irq_create_mapping’: > kernel/irq/irqdomain.c:403:47: error: ‘irq’ undeclared (first use in > this function) > kernel/irq/irqdomain.c:403:47: note: each undeclared identifier is > reported only once for each function it app Oops, I had fixed that but didn't refresh the patch. Change the references in that function from irq to virq, or pop off the top patch to fix. I'll push out a fixed tree when I get home. g. > > Rob > > > Cheers, > > g. > > > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > > > > Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) > > > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6 irqdomain/next > > > > Grant Likely (24): > > irq_domain: add documentation and MAINTAINERS entry. > > dt: Make irqdomain less verbose > > irq_domain: Make irq_domain structure match powerpc's irq_host > > irq_domain: convert microblaze from irq_host to irq_domain > > irq_domain/powerpc: Use common irq_domain structure instead of irq_host > > irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead > > irq_domain/powerpc: Eliminate virq_is_host() > > irq_domain: Move irq_domain code from powerpc to kernel/irq > > irqdomain: remove NO_IRQ from irq domain code > > irq_domain: Remove references to old irq_host names > > irq_domain: Replace irq_alloc_host() with revmap-specific initializers > > irq_domain: Add support for base irq and hwirq in legacy mappings > > irq_domain: Remove 'new' irq_domain in favour of the ppc one > > irq_domain: Remove irq_domain_add_simple() > > irq_domain: Create common xlate functions that device drivers can use > > irq_domain: constify irq_domain_ops > > irq_domain/c6x: constify irq_domain structures > > irq_domain/c6x: Use library of xlate functions > > irq_domain/powerpc: constify irq_domain_ops > > irqdomain/powerpc: Replace custom xlate functions with library functions > > irq_domain/x86: Convert x86 (embedded) to use common irq_domain > > irq_domain: Include hwirq number in /proc/interrupts > > irq_domain: remove "hint" when allocating irq numbers > > irq_domain: mostly eliminate slow-path revmap lookups > > > > Mark Salter (1): > > irq_domain/c6x: Convert c6x to use generic irq_domain support. > > > > Documentation/IRQ-domain.txt | 113 +++ > > MAINTAINERS |9 + > > arch/arm/common/gic.c| 95 ++-- > > arch/arm/common/vic.c| 16 +- > > arch/arm/include/asm/hardware/gic.h |4 +- > > arch/arm/include/asm/hardware/vic.h |2 + > > arch/arm/mach-exynos/common.c|2 +- > > arch/arm/mach-imx/mach-imx6q.c |3 +- > > arch/arm/mach-msm/board-msm8x60.c|8 +- > > arch/arm/mach-mx5/imx51-dt.c |4 +- > > arch/arm/mach-mx5/imx53-dt.c |4 +- > > arch/arm/mach-omap2/board-generic.c |2 +- > > arch/arm/mach-prima2/irq.c |2 +- > > arch/arm/mach-versatile/core.c |5 +- > > arch/c6x/Kconfig |1 + > > arch/c6x/include/asm/irq.h | 245 +--- > > arch/c6x/kernel/irq.c| 612 + > > arch/c6x/platforms/megamod-pic.c | 25 +- > > arch/microblaze/include/asm/irq.h|4 +- > > arch/microblaze/kernel/irq.c |2 +- > > arch/microblaze/kernel/setup.c |2 - > > arch/powerpc/Kconfig |1 + > > arch/powerpc/include/asm/ehv_pic.h |2 +- > > arch/powerpc/include/asm/i8259.h |2 +- > > arch/powerpc/include/asm/irq.h | 247 +--- > > arch/powerpc/include/asm/mpic.h |2 +- > > arch/powerpc/include/asm/xics.h |
Re: [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.
On Jan 28, 2012 10:25 AM, "Randy Dunlap" wrote: > > On 01/27/2012 01:35 PM, Grant Likely wrote: > > Documentation for irq_domain library which will be created in subsequent > > patches. > > I posted a lot of comments to v2 on Jan. 24. > Looks like they were ignored. I just hadn't gotten to them. I've made the changes since and they will be part of v4. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
On Thu, Nov 24, 2011 at 12:18 PM, Michael S. Tsirkin wrote: > mips copied pci_iomap from generic code, probably to avoid > pulling the rest of iomap.c in. Since that's in > a separate file now, we can reuse the common implementation. [snip] > - if (flags & IORESOURCE_IO) > - return ioport_map_pci(dev, start, len); While investigating a new warning on the 3.3-rc1 MIPS build (unused static function ioport_map_pci()), I noticed that this patch has shown up in Linus' tree as commit eab90291d35438bcebf7c3dc85be66d0f24e3002. I am not completely clear on the implications it has on mapping PCI I/O regions: Prior to this change, the MIPS version of pci_iomap() called a MIPS-specific function, ioport_map_pci(), which tried to use the PCI controller's io_map_base field to determine the base address of the PCI I/O space. It also had a fallback mechanism to deal with the case where io_map_base is unset. Now, in 3.3-rc1, the generic version of pci_iomap() is used instead. This code just calls arch/mips/lib/iomap.c:ioport_map() on these regions. ioport_map() falls through to ioport_map_legacy(), which always uses mips_io_port_base (not the PCI controller's io_map_base) as the base address. But on MIPS, it is still permissible to use different I/O port bases for PCI devices and for legacy (ISA?) devices. Is this new behavior desirable, or are there any supported platforms on which adverse effects might be seen? As for my part, I don't use PCI I/O regions at all - just memory regions. I'm more worried about making sure my tree builds with 0 warnings. If we do want to move ahead with the switch to GENERIC_PCI_IOMAP now, I have patches to scrap iomap-pci.c entirely and squash the unused function warning. If we still want to support the case where io_map_base != mips_io_port_base, maybe it would be better to revert commit eab90291 for 3.3. Might also want to take a look at SH since it also appears to have an orphaned ioport_map_pci() function. What are your thoughts? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RTC on 2.6.36 for PowerMac 8600
kevin diggs writes: > [root@PowerMac8600B root]# hwclock --debug > hwclock from util-linux-2.12pre > Using /dev/rtc interface to clock. > Last drift adjustment done at 131743 seconds after 1969 > Last calibration done at 131743 seconds after 1969 > Hardware clock is on local time > Assuming hardware clock is kept in local time. > Waiting for clock tick... > /dev/rtc does not have interrupt functions. Waiting in loop for time > from /dev/rtc to change > RTC_RD_TIME: Invalid argument Perhaps the RTC was reset due to battery running out? That would set the year to 1900, but the kernel RTC interface cannot represent dates before 1970. Unfortunately hwclock insists on reading the RTC even when you just want to write to it, so you cannot fix that with hwclock -w. When the battery of my iBook has run out I'm using the following to reset RTC to current time so that it is usable again. Andreas. #include #include #include #include int main (void) { time_t now; struct tm gmt; struct rtc_time rtc; int fd; now = time (0); gmt = *gmtime (&now); rtc.tm_sec = gmt.tm_sec; rtc.tm_min = gmt.tm_min; rtc.tm_hour = gmt.tm_hour; rtc.tm_mday = gmt.tm_mday; rtc.tm_mon = gmt.tm_mon; rtc.tm_year = gmt.tm_year; rtc.tm_wday = gmt.tm_wday; rtc.tm_yday = gmt.tm_yday; rtc.tm_isdst = gmt.tm_isdst; fd = open ("/dev/rtc", O_RDONLY); if (fd < 0) fd = open ("/dev/rtc0", O_RDONLY); if (fd < 0) { perror ("/dev/rtc"); return 1; } if (ioctl (fd, RTC_SET_TIME, &rtc) < 0) { perror ("RTC_SET_TIME"); return 1; } return 0; } -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
On Sat, Jan 28, 2012 at 02:38:10PM -0800, Kevin Cernekee wrote: > On Thu, Nov 24, 2011 at 12:18 PM, Michael S. Tsirkin wrote: > > mips copied pci_iomap from generic code, probably to avoid > > pulling the rest of iomap.c in. Since that's in > > a separate file now, we can reuse the common implementation. > > [snip] > > > - if (flags & IORESOURCE_IO) > > - return ioport_map_pci(dev, start, len); > > While investigating a new warning on the 3.3-rc1 MIPS build (unused > static function ioport_map_pci()), I noticed that this patch has shown > up in Linus' tree as commit eab90291d35438bcebf7c3dc85be66d0f24e3002. > > I am not completely clear on the implications it has on mapping PCI I/O > regions: Yes, my bad, I missed the difference between ioport_map_pci and ioport_map for both MIPS and SH. I'll post a patch to fix this, which is probably preferable to reintroducing the code duplication where it might trip us up again. -- MST ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
On 01/26/2012 04:55 AM, Tabi Timur-B04825 wrote: On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan wrote: Signed-off-by: Fanzc Please fix this. There are only two e's in freescale. In addition, please use your full name. Hi Timur, You mean that need to remove the define to other file or create new file? Zhicheng Fan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
On 01/16/2012 03:08 AM, Michael Neuling wrote: [...] > From: Michael Neuling > > [PATCH] drivers/video: compile fixes for fsl-diu-fb.c > > Fix a compiler errors introduced in: > commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0 > Author: Timur Tabi > drivers/video: fsl-diu-fb: merge all allocated data into one block > > Signed-off-by: Michael Neuling Applied. Thanks, Florian Tobias Schandinat > > diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c > index acf292b..6af3f16 100644 > --- a/drivers/video/fsl-diu-fb.c > +++ b/drivers/video/fsl-diu-fb.c > @@ -1432,7 +1432,7 @@ static int fsl_diu_suspend(struct platform_device > *ofdev, pm_message_t state) > struct fsl_diu_data *data; > > data = dev_get_drvdata(&ofdev->dev); > - disable_lcdc(data->fsl_diu_info[0]); > + disable_lcdc(data->fsl_diu_info); > > return 0; > } > @@ -1442,7 +1442,7 @@ static int fsl_diu_resume(struct platform_device *ofdev) > struct fsl_diu_data *data; > > data = dev_get_drvdata(&ofdev->dev); > - enable_lcdc(data->fsl_diu_info[0]); > + enable_lcdc(data->fsl_diu_info); > > return 0; > } > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev