LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 17:59 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437A21EA.5020507@ru.mvista.com>

On Tue, Nov 15, 2005 at 08:59:06PM +0300, Vitaly Bordug wrote:
> Greg KH wrote:
> >On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> >>Hi, Greg!
> >>
> >>While doing "platformization" for one of the Freescale SoC's, I have 
> >>discovered a serious drawback of the model - it prevents registering 
> >>driver with the same name.
> >
> >That's not a "drawback" :)
> >
> >>For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
> >>its device fsl-cpm-scc could (and actually are) utilized in the 
> >>different drivers.
> >>
> >>Those devices will have different bus_id, but pdev->name fields are the 
> >>same for all the fsl-cpm-scc, only id is different there. Hence the 
> >>fsl-cpm-scc could be driver_register'ed only once, while it is required 
> >>several times.
> >
> >A driver is registered only once, but can be bound to multiple devices
> >just fine, right?
> Please let me know, how?

All PCI and USB and I2C drivers are able to bind to multiple devices :)

> I have for instance struct device_driver with name="fsl-cpm-scc" in both 
> fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same device with 
> different id's).
> 
> Once it has been registered in fs_enet, I could not register it in 
> cpm_uart, due to kobject_register fo require unique names in kobject->name. 
> Am I missing something?

You only register the driver once.  The individual devices can be bound
to the same driver, right?

> Not registering it in CPM_UART, how the pdev could be obtained?
> 
> Maybe this is clear, but platform stuff is cumbersome some times...

Then make it cleaner :)

If you have specific code that explains this better, that might help
out.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Russell King @ 2005-11-15 19:06 UTC (permalink / raw)
  To: Andrey Volkov; +Cc: linux-kernel, ML linuxppc-embedded
In-Reply-To: <437A2EE8.4050404@varma-el.com>

