Re: arch/mips/alchemy/devboards/db1300.c:(.text.db1300_wm97xx_probe+0x2c): undefined reference to `wm97xx_config_gpio'
Hello all, On Mon, Jul 13, 2020 at 3:29 AM Jiaxun Yang wrote: > > 在 2020/7/12 18:01, kernel test robot 写道: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > head: 0aea6d5c5be33ce94c16f9ab2f64de1f481f424b > > commit: ff487d41036035376e47972c7c522490b839ab37 MIPS: Truncate link > > address into 32bit for 32bit kernel > > date: 9 weeks ago > > config: mips-randconfig-c023-20200712 (attached as .config) > > compiler: mipsel-linux-gcc (GCC) 9.3.0 > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot > > > > All errors (new ones prefixed by >>): > > > > mipsel-linux-ld: arch/mips/alchemy/devboards/db1300.o: in function > > `db1300_wm97xx_probe': > > Well this seems unrelated with my changes. Yes, > Just wonder if alchemy still alive? My test hardware still works > Should I fix it or just drop alchemy support? Something like this should fix it. I never tested randconfig because I find it kind of pointless for these kinds of specialized boards/systems. diff --git a/arch/mips/alchemy/devboards/db1300.c b/arch/mips/alchemy/devboards/db1300.c index 8ac1f56ee57d..9c7736d88bce 100644 --- a/arch/mips/alchemy/devboards/db1300.c +++ b/arch/mips/alchemy/devboards/db1300.c @@ -746,6 +746,7 @@ static struct wm97xx_mach_ops db1300_wm97xx_ops = { static int db1300_wm97xx_probe(struct platform_device *pdev) { +#if IS_ENABLED(CONFIG_TOUCHSCREEN_WM97XX) struct wm97xx *wm = platform_get_drvdata(pdev); /* external pendown indicator */ @@ -761,6 +762,9 @@ static int db1300_wm97xx_probe(struct platform_device *pdev) wm->pen_irq = DB1300_AC97_PEN_INT; return wm97xx_register_mach_ops(wm, _wm97xx_ops); +#else + return -ENODEV; +#endif } Manuel
Re: [PATCH] au1200fb: don't use DMA_ATTR_NON_CONSISTENT
On Tue, Jun 25, 2019 at 2:13 PM Christoph Hellwig wrote: > > au1200fb allocates DMA memory using DMA_ATTR_NON_CONSISTENT, but never > calls dma_cache_sync to synchronize the memory between the CPU and the > device. If it was use on a not cache coherent bus that would be fatal, > but as far as I can tell from the naming and the mips platform > implementation it always is used in cache coherent systems. Remove > the DMA_ATTR_NON_CONSISTENT flag, which is a no-op in that case. Very early au1200 chips, on which this driver apparently was developed on, had issues with cache coherency, but this was fixed in a later step, none of the 3 steppings I have access to exhibit any problems with this patch applied. > Signed-off-by: Christoph Hellwig Acked-By: Manuel Lauss
Re: [PATCH 2/3] au1200fb: fix DMA API abuse
Servus Christoph, On Thu, May 9, 2019 at 7:39 PM Christoph Hellwig wrote: > Virtual addresses return from dma(m)_alloc_attrs are opaque in what > backs then, and drivers must not poke into them. Similarly caching > modes are not supposed to be directly set by the driver. Switch the > driver to use the generic DMA API mmap helper to avoid these problems. > > Signed-off-by: Christoph Hellwig > --- > drivers/video/fbdev/au1200fb.c | 19 --- > 1 file changed, 4 insertions(+), 15 deletions(-) Runs fine on my test system. Tested-by: Manuel Lauss
Re: MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Thu, May 25, 2017 at 8:54 AM, SF Markus Elfringwrote: >>> How do you think about to achieve a small code reduction also for this >>> software module? >> >> Generally speaking, sure. > > Thanks for your interest in such a direction. > > >> But why remove just this one? Is it because it loosely follows a >> pattern that was deemed removable in that slidedeck you linked to? > > I derived another source code search approach from the implementation > of the check “OOM_MESSAGE” in the script “checkpatch.pl” for > the semantic patch language (Coccinelle software). > The involved search patterns are still evolving and the used lists > (or regular expressions) for function names where it might make sense > to reconsider the usage of special logging calls is therefore incomplete. > > >> (the "usb_submit_urb()" part)? > > Would you like to extend the function selection for further considerations? > > >>> Do you find information from a Linux allocation failure report sufficient >>> for such a function implementation? >> >> Yes, I wrote that code, and in case this driver doesn't load, I'd like >> to know precisely where initialization failed. >> I can happily spare a few bytes for that. > > Does this kind of answer contain a bit of contradiction? > > * Why do you seem to insist on another message if information from a Linux > allocation failure report would be sufficient already also for this > software module? > > * Do you want that it can become easier to map a position in a backtrace > to a place in your source code? Does kmalloc() nowadays print a message which invocation (source line) failed? If so I won't be standing in your way, but if not, you need to come up with something for convincing than answering questions with more questions. Manuel
Re: MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Thu, May 25, 2017 at 8:54 AM, SF Markus Elfring wrote: >>> How do you think about to achieve a small code reduction also for this >>> software module? >> >> Generally speaking, sure. > > Thanks for your interest in such a direction. > > >> But why remove just this one? Is it because it loosely follows a >> pattern that was deemed removable in that slidedeck you linked to? > > I derived another source code search approach from the implementation > of the check “OOM_MESSAGE” in the script “checkpatch.pl” for > the semantic patch language (Coccinelle software). > The involved search patterns are still evolving and the used lists > (or regular expressions) for function names where it might make sense > to reconsider the usage of special logging calls is therefore incomplete. > > >> (the "usb_submit_urb()" part)? > > Would you like to extend the function selection for further considerations? > > >>> Do you find information from a Linux allocation failure report sufficient >>> for such a function implementation? >> >> Yes, I wrote that code, and in case this driver doesn't load, I'd like >> to know precisely where initialization failed. >> I can happily spare a few bytes for that. > > Does this kind of answer contain a bit of contradiction? > > * Why do you seem to insist on another message if information from a Linux > allocation failure report would be sufficient already also for this > software module? > > * Do you want that it can become easier to map a position in a backtrace > to a place in your source code? Does kmalloc() nowadays print a message which invocation (source line) failed? If so I won't be standing in your way, but if not, you need to come up with something for convincing than answering questions with more questions. Manuel
Re: [PATCH] MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Wed, May 24, 2017 at 8:15 PM, SF Markus Elfringwrote: >>> +++ b/arch/mips/pci/pci-alchemy.c >>> @@ -377,7 +377,6 @@ static int alchemy_pci_probe(struct platform_device >>> *pdev) >>> >>> ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); >>> if (!ctx) { >>> - dev_err(>dev, "no memory for pcictl context\n"); >>> ret = -ENOMEM; >>> goto out; >>> } >>> -- >>> 2.13.0 >> >> Why are you removing just this one dev_err()? > > How do you think about to achieve a small code reduction also for this > software module? Generally speaking, sure. But why remove just this one? Is it because it loosely follows a pattern that was deemed removable in that slidedeck you linked to? (the "usb_submit_urb()" part)? >> What issue are you trying to address? > > Do you find information from a Linux allocation failure report sufficient > for such a function implementation? Yes, I wrote that code, and in case this driver doesn't load, I'd like to know precisely where initialization failed. I can happily spare a few bytes for that. Manuel
Re: [PATCH] MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Wed, May 24, 2017 at 8:15 PM, SF Markus Elfring wrote: >>> +++ b/arch/mips/pci/pci-alchemy.c >>> @@ -377,7 +377,6 @@ static int alchemy_pci_probe(struct platform_device >>> *pdev) >>> >>> ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); >>> if (!ctx) { >>> - dev_err(>dev, "no memory for pcictl context\n"); >>> ret = -ENOMEM; >>> goto out; >>> } >>> -- >>> 2.13.0 >> >> Why are you removing just this one dev_err()? > > How do you think about to achieve a small code reduction also for this > software module? Generally speaking, sure. But why remove just this one? Is it because it loosely follows a pattern that was deemed removable in that slidedeck you linked to? (the "usb_submit_urb()" part)? >> What issue are you trying to address? > > Do you find information from a Linux allocation failure report sufficient > for such a function implementation? Yes, I wrote that code, and in case this driver doesn't load, I'd like to know precisely where initialization failed. I can happily spare a few bytes for that. Manuel
Re: [PATCH] MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Wed, May 24, 2017 at 6:42 PM, SF Markus Elfringwrote: > From: Markus Elfring > Date: Wed, 24 May 2017 18:32:21 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Link: > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf > Signed-off-by: Markus Elfring > --- > arch/mips/pci/pci-alchemy.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/mips/pci/pci-alchemy.c b/arch/mips/pci/pci-alchemy.c > index e99ca7702d8a..a58c3290bd4e 100644 > --- a/arch/mips/pci/pci-alchemy.c > +++ b/arch/mips/pci/pci-alchemy.c > @@ -377,7 +377,6 @@ static int alchemy_pci_probe(struct platform_device *pdev) > > ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); > if (!ctx) { > - dev_err(>dev, "no memory for pcictl context\n"); > ret = -ENOMEM; > goto out; > } > -- > 2.13.0 Why are you removing just this one dev_err()? What issue are you trying to address? Manuel
Re: [PATCH] MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()
On Wed, May 24, 2017 at 6:42 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 24 May 2017 18:32:21 +0200 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Link: > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf > Signed-off-by: Markus Elfring > --- > arch/mips/pci/pci-alchemy.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/mips/pci/pci-alchemy.c b/arch/mips/pci/pci-alchemy.c > index e99ca7702d8a..a58c3290bd4e 100644 > --- a/arch/mips/pci/pci-alchemy.c > +++ b/arch/mips/pci/pci-alchemy.c > @@ -377,7 +377,6 @@ static int alchemy_pci_probe(struct platform_device *pdev) > > ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); > if (!ctx) { > - dev_err(>dev, "no memory for pcictl context\n"); > ret = -ENOMEM; > goto out; > } > -- > 2.13.0 Why are you removing just this one dev_err()? What issue are you trying to address? Manuel
Re: [PATCH v2 07/13] MIPS: mm: Fix MIPS32 36b physical addressing (alchemy, netlogic)
On Mon, Apr 18, 2016 at 11:35 AM, Paul Burtonwrote: > There are 2 distinct cases in which a kernel for a MIPS32 CPU > (CONFIG_CPU_MIPS32=y) may use 64 bit physical addresses > (CONFIG_PHYS_ADDR_T_64BIT=y): > > - 36 bit physical addressing as used by RMI Alchemy & Netlogic XLP/XLR > CPUs. > > - MIPS32r5 eXtended Physical Addressing (XPA). This hunk here gives me a build failure on Alchemy: /home/mano/dev/db1200/kernel/linux/arch/mips/mm/init.c: In function '__kmap_pgprot': /home/mano/dev/db1200/kernel/linux/arch/mips/mm/init.c:116:28: error: '_PFNX_MASK' undeclared (first use in this function) entrylo = (pte.pte_low & _PFNX_MASK); > diff --git a/arch/mips/include/asm/pgtable-bits.h > b/arch/mips/include/asm/pgtable-bits.h > index 5bc663d..58e8bf8 100644 > --- a/arch/mips/include/asm/pgtable-bits.h > +++ b/arch/mips/include/asm/pgtable-bits.h > @@ -32,11 +32,11 @@ > * unpredictable things. The code (when it is written) to deal with > * this problem will be in the update_mmu_cache() code for the r4k. > */ > -#if defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32) > +#if defined(CONFIG_XPA) > > /* > - * Page table bit offsets used for 64 bit physical addressing on MIPS32, > - * for example with Alchemy, Netlogic XLP/XLR or XPA. > + * Page table bit offsets used for 64 bit physical addressing on > + * MIPS32r5 with XPA. > */ > enum pgtable_bits { > /* Used by TLB hardware (placed in EntryLo*) */ > @@ -59,6 +59,27 @@ enum pgtable_bits { > */ > #define _PFNX_MASK 0xff > > +#elif defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32) > + > +/* > + * Page table bit offsets used for 36 bit physical addressing on MIPS32, > + * for example with Alchemy or Netlogic XLP/XLR. > + */ > +enum pgtable_bits { > + /* Used by TLB hardware (placed in EntryLo*) */ > + _PAGE_GLOBAL_SHIFT, > + _PAGE_VALID_SHIFT, > + _PAGE_DIRTY_SHIFT, > + _CACHE_SHIFT, > + > + /* Used only by software (masked out before writing EntryLo*) */ > + _PAGE_PRESENT_SHIFT = _CACHE_SHIFT + 3, > + _PAGE_NO_READ_SHIFT, > + _PAGE_WRITE_SHIFT, > + _PAGE_ACCESSED_SHIFT, > + _PAGE_MODIFIED_SHIFT, > +}; > + forgot _PFNX_MASK here? Manuel
Re: [PATCH v2 07/13] MIPS: mm: Fix MIPS32 36b physical addressing (alchemy, netlogic)
On Mon, Apr 18, 2016 at 11:35 AM, Paul Burton wrote: > There are 2 distinct cases in which a kernel for a MIPS32 CPU > (CONFIG_CPU_MIPS32=y) may use 64 bit physical addresses > (CONFIG_PHYS_ADDR_T_64BIT=y): > > - 36 bit physical addressing as used by RMI Alchemy & Netlogic XLP/XLR > CPUs. > > - MIPS32r5 eXtended Physical Addressing (XPA). This hunk here gives me a build failure on Alchemy: /home/mano/dev/db1200/kernel/linux/arch/mips/mm/init.c: In function '__kmap_pgprot': /home/mano/dev/db1200/kernel/linux/arch/mips/mm/init.c:116:28: error: '_PFNX_MASK' undeclared (first use in this function) entrylo = (pte.pte_low & _PFNX_MASK); > diff --git a/arch/mips/include/asm/pgtable-bits.h > b/arch/mips/include/asm/pgtable-bits.h > index 5bc663d..58e8bf8 100644 > --- a/arch/mips/include/asm/pgtable-bits.h > +++ b/arch/mips/include/asm/pgtable-bits.h > @@ -32,11 +32,11 @@ > * unpredictable things. The code (when it is written) to deal with > * this problem will be in the update_mmu_cache() code for the r4k. > */ > -#if defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32) > +#if defined(CONFIG_XPA) > > /* > - * Page table bit offsets used for 64 bit physical addressing on MIPS32, > - * for example with Alchemy, Netlogic XLP/XLR or XPA. > + * Page table bit offsets used for 64 bit physical addressing on > + * MIPS32r5 with XPA. > */ > enum pgtable_bits { > /* Used by TLB hardware (placed in EntryLo*) */ > @@ -59,6 +59,27 @@ enum pgtable_bits { > */ > #define _PFNX_MASK 0xff > > +#elif defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32) > + > +/* > + * Page table bit offsets used for 36 bit physical addressing on MIPS32, > + * for example with Alchemy or Netlogic XLP/XLR. > + */ > +enum pgtable_bits { > + /* Used by TLB hardware (placed in EntryLo*) */ > + _PAGE_GLOBAL_SHIFT, > + _PAGE_VALID_SHIFT, > + _PAGE_DIRTY_SHIFT, > + _CACHE_SHIFT, > + > + /* Used only by software (masked out before writing EntryLo*) */ > + _PAGE_PRESENT_SHIFT = _CACHE_SHIFT + 3, > + _PAGE_NO_READ_SHIFT, > + _PAGE_WRITE_SHIFT, > + _PAGE_ACCESSED_SHIFT, > + _PAGE_MODIFIED_SHIFT, > +}; > + forgot _PFNX_MASK here? Manuel
Re: [PATCH] pcmcia: db1xxx: use correct irq_to_gpio helper
Hi Arnd, On Tue, Mar 1, 2016 at 11:12 PM, Arnd Bergmannwrote: > After the removal of asm/gpio.h and asm/mach-au1x00/gpio.h, the db1xxx_ss > pcmcia driver picked up the wrong irq_to_gpio function from the generic > headers. > > This restores the old __au_irq_to_gpio() implementation, but keeps > it local to the only file that uses it. > > It would be nicer to just pass the gpio number from platform code, > but restoring the previous implementation seems safer. Give me a few hours and I'll fix this driver for good. > Signed-off-by: Arnd Bergmann > Cc: sta...@vger.kernel.org # v4.3 > Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") > --- > I think this is now the last holdout of the irq_to_gpio function, > and it's been broken for a while. Maybe Ralf can queue it up through > the MIPS tree along with the other fix for irq_to_gpio? It's not broken though.. this driver on current linus-git works fine! Thank you, Manuel
Re: [PATCH] pcmcia: db1xxx: use correct irq_to_gpio helper
Hi Arnd, On Tue, Mar 1, 2016 at 11:12 PM, Arnd Bergmann wrote: > After the removal of asm/gpio.h and asm/mach-au1x00/gpio.h, the db1xxx_ss > pcmcia driver picked up the wrong irq_to_gpio function from the generic > headers. > > This restores the old __au_irq_to_gpio() implementation, but keeps > it local to the only file that uses it. > > It would be nicer to just pass the gpio number from platform code, > but restoring the previous implementation seems safer. Give me a few hours and I'll fix this driver for good. > Signed-off-by: Arnd Bergmann > Cc: sta...@vger.kernel.org # v4.3 > Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") > --- > I think this is now the last holdout of the irq_to_gpio function, > and it's been broken for a while. Maybe Ralf can queue it up through > the MIPS tree along with the other fix for irq_to_gpio? It's not broken though.. this driver on current linus-git works fine! Thank you, Manuel
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbottwrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? Can you test this? I think the old HPCP bit should just be ignored, although windows does use it, i.e. when I enable hotplug capability in the bios on my desktop it shows the "eject device" icon for a device attached to the port on the motherboard, we probably can ignore it on linux to not break all automounting distros. On my laptop, where I care about this, it still works as intended. diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index 4029679..e029e3c 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -1164,8 +1164,7 @@ static void ahci_port_init(struct device *dev, struct ata_port *ap, /* mark esata ports */ tmp = readl(port_mmio + PORT_CMD); - if ((tmp & PORT_CMD_HPCP) || - ((tmp & PORT_CMD_ESP) && (hpriv->cap & HOST_CAP_SXS))) + if ((tmp & PORT_CMD_ESP) && (hpriv->cap & HOST_CAP_SXS)) ap->pflags |= ATA_PFLAG_EXTERNAL; }
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbott wrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? Can you test this? I think the old HPCP bit should just be ignored, although windows does use it, i.e. when I enable hotplug capability in the bios on my desktop it shows the "eject device" icon for a device attached to the port on the motherboard, we probably can ignore it on linux to not break all automounting distros. On my laptop, where I care about this, it still works as intended. diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index 4029679..e029e3c 100644 --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -1164,8 +1164,7 @@ static void ahci_port_init(struct device *dev, struct ata_port *ap, /* mark esata ports */ tmp = readl(port_mmio + PORT_CMD); - if ((tmp & PORT_CMD_HPCP) || - ((tmp & PORT_CMD_ESP) && (hpriv->cap & HOST_CAP_SXS))) + if ((tmp & PORT_CMD_ESP) && (hpriv->cap & HOST_CAP_SXS)) ap->pflags |= ATA_PFLAG_EXTERNAL; }
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbottwrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? Do the affected users have sata ports set to hotplug capable? Because that's what the patch does: it flags ports which have the hotplug capability enabled as "removable", and I guess redhat just automounts anything that is flagged as a removable disk (like an usb drive). Manuel
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbott wrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? Do the affected users have sata ports set to hotplug capable? Because that's what the patch does: it flags ports which have the hotplug capability enabled as "removable", and I guess redhat just automounts anything that is flagged as a removable disk (like an usb drive). Manuel
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbottwrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? This patch doesn't cause esata disks to be automounted on my distro (gentoo), it just let's them appear in KDE's removable device widget for me to mount it at a klick's notice. I'm not convinced this is a "breaking userspace" problem. Manuel
Re: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior
On Thu, Feb 25, 2016 at 6:12 PM, Laura Abbott wrote: > Hi, > > We received a bugzilla report > https://bugzilla.redhat.com/show_bug.cgi?id=1310682 > of partitions being automounted unexpectedly. Testing showed that > 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable") was > responsible. > This seems to be classified as 'breaking' userspace given that this behavior > results > in partitions that were previously unmounted now being being mounted > unwanted > automatically which is unwanted behavior for the user. Can we revert this > patch or > give a fix to change this behavior? This patch doesn't cause esata disks to be automounted on my distro (gentoo), it just let's them appear in KDE's removable device widget for me to mount it at a klick's notice. I'm not convinced this is a "breaking userspace" problem. Manuel
Re: [PATCH] MIPS: Remove all the uses of custom gpio.h
On Thu, Jul 30, 2015 at 7:28 PM, Alban Bedel wrote: > Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS > machines, and each machine type provides its own gpio.h. However > only a handful really implement the GPIO API, most just forward > everythings to gpiolib. > > The Alchemy machine is notable as it provides a system to allow > implementing the GPIO API at the board level. But it is not used by > any board currently supported, so it can also be removed. Threre's only out-of-tree users which I also maintain, so it's fine with me. > arch/mips/alchemy/Kconfig | 7 -- > arch/mips/alchemy/board-gpr.c | 1 + > arch/mips/alchemy/board-mtx1.c | 1 + > arch/mips/alchemy/common/Makefile | 7 +- > arch/mips/alchemy/devboards/db1000.c| 1 + > arch/mips/alchemy/devboards/db1300.c| 1 + > arch/mips/alchemy/devboards/db1550.c| 1 + > arch/mips/alchemy/devboards/pm.c| 2 +- > arch/mips/include/asm/mach-au1x00/gpio-au1000.h | 148 > ++-- > arch/mips/include/asm/mach-au1x00/gpio.h | 86 -- For the alchemy parts: Acked-by: Manuel Lauss -- Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Remove all the uses of custom gpio.h
On Thu, Jul 30, 2015 at 7:28 PM, Alban Bedel al...@free.fr wrote: Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS machines, and each machine type provides its own gpio.h. However only a handful really implement the GPIO API, most just forward everythings to gpiolib. The Alchemy machine is notable as it provides a system to allow implementing the GPIO API at the board level. But it is not used by any board currently supported, so it can also be removed. Threre's only out-of-tree users which I also maintain, so it's fine with me. arch/mips/alchemy/Kconfig | 7 -- arch/mips/alchemy/board-gpr.c | 1 + arch/mips/alchemy/board-mtx1.c | 1 + arch/mips/alchemy/common/Makefile | 7 +- arch/mips/alchemy/devboards/db1000.c| 1 + arch/mips/alchemy/devboards/db1300.c| 1 + arch/mips/alchemy/devboards/db1550.c| 1 + arch/mips/alchemy/devboards/pm.c| 2 +- arch/mips/include/asm/mach-au1x00/gpio-au1000.h | 148 ++-- arch/mips/include/asm/mach-au1x00/gpio.h| 86 -- For the alchemy parts: Acked-by: Manuel Lauss manuel.la...@gmail.com -- Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Remove most of the custom gpio.h
On Wed, Jul 22, 2015 at 7:33 PM, Alban Bedel wrote: > Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS > machines, and each machine type provides its own gpio.h. However only > the Alchemy machine really use the feature, all other machines only > use the default wrappers. > > For most machine types we can just remove the custom gpio.h, as well > as the custom wrappers if some exists. A few more fixes are need in > a few drivers as they rely on linux/gpio.h to provides some machine > specific definitions, or used asm/gpio.h instead of linux/gpio.h for > the gpio API. > > Signed-off-by: Alban Bedel > --- > > This patch is based on my previous serie: > "MIPS: ath79: Move the GPIO driver to drivers/gpio". > > For testing I tried to build all mips defconfig, however my toolchain > couldn't handle a few configs: ip28 malta_qemu_32r6 maltasmvp_eva > sead3micro. If somebody can test these that would be more than welcome. > > It might well be that some more drivers for MIPS devices that are not > enabled in the defconfig will break because of this change, so more > testing would be nice :) > > Regarding Alchemy I'm not sure what to do. It use a little more > complex setup, quoting arch/mips/include/asm/mach-au1x00/gpio.h: > > /* Linux gpio framework integration. > * > * 4 use cases of Alchemy GPIOS: > *(1) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=y: > * Board must register gpiochips. > *(2) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=n: > * A gpiochip for the 75 GPIOs is registered. > * > *(3) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=y: > * the boards' gpio.h must provide the linux gpio wrapper > functions, > * > *(4) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=n: > * inlinable gpio functions are provided which enable access to the > * Au1300 gpios only by using the numbers straight out of the data- > * sheets. > > * Cases 1 and 3 are intended for boards which want to provide their own > * GPIO namespace and -operations (i.e. for example you have 8 GPIOs > * which are in part provided by spare Au1300 GPIO pins and in part by > * an external FPGA but you still want them to be accssible in linux > * as gpio0-7. The board can of course use the alchemy_gpioX_* functions > * as required). > */ > > This sound to me like this is really not needed anymore. Is there any > users of this left, or can it just go? There are no in-tree users of this, but a few out-of-tree ones (all made by me) Does it have to be removed? Is it blocking anything? Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Remove most of the custom gpio.h
On Wed, Jul 22, 2015 at 7:33 PM, Alban Bedel al...@free.fr wrote: Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS machines, and each machine type provides its own gpio.h. However only the Alchemy machine really use the feature, all other machines only use the default wrappers. For most machine types we can just remove the custom gpio.h, as well as the custom wrappers if some exists. A few more fixes are need in a few drivers as they rely on linux/gpio.h to provides some machine specific definitions, or used asm/gpio.h instead of linux/gpio.h for the gpio API. Signed-off-by: Alban Bedel al...@free.fr --- This patch is based on my previous serie: MIPS: ath79: Move the GPIO driver to drivers/gpio. For testing I tried to build all mips defconfig, however my toolchain couldn't handle a few configs: ip28 malta_qemu_32r6 maltasmvp_eva sead3micro. If somebody can test these that would be more than welcome. It might well be that some more drivers for MIPS devices that are not enabled in the defconfig will break because of this change, so more testing would be nice :) Regarding Alchemy I'm not sure what to do. It use a little more complex setup, quoting arch/mips/include/asm/mach-au1x00/gpio.h: /* Linux gpio framework integration. * * 4 use cases of Alchemy GPIOS: *(1) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=y: * Board must register gpiochips. *(2) GPIOLIB=y, ALCHEMY_GPIO_INDIRECT=n: * A gpiochip for the 75 GPIOs is registered. * *(3) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=y: * the boards' gpio.h must provide the linux gpio wrapper functions, * *(4) GPIOLIB=n, ALCHEMY_GPIO_INDIRECT=n: * inlinable gpio functions are provided which enable access to the * Au1300 gpios only by using the numbers straight out of the data- * sheets. * Cases 1 and 3 are intended for boards which want to provide their own * GPIO namespace and -operations (i.e. for example you have 8 GPIOs * which are in part provided by spare Au1300 GPIO pins and in part by * an external FPGA but you still want them to be accssible in linux * as gpio0-7. The board can of course use the alchemy_gpioX_* functions * as required). */ This sound to me like this is really not needed anymore. Is there any users of this left, or can it just go? There are no in-tree users of this, but a few out-of-tree ones (all made by me) Does it have to be removed? Is it blocking anything? Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable
On Tue, Jul 14, 2015 at 10:16 AM, Thomas Gleixner wrote: > On Tue, 14 Jul 2015, Manuel Lauss wrote: > >> On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner wrote: >> > bcsr_csc_handler() is a cascading interrupt handler. It has a >> > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() >> > call. The value of this disable/enable is zero because its a complete >> > noop: >> > >> > disable_irq_nosync() merily increments the disable count without >> > actually masking the interrupt. enable_irq() soleley decrements the >> > disable count without touching the interrupt chip. The interrupt >> > cannot arrive again because the complete call chain runs with >> > interrupts disabled. >> > >> > Remove it. >> >> Is there another patch this one depends on? The DB1300 board doesn't > > No. > >> boot (i.e. interrupts from the cpld aren't serviced) with this patch applied: >> (irq 136 is the first serviced by the bcsr cpld): >> >> irq 136: nobody cared (try booting with the "irqpoll" option) > > That's weird. Looking deeper, enable_irq() actually calls > chip->unmask() unconditionally. So it seems the chip is sensitive to > that. > > Does the following patch on top fix things again? > > Thanks, > > tglx > > diff --git a/arch/mips/alchemy/devboards/bcsr.c > b/arch/mips/alchemy/devboards/bcsr.c > index 3a24f2d6ecfd..ec47abe580c6 100644 > --- a/arch/mips/alchemy/devboards/bcsr.c > +++ b/arch/mips/alchemy/devboards/bcsr.c > @@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod); > static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d) > { > unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT); > + struct irq_chip *chip = irq_desc_get_chip(d); > > + chained_irq_enter(chip, d); > generic_handle_irq(bcsr_csc_base + __ffs(bisr)); > + chained_irq_exit(chip, d); > } > > static void bcsr_irq_mask(struct irq_data *d) Yes. Add #include on top and it works again. This hardware is problematic, an older variant with identical verilog code in the cpld's irq unit works fine without this. Thanks, Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable
On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner wrote: > bcsr_csc_handler() is a cascading interrupt handler. It has a > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() > call. The value of this disable/enable is zero because its a complete > noop: > > disable_irq_nosync() merily increments the disable count without > actually masking the interrupt. enable_irq() soleley decrements the > disable count without touching the interrupt chip. The interrupt > cannot arrive again because the complete call chain runs with > interrupts disabled. > > Remove it. Is there another patch this one depends on? The DB1300 board doesn't boot (i.e. interrupts from the cpld aren't serviced) with this patch applied: (irq 136 is the first serviced by the bcsr cpld): irq 136: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 50 Comm: kworker/u2:2 Not tainted 4.1.0-db1xxx-12807-g1ced2d0-dirty #8 Workqueue: events_unbound async_run_entry_fn Stack : 8090c3ec 8090c3c4 809d 80153668 80908814 0032 80a03828 8090c3c4 8093b2fc 8fb736e4 80908814 807e7f3c 8013f8dc 8fb736e4 8fb73704 80908814 8013726c 0002 6e657665 755f7374 756f626e 646e 8fc32500 8fc32c00 ... Call Trace: [<8010ee6c>] show_stack+0x64/0x7c [<801571c4>] __report_bad_irq.isra.0+0x40/0x100 [<801574d8>] note_interrupt+0x1e0/0x338 [<80154d3c>] handle_irq_event_percpu+0xe8/0x1a0 [<80154e34>] handle_irq_event+0x40/0x6c [<80157c8c>] handle_level_irq+0xac/0x16c [<801543e8>] generic_handle_irq+0x44/0x5c [<801543e8>] generic_handle_irq+0x44/0x5c [<801543e8>] generic_handle_irq+0x44/0x5c [<8010bd04>] do_IRQ+0x18/0x24 [<8010a018>] ret_from_irq+0x0/0x4 [<801d95fc>] kmem_cache_alloc+0x0/0xf8 [<80216b38>] alloc_buffer_head+0x1c/0x70 [<80216cb0>] alloc_page_buffers+0xbc/0x134 [<80216d4c>] create_empty_buffers+0x24/0x14c [<80216ee0>] create_page_buffers+0x6c/0x94 [<8021896c>] block_read_full_page+0x48/0x4b8 [<8019dac8>] do_read_cache_page+0xac/0x278 [<8019dcb4>] read_cache_page+0x20/0x2c [<803da774>] read_dev_sector+0x34/0xc0 [<803dc7ec>] read_lba.isra.0+0xe8/0x200 [<803dcb80>] is_gpt_valid+0x27c/0x318 [<803dcd40>] efi_partition+0x124/0xb44 [<803db9b4>] check_partition+0x108/0x254 [<803dae84>] rescan_partitions+0x104/0x384 [<8021cc8c>] __blkdev_get+0x318/0x440 [<8021d8d0>] blkdev_get+0x11c/0x330 [<803d8c08>] add_disk+0x380/0x488 [<8048e350>] sd_probe_async+0x100/0x228 [<8013d7ec>] async_run_entry_fn+0x4c/0x118 [<80135080>] process_one_work+0x130/0x40c [<801354c8>] worker_thread+0x16c/0x5a8 [<8013af04>] kthread+0xd4/0xec [<8010a068>] ret_from_kernel_thread+0x14/0x1c handlers: [<804ab75c>] ata_sff_interrupt Disabling IRQ #136 Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable
On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner t...@linutronix.de wrote: bcsr_csc_handler() is a cascading interrupt handler. It has a disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() call. The value of this disable/enable is zero because its a complete noop: disable_irq_nosync() merily increments the disable count without actually masking the interrupt. enable_irq() soleley decrements the disable count without touching the interrupt chip. The interrupt cannot arrive again because the complete call chain runs with interrupts disabled. Remove it. Is there another patch this one depends on? The DB1300 board doesn't boot (i.e. interrupts from the cpld aren't serviced) with this patch applied: (irq 136 is the first serviced by the bcsr cpld): irq 136: nobody cared (try booting with the irqpoll option) CPU: 0 PID: 50 Comm: kworker/u2:2 Not tainted 4.1.0-db1xxx-12807-g1ced2d0-dirty #8 Workqueue: events_unbound async_run_entry_fn Stack : 8090c3ec 8090c3c4 809d 80153668 80908814 0032 80a03828 8090c3c4 8093b2fc 8fb736e4 80908814 807e7f3c 8013f8dc 8fb736e4 8fb73704 80908814 8013726c 0002 6e657665 755f7374 756f626e 646e 8fc32500 8fc32c00 ... Call Trace: [8010ee6c] show_stack+0x64/0x7c [801571c4] __report_bad_irq.isra.0+0x40/0x100 [801574d8] note_interrupt+0x1e0/0x338 [80154d3c] handle_irq_event_percpu+0xe8/0x1a0 [80154e34] handle_irq_event+0x40/0x6c [80157c8c] handle_level_irq+0xac/0x16c [801543e8] generic_handle_irq+0x44/0x5c [801543e8] generic_handle_irq+0x44/0x5c [801543e8] generic_handle_irq+0x44/0x5c [8010bd04] do_IRQ+0x18/0x24 [8010a018] ret_from_irq+0x0/0x4 [801d95fc] kmem_cache_alloc+0x0/0xf8 [80216b38] alloc_buffer_head+0x1c/0x70 [80216cb0] alloc_page_buffers+0xbc/0x134 [80216d4c] create_empty_buffers+0x24/0x14c [80216ee0] create_page_buffers+0x6c/0x94 [8021896c] block_read_full_page+0x48/0x4b8 [8019dac8] do_read_cache_page+0xac/0x278 [8019dcb4] read_cache_page+0x20/0x2c [803da774] read_dev_sector+0x34/0xc0 [803dc7ec] read_lba.isra.0+0xe8/0x200 [803dcb80] is_gpt_valid+0x27c/0x318 [803dcd40] efi_partition+0x124/0xb44 [803db9b4] check_partition+0x108/0x254 [803dae84] rescan_partitions+0x104/0x384 [8021cc8c] __blkdev_get+0x318/0x440 [8021d8d0] blkdev_get+0x11c/0x330 [803d8c08] add_disk+0x380/0x488 [8048e350] sd_probe_async+0x100/0x228 [8013d7ec] async_run_entry_fn+0x4c/0x118 [80135080] process_one_work+0x130/0x40c [801354c8] worker_thread+0x16c/0x5a8 [8013af04] kthread+0xd4/0xec [8010a068] ret_from_kernel_thread+0x14/0x1c handlers: [804ab75c] ata_sff_interrupt Disabling IRQ #136 Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable
On Tue, Jul 14, 2015 at 10:16 AM, Thomas Gleixner t...@linutronix.de wrote: On Tue, 14 Jul 2015, Manuel Lauss wrote: On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner t...@linutronix.de wrote: bcsr_csc_handler() is a cascading interrupt handler. It has a disable_irq_nosync()/enable_irq() pair around the generic_handle_irq() call. The value of this disable/enable is zero because its a complete noop: disable_irq_nosync() merily increments the disable count without actually masking the interrupt. enable_irq() soleley decrements the disable count without touching the interrupt chip. The interrupt cannot arrive again because the complete call chain runs with interrupts disabled. Remove it. Is there another patch this one depends on? The DB1300 board doesn't No. boot (i.e. interrupts from the cpld aren't serviced) with this patch applied: (irq 136 is the first serviced by the bcsr cpld): irq 136: nobody cared (try booting with the irqpoll option) That's weird. Looking deeper, enable_irq() actually calls chip-unmask() unconditionally. So it seems the chip is sensitive to that. Does the following patch on top fix things again? Thanks, tglx diff --git a/arch/mips/alchemy/devboards/bcsr.c b/arch/mips/alchemy/devboards/bcsr.c index 3a24f2d6ecfd..ec47abe580c6 100644 --- a/arch/mips/alchemy/devboards/bcsr.c +++ b/arch/mips/alchemy/devboards/bcsr.c @@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod); static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d) { unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT); + struct irq_chip *chip = irq_desc_get_chip(d); + chained_irq_enter(chip, d); generic_handle_irq(bcsr_csc_base + __ffs(bisr)); + chained_irq_exit(chip, d); } static void bcsr_irq_mask(struct irq_data *d) Yes. Add #include linux/irqchip/chained_irq.h on top and it works again. This hardware is problematic, an older variant with identical verilog code in the cpld's irq unit works fine without this. Thanks, Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: wm8731: let codec to manage clock by itself
On Mon, Feb 16, 2015 at 11:31 AM, Charles Keepax wrote: > On Thu, Feb 12, 2015 at 04:23:06PM +0800, Bo Shen wrote: >> Hi All, >> >> On 02/05/2015 03:35 PM, Bo Shen wrote: >>> Let the wm8731 codec to manage clock by itself. >>> >>> Signed-off-by: Bo Shen >>> --- >>> >>> sound/soc/codecs/wm8731.c | 28 >>> 1 file changed, 28 insertions(+) >> >> Any comments for this patch (aka ping?) > > I preferred the idea of having the clock as optional and from the > discussion on the last patch it didn't look too tricky to me too > achieve. OTOH I think the Atmel system is the only one that uses > both this CODEC and common clock so it doesn't look like this > would cause any problems, but might be nice for this not to be > one more thing for someone to fix up when moving a system to > common clock. Not quite, there's one MIPS platform I maintain which needs a patch like the one below (tested): diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c index 8c13675..aa01ab2 100644 --- a/arch/mips/alchemy/devboards/db1200.c +++ b/arch/mips/alchemy/devboards/db1200.c @@ -19,6 +19,8 @@ */ #include +#include +#include #include #include #include @@ -862,6 +864,12 @@ int __init db1200_dev_setup(void) irq_set_status_flags(DB1200_PC1_INSERT_INT, IRQ_NOAUTOEN); irq_set_status_flags(DB1200_PC1_EJECT_INT, IRQ_NOAUTOEN); +/* register the 12MHz crystal for the WM8731 I2S codec */ +c = clk_register_fixed_rate(NULL, "wm8731xtal", NULL, +CLK_IS_ROOT, 1200); +if (!IS_ERR(c)) +clk_register_clkdev(c, "mclk", "0-001b"); + i2c_register_board_info(0, db1200_i2c_devs, ARRAY_SIZE(db1200_i2c_devs)); spi_register_board_info(db1200_spi_devs, diff --git a/arch/mips/alchemy/devboards/db1300.c b/arch/mips/alchemy/devboards/db1300.c index 1c64fdb..1aa01c8 100644 --- a/arch/mips/alchemy/devboards/db1300.c +++ b/arch/mips/alchemy/devboards/db1300.c @@ -5,6 +5,8 @@ */ #include +#include +#include #include #include #include @@ -799,6 +801,12 @@ int __init db1300_dev_setup(void) if (platform_driver_register(_wm97xx_driver)) pr_warn("DB1300: failed to init touch pen irq support!\n"); +/* register the 12MHz crystal for the WM8731 I2S codec */ +c = clk_register_fixed_rate(NULL, "wm8731xtal", NULL, +CLK_IS_ROOT, 1200); +if (!IS_ERR(c)) +clk_register_clkdev(c, "mclk", "0-001b"); + /* Audio PSC clock is supplied by codecs (PSC1, 2) */ __raw_writel(PSC_SEL_CLK_SERCLK, (void __iomem *)KSEG1ADDR(AU1300_PSC1_PHYS_ADDR) + PSC_SEL_OFFSET); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: wm8731: let codec to manage clock by itself
On Mon, Feb 16, 2015 at 11:31 AM, Charles Keepax ckee...@opensource.wolfsonmicro.com wrote: On Thu, Feb 12, 2015 at 04:23:06PM +0800, Bo Shen wrote: Hi All, On 02/05/2015 03:35 PM, Bo Shen wrote: Let the wm8731 codec to manage clock by itself. Signed-off-by: Bo Shen voice.s...@atmel.com --- sound/soc/codecs/wm8731.c | 28 1 file changed, 28 insertions(+) Any comments for this patch (aka ping?) I preferred the idea of having the clock as optional and from the discussion on the last patch it didn't look too tricky to me too achieve. OTOH I think the Atmel system is the only one that uses both this CODEC and common clock so it doesn't look like this would cause any problems, but might be nice for this not to be one more thing for someone to fix up when moving a system to common clock. Not quite, there's one MIPS platform I maintain which needs a patch like the one below (tested): diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c index 8c13675..aa01ab2 100644 --- a/arch/mips/alchemy/devboards/db1200.c +++ b/arch/mips/alchemy/devboards/db1200.c @@ -19,6 +19,8 @@ */ #include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h #include linux/dma-mapping.h #include linux/gpio.h #include linux/i2c.h @@ -862,6 +864,12 @@ int __init db1200_dev_setup(void) irq_set_status_flags(DB1200_PC1_INSERT_INT, IRQ_NOAUTOEN); irq_set_status_flags(DB1200_PC1_EJECT_INT, IRQ_NOAUTOEN); +/* register the 12MHz crystal for the WM8731 I2S codec */ +c = clk_register_fixed_rate(NULL, wm8731xtal, NULL, +CLK_IS_ROOT, 1200); +if (!IS_ERR(c)) +clk_register_clkdev(c, mclk, 0-001b); + i2c_register_board_info(0, db1200_i2c_devs, ARRAY_SIZE(db1200_i2c_devs)); spi_register_board_info(db1200_spi_devs, diff --git a/arch/mips/alchemy/devboards/db1300.c b/arch/mips/alchemy/devboards/db1300.c index 1c64fdb..1aa01c8 100644 --- a/arch/mips/alchemy/devboards/db1300.c +++ b/arch/mips/alchemy/devboards/db1300.c @@ -5,6 +5,8 @@ */ #include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h #include linux/dma-mapping.h #include linux/gpio.h #include linux/gpio_keys.h @@ -799,6 +801,12 @@ int __init db1300_dev_setup(void) if (platform_driver_register(db1300_wm97xx_driver)) pr_warn(DB1300: failed to init touch pen irq support!\n); +/* register the 12MHz crystal for the WM8731 I2S codec */ +c = clk_register_fixed_rate(NULL, wm8731xtal, NULL, +CLK_IS_ROOT, 1200); +if (!IS_ERR(c)) +clk_register_clkdev(c, mclk, 0-001b); + /* Audio PSC clock is supplied by codecs (PSC1, 2) */ __raw_writel(PSC_SEL_CLK_SERCLK, (void __iomem *)KSEG1ADDR(AU1300_PSC1_PHYS_ADDR) + PSC_SEL_OFFSET); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown wrote: > On Tue, Feb 03, 2015 at 08:54:57AM +0100, Manuel Lauss wrote: > >> +wm8731->mclk = devm_clk_get(>dev, "mclk"); >> +if (IS_ERR(wm8731->mclk)) { >> +wm8731->mclk = NULL; >> +dev_warn(>dev, "assuming static MCLK\n"); >> +} > > This is broken for both deferred probe and in the case where the clock > API genuinely returns a NULL clock. Other than that it's the kind of > thing that we've done for some other drivers, though it's not good to > have to do this. Check them for correct behaviour. Hm, so the only option is to create the simples possible 12MHz clk object? Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown broo...@kernel.org wrote: On Tue, Feb 03, 2015 at 08:54:57AM +0100, Manuel Lauss wrote: +wm8731-mclk = devm_clk_get(spi-dev, mclk); +if (IS_ERR(wm8731-mclk)) { +wm8731-mclk = NULL; +dev_warn(spi-dev, assuming static MCLK\n); +} This is broken for both deferred probe and in the case where the clock API genuinely returns a NULL clock. Other than that it's the kind of thing that we've done for some other drivers, though it's not good to have to do this. Check them for correct behaviour. Hm, so the only option is to create the simples possible 12MHz clk object? Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
On Tue, Feb 3, 2015 at 4:33 AM, Bo Shen wrote: > Let the wm8731 codec to manage clock by itself. > > As all at91 related boards have been switch to CCF framework. So, on > the at91 related boards which use wm8731 will let it manage the clock, > or else the board use wm8731 is broken. > > However, at the same time the wm8731 codec is used on other boards, > I am sure this change will broken some boards. > > For example: poodle and corgi based on PXA SoC (in default configuration > file, no one use it). DB1200 board which is a mips based board. So I have > no idea how to fix them. > > So, my suggestion is to add CCF check based on the following patch? Any > idea or suggestions? What about the patch below? It makes absence of mclk object non-fatal and checks if wm8731->mclk is non-NULL before enabling/disabling it. Works on my DB1200/DB1300 boards: diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c index b115ed8..648b8cd 100644 --- a/sound/soc/codecs/wm8731.c +++ b/sound/soc/codecs/wm8731.c @@ -13,6 +13,7 @@ * published by the Free Software Foundation. */ +#include #include #include #include @@ -45,6 +46,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = { /* codec private data */ struct wm8731_priv { struct regmap *regmap; +struct clk *mclk; struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES]; const struct snd_pcm_hw_constraint_list *constraints; unsigned int sysclk; @@ -389,6 +391,8 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai *codec_dai, switch (clk_id) { case WM8731_SYSCLK_XTAL: case WM8731_SYSCLK_MCLK: +if (wm8731->mclk && clk_set_rate(wm8731->mclk, freq)) +return -EINVAL; wm8731->sysclk_type = clk_id; break; default: @@ -490,6 +494,8 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, switch (level) { case SND_SOC_BIAS_ON: +if (wm8731->mclk) +clk_prepare_enable(wm8731->mclk); break; case SND_SOC_BIAS_PREPARE: break; @@ -508,6 +514,8 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, snd_soc_write(codec, WM8731_PWR, reg | 0x0040); break; case SND_SOC_BIAS_OFF: +if (wm8731->mclk) +clk_disable_unprepare(wm8731->mclk); snd_soc_write(codec, WM8731_PWR, 0x); regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies), wm8731->supplies); @@ -666,6 +674,12 @@ static int wm8731_spi_probe(struct spi_device *spi) if (wm8731 == NULL) return -ENOMEM; +wm8731->mclk = devm_clk_get(>dev, "mclk"); +if (IS_ERR(wm8731->mclk)) { +wm8731->mclk = NULL; +dev_warn(>dev, "assuming static MCLK\n"); +} + mutex_init(>lock); wm8731->regmap = devm_regmap_init_spi(spi, _regmap); @@ -719,6 +733,12 @@ static int wm8731_i2c_probe(struct i2c_client *i2c, mutex_init(>lock); +wm8731->mclk = devm_clk_get(>dev, "mclk"); +if (IS_ERR(wm8731->mclk)) { +wm8731->mclk = NULL; +dev_warn(>dev, "assuming static MCLK\n"); +} + wm8731->regmap = devm_regmap_init_i2c(i2c, _regmap); if (IS_ERR(wm8731->regmap)) { ret = PTR_ERR(wm8731->regmap); -- Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
On Tue, Feb 3, 2015 at 4:33 AM, Bo Shen voice.s...@atmel.com wrote: Let the wm8731 codec to manage clock by itself. As all at91 related boards have been switch to CCF framework. So, on the at91 related boards which use wm8731 will let it manage the clock, or else the board use wm8731 is broken. However, at the same time the wm8731 codec is used on other boards, I am sure this change will broken some boards. For example: poodle and corgi based on PXA SoC (in default configuration file, no one use it). DB1200 board which is a mips based board. So I have no idea how to fix them. So, my suggestion is to add CCF check based on the following patch? Any idea or suggestions? What about the patch below? It makes absence of mclk object non-fatal and checks if wm8731-mclk is non-NULL before enabling/disabling it. Works on my DB1200/DB1300 boards: diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c index b115ed8..648b8cd 100644 --- a/sound/soc/codecs/wm8731.c +++ b/sound/soc/codecs/wm8731.c @@ -13,6 +13,7 @@ * published by the Free Software Foundation. */ +#include linux/clk.h #include linux/module.h #include linux/moduleparam.h #include linux/init.h @@ -45,6 +46,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = { /* codec private data */ struct wm8731_priv { struct regmap *regmap; +struct clk *mclk; struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES]; const struct snd_pcm_hw_constraint_list *constraints; unsigned int sysclk; @@ -389,6 +391,8 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai *codec_dai, switch (clk_id) { case WM8731_SYSCLK_XTAL: case WM8731_SYSCLK_MCLK: +if (wm8731-mclk clk_set_rate(wm8731-mclk, freq)) +return -EINVAL; wm8731-sysclk_type = clk_id; break; default: @@ -490,6 +494,8 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, switch (level) { case SND_SOC_BIAS_ON: +if (wm8731-mclk) +clk_prepare_enable(wm8731-mclk); break; case SND_SOC_BIAS_PREPARE: break; @@ -508,6 +514,8 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, snd_soc_write(codec, WM8731_PWR, reg | 0x0040); break; case SND_SOC_BIAS_OFF: +if (wm8731-mclk) +clk_disable_unprepare(wm8731-mclk); snd_soc_write(codec, WM8731_PWR, 0x); regulator_bulk_disable(ARRAY_SIZE(wm8731-supplies), wm8731-supplies); @@ -666,6 +674,12 @@ static int wm8731_spi_probe(struct spi_device *spi) if (wm8731 == NULL) return -ENOMEM; +wm8731-mclk = devm_clk_get(spi-dev, mclk); +if (IS_ERR(wm8731-mclk)) { +wm8731-mclk = NULL; +dev_warn(spi-dev, assuming static MCLK\n); +} + mutex_init(wm8731-lock); wm8731-regmap = devm_regmap_init_spi(spi, wm8731_regmap); @@ -719,6 +733,12 @@ static int wm8731_i2c_probe(struct i2c_client *i2c, mutex_init(wm8731-lock); +wm8731-mclk = devm_clk_get(i2c-dev, mclk); +if (IS_ERR(wm8731-mclk)) { +wm8731-mclk = NULL; +dev_warn(i2c-dev, assuming static MCLK\n); +} + wm8731-regmap = devm_regmap_init_i2c(i2c, wm8731_regmap); if (IS_ERR(wm8731-regmap)) { ret = PTR_ERR(wm8731-regmap); -- Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS: hang in kmalloc with seccomp writer locks
On Mon, Aug 11, 2014 at 1:49 PM, David Rientjes wrote: > On Mon, 11 Aug 2014, Manuel Lauss wrote: > >> Hi Kees, >> >> My MIPS32 toys hang early during bootup at the first kmalloc() with >> seccomp enabled. >> I've bisected it to commit dbd952127d11bb44a4ea30b08cc60531b6a23d71 >> ("seccomp: introduce writer locking"). And indeed, reverting this >> commit fixes the hang. >> >> I'm not sure if seccomp is even working on MIPS, but I've never had >> problems with >> it before so I thought I let you know. >> > > Does enabling CONFIG_DEBUG_SPINLOCK fix the issue? Yes it does indeed. Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MIPS: hang in kmalloc with seccomp writer locks
Hi Kees, My MIPS32 toys hang early during bootup at the first kmalloc() with seccomp enabled. I've bisected it to commit dbd952127d11bb44a4ea30b08cc60531b6a23d71 ("seccomp: introduce writer locking"). And indeed, reverting this commit fixes the hang. I'm not sure if seccomp is even working on MIPS, but I've never had problems with it before so I thought I let you know. Thanks, and have a nice day! Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MIPS: hang in kmalloc with seccomp writer locks
Hi Kees, My MIPS32 toys hang early during bootup at the first kmalloc() with seccomp enabled. I've bisected it to commit dbd952127d11bb44a4ea30b08cc60531b6a23d71 (seccomp: introduce writer locking). And indeed, reverting this commit fixes the hang. I'm not sure if seccomp is even working on MIPS, but I've never had problems with it before so I thought I let you know. Thanks, and have a nice day! Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS: hang in kmalloc with seccomp writer locks
On Mon, Aug 11, 2014 at 1:49 PM, David Rientjes rient...@google.com wrote: On Mon, 11 Aug 2014, Manuel Lauss wrote: Hi Kees, My MIPS32 toys hang early during bootup at the first kmalloc() with seccomp enabled. I've bisected it to commit dbd952127d11bb44a4ea30b08cc60531b6a23d71 (seccomp: introduce writer locking). And indeed, reverting this commit fixes the hang. I'm not sure if seccomp is even working on MIPS, but I've never had problems with it before so I thought I let you know. Does enabling CONFIG_DEBUG_SPINLOCK fix the issue? Yes it does indeed. Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] mips: Add cma support to mips
Hi, On Wed, Jul 16, 2014 at 5:51 PM, Zubair Lutfullah Kakakhel wrote: > Here we have 4 patches that add cma support to mips. > > Patch 1 adds dma-contiguous.h to asm-generic > Patch 2 and 3 make arm64 and x86 use dma-contiguous from asm-generic > Patch 4 adds cma to mips. I've given this a try on mips32, I haven't dug into this error yet, maybe you have an idea: [...] Alchemy clocktree installed cma: CMA: reserved 32 MiB at 0a00 [...] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-platform: EHCI generic platform driver ehci-platform ehci-platform.0: EHCI Host Controller ehci-platform ehci-platform.0: new USB bus registered, assigned bus number 1 CPU 0 Unable to handle kernel paging request at virtual address , epc == 807669b0, ra == 8041a970 Oops[#1]: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc4-db1xxx-00062-g6c7bf71-dirty #1 task: 8bc34000 ti: 8bc1e000 task.ti: 8bc1e000 $ 0 : 10003c00 8bc1fb90 $ 4 : 80974f9c 0093 0093 $ 8 : 0007 808d 0010 0093 $12 : 5f6d6f72 746e6f63 $16 : 80974f9c 0001 8bc34000 808e6220 $20 : 80974fa0 80974f9c 8bc76380 $24 : 0010 804091cc $28 : 8bc1e000 8bc1fb80 8097 8041a970 Hi: Lo: 3a699d00 epc : 807669b0 __mutex_lock_slowpath+0x4c/0x108 Not tainted ra: 8041a970 dma_alloc_from_contiguous+0xb8/0x1ec Status: 10003c03KERNEL EXL IE Cause : 0080800c BadVA : PrId : 800c8000 (Au1300) Process swapper (pid: 1, threadinfo=8bc1e000, task=8bc34000, tls=) Stack : 8bc77010 8079 808f 8bc76380 80974fa0 8bc1fbd8 0013 0006 80974f90 0001 808e6220 8079 8041a970 8b752c83 80790adc 80974f90 0001 808932d5 8bc1fcb4 808932d3 0fff 1000 8b752e8c 00d0 8bc77010 808f 808f 8bc76380 80111d58 ff0a0210 8b752c80 0003 8b752c80 8bc1fcb0 ... Call Trace: [<807669b0>] __mutex_lock_slowpath+0x4c/0x108 [<8041a970>] dma_alloc_from_contiguous+0xb8/0x1ec [<80111d58>] mips_dma_alloc_coherent+0xa4/0x148 [<801c11f8>] dma_pool_alloc+0xe0/0x1bc [<804c755c>] ehci_qh_alloc+0x44/0xd4 [<804c8044>] ehci_setup+0x158/0x448 [<804cadfc>] ehci_platform_reset+0x74/0xd8 [<804af588>] usb_add_hcd+0x26c/0x79c [<804caca0>] ehci_platform_probe+0x2c4/0x3ac [<80417480>] platform_drv_probe+0x24/0x60 [<80415d8c>] driver_probe_device+0xec/0x244 [<80415fc4>] __driver_attach+0x7c/0xb4 [<80414190>] bus_for_each_dev+0x64/0xc0 [<80414cd0>] bus_add_driver+0xdc/0x1f8 [<804168d8>] driver_register+0xac/0x114 [<80901c7c>] do_one_initcall+0x174/0x240 [<80901ecc>] kernel_init_freeable+0x184/0x250 [<80761edc>] kernel_init+0x10/0x100 [<80108d88>] ret_from_kernel_thread+0x14/0x1c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] mips: Add cma support to mips
Hi, On Wed, Jul 16, 2014 at 5:51 PM, Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com wrote: Here we have 4 patches that add cma support to mips. Patch 1 adds dma-contiguous.h to asm-generic Patch 2 and 3 make arm64 and x86 use dma-contiguous from asm-generic Patch 4 adds cma to mips. I've given this a try on mips32, I haven't dug into this error yet, maybe you have an idea: [...] Alchemy clocktree installed cma: CMA: reserved 32 MiB at 0a00 [...] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-platform: EHCI generic platform driver ehci-platform ehci-platform.0: EHCI Host Controller ehci-platform ehci-platform.0: new USB bus registered, assigned bus number 1 CPU 0 Unable to handle kernel paging request at virtual address , epc == 807669b0, ra == 8041a970 Oops[#1]: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc4-db1xxx-00062-g6c7bf71-dirty #1 task: 8bc34000 ti: 8bc1e000 task.ti: 8bc1e000 $ 0 : 10003c00 8bc1fb90 $ 4 : 80974f9c 0093 0093 $ 8 : 0007 808d 0010 0093 $12 : 5f6d6f72 746e6f63 $16 : 80974f9c 0001 8bc34000 808e6220 $20 : 80974fa0 80974f9c 8bc76380 $24 : 0010 804091cc $28 : 8bc1e000 8bc1fb80 8097 8041a970 Hi: Lo: 3a699d00 epc : 807669b0 __mutex_lock_slowpath+0x4c/0x108 Not tainted ra: 8041a970 dma_alloc_from_contiguous+0xb8/0x1ec Status: 10003c03KERNEL EXL IE Cause : 0080800c BadVA : PrId : 800c8000 (Au1300) Process swapper (pid: 1, threadinfo=8bc1e000, task=8bc34000, tls=) Stack : 8bc77010 8079 808f 8bc76380 80974fa0 8bc1fbd8 0013 0006 80974f90 0001 808e6220 8079 8041a970 8b752c83 80790adc 80974f90 0001 808932d5 8bc1fcb4 808932d3 0fff 1000 8b752e8c 00d0 8bc77010 808f 808f 8bc76380 80111d58 ff0a0210 8b752c80 0003 8b752c80 8bc1fcb0 ... Call Trace: [807669b0] __mutex_lock_slowpath+0x4c/0x108 [8041a970] dma_alloc_from_contiguous+0xb8/0x1ec [80111d58] mips_dma_alloc_coherent+0xa4/0x148 [801c11f8] dma_pool_alloc+0xe0/0x1bc [804c755c] ehci_qh_alloc+0x44/0xd4 [804c8044] ehci_setup+0x158/0x448 [804cadfc] ehci_platform_reset+0x74/0xd8 [804af588] usb_add_hcd+0x26c/0x79c [804caca0] ehci_platform_probe+0x2c4/0x3ac [80417480] platform_drv_probe+0x24/0x60 [80415d8c] driver_probe_device+0xec/0x244 [80415fc4] __driver_attach+0x7c/0xb4 [80414190] bus_for_each_dev+0x64/0xc0 [80414cd0] bus_add_driver+0xdc/0x1f8 [804168d8] driver_register+0xac/0x114 [80901c7c] do_one_initcall+0x174/0x240 [80901ecc] kernel_init_freeable+0x184/0x250 [80761edc] kernel_init+0x10/0x100 [80108d88] ret_from_kernel_thread+0x14/0x1c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 05/11] MIPS: Alchemy: pci: use clk framework to enable PCI clock
Hi Sergei, On Thu, Jul 3, 2014 at 3:50 PM, Sergei Shtylyov wrote: >> --- a/arch/mips/pci/pci-alchemy.c >> +++ b/arch/mips/pci/pci-alchemy.c >> @@ -394,11 +396,24 @@ static int alchemy_pci_probe(struct platform_device >> *pdev) >> + ret = clk_prepare_enable(c); >> + if (ret) { >> + dev_err(>dev, "cannot enable PCI clock\n"); >> + clk_put(c); >> + goto out2; > > >Isn't it simpler to add one more label before clk_put() at end of > function? Yes, I have changed it locally. Thank you! Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 04/11] MIPS: Alchemy: usb: use clk framework
Add use of the common clock framework to set and enable the 48MHz clock source for the onchip OHCI and UDC blocks. Tested on a DB1500. (Au1200 and Au1300 use an external 48MHz crystal). Signed-off-by: Manuel Lauss --- v2: taken from initial patch #2 arch/mips/alchemy/common/usb.c | 47 +++--- 1 file changed, 40 insertions(+), 7 deletions(-) diff --git a/arch/mips/alchemy/common/usb.c b/arch/mips/alchemy/common/usb.c index d193dbe..297805a 100644 --- a/arch/mips/alchemy/common/usb.c +++ b/arch/mips/alchemy/common/usb.c @@ -9,6 +9,7 @@ * */ +#include #include #include #include @@ -387,10 +388,25 @@ static inline void au1200_usb_init(void) udelay(1000); } -static inline void au1000_usb_init(unsigned long rb, int reg) +static inline int au1000_usb_init(unsigned long rb, int reg) { void __iomem *base = (void __iomem *)KSEG1ADDR(rb + reg); unsigned long r = __raw_readl(base); + struct clk *c; + + /* 48MHz check. Don't init if no one can provide it */ + c = clk_get(NULL, "usbh_clk"); + if (IS_ERR(c)) + return -ENODEV; + if (clk_round_rate(c, 4800) != 4800) { + clk_put(c); + return -ENODEV; + } + if (clk_set_rate(c, 4800)) { + clk_put(c); + return -ENODEV; + } + clk_put(c); #if defined(__BIG_ENDIAN) r |= USBHEN_BE; @@ -400,6 +416,8 @@ static inline void au1000_usb_init(unsigned long rb, int reg) __raw_writel(r, base); wmb(); udelay(1000); + + return 0; } @@ -407,8 +425,15 @@ static inline void __au1xx0_ohci_control(int enable, unsigned long rb, int creg) { void __iomem *base = (void __iomem *)KSEG1ADDR(rb); unsigned long r = __raw_readl(base + creg); + struct clk *c = clk_get(NULL, "usbh_clk"); + + if (IS_ERR(c)) + return; if (enable) { + if (clk_prepare_enable(c)) + goto out; + __raw_writel(r | USBHEN_CE, base + creg); wmb(); udelay(1000); @@ -423,7 +448,10 @@ static inline void __au1xx0_ohci_control(int enable, unsigned long rb, int creg) } else { __raw_writel(r & ~(USBHEN_CE | USBHEN_E), base + creg); wmb(); + clk_disable_unprepare(c); } +out: + clk_put(c); } static inline int au1000_usb_control(int block, int enable, unsigned long rb, @@ -457,11 +485,11 @@ int alchemy_usb_control(int block, int enable) case ALCHEMY_CPU_AU1500: case ALCHEMY_CPU_AU1100: ret = au1000_usb_control(block, enable, - AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); + AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); break; case ALCHEMY_CPU_AU1550: ret = au1000_usb_control(block, enable, - AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); + AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); break; case ALCHEMY_CPU_AU1200: ret = au1200_usb_control(block, enable); @@ -569,14 +597,18 @@ static struct syscore_ops alchemy_usb_pm_ops = { static int __init alchemy_usb_init(void) { + int ret = 0; + switch (alchemy_get_cputype()) { case ALCHEMY_CPU_AU1000: case ALCHEMY_CPU_AU1500: case ALCHEMY_CPU_AU1100: - au1000_usb_init(AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); + ret = au1000_usb_init(AU1000_USB_OHCI_PHYS_ADDR, + AU1000_OHCICFG); break; case ALCHEMY_CPU_AU1550: - au1000_usb_init(AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); + ret = au1000_usb_init(AU1550_USB_OHCI_PHYS_ADDR, + AU1550_OHCICFG); break; case ALCHEMY_CPU_AU1200: au1200_usb_init(); @@ -586,8 +618,9 @@ static int __init alchemy_usb_init(void) break; } - register_syscore_ops(_usb_pm_ops); + if (!ret) + register_syscore_ops(_usb_pm_ops); - return 0; + return ret; } arch_initcall(alchemy_usb_init); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 02/11] MIPS: Alchemy: clock framework integration of onchip clocks
This patch introduces common clock framework integration for all configurable on-chip clocks on Alchemy chips: - 2 or 3 PLLs which generate integer multiples of the root rate 12MHz, - 6 dividers which take one of the 3 PLLs as input and divide their rate by either multiples of 2 or 1 (Au1300). - another bank of up to 6 muxes which take either one of the 6 above dividers or one of the PLLs directly and divide their rate further by 1, 2, 3 or 4. - a few other sources which are used by onchip peripherals and are informational. This implementation will take the clock tree as it was set up by boot firmware: all in-kernel boards should continue to work without having to set up the clock tree in board code. CLK_IGNORE_DISABLED will be removed once all drivers have been converted. Signed-off-by: Manuel Lauss --- v2: split into multiple patches, few improvements arch/mips/Kconfig |1 + arch/mips/alchemy/common/Makefile |4 +- arch/mips/alchemy/common/clock.c | 1097 arch/mips/include/asm/mach-au1x00/au1000.h | 16 + 4 files changed, 1116 insertions(+), 2 deletions(-) create mode 100644 arch/mips/alchemy/common/clock.c diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 458608d..86e79de 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -72,6 +72,7 @@ config MIPS_ALCHEMY select SYS_SUPPORTS_APM_EMULATION select ARCH_REQUIRE_GPIOLIB select SYS_SUPPORTS_ZBOOT + select COMMON_CLK config AR7 bool "Texas Instruments AR7" diff --git a/arch/mips/alchemy/common/Makefile b/arch/mips/alchemy/common/Makefile index cb83d8d..c8dedcb 100644 --- a/arch/mips/alchemy/common/Makefile +++ b/arch/mips/alchemy/common/Makefile @@ -5,8 +5,8 @@ # Makefile for the Alchemy Au1xx0 CPUs, generic files. # -obj-y += prom.o time.o clocks.o platform.o power.o setup.o \ - sleeper.o dma.o dbdma.o vss.o irq.o usb.o +obj-y += prom.o time.o clock.o clocks.o platform.o power.o \ +setup.o sleeper.o dma.o dbdma.o vss.o irq.o usb.o # optional gpiolib support ifeq ($(CONFIG_ALCHEMY_GPIO_INDIRECT),) diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c new file mode 100644 index 000..f29470b --- /dev/null +++ b/arch/mips/alchemy/common/clock.c @@ -0,0 +1,1097 @@ +/* + * Alchemy clocks. + * + * Exposes all configurable internal clock sources to the clk framework. + * + * We have: + * - Root source, usually 12MHz supplied by an external crystal + * - 3 PLLs which generate multiples of root rate [AUX, CPU, AUX2] + * + * Dividers: + * - 6 clock dividers with: + * * selectable source [one of the PLLs], + * * output divided between [2 .. 512 in steps of 2] (!Au1300) + * or [1 .. 256 in steps of 1] (Au1300), + * * can be enabled individually. + * + * - up to 6 "internal" (fixed) consumers which: + * * take either AUXPLL or one of the above 6 dividers as input, + * * divide this input by 1, 2, or 4 (and 3 on Au1300). + * * can be disabled separately. + * + * Misc clocks: + * - sysbus clock: CPU core clock (CPUPLL) divided by 2, 3 or 4. + *depends on board design and should be set by bootloader, read-only. + * - peripheral clock: half the rate of sysbus clock, source for a lot + *of peripheral blocks, read-only. + * - memory clock: clk rate to main memory chips, depends on board + *design and is read-only, + * - lrclk: the static bus clock signal for synchronous operation. + *depends on board design, must be set by bootloader, + *but may be required to correctly configure devices attached to + *the static bus. The Au1000/1500/1100 manuals call it LCLK, on + *later models it's called RCLK. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Base clock: 12MHz is the default in all databooks, and I haven't + * found any board yet which uses a different rate. + */ +#define ALCHEMY_ROOTCLK_RATE 1200 + +/* + * the internal sources which can be driven by the PLLs and dividers. + * Names taken from the databooks, refer to them for more information, + * especially which ones are share a clock line. + */ +static const char * const alchemy_au1300_intclknames[] = { + "lcd_intclk", "gpemgp_clk", "maempe_clk", "maebsa_clk", + "EXTCLK0", "EXTCLK1" +}; + +static const char * const alchemy_au1200_intclknames[] = { + "lcd_intclk", NULL, NULL, NULL, "EXTCLK0", "EXTCLK1" +}; + +static const char * const alchemy_au1550_intclknames[] = { + "usb_clk", "psc0_intclk", "psc1_intclk", "pci_clko", + "EXTCLK0", "EXTCLK1" +}; + +static const char * const alchemy_au1100_intclknames[] = { + "usb_clk", "lcd_intclk", NULL, "i2s_clk", "EXTCLK0&quo
[RFC PATCH v2 06/11] MIPS: Alchemy: db1200: use clk framework
Make use of the clk framework to give us a rate as close to 50MHz as possible. Signed-off-by: Manuel Lauss --- arch/mips/alchemy/devboards/db1200.c | 45 1 file changed, 20 insertions(+), 25 deletions(-) diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c index 8c71cde..f255586 100644 --- a/arch/mips/alchemy/devboards/db1200.c +++ b/arch/mips/alchemy/devboards/db1200.c @@ -18,6 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include #include #include #include @@ -129,7 +130,6 @@ static int __init db1200_detect_board(void) int __init db1200_board_setup(void) { - unsigned long freq0, clksrc, div, pfc; unsigned short whoami; if (db1200_detect_board()) @@ -149,30 +149,6 @@ int __init db1200_board_setup(void) " Board-ID %d Daughtercard ID %d\n", get_system_type(), (whoami >> 4) & 0xf, (whoami >> 8) & 0xf, whoami & 0xf); - /* SMBus/SPI on PSC0, Audio on PSC1 */ - pfc = AU1X_RDSYS(AU1000_SYS_PINFUNC); - pfc &= ~(SYS_PINFUNC_P0A | SYS_PINFUNC_P0B); - pfc &= ~(SYS_PINFUNC_P1A | SYS_PINFUNC_P1B | SYS_PINFUNC_FS3); - pfc |= SYS_PINFUNC_P1C; /* SPI is configured later */ - AU1X_WRSYS(pfc, AU1000_SYS_PINFUNC); - - /* Clock configurations: PSC0: ~50MHz via Clkgen0, derived from -* CPU clock; all other clock generators off/unused. -*/ - div = (get_au1x00_speed() + 2500) / 5000; - if (div & 1) - div++; - div = ((div >> 1) - 1) & 0xff; - - freq0 = div << SYS_FC_FRDIV0_BIT; - AU1X_WRSYS(freq0, AU1000_SYS_FREQCTRL0); - freq0 |= SYS_FC_FE0;/* enable F0 */ - AU1X_WRSYS(freq0, AU1000_SYS_FREQCTRL0); - - /* psc0_intclk comes 1:1 from F0 */ - clksrc = SYS_CS_MUX_FQ0 << SYS_CS_ME0_BIT; - AU1X_WRSYS(clksrc, AU1000_SYS_CLKSRC); - return 0; } @@ -845,6 +821,7 @@ int __init db1200_dev_setup(void) unsigned long pfc; unsigned short sw; int swapped, bid; + struct clk *c; bid = BCSR_WHOAMI_BOARD(bcsr_read(BCSR_WHOAMI)); if ((bid == BCSR_WHOAMI_PB1200_DDR1) || @@ -857,6 +834,24 @@ int __init db1200_dev_setup(void) irq_set_irq_type(AU1200_GPIO7_INT, IRQ_TYPE_LEVEL_LOW); bcsr_init_irq(DB1200_INT_BEGIN, DB1200_INT_END, AU1200_GPIO7_INT); + /* SMBus/SPI on PSC0, Audio on PSC1 */ + pfc = AU1X_RDSYS(AU1000_SYS_PINFUNC); + pfc &= ~(SYS_PINFUNC_P0A | SYS_PINFUNC_P0B); + pfc &= ~(SYS_PINFUNC_P1A | SYS_PINFUNC_P1B | SYS_PINFUNC_FS3); + pfc |= SYS_PINFUNC_P1C; /* SPI is configured later */ + AU1X_WRSYS(pfc, AU1000_SYS_PINFUNC); + + /* get 50MHz for I2C driver on PSC0 */ + c = clk_get(NULL, "psc0_intclk"); + if (!IS_ERR(c)) { + pfc = clk_round_rate(c, 5000); + if ((pfc < 1) || (abs(5000 - pfc) > 250)) + pr_warn("DB1200: cant get I2C close to 50MHz\n"); + else + clk_set_rate(c, pfc); + clk_put(c); + } + /* insert/eject pairs: one of both is always screaming. To avoid * issues they must not be automatically enabled when initially * requested. -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 11/11] MIPS: Alchemy: remove old clock support
With the clock framework in place, remove unused functions and bits. Signed-off-by: Manuel Lauss --- arch/mips/alchemy/common/Makefile | 2 +- arch/mips/alchemy/common/clocks.c | 87 -- arch/mips/alchemy/common/setup.c | 15 -- arch/mips/include/asm/mach-au1x00/au1000.h | 68 --- 4 files changed, 1 insertion(+), 171 deletions(-) delete mode 100644 arch/mips/alchemy/common/clocks.c diff --git a/arch/mips/alchemy/common/Makefile b/arch/mips/alchemy/common/Makefile index c8dedcb..f64744f 100644 --- a/arch/mips/alchemy/common/Makefile +++ b/arch/mips/alchemy/common/Makefile @@ -5,7 +5,7 @@ # Makefile for the Alchemy Au1xx0 CPUs, generic files. # -obj-y += prom.o time.o clock.o clocks.o platform.o power.o \ +obj-y += prom.o time.o clock.o platform.o power.o \ setup.o sleeper.o dma.o dbdma.o vss.o irq.o usb.o # optional gpiolib support diff --git a/arch/mips/alchemy/common/clocks.c b/arch/mips/alchemy/common/clocks.c deleted file mode 100644 index e77fa9b..000 --- a/arch/mips/alchemy/common/clocks.c +++ /dev/null @@ -1,87 +0,0 @@ -/* - * BRIEF MODULE DESCRIPTION - * Simple Au1xx0 clocks routines. - * - * Copyright 2001, 2008 MontaVista Software Inc. - * Author: MontaVista Software, Inc. - * - * 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. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#include -#include -#include -#include - -/* - * I haven't found anyone that doesn't use a 12 MHz source clock, - * but just in case. - */ -#define AU1000_SRC_CLK 1200 - -static unsigned int au1x00_clock; /* Hz */ - -/* - * Set the au1000_clock - */ -void set_au1x00_speed(unsigned int new_freq) -{ - au1x00_clock = new_freq; -} - -unsigned int get_au1x00_speed(void) -{ - return au1x00_clock; -} -EXPORT_SYMBOL(get_au1x00_speed); - -/* - * We read the real processor speed from the PLL. This is important - * because it is more accurate than computing it from the 32 KHz - * counter, if it exists. If we don't have an accurate processor - * speed, all of the peripherals that derive their clocks based on - * this advertised speed will introduce error and sometimes not work - * properly. This function is further convoluted to still allow configurations - * to do that in case they have really, really old silicon with a - * write-only PLL register.-- Dan - */ -unsigned long au1xxx_calc_clock(void) -{ - unsigned long cpu_speed; - - /* -* On early Au1000, sys_cpupll was write-only. Since these -* silicon versions of Au1000 are not sold by AMD, we don't bend -* over backwards trying to determine the frequency. -*/ - if (au1xxx_cpu_has_pll_wo()) - cpu_speed = 39600; - else - cpu_speed = (AU1X_RDSYS(AU1000_SYS_CPUPLL) & 0x003f) - * AU1000_SRC_CLK; - - /* On Alchemy CPU:counter ratio is 1:1 */ - mips_hpt_frequency = cpu_speed; - - set_au1x00_speed(cpu_speed); - - return cpu_speed; -} diff --git a/arch/mips/alchemy/common/setup.c b/arch/mips/alchemy/common/setup.c index 6f8b91d..f635934 100644 --- a/arch/mips/alchemy/common/setup.c +++ b/arch/mips/alchemy/common/setup.c @@ -27,12 +27,9 @@ #include #include -#include -#include #include #include -#include #include @@ -40,18 +37,6 @@ extern void __init board_setup(void); void __init plat_mem_setup(void) { - unsigned long est_freq; - - /* determine core clock */ - est_freq = au1xxx_calc_clock(); - est_freq += 5000;/* round */ - est_freq -= est_freq % 1; - printk(KERN_INFO "(PRId %08x) @ %lu.%02lu MHz\n", read_c0_prid(), - est_
[RFC PATCH v2 05/11] MIPS: Alchemy: pci: use clk framework to enable PCI clock
Use the clock framework to get at the PCI clock source and enable it on driver initialization. Signed-off-by: Manuel Lauss --- arch/mips/pci/pci-alchemy.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/mips/pci/pci-alchemy.c b/arch/mips/pci/pci-alchemy.c index 912c5f2..adc810f 100644 --- a/arch/mips/pci/pci-alchemy.c +++ b/arch/mips/pci/pci-alchemy.c @@ -7,6 +7,7 @@ * Support for all devices (greater than 16) added by David Gathright. */ +#include #include #include #include @@ -365,6 +366,7 @@ static int alchemy_pci_probe(struct platform_device *pdev) void __iomem *virt_io; unsigned long val; struct resource *r; + struct clk *c; int ret; /* need at least PCI IRQ mapping table */ @@ -394,11 +396,24 @@ static int alchemy_pci_probe(struct platform_device *pdev) goto out1; } + c = clk_get(>dev, "pci_clko"); + if (IS_ERR(c)) { + dev_err(>dev, "unable to find PCI clock\n"); + ret = PTR_ERR(c); + goto out2; + } + ret = clk_prepare_enable(c); + if (ret) { + dev_err(>dev, "cannot enable PCI clock\n"); + clk_put(c); + goto out2; + } + ctx->regs = ioremap_nocache(r->start, resource_size(r)); if (!ctx->regs) { dev_err(>dev, "cannot map pci regs\n"); ret = -ENODEV; - goto out2; + goto out5; } /* map parts of the PCI IO area */ @@ -466,12 +481,18 @@ static int alchemy_pci_probe(struct platform_device *pdev) register_syscore_ops(_pci_pmops); register_pci_controller(>alchemy_pci_ctrl); + dev_info(>dev, "PCI controller at %ld MHz\n", +clk_get_rate(c) / 100); + return 0; out4: iounmap(virt_io); out3: iounmap(ctx->regs); +out5: + clk_disable_unprepare(c); + clk_put(c); out2: release_mem_region(r->start, resource_size(r)); out1: -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 10/11] MIPS: Alchemy: au1xmmc: use clk framework
Use the clock framework to get the peripheral clock rate to correctly set the MMC/SD bus clock divider. Signed-off-by: Manuel Lauss --- drivers/mmc/host/au1xmmc.c | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c index 1837309..0c0ed16 100644 --- a/drivers/mmc/host/au1xmmc.c +++ b/drivers/mmc/host/au1xmmc.c @@ -32,6 +32,7 @@ * (the low to high transition will not occur). */ +#include #include #include #include @@ -118,6 +119,7 @@ struct au1xmmc_host { struct au1xmmc_platform_data *platdata; struct platform_device *pdev; struct resource *ioarea; + struct clk *clk; }; /* Status flags used by the host structure */ @@ -596,17 +598,10 @@ static void au1xmmc_cmd_complete(struct au1xmmc_host *host, u32 status) static void au1xmmc_set_clock(struct au1xmmc_host *host, int rate) { - unsigned int pbus = get_au1x00_speed(); - unsigned int divisor; + unsigned int pbus = clk_get_rate(host->clk); + unsigned int divisor = ((pbus / rate) / 2) - 1; u32 config; - /* From databook: -* divisor = cpuclock / sbus_divisor) / 2) / mmcclock) / 2) - 1 -*/ - pbus /= ((AU1X_RDSYS(AU1000_SYS_POWERCTRL) & 0x3) + 2); - pbus /= 2; - divisor = ((pbus / rate) / 2) - 1; - config = __raw_readl(HOST_CONFIG(host)); config &= ~(SD_CONFIG_DIV); @@ -1029,6 +1024,16 @@ static int au1xmmc_probe(struct platform_device *pdev) goto out3; } + host->clk = clk_get(>dev, ALCHEMY_PERIPH_CLK); + if (IS_ERR(host->clk)) { + dev_err(>dev, "cannot find clock\n"); + goto out_irq; + } + if (clk_prepare_enable(host->clk)) { + dev_err(>dev, "cannot enable clock\n"); + goto out_clk; + } + host->status = HOST_S_IDLE; /* board-specific carddetect setup, if any */ @@ -1105,7 +1110,10 @@ out5: if (host->platdata && host->platdata->cd_setup && !(mmc->caps & MMC_CAP_NEEDS_POLL)) host->platdata->cd_setup(mmc, 0); - +out_clk: + clk_disable_unprepare(host->clk); + clk_put(host->clk); +out_irq: free_irq(host->irq, host); out3: iounmap((void *)host->iobase); @@ -1147,6 +1155,9 @@ static int au1xmmc_remove(struct platform_device *pdev) au1xmmc_set_power(host, 0); + clk_disable_unprepare(host->clk); + clk_put(host->clk); + free_irq(host->irq, host); iounmap((void *)host->iobase); release_resource(host->ioarea); -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 08/11] MIPS: Alchemy: au1100fb: use clk framework
Use the clock framework to en/disable the clock to the au1100 framebuffer device. Signed-off-by: Manuel Lauss --- arch/mips/alchemy/devboards/db1000.c | 14 ++ drivers/video/fbdev/au1100fb.c | 36 ++-- drivers/video/fbdev/au1100fb.h | 1 + 3 files changed, 37 insertions(+), 14 deletions(-) diff --git a/arch/mips/alchemy/devboards/db1000.c b/arch/mips/alchemy/devboards/db1000.c index 6e55bcc..5b4f81b 100644 --- a/arch/mips/alchemy/devboards/db1000.c +++ b/arch/mips/alchemy/devboards/db1000.c @@ -19,6 +19,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include #include #include #include @@ -496,6 +497,7 @@ int __init db1000_dev_setup(void) int board = BCSR_WHOAMI_BOARD(bcsr_read(BCSR_WHOAMI)); int c0, c1, d0, d1, s0, s1, flashsize = 32, twosocks = 1; unsigned long pfc; + struct clk *c, *p; if (board == BCSR_WHOAMI_DB1500) { c0 = AU1500_GPIO2_INT; @@ -525,6 +527,18 @@ int __init db1000_dev_setup(void) spi_register_board_info(db1100_spi_info, ARRAY_SIZE(db1100_spi_info)); + /* link LCD clock to AUXPLL */ + p = clk_get(NULL, "auxpll_clk"); + c = clk_get(NULL, "lcd_intclk"); + if (!IS_ERR(c) && !IS_ERR(p)) { + clk_set_parent(c, p); + clk_set_rate(c, clk_get_rate(p)); + } + if (!IS_ERR(c)) + clk_put(c); + if (!IS_ERR(p)) + clk_put(p); + platform_add_devices(db1100_devs, ARRAY_SIZE(db1100_devs)); platform_device_register(_spi_dev); } else if (board == BCSR_WHOAMI_DB1000) { diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c index 2c2804b..a7145ce 100644 --- a/drivers/video/fbdev/au1100fb.c +++ b/drivers/video/fbdev/au1100fb.c @@ -41,6 +41,7 @@ * with this program; if not, write to the Free Software Foundation, Inc., * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include #include #include #include @@ -434,7 +435,7 @@ static int au1100fb_drv_probe(struct platform_device *dev) struct au1100fb_device *fbdev = NULL; struct resource *regs_res; unsigned long page; - u32 sys_clksrc; + struct clk *c; /* Allocate new device private */ fbdev = devm_kzalloc(>dev, sizeof(struct au1100fb_device), @@ -473,6 +474,13 @@ static int au1100fb_drv_probe(struct platform_device *dev) print_dbg("Register memory map at %p", fbdev->regs); print_dbg("phys=0x%08x, size=%d", fbdev->regs_phys, fbdev->regs_len); + c = clk_get(NULL, "lcd_intclk"); + if (!IS_ERR(c)) { + fbdev->lcdclk = c; + clk_set_rate(c, 4800); + clk_prepare_enable(c); + } + /* Allocate the framebuffer to the maximum screen size * nbr of video buffers */ fbdev->fb_len = fbdev->panel->xres * fbdev->panel->yres * (fbdev->panel->bpp >> 3) * AU1100FB_NBR_VIDEO_BUFFERS; @@ -506,11 +514,6 @@ static int au1100fb_drv_probe(struct platform_device *dev) print_dbg("Framebuffer memory map at %p", fbdev->fb_mem); print_dbg("phys=0x%08x, size=%dK", fbdev->fb_phys, fbdev->fb_len / 1024); - /* Setup LCD clock to AUX (48 MHz) */ - sys_clksrc = AU1X_RDSYS(AU1000_SYS_CLKSRC) & - ~(SYS_CS_ML_MASK | SYS_CS_DL | SYS_CS_CL); - AU1X_WRSYS((sys_clksrc | (1 << SYS_CS_ML_BIT)), AU1000_SYS_CLKSRC); - /* load the panel info into the var struct */ au1100fb_var.bits_per_pixel = fbdev->panel->bpp; au1100fb_var.xres = fbdev->panel->xres; @@ -547,6 +550,10 @@ static int au1100fb_drv_probe(struct platform_device *dev) return 0; failed: + if (fbdev->lcdclk) { + clk_disable_unprepare(fbdev->lcdclk); + clk_put(fbdev->lcdclk); + } if (fbdev->fb_mem) { dma_free_noncoherent(>dev, fbdev->fb_len, fbdev->fb_mem, fbdev->fb_phys); @@ -577,11 +584,15 @@ int au1100fb_drv_remove(struct platform_device *dev) fb_dealloc_cmap(>info.cmap); + if (fbdev->lcdclk) { + clk_disable_unprepare(fbdev->lcdclk); + clk_put(fbdev->lcdclk); + } + return 0; } #ifdef CONFIG_PM -static u32 sys_clksrc; static struct au1100fb_regs fbregs; int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state) @@ -591,14 +602,11 @@ int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state) if (!fbdev)
[RFC PATCH v2 09/11] MIPS: Alchemy: au1200fb: use clk framework
minimal patch to replace direct clock register hackery with clock framework calls. Signed-off-by: Manuel Lauss --- v2: initial version, new drivers/video/fbdev/au1200fb.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c index 230cfa8..3c8cf71 100644 --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -30,6 +30,7 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include #include #include #include @@ -829,11 +830,19 @@ static void au1200_setpanel(struct panel_settings *newpanel, */ if (!(panel->mode_clkcontrol & LCD_CLKCONTROL_EXT)) { - uint32 sys_clksrc; - AU1X_WRSYS(panel->mode_auxpll, AU1000_SYS_AUXPLL); - sys_clksrc = AU1X_RDSYS(AU1000_SYS_CLKSRC) & ~0x001f; - sys_clksrc |= panel->mode_toyclksrc; - AU1X_WRSYS(sys_clksrc, AU1000_SYS_CLKSRC); + struct clk *a, *c = clk_get(NULL, "lcd_intclk"); + + if (!IS_ERR(c)) { + if ((panel->mode_toyclksrc & 7) == 4) { + a = clk_get(NULL, ALCHEMY_AUXPLL_CLK); + if (!IS_ERR(a)) { + clk_set_parent(c, a); + clk_put(a); + } + } + clk_prepare_enable(c); + clk_put(c); + } } /* -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 03/11] MIPS: Alchemy: platform: use clk framework for uarts
Use the clock framework to get the rate of the peripheral clock. Remove the now obsolete get_uart_baud_base function. Signed-off-by: Manuel Lauss --- v2: initial version, taken from original patch #2 arch/mips/alchemy/common/clocks.c | 19 --- arch/mips/alchemy/common/platform.c| 13 - arch/mips/include/asm/mach-au1x00/au1000.h | 2 -- 3 files changed, 12 insertions(+), 22 deletions(-) diff --git a/arch/mips/alchemy/common/clocks.c b/arch/mips/alchemy/common/clocks.c index 35db35b..e77fa9b 100644 --- a/arch/mips/alchemy/common/clocks.c +++ b/arch/mips/alchemy/common/clocks.c @@ -38,7 +38,6 @@ #define AU1000_SRC_CLK 1200 static unsigned int au1x00_clock; /* Hz */ -static unsigned long uart_baud_base; /* * Set the au1000_clock @@ -55,21 +54,6 @@ unsigned int get_au1x00_speed(void) EXPORT_SYMBOL(get_au1x00_speed); /* - * The UART baud base is not known at compile time ... if - * we want to be able to use the same code on different - * speed CPUs. - */ -unsigned long get_au1x00_uart_baud_base(void) -{ - return uart_baud_base; -} - -void set_au1x00_uart_baud_base(unsigned long new_baud_base) -{ - uart_baud_base = new_baud_base; -} - -/* * We read the real processor speed from the PLL. This is important * because it is more accurate than computing it from the 32 KHz * counter, if it exists. If we don't have an accurate processor @@ -96,9 +80,6 @@ unsigned long au1xxx_calc_clock(void) /* On Alchemy CPU:counter ratio is 1:1 */ mips_hpt_frequency = cpu_speed; - /* Equation: Baudrate = CPU / (SD * 2 * CLKDIV * 16) */ - set_au1x00_uart_baud_base(cpu_speed / - (2 * ((AU1X_RDSYS(AU1000_SYS_POWERCTRL) & 0x03) + 2) * 16)); set_au1x00_speed(cpu_speed); diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c index 4cdc8fd..e70d5c1 100644 --- a/arch/mips/alchemy/common/platform.c +++ b/arch/mips/alchemy/common/platform.c @@ -11,6 +11,7 @@ * warranty of any kind, whether express or implied. */ +#include #include #include #include @@ -99,10 +100,20 @@ static struct platform_device au1xx0_uart_device = { static void __init alchemy_setup_uarts(int ctype) { - unsigned int uartclk = get_au1x00_uart_baud_base() * 16; + long uartclk; int s = sizeof(struct plat_serial8250_port); int c = alchemy_get_uarts(ctype); struct plat_serial8250_port *ports; + struct clk *clk = clk_get(NULL, ALCHEMY_PERIPH_CLK); + + if (IS_ERR(clk)) + return; + if (clk_prepare_enable(clk)) { + clk_put(clk); + return; + } + uartclk = clk_get_rate(clk); + clk_put(clk); ports = kzalloc(s * (c + 1), GFP_KERNEL); if (!ports) { diff --git a/arch/mips/include/asm/mach-au1x00/au1000.h b/arch/mips/include/asm/mach-au1x00/au1000.h index 734b4ac..46ce1fe 100644 --- a/arch/mips/include/asm/mach-au1x00/au1000.h +++ b/arch/mips/include/asm/mach-au1x00/au1000.h @@ -829,8 +829,6 @@ static inline int alchemy_get_macs(int type) /* arch/mips/au1000/common/clocks.c */ extern void set_au1x00_speed(unsigned int new_freq); extern unsigned int get_au1x00_speed(void); -extern void set_au1x00_uart_baud_base(unsigned long new_baud_base); -extern unsigned long get_au1x00_uart_baud_base(void); extern unsigned long au1xxx_calc_clock(void); /* PM: arch/mips/alchemy/common/sleeper.S, power.c, irq.c */ -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 07/11] MIPS: Alchemy: irda: use clk framework
Test the existence of the irda_clk clock object, use it to en/dis- able it when date is being transferred. Signed-off-by: Manuel Lauss --- drivers/net/irda/au1k_ir.c | 48 -- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/drivers/net/irda/au1k_ir.c b/drivers/net/irda/au1k_ir.c index 5f91e3e..aab2cf7 100644 --- a/drivers/net/irda/au1k_ir.c +++ b/drivers/net/irda/au1k_ir.c @@ -18,6 +18,7 @@ * with this program; if not, see <http://www.gnu.org/licenses/>. */ +#include #include #include #include @@ -175,6 +176,7 @@ struct au1k_private { struct resource *ioarea; struct au1k_irda_platform_data *platdata; + struct clk *irda_clk; }; static int qos_mtt_bits = 0x07; /* 1 ms or more */ @@ -514,9 +516,39 @@ static irqreturn_t au1k_irda_interrupt(int dummy, void *dev_id) static int au1k_init(struct net_device *dev) { struct au1k_private *aup = netdev_priv(dev); - u32 enable, ring_address; + u32 enable, ring_address, phyck; + struct clk *c; int i; + c = clk_get(NULL, "irda_clk"); + if (IS_ERR(c)) + return PTR_ERR(c); + i = clk_prepare_enable(c); + if (i) { + clk_put(c); + return i; + } + + switch (clk_get_rate(c)) { + case 4000: + phyck = IR_PHYCLK_40MHZ; + break; + case 4800: + phyck = IR_PHYCLK_48MHZ; + break; + case 5600: + phyck = IR_PHYCLK_56MHZ; + break; + case 6400: + phyck = IR_PHYCLK_64MHZ; + break; + default: + clk_disable_unprepare(c); + clk_put(c); + return -EINVAL; + } + aup->irda_clk = c; + enable = IR_HC | IR_CE | IR_C; #ifndef CONFIG_CPU_LITTLE_ENDIAN enable |= IR_BE; @@ -545,7 +577,7 @@ static int au1k_init(struct net_device *dev) irda_write(aup, IR_RING_SIZE, (RING_SIZE_64 << 8) | (RING_SIZE_64 << 12)); - irda_write(aup, IR_CONFIG_2, IR_PHYCLK_48MHZ | IR_ONE_PIN); + irda_write(aup, IR_CONFIG_2, phyck | IR_ONE_PIN); irda_write(aup, IR_RING_ADDR_CMPR, 0); au1k_irda_set_speed(dev, 9600); @@ -619,6 +651,9 @@ static int au1k_irda_stop(struct net_device *dev) free_irq(aup->irq_tx, dev); free_irq(aup->irq_rx, dev); + clk_disable_unprepare(aup->irda_clk); + clk_put(aup->irda_clk); + return 0; } @@ -853,6 +888,7 @@ static int au1k_irda_probe(struct platform_device *pdev) struct au1k_private *aup; struct net_device *dev; struct resource *r; + struct clk *c; int err; dev = alloc_irdadev(sizeof(struct au1k_private)); @@ -886,6 +922,14 @@ static int au1k_irda_probe(struct platform_device *pdev) if (!aup->ioarea) goto out; + /* bail out early if clock doesn't exist */ + c = clk_get(NULL, "irda_clk"); + if (IS_ERR(c)) { + err = PTR_ERR(c); + goto out; + } + clk_put(c); + aup->iobase = ioremap_nocache(r->start, resource_size(r)); if (!aup->iobase) goto out2; -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 00/11] MIPS: Alchemy: clock framework support
Hello, Here's another round of patches which expose the configurable parts of the onchip clocktree of Alchemy SoCs to the common clock framework. v2: split original patch #2 into a clock framework patch and multiple driver adjustment patches, suggested by Mike Turquette. patch #1 is a big(ger) cleanup of the au1000.h header which presented itself during preparation of the other patches. It's required for the others to compile. patch #2 adds the clock framework integration, patches #3-#11 adjust various setup files and drivers to use the clock framework to get at required clocks and frequencies. The whole series has been tested on DB1300 and DB1500 boards (i.e. the newest variant and an older one with the inflexible dividers), every- thing works as before. Example clock tree dumps: All clocks listed here have been set up by firmware. db1300 ~ # cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy root_clk 331200 0 auxpll2_clk 11 75600 0 fg5_clk00 25200 0 maebsa_clk 00 25200 0 fg4_clk00 18900 0 maempe_clk 00 18900 0 fg3_clk00 25200 0 gpemgp_clk 00 25200 0 fg2_clk11 18900 0 EXTCLK1 114725 0 fg1_clk00 75600 0 fg0_clk00 75600 0 auxpll_clk11 19200 0 EXTCLK000 19200 0 lcd_intclk 119600 0 cpu_clk 11 66000 0 sysbus_clk 11 33000 0 mem_clk 00 33000 0 periph_clk 33 16500 0 lr_clk 00 16500 0 db1500 ~ # cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy root_clk 221200 0 auxpll_clk22 38400 0 EXTCLK100 38400 0 EXTCLK000 38400 0 fg2_clk116400 0 pci_clko116400 0 fg1_clk119600 0 usbh_clk114800 0 usbd_clk004800 0 cpu_clk 11 39600 0 fg5_clk00 19800 0 fg4_clk00 19800 0 fg3_clk00 19800 0 fg0_clk00 19800 0 sysbus_clk 11 19800 0 mem_clk 009900 0 periph_clk 119900 0 lr_clk 009900 0 Feedback very much appreciated! Thank you, Manuel Lauss Manuel Lauss (11): MIPS: Alchemy: au1000 header file cleanup MIPS: Alchemy: clock framework integration of onchip clocks MIPS: Alchemy: platform: use clk framework for uarts MIPS: Alchemy: usb: use clk framework MIPS: Alchemy: pci: use clk framework to enable PCI clock MIPS: Alchemy: db1200: use clk framework MIPS: Alchemy: irda: use clk framework MIPS: Alchemy: au1100fb: use clk framework MIPS: Alchemy: au1200fb: use clk framework MIPS: Alchemy: au1xmmc: use clk framework MIPS: Alchemy: remove old clock support arch/mips/Kconfig
[RFC PATCH v2 00/11] MIPS: Alchemy: clock framework support
Hello, Here's another round of patches which expose the configurable parts of the onchip clocktree of Alchemy SoCs to the common clock framework. v2: split original patch #2 into a clock framework patch and multiple driver adjustment patches, suggested by Mike Turquette. patch #1 is a big(ger) cleanup of the au1000.h header which presented itself during preparation of the other patches. It's required for the others to compile. patch #2 adds the clock framework integration, patches #3-#11 adjust various setup files and drivers to use the clock framework to get at required clocks and frequencies. The whole series has been tested on DB1300 and DB1500 boards (i.e. the newest variant and an older one with the inflexible dividers), every- thing works as before. Example clock tree dumps: All clocks listed here have been set up by firmware. db1300 ~ # cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy root_clk 331200 0 auxpll2_clk 11 75600 0 fg5_clk00 25200 0 maebsa_clk 00 25200 0 fg4_clk00 18900 0 maempe_clk 00 18900 0 fg3_clk00 25200 0 gpemgp_clk 00 25200 0 fg2_clk11 18900 0 EXTCLK1 114725 0 fg1_clk00 75600 0 fg0_clk00 75600 0 auxpll_clk11 19200 0 EXTCLK000 19200 0 lcd_intclk 119600 0 cpu_clk 11 66000 0 sysbus_clk 11 33000 0 mem_clk 00 33000 0 periph_clk 33 16500 0 lr_clk 00 16500 0 db1500 ~ # cat /sys/kernel/debug/clk/clk_summary clock enable_cnt prepare_cntrate accuracy root_clk 221200 0 auxpll_clk22 38400 0 EXTCLK100 38400 0 EXTCLK000 38400 0 fg2_clk116400 0 pci_clko116400 0 fg1_clk119600 0 usbh_clk114800 0 usbd_clk004800 0 cpu_clk 11 39600 0 fg5_clk00 19800 0 fg4_clk00 19800 0 fg3_clk00 19800 0 fg0_clk00 19800 0 sysbus_clk 11 19800 0 mem_clk 009900 0 periph_clk 119900 0 lr_clk 009900 0 Feedback very much appreciated! Thank you, Manuel Lauss Manuel Lauss (11): MIPS: Alchemy: au1000 header file cleanup MIPS: Alchemy: clock framework integration of onchip clocks MIPS: Alchemy: platform: use clk framework for uarts MIPS: Alchemy: usb: use clk framework MIPS: Alchemy: pci: use clk framework to enable PCI clock MIPS: Alchemy: db1200: use clk framework MIPS: Alchemy: irda: use clk framework MIPS: Alchemy: au1100fb: use clk framework MIPS: Alchemy: au1200fb: use clk framework MIPS: Alchemy: au1xmmc: use clk framework MIPS: Alchemy: remove old clock support arch/mips/Kconfig
[RFC PATCH v2 07/11] MIPS: Alchemy: irda: use clk framework
Test the existence of the irda_clk clock object, use it to en/dis- able it when date is being transferred. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- drivers/net/irda/au1k_ir.c | 48 -- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/drivers/net/irda/au1k_ir.c b/drivers/net/irda/au1k_ir.c index 5f91e3e..aab2cf7 100644 --- a/drivers/net/irda/au1k_ir.c +++ b/drivers/net/irda/au1k_ir.c @@ -18,6 +18,7 @@ * with this program; if not, see http://www.gnu.org/licenses/. */ +#include linux/clk.h #include linux/module.h #include linux/netdevice.h #include linux/interrupt.h @@ -175,6 +176,7 @@ struct au1k_private { struct resource *ioarea; struct au1k_irda_platform_data *platdata; + struct clk *irda_clk; }; static int qos_mtt_bits = 0x07; /* 1 ms or more */ @@ -514,9 +516,39 @@ static irqreturn_t au1k_irda_interrupt(int dummy, void *dev_id) static int au1k_init(struct net_device *dev) { struct au1k_private *aup = netdev_priv(dev); - u32 enable, ring_address; + u32 enable, ring_address, phyck; + struct clk *c; int i; + c = clk_get(NULL, irda_clk); + if (IS_ERR(c)) + return PTR_ERR(c); + i = clk_prepare_enable(c); + if (i) { + clk_put(c); + return i; + } + + switch (clk_get_rate(c)) { + case 4000: + phyck = IR_PHYCLK_40MHZ; + break; + case 4800: + phyck = IR_PHYCLK_48MHZ; + break; + case 5600: + phyck = IR_PHYCLK_56MHZ; + break; + case 6400: + phyck = IR_PHYCLK_64MHZ; + break; + default: + clk_disable_unprepare(c); + clk_put(c); + return -EINVAL; + } + aup-irda_clk = c; + enable = IR_HC | IR_CE | IR_C; #ifndef CONFIG_CPU_LITTLE_ENDIAN enable |= IR_BE; @@ -545,7 +577,7 @@ static int au1k_init(struct net_device *dev) irda_write(aup, IR_RING_SIZE, (RING_SIZE_64 8) | (RING_SIZE_64 12)); - irda_write(aup, IR_CONFIG_2, IR_PHYCLK_48MHZ | IR_ONE_PIN); + irda_write(aup, IR_CONFIG_2, phyck | IR_ONE_PIN); irda_write(aup, IR_RING_ADDR_CMPR, 0); au1k_irda_set_speed(dev, 9600); @@ -619,6 +651,9 @@ static int au1k_irda_stop(struct net_device *dev) free_irq(aup-irq_tx, dev); free_irq(aup-irq_rx, dev); + clk_disable_unprepare(aup-irda_clk); + clk_put(aup-irda_clk); + return 0; } @@ -853,6 +888,7 @@ static int au1k_irda_probe(struct platform_device *pdev) struct au1k_private *aup; struct net_device *dev; struct resource *r; + struct clk *c; int err; dev = alloc_irdadev(sizeof(struct au1k_private)); @@ -886,6 +922,14 @@ static int au1k_irda_probe(struct platform_device *pdev) if (!aup-ioarea) goto out; + /* bail out early if clock doesn't exist */ + c = clk_get(NULL, irda_clk); + if (IS_ERR(c)) { + err = PTR_ERR(c); + goto out; + } + clk_put(c); + aup-iobase = ioremap_nocache(r-start, resource_size(r)); if (!aup-iobase) goto out2; -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 09/11] MIPS: Alchemy: au1200fb: use clk framework
minimal patch to replace direct clock register hackery with clock framework calls. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- v2: initial version, new drivers/video/fbdev/au1200fb.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c index 230cfa8..3c8cf71 100644 --- a/drivers/video/fbdev/au1200fb.c +++ b/drivers/video/fbdev/au1200fb.c @@ -30,6 +30,7 @@ * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include linux/clk.h #include linux/module.h #include linux/platform_device.h #include linux/kernel.h @@ -829,11 +830,19 @@ static void au1200_setpanel(struct panel_settings *newpanel, */ if (!(panel-mode_clkcontrol LCD_CLKCONTROL_EXT)) { - uint32 sys_clksrc; - AU1X_WRSYS(panel-mode_auxpll, AU1000_SYS_AUXPLL); - sys_clksrc = AU1X_RDSYS(AU1000_SYS_CLKSRC) ~0x001f; - sys_clksrc |= panel-mode_toyclksrc; - AU1X_WRSYS(sys_clksrc, AU1000_SYS_CLKSRC); + struct clk *a, *c = clk_get(NULL, lcd_intclk); + + if (!IS_ERR(c)) { + if ((panel-mode_toyclksrc 7) == 4) { + a = clk_get(NULL, ALCHEMY_AUXPLL_CLK); + if (!IS_ERR(a)) { + clk_set_parent(c, a); + clk_put(a); + } + } + clk_prepare_enable(c); + clk_put(c); + } } /* -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 03/11] MIPS: Alchemy: platform: use clk framework for uarts
Use the clock framework to get the rate of the peripheral clock. Remove the now obsolete get_uart_baud_base function. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- v2: initial version, taken from original patch #2 arch/mips/alchemy/common/clocks.c | 19 --- arch/mips/alchemy/common/platform.c| 13 - arch/mips/include/asm/mach-au1x00/au1000.h | 2 -- 3 files changed, 12 insertions(+), 22 deletions(-) diff --git a/arch/mips/alchemy/common/clocks.c b/arch/mips/alchemy/common/clocks.c index 35db35b..e77fa9b 100644 --- a/arch/mips/alchemy/common/clocks.c +++ b/arch/mips/alchemy/common/clocks.c @@ -38,7 +38,6 @@ #define AU1000_SRC_CLK 1200 static unsigned int au1x00_clock; /* Hz */ -static unsigned long uart_baud_base; /* * Set the au1000_clock @@ -55,21 +54,6 @@ unsigned int get_au1x00_speed(void) EXPORT_SYMBOL(get_au1x00_speed); /* - * The UART baud base is not known at compile time ... if - * we want to be able to use the same code on different - * speed CPUs. - */ -unsigned long get_au1x00_uart_baud_base(void) -{ - return uart_baud_base; -} - -void set_au1x00_uart_baud_base(unsigned long new_baud_base) -{ - uart_baud_base = new_baud_base; -} - -/* * We read the real processor speed from the PLL. This is important * because it is more accurate than computing it from the 32 KHz * counter, if it exists. If we don't have an accurate processor @@ -96,9 +80,6 @@ unsigned long au1xxx_calc_clock(void) /* On Alchemy CPU:counter ratio is 1:1 */ mips_hpt_frequency = cpu_speed; - /* Equation: Baudrate = CPU / (SD * 2 * CLKDIV * 16) */ - set_au1x00_uart_baud_base(cpu_speed / - (2 * ((AU1X_RDSYS(AU1000_SYS_POWERCTRL) 0x03) + 2) * 16)); set_au1x00_speed(cpu_speed); diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c index 4cdc8fd..e70d5c1 100644 --- a/arch/mips/alchemy/common/platform.c +++ b/arch/mips/alchemy/common/platform.c @@ -11,6 +11,7 @@ * warranty of any kind, whether express or implied. */ +#include linux/clk.h #include linux/dma-mapping.h #include linux/etherdevice.h #include linux/init.h @@ -99,10 +100,20 @@ static struct platform_device au1xx0_uart_device = { static void __init alchemy_setup_uarts(int ctype) { - unsigned int uartclk = get_au1x00_uart_baud_base() * 16; + long uartclk; int s = sizeof(struct plat_serial8250_port); int c = alchemy_get_uarts(ctype); struct plat_serial8250_port *ports; + struct clk *clk = clk_get(NULL, ALCHEMY_PERIPH_CLK); + + if (IS_ERR(clk)) + return; + if (clk_prepare_enable(clk)) { + clk_put(clk); + return; + } + uartclk = clk_get_rate(clk); + clk_put(clk); ports = kzalloc(s * (c + 1), GFP_KERNEL); if (!ports) { diff --git a/arch/mips/include/asm/mach-au1x00/au1000.h b/arch/mips/include/asm/mach-au1x00/au1000.h index 734b4ac..46ce1fe 100644 --- a/arch/mips/include/asm/mach-au1x00/au1000.h +++ b/arch/mips/include/asm/mach-au1x00/au1000.h @@ -829,8 +829,6 @@ static inline int alchemy_get_macs(int type) /* arch/mips/au1000/common/clocks.c */ extern void set_au1x00_speed(unsigned int new_freq); extern unsigned int get_au1x00_speed(void); -extern void set_au1x00_uart_baud_base(unsigned long new_baud_base); -extern unsigned long get_au1x00_uart_baud_base(void); extern unsigned long au1xxx_calc_clock(void); /* PM: arch/mips/alchemy/common/sleeper.S, power.c, irq.c */ -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 08/11] MIPS: Alchemy: au1100fb: use clk framework
Use the clock framework to en/disable the clock to the au1100 framebuffer device. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- arch/mips/alchemy/devboards/db1000.c | 14 ++ drivers/video/fbdev/au1100fb.c | 36 ++-- drivers/video/fbdev/au1100fb.h | 1 + 3 files changed, 37 insertions(+), 14 deletions(-) diff --git a/arch/mips/alchemy/devboards/db1000.c b/arch/mips/alchemy/devboards/db1000.c index 6e55bcc..5b4f81b 100644 --- a/arch/mips/alchemy/devboards/db1000.c +++ b/arch/mips/alchemy/devboards/db1000.c @@ -19,6 +19,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include linux/clk.h #include linux/dma-mapping.h #include linux/gpio.h #include linux/init.h @@ -496,6 +497,7 @@ int __init db1000_dev_setup(void) int board = BCSR_WHOAMI_BOARD(bcsr_read(BCSR_WHOAMI)); int c0, c1, d0, d1, s0, s1, flashsize = 32, twosocks = 1; unsigned long pfc; + struct clk *c, *p; if (board == BCSR_WHOAMI_DB1500) { c0 = AU1500_GPIO2_INT; @@ -525,6 +527,18 @@ int __init db1000_dev_setup(void) spi_register_board_info(db1100_spi_info, ARRAY_SIZE(db1100_spi_info)); + /* link LCD clock to AUXPLL */ + p = clk_get(NULL, auxpll_clk); + c = clk_get(NULL, lcd_intclk); + if (!IS_ERR(c) !IS_ERR(p)) { + clk_set_parent(c, p); + clk_set_rate(c, clk_get_rate(p)); + } + if (!IS_ERR(c)) + clk_put(c); + if (!IS_ERR(p)) + clk_put(p); + platform_add_devices(db1100_devs, ARRAY_SIZE(db1100_devs)); platform_device_register(db1100_spi_dev); } else if (board == BCSR_WHOAMI_DB1000) { diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c index 2c2804b..a7145ce 100644 --- a/drivers/video/fbdev/au1100fb.c +++ b/drivers/video/fbdev/au1100fb.c @@ -41,6 +41,7 @@ * with this program; if not, write to the Free Software Foundation, Inc., * 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include linux/clk.h #include linux/module.h #include linux/kernel.h #include linux/errno.h @@ -434,7 +435,7 @@ static int au1100fb_drv_probe(struct platform_device *dev) struct au1100fb_device *fbdev = NULL; struct resource *regs_res; unsigned long page; - u32 sys_clksrc; + struct clk *c; /* Allocate new device private */ fbdev = devm_kzalloc(dev-dev, sizeof(struct au1100fb_device), @@ -473,6 +474,13 @@ static int au1100fb_drv_probe(struct platform_device *dev) print_dbg(Register memory map at %p, fbdev-regs); print_dbg(phys=0x%08x, size=%d, fbdev-regs_phys, fbdev-regs_len); + c = clk_get(NULL, lcd_intclk); + if (!IS_ERR(c)) { + fbdev-lcdclk = c; + clk_set_rate(c, 4800); + clk_prepare_enable(c); + } + /* Allocate the framebuffer to the maximum screen size * nbr of video buffers */ fbdev-fb_len = fbdev-panel-xres * fbdev-panel-yres * (fbdev-panel-bpp 3) * AU1100FB_NBR_VIDEO_BUFFERS; @@ -506,11 +514,6 @@ static int au1100fb_drv_probe(struct platform_device *dev) print_dbg(Framebuffer memory map at %p, fbdev-fb_mem); print_dbg(phys=0x%08x, size=%dK, fbdev-fb_phys, fbdev-fb_len / 1024); - /* Setup LCD clock to AUX (48 MHz) */ - sys_clksrc = AU1X_RDSYS(AU1000_SYS_CLKSRC) - ~(SYS_CS_ML_MASK | SYS_CS_DL | SYS_CS_CL); - AU1X_WRSYS((sys_clksrc | (1 SYS_CS_ML_BIT)), AU1000_SYS_CLKSRC); - /* load the panel info into the var struct */ au1100fb_var.bits_per_pixel = fbdev-panel-bpp; au1100fb_var.xres = fbdev-panel-xres; @@ -547,6 +550,10 @@ static int au1100fb_drv_probe(struct platform_device *dev) return 0; failed: + if (fbdev-lcdclk) { + clk_disable_unprepare(fbdev-lcdclk); + clk_put(fbdev-lcdclk); + } if (fbdev-fb_mem) { dma_free_noncoherent(dev-dev, fbdev-fb_len, fbdev-fb_mem, fbdev-fb_phys); @@ -577,11 +584,15 @@ int au1100fb_drv_remove(struct platform_device *dev) fb_dealloc_cmap(fbdev-info.cmap); + if (fbdev-lcdclk) { + clk_disable_unprepare(fbdev-lcdclk); + clk_put(fbdev-lcdclk); + } + return 0; } #ifdef CONFIG_PM -static u32 sys_clksrc; static struct au1100fb_regs fbregs; int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state) @@ -591,14 +602,11 @@ int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state) if (!fbdev) return 0; - /* Save the clock source state */ - sys_clksrc = AU1X_RDSYS
[RFC PATCH v2 10/11] MIPS: Alchemy: au1xmmc: use clk framework
Use the clock framework to get the peripheral clock rate to correctly set the MMC/SD bus clock divider. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- drivers/mmc/host/au1xmmc.c | 31 +-- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c index 1837309..0c0ed16 100644 --- a/drivers/mmc/host/au1xmmc.c +++ b/drivers/mmc/host/au1xmmc.c @@ -32,6 +32,7 @@ * (the low to high transition will not occur). */ +#include linux/clk.h #include linux/module.h #include linux/init.h #include linux/platform_device.h @@ -118,6 +119,7 @@ struct au1xmmc_host { struct au1xmmc_platform_data *platdata; struct platform_device *pdev; struct resource *ioarea; + struct clk *clk; }; /* Status flags used by the host structure */ @@ -596,17 +598,10 @@ static void au1xmmc_cmd_complete(struct au1xmmc_host *host, u32 status) static void au1xmmc_set_clock(struct au1xmmc_host *host, int rate) { - unsigned int pbus = get_au1x00_speed(); - unsigned int divisor; + unsigned int pbus = clk_get_rate(host-clk); + unsigned int divisor = ((pbus / rate) / 2) - 1; u32 config; - /* From databook: -* divisor = cpuclock / sbus_divisor) / 2) / mmcclock) / 2) - 1 -*/ - pbus /= ((AU1X_RDSYS(AU1000_SYS_POWERCTRL) 0x3) + 2); - pbus /= 2; - divisor = ((pbus / rate) / 2) - 1; - config = __raw_readl(HOST_CONFIG(host)); config = ~(SD_CONFIG_DIV); @@ -1029,6 +1024,16 @@ static int au1xmmc_probe(struct platform_device *pdev) goto out3; } + host-clk = clk_get(pdev-dev, ALCHEMY_PERIPH_CLK); + if (IS_ERR(host-clk)) { + dev_err(pdev-dev, cannot find clock\n); + goto out_irq; + } + if (clk_prepare_enable(host-clk)) { + dev_err(pdev-dev, cannot enable clock\n); + goto out_clk; + } + host-status = HOST_S_IDLE; /* board-specific carddetect setup, if any */ @@ -1105,7 +1110,10 @@ out5: if (host-platdata host-platdata-cd_setup !(mmc-caps MMC_CAP_NEEDS_POLL)) host-platdata-cd_setup(mmc, 0); - +out_clk: + clk_disable_unprepare(host-clk); + clk_put(host-clk); +out_irq: free_irq(host-irq, host); out3: iounmap((void *)host-iobase); @@ -1147,6 +1155,9 @@ static int au1xmmc_remove(struct platform_device *pdev) au1xmmc_set_power(host, 0); + clk_disable_unprepare(host-clk); + clk_put(host-clk); + free_irq(host-irq, host); iounmap((void *)host-iobase); release_resource(host-ioarea); -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 11/11] MIPS: Alchemy: remove old clock support
With the clock framework in place, remove unused functions and bits. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- arch/mips/alchemy/common/Makefile | 2 +- arch/mips/alchemy/common/clocks.c | 87 -- arch/mips/alchemy/common/setup.c | 15 -- arch/mips/include/asm/mach-au1x00/au1000.h | 68 --- 4 files changed, 1 insertion(+), 171 deletions(-) delete mode 100644 arch/mips/alchemy/common/clocks.c diff --git a/arch/mips/alchemy/common/Makefile b/arch/mips/alchemy/common/Makefile index c8dedcb..f64744f 100644 --- a/arch/mips/alchemy/common/Makefile +++ b/arch/mips/alchemy/common/Makefile @@ -5,7 +5,7 @@ # Makefile for the Alchemy Au1xx0 CPUs, generic files. # -obj-y += prom.o time.o clock.o clocks.o platform.o power.o \ +obj-y += prom.o time.o clock.o platform.o power.o \ setup.o sleeper.o dma.o dbdma.o vss.o irq.o usb.o # optional gpiolib support diff --git a/arch/mips/alchemy/common/clocks.c b/arch/mips/alchemy/common/clocks.c deleted file mode 100644 index e77fa9b..000 --- a/arch/mips/alchemy/common/clocks.c +++ /dev/null @@ -1,87 +0,0 @@ -/* - * BRIEF MODULE DESCRIPTION - * Simple Au1xx0 clocks routines. - * - * Copyright 2001, 2008 MontaVista Software Inc. - * Author: MontaVista Software, Inc. sou...@mvista.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. - * - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN - * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT, - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#include linux/module.h -#include linux/spinlock.h -#include asm/time.h -#include asm/mach-au1x00/au1000.h - -/* - * I haven't found anyone that doesn't use a 12 MHz source clock, - * but just in case. - */ -#define AU1000_SRC_CLK 1200 - -static unsigned int au1x00_clock; /* Hz */ - -/* - * Set the au1000_clock - */ -void set_au1x00_speed(unsigned int new_freq) -{ - au1x00_clock = new_freq; -} - -unsigned int get_au1x00_speed(void) -{ - return au1x00_clock; -} -EXPORT_SYMBOL(get_au1x00_speed); - -/* - * We read the real processor speed from the PLL. This is important - * because it is more accurate than computing it from the 32 KHz - * counter, if it exists. If we don't have an accurate processor - * speed, all of the peripherals that derive their clocks based on - * this advertised speed will introduce error and sometimes not work - * properly. This function is further convoluted to still allow configurations - * to do that in case they have really, really old silicon with a - * write-only PLL register.-- Dan - */ -unsigned long au1xxx_calc_clock(void) -{ - unsigned long cpu_speed; - - /* -* On early Au1000, sys_cpupll was write-only. Since these -* silicon versions of Au1000 are not sold by AMD, we don't bend -* over backwards trying to determine the frequency. -*/ - if (au1xxx_cpu_has_pll_wo()) - cpu_speed = 39600; - else - cpu_speed = (AU1X_RDSYS(AU1000_SYS_CPUPLL) 0x003f) - * AU1000_SRC_CLK; - - /* On Alchemy CPU:counter ratio is 1:1 */ - mips_hpt_frequency = cpu_speed; - - set_au1x00_speed(cpu_speed); - - return cpu_speed; -} diff --git a/arch/mips/alchemy/common/setup.c b/arch/mips/alchemy/common/setup.c index 6f8b91d..f635934 100644 --- a/arch/mips/alchemy/common/setup.c +++ b/arch/mips/alchemy/common/setup.c @@ -27,12 +27,9 @@ #include linux/init.h #include linux/ioport.h -#include linux/jiffies.h -#include linux/module.h #include asm/dma-coherence.h #include asm/mipsregs.h -#include asm/time.h #include asm/mach-au1x00/au1000.h @@ -40,18 +37,6 @@ extern void __init board_setup(void); void __init plat_mem_setup(void) { - unsigned long est_freq; - - /* determine core clock
[RFC PATCH v2 05/11] MIPS: Alchemy: pci: use clk framework to enable PCI clock
Use the clock framework to get at the PCI clock source and enable it on driver initialization. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- arch/mips/pci/pci-alchemy.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/mips/pci/pci-alchemy.c b/arch/mips/pci/pci-alchemy.c index 912c5f2..adc810f 100644 --- a/arch/mips/pci/pci-alchemy.c +++ b/arch/mips/pci/pci-alchemy.c @@ -7,6 +7,7 @@ * Support for all devices (greater than 16) added by David Gathright. */ +#include linux/clk.h #include linux/export.h #include linux/types.h #include linux/pci.h @@ -365,6 +366,7 @@ static int alchemy_pci_probe(struct platform_device *pdev) void __iomem *virt_io; unsigned long val; struct resource *r; + struct clk *c; int ret; /* need at least PCI IRQ mapping table */ @@ -394,11 +396,24 @@ static int alchemy_pci_probe(struct platform_device *pdev) goto out1; } + c = clk_get(pdev-dev, pci_clko); + if (IS_ERR(c)) { + dev_err(pdev-dev, unable to find PCI clock\n); + ret = PTR_ERR(c); + goto out2; + } + ret = clk_prepare_enable(c); + if (ret) { + dev_err(pdev-dev, cannot enable PCI clock\n); + clk_put(c); + goto out2; + } + ctx-regs = ioremap_nocache(r-start, resource_size(r)); if (!ctx-regs) { dev_err(pdev-dev, cannot map pci regs\n); ret = -ENODEV; - goto out2; + goto out5; } /* map parts of the PCI IO area */ @@ -466,12 +481,18 @@ static int alchemy_pci_probe(struct platform_device *pdev) register_syscore_ops(alchemy_pci_pmops); register_pci_controller(ctx-alchemy_pci_ctrl); + dev_info(pdev-dev, PCI controller at %ld MHz\n, +clk_get_rate(c) / 100); + return 0; out4: iounmap(virt_io); out3: iounmap(ctx-regs); +out5: + clk_disable_unprepare(c); + clk_put(c); out2: release_mem_region(r-start, resource_size(r)); out1: -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 06/11] MIPS: Alchemy: db1200: use clk framework
Make use of the clk framework to give us a rate as close to 50MHz as possible. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- arch/mips/alchemy/devboards/db1200.c | 45 1 file changed, 20 insertions(+), 25 deletions(-) diff --git a/arch/mips/alchemy/devboards/db1200.c b/arch/mips/alchemy/devboards/db1200.c index 8c71cde..f255586 100644 --- a/arch/mips/alchemy/devboards/db1200.c +++ b/arch/mips/alchemy/devboards/db1200.c @@ -18,6 +18,7 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include linux/clk.h #include linux/dma-mapping.h #include linux/gpio.h #include linux/i2c.h @@ -129,7 +130,6 @@ static int __init db1200_detect_board(void) int __init db1200_board_setup(void) { - unsigned long freq0, clksrc, div, pfc; unsigned short whoami; if (db1200_detect_board()) @@ -149,30 +149,6 @@ int __init db1200_board_setup(void) Board-ID %d Daughtercard ID %d\n, get_system_type(), (whoami 4) 0xf, (whoami 8) 0xf, whoami 0xf); - /* SMBus/SPI on PSC0, Audio on PSC1 */ - pfc = AU1X_RDSYS(AU1000_SYS_PINFUNC); - pfc = ~(SYS_PINFUNC_P0A | SYS_PINFUNC_P0B); - pfc = ~(SYS_PINFUNC_P1A | SYS_PINFUNC_P1B | SYS_PINFUNC_FS3); - pfc |= SYS_PINFUNC_P1C; /* SPI is configured later */ - AU1X_WRSYS(pfc, AU1000_SYS_PINFUNC); - - /* Clock configurations: PSC0: ~50MHz via Clkgen0, derived from -* CPU clock; all other clock generators off/unused. -*/ - div = (get_au1x00_speed() + 2500) / 5000; - if (div 1) - div++; - div = ((div 1) - 1) 0xff; - - freq0 = div SYS_FC_FRDIV0_BIT; - AU1X_WRSYS(freq0, AU1000_SYS_FREQCTRL0); - freq0 |= SYS_FC_FE0;/* enable F0 */ - AU1X_WRSYS(freq0, AU1000_SYS_FREQCTRL0); - - /* psc0_intclk comes 1:1 from F0 */ - clksrc = SYS_CS_MUX_FQ0 SYS_CS_ME0_BIT; - AU1X_WRSYS(clksrc, AU1000_SYS_CLKSRC); - return 0; } @@ -845,6 +821,7 @@ int __init db1200_dev_setup(void) unsigned long pfc; unsigned short sw; int swapped, bid; + struct clk *c; bid = BCSR_WHOAMI_BOARD(bcsr_read(BCSR_WHOAMI)); if ((bid == BCSR_WHOAMI_PB1200_DDR1) || @@ -857,6 +834,24 @@ int __init db1200_dev_setup(void) irq_set_irq_type(AU1200_GPIO7_INT, IRQ_TYPE_LEVEL_LOW); bcsr_init_irq(DB1200_INT_BEGIN, DB1200_INT_END, AU1200_GPIO7_INT); + /* SMBus/SPI on PSC0, Audio on PSC1 */ + pfc = AU1X_RDSYS(AU1000_SYS_PINFUNC); + pfc = ~(SYS_PINFUNC_P0A | SYS_PINFUNC_P0B); + pfc = ~(SYS_PINFUNC_P1A | SYS_PINFUNC_P1B | SYS_PINFUNC_FS3); + pfc |= SYS_PINFUNC_P1C; /* SPI is configured later */ + AU1X_WRSYS(pfc, AU1000_SYS_PINFUNC); + + /* get 50MHz for I2C driver on PSC0 */ + c = clk_get(NULL, psc0_intclk); + if (!IS_ERR(c)) { + pfc = clk_round_rate(c, 5000); + if ((pfc 1) || (abs(5000 - pfc) 250)) + pr_warn(DB1200: cant get I2C close to 50MHz\n); + else + clk_set_rate(c, pfc); + clk_put(c); + } + /* insert/eject pairs: one of both is always screaming. To avoid * issues they must not be automatically enabled when initially * requested. -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v2 02/11] MIPS: Alchemy: clock framework integration of onchip clocks
This patch introduces common clock framework integration for all configurable on-chip clocks on Alchemy chips: - 2 or 3 PLLs which generate integer multiples of the root rate 12MHz, - 6 dividers which take one of the 3 PLLs as input and divide their rate by either multiples of 2 or 1 (Au1300). - another bank of up to 6 muxes which take either one of the 6 above dividers or one of the PLLs directly and divide their rate further by 1, 2, 3 or 4. - a few other sources which are used by onchip peripherals and are informational. This implementation will take the clock tree as it was set up by boot firmware: all in-kernel boards should continue to work without having to set up the clock tree in board code. CLK_IGNORE_DISABLED will be removed once all drivers have been converted. Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- v2: split into multiple patches, few improvements arch/mips/Kconfig |1 + arch/mips/alchemy/common/Makefile |4 +- arch/mips/alchemy/common/clock.c | 1097 arch/mips/include/asm/mach-au1x00/au1000.h | 16 + 4 files changed, 1116 insertions(+), 2 deletions(-) create mode 100644 arch/mips/alchemy/common/clock.c diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 458608d..86e79de 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -72,6 +72,7 @@ config MIPS_ALCHEMY select SYS_SUPPORTS_APM_EMULATION select ARCH_REQUIRE_GPIOLIB select SYS_SUPPORTS_ZBOOT + select COMMON_CLK config AR7 bool Texas Instruments AR7 diff --git a/arch/mips/alchemy/common/Makefile b/arch/mips/alchemy/common/Makefile index cb83d8d..c8dedcb 100644 --- a/arch/mips/alchemy/common/Makefile +++ b/arch/mips/alchemy/common/Makefile @@ -5,8 +5,8 @@ # Makefile for the Alchemy Au1xx0 CPUs, generic files. # -obj-y += prom.o time.o clocks.o platform.o power.o setup.o \ - sleeper.o dma.o dbdma.o vss.o irq.o usb.o +obj-y += prom.o time.o clock.o clocks.o platform.o power.o \ +setup.o sleeper.o dma.o dbdma.o vss.o irq.o usb.o # optional gpiolib support ifeq ($(CONFIG_ALCHEMY_GPIO_INDIRECT),) diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c new file mode 100644 index 000..f29470b --- /dev/null +++ b/arch/mips/alchemy/common/clock.c @@ -0,0 +1,1097 @@ +/* + * Alchemy clocks. + * + * Exposes all configurable internal clock sources to the clk framework. + * + * We have: + * - Root source, usually 12MHz supplied by an external crystal + * - 3 PLLs which generate multiples of root rate [AUX, CPU, AUX2] + * + * Dividers: + * - 6 clock dividers with: + * * selectable source [one of the PLLs], + * * output divided between [2 .. 512 in steps of 2] (!Au1300) + * or [1 .. 256 in steps of 1] (Au1300), + * * can be enabled individually. + * + * - up to 6 internal (fixed) consumers which: + * * take either AUXPLL or one of the above 6 dividers as input, + * * divide this input by 1, 2, or 4 (and 3 on Au1300). + * * can be disabled separately. + * + * Misc clocks: + * - sysbus clock: CPU core clock (CPUPLL) divided by 2, 3 or 4. + *depends on board design and should be set by bootloader, read-only. + * - peripheral clock: half the rate of sysbus clock, source for a lot + *of peripheral blocks, read-only. + * - memory clock: clk rate to main memory chips, depends on board + *design and is read-only, + * - lrclk: the static bus clock signal for synchronous operation. + *depends on board design, must be set by bootloader, + *but may be required to correctly configure devices attached to + *the static bus. The Au1000/1500/1100 manuals call it LCLK, on + *later models it's called RCLK. + */ + +#include linux/init.h +#include linux/io.h +#include linux/clk-provider.h +#include linux/clkdev.h +#include linux/clk-private.h +#include linux/slab.h +#include linux/spinlock.h +#include linux/types.h +#include asm/mach-au1x00/au1000.h + +/* Base clock: 12MHz is the default in all databooks, and I haven't + * found any board yet which uses a different rate. + */ +#define ALCHEMY_ROOTCLK_RATE 1200 + +/* + * the internal sources which can be driven by the PLLs and dividers. + * Names taken from the databooks, refer to them for more information, + * especially which ones are share a clock line. + */ +static const char * const alchemy_au1300_intclknames[] = { + lcd_intclk, gpemgp_clk, maempe_clk, maebsa_clk, + EXTCLK0, EXTCLK1 +}; + +static const char * const alchemy_au1200_intclknames[] = { + lcd_intclk, NULL, NULL, NULL, EXTCLK0, EXTCLK1 +}; + +static const char * const alchemy_au1550_intclknames[] = { + usb_clk, psc0_intclk, psc1_intclk, pci_clko, + EXTCLK0, EXTCLK1 +}; + +static const char * const alchemy_au1100_intclknames[] = { + usb_clk, lcd_intclk, NULL, i2s_clk, EXTCLK0, EXTCLK1 +}; + +static const char * const alchemy_au1500_intclknames[] = { + NULL
[RFC PATCH v2 04/11] MIPS: Alchemy: usb: use clk framework
Add use of the common clock framework to set and enable the 48MHz clock source for the onchip OHCI and UDC blocks. Tested on a DB1500. (Au1200 and Au1300 use an external 48MHz crystal). Signed-off-by: Manuel Lauss manuel.la...@gmail.com --- v2: taken from initial patch #2 arch/mips/alchemy/common/usb.c | 47 +++--- 1 file changed, 40 insertions(+), 7 deletions(-) diff --git a/arch/mips/alchemy/common/usb.c b/arch/mips/alchemy/common/usb.c index d193dbe..297805a 100644 --- a/arch/mips/alchemy/common/usb.c +++ b/arch/mips/alchemy/common/usb.c @@ -9,6 +9,7 @@ * */ +#include linux/clk.h #include linux/init.h #include linux/io.h #include linux/module.h @@ -387,10 +388,25 @@ static inline void au1200_usb_init(void) udelay(1000); } -static inline void au1000_usb_init(unsigned long rb, int reg) +static inline int au1000_usb_init(unsigned long rb, int reg) { void __iomem *base = (void __iomem *)KSEG1ADDR(rb + reg); unsigned long r = __raw_readl(base); + struct clk *c; + + /* 48MHz check. Don't init if no one can provide it */ + c = clk_get(NULL, usbh_clk); + if (IS_ERR(c)) + return -ENODEV; + if (clk_round_rate(c, 4800) != 4800) { + clk_put(c); + return -ENODEV; + } + if (clk_set_rate(c, 4800)) { + clk_put(c); + return -ENODEV; + } + clk_put(c); #if defined(__BIG_ENDIAN) r |= USBHEN_BE; @@ -400,6 +416,8 @@ static inline void au1000_usb_init(unsigned long rb, int reg) __raw_writel(r, base); wmb(); udelay(1000); + + return 0; } @@ -407,8 +425,15 @@ static inline void __au1xx0_ohci_control(int enable, unsigned long rb, int creg) { void __iomem *base = (void __iomem *)KSEG1ADDR(rb); unsigned long r = __raw_readl(base + creg); + struct clk *c = clk_get(NULL, usbh_clk); + + if (IS_ERR(c)) + return; if (enable) { + if (clk_prepare_enable(c)) + goto out; + __raw_writel(r | USBHEN_CE, base + creg); wmb(); udelay(1000); @@ -423,7 +448,10 @@ static inline void __au1xx0_ohci_control(int enable, unsigned long rb, int creg) } else { __raw_writel(r ~(USBHEN_CE | USBHEN_E), base + creg); wmb(); + clk_disable_unprepare(c); } +out: + clk_put(c); } static inline int au1000_usb_control(int block, int enable, unsigned long rb, @@ -457,11 +485,11 @@ int alchemy_usb_control(int block, int enable) case ALCHEMY_CPU_AU1500: case ALCHEMY_CPU_AU1100: ret = au1000_usb_control(block, enable, - AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); + AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); break; case ALCHEMY_CPU_AU1550: ret = au1000_usb_control(block, enable, - AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); + AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); break; case ALCHEMY_CPU_AU1200: ret = au1200_usb_control(block, enable); @@ -569,14 +597,18 @@ static struct syscore_ops alchemy_usb_pm_ops = { static int __init alchemy_usb_init(void) { + int ret = 0; + switch (alchemy_get_cputype()) { case ALCHEMY_CPU_AU1000: case ALCHEMY_CPU_AU1500: case ALCHEMY_CPU_AU1100: - au1000_usb_init(AU1000_USB_OHCI_PHYS_ADDR, AU1000_OHCICFG); + ret = au1000_usb_init(AU1000_USB_OHCI_PHYS_ADDR, + AU1000_OHCICFG); break; case ALCHEMY_CPU_AU1550: - au1000_usb_init(AU1550_USB_OHCI_PHYS_ADDR, AU1550_OHCICFG); + ret = au1000_usb_init(AU1550_USB_OHCI_PHYS_ADDR, + AU1550_OHCICFG); break; case ALCHEMY_CPU_AU1200: au1200_usb_init(); @@ -586,8 +618,9 @@ static int __init alchemy_usb_init(void) break; } - register_syscore_ops(alchemy_usb_pm_ops); + if (!ret) + register_syscore_ops(alchemy_usb_pm_ops); - return 0; + return ret; } arch_initcall(alchemy_usb_init); -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 05/11] MIPS: Alchemy: pci: use clk framework to enable PCI clock
Hi Sergei, On Thu, Jul 3, 2014 at 3:50 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: --- a/arch/mips/pci/pci-alchemy.c +++ b/arch/mips/pci/pci-alchemy.c @@ -394,11 +396,24 @@ static int alchemy_pci_probe(struct platform_device *pdev) + ret = clk_prepare_enable(c); + if (ret) { + dev_err(pdev-dev, cannot enable PCI clock\n); + clk_put(c); + goto out2; Isn't it simpler to add one more label before clk_put() at end of function? Yes, I have changed it locally. Thank you! Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MIPS: Alchemy: common clock framework integration
Hi Mike, On Wed, Jul 2, 2014 at 7:20 AM, Mike Turquette wrote: > Quoting Manuel Lauss (2014-06-29 09:57:35) >> Expose chip-internal configurable clocks to the common clk framework, >> and fix a few drivers to take advantage of it. > > Thanks for the patch series! Both patches cover a lot of ground, but > I'll focus on #2. It would be best to split the driver changes out I sent the first one along because the second doesn't compile without it. > separately. You can introduce the common clk changes but not compile > them in, then change the drivers, then add the logic to compile the new > common clock driver all as separate patches. I'll split them into pure clock framework and enablement parts. > Additionally, it would be cool to push this driver out to drivers/clk/ > if you are so inclined. It looks like your header dependencies are not > so bad as to make that task impossible. Just a suggestion from me. This clock framework is for a single line of MIPS SoCs which are no longer being developed by the manufacturer and I don't think it is reusable for any other soc line currently in existence. I'd like to keep it within the mips tree for that reason. (I find the ARM way of sprinkling the whole tree with a single driver for each iteration of each custom on-chip peripheral on each ARM chip [exaggerated of course] quite messy. But that's just me). Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] MIPS: Alchemy: common clock framework integration
Hi Mike, On Wed, Jul 2, 2014 at 7:20 AM, Mike Turquette mturque...@linaro.org wrote: Quoting Manuel Lauss (2014-06-29 09:57:35) Expose chip-internal configurable clocks to the common clk framework, and fix a few drivers to take advantage of it. Thanks for the patch series! Both patches cover a lot of ground, but I'll focus on #2. It would be best to split the driver changes out I sent the first one along because the second doesn't compile without it. separately. You can introduce the common clk changes but not compile them in, then change the drivers, then add the logic to compile the new common clock driver all as separate patches. I'll split them into pure clock framework and enablement parts. Additionally, it would be cool to push this driver out to drivers/clk/ if you are so inclined. It looks like your header dependencies are not so bad as to make that task impossible. Just a suggestion from me. This clock framework is for a single line of MIPS SoCs which are no longer being developed by the manufacturer and I don't think it is reusable for any other soc line currently in existence. I'd like to keep it within the mips tree for that reason. (I find the ARM way of sprinkling the whole tree with a single driver for each iteration of each custom on-chip peripheral on each ARM chip [exaggerated of course] quite messy. But that's just me). Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] MIPS: Alchemy: common clk framework integration
This is a request for comments for the below patches. Patch 1 is a cleanup I came up with while writing patch 2. I'm sending it along because the other one depends on some things introduced in it to compile cleanly. Patch 2 adds COMMON_CLK support for all configurable internal clock sources on alchemy socs. Please have a look! Thanks a lot, Manuel Lauss Manuel Lauss (2): MIPS: Alchemy: au1000 header file cleanup MIPS: Alchemy: common clock framework integration arch/mips/Kconfig |1 + arch/mips/alchemy/board-mtx1.c |4 +- arch/mips/alchemy/board-xxs1500.c |4 +- arch/mips/alchemy/common/Makefile |2 +- arch/mips/alchemy/common/clock.c| 1113 ++ arch/mips/alchemy/common/clocks.c | 105 - arch/mips/alchemy/common/dbdma.c| 22 +- arch/mips/alchemy/common/dma.c | 15 +- arch/mips/alchemy/common/irq.c |4 +- arch/mips/alchemy/common/platform.c | 12 +- arch/mips/alchemy/common/power.c| 88 +- arch/mips/alchemy/common/setup.c| 21 +- arch/mips/alchemy/common/time.c | 25 +- arch/mips/alchemy/common/usb.c | 10 + arch/mips/alchemy/devboards/db1000.c| 19 +- arch/mips/alchemy/devboards/db1200.c| 73 +- arch/mips/alchemy/devboards/db1300.c| 10 +- arch/mips/alchemy/devboards/db1550.c| 25 +- arch/mips/alchemy/devboards/pm.c| 39 +- arch/mips/include/asm/mach-au1x00/au1000.h | 2514 ++- arch/mips/include/asm/mach-au1x00/au1000_dma.h | 51 +- arch/mips/include/asm/mach-au1x00/gpio-au1000.h | 66 +- arch/mips/pci/pci-alchemy.c | 85 +- drivers/mmc/host/au1xmmc.c | 194 +- drivers/mtd/nand/au1550nd.c | 52 +- drivers/net/ethernet/amd/au1000_eth.c | 155 +- drivers/net/irda/au1k_ir.c | 48 +- drivers/rtc/rtc-au1xxx.c| 18 +- drivers/spi/spi-au1550.c| 66 +- drivers/video/fbdev/au1100fb.c | 19 +- drivers/video/fbdev/au1200fb.c | 34 +- sound/soc/au1x/psc-ac97.c | 140 +- sound/soc/au1x/psc-i2s.c| 100 +- sound/soc/au1x/psc.h| 22 +- 34 files changed, 3017 insertions(+), 2139 deletions(-) create mode 100644 arch/mips/alchemy/common/clock.c delete mode 100644 arch/mips/alchemy/common/clocks.c -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] MIPS: Alchemy: common clk framework integration
This is a request for comments for the below patches. Patch 1 is a cleanup I came up with while writing patch 2. I'm sending it along because the other one depends on some things introduced in it to compile cleanly. Patch 2 adds COMMON_CLK support for all configurable internal clock sources on alchemy socs. Please have a look! Thanks a lot, Manuel Lauss Manuel Lauss (2): MIPS: Alchemy: au1000 header file cleanup MIPS: Alchemy: common clock framework integration arch/mips/Kconfig |1 + arch/mips/alchemy/board-mtx1.c |4 +- arch/mips/alchemy/board-xxs1500.c |4 +- arch/mips/alchemy/common/Makefile |2 +- arch/mips/alchemy/common/clock.c| 1113 ++ arch/mips/alchemy/common/clocks.c | 105 - arch/mips/alchemy/common/dbdma.c| 22 +- arch/mips/alchemy/common/dma.c | 15 +- arch/mips/alchemy/common/irq.c |4 +- arch/mips/alchemy/common/platform.c | 12 +- arch/mips/alchemy/common/power.c| 88 +- arch/mips/alchemy/common/setup.c| 21 +- arch/mips/alchemy/common/time.c | 25 +- arch/mips/alchemy/common/usb.c | 10 + arch/mips/alchemy/devboards/db1000.c| 19 +- arch/mips/alchemy/devboards/db1200.c| 73 +- arch/mips/alchemy/devboards/db1300.c| 10 +- arch/mips/alchemy/devboards/db1550.c| 25 +- arch/mips/alchemy/devboards/pm.c| 39 +- arch/mips/include/asm/mach-au1x00/au1000.h | 2514 ++- arch/mips/include/asm/mach-au1x00/au1000_dma.h | 51 +- arch/mips/include/asm/mach-au1x00/gpio-au1000.h | 66 +- arch/mips/pci/pci-alchemy.c | 85 +- drivers/mmc/host/au1xmmc.c | 194 +- drivers/mtd/nand/au1550nd.c | 52 +- drivers/net/ethernet/amd/au1000_eth.c | 155 +- drivers/net/irda/au1k_ir.c | 48 +- drivers/rtc/rtc-au1xxx.c| 18 +- drivers/spi/spi-au1550.c| 66 +- drivers/video/fbdev/au1100fb.c | 19 +- drivers/video/fbdev/au1200fb.c | 34 +- sound/soc/au1x/psc-ac97.c | 140 +- sound/soc/au1x/psc-i2s.c| 100 +- sound/soc/au1x/psc.h| 22 +- 34 files changed, 3017 insertions(+), 2139 deletions(-) create mode 100644 arch/mips/alchemy/common/clock.c delete mode 100644 arch/mips/alchemy/common/clocks.c -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Enable interrupts before WAIT instruction.
Hi David, On Thu, May 2, 2013 at 10:48 PM, David Daney wrote: > From: David Daney > > As noted by Thomas Gleixner: > >commit cdbedc61c8 (mips: Use generic idle loop) broke MIPS as I did >not realize that MIPS wants to invoke the wait instructions with >interrupts enabled. > > Instead of enabling interrupts in arch_cpu_idle() as Thomas' initial > patch does, we follow Linus' suggestion of doing it in the assembly > code to prevent the compiler from rearranging things. > > Signed-off-by: David Daney > Reported-by: EunBong Song > Cc: Thomas Gleixner > Cc: Jonas Gorski > --- > > This is only very lightly tested, we need more testing before > declaring it the definitive fix. > > arch/mips/kernel/genex.S | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Unfortunately this patch doesn't work for me, system just hangs at certain points during kernel startup. Reverting the patch above fixes it, but with this warning: ehci-platform ehci-platform.0: irq 98, io mem 0x1402 [ cut here ] WARNING: at /home/mano/db1200/kernel/linux/kernel/cpu/idle.c:96 cpu_startup_entry+0x138/0x184() CPU: 0 PID: 0 Comm: swapper Not tainted 3.9.0-db1235-10522-g6295a89 #2 Stack : 809b4462 0046 80929c20 808c6504 808c3428 80929b27 80929dc8 809b3c04 80093348 807d1000 2cb41780 8011f458 808c4a28 8091fe24 8091fdb0 ... Call Trace: [<8010a1fc>] show_stack+0x64/0x7c [<8011f614>] warn_slowpath_common+0x70/0xa0 [<8011f700>] warn_slowpath_null+0x18/0x28 [<80150464>] cpu_startup_entry+0x138/0x184 [<809658f0>] start_kernel+0x360/0x378 ---[ end trace 19427144468f733d ]--- ehci-platform ehci-platform.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found Thanks, Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: Enable interrupts before WAIT instruction.
Hi David, On Thu, May 2, 2013 at 10:48 PM, David Daney ddaney.c...@gmail.com wrote: From: David Daney david.da...@cavium.com As noted by Thomas Gleixner: commit cdbedc61c8 (mips: Use generic idle loop) broke MIPS as I did not realize that MIPS wants to invoke the wait instructions with interrupts enabled. Instead of enabling interrupts in arch_cpu_idle() as Thomas' initial patch does, we follow Linus' suggestion of doing it in the assembly code to prevent the compiler from rearranging things. Signed-off-by: David Daney david.da...@cavium.com Reported-by: EunBong Song eunb.s...@samsung.com Cc: Thomas Gleixner t...@linutronix.de Cc: Jonas Gorski j...@openwrt.org --- This is only very lightly tested, we need more testing before declaring it the definitive fix. arch/mips/kernel/genex.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) Unfortunately this patch doesn't work for me, system just hangs at certain points during kernel startup. Reverting the patch above fixes it, but with this warning: ehci-platform ehci-platform.0: irq 98, io mem 0x1402 [ cut here ] WARNING: at /home/mano/db1200/kernel/linux/kernel/cpu/idle.c:96 cpu_startup_entry+0x138/0x184() CPU: 0 PID: 0 Comm: swapper Not tainted 3.9.0-db1235-10522-g6295a89 #2 Stack : 809b4462 0046 80929c20 808c6504 808c3428 80929b27 80929dc8 809b3c04 80093348 807d1000 2cb41780 8011f458 808c4a28 8091fe24 8091fdb0 ... Call Trace: [8010a1fc] show_stack+0x64/0x7c [8011f614] warn_slowpath_common+0x70/0xa0 [8011f700] warn_slowpath_null+0x18/0x28 [80150464] cpu_startup_entry+0x138/0x184 [809658f0] start_kernel+0x360/0x378 ---[ end trace 19427144468f733d ]--- ehci-platform ehci-platform.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found Thanks, Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli wrote: > This also greatly simplifies the power_{on,off} callbacks and make them > work on platform device id instead of checking the OHCI controller base > address like what was done in ohci-au1xxx.c. > > Signed-off-by: Florian Fainelli > --- > arch/mips/alchemy/common/platform.c | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/arch/mips/alchemy/common/platform.c > b/arch/mips/alchemy/common/platform.c > index 57335a2..cd12458 100644 > --- a/arch/mips/alchemy/common/platform.c > +++ b/arch/mips/alchemy/common/platform.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -142,6 +143,34 @@ static struct usb_ehci_pdata alchemy_ehci_pdata = { > .power_suspend = alchemy_ehci_power_off, > }; > > +/* Power on callback for the ohci platform driver */ > +static int alchemy_ohci_power_on(struct platform_device *pdev) > +{ > + int unit; > + > + unit = (pdev->id == 1) ? > + ALCHEMY_USB_OHCI1 : ALCHEMY_USB_OHCI0; > + > + return alchemy_usb_control(unit, 1); > +} > + > +/* Power off/suspend callback for the ohci platform driver */ > +static void alchemy_ohci_power_off(struct platform_device *pdev) > +{ > + int unit; > + > + unit = (pdev->id == 1) ? > + ALCHEMY_USB_OHCI1 : ALCHEMY_USB_OHCI0; > + > + alchemy_usb_control(unit, 0); > +} > + > +static struct usb_ohci_pdata alchemy_ohci_pdata = { > + .power_on = alchemy_ohci_power_on, > + .power_off = alchemy_ohci_power_off, > + .power_suspend = alchemy_ohci_power_off, > +}; > + > static unsigned long alchemy_ohci_data[][2] __initdata = { > [ALCHEMY_CPU_AU1000] = { AU1000_USB_OHCI_PHYS_ADDR, > AU1000_USB_HOST_INT }, > [ALCHEMY_CPU_AU1500] = { AU1000_USB_OHCI_PHYS_ADDR, > AU1500_USB_HOST_INT }, > @@ -192,6 +221,7 @@ static void __init alchemy_setup_usb(int ctype) > pdev->name = "au1xxx-ohci"; Should be "ohci-platform" (2x). With this change USB works on all my Alchemy boards. I'd also suggest to move drivers/usb/host/alchemy-common.c to arch/mips/alchemy/common/usb.c. (same for octeon2-common.c) Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:24 PM, Florian Fainelli wrote: > On Wednesday 03 October 2012 17:21:37 Manuel Lauss wrote: >> On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli wrote: >> > This also greatly simplifies the power_{on,off} callbacks and make them >> > work on platform device id instead of checking the OHCI controller base >> > address like what was done in ohci-au1xxx.c. >> >> That was by design -- the base address is far more reliable in identifying > the >> correct controller instance than the platform device id. There are systems >> in the field which don't use the alchemy/common/platform.c file at all. > > Fair enough, but the way it was done previously was very error-prone if the > base address changed for any reason in the platform code, and you did not > notice it had to be changed in the OHCI driver too, then it simply did not Since the Alchemy line is dead this point is moot. > work. By systems in the field you mean out of tree users? If so, I'd say that > it's up to you to get them maintained or merged. I'm not against the patch at all, quite the contrary. Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli wrote: > This also greatly simplifies the power_{on,off} callbacks and make them > work on platform device id instead of checking the OHCI controller base > address like what was done in ohci-au1xxx.c. That was by design -- the base address is far more reliable in identifying the correct controller instance than the platform device id. There are systems in the field which don't use the alchemy/common/platform.c file at all. Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/25] MIPS: Alchemy: use the ehci platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli wrote: > Use the ehci platform driver power_{on,suspend,off} callbacks to perform the > USB block gate enabling/disabling as what the ehci-au1xxx.c driver does. > > Signed-off-by: Florian Fainelli > --- > arch/mips/alchemy/common/platform.c | 23 ++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/arch/mips/alchemy/common/platform.c > b/arch/mips/alchemy/common/platform.c > index c0f3ce6..57335a2 100644 > --- a/arch/mips/alchemy/common/platform.c > +++ b/arch/mips/alchemy/common/platform.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -122,6 +123,25 @@ static void __init alchemy_setup_uarts(int ctype) > static u64 alchemy_ohci_dmamask = DMA_BIT_MASK(32); > static u64 __maybe_unused alchemy_ehci_dmamask = DMA_BIT_MASK(32); > > +/* Power on callback for the ehci platform driver */ > +static int alchemy_ehci_power_on(struct platform_device *pdev) > +{ > + return alchemy_usb_control(ALCHEMY_USB_EHCI0, 1); > +} > + > +/* Power off/suspend callback for the ehci platform driver */ > +static void alchemy_ehci_power_off(struct platform_device *pdev) > +{ > + alchemy_usb_control(ALCHEMY_USB_EHCI0, 0); > +} > + > +static struct usb_ehci_pdata alchemy_ehci_pdata = { > + .need_io_watchdog = 0, This member doesn't exist. Manuel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/25] MIPS: Alchemy: use the ehci platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli flor...@openwrt.org wrote: Use the ehci platform driver power_{on,suspend,off} callbacks to perform the USB block gate enabling/disabling as what the ehci-au1xxx.c driver does. Signed-off-by: Florian Fainelli flor...@openwrt.org --- arch/mips/alchemy/common/platform.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c index c0f3ce6..57335a2 100644 --- a/arch/mips/alchemy/common/platform.c +++ b/arch/mips/alchemy/common/platform.c @@ -17,6 +17,7 @@ #include linux/platform_device.h #include linux/serial_8250.h #include linux/slab.h +#include linux/usb/ehci_pdriver.h #include asm/mach-au1x00/au1000.h #include asm/mach-au1x00/au1xxx_dbdma.h @@ -122,6 +123,25 @@ static void __init alchemy_setup_uarts(int ctype) static u64 alchemy_ohci_dmamask = DMA_BIT_MASK(32); static u64 __maybe_unused alchemy_ehci_dmamask = DMA_BIT_MASK(32); +/* Power on callback for the ehci platform driver */ +static int alchemy_ehci_power_on(struct platform_device *pdev) +{ + return alchemy_usb_control(ALCHEMY_USB_EHCI0, 1); +} + +/* Power off/suspend callback for the ehci platform driver */ +static void alchemy_ehci_power_off(struct platform_device *pdev) +{ + alchemy_usb_control(ALCHEMY_USB_EHCI0, 0); +} + +static struct usb_ehci_pdata alchemy_ehci_pdata = { + .need_io_watchdog = 0, This member doesn't exist. Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli flor...@openwrt.org wrote: This also greatly simplifies the power_{on,off} callbacks and make them work on platform device id instead of checking the OHCI controller base address like what was done in ohci-au1xxx.c. That was by design -- the base address is far more reliable in identifying the correct controller instance than the platform device id. There are systems in the field which don't use the alchemy/common/platform.c file at all. Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:24 PM, Florian Fainelli flor...@openwrt.org wrote: On Wednesday 03 October 2012 17:21:37 Manuel Lauss wrote: On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli flor...@openwrt.org wrote: This also greatly simplifies the power_{on,off} callbacks and make them work on platform device id instead of checking the OHCI controller base address like what was done in ohci-au1xxx.c. That was by design -- the base address is far more reliable in identifying the correct controller instance than the platform device id. There are systems in the field which don't use the alchemy/common/platform.c file at all. Fair enough, but the way it was done previously was very error-prone if the base address changed for any reason in the platform code, and you did not notice it had to be changed in the OHCI driver too, then it simply did not Since the Alchemy line is dead this point is moot. work. By systems in the field you mean out of tree users? If so, I'd say that it's up to you to get them maintained or merged. I'm not against the patch at all, quite the contrary. Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 24/25] MIPS: Alchemy: use the OHCI platform driver
On Wed, Oct 3, 2012 at 5:03 PM, Florian Fainelli flor...@openwrt.org wrote: This also greatly simplifies the power_{on,off} callbacks and make them work on platform device id instead of checking the OHCI controller base address like what was done in ohci-au1xxx.c. Signed-off-by: Florian Fainelli flor...@openwrt.org --- arch/mips/alchemy/common/platform.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c index 57335a2..cd12458 100644 --- a/arch/mips/alchemy/common/platform.c +++ b/arch/mips/alchemy/common/platform.c @@ -18,6 +18,7 @@ #include linux/serial_8250.h #include linux/slab.h #include linux/usb/ehci_pdriver.h +#include linux/usb/ohci_pdriver.h #include asm/mach-au1x00/au1000.h #include asm/mach-au1x00/au1xxx_dbdma.h @@ -142,6 +143,34 @@ static struct usb_ehci_pdata alchemy_ehci_pdata = { .power_suspend = alchemy_ehci_power_off, }; +/* Power on callback for the ohci platform driver */ +static int alchemy_ohci_power_on(struct platform_device *pdev) +{ + int unit; + + unit = (pdev-id == 1) ? + ALCHEMY_USB_OHCI1 : ALCHEMY_USB_OHCI0; + + return alchemy_usb_control(unit, 1); +} + +/* Power off/suspend callback for the ohci platform driver */ +static void alchemy_ohci_power_off(struct platform_device *pdev) +{ + int unit; + + unit = (pdev-id == 1) ? + ALCHEMY_USB_OHCI1 : ALCHEMY_USB_OHCI0; + + alchemy_usb_control(unit, 0); +} + +static struct usb_ohci_pdata alchemy_ohci_pdata = { + .power_on = alchemy_ohci_power_on, + .power_off = alchemy_ohci_power_off, + .power_suspend = alchemy_ohci_power_off, +}; + static unsigned long alchemy_ohci_data[][2] __initdata = { [ALCHEMY_CPU_AU1000] = { AU1000_USB_OHCI_PHYS_ADDR, AU1000_USB_HOST_INT }, [ALCHEMY_CPU_AU1500] = { AU1000_USB_OHCI_PHYS_ADDR, AU1500_USB_HOST_INT }, @@ -192,6 +221,7 @@ static void __init alchemy_setup_usb(int ctype) pdev-name = au1xxx-ohci; Should be ohci-platform (2x). With this change USB works on all my Alchemy boards. I'd also suggest to move drivers/usb/host/alchemy-common.c to arch/mips/alchemy/common/usb.c. (same for octeon2-common.c) Manuel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mips SMBUS_PSC_BASE compile errors
Hi Jean, On Mon, Feb 18, 2008 at 12:49:47PM +0100, Jean Delvare wrote: > On Mon, 18 Feb 2008 11:21:46 +0100, Manuel Lauss wrote: > > > ... > > > CC arch/mips/au1000/common/platform.o > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:277: > > > error: 'PSC0_BASE_ADDR' undeclared here (not in a function) > > > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:314: > > > warning: no previous prototype for 'au1xxx_platform_init' > > > make[2]: *** [arch/mips/au1000/common/platform.o] Error 1 > > > > Thanks, here's a patch. The db1200/pb1550 defconfigs (+ i2c enabled) compile [...] > As the breakage came through my i2c tree, I guess I am supposed to push > this fix as well? Yes, please do. Thank you! Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mips SMBUS_PSC_BASE compile errors
> ... > CC arch/mips/au1000/common/platform.o > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:277: > error: 'PSC0_BASE_ADDR' undeclared here (not in a function) > /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:314: > warning: no previous prototype for 'au1xxx_platform_init' > make[2]: *** [arch/mips/au1000/common/platform.o] Error 1 Thanks, here's a patch. The db1200/pb1550 defconfigs (+ i2c enabled) compile fine with it: --- >From 0300b5b756561de57e09d49b06f608f2d541c3f3 Mon Sep 17 00:00:00 2001 From: Manuel Lauss <[EMAIL PROTECTED]> Date: Mon, 18 Feb 2008 11:12:20 +0100 Subject: [PATCH] Alchemy: compile fix Commit 8b798c4d16b762d15f4055597ff8d87f73b35552 broke alchemy build, fix it. Pointed out by Adrian Bunk. Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]> --- include/asm-mips/mach-db1x00/db1200.h |1 + include/asm-mips/mach-db1x00/db1x00.h |1 + include/asm-mips/mach-pb1x00/pb1200.h |1 + include/asm-mips/mach-pb1x00/pb1550.h |1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-mips/mach-db1x00/db1200.h b/include/asm-mips/mach-db1x00/db1200.h index 050eae8..a6bdac6 100644 --- a/include/asm-mips/mach-db1x00/db1200.h +++ b/include/asm-mips/mach-db1x00/db1200.h @@ -25,6 +25,7 @@ #define __ASM_DB1200_H #include +#include // This is defined in au1000.h with bogus value #undef AU1X00_EXTERNAL_INT diff --git a/include/asm-mips/mach-db1x00/db1x00.h b/include/asm-mips/mach-db1x00/db1x00.h index 0f5f4c2..e7a88ba 100644 --- a/include/asm-mips/mach-db1x00/db1x00.h +++ b/include/asm-mips/mach-db1x00/db1x00.h @@ -28,6 +28,7 @@ #ifndef __ASM_DB1X00_H #define __ASM_DB1X00_H +#include #ifdef CONFIG_MIPS_DB1550 diff --git a/include/asm-mips/mach-pb1x00/pb1200.h b/include/asm-mips/mach-pb1x00/pb1200.h index d9f384a..ed5fd73 100644 --- a/include/asm-mips/mach-pb1x00/pb1200.h +++ b/include/asm-mips/mach-pb1x00/pb1200.h @@ -25,6 +25,7 @@ #define __ASM_PB1200_H #include +#include // This is defined in au1000.h with bogus value #undef AU1X00_EXTERNAL_INT diff --git a/include/asm-mips/mach-pb1x00/pb1550.h b/include/asm-mips/mach-pb1x00/pb1550.h index 9a4955c..c2ab0e2 100644 --- a/include/asm-mips/mach-pb1x00/pb1550.h +++ b/include/asm-mips/mach-pb1x00/pb1550.h @@ -28,6 +28,7 @@ #define __ASM_PB1550_H #include +#include #define DBDMA_AC97_TX_CHAN DSCR_CMD0_PSC1_TX #define DBDMA_AC97_RX_CHAN DSCR_CMD0_PSC1_RX -- 1.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mips SMBUS_PSC_BASE compile errors
... CC arch/mips/au1000/common/platform.o /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:277: error: 'PSC0_BASE_ADDR' undeclared here (not in a function) /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:314: warning: no previous prototype for 'au1xxx_platform_init' make[2]: *** [arch/mips/au1000/common/platform.o] Error 1 Thanks, here's a patch. The db1200/pb1550 defconfigs (+ i2c enabled) compile fine with it: --- From 0300b5b756561de57e09d49b06f608f2d541c3f3 Mon Sep 17 00:00:00 2001 From: Manuel Lauss [EMAIL PROTECTED] Date: Mon, 18 Feb 2008 11:12:20 +0100 Subject: [PATCH] Alchemy: compile fix Commit 8b798c4d16b762d15f4055597ff8d87f73b35552 broke alchemy build, fix it. Pointed out by Adrian Bunk. Signed-off-by: Manuel Lauss [EMAIL PROTECTED] --- include/asm-mips/mach-db1x00/db1200.h |1 + include/asm-mips/mach-db1x00/db1x00.h |1 + include/asm-mips/mach-pb1x00/pb1200.h |1 + include/asm-mips/mach-pb1x00/pb1550.h |1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-mips/mach-db1x00/db1200.h b/include/asm-mips/mach-db1x00/db1200.h index 050eae8..a6bdac6 100644 --- a/include/asm-mips/mach-db1x00/db1200.h +++ b/include/asm-mips/mach-db1x00/db1200.h @@ -25,6 +25,7 @@ #define __ASM_DB1200_H #include linux/types.h +#include asm/mach-au1x00/au1xxx_psc.h // This is defined in au1000.h with bogus value #undef AU1X00_EXTERNAL_INT diff --git a/include/asm-mips/mach-db1x00/db1x00.h b/include/asm-mips/mach-db1x00/db1x00.h index 0f5f4c2..e7a88ba 100644 --- a/include/asm-mips/mach-db1x00/db1x00.h +++ b/include/asm-mips/mach-db1x00/db1x00.h @@ -28,6 +28,7 @@ #ifndef __ASM_DB1X00_H #define __ASM_DB1X00_H +#include asm/mach-au1x00/au1xxx_psc.h #ifdef CONFIG_MIPS_DB1550 diff --git a/include/asm-mips/mach-pb1x00/pb1200.h b/include/asm-mips/mach-pb1x00/pb1200.h index d9f384a..ed5fd73 100644 --- a/include/asm-mips/mach-pb1x00/pb1200.h +++ b/include/asm-mips/mach-pb1x00/pb1200.h @@ -25,6 +25,7 @@ #define __ASM_PB1200_H #include linux/types.h +#include asm/mach-au1x00/au1xxx_psc.h // This is defined in au1000.h with bogus value #undef AU1X00_EXTERNAL_INT diff --git a/include/asm-mips/mach-pb1x00/pb1550.h b/include/asm-mips/mach-pb1x00/pb1550.h index 9a4955c..c2ab0e2 100644 --- a/include/asm-mips/mach-pb1x00/pb1550.h +++ b/include/asm-mips/mach-pb1x00/pb1550.h @@ -28,6 +28,7 @@ #define __ASM_PB1550_H #include linux/types.h +#include asm/mach-au1x00/au1xxx_psc.h #define DBDMA_AC97_TX_CHAN DSCR_CMD0_PSC1_TX #define DBDMA_AC97_RX_CHAN DSCR_CMD0_PSC1_RX -- 1.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mips SMBUS_PSC_BASE compile errors
Hi Jean, On Mon, Feb 18, 2008 at 12:49:47PM +0100, Jean Delvare wrote: On Mon, 18 Feb 2008 11:21:46 +0100, Manuel Lauss wrote: ... CC arch/mips/au1000/common/platform.o /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:277: error: 'PSC0_BASE_ADDR' undeclared here (not in a function) /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/mips/au1000/common/platform.c:314: warning: no previous prototype for 'au1xxx_platform_init' make[2]: *** [arch/mips/au1000/common/platform.o] Error 1 Thanks, here's a patch. The db1200/pb1550 defconfigs (+ i2c enabled) compile [...] As the breakage came through my i2c tree, I guess I am supposed to push this fix as well? Yes, please do. Thank you! Manuel Lauss -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: > Greetings, > > Driver detects card insertion / ejection and sets power properly. The mapping > looks resonable also compairing to a working 2.6.17 driver. > modprobe hostap_cs > hostap_cs: Registered netdevice wifi0 > Unable to handle kernel NULL pointer dereference at virtual address 0028 > pc = 8d0031b8 > *pde = > Oops: [#1] > Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel > > Pid : 283, Comm: modprobe > PC is at generic_inw+0x8/0x20 > PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted > R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 > R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 > R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 > R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 > MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 > > Call trace: > [] prism2_interrupt+0x4a/0xc50 [hostap_cs] The oops output suggests it crashes in drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), specifically when it tries to read the HF384X_SWSUPPORT0_OFF register (which ist at offset 0x28, just like the oopsing address). So, looking at the HFA384X_INW macro, it seems dev->base_addr is NULL. I suspect this is because of set_io_map() callback in the hd64461.c socket driver. The comment there says IO area is statically mapped, yet it returns null; I suggest you let it return the base address of the IO area instead. -- Manuel Lauss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [HD64461_PCMCIA_driver] - Shared IRQ lines / Segfaults
On Wed, Jan 30, 2008 at 01:20:36PM +0100, Kristoffer Ericson wrote: Greetings, Driver detects card insertion / ejection and sets power properly. The mapping looks resonable also compairing to a working 2.6.17 driver. modprobe hostap_cs hostap_cs: Registered netdevice wifi0 Unable to handle kernel NULL pointer dereference at virtual address 0028 pc = 8d0031b8 *pde = Oops: [#1] Modules linked in: hostap_cs hostap orinoco_cs orinoco hermes atmel_cs atmel Pid : 283, Comm: modprobe PC is at generic_inw+0x8/0x20 PC : 8d0031b8 SP : 8ecaba74 SR : 40f0 TEA : c0045040Not tainted R0 : 0028 R1 : 8d2d9030 R2 : 8d2ac050 R3 : 0007 R4 : 0028 R5 : 0002 R6 : 0080 R7 : 8ecf06a0 R8 : 8ee62000 R9 : 8a32 R10 : c002a1b0 R11 : 8ee62000 R12 : 0080 R13 : 8ee62000 R14 : 8ecf06a0 MACH: 458f MACL: 1110 GBR : 296ce450 PR : 8d0031b8 Call trace: [c002a1fa] prism2_interrupt+0x4a/0xc50 [hostap_cs] The oops output suggests it crashes in drivers/net/wireless/hostap/hostap_hw.c::prism2_check_magic(), specifically when it tries to read the HF384X_SWSUPPORT0_OFF register (which ist at offset 0x28, just like the oopsing address). So, looking at the HFA384X_INW macro, it seems dev-base_addr is NULL. I suspect this is because of set_io_map() callback in the hd64461.c socket driver. The comment there says IO area is statically mapped, yet it returns null; I suggest you let it return the base address of the IO area instead. -- Manuel Lauss -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc9-git4: pata_pcmcia, disabling IRQ #9
Hello, Latest git, insert a CF card into cardbus slot gives: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0c-0x0f: excluding 0xc-0xc 0xe-0xf cs: memory probe 0x6000-0x60ff: clean. cs: memory probe 0xa000-0xa0ff: clean. cs: memory probe 0xdea0-0xdeaf: excluding 0xdea0-0xdeaf cs: memory probe 0xff60-0xff6f: excluding 0xff60-0xff60 0xff6a-0xff6d 0xff6f-0xff6f pcmcia: registering new device pcmcia0.0 irq 9: nobody cared (try booting with the "irqpoll" option) [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x15/0x17 [] __report_bad_irq+0x39/0x79 [] note_interrupt+0x1f8/0x234 [] handle_level_irq+0x8e/0xd1 [] do_IRQ+0x92/0xad [] common_interrupt+0x23/0x28 [] handle_level_irq+0x7a/0xd1 [] do_IRQ+0x83/0xad === handlers: [] (acpi_irq+0x0/0x18) [] (yenta_interrupt+0x0/0xb7) [] (usb_hcd_irq+0x0/0x51) [] (usb_hcd_irq+0x0/0x51) [] (usb_hcd_irq+0x0/0x51) [] (snd_intel8x0_interrupt+0x0/0x1e8) [] (e1000_intr+0x0/0xeb) Disabling IRQ #9 scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x irq 9 ata3.00: qc timeout (cmd 0x91) ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4) However, if I rename pata_pcmcia.ko so that udev cannot autoload it, insert the card and manually load pata_pcmcia.ko it works: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0c-0x0f: excluding 0xc-0xc 0xe-0xf cs: memory probe 0x6000-0x60ff: clean. cs: memory probe 0xa000-0xa0ff: clean. cs: memory probe 0xdea0-0xdeaf: excluding 0xdea0-0xdeaf cs: memory probe 0xff60-0xff6f: excluding 0xff60-0xff60 0xff6a-0xff6d 0xff6f-0xff6f pcmcia: registering new device pcmcia0.0 # insmod pata_pcmcia.ko scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x irq 9 ata3.00: CFA: , verB2.10, max PIO2 ata3.00: 507904 sectors, multi 0: LBA ata3.00: configured for PIO0 scsi 2:0:0:0: Direct-Access ATA verB PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 507904 512-byte hardware sectors (260 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 507904 512-byte hardware sectors (260 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 System is a Vaio with ICH4 and TI PCI7420 Cardbus bridge. If you need more info, please don't hesitate to ask. Thank you, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc9-git4: pata_pcmcia, disabling IRQ #9
Hello, Latest git, insert a CF card into cardbus slot gives: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0c-0x0f: excluding 0xc-0xc 0xe-0xf cs: memory probe 0x6000-0x60ff: clean. cs: memory probe 0xa000-0xa0ff: clean. cs: memory probe 0xdea0-0xdeaf: excluding 0xdea0-0xdeaf cs: memory probe 0xff60-0xff6f: excluding 0xff60-0xff60 0xff6a-0xff6d 0xff6f-0xff6f pcmcia: registering new device pcmcia0.0 irq 9: nobody cared (try booting with the irqpoll option) [c01041f2] show_trace_log_lvl+0x1a/0x2f [c01042ed] show_trace+0x12/0x14 [c0104ea0] dump_stack+0x15/0x17 [c0133b48] __report_bad_irq+0x39/0x79 [c0133d80] note_interrupt+0x1f8/0x234 [c0134527] handle_level_irq+0x8e/0xd1 [c0105a6d] do_IRQ+0x92/0xad [c0103f57] common_interrupt+0x23/0x28 [c0134513] handle_level_irq+0x7a/0xd1 [c0105a5e] do_IRQ+0x83/0xad === handlers: [c02a8a38] (acpi_irq+0x0/0x18) [c03268e0] (yenta_interrupt+0x0/0xb7) [c032b1d7] (usb_hcd_irq+0x0/0x51) [c032b1d7] (usb_hcd_irq+0x0/0x51) [c032b1d7] (usb_hcd_irq+0x0/0x51) [c037c08c] (snd_intel8x0_interrupt+0x0/0x1e8) [c02eeaff] (e1000_intr+0x0/0xeb) Disabling IRQ #9 scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x irq 9 ata3.00: qc timeout (cmd 0x91) ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x4) However, if I rename pata_pcmcia.ko so that udev cannot autoload it, insert the card and manually load pata_pcmcia.ko it works: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0c-0x0f: excluding 0xc-0xc 0xe-0xf cs: memory probe 0x6000-0x60ff: clean. cs: memory probe 0xa000-0xa0ff: clean. cs: memory probe 0xdea0-0xdeaf: excluding 0xdea0-0xdeaf cs: memory probe 0xff60-0xff6f: excluding 0xff60-0xff60 0xff6a-0xff6d 0xff6f-0xff6f pcmcia: registering new device pcmcia0.0 # insmod pata_pcmcia.ko scsi2 : pata_pcmcia ata3: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x irq 9 ata3.00: CFA: , verB2.10, max PIO2 ata3.00: 507904 sectors, multi 0: LBA ata3.00: configured for PIO0 scsi 2:0:0:0: Direct-Access ATA verB PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 507904 512-byte hardware sectors (260 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 507904 512-byte hardware sectors (260 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 System is a Vaio with ICH4 and TI PCI7420 Cardbus bridge. If you need more info, please don't hesitate to ask. Thank you, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Investigating SD card failures
Hi Pierre, Thank your for your answer! Pierre Ossman wrote: > On Fri, 27 Jul 2007 07:50:26 +0200 > Manuel Lauss <[EMAIL PROTECTED]> wrote: > >> Hi Pierre, >> >> I have a 1GB SanDisk SD card here which linux does not recognize. >> Looking at the MMC debug output, I see the MMC core repeatedly >> issues CMD55/CMD41 commands (which all succeed!) then stops >> after 100 times. In sd_ops.c the code checks for a bit to get set. >> My question is, what exactly is this bit supposed to indicate? >> > > That the card has initialized. Try extending the time that loop runs and see > if the card powers up. Did that, waited almost 10 seconds, didn't help. I found a printed version of the SD spec; it turned out to be a power supply problem. Apparently the power supply is not strong enough and/or the card very sensitive to power fluctuations; put in another piece of hardware with redesigned power supply the card works fine. Sorry for the noise! Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Investigating SD card failures
Hi Pierre, Thank your for your answer! Pierre Ossman wrote: On Fri, 27 Jul 2007 07:50:26 +0200 Manuel Lauss [EMAIL PROTECTED] wrote: Hi Pierre, I have a 1GB SanDisk SD card here which linux does not recognize. Looking at the MMC debug output, I see the MMC core repeatedly issues CMD55/CMD41 commands (which all succeed!) then stops after 100 times. In sd_ops.c the code checks for a bit to get set. My question is, what exactly is this bit supposed to indicate? That the card has initialized. Try extending the time that loop runs and see if the card powers up. Did that, waited almost 10 seconds, didn't help. I found a printed version of the SD spec; it turned out to be a power supply problem. Apparently the power supply is not strong enough and/or the card very sensitive to power fluctuations; put in another piece of hardware with redesigned power supply the card works fine. Sorry for the noise! Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Investigating SD card failures
Hi Pierre, I have a 1GB SanDisk SD card here which linux does not recognize. Looking at the MMC debug output, I see the MMC core repeatedly issues CMD55/CMD41 commands (which all succeed!) then stops after 100 times. In sd_ops.c the code checks for a bit to get set. My question is, what exactly is this bit supposed to indicate? Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Investigating SD card failures
Hi Pierre, I have a 1GB SanDisk SD card here which linux does not recognize. Looking at the MMC debug output, I see the MMC core repeatedly issues CMD55/CMD41 commands (which all succeed!) then stops after 100 times. In sd_ops.c the code checks for a bit to get set. My question is, what exactly is this bit supposed to indicate? Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Tue, Jul 24, 2007 at 09:56:59PM +0200, Stefan Richter wrote: > Manuel Lauss wrote: > > Actually, copying data to the disk while playing/seeking through a moviefile > > which is also located on it is already enough. Forget the NFS thing... > > > > Afterwards the firewire_sbp2 module has to be rmmod-ed and modprobed again > > or it will continue to throw errors even for single reads. > > > > I hope this helps tracking it down... > > I tried this and similar tests on my main PC (PCIe based) and on an > Athlon/KM266 PC, with 1394b and 1394a hardware. Nothing happened, > except for a single "status write for unknown orb", followed by command > abort from which the disk immediately recovered. I did many tests and > it didn't happen again. I.e. it's probable that the supposed bug > happens here too, but very rarely. I tried 2.6.23 in the meantime, it's *MUCH* harder to trigger; in fact I had to skip through movies for ~10 minutes to get the orb timeout. The disk was inaccessible for a few seconds then recovered fine. > Could you (and everyone else who has repeated I/O errors with the new > drivers, but not with the old drivers) test the attached patches, one > patch at a time? They apply to 2.6.22. Will do. Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Tue, Jul 24, 2007 at 09:56:59PM +0200, Stefan Richter wrote: Manuel Lauss wrote: Actually, copying data to the disk while playing/seeking through a moviefile which is also located on it is already enough. Forget the NFS thing... Afterwards the firewire_sbp2 module has to be rmmod-ed and modprobed again or it will continue to throw errors even for single reads. I hope this helps tracking it down... I tried this and similar tests on my main PC (PCIe based) and on an Athlon/KM266 PC, with 1394b and 1394a hardware. Nothing happened, except for a single status write for unknown orb, followed by command abort from which the disk immediately recovered. I did many tests and it didn't happen again. I.e. it's probable that the supposed bug happens here too, but very rarely. I tried 2.6.23 in the meantime, it's *MUCH* harder to trigger; in fact I had to skip through movies for ~10 minutes to get the orb timeout. The disk was inaccessible for a few seconds then recovered fine. Could you (and everyone else who has repeated I/O errors with the new drivers, but not with the old drivers) test the attached patches, one patch at a time? They apply to 2.6.22. Will do. Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Mon, Jul 23, 2007 at 08:33:36PM +0200, Manuel Lauss wrote: > On Mon, Jul 23, 2007 at 01:34:28PM +0200, Stefan Richter wrote: > > Manuel Lauss wrote: > > > I noticed the failures start when there are 2 concurrent disk accesses > > > (copy something from fw disk on shell 1 and it runs fine; start to > > > copy something TO the fw disk on shell 2 and a "management write failed" > > > error appears after 1-2 sec. with the orb timeout after a looong time) > > > > Most of my tests have been with a single process, but I already tested > > several processes at once in parallel too. But probably only on the > > bigger machine where neither the CPU nor the PCI bus (and this might be > > important) would become a bottleneck. I have to test this again on the > > smaller machines. > > I think I found a way to reliably reproduce the problem (2.6.22) > > NFS-export the fw disk, mount it on another host, put a movie on it, > play it with mplayer on the other machine. Seek a little in the movie, > locks up every time here. If it doesnt, copy data to the disk in parallel. Actually, copying data to the disk while playing/seeking through a moviefile which is also located on it is already enough. Forget the NFS thing... Afterwards the firewire_sbp2 module has to be rmmod-ed and modprobed again or it will continue to throw errors even for single reads. I hope this helps tracking it down... Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Mon, Jul 23, 2007 at 01:34:28PM +0200, Stefan Richter wrote: > Manuel Lauss wrote: > > I noticed the failures start when there are 2 concurrent disk accesses > > (copy something from fw disk on shell 1 and it runs fine; start to > > copy something TO the fw disk on shell 2 and a "management write failed" > > error appears after 1-2 sec. with the orb timeout after a looong time) > > Most of my tests have been with a single process, but I already tested > several processes at once in parallel too. But probably only on the > bigger machine where neither the CPU nor the PCI bus (and this might be > important) would become a bottleneck. I have to test this again on the > smaller machines. I think I found a way to reliably reproduce the problem (2.6.22) NFS-export the fw disk, mount it on another host, put a movie on it, play it with mplayer on the other machine. Seek a little in the movie, locks up every time here. If it doesnt, copy data to the disk in parallel. Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
Hi, On Mon, Jul 23, 2007 at 09:40:21AM +0200, Stefan Richter wrote: > Manuel Lauss wrote: > > I too experience these bugs with the new fw stack; this time with a TI > > OHCI-1394a combo chip in 2 different laptops and a Via 1394 pci addon card. > > The target is a an external hd enclosure with an Oxford Semi chip. > > Thanks for the info. Then there is definitely a driver problem. It is > essential that I (and Kristian) find a way to reproduce it. I noticed the failures start when there are 2 concurrent disk accesses (copy something from fw disk on shell 1 and it runs fine; start to copy something TO the fw disk on shell 2 and a "management write failed" error appears after 1-2 sec. with the orb timeout after a looong time) I didn't investigate it further and switched back to the old stack. Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
Hello, On Mon, Jul 23, 2007 at 01:34:11AM +0200, Stefan Richter wrote: > > Software: > > Kernel Vanilla 2.6.22, gcc 4.1.2. > > > > On another PC same problem, but replugging one or two times get the thing > > working. > > Which controller does this other PC have? I too experience these bugs with the new fw stack; this time with a TI OHCI-1394a combo chip in 2 different laptops and a Via 1394 pci addon card. The target is a an external hd enclosure with an Oxford Semi chip. Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
Hello, On Mon, Jul 23, 2007 at 01:34:11AM +0200, Stefan Richter wrote: massive bugreport snipped Software: Kernel Vanilla 2.6.22, gcc 4.1.2. On another PC same problem, but replugging one or two times get the thing working. Which controller does this other PC have? I too experience these bugs with the new fw stack; this time with a TI OHCI-1394a combo chip in 2 different laptops and a Via 1394 pci addon card. The target is a an external hd enclosure with an Oxford Semi chip. Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
Hi, On Mon, Jul 23, 2007 at 09:40:21AM +0200, Stefan Richter wrote: Manuel Lauss wrote: I too experience these bugs with the new fw stack; this time with a TI OHCI-1394a combo chip in 2 different laptops and a Via 1394 pci addon card. The target is a an external hd enclosure with an Oxford Semi chip. Thanks for the info. Then there is definitely a driver problem. It is essential that I (and Kristian) find a way to reproduce it. I noticed the failures start when there are 2 concurrent disk accesses (copy something from fw disk on shell 1 and it runs fine; start to copy something TO the fw disk on shell 2 and a management write failed error appears after 1-2 sec. with the orb timeout after a looong time) I didn't investigate it further and switched back to the old stack. Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Mon, Jul 23, 2007 at 01:34:28PM +0200, Stefan Richter wrote: Manuel Lauss wrote: I noticed the failures start when there are 2 concurrent disk accesses (copy something from fw disk on shell 1 and it runs fine; start to copy something TO the fw disk on shell 2 and a management write failed error appears after 1-2 sec. with the orb timeout after a looong time) Most of my tests have been with a single process, but I already tested several processes at once in parallel too. But probably only on the bigger machine where neither the CPU nor the PCI bus (and this might be important) would become a bottleneck. I have to test this again on the smaller machines. I think I found a way to reliably reproduce the problem (2.6.22) NFS-export the fw disk, mount it on another host, put a movie on it, play it with mplayer on the other machine. Seek a little in the movie, locks up every time here. If it doesnt, copy data to the disk in parallel. Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] firewire: mass-storage i/o-problems
On Mon, Jul 23, 2007 at 08:33:36PM +0200, Manuel Lauss wrote: On Mon, Jul 23, 2007 at 01:34:28PM +0200, Stefan Richter wrote: Manuel Lauss wrote: I noticed the failures start when there are 2 concurrent disk accesses (copy something from fw disk on shell 1 and it runs fine; start to copy something TO the fw disk on shell 2 and a management write failed error appears after 1-2 sec. with the orb timeout after a looong time) Most of my tests have been with a single process, but I already tested several processes at once in parallel too. But probably only on the bigger machine where neither the CPU nor the PCI bus (and this might be important) would become a bottleneck. I have to test this again on the smaller machines. I think I found a way to reliably reproduce the problem (2.6.22) NFS-export the fw disk, mount it on another host, put a movie on it, play it with mplayer on the other machine. Seek a little in the movie, locks up every time here. If it doesnt, copy data to the disk in parallel. Actually, copying data to the disk while playing/seeking through a moviefile which is also located on it is already enough. Forget the NFS thing... Afterwards the firewire_sbp2 module has to be rmmod-ed and modprobed again or it will continue to throw errors even for single reads. I hope this helps tracking it down... Thanks, Manuel Lauss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc4-mm2
On Thu, Jun 07, 2007 at 06:37:02PM +0900, Paul Mundt wrote: > On Thu, Jun 07, 2007 at 11:19:42AM +0200, Manuel Lauss wrote: > > On Thu, Jun 07, 2007 at 04:11:38PM +0900, Paul Mundt wrote: > > > On Wed, Jun 06, 2007 at 11:42:31PM -0700, William Lee Irwin III wrote: > > > > sound/soc/sh/Kconfig:6:warning: 'select' used by config symbol > > > > 'SND_SOC_PCM_SH7760' refers to undefined symbol 'SH_DMABRG' > > > > --- > > > > Make SND_SOC_PCM_SH7760 depend on SH_DMABRG rather than selecting it > > > > Fixes Kconfig warning about undefined SH_DMABRG symbol on non-sh builds. > > > Are you sure this is the way you want to go? The select here is > reasonably useful. I hope the other people using this code are smart enough to set SH_DMABRG in their board's defconfig. (I seem to remember there was an argument about the evilness of select; and as far as I know I am the only user of this code anyway) If you think select is more useful then I'll send another patch to the alsa folks. Thanks, Manuel Lauss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/