how to fix 405ex SDR0_MFR_ECS
hello all SDR0_MFR_ECS is defined for 440xx,now want to change it for 405ex ,but i donnot known what means in /drivers/net/ibm_newemac/core.c line 2374 to 2385 ? plese help me leo 2009:02:21 ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ioremap fails for a device in PCI-E slot on AMCC katmai board
On Fri, 2009-02-20 at 17:35 -0800, Shubhada Pugaonkar wrote: > > > cxgb3_main.c: > > mmio_start = pci_resource_start(pdev, 0); > > mmio_len = pci_resource_len(pdev, 0); > > ai = t3_get_adapter_info(ent->driver_data); > My bet is that mmio_start is an unsigned long instead of a resource_size_t and thus gets cropped (ie, driver bug). (/me goes read the source) Yes, indeed, that's the problem. Change the definition of mmio_start and mmio_len to resource_size_t, that should fix it. I suspect the other driver has the same problem. Note: They will still get cropped, I suspect, when copied to netdev->mem_start, nothing much to do here, but fortunately those fields aren't used. BTW. If you do patches to fix those drivers, please send them to the net...@vger.kernel.org mailing list too. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
> > Am I correct in saying that cpu_to_le32 and le32_to_cpu are the
> > functions/macros I need to use to do byte swapping to make everything
> > go little endian (and back again when I read them back in the kernel)?
> >
> > Or is there some cleverer way already implemented in the kernel?
> >
>
> I would say that the __raw_readl() reads in cpu order. If you wanted to
> convert that to le32, you'd use cpu_to_le32().
Beware that __raw_* forms also don't have memory barriers.
In general, you know what byte order your device uses (which is often
little endian) and you use the appropriate ioread32{be}. Now, for
userspace, you simply need to mimmic those accessors.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, Feb 20, 2009 at 03:56:39PM -0600, Matt Sealey wrote: > On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote: > > On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote: > >> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote: > >> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote: > >> > > >> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you > >> > want. They don't change byte ordering. > >> > >> Are they guaranteed to only do 32-bit, aligned accesses? > >> > > > > I don't think so. I certainly wouldn't count on anything better than a > > byte-by-byte memcpy. > > > >> I made some cheats on my CPLD to ignore byte enables and so on, > >> because it makes the design cleaner and easier to read (for students) > >> plus, saves a ton of logic cells. It's totally within the PCI > >> standard, but it means if you do a byte read memcpy() you get.. very > >> weird results (i.e. not great). > >> > > > > Right, I understand how that works :) > > > > Some usage of cscope shows that __raw_readl() might be what you want, > > as well as __raw_writel() for writing. I'm not sure it is universally > > available, but maybe they are. > > > > The comment on PowerPC says "Non ordered and non-swapping "raw" > > accessors". Looks about right. ARM's implementation uses them to > > implement ioread32() and friends by adding byteswapping. > > Am I correct in saying that cpu_to_le32 and le32_to_cpu are the > functions/macros I need to use to do byte swapping to make everything > go little endian (and back again when I read them back in the kernel)? > > Or is there some cleverer way already implemented in the kernel? > I would say that the __raw_readl() reads in cpu order. If you wanted to convert that to le32, you'd use cpu_to_le32(). Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, 2009-02-20 at 12:57 -0600, Matt Sealey wrote: > Hi guys, > > What's the correct way to read from PCI address space (basically it's > guaranteed to be non-coherent memory bar) without flipping bits like > ioread32() does? ioread32be() ? :-) But from what you say below, it seems the wrong approach. > I need to be able to copy a bank of registers from PCI address space > into a temporary buffer so I can compare them in userspace through > UIO. Because of the flipping and the difference between the original > kernel driver (which used ioread32() and therefore "saw" big endian) > and the userspace app (which has a direct view of the PCI space, and > therefore "sees" little endian) I decided to give userspace an > absolutely consistent little-endian view seeing as this may get ported > to ARM in the coming months. Your sentence above doesn't seem to make much sense to me ... Why don't you just have your userspace use lwbrx and "see" the same thing as the kernel ? Which would also happen to be the same thing as an ARM in LE mode would see... > I want to put as little code in there as possible and not laboriously > manually flip from my ioread32() big endian values to little endian > again (waste of time and code) if I can help it. Being able to read > the raw value would help a lot, and if I need to do calculations on a > small portion of the data then I can do the flips manually then (using > le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the > amount of porting I need to do in both kernel and userspace alike. > > So, is there something like a direct ioread32le() or so, which will > not change behaviour across architectures, is present on ARM and PPC, > and will handle both PCI address space, and "normal" "ioremapped" > memory? Little of what you say above make sense, you mix unrelated concepts and all other weirdness mangled with purely false assumptions but from what I can tell, what you should do is something along the line of: - kernel uses normal ioread32 on all platforms - userspace use lwbrx on powerpc and normal loads on LE platforms via some kind of macro you define for that That will give you a consistent view accross the board. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, Feb 20, 2009 at 3:07 PM, Ira Snyder wrote: > On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote: >> On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote: >> > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote: >> > >> > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you >> > want. They don't change byte ordering. >> >> Are they guaranteed to only do 32-bit, aligned accesses? >> > > I don't think so. I certainly wouldn't count on anything better than a > byte-by-byte memcpy. > >> I made some cheats on my CPLD to ignore byte enables and so on, >> because it makes the design cleaner and easier to read (for students) >> plus, saves a ton of logic cells. It's totally within the PCI >> standard, but it means if you do a byte read memcpy() you get.. very >> weird results (i.e. not great). >> > > Right, I understand how that works :) > > Some usage of cscope shows that __raw_readl() might be what you want, > as well as __raw_writel() for writing. I'm not sure it is universally > available, but maybe they are. > > The comment on PowerPC says "Non ordered and non-swapping "raw" > accessors". Looks about right. ARM's implementation uses them to > implement ioread32() and friends by adding byteswapping. Am I correct in saying that cpu_to_le32 and le32_to_cpu are the functions/macros I need to use to do byte swapping to make everything go little endian (and back again when I read them back in the kernel)? Or is there some cleverer way already implemented in the kernel? -- Matt Sealey Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
Scott, I am not so sure about your PHY, but if you access to PHY while packet transmission through MDIO bus, the packet might be corrupted. Do you have "phy_interrupt" in the /proc/interrupts? What is your dmesg around the eTSEC look like (there is phy driver info surrounded). Regards Dai > -Original Message- > From: Scott Coulter [mailto:scott.coul...@cyclone.com] > Sent: Friday, February 20, 2009 3:00 PM > To: Haruki Dai-R35557; linuxppc-dev@ozlabs.org > Cc: Gala Kumar-B11780 > Subject: RE: Gianfar tx-babbling-errors > > > > > Dai, > > > Is this your own board? If so, what PHY chip are you using? Are you > > using the PHY driver? > > If the generic PHY driver is used and polling the MDIO periodically > for > > the link check, you may truncate the packet. I hope this is not the > > case. > > Yes this is our own board. Both the 8568E and 8572E processors each > expose two TSECs. The 4 TSECs are each connected to a separate > interface of a Broadcom 5464 Quad PHY in RGMII mode. I am pretty sure > that there is no interrupt connected (I'll have to check with the > hardware engineer) and I know that I didn't configure one in the DTS > file. My kernel is configured to use the Broadcomm 54xx driver, but I'm > not sure if it polls when no interrupt is configured. > > Thanks, > Scott > ___ > > Scott N. Coulter > Senior Software Engineer > > Cyclone Microsystems > 370 James Street Phone: 203.786.5536 ext. 118 > New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com > U.S.A.Web:http://www.cyclone.com > ___ > > > -Original Message- > > From: Haruki Dai-R35557 [mailto:dai.har...@freescale.com] > > Sent: February 20, 2009 2:16PM > > To: Scott Coulter; linuxppc-dev@ozlabs.org > > Cc: Gala Kumar-B11780 > > Subject: RE: Gianfar tx-babbling-errors > > > > Hi Scott, > > > > > > Regards > > Dai > > > > > -Original Message- > > > From: linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org > > > [mailto:linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org] On > > Behalf Of > > > Scott Coulter > > > Sent: Wednesday, February 18, 2009 10:16 AM > > > To: linuxppc-dev@ozlabs.org > > > Subject: Gianfar tx-babbling-errors > > > > > > > > > Hi all, > > > > > > As a simple stress test for my board with an MPC8572E and an > MPC8568E > > on > > > it, I setup both processors to boot linux 2.6.27.6 with an NFS root > > and > > > then perform repeated native compiles of a linux kernel over NFS. > > After > > > running for 4 days straight or so with between 250-300 build cycles > > per > > > processor, I stopped the builds and ran ethtool to look for any odd > > > statistics. Both processors reported non-zero values for > > > tx-babbling-errors. Both processors reported around 1300 > > > tx-babbling-errors out of about 80,000,000 Tx packets. Should I be > > > concerned about the tx-babbling-errors? What conditions would cause > > > these errors to be reported? > > > > > > Thanks, > > > Scott > > > > > > > > > > > > > > > > > > ___ > > > > > > Scott N. Coulter > > > Senior Software Engineer > > > > > > Cyclone Microsystems > > > 370 James Street Phone: 203.786.5536 ext. 118 > > > New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com > > > U.S.A.Web:http://www.cyclone.com > > > ___ > > > > > > ___ > > > Linuxppc-dev mailing list > > > Linuxppc-dev@ozlabs.org > > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, Feb 20, 2009 at 02:05:08PM -0600, Matt Sealey wrote: > On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote: > > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote: > > > > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you > > want. They don't change byte ordering. > > Are they guaranteed to only do 32-bit, aligned accesses? > I don't think so. I certainly wouldn't count on anything better than a byte-by-byte memcpy. > I made some cheats on my CPLD to ignore byte enables and so on, > because it makes the design cleaner and easier to read (for students) > plus, saves a ton of logic cells. It's totally within the PCI > standard, but it means if you do a byte read memcpy() you get.. very > weird results (i.e. not great). > Right, I understand how that works :) Some usage of cscope shows that __raw_readl() might be what you want, as well as __raw_writel() for writing. I'm not sure it is universally available, but maybe they are. The comment on PowerPC says "Non ordered and non-swapping "raw" accessors". Looks about right. ARM's implementation uses them to implement ioread32() and friends by adding byteswapping. Hope it helps, Ira > -- > Matt Sealey > Genesi, Manager, Developer Relations > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
Dai, > Is this your own board? If so, what PHY chip are you using? Are you > using the PHY driver? > If the generic PHY driver is used and polling the MDIO periodically for > the link check, you may truncate the packet. I hope this is not the > case. Yes this is our own board. Both the 8568E and 8572E processors each expose two TSECs. The 4 TSECs are each connected to a separate interface of a Broadcom 5464 Quad PHY in RGMII mode. I am pretty sure that there is no interrupt connected (I'll have to check with the hardware engineer) and I know that I didn't configure one in the DTS file. My kernel is configured to use the Broadcomm 54xx driver, but I'm not sure if it polls when no interrupt is configured. Thanks, Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ > -Original Message- > From: Haruki Dai-R35557 [mailto:dai.har...@freescale.com] > Sent: February 20, 2009 2:16PM > To: Scott Coulter; linuxppc-dev@ozlabs.org > Cc: Gala Kumar-B11780 > Subject: RE: Gianfar tx-babbling-errors > > Hi Scott, > > > Regards > Dai > > > -Original Message- > > From: linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org > > [mailto:linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org] On > Behalf Of > > Scott Coulter > > Sent: Wednesday, February 18, 2009 10:16 AM > > To: linuxppc-dev@ozlabs.org > > Subject: Gianfar tx-babbling-errors > > > > > > Hi all, > > > > As a simple stress test for my board with an MPC8572E and an MPC8568E > on > > it, I setup both processors to boot linux 2.6.27.6 with an NFS root > and > > then perform repeated native compiles of a linux kernel over NFS. > After > > running for 4 days straight or so with between 250-300 build cycles > per > > processor, I stopped the builds and ran ethtool to look for any odd > > statistics. Both processors reported non-zero values for > > tx-babbling-errors. Both processors reported around 1300 > > tx-babbling-errors out of about 80,000,000 Tx packets. Should I be > > concerned about the tx-babbling-errors? What conditions would cause > > these errors to be reported? > > > > Thanks, > > Scott > > > > > > > > > > > > ___ > > > > Scott N. Coulter > > Senior Software Engineer > > > > Cyclone Microsystems > > 370 James Street Phone: 203.786.5536 ext. 118 > > New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com > > U.S.A.Web:http://www.cyclone.com > > ___ > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote: * Kumar Gala | 2009-02-19 14:49:17 [-0600]: Now that we set archdata for of_platform and platform devices via platform_notify() we no longer need to special case having a NULL device pointer or NULL archdata. It should be a driver error if this condition shows up and the driver should be fixed. Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on ppc 86xx, looks good. Acked-by: Becky Bruce -B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote: * Kumar Gala | 2009-02-19 14:49:16 [-0600]: Since a number of powerpc chips are SoCs we end up having dma-able devices that are registered as platform or of_platform devices. We need to hook the archdata to setup proper dma_ops for these devices. In the short term the majority of these devices only need the direct_dma_ops as the platforms don't have any IOMMUs. In the future to enable >4G DMA support on ppc32 we can hook swiotlb ops. Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on ppc 86xx, looks good. Acked-by: Becky Bruce -B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
On Feb 19, 2009, at 4:08 PM, Benjamin Krill wrote: * Kumar Gala | 2009-02-19 14:49:15 [-0600]: This will allow us to remove the ppc32 specific checks in get_dma_ops() that defaults to dma_direct_ops if the archdata is NULL. We really should always have archdata set to something going forward. Signed-off-by: Kumar Gala Acked-by: Benjamin Krill Tested on ppc 86xx, looks good. Acked-by: Becky Bruce -B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, Feb 20, 2009 at 1:11 PM, Ira Snyder wrote: > On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote: > > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you > want. They don't change byte ordering. Are they guaranteed to only do 32-bit, aligned accesses? I made some cheats on my CPLD to ignore byte enables and so on, because it makes the design cleaner and easier to read (for students) plus, saves a ton of logic cells. It's totally within the PCI standard, but it means if you do a byte read memcpy() you get.. very weird results (i.e. not great). -- Matt Sealey Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Gianfar tx-babbling-errors
Hi Scott, Is this your own board? If so, what PHY chip are you using? Are you using the PHY driver? If the generic PHY driver is used and polling the MDIO periodically for the link check, you may truncate the packet. I hope this is not the case. Regards Dai > -Original Message- > From: linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org > [mailto:linuxppc-dev-bounces+dai.haruki=freescale@ozlabs.org] On Behalf Of > Scott Coulter > Sent: Wednesday, February 18, 2009 10:16 AM > To: linuxppc-dev@ozlabs.org > Subject: Gianfar tx-babbling-errors > > > Hi all, > > As a simple stress test for my board with an MPC8572E and an MPC8568E on > it, I setup both processors to boot linux 2.6.27.6 with an NFS root and > then perform repeated native compiles of a linux kernel over NFS. After > running for 4 days straight or so with between 250-300 build cycles per > processor, I stopped the builds and ran ethtool to look for any odd > statistics. Both processors reported non-zero values for > tx-babbling-errors. Both processors reported around 1300 > tx-babbling-errors out of about 80,000,000 Tx packets. Should I be > concerned about the tx-babbling-errors? What conditions would cause > these errors to be reported? > > Thanks, > Scott > > > > > > ___ > > Scott N. Coulter > Senior Software Engineer > > Cyclone Microsystems > 370 James Street Phone: 203.786.5536 ext. 118 > New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com > U.S.A.Web:http://www.cyclone.com > ___ > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI reading without endian conversion
On Fri, Feb 20, 2009 at 12:57:36PM -0600, Matt Sealey wrote: > Hi guys, > > What's the correct way to read from PCI address space (basically it's > guaranteed to be non-coherent memory bar) without flipping bits like > ioread32() does? > > I need to be able to copy a bank of registers from PCI address space > into a temporary buffer so I can compare them in userspace through > UIO. Because of the flipping and the difference between the original > kernel driver (which used ioread32() and therefore "saw" big endian) > and the userspace app (which has a direct view of the PCI space, and > therefore "sees" little endian) I decided to give userspace an > absolutely consistent little-endian view seeing as this may get ported > to ARM in the coming months. > > I want to put as little code in there as possible and not laboriously > manually flip from my ioread32() big endian values to little endian > again (waste of time and code) if I can help it. Being able to read > the raw value would help a lot, and if I need to do calculations on a > small portion of the data then I can do the flips manually then (using > le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the > amount of porting I need to do in both kernel and userspace alike. > > So, is there something like a direct ioread32le() or so, which will > not change behaviour across architectures, is present on ARM and PPC, > and will handle both PCI address space, and "normal" "ioremapped" > memory? > I'm pretty sure memcpy_fromio() and memcpy_toio() will get you what you want. They don't change byte ordering. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PCI reading without endian conversion
Hi guys, What's the correct way to read from PCI address space (basically it's guaranteed to be non-coherent memory bar) without flipping bits like ioread32() does? I need to be able to copy a bank of registers from PCI address space into a temporary buffer so I can compare them in userspace through UIO. Because of the flipping and the difference between the original kernel driver (which used ioread32() and therefore "saw" big endian) and the userspace app (which has a direct view of the PCI space, and therefore "sees" little endian) I decided to give userspace an absolutely consistent little-endian view seeing as this may get ported to ARM in the coming months. I want to put as little code in there as possible and not laboriously manually flip from my ioread32() big endian values to little endian again (waste of time and code) if I can help it. Being able to read the raw value would help a lot, and if I need to do calculations on a small portion of the data then I can do the flips manually then (using le32_to_cpu and cpu_to_le32 which will be a noop on ARM), reducing the amount of porting I need to do in both kernel and userspace alike. So, is there something like a direct ioread32le() or so, which will not change behaviour across architectures, is present on ARM and PPC, and will handle both PCI address space, and "normal" "ioremapped" memory? -- Matt Sealey Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
eTSEC queries on 8548E
Hi, I am a newbie to PowerPC architecture and eTSEC. I have some queries: 1. Is there a way for me to configure different eTSECs in different media modes? I understand that the MII interface does the same thing; yet do I have to take some explicit care in the drivers for the eTSEC to differentiate between a copper and fiber interface? Is this task of the SW or is this configuration basically by the HW. 2. My custom board has the TSECs connected to a Marvell switch; one of the ports being connected via the RGMII interface to a copper media; whilst the other connected via the RGMII interface to another port on the switch via the SGMII interface. Do I need to make any changes in the driver to effect this configuration. I referred the gianfar, mdio, phy, mii drivers; but couldnt find any specific code which would enable me to differentiate the media interfaces. 3. My HW team tells me to write specific values to the PHY registers which will differentiate the media interfaces to the Marvell switch via the MDIO/MDCTL configuration lines from the MPC. If this is the case, a. Would it be recommended to implement a PHY-ID specific implementation for writing to the PHY registers in the gfar_enet_open when the phy_connect function is called? OR b. Would it be recommended to pass some kind of member through the DTS file to the kernel, therbey affecting a change in the platform specific file. Can any one please help me clear off these queries? Thanx! Sundar ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 10/13] sdhci: Add quirk for controllers that need small delays for PIO
Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |3 +++
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f63db25..eff615d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -391,6 +391,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host)
mask = ~0;
while (sdhci_readl(host, SDHCI_PRESENT_STATE) & mask) {
+ if (host->quirks & SDHCI_QUIRK_PIO_NEEDS_DELAY)
+ udelay(100);
+
if (host->data->flags & MMC_DATA_READ)
sdhci_read_block_pio(host);
else
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 63b436a..44c820a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -227,6 +227,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_32BIT_REGISTERS(1<<18)
/* Controller has nonstandard clock management */
#define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
+/* Controller does not like fast PIO transfers */
+#define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<20)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Add power management support for MPC837x boards
On Fri, Feb 20, 2009 at 11:31:09AM -0600, Scott Wood wrote: > Anton Vorontsov wrote: >> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts >> b/arch/powerpc/boot/dts/mpc8377_mds.dts >> index 3e3ec8f..c54b90d 100644 >> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts >> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts >> @@ -137,6 +137,7 @@ >> reg = <0x3000 0x100>; >> interrupts = <14 0x8>; >> interrupt-parent = <&ipic>; >> +sleep = <&pmc 0x0c00>; >> dfsrr; > > [snip] > >> @@ -318,6 +325,7 @@ >> reg = <0x2e000 0x1000>; >> interrupts = <42 0x8>; >> interrupt-parent = <&ipic>; >> +sleep = <&pmc 0x0c00>; > > You have two different nodes with the same bits referenced. Yes, I2C1 and eSDHC are using the same clock source. > These nodes > cannot be put to sleep independently, and as such need to be under a > common sleep-nexus node. Ah, that's what the sleep-nexus nodes are for... ;-) Thank you Scott, I'll add the sleep-nexus nodes. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 13/13] mmc: Add OpenFirmware bindings for SDHCI driver
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.
So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: Anton Vorontsov
Acked-by: Arnd Bergmann
---
drivers/mmc/host/Kconfig| 10 ++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sdhci-of.c | 287 +++
3 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/sdhci-of.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 99d4b28..73b79e1 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -65,6 +65,16 @@ config MMC_RICOH_MMC
If unsure, say Y.
+config MMC_SDHCI_OF
+ tristate "SDHCI support on OpenFirmware platforms"
+ depends on MMC_SDHCI && PPC_OF
+ help
+ This selects the OF support for Secure Digital Host Controller
+ Interfaces. So far, only the Freescale eSDHC controller is known
+ to exist on OF platforms.
+
+ If unsure, say N.
+
config MMC_OMAP
tristate "TI OMAP Multimedia Card Interface support"
depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index dedec55..dd512d9 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMC_MXC) += mxcmmc.o
obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o
obj-$(CONFIG_MMC_RICOH_MMC)+= ricoh_mmc.o
+obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
obj-$(CONFIG_MMC_OMAP) += omap.o
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
new file mode 100644
index 000..22bf006
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of.c
@@ -0,0 +1,287 @@
+/*
+ * OpenFirmware bindings for Secure Digital Host Controller Interface.
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ *
+ * Authors: Xiaobo Xie
+ * Anton Vorontsov
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "sdhci.h"
+
+struct sdhci_of_data {
+ unsigned int quirks;
+ struct sdhci_ops ops;
+};
+
+struct sdhci_of_host {
+ unsigned int clock;
+};
+
+/*
+ * Ops and quirks for the Freescale eSDHC controller.
+ */
+
+#define ESDHC_DMA_SYSCTL 0x40c
+#define ESDHC_DMA_SNOOP0x0040
+
+#define ESDHC_SYSTEM_CONTROL 0x2c
+#define ESDHC_CLOCK_MASK 0xfff0
+#define ESDHC_PREDIV_SHIFT 8
+#define ESDHC_DIVIDER_SHIFT4
+#define ESDHC_CLOCK_PEREN 0x0004
+#define ESDHC_CLOCK_HCKEN 0x0002
+#define ESDHC_CLOCK_IPGEN 0x0001
+
+static u32 esdhc_readl(struct sdhci_host *host, int reg)
+{
+ return in_be32(host->ioaddr + reg);
+}
+
+static u16 esdhc_readw(struct sdhci_host *host, int reg)
+{
+ return in_be16(host->ioaddr + (reg ^ 0x2));
+}
+
+static u8 esdhc_readb(struct sdhci_host *host, int reg)
+{
+ return in_8(host->ioaddr + (reg ^ 0x3));
+}
+
+static void esdhc_writel(struct sdhci_host *host, u32 val, int reg)
+{
+ out_be32(host->ioaddr + reg, val);
+}
+
+static void esdhc_writew(struct sdhci_host *host, u16 val, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x2) * 8;
+
+ clrsetbits_be32(host->ioaddr + base, 0x << shift, val << shift);
+}
+
+static void esdhc_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+ int base = reg & ~0x3;
+ int shift = (reg & 0x3) * 8;
+
+ clrsetbits_be32(host->ioaddr + base , 0xff << shift, val << shift);
+}
+
+static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+ int div;
+ int pre_div = 2;
+
+ clrbits32(host->ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
+ ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
+
+ if (clock == 0)
+ goto out;
+
+ if (host->max_clk / 16 > clock) {
+ for (; pre_div < 256; pre_div *= 2) {
+ if (host->max_clk / pre_div < clock * 16)
+ break;
+ }
+ }
+
+ for (div = 1; div <= 16; div++) {
+ if (host->max_clk / (div * pre_div) <= clock)
+ break;
+ }
+
+ pre_div >>= 1;
+
+ setbits32(host->ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
+ ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN |
+ div << ESDHC_DIVIDER_SHIFT | pre_div << ESDHC_PREDIV_SHIFT);
+ mdelay(10
[PATCH 09/13] sdhci: Add set_clock callback and a quirk for nonstandard clocks
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
that makes the patch difficult to reuse.
[1] http://lkml.org/lkml/2008/12/2/160
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |6 ++
drivers/mmc/host/sdhci.h |4
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 96a0482..f63db25 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1013,6 +1013,12 @@ static void sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
if (clock == host->clock)
return;
+ if (host->ops->set_clock) {
+ host->ops->set_clock(host, clock);
+ if (host->quirks & SDHCI_QUIRK_NONSTANDARD_CLOCK)
+ return;
+ }
+
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
if (clock == 0)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index ef70900..63b436a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -225,6 +225,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<17)
/* Controller has all registers of 32 bit width */
#define SDHCI_QUIRK_32BIT_REGISTERS(1<<18)
+/* Controller has nonstandard clock management */
+#define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
@@ -288,6 +290,8 @@ struct sdhci_ops {
void(*writew)(struct sdhci_host *host, u16 val, int reg);
void(*writeb)(struct sdhci_host *host, u8 val, int reg);
+ void(*set_clock)(struct sdhci_host *host, unsigned int clock);
+
int (*enable_dma)(struct sdhci_host *host);
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 12/13] sdhci: Add quirk for controllers with max. block size up to 4096 bytes
FSL eSDHC controllers can support maximum block size up to 4096
bytes. The MBL (Maximum Block Length) field in the capabilities
register extended by one bit, and bits 13:15 in the block size
register reserved.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 28
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 91f021d..4397694 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -682,6 +682,7 @@ static void sdhci_set_transfer_irqs(struct sdhci_host *host)
static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
{
+ u16 blksz;
u8 count;
u8 ctrl;
int ret;
@@ -831,7 +832,12 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
sdhci_set_transfer_irqs(host);
/* We do not handle DMA boundaries, so set it to max (512 KiB) */
- sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data->blksz), SDHCI_BLOCK_SIZE);
+ if (host->quirks & SDHCI_QUIRK_MAX_BLK_SZ_4096)
+ blksz = data->blksz;
+ else
+ blksz = SDHCI_MAKE_BLKSZ(7, data->blksz);
+
+ sdhci_writew(host, blksz, SDHCI_BLOCK_SIZE);
sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
}
@@ -1840,13 +1846,19 @@ int sdhci_add_host(struct sdhci_host *host)
* Maximum block size. This varies from controller to controller and
* is specified in the capabilities register.
*/
- mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >>
SDHCI_MAX_BLOCK_SHIFT;
- if (mmc->max_blk_size >= 3) {
- printk(KERN_WARNING "%s: Invalid maximum block size, "
- "assuming 512 bytes\n", mmc_hostname(mmc));
- mmc->max_blk_size = 512;
- } else
- mmc->max_blk_size = 512 << mmc->max_blk_size;
+ if (host->quirks & SDHCI_QUIRK_MAX_BLK_SZ_4096) {
+ mmc->max_blk_size = 3;
+ } else {
+ mmc->max_blk_size = (caps & SDHCI_MAX_BLOCK_MASK) >>
+ SDHCI_MAX_BLOCK_SHIFT;
+ if (mmc->max_blk_size >= 3) {
+ printk(KERN_WARNING "%s: Invalid maximum block size, "
+ "assuming 512 bytes\n", mmc_hostname(mmc));
+ mmc->max_blk_size = 0;
+ }
+ }
+
+ mmc->max_blk_size = 512 << mmc->max_blk_size;
/*
* Maximum block count.
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 5c5a950..c8628b4 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -231,6 +231,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<20)
/* Controller losing signal/interrupt enable states after reset */
#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<21)
+/* Controller supports nonstandard maximum block length of 4096 bytes */
+#define SDHCI_QUIRK_MAX_BLK_SZ_4096(1<<22)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 11/13] sdhci: Add quirk for controllers that need IRQ re-init after reset
FSL eSDHC controllers losing signal/interrupt enable states after
reset, so we should re-enable them.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |7 +++
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index eff615d..91f021d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -189,6 +189,7 @@ static void sdhci_disable_card_detection(struct sdhci_host
*host)
static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
unsigned long timeout;
+ u32 uninitialized_var(ier);
if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
@@ -196,6 +197,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
return;
}
+ if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
+ ier = sdhci_readl(host, SDHCI_INT_ENABLE);
+
sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
if (mask & SDHCI_RESET_ALL)
@@ -215,6 +219,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
timeout--;
mdelay(1);
}
+
+ if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
+ sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
}
static void sdhci_init(struct sdhci_host *host)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 44c820a..5c5a950 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -229,6 +229,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
/* Controller does not like fast PIO transfers */
#define SDHCI_QUIRK_PIO_NEEDS_DELAY(1<<20)
+/* Controller losing signal/interrupt enable states after reset */
+#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<21)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 07/13] sdhci: Add support for hosts with strict 32 bit addressing
SDHCI driver must take special care when working with "triggering"
registers on hosts with strict 32 bit addressing.
In FSL eSDHC hosts all registers are 32 bit width, writing to the
first half of any register will cause [undefined?] write the second
half of the register. That is, 16 bit write to the TRANSFER_MODE
register, makes hardware see a bogus write to the COMMAND register
(these two registers are adjacent).
This patch adds SDHCI_QUIRK_32BIT_REGISTERS quirk. When specified,
the sdhci driver will try to "pack" all dangerous writes into single
32 bit write transaction.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 19 ++-
drivers/mmc/host/sdhci.h |4
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d668625..1c36a25 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -825,13 +825,13 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
}
-static void sdhci_set_transfer_mode(struct sdhci_host *host,
+static u16 sdhci_get_transfer_mode(struct sdhci_host *host,
struct mmc_data *data)
{
u16 mode;
if (data == NULL)
- return;
+ return 0;
WARN_ON(!host->data);
@@ -843,7 +843,7 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
if (host->flags & SDHCI_REQ_USE_DMA)
mode |= SDHCI_TRNS_DMA;
- sdhci_writew(host, mode, SDHCI_TRANSFER_MODE);
+ return mode;
}
static void sdhci_finish_data(struct sdhci_host *host)
@@ -895,6 +895,7 @@ static void sdhci_finish_data(struct sdhci_host *host)
static void sdhci_send_command(struct sdhci_host *host, struct mmc_command
*cmd)
{
int flags;
+ u16 xfer_mode;
u32 mask;
unsigned long timeout;
@@ -933,7 +934,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd->arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd->data);
+ xfer_mode = sdhci_get_transfer_mode(host, cmd->data);
if ((cmd->flags & MMC_RSP_136) && (cmd->flags & MMC_RSP_BUSY)) {
printk(KERN_ERR "%s: Unsupported response type!\n",
@@ -959,7 +960,15 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
if (cmd->data)
flags |= SDHCI_CMD_DATA;
- sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
+ if (host->quirks & SDHCI_QUIRK_32BIT_REGISTERS) {
+ sdhci_writel(host,
+ SDHCI_MAKE_CMD_32BIT(cmd->opcode, flags, xfer_mode),
+ SDHCI_TRANSFER_MODE);
+ } else {
+ sdhci_writew(host, xfer_mode, SDHCI_TRANSFER_MODE);
+ sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags),
+ SDHCI_COMMAND);
+ }
}
static void sdhci_finish_command(struct sdhci_host *host)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 051fef5..7b115d8 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -44,6 +44,8 @@
#define SDHCI_CMD_RESP_SHORT_BUSY 0x03
#define SDHCI_MAKE_CMD(c, f) (((c & 0xff) << 8) | (f & 0xff))
+#define SDHCI_MAKE_CMD_32BIT(c, f, m) \
+ c) & 0xff) << 24) | (((f) & 0xff) << 16) | ((m) & 0x37))
#define SDHCI_RESPONSE 0x10
@@ -221,6 +223,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_BROKEN_CARD_DETECTION (1<<16)
/* Controller reports inverted write-protect state */
#define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<17)
+/* Controller has all registers of 32 bit width */
+#define SDHCI_QUIRK_32BIT_REGISTERS(1<<18)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 04/13] sdhci: Enable only relevant (DMA/PIO) interrupts during transfers
Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.
This patch modifies the driver so that now we only enable relevant
(DMA or PIO) interrupts during transfers.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fadaeb8..2728e90 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -222,9 +222,7 @@ static void sdhci_init(struct sdhci_host *host)
SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_INDEX |
SDHCI_INT_END_BIT | SDHCI_INT_CRC | SDHCI_INT_TIMEOUT |
- SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL |
- SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE |
- SDHCI_INT_ADMA_ERROR);
+ SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE);
}
static void sdhci_reinit(struct sdhci_host *host)
@@ -658,6 +656,17 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host,
struct mmc_data *data)
return count;
}
+static void sdhci_set_transfer_irqs(struct sdhci_host *host)
+{
+ u32 pio_irqs = SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL;
+ u32 dma_irqs = SDHCI_INT_DMA_END | SDHCI_INT_ADMA_ERROR;
+
+ if (host->flags & SDHCI_REQ_USE_DMA)
+ sdhci_clear_set_irqs(host, pio_irqs, dma_irqs);
+ else
+ sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
+}
+
static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
{
u8 count;
@@ -806,6 +815,8 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
host->blocks = data->blocks;
}
+ sdhci_set_transfer_irqs(host);
+
/* We do not handle DMA boundaries, so set it to max (512 KiB) */
sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data->blksz), SDHCI_BLOCK_SIZE);
sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 08/13] sdhci: Add get_{max,timeout}_clock callbacks
From: Ben Dooks
Some controllers do not provide clock information in their capabilities
(in the Samsung case, it is because there are multiple clock sources
available to the controller). Add hooks to allow the system to supply
clock information.
p.s.
In the original Ben's patch there was a bug that makes sdhci_add_host()
return -ENODEV even if callbacks were specified. This is fixed now.
Signed-off-by: Ben Dooks
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 22 +++---
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1c36a25..96a0482 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1736,19 +1736,27 @@ int sdhci_add_host(struct sdhci_host *host)
host->max_clk =
(caps & SDHCI_CLOCK_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
+ host->max_clk *= 100;
if (host->max_clk == 0) {
- printk(KERN_ERR "%s: Hardware doesn't specify base clock "
- "frequency.\n", mmc_hostname(mmc));
- return -ENODEV;
+ if (!host->ops->get_max_clock) {
+ printk(KERN_ERR
+ "%s: Hardware doesn't specify base clock "
+ "frequency.\n", mmc_hostname(mmc));
+ return -ENODEV;
+ }
+ host->max_clk = host->ops->get_max_clock(host);
}
- host->max_clk *= 100;
host->timeout_clk =
(caps & SDHCI_TIMEOUT_CLK_MASK) >> SDHCI_TIMEOUT_CLK_SHIFT;
if (host->timeout_clk == 0) {
- printk(KERN_ERR "%s: Hardware doesn't specify timeout clock "
- "frequency.\n", mmc_hostname(mmc));
- return -ENODEV;
+ if (!host->ops->get_timeout_clock) {
+ printk(KERN_ERR
+ "%s: Hardware doesn't specify timeout clock "
+ "frequency.\n", mmc_hostname(mmc));
+ return -ENODEV;
+ }
+ host->timeout_clk = host->ops->get_timeout_clock(host);
}
if (caps & SDHCI_TIMEOUT_CLK_UNIT)
host->timeout_clk *= 1000;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 7b115d8..ef70900 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -289,6 +289,8 @@ struct sdhci_ops {
void(*writeb)(struct sdhci_host *host, u8 val, int reg);
int (*enable_dma)(struct sdhci_host *host);
+ unsigned int(*get_max_clock)(struct sdhci_host *host);
+ unsigned int(*get_timeout_clock)(struct sdhci_host *host);
};
extern void sdhci_writel(struct sdhci_host *host, u32 val, int reg);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 06/13] sdhci: Add support for hosts reporting inverted write-protect state
This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.
p.s. Actually, the quirk is more board-specific than
controller-specific.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |2 ++
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 782fb58..d668625 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1202,6 +1202,8 @@ static int sdhci_get_ro(struct mmc_host *mmc)
spin_unlock_irqrestore(&host->lock, flags);
+ if (host->quirks & SDHCI_QUIRK_INVERTED_WRITE_PROTECT)
+ return !!(present & SDHCI_WRITE_PROTECT);
return !(present & SDHCI_WRITE_PROTECT);
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index b10920d..051fef5 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -219,6 +219,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_NO_BUSY_IRQ(1<<15)
/* Controller has unreliable card detection */
#define SDHCI_QUIRK_BROKEN_CARD_DETECTION (1<<16)
+/* Controller reports inverted write-protect state */
+#define SDHCI_QUIRK_INVERTED_WRITE_PROTECT (1<<17)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 02/13] sdhci: Add support for bus-specific IO memory accessors
Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).
With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.
For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endian addressing. That is, readb(0x2f) should turn
into readb(0x2c), and readw(0x2c) should be translated to
le16_to_cpu(readw(0x2e)).
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci-pci.c |4 +-
drivers/mmc/host/sdhci.c | 214 ++
drivers/mmc/host/sdhci.h | 14 +++
3 files changed, 149 insertions(+), 83 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index f07255c..a3ced4d 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -212,7 +212,7 @@ static int jmicron_probe_slot(struct sdhci_pci_slot *slot)
if (slot->chip->pdev->revision == 0) {
u16 version;
- version = readl(slot->host->ioaddr + SDHCI_HOST_VERSION);
+ version = sdhci_readl(slot->host, SDHCI_HOST_VERSION);
version = (version & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
@@ -583,7 +583,7 @@ static void sdhci_pci_remove_slot(struct sdhci_pci_slot
*slot)
u32 scratch;
dead = 0;
- scratch = readl(slot->host->ioaddr + SDHCI_INT_STATUS);
+ scratch = sdhci_readl(slot->host, SDHCI_INT_STATUS);
if (scratch == (u32)-1)
dead = 1;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0a1f5c5..8682f7f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
@@ -48,35 +49,35 @@ static void sdhci_dumpregs(struct sdhci_host *host)
printk(KERN_DEBUG DRIVER_NAME ": == REGISTER DUMP
==\n");
printk(KERN_DEBUG DRIVER_NAME ": Sys addr: 0x%08x | Version: 0x%08x\n",
- readl(host->ioaddr + SDHCI_DMA_ADDRESS),
- readw(host->ioaddr + SDHCI_HOST_VERSION));
+ sdhci_readl(host, SDHCI_DMA_ADDRESS),
+ sdhci_readw(host, SDHCI_HOST_VERSION));
printk(KERN_DEBUG DRIVER_NAME ": Blk size: 0x%08x | Blk cnt: 0x%08x\n",
- readw(host->ioaddr + SDHCI_BLOCK_SIZE),
- readw(host->ioaddr + SDHCI_BLOCK_COUNT));
+ sdhci_readw(host, SDHCI_BLOCK_SIZE),
+ sdhci_readw(host, SDHCI_BLOCK_COUNT));
printk(KERN_DEBUG DRIVER_NAME ": Argument: 0x%08x | Trn mode: 0x%08x\n",
- readl(host->ioaddr + SDHCI_ARGUMENT),
- readw(host->ioaddr + SDHCI_TRANSFER_MODE));
+ sdhci_readl(host, SDHCI_ARGUMENT),
+ sdhci_readw(host, SDHCI_TRANSFER_MODE));
printk(KERN_DEBUG DRIVER_NAME ": Present: 0x%08x | Host ctl: 0x%08x\n",
- readl(host->ioaddr + SDHCI_PRESENT_STATE),
- readb(host->ioaddr + SDHCI_HOST_CONTROL));
+ sdhci_readl(host, SDHCI_PRESENT_STATE),
+ sdhci_readb(host, SDHCI_HOST_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Power:0x%08x | Blk gap: 0x%08x\n",
- readb(host->ioaddr + SDHCI_POWER_CONTROL),
- readb(host->ioaddr + SDHCI_BLOCK_GAP_CONTROL));
+ sdhci_readb(host, SDHCI_POWER_CONTROL),
+ sdhci_readb(host, SDHCI_BLOCK_GAP_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Wake-up: 0x%08x | Clock:0x%08x\n",
- readb(host->ioaddr + SDHCI_WAKE_UP_CONTROL),
- readw(host->ioaddr + SDHCI_CLOCK_CONTROL));
+ sdhci_readb(host, SDHCI_WAKE_UP_CONTROL),
+ sdhci_readw(host, SDHCI_CLOCK_CONTROL));
printk(KERN_DEBUG DRIVER_NAME ": Timeout: 0x%08x | Int stat: 0x%08x\n",
- readb(host->ioaddr + SDHCI_TIMEOUT_CONTROL),
- readl(host->ioaddr + SDHCI_INT_STATUS));
+ sdhci_readb(host, SDHCI_TIMEOUT_CONTROL),
+ sdhci_readl(host, SDHCI_INT_STATUS));
printk(KERN_DEBUG DRIVER_NAME ": Int enab: 0x%08x | Sig enab: 0x%08x\n",
- readl(host->ioaddr + SDHCI_INT_ENABLE),
- readl(host->ioaddr + SDHCI_SIGNAL_ENABLE));
+ sdhci_readl(host, SDHCI_INT_ENABLE),
+ sdhci_readl(host, SDHCI_SIGNAL_ENABLE));
printk(KERN_DEBUG DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
- readw(host->ioaddr + SDHCI_ACMD12_ERR),
- readw(host->ioaddr + SDHCI_SLOT_INT_STATUS));
+ sdhci_readw(host, SDHCI_ACMD12_ERR),
+ sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
printk(KERN_DEBUG DRIVER_NAME ": Caps: 0x%08x | Max curr: 0x%08x\n",
- readl(host->ioaddr + SDHCI_CAPABILITIES),
- readl(host->ioaddr + SDHCI_MAX_CURRENT));
+ sdhci_readl(hos
[PATCH 03/13] sdhci: Split card-detection IRQs management from sdhci_init()
Card detection interrupts should be handled separately as they should
not be enabled before mmc_add_host() returns and should be disabled
before calling mmc_remove_host(). The same is for suspend and resume
routines.
sdhci_init() no longer enables card-detection irqs. Instead, two new
functions implemented: sdhci_enable_card_detection() and
sdhci_disable_card_detection().
New sdhci_reinit() call implemented to behave the same way as the old
sdhci_init().
Also, this patch implements and uses few new helpers to manage IRQs in
a more conveinient way, that is:
- sdhci_clear_set_irqs()
- sdhci_unmask_irqs()
- sdhci_mask_irqs()
- SDHCI_INT_ALL_MASK constant
sdhci_enable_sdio_irq() converted to these new helpers, plus the
helpers will be used by the subsequent patches.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 78 --
drivers/mmc/host/sdhci.h |4 ++
2 files changed, 65 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8682f7f..fadaeb8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -142,6 +142,47 @@ u8 sdhci_readb(struct sdhci_host *host, int reg)
}
EXPORT_SYMBOL_GPL(sdhci_readb);
+static void sdhci_clear_set_irqs(struct sdhci_host *host, u32 clear, u32 set)
+{
+ u32 ier;
+
+ ier = sdhci_readl(host, SDHCI_INT_ENABLE);
+ ier &= ~clear;
+ ier |= set;
+ sdhci_writel(host, ier, SDHCI_INT_ENABLE);
+ sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_unmask_irqs(struct sdhci_host *host, u32 irqs)
+{
+ sdhci_clear_set_irqs(host, 0, irqs);
+}
+
+static void sdhci_mask_irqs(struct sdhci_host *host, u32 irqs)
+{
+ sdhci_clear_set_irqs(host, irqs, 0);
+}
+
+static void sdhci_set_card_detection(struct sdhci_host *host, bool enable)
+{
+ u32 irqs = SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT;
+
+ if (enable)
+ sdhci_unmask_irqs(host, irqs);
+ else
+ sdhci_mask_irqs(host, irqs);
+}
+
+static void sdhci_enable_card_detection(struct sdhci_host *host)
+{
+ sdhci_set_card_detection(host, true);
+}
+
+static void sdhci_disable_card_detection(struct sdhci_host *host)
+{
+ sdhci_set_card_detection(host, false);
+}
+
static void sdhci_reset(struct sdhci_host *host, u8 mask)
{
unsigned long timeout;
@@ -175,20 +216,21 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
static void sdhci_init(struct sdhci_host *host)
{
- u32 intmask;
-
sdhci_reset(host, SDHCI_RESET_ALL);
- intmask = SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
+ sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK,
+ SDHCI_INT_BUS_POWER | SDHCI_INT_DATA_END_BIT |
SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT | SDHCI_INT_INDEX |
SDHCI_INT_END_BIT | SDHCI_INT_CRC | SDHCI_INT_TIMEOUT |
- SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT |
SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL |
SDHCI_INT_DMA_END | SDHCI_INT_DATA_END | SDHCI_INT_RESPONSE |
- SDHCI_INT_ADMA_ERROR;
+ SDHCI_INT_ADMA_ERROR);
+}
- sdhci_writel(host, intmask, SDHCI_INT_ENABLE);
- sdhci_writel(host, intmask, SDHCI_SIGNAL_ENABLE);
+static void sdhci_reinit(struct sdhci_host *host)
+{
+ sdhci_init(host);
+ sdhci_enable_card_detection(host);
}
static void sdhci_activate_led(struct sdhci_host *host)
@@ -1087,7 +1129,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
*/
if (ios->power_mode == MMC_POWER_OFF) {
sdhci_writel(host, 0, SDHCI_SIGNAL_ENABLE);
- sdhci_init(host);
+ sdhci_reinit(host);
}
sdhci_set_clock(host, ios->clock);
@@ -1148,7 +1190,6 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc,
int enable)
{
struct sdhci_host *host;
unsigned long flags;
- u32 ier;
host = mmc_priv(mmc);
@@ -1157,15 +1198,10 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc,
int enable)
if (host->flags & SDHCI_DEVICE_DEAD)
goto out;
- ier = sdhci_readl(host, SDHCI_INT_ENABLE);
-
- ier &= ~SDHCI_INT_CARD_INT;
if (enable)
- ier |= SDHCI_INT_CARD_INT;
-
- sdhci_writel(host, ier, SDHCI_INT_ENABLE);
- sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
-
+ sdhci_unmask_irqs(host, SDHCI_INT_CARD_INT);
+ else
+ sdhci_mask_irqs(host, SDHCI_INT_CARD_INT);
out:
mmiowb();
@@ -1507,6 +1543,8 @@ int sdhci_suspend_host(struct sdhci_host *host,
pm_message_t state)
{
int ret;
+ sdhci_disable_card_detection(host);
+
ret = mmc_suspend_host(host->mmc, state);
if (ret)
return ret;
@@ -1539,6 +1577,8 @@ int sdhci_resume_host(struct sdhci_host *host)
if (ret)
[PATCH 05/13] sdhci: Add support for card-detection polling
This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.
This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to "debounce" card-detection
IRQs by reading present state and disabling particular interrupts. But
with this debouncing scheme I noticed that sometimes we miss card
insertion/removal events.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c | 17 ++---
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2728e90..782fb58 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -167,6 +167,9 @@ static void sdhci_set_card_detection(struct sdhci_host
*host, bool enable)
{
u32 irqs = SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT;
+ if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ return;
+
if (enable)
sdhci_unmask_irqs(host, irqs);
else
@@ -1110,13 +1113,18 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host->mrq = mrq;
+ if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ goto send;
+
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT)
|| (host->flags & SDHCI_DEVICE_DEAD)) {
host->mrq->cmd->error = -ENOMEDIUM;
tasklet_schedule(&host->finish_tasklet);
- } else
- sdhci_send_command(host, mrq->cmd);
-
+ goto out;
+ }
+send:
+ sdhci_send_command(host, mrq->cmd);
+out:
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
}
@@ -1742,6 +1750,9 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->f_max = host->max_clk;
mmc->caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ;
+ if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ mmc->caps |= MMC_CAP_NEEDS_POLL;
+
if ((caps & SDHCI_CAN_DO_HISPD) ||
(host->quirks & SDHCI_QUIRK_FORCE_HIGHSPEED))
mmc->caps |= MMC_CAP_SD_HIGHSPEED;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 45c8309..b10920d 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -217,6 +217,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_FORCE_HIGHSPEED(1<<14)
/* Controller does not provide transfer-complete interrupt when not busy */
#define SDHCI_QUIRK_NO_BUSY_IRQ(1<<15)
+/* Controller has unreliable card detection */
+#define SDHCI_QUIRK_BROKEN_CARD_DETECTION (1<<16)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 01/13] sdhci: Add quirk for controllers with no end-of-busy IRQ
From: Ben Dooks
The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
to generate an INT_DATA_END after the transfer has completed and
the bus busy state finished.
Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
new busy method are the cause of the behaviour change.
Signed-off-by: Ben Dooks
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |5 -
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6b2d1f9..0a1f5c5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1291,8 +1291,11 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32
intmask)
if (host->cmd->data)
DBG("Cannot wait for busy signal when also "
"doing a data transfer");
- else
+ else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ))
return;
+
+ /* The controller does not support the end-of-busy IRQ,
+* fall through and take the SDHCI_INT_RESPONSE */
}
if (intmask & SDHCI_INT_RESPONSE)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 3efba23..2d08dd4 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -210,6 +210,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_BROKEN_SMALL_PIO (1<<13)
/* Controller supports high speed but doesn't have the caps bit set */
#define SDHCI_QUIRK_FORCE_HIGHSPEED(1<<14)
+/* Controller does not provide transfer-complete interrupt when not busy */
+#define SDHCI_QUIRK_NO_BUSY_IRQ(1<<15)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/13] FSL eSDHC support
Hi all, Some updates for the eSDHC support: Changes since the third RFC: - Use uninitialized_var() (suggested by Laurent Pinchart); - Fixed a bug in eSDHC SDCLK prescaler calculations because of which we were over-clocking the SDCLK, and that caused CRC errors using some SD cards; - Not a change, but some status: SDHS (50 MHz) cards were tested to NOT work (at least on MPC837x boards) -- this is to be investigated further. SDHC (> 4 GB) cards were not tested, yet. Changes since the second RFC: - Addressed all comments that were raised by Pierre Ossman. There were too many to mention them all, so here is the link: http://lkml.org/lkml/2009/2/6/320 Changes since the first RFC: - Use of_iomap() in sdhci-of.c (suggested by Arnd Bergmann). Also added Arnd's Acked-by: line for the sdhci-of patch. - Kconfig help text improved (thanks to Matt Sealey and M. Warner Losh). - In "sdhci: Add quirk to suppress PIO interrupts during DMA transfers" patch: sdhci_init() now clears SDHCI_PIO_DISABLED flag, otherwise we won't disable PIO interrupts after suspend. - New patch: "sdhci: Add type checking for IO memory accessors" -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Add power management support for MPC837x boards
Anton Vorontsov wrote: diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts index 3e3ec8f..c54b90d 100644 --- a/arch/powerpc/boot/dts/mpc8377_mds.dts +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts @@ -137,6 +137,7 @@ reg = <0x3000 0x100>; interrupts = <14 0x8>; interrupt-parent = <&ipic>; + sleep = <&pmc 0x0c00>; dfsrr; [snip] @@ -318,6 +325,7 @@ reg = <0x2e000 0x1000>; interrupts = <42 0x8>; interrupt-parent = <&ipic>; + sleep = <&pmc 0x0c00>; You have two different nodes with the same bits referenced. These nodes cannot be put to sleep independently, and as such need to be under a common sleep-nexus node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: Add power management support for MPC837x boards
This patch adds pmc nodes to the device tree files so that the boards
will able to use standby capability of MPC837x processors. The MPC837x
PMC controllers are compatible with MPC8349 ones (i.e. no deep sleep).
sleep = <> properties are used to specify SCCR masks as described
in "Specifying Device Power Management Information (sleep property)"
chapter in Documentation/powerpc/booting-without-of.txt.
A processor is able to wakeup the boards on LAN events (Wake-On-Lan),
console events (with no_console_suspend kernel command line), GPIO
events and external IRQs (IRQ1 and IRQ2).
The processor can also wakeup the boards by the fourth general purpose
timer in GTM1 block, but the GTM wakeup support isn't yet implemented
(it's tested to work, but it's unclear how can we use the quite short
GTM timers, and how do we want to expose the GTM to userspace).
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 20
arch/powerpc/boot/dts/mpc8377_rdb.dts | 20
arch/powerpc/boot/dts/mpc8378_mds.dts | 18 ++
arch/powerpc/boot/dts/mpc8378_rdb.dts | 18 ++
arch/powerpc/boot/dts/mpc8379_mds.dts | 20
arch/powerpc/boot/dts/mpc8379_rdb.dts | 20
6 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 3e3ec8f..c54b90d 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -137,6 +137,7 @@
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
+ sleep = <&pmc 0x0c00>;
dfsrr;
r...@68 {
@@ -176,6 +177,7 @@
interrupts = <38 0x8>;
dr_mode = "host";
phy_type = "ulpi";
+ sleep = <&pmc 0x00c0>;
};
m...@24520 {
@@ -226,6 +228,8 @@
interrupt-parent = <&ipic>;
tbi-handle = <&tbi0>;
phy-handle = <&phy2>;
+ sleep = <&pmc 0xc000>;
+ fsl,magic-packet;
};
enet1: ether...@25000 {
@@ -240,6 +244,8 @@
interrupt-parent = <&ipic>;
tbi-handle = <&tbi1>;
phy-handle = <&phy3>;
+ sleep = <&pmc 0x3000>;
+ fsl,magic-packet;
};
serial0: ser...@4500 {
@@ -311,6 +317,7 @@
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x9fe>;
fsl,descriptor-types-mask = <0x3ab0ebf>;
+ sleep = <&pmc 0x0300>;
};
sd...@2e000 {
@@ -318,6 +325,7 @@
reg = <0x2e000 0x1000>;
interrupts = <42 0x8>;
interrupt-parent = <&ipic>;
+ sleep = <&pmc 0x0c00>;
/* Filled in by U-Boot */
clock-frequency = <0>;
};
@@ -327,6 +335,7 @@
reg = <0x18000 0x1000>;
interrupts = <44 0x8>;
interrupt-parent = <&ipic>;
+ sleep = <&pmc 0x00c0>;
};
s...@19000 {
@@ -334,6 +343,7 @@
reg = <0x19000 0x1000>;
interrupts = <45 0x8>;
interrupt-parent = <&ipic>;
+ sleep = <&pmc 0x0030>;
};
/* IPIC
@@ -349,6 +359,13 @@
#interrupt-cells = <2>;
reg = <0x700 0x100>;
};
+
+ pmc: po...@b00 {
+ compatible = "fsl,mpc8377-pmc", "fsl,mpc8349-pmc";
+ reg = <0xb00 0x100 0xa00 0x100>;
+ interrupts = <80 0x8>;
+ interrupt-parent = <&ipic>;
+ };
};
pci0: p...@e0008500 {
@@ -403,6 +420,7 @@
ranges = <0x0200 0x0 0x9000 0x9000 0x0 0x1000
0x4200 0x0 0x8000 0x8000 0x0 0x1000
0x0100 0x0 0x 0xe030 0x0 0x0010>;
+ sleep = <&pmc 0x0001>;
clock-frequency = <0>;
#interrupt-cells = <1>;
#size-cells = <2>;
@@ -428,6 +446,7 @@
0 0 0 2 &ipic 1 8
0 0 0 3 &ipic 1 8
0 0 0 4 &ipic 1 8>;
+ sleep = <&pmc 0x0030>;
c
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 20 Feb 2009 16:46:44 +0100 Geert Uytterhoeven wrote: > Fortunately there already exists a generic RTC class driver: "rtc-parisc". > Despite it's name, it's platform-independent, as it's build on top of the RTC > abstraction used by "genrtc". > > This patch series > - adds a missing module alias to rtc-parisc, > - renames rtc-parisc to rtc-generic, > - converts the architectures that currently have CONFIG_GEN_RTC enabled in > their defconfig (m68k, parisc, powerpc) to rtc-generic, > - removes the obsolete rtc-ppc driver, > - removes the old genrtc driver. > > Note that genrtc may be used on other archictectures as well: at least alpha > has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow > genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, > xtensa). > > Furthermore genrtc and rtc-generic are not 100% userspace compatible: > - /dev/rtc provided by genrtc uses a misc character device (10:135), > - /dev/rtc provided by rtc-generic uses a dynamic character device. Hello, my opinion on this kind of stuff is that I want to avoid the layering of implementations under the rtc subsystem. I'd rather prefer that each rtc device had its own driver. I've made error in the past, by accepting such kind of drivers, and would like to avoid that it happens again. Regarding the user space, the assumption that a device has a fixed major:minor number should be dropped as well. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 5/5] rtc: Kill genrtc, as all its users have been converted to rtc-generic
Warning: genrtc and rtc-generic are not 100% userspace compatible:
- /dev/rtc provided by genrtc uses a misc character device (10:135)
- /dev/rtc provided by rtc-generic uses a dynamic character device
Signed-off-by: Geert Uytterhoeven
---
drivers/char/Kconfig | 25 ---
drivers/char/Makefile |1 -
drivers/char/genrtc.c | 527 -
3 files changed, 0 insertions(+), 553 deletions(-)
delete mode 100644 drivers/char/genrtc.c
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 735bbe2..c0960a1 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -840,31 +840,6 @@ config JS_RTC
To compile this driver as a module, choose M here: the
module will be called js-rtc.
-config GEN_RTC
- tristate "Generic /dev/rtc emulation"
- depends on RTC!=y && !IA64 && !ARM && !M32R && !MIPS && !SPARC && !FRV
&& !S390 && !SUPERH && !AVR32 && !BLACKFIN
- ---help---
- If you say Y here and create a character special file /dev/rtc with
- major number 10 and minor number 135 using mknod ("man mknod"), you
- will get access to the real time clock (or hardware clock) built
- into your computer.
-
- It reports status information via the file /proc/driver/rtc and its
- behaviour is set by various ioctls on /dev/rtc. If you enable the
- "extended RTC operation" below it will also provide an emulation
- for RTC_UIE which is required by some programs and may improve
- precision in some cases.
-
- To compile this driver as a module, choose M here: the
- module will be called genrtc.
-
-config GEN_RTC_X
- bool "Extended RTC operation"
- depends on GEN_RTC
- help
- Provides an emulation for RTC_UIE which is required by some programs
- and may improve precision of the generic RTC support in some cases.
-
config EFI_RTC
bool "EFI Real Time Clock Services"
depends on IA64
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index 565e473..c9432f0 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -75,7 +75,6 @@ obj-$(CONFIG_APPLICOM)+= applicom.o
obj-$(CONFIG_SONYPI) += sonypi.o
obj-$(CONFIG_RTC) += rtc.o
obj-$(CONFIG_HPET) += hpet.o
-obj-$(CONFIG_GEN_RTC) += genrtc.o
obj-$(CONFIG_EFI_RTC) += efirtc.o
obj-$(CONFIG_DS1302) += ds1302.o
obj-$(CONFIG_XILINX_HWICAP)+= xilinx_hwicap/
diff --git a/drivers/char/genrtc.c b/drivers/char/genrtc.c
deleted file mode 100644
index aac0985..000
--- a/drivers/char/genrtc.c
+++ /dev/null
@@ -1,527 +0,0 @@
-/*
- * Real Time Clock interface for
- * - q40 and other m68k machines,
- * - HP PARISC machines
- * - PowerPC machines
- * emulate some RTC irq capabilities in software
- *
- * Copyright (C) 1999 Richard Zidlicky
- *
- * based on Paul Gortmaker's rtc.c device and
- * Sam Creasey Generic rtc driver
- *
- * This driver allows use of the real time clock (built into
- * nearly all computers) from user space. It exports the /dev/rtc
- * interface supporting various ioctl() and also the /proc/driver/rtc
- * pseudo-file for status information.
- *
- * The ioctls can be used to set the interrupt behaviour where
- * supported.
- *
- * The /dev/rtc interface will block on reads until an interrupt
- * has been received. If a RTC interrupt has already happened,
- * it will output an unsigned long and then block. The output value
- * contains the interrupt status in the low byte and the number of
- * interrupts since the last read in the remaining high bytes. The
- * /dev/rtc interface can also be used with the select(2) call.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- *
-
- * 1.01 fix for 2.3.Xr...@linux-m68k.org
- * 1.02 merged with code from genrtc.c r...@linux-m68k.org
- * 1.03 make it more portablezip...@linux-m68k.org
- * 1.04 removed useless timer code r...@linux-m68k.org
- * 1.05 portable RTC_UIE emulation r...@linux-m68k.org
- * 1.06 set_rtc_time can return an error tr...@kernel.crashing.org
- * 1.07 ported to HP PARISC (hppa) Helge Deller
- */
-
-#define RTC_VERSION"1.07"
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-/*
- * We sponge a minor off of the misc major. No need slurping
- * up another valuable major dev number for this. If you add
- * an ioctl, make sure you don't conflict with SPAR
[PATCH/RFC 2/5] pa-risc: Rename rtc-parisc to rtc-generic
The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
generic RTC infrastructure ([gs]et_rtc_time()).
Rename the driver from rtc-parisc to rtc-generic, and make it depend on the new
Kconfig symbol ARCH_HAS_GENERIC_RTC.
Signed-off-by: Geert Uytterhoeven
---
arch/parisc/Kconfig |6 ++-
arch/parisc/kernel/time.c |6 +-
drivers/rtc/Kconfig | 10 ++--
drivers/rtc/Makefile |2 +-
drivers/rtc/rtc-generic.c | 113 +
drivers/rtc/rtc-parisc.c | 113 -
6 files changed, 127 insertions(+), 123 deletions(-)
create mode 100644 drivers/rtc/rtc-generic.c
delete mode 100644 drivers/rtc/rtc-parisc.c
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index aacf11d..cacb3a1 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -10,7 +10,7 @@ config PARISC
select HAVE_IDE
select HAVE_OPROFILE
select RTC_CLASS
- select RTC_DRV_PARISC
+ select RTC_DRV_GENERIC
select INIT_ALL_POSSIBLE
help
The PA-RISC microprocessor is designed by Hewlett-Packard and used
@@ -43,6 +43,10 @@ config ARCH_HAS_ILOG2_U64
bool
default n
+config ARCH_HAS_GENERIC_RTC
+ bool
+ default y
+
config GENERIC_FIND_NEXT_BIT
bool
default y
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 9d46c43..849f460 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -216,8 +216,8 @@ void __init start_cpu_itimer(void)
per_cpu(cpu_data, cpu).it_value = next_tick;
}
-struct platform_device rtc_parisc_dev = {
- .name = "rtc-parisc",
+static struct platform_device rtc_generic_dev = {
+ .name = "rtc-generic",
.id = -1,
};
@@ -225,7 +225,7 @@ static int __init rtc_init(void)
{
int ret;
- ret = platform_device_register(&rtc_parisc_dev);
+ ret = platform_device_register(&rtc_generic_dev);
if (ret < 0)
printk(KERN_ERR "unable to register rtc device...\n");
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81450fb..3e58182 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -677,12 +677,12 @@ config RTC_DRV_RS5C313
help
If you say yes here you get support for the Ricoh RS5C313 RTC chips.
-config RTC_DRV_PARISC
- tristate "PA-RISC firmware RTC support"
- depends on PARISC
+config RTC_DRV_GENERIC
+ tristate "Generic RTC support"
+ depends on ARCH_HAS_GENERIC_RTC
help
- Say Y or M here to enable RTC support on PA-RISC systems using
- firmware calls. If you do not know what you are doing, you should
+ Say Y or M here to enable RTC support on systems using the generic
+ RTC abstraction. If you do not know what you are doing, you should
just say Y.
config RTC_DRV_PPC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0e697aa..9c18a01 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -55,7 +55,7 @@ obj-$(CONFIG_RTC_DRV_PCF8563) += rtc-pcf8563.o
obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o
obj-$(CONFIG_RTC_DRV_PL030)+= rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031)+= rtc-pl031.o
-obj-$(CONFIG_RTC_DRV_PARISC) += rtc-parisc.o
+obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
diff --git a/drivers/rtc/rtc-generic.c b/drivers/rtc/rtc-generic.c
new file mode 100644
index 000..b744c7d
--- /dev/null
+++ b/drivers/rtc/rtc-generic.c
@@ -0,0 +1,113 @@
+/* rtc-generic: RTC driver using the generic RTC abstraction
+ *
+ * Copyright (C) 2008 Kyle McMartin
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+/* as simple as can be, and no simpler. */
+struct generic_rtc {
+ struct rtc_device *rtc;
+ spinlock_t lock;
+};
+
+static int generic_get_time(struct device *dev, struct rtc_time *tm)
+{
+ struct generic_rtc *p = dev_get_drvdata(dev);
+ unsigned long flags, ret;
+
+ spin_lock_irqsave(&p->lock, flags);
+ ret = get_rtc_time(tm);
+ spin_unlock_irqrestore(&p->lock, flags);
+
+ if (ret & RTC_BATT_BAD)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static int generic_set_time(struct device *dev, struct rtc_time *tm)
+{
+ struct generic_rtc *p = dev_get_drvdata(dev);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&p->lock, flags);
+ ret = set_rtc_time(tm);
+ spin_unlock_irqrestore(&p->lock, flags);
+
+ if (ret < 0)
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
+static const struct rtc_class_ops generic_rtc_ops = {
+ .read_time = generic_get_time,
+ .set_time = generic_set_time,
+};
+
+static int __devinit generic_rtc_probe(struct platform_device *dev)
+{
+ struct gener
[PATCH/RFC 0/5] Generic RTC class driver
I've been looking into problems with auto-loading the RTC driver on PPC (more specifically on PS3): - The recent "rtc-ppc" RTC class driver is not autoloaded by udev because it's an old style platform driver that contains its own platform device. - The alternative old "genrtc" driver is autoloaded on non-udev systems only because it contains the module alias char-major-10-135. However, it's not a new-style RTC class driver. Fortunately there already exists a generic RTC class driver: "rtc-parisc". Despite it's name, it's platform-independent, as it's build on top of the RTC abstraction used by "genrtc". This patch series - adds a missing module alias to rtc-parisc, - renames rtc-parisc to rtc-generic, - converts the architectures that currently have CONFIG_GEN_RTC enabled in their defconfig (m68k, parisc, powerpc) to rtc-generic, - removes the obsolete rtc-ppc driver, - removes the old genrtc driver. Note that genrtc may be used on other archictectures as well: at least alpha has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa). Furthermore genrtc and rtc-generic are not 100% userspace compatible: - /dev/rtc provided by genrtc uses a misc character device (10:135), - /dev/rtc provided by rtc-generic uses a dynamic character device. So perhaps we don't want to kill gen-rtc yet? Any comments are welcomed! With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 4/5] powerpc: Enable rtc-generic, and kill rtc-ppc
Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set.
Kill rtc-ppc, as rtc-generic offers the same functionality in a more generic
way.
Signed-off-by: Geert Uytterhoeven
---
arch/powerpc/Kconfig |4 ++
arch/powerpc/kernel/time.c | 22 ++
drivers/rtc/Kconfig|8 -
drivers/rtc/Makefile |1 -
drivers/rtc/rtc-ppc.c | 69
5 files changed, 26 insertions(+), 78 deletions(-)
delete mode 100644 drivers/rtc/rtc-ppc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 40b7981..82e47b0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -85,6 +85,10 @@ config ARCH_HAS_ILOG2_U64
bool
default y if 64BIT
+config ARCH_HAS_GENERIC_RTC
+ bool
+ default y
+
config GENERIC_HWEIGHT
bool
default y
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index c956403..616c7d3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1127,3 +1127,25 @@ void div128_by_32(u64 dividend_high, u64 dividend_low,
dr->result_low = ((u64)y << 32) + z;
}
+
+static struct platform_device rtc_generic_dev = {
+ .name = "rtc-generic",
+ .id = -1,
+};
+
+static int __init rtc_init(void)
+{
+ int ret;
+
+ if (!ppc_md.get_rtc_time)
+ return -ENODEV;
+
+ ret = platform_device_register(&rtc_generic_dev);
+ if (ret < 0)
+ pr_err("Unable to register rtc device...\n");
+
+ /* not necessarily an error */
+ return 0;
+}
+
+module_init(rtc_init);
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 3e58182..9964a72 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -685,14 +685,6 @@ config RTC_DRV_GENERIC
RTC abstraction. If you do not know what you are doing, you should
just say Y.
-config RTC_DRV_PPC
- tristate "PowerPC machine dependent RTC support"
- depends on PPC
- help
-The PowerPC kernel has machine-specific functions for accessing
-the RTC. This exposes that functionality through the generic RTC
-class.
-
config RTC_DRV_PXA
tristate "PXA27x/PXA3xx"
depends on ARCH_PXA
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 9c18a01..bd209a5 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_RTC_DRV_PCF8583) += rtc-pcf8583.o
obj-$(CONFIG_RTC_DRV_PL030)+= rtc-pl030.o
obj-$(CONFIG_RTC_DRV_PL031)+= rtc-pl031.o
obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o
-obj-$(CONFIG_RTC_DRV_PPC) += rtc-ppc.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
diff --git a/drivers/rtc/rtc-ppc.c b/drivers/rtc/rtc-ppc.c
deleted file mode 100644
index c8e97e2..000
--- a/drivers/rtc/rtc-ppc.c
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * RTC driver for ppc_md RTC functions
- *
- * © 2007 Red Hat, Inc.
- *
- * Author: David Woodhouse
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-#include
-#include
-#include
-#include
-#include
-
-static int ppc_rtc_read_time(struct device *dev, struct rtc_time *tm)
-{
- ppc_md.get_rtc_time(tm);
- return 0;
-}
-
-static int ppc_rtc_set_time(struct device *dev, struct rtc_time *tm)
-{
- return ppc_md.set_rtc_time(tm);
-}
-
-static const struct rtc_class_ops ppc_rtc_ops = {
- .set_time = ppc_rtc_set_time,
- .read_time = ppc_rtc_read_time,
-};
-
-static struct rtc_device *rtc;
-static struct platform_device *ppc_rtc_pdev;
-
-static int __init ppc_rtc_init(void)
-{
- if (!ppc_md.get_rtc_time || !ppc_md.set_rtc_time)
- return -ENODEV;
-
- ppc_rtc_pdev = platform_device_register_simple("ppc-rtc", 0, NULL, 0);
- if (IS_ERR(ppc_rtc_pdev))
- return PTR_ERR(ppc_rtc_pdev);
-
- rtc = rtc_device_register("ppc_md", &ppc_rtc_pdev->dev,
- &ppc_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc)) {
- platform_device_unregister(ppc_rtc_pdev);
- return PTR_ERR(rtc);
- }
-
- return 0;
-}
-
-static void __exit ppc_rtc_exit(void)
-{
- rtc_device_unregister(rtc);
- platform_device_unregister(ppc_rtc_pdev);
-}
-
-module_init(ppc_rtc_init);
-module_exit(ppc_rtc_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("David Woodhouse ");
-MODULE_DESCRIPTION("Generic RTC class driver for PowerPC");
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 3/5] m68k: Enable rtc-generic
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/Kconfig |4
arch/m68k/kernel/time.c | 21 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index fb87c08..9d2565e 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -27,6 +27,10 @@ config ARCH_HAS_ILOG2_U64
bool
default n
+config ARCH_HAS_GENERIC_RTC
+ bool
+ default y
+
config GENERIC_HWEIGHT
bool
default y
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 7db4159..b26933f 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -159,3 +160,23 @@ int do_settimeofday(struct timespec *tv)
}
EXPORT_SYMBOL(do_settimeofday);
+
+
+static struct platform_device rtc_generic_dev = {
+ .name = "rtc-generic",
+ .id = -1,
+};
+
+static int __init rtc_init(void)
+{
+ int ret;
+
+ ret = platform_device_register(&rtc_generic_dev);
+ if (ret < 0)
+ pr_err("Unable to register rtc device...\n");
+
+ /* not necessarily an error */
+ return 0;
+}
+
+module_init(rtc_init);
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC 1/5] rtc-parisc: Add missing module alias
Make udev autoload the driver
Signed-off-by: Geert Uytterhoeven
---
drivers/rtc/rtc-parisc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/rtc/rtc-parisc.c b/drivers/rtc/rtc-parisc.c
index c6bfa6f..28fb7d3 100644
--- a/drivers/rtc/rtc-parisc.c
+++ b/drivers/rtc/rtc-parisc.c
@@ -110,3 +110,4 @@ module_exit(parisc_rtc_fini);
MODULE_AUTHOR("Kyle McMartin ");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("HP PA-RISC RTC driver");
+MODULE_ALIAS("platform:rtc-parisc");
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add rtas rtc calls for the QPACE platform
The new firmware release exports further RTC calls. This
patch adds these calls to the QPACE platform setup file.
Signed-off-by: Benjamin Krill
---
arch/powerpc/platforms/cell/qpace_setup.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c
b/arch/powerpc/platforms/cell/qpace_setup.c
index 775cd80..c5ce02e 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -128,6 +128,8 @@ define_machine(qpace) {
.power_off = rtas_power_off,
.halt = rtas_halt,
.get_boot_time = rtas_get_boot_time,
+ .get_rtc_time = rtas_get_rtc_time,
+ .set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = qpace_progress,
.init_IRQ = iic_init_IRQ,
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
Hello,
My board has a Davicom DM9000A ethernet controller on the MPC5200B's
Local Plus bus.
With the following setup and code the controller *works fine* with the
MPC5200B, but I think the code + setup to make it happen could be a
lot cleaner.
The DM9000A is setup for 16 bit mode, and wired as such to the
MPC5200B, A1 is wired to the DM9000 CMD pin.
The DM9000 is accessed trough two registers, address and data register.
The chip-select used is CS1 and it is setup in U-boot as follows:
/* Start addres: FB00
Data Bus Size: 2 bytes
Address Bus Size: 16 bit
Mux off.
*/
#define CFG_CS1_CFG = 0x04041500
The resulting physical DM9000 register map is:
FB00 : address register
FB02 : data register
I have the following definition for this network device in my dts:
enet1:ether...@fb00 {
#size-cells = <1>;
#address-cells = <1>;
device_type = "network";
compatible = "davicom,dm9000";
reg = <0xfb00 0x0002// DM9000 Address
register
0xfb02 0x0002>; // DM9000 Data register
mac-address = [ 00 00 00 00 00 00 ]; // Filled in by u-boot
interrupts = <1 1 0>; // External interrupt 1
interrupt-parent = <&mpc5200_pic>;
};
To pass this information to the unmodified DM9000 driver I put
together a wrapper arch/powerpc/sysdev/dm9000_dev.c (see below) for
the of_ part (I reused most of the work from
arch/powerpc/sysdev/tsi108_dev.c):
Because the dm9000 driver uses the data address both as pointer to u16
and pointer to u8, this works for a little-endian cpu to the
little-endian dm9000, but not for the big endian MPC5200 to little
endian dm9000.
So I add an offset of 1 to this pointer when it is passed to the
dm9000 driver. This offset of 1 is wrong for the u16 accesses of the
DM9000 driver, besides that the data needs to be byteswapped for the
dm9000 driver.
For these two reasons I wrote the functions dm9000_outblk_16bit
dm9000_intblk_16bit dm9000_dumpblk_16bit which are passed via the
platform_data.
Apart from comments on my assumptions I have the following questions
about this situation and my code:
- Is it the right way to make a separate arch/powerpc/sysdev/*_dev.c
for reading the device-tree and passing it to a driver, in stead of
adding it to the driver itself?
- I think the best solution to handle the separate address and data
register is the 2 entry register array in the device tree as above,
this accounts for an odd connection to the DM9000's CMD pin. Agree?
- The MPC5200's chip-select can be configured to do byte-swapping on
read and write, however when I configured it as such and I removed my
offsetting by 1 and byte-swapping code It didn't work.
- Any suggestions to what could be wrong here? Or does the MPC5200 in
this case only byte swap u16 reads, but a u8 read is unchanged?
- What about how the DM9000 driver deals with this u8 read and u16
read, is this correct?
Thanks,
Henk
/*
* dm9000 device setup code
*
* Maintained by Henk Stegeman < henk.stege...@gmail.com >
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef DEBUG
#define DBG(fmt...) do { printk(fmt); } while(0)
#else
#define DBG(fmt...) do { } while(0)
#endif
#define U16_SWAP_BYTES(v) (((v << 8) & 0xff00) | ((v >> 8) & 0x00ff))
static void dm9000_outblk_16bit(void __iomem *reg, void *data, int count)
{
u16 * pU16 = data;
count = ( count + 1 ) >> 1;
while (count > 0) {
/* subtract 1 from reg to get back at the 16bit reg addr */
out_be16(reg - 1, U16_SWAP_BYTES(* pU16));
pU16 ++;
count --;
}
}
static void dm9000_inblk_16bit(void __iomem *reg, void *data, int count)
{
u16 * pU16 = data;
count = ( count + 1 ) >> 1;
while (count > 0) {
/* subtract 1 from reg to get back at the 16bit reg addr */
* pU16 = in_be16(reg - 1);
* pU16 = U16_SWAP_BYTES(* pU16);
pU16 ++;
count --;
}
}
static void dm9000_dumpblk_16bit(void __iomem *reg, int count)
{
volatile u16 tmp;
count = ( count + 1 ) >> 1;
while (count > 0) {
/* subtract 1 from reg to get back at the 16bit reg addr */
tmp = in_be16(reg - 1);
count --;
}
}
#define NUM_DM9000_RESOURCES 3
static int __init dm9000_eth_of_init(void)
{
st
Re: [PATCH] ehea: Fix memory hotplug handling
From: Thomas Klein Date: Thu, 19 Feb 2009 12:32:11 +0100 > Added missing set_bit() to disable data transfer when a memchange > notification is handled > > Signed-off-by: Thomas Klein Applied to net-next-2.6 But this was a real pain because you never tell me what tree your changes are destined for. I assumed since you said "bug fix" you want this in net-2.6, but of course this patch doesn't apply there since the driver version is different in that tree. You can save me all of that trial-and-error wasted time if you simply say "net-next-2.6" or "net-2.6" either in the "[PATCH ...]" part of your subject or in the message body itself. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Enable hashdist by default on PowerPC
From: Anton Blanchard Date: Fri, 20 Feb 2009 16:19:56 +1100 > > Hi David, > > > I should probably do this on sparc64 too. > > > > Why don't we just change this thing to CONFIG_64BIT? > > I agree. How does this look? Hmmm... my bad, I think you need to keep the CONFIG_NUMA there too as there is a TLB usage penalty for non-NUMA systems if you only use CONFIG_64BIT there. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