On Tue, Nov 15, 2005 at 09:54:32PM +0300, Andrey Volkov wrote:
> Hello Russell,
> 
> I fear it is not a last patch of such kind :(.
> Please recheck places where you are changed
> pdev<->dev.

Either that will have to wait a number of days or someone else will
have to do that.  I'm sorry but I'm rather unwell and in no fit state
to do anything major with kernels atm.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply

* [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Andrey Volkov @ 2005-11-15 18:54 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel, ML linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

Hello Russell,

I fear it is not a last patch of such kind :(.
Please recheck places where you are changed
pdev<->dev.

-- 
Regards
Andrey Volkov


[-- Attachment #2: ohci-ohci-ppc-soc.diff --]
[-- Type: text/plain, Size: 597 bytes --]

Fix copy-paste bug in ohci-ppc-soc.c(ohci_hcd_ppc_soc_drv_remove)

Sign-off-by: Andrey Volkov <avolkov@varma-el.com>
---

diff --git a/drivers/usb/host/ohci-ppc-soc.c b/drivers/usb/host/ohci-ppc-soc.c
index 1875576..2ec6a78 100644
--- a/drivers/usb/host/ohci-ppc-soc.c
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -185,7 +185,7 @@ static int ohci_hcd_ppc_soc_drv_probe(st
 
 static int ohci_hcd_ppc_soc_drv_remove(struct platform_device *pdev)
 {
-	struct usb_hcd *hcd = platform_get_drvdata(dev);
+	struct usb_hcd *hcd = platform_get_drvdata(pdev);
 
 	usb_hcd_ppc_soc_remove(hcd, pdev);
 	return 0;

^ permalink raw reply related

* [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Andrey Volkov @ 2005-11-15 18:53 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel, ML linuxppc-embedded

Hello Russell,

I fear it is not a last patch of such kind :(.
Please recheck places where you are changed
pdev<->dev.

-- 
Regards
Andrey Volkov

^ permalink raw reply

* Re: Linuv 2.6.15-rc1
From: Olaf Hering @ 2005-11-15 18:53 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Linux Kernel Mailing List, ppc-dev list, Linus Torvalds,
	Michael Buesch
In-Reply-To: <1131915560.5504.67.camel@gaston>

 On Mon, Nov 14, Benjamin Herrenschmidt wrote:

> On Sun, 2005-11-13 at 10:37 -0600, Kumar Gala wrote:
> 
> > Can we please add some defconfigs for arch/powerpc to possibly help  
> > with this issue.  I'm think a pmac32, pmac64, and whatever other 64  
> > bit configs would be a good start.
> 
> The 64 bits defconfigs are there already. I'll do a pmac one.

Can you move also arch/ppc64/defconfig into arch/powerpc/configs/?

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

^ permalink raw reply

* Re: Platform device model drawback
From: Vitaly Bordug @ 2005-11-15 17:59 UTC (permalink / raw)
  To: Greg KH; +Cc: linuxppc-embedded list
In-Reply-To: <20051115165532.GB12968@kroah.com>

Greg KH wrote:
> On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
>> Hi, Greg!
>>
>> While doing "platformization" for one of the Freescale SoC's, I have 
>> discovered a serious drawback of the model - it prevents registering 
>> driver with the same name.
> 
> That's not a "drawback" :)
> 
>> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
>> its device fsl-cpm-scc could (and actually are) utilized in the 
>> different drivers.
>>
>> Those devices will have different bus_id, but pdev->name fields are the 
>> same for all the fsl-cpm-scc, only id is different there. Hence the 
>> fsl-cpm-scc could be driver_register'ed only once, while it is required 
>> several times.
> 
> A driver is registered only once, but can be bound to multiple devices
> just fine, right?
Please let me know, how?

I have for instance struct device_driver with name="fsl-cpm-scc" in both fs_enet and 
cpm_uart(one using SCC1, the other - SCC4, the same device with different id's).

Once it has been registered in fs_enet, I could not register it in cpm_uart, due to 
kobject_register fo require unique names in kobject->name. Am I missing something?

Not registering it in CPM_UART, how the pdev could be obtained?

Maybe this is clear, but platform stuff is cumbersome some times...
> 
>> Could you please suggest possible solutions for this situation? This is 
>> relatively common case among freescale chips, so I guess inventing a 
>> workaround is odd, and writing an additional shim to handle CPM device 
>> multiplexing  is odd either.
> 
> I don't see the problem here.  Are you looking at the new stuff in
> 2.6.15-rc1?
> 
Yes, sort of. I am going to add 8xx IRDA and make cpm_uart platform device model compatible.
> thanks,
> 
> greg k-h
> 
> 


-- 
Sincerely,
Vitaly

^ permalink raw reply

* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 16:55 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437A1208.2060804@ru.mvista.com>

On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> Hi, Greg!
> 
> While doing "platformization" for one of the Freescale SoC's, I have 
> discovered a serious drawback of the model - it prevents registering 
> driver with the same name.

That's not a "drawback" :)

> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
> its device fsl-cpm-scc could (and actually are) utilized in the 
> different drivers.
> 
> Those devices will have different bus_id, but pdev->name fields are the 
> same for all the fsl-cpm-scc, only id is different there. Hence the 
> fsl-cpm-scc could be driver_register'ed only once, while it is required 
> several times.

A driver is registered only once, but can be bound to multiple devices
just fine, right?

> Could you please suggest possible solutions for this situation? This is 
> relatively common case among freescale chips, so I guess inventing a 
> workaround is odd, and writing an additional shim to handle CPM device 
> multiplexing  is odd either.

I don't see the problem here.  Are you looking at the new stuff in
2.6.15-rc1?

thanks,

greg k-h

^ permalink raw reply

* [PATCH] powerpc: add new powerbooks to feature table
From: Olof Johansson @ 2005-11-15 17:05 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

Hi,

The previous PowerBook patch didn't contain the feature table updates
for ARCH=powerpc. Here they are.


Signed-off-by: Olof Johansson <olof@lixom.net>


Index: linux-2.6/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/feature.c	2005-11-15 00:05:28.000000000 -0800
+++ linux-2.6/arch/powerpc/platforms/powermac/feature.c	2005-11-15 00:05:59.000000000 -0800
@@ -2362,6 +2362,14 @@ static struct pmac_mb_def pmac_mb_defs[]
 		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
 		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
 	},
+	{	"PowerBook5,8",			"PowerBook G4 15\"",
+		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
+		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+	},
+	{	"PowerBook5,9",			"PowerBook G4 17\"",
+		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
+		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+	},
 	{	"PowerBook6,1",			"PowerBook G4 12\"",
 		PMAC_TYPE_UNKNOWN_INTREPID,	intrepid_features,
 		PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,

^ permalink raw reply

* [PATCH] powerpc: replace page_to_virt() with lowmem_page_address() for Book-E
From: Kumar Gala @ 2005-11-15 17:03 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev, linuxppc-embedded

page_to_virt and lowmem_page_address provided equiavlent functionality
so use the more standard lowmem_page_address

This also addresses build issue in ARCH=powerpc since page_to_virt()
has been removed from include/asm-powerpc/page.h

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

---
commit bd544f8830a563d50d58970c9360379efc555641
tree 887891cdf18bef998f5b5a5ffff9b879ff3591db
parent 1b5b521b837ee0a9366a0750d915e09566229be4
author Kumar Gala <galak@kernel.crashing.org> Tue, 15 Nov 2005 11:03:34 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 15 Nov 2005 11:03:34 -0600

 include/asm-ppc/pgalloc.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-ppc/pgalloc.h b/include/asm-ppc/pgalloc.h
index 931b6de..bdefd1c 100644
--- a/include/asm-ppc/pgalloc.h
+++ b/include/asm-ppc/pgalloc.h
@@ -28,7 +28,7 @@ extern void pgd_free(pgd_t *pgd);
 #define pmd_populate_kernel(mm, pmd, pte)	\
 		(pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
 #define pmd_populate(mm, pmd, pte)	\
-		(pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
+		(pmd_val(*(pmd)) = (unsigned long)lowmem_page_address(pte) | _PMD_PRESENT)
 #endif
 
 extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);

^ permalink raw reply related

* Platform device model drawback
From: Vitaly Bordug @ 2005-11-15 16:51 UTC (permalink / raw)
  To: Greg KH; +Cc: linuxppc-embedded list

Hi, Greg!

While doing "platformization" for one of the Freescale SoC's, I have 
discovered a serious drawback of the model - it prevents registering 
driver with the same name.

For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
its device fsl-cpm-scc could (and actually are) utilized in the 
different drivers.

Those devices will have different bus_id, but pdev->name fields are the 
same for all the fsl-cpm-scc, only id is different there. Hence the 
fsl-cpm-scc could be driver_register'ed only once, while it is required 
several times.

Could you please suggest possible solutions for this situation? This is 
relatively common case among freescale chips, so I guess inventing a 
workaround is odd, and writing an additional shim to handle CPM device 
multiplexing  is odd either.

TIA!
--
Sincerely,
Vitaly

^ permalink raw reply

* Re: [PATCH] powerpc: put page page_to_virt for Book-e processors
From: Kumar Gala @ 2005-11-15 16:45 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051115092042.GA2060@lst.de>

On Tue, 15 Nov 2005, Christoph Hellwig wrote:

> On Mon, Nov 14, 2005 at 05:21:44PM -0600, Kumar Gala wrote:
> > Book-E processors use page_to_virt since we have to always translate.
> 
> Why can't you use the proper page_address() macro?

I really want is lowmem_page_address() since the only current ppc user of
page_to_virt() in include/asm-ppc/pgalloc.h is pmd_populate() for book-e.  
We have to have pages in lowmem.

- kumar

^ permalink raw reply

* Re: MPC8555 USB host support
From: Vitaly Bordug @ 2005-11-15 15:40 UTC (permalink / raw)
  To: Kumar Gala; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D95D5881-250C-4B54-BD5A-54C79D9E0496@kernel.crashing.org>

Kumar Gala wrote:
> Any reason not to get this driver into the kernel main line?
I guess because this device is known to work in some specific instance, 
but bot generic one. The best we can do is to consolidate our efforts to 
make it more usable or state that it is impossible.

> 
> - kumar
> 
> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
> 
>> Hans Schillstrom wrote:
>>
>>> Hi Mike
>>> I'm working with a 8270 board and 2.6.12 kernel and searching for USB
>>> drivers.
>>>
>>> Could you help me finding the files ?
>>>
>> I've opened a project on the SourceForge, 
>> http://cpm2usb.sourceforge.net. The file containing patch against 
>> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb.
>>
>>> I can help you with the testing.
>>> What status do they have right now ?
>>>
>> The driver was developed on MPC8272ADS, but should go as well on 8270 
>> since they have the same USB host controller AFAIK.
>> Currently, as far as I tested it works fine with full-speed single 
>> device attached through hub, but fails is there are transfers from/to 
>> several devices simultaneously.
>> As for the code itself, it's far from being perfect.
>>
>>> Regards Hans
>>>
>>
>>
>> --Sincerely yours,
>> Mike Rapoport
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 


-- 
Sincerely,
Vitaly

^ permalink raw reply

* Re: MPC8555 USB host support
From: Mike Rapoport @ 2005-11-15 15:38 UTC (permalink / raw)
  To: Kumar Gala; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D95D5881-250C-4B54-BD5A-54C79D9E0496@kernel.crashing.org>

Kumar Gala wrote:

> Any reason not to get this driver into the kernel main line?

In my opinion there is a lot of work to be done to get the driver 
upstream. If you'd like to I can clean it up and post a patch here.

>
> - kumar
>
> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
>
>


-- 
Sincerely yours,
Mike Rapoport

^ permalink raw reply

* Re: MPC8555 USB host support
From: Kumar Gala @ 2005-11-15 15:22 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <43798741.5070604@compulab.co.il>

Any reason not to get this driver into the kernel main line?

- kumar

On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:

> Hans Schillstrom wrote:
>
>> Hi Mike
>> I'm working with a 8270 board and 2.6.12 kernel and searching for USB
>> drivers.
>>
>> Could you help me finding the files ?
>>
> I've opened a project on the SourceForge, http:// 
> cpm2usb.sourceforge.net. The file containing patch against 2.6.12.3  
> can be downloaded at http://sourceforge.net/projects/cpm2usb.
>
>> I can help you with the testing.
>> What status do they have right now ?
>>
> The driver was developed on MPC8272ADS, but should go as well on  
> 8270 since they have the same USB host controller AFAIK.
> Currently, as far as I tested it works fine with full-speed single  
> device attached through hub, but fails is there are transfers from/ 
> to several devices simultaneously.
> As for the code itself, it's far from being perfect.
>
>> Regards Hans
>>
>
>
> -- 
> Sincerely yours,
> Mike Rapoport
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: interrupts limit??
From: Mark Chambers @ 2005-11-15 12:40 UTC (permalink / raw)
  To: zjznliang, linuxppc-embedded
In-Reply-To: <20051115054109.CE1FD68763@ozlabs.org>



> Hi ,linuxppc-embedded !
>
>   I have done the interrupt request by request_irq() on the Linux 2.4.25
,when typing the 'cat /proc/interrupts', I can see the information as follow
:
>
> /proc # cat interrupts
>            CPU0
>   2:       3420   8xx SIU   Edge      wbga_interrupt
>   5:          0   8xx SIU   Edge      CPM cascade
>  15:          0   8xx SIU   Edge      tbint
>  16:          0   CPM       Edge      error
>  20:        801   CPM       Edge      SMC1
>
> and I can see the number of wbga_interrupt is increasing. But a few
minutes later ,the number is locked at 128000 as follow:
>
> /proc # cat interrupts
>            CPU0
>   2:     128000   8xx SIU   Edge      wbga_interrupt
>   5:          0   8xx SIU   Edge      CPM cascade
>  15:          0   8xx SIU   Edge      tbint
>  16:          0   CPM       Edge      error
>  20:        833   CPM       Edge      SMC1
>
> and there is no wbga_interrupt any more....what's the matter with the
interrupt?why is 128000???
>
>

The problem is not /proc/interrupts, if that's what you're thinking.  The
number can go much
higher.  Believe what it's telling you:  Your driver has a problem and has
stopped generating
interrupts.

Mark Chambers

^ permalink raw reply

* Re: [PATCH] ppc: Fix boot with yaboot with ARCH=ppc
From: Mikael Pettersson @ 2005-11-15 12:33 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1132039305.5646.17.camel@gaston>

Benjamin Herrenschmidt writes:
 > The merge of machine types broke boot with yaboot & ARCH=ppc due to the
 > old code still retreiving the old-syle machine type passed in by yaboot.
 > This patch fixes it by translating those old numbers. Since that whole
 > mecanism is deprecated, this is a temporary fix until ARCH=ppc uses the
 > new prom_init that the merged architecture now uses for both ppc32 and
 > ppc64 (after 2.6.15)
 > 
 > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

This fixed my eMac, thanks.

Acked-by: Mikael Pettersson <mikpe@csd.uu.se>

 > 
 > Index: linux-work/arch/ppc/kernel/setup.c
 > ===================================================================
 > --- linux-work.orig/arch/ppc/kernel/setup.c	2005-11-15 18:15:23.000000000 +1100
 > +++ linux-work/arch/ppc/kernel/setup.c	2005-11-15 18:18:37.000000000 +1100
 > @@ -602,7 +602,19 @@
 >  #endif /* CONFIG_BLK_DEV_INITRD */
 >  #ifdef CONFIG_PPC_MULTIPLATFORM
 >  		case BI_MACHTYPE:
 > -			_machine = data[0];
 > +			/* Machine types changed with the merge. Since the
 > +			 * bootinfo are now deprecated, we can just hard code
 > +			 * the appropriate conversion here for when we are
 > +			 * called with yaboot which passes us a machine type
 > +			 * this way.
 > +			 */
 > +			switch(data[0]) {
 > +			case 1: _machine = _MACH_prep; break;
 > +			case 2: _machine = _MACH_Pmac; break;
 > +			case 4: _machine = _MACH_chrp; break;
 > +			default:
 > +				_machine = data[0];
 > +			}
 >  			break;
 >  #endif
 >  		case BI_MEMSIZE:
 > 
 > 
 > -
 > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
 > Please read the FAQ at  http://www.tux.org/lkml/
 > 

^ permalink raw reply

* porting linux to new board type
From: Joachim Denil @ 2005-11-15 12:03 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Hi,
 
For an internship I have to port linux to custom made board. I assume I'll
have to set the memory-map right and make the hardware initialize, set IRQ,
.. Browsing trough the kernel source I found that all that happens within
/arch/ppc/platforms and there are separate files for each board. But how do
I start to write my own code. Can someone give me some pointers or is there
any documentation on this subject? This is what my board is made of:
 
*	64 Mb SDRAM (a PLD copy's the kernel to this location (0x00000000))
*	1 MB boot ram (a PLD copy's the boot loader from flash to this
location at the end of the memory map)
*	MMC card reader
*	Flash 8MB (don't have to use it though-> the PLD's use them to copy
boot loader and kernel there)
*	Leds that I can use through a PLD-register
 
The processor is a 405Gr processor, 1 UART is connected to a V24 iface.
The boot loader is a striped version of ppcboot, and is now used to load a
self written RTOS. So I guess I can use that version.
 
Is there besides this something else I 'll have to adjust? 
 
Thanks,
 
Joachim Denil
Student @ Karel De Grote hogeschool Antwerpen (Belgium)

[-- Attachment #2: Type: text/html, Size: 8979 bytes --]

^ permalink raw reply

* Re: MPC8555 USB host support
From: Alexandre BASTOS @ 2005-11-15 12:03 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: linuxppc-embedded
In-Reply-To: <43798741.5070604@compulab.co.il>

Mike,


> I've opened a project on the SourceForge,
> http://cpm2usb.sourceforge.net. The file containing patch against
> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb.
>
> The driver was developed on MPC8272ADS, but should go as well on 8270
> since they have the same USB host controller AFAIK.
> Currently, as far as I tested it works fine with full-speed single
> device attached through hub, but fails is there are transfers from/to
> several devices simultaneously.
> As for the code itself, it's far from being perfect.


I have been testing your cpm2usb driver from sourceforge on my
MPC8272ADS and I couldn't get a usb 2.0 pendrive working.

usbcore tries to identify the device with both schemes, old and
new, but the hcd returns always a timeout. The output from console:

# modprobe usbcore
usbcore: registered new driver usbfs
usbcore: registered new driver hub

# modprobe m82xx-hcd
=> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd.3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd.3: new USB bus registered, assigned bus number 1
usb usb1: Product: PQ2 intergrated USB controller v0.1
usb usb1: Manufacturer: Linux 2.6.12 mpc82xx-hcd
usb usb1: SerialNumber: mpc82xx-hcd.3
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation

[... After pendrive insertion]

usb 1-1: new full speed USB device using mpc82xx-hcd and address 2
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 3
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 4
usb 1-1: device not accepting address 4, error -110
usb 1-1: new full speed USB device using mpc82xx-hcd and address 5
usb 1-1: device not accepting address 5, error -110

To compile the driver as a module, I made only a change in "tx_err"
function from m82xx-hcd.c, which shouldn't be affecting.
I have also commented out the re-definition of BCSR_ADDR, which is
already defined to f4500000 in pq2ads.h

--- m82xx-hcd.c.orig    2005-11-15 12:05:40.547987056 +0100
+++ m82xx-hcd.c 2005-11-14 18:15:13.000000000 +0100
@@ -98,7 +98,7 @@
        hp->usb_clock = USB_CLOCK_PC24_CLK8;

        {
-#define BCSR_ADDR              ((uint)0xf8000000)
+//#define BCSR_ADDR            ((uint)0xf8000000)
        volatile uint* bcsr_usb = (volatile uint*)(BCSR_ADDR +
                                                   BCSR_USB_OFFSET);

@@ -281,7 +281,9 @@
 static void tx_err(struct m8xxhci_private *hp, int ber)
 {
        volatile usbregs_t *usbregs = hp->usbregs;
-       volatile cpm_cpm2_t *cp = cpmp;
+       //volatile cpm_cpm2_t *cp = cpmp;
+       volatile cpm2_map_t *immap = (volatile cpm2_map_t *)CPM_MAP_ADDR;
+       volatile cpm_cpm2_t *cp = &immap->im_cpm;

        if ( hp->active_qe )
                hp->stats.txe[hp->active_qe->qtype]++;

So, any idea which could be happening? I have little knowledge about usb
so I am quite lost.


Thanks.

Alex BASTOS

^ permalink raw reply

* Re: BDI2000 and Linux 2.6 kernel
From: Marcelo Tosatti @ 2005-11-15  5:46 UTC (permalink / raw)
  To: Guillaume Autran; +Cc: support, linux-ppc-embedded
In-Reply-To: <437920D3.8020105@mrv.com>

On Mon, Nov 14, 2005 at 06:42:11PM -0500, Guillaume Autran wrote:
> Hi Marcelo,
> 
> Despite your patch, I'm still having trouble getting my BDI2000 to 
> translate kernel virtual address to physical address on a 2.6.13 kernel.
> 
> What should I look for to make sure I set it up properly ?

Hi Guillaume,

Can you please describe what problems are you having in more detail?

Do you still get "*** MMU: address translation for 0xCxxxxxxx" messages?

^ permalink raw reply

* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Marcelo Tosatti @ 2005-11-15  5:42 UTC (permalink / raw)
  To: Florian Schirmer; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <43798327.70305@tuxbox.org>

Hi Florian!

On Tue, Nov 15, 2005 at 07:41:43AM +0100, Florian Schirmer wrote:
> Hi,
> 
> >Note: From my reading of the documentation, even if the SWRI bit is
> >unset (interrupt select mode), an NMI at IRQ0 should cause the system to
> >jump to exception vector 0x100, resetting the system.
> >
> >So I'm wondering if the interrupt mode ever worked?
> 
> Never tried the interrupt mode. IMHO doesn't make much sense for a 
> watchdog. Why don't you simply set SWRI?

The SYPCR register can be set only _once_ at machine startup and the
bootloader in question does not have an option to change the mode. Many
bootloaders probably dont.

> >+static void m8xx_wdt_timer_func(unsigned long data)
> >+{
> >+	m8xx_wdt_reset();
> >+	m8xx_wdt_timer.expires = jiffies + 25;
> >+	add_timer(&m8xx_wdt_timer);
> >+}
> >+
> >+void m8xx_wdt_install_timer(volatile immap_t *imap)
> >+{
> >+	m8xx_wdt_timer.expires = jiffies + 25;
> >+	add_timer(&m8xx_wdt_timer);
> >+}
> 
> m8xx_wdt_install_timer doesn't need imap and you could call it from 
> m8xx_wdt_timer_func to re-engange the timer resulting in less duplicated 
> code. Just a cosmetic thing though.

Indeed. Will update the patch and resend you for review.

Thanks

^ permalink raw reply

* Re: [PATCH] powerpc: put page page_to_virt for Book-e processors
From: Christoph Hellwig @ 2005-11-15  9:20 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.44.0511141721190.9033-100000@gate.crashing.org>

On Mon, Nov 14, 2005 at 05:21:44PM -0600, Kumar Gala wrote:
> Book-E processors use page_to_virt since we have to always translate.

Why can't you use the proper page_address() macro?

^ permalink raw reply

* [PATCH] ppc: Fix boot with yaboot with ARCH=ppc
From: Benjamin Herrenschmidt @ 2005-11-15  7:21 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list

The merge of machine types broke boot with yaboot & ARCH=ppc due to the
old code still retreiving the old-syle machine type passed in by yaboot.
This patch fixes it by translating those old numbers. Since that whole
mecanism is deprecated, this is a temporary fix until ARCH=ppc uses the
new prom_init that the merged architecture now uses for both ppc32 and
ppc64 (after 2.6.15)

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Index: linux-work/arch/ppc/kernel/setup.c
===================================================================
--- linux-work.orig/arch/ppc/kernel/setup.c	2005-11-15 18:15:23.000000000 +1100
+++ linux-work/arch/ppc/kernel/setup.c	2005-11-15 18:18:37.000000000 +1100
@@ -602,7 +602,19 @@
 #endif /* CONFIG_BLK_DEV_INITRD */
 #ifdef CONFIG_PPC_MULTIPLATFORM
 		case BI_MACHTYPE:
-			_machine = data[0];
+			/* Machine types changed with the merge. Since the
+			 * bootinfo are now deprecated, we can just hard code
+			 * the appropriate conversion here for when we are
+			 * called with yaboot which passes us a machine type
+			 * this way.
+			 */
+			switch(data[0]) {
+			case 1: _machine = _MACH_prep; break;
+			case 2: _machine = _MACH_Pmac; break;
+			case 4: _machine = _MACH_chrp; break;
+			default:
+				_machine = data[0];
+			}
 			break;
 #endif
 		case BI_MEMSIZE:

^ permalink raw reply

* Re: MPC8555 USB host support
From: Mike Rapoport @ 2005-11-15  6:59 UTC (permalink / raw)
  To: Hans Schillstrom; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <1131960060.7748.9.camel@hawk.pwav.net>

Hans Schillstrom wrote:

>Hi Mike
>I'm working with a 8270 board and 2.6.12 kernel and searching for USB
>drivers.
>
>Could you help me finding the files ?
>  
>
I've opened a project on the SourceForge, 
http://cpm2usb.sourceforge.net. The file containing patch against 
2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb.

>I can help you with the testing.
>What status do they have right now ?
>  
>
The driver was developed on MPC8272ADS, but should go as well on 8270 
since they have the same USB host controller AFAIK.
Currently, as far as I tested it works fine with full-speed single 
device attached through hub, but fails is there are transfers from/to 
several devices simultaneously.
As for the code itself, it's far from being perfect.

>Regards 
>Hans
>  
>


-- 
Sincerely yours,
Mike Rapoport

^ permalink raw reply

* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Florian Schirmer @ 2005-11-15  6:41 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051114143821.GA28852@logos.cnet>

Hi,

> Note: From my reading of the documentation, even if the SWRI bit is
> unset (interrupt select mode), an NMI at IRQ0 should cause the system to
> jump to exception vector 0x100, resetting the system.
> 
> So I'm wondering if the interrupt mode ever worked?

Never tried the interrupt mode. IMHO doesn't make much sense for a 
watchdog. Why don't you simply set SWRI?


> +static void m8xx_wdt_timer_func(unsigned long data)
> +{
> +	m8xx_wdt_reset();
> +	m8xx_wdt_timer.expires = jiffies + 25;
> +	add_timer(&m8xx_wdt_timer);
> +}
> +
> +void m8xx_wdt_install_timer(volatile immap_t *imap)
> +{
> +	m8xx_wdt_timer.expires = jiffies + 25;
> +	add_timer(&m8xx_wdt_timer);
> +}

m8xx_wdt_install_timer doesn't need imap and you could call it from 
m8xx_wdt_timer_func to re-engange the timer resulting in less duplicated 
code. Just a cosmetic thing though.

Best,
   Florian

^ permalink raw reply

* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select\
From: Florian Schirmer @ 2005-11-15  6:11 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051114160302.GC29411@logos.cnet>

Hi,

> Actually, drivers/char/watchdog/mpc8xx_wdt.c is a module, while
> some of the initialization code must reside in the kernel image.
> 
> Thats the reason for the split - not sure if merging the two
> files is worth?

If you have a short timeout (like the 2 secs we had) then you need to 
have the handler ready long before the module could be loaded.

Best,
   Florian

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox