Re: arch/mips/alchemy/devboards/db1300.c:(.text.db1300_wm97xx_probe+0x2c): undefined reference to `wm97xx_config_gpio'

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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()

[Manuel Lauss]

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: MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()

[Manuel Lauss]

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()

[Manuel Lauss]

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()

[Manuel Lauss]

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()

[Manuel Lauss]

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] MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci_probe()

[Manuel Lauss]

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)

[Manuel Lauss]

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 v2 07/13] MIPS: mm: Fix MIPS32 36b physical addressing (alchemy, netlogic)

[Manuel Lauss]

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

[Manuel Lauss]

 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: [PATCH] pcmcia: db1xxx: use correct irq_to_gpio helper

[Manuel Lauss]

 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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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: [REGRESSION] 8a3e33cf92c7 "ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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.

[Manuel Lauss]

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.

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

> ...
>   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

[Manuel Lauss]

 ...
   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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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

[Manuel Lauss]

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/