* Re: dtc: RFC: Fix some lexical problems with references
From: Jon Loeliger @ 2007-11-28 19:53 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071122061007.GA22888@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The recent change to the lexer to only recognize property and node
> names in the appropriate context removed a number of lexical warts in
> our language that would have gotten ugly as we add expression support
> and so forth.
>
> But there's one nasty one remaining: references can contain a full
> path, including the various problematic node name characters (',', '+'
> and '-', for example). This would cause trouble with expressions, and
> it also causes trouble with the patch I'm working on to allow
> expanding references to paths rather than phandles. This patch
> therefore reworks the lexer to mitigate these problems.
>
> - References to labels cause no problems. These are now
> recognized separately from references to full paths. No syntax change
> here.
>
> - References to full paths, including problematic characters
> are allowed by "quoting" the path with braces
> e.g. &{/pci@10000/somedevice@3,8000}. The braces protect any internal
> problematic characters from being confused with operators or whatever.
>
> - For compatibility with existing dts files, in v0 dts files
> we allow bare references to paths as before &/foo/bar/whatever - but
> *only* if the path contains no troublesome characters. Specifically
> only [a-zA-Z0-9_@/] are allowed.
>
> This is an incompatible change to the dts-v1 format, but since AFAIK
> no-one has yet switched to dts-v1 files, I think we can get away with
> it. Better to make the transition when people to convert to v1, and
> get rid of the problematic old syntax.
>
> Strictly speaking, it's also an incompatible change to the v0 format,
> since some path references that were allowed before are no longer
> allowed. I suspect no-one has been using the no-longer-supported
> forms (certainly none of the kernel dts files will cause trouble). We
> might need to think about this harder, though.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Benjamin Herrenschmidt @ 2007-11-28 19:52 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: netdev, Kok, Auke-jan H, Jeff Garzik, linuxppc-dev
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203DF7871@orsmsx418.amr.corp.intel.com>
On Wed, 2007-11-28 at 10:47 -0800, Brandeburg, Jesse wrote:
>
> > The side effect is that I removed the assignments to the netdev
> > fields mem_start, mem_end and base_addr, which are totally useless
> > for PCI devices.
>
> also, concerning this, ifconfig shows the output of these variables, I
> don't think we want to blatantly remove them, as it is actually removing
> information that is, if not used, at least displayed to user space.
It's not the right place to have that information and there is no
room in the user space field to fit more than 32 bits on 32 bits
platforms so I'd rather remove it. It's really only for ISA drivers that
have user configurable addresses.
Ben.
^ permalink raw reply
* Re: FW: CRS - #454833 is assigned to Amit Kasat for review by eliasd
From: John Bonesio @ 2007-11-28 19:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C0565CBFB@XCO-EXCHVS1.xlnx.xilinx.com>
Hi Rick,
I just checked more closely. The linux 2.6 mld uses the following directories:
$XILINX_EDK/sw/ThirdParty/bsp/$MLD_version
$XILINX_EDK/sw/XilinxProcessorIPLib/drivers
<project directory>/bsp/$MLD_version
If 'edk_user_repository', is an actual directory name, then it is not used in the Linux MLD.
- John
On Wednesday 28 November 2007 10:15, Rick Moleres wrote:
>
> John,
>
> So, the Linux MLD does use the edk_repository to search for drivers
> etc...?
>
> Thanks,
> Rick
>
> -----Original Message-----
> From: John Bonesio [mailto:jbonesio@xilinx.com]
> Sent: Wednesday, November 28, 2007 10:54 AM
> To: Rick Moleres
> Cc: embedded_ip_sw
> Subject: Re: FW: CRS - #454833 is assigned to Amit Kasat for review by
> eliasd
>
> Hi Rick,
>
> It's possible we may need to change some (all?) of our mld's, but the
> change should be small (on the order of 1-5 lines).
>
> - John
>
> On Wednesday 28 November 2007 08:20, Rick Moleres wrote:
> > All,
> >
> >
> >
> > Does this impact any of our MLDs?
> >
> >
> >
> > Thanks,
> >
> > Rick
> >
> >
> >
> > ________________________________
> >
> > From: Chang Sun
> > Sent: Tuesday, November 27, 2007 6:13 PM
> > To: Amit Kasat; Randy Robinson; Rick Moleres
> > Subject: RE: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> >
> >
> >
> > Hi Amit,
> >
> >
> >
> > I included Rick for this comment/suggestion, since Rick's team has
> been
> > doing most of the RTOS MLD integration work (Linux and VxWorks). Rick
> > should be able to suggest the level of impact by this change.
> >
> > We also have some partners, e.g. Mentor Graphics supporting the MLD
> > integration directly, so I hope this change has no major impact on
> them,
> > assuming we provide them well documented instructions.
> >
> >
> >
> > Thanks,
> >
> > Chang
> >
> > ________________________________
> >
> > From: Amit Kasat
> > Sent: Tuesday, November 27, 2007 2:30 PM
> > To: Randy Robinson; Chang Sun
> > Subject: FW: CRS - #454833 is assigned to Amit Kasat for review by
> > eliasd
> >
> >
> >
> > Hi Randy, Chang:
> >
> >
> >
> > I would like to deprecate this mechanism of automatically reading
> > edk_user_repository if this directory exists at the same level at EDK
> > installation. I believe some of our Board and MLD partners use this
> > mechanism. Going forward, we would like them to use the setting in XPS
> > Gui's
> >
> >
> >
> > Edit -> Preferences -> Application Preferences -> Global Peripheral
> > Repository
> >
> >
> >
> > This is a much better, documented and GUI-supported way of specifiying
> > peripheral repository path that's picked up automatically for all
> > projects.
> >
> >
> >
> > We will need to tell the partners to start using the new mechanism.
> This
> > mechanism gives them the flexibility to use any directory to install
> > their XBD/MLDs and point to it using this setting.
> >
> >
> >
> > The edk_cr_review_team did not have any concerns about it. I just
> wanted
> > to make sure you guys are ok with it too.
> >
> >
> >
> > Thanks,
> >
> > Amit
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: crs@xilinx.com [mailto:crs@xilinx.com]
> >
> > > Sent: Tuesday, November 27, 2007 2:19 PM
> >
> > > To: Amit Kasat
> >
> > > Subject: CRS - #454833 is assigned to Amit Kasat for review by
> eliasd
> >
> > >
> >
> > > http://governator:9089/itg/html/kintanaHome.html
> >
> > >
> >
> > >
> >
> > > CR #: 454833
> >
> > > CR Link:
> >
> > >
> >
> http://governator:9089/itg//web/knta/crt/RequestDetail.jsp?REQUEST_ID=45
> > 48
> >
> > > 33
> >
> > > Created By: Amit Kasat
> >
> > > Creation Date: 20-NOV-07
> >
> > > Description: Deprecate and then remove support of
> > built in
> >
> > > reposiotry - $XILINX_EDK/../edk_user_repository
> >
> > > Status: New
> >
> > > Application: EDK_General
> >
> > > Assigned Group: EDK
> >
> > > Assigned To: Amit Kasat
> >
> > > Priority: 3
> >
> > > Version Found: EDK_K.9
> >
> > > To Be Fixed Version:
> >
> > > Apps Priority: NA
> >
> > > Details: Currently, If a directory named
> >
> > > edk_user_repository is present at the same level as EDK
> isntallation,
> > then
> >
> > > it is automaticaly added to the search path for pcores, drivers etc.
> >
> > > However, in EDK 9.1, we added concept of Global Peripheral
> Repository
> >
> > > which allows users to add such a setting as a preference through the
> > GUI
> >
> > > and make it applicable to all thier projects.
> >
> > >
> >
> > > This is a much cleaner mechanism of handling these search paths. I
> > would
> >
> > > like to deprecate usage of the edk_user_repository from tools in
> EDK_K
> >
> > > (issue a warning) and stop reading it in EDK_L.
> >
> > >
> >
> > > These options are not used much and we woud like to cleanup to
> reduce
> >
> > > testing and corner case issues.
> >
> > >
> >
> ------------------------------------------------------------------------
> > --
> >
> > > ---------------------------
> >
> > > Notes:
> >
> > > Elias Dabbagh(eliasd) November 27, 2007 02:18 PM:
> >
> > > Assigned To to Amit Kasat
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Public Data Directory /public/bugcases to
> >
> > > http://governator:1111/public/bugcases/454000-454999/454833/
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Owner to akasat
> >
> > >
> >
> > > Amit Kasat(akasat) November 20, 2007 03:58 PM:
> >
> > > Request Status Not Submitted to New
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> ========================================================================
> > ==
> >
> > > ==
> >
> > >
> >
> >
> >
> >
>
> --
> +-------------------------------+
> | This space for rent
> +-------------------------------+
>
--
+-------------------------------+
| This space for rent
+-------------------------------+
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 19:36 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071128194321.0804b3aa@i1501.lan.towertech.it>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
>
> mmm. I've been told it should work ;)
>
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
>
> this one must be deselected.
>
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
>
> ditto.
>
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
>
> maybe the wrong driver is kicking in here.
> the fact that there is no rtc class
> related output in dmesg should and that
> there is no /dev/rtc0 could be a sign that the whole class
> is not going in.
>
> do you have full dmesg?
My current
.config as well as the dmesg is attached with your
suggested changes.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: dmesg-fail.txt --]
[-- Type: text/plain, Size: 15334 bytes --]
DEV: registering device: ID = 'tty47'
DEV: registering device: ID = 'tty48'
DEV: registering device: ID = 'tty49'
DEV: registering device: ID = 'tty50'
DEV: registering device: ID = 'tty51'
DEV: registering device: ID = 'tty52'
DEV: registering device: ID = 'tty53'
DEV: registering device: ID = 'tty54'
DEV: registering device: ID = 'tty55'
DEV: registering device: ID = 'tty56'
DEV: registering device: ID = 'tty57'
DEV: registering device: ID = 'tty58'
DEV: registering device: ID = 'tty59'
DEV: registering device: ID = 'tty60'
DEV: registering device: ID = 'tty61'
DEV: registering device: ID = 'tty62'
DEV: registering device: ID = 'tty63'
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
Registering platform device 'serial8250'. Parent at platform
DEV: registering device: ID = 'serial8250'
bus platform: add device serial8250
DEV: registering device: ID = 'ttyS0'
DEV: registering device: ID = 'ttyS1'
DEV: registering device: ID = 'ttyS2'
DEV: registering device: ID = 'ttyS3'
bus platform: add driver serial8250
platform: Matched Device serial8250.0 with Driver serial8250
platform: Probing driver serial8250 with device serial8250.0
DEV: Unregistering device. ID = 'ttyS0'
device_create_release called for ttyS0
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
DEV: registering device: ID = 'ttyS0'
DEV: Unregistering device. ID = 'ttyS1'
device_create_release called for ttyS1
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
DEV: registering device: ID = 'ttyS1'
bound device 'serial8250.0' to driver 'serial8250'
platform: Bound Device serial8250.0 to Driver serial8250
platform: Matched Device serial8250 with Driver serial8250
platform: Probing driver serial8250 with device serial8250
bound device 'serial8250' to driver 'serial8250'
platform: Bound Device serial8250 to Driver serial8250
bus pci: add driver serial
loop: module loaded
bus platform: add driver fsl-gianfar_mdio
platform: Matched Device fsl-gianfar_mdio.-5 with Driver fsl-gianfar_mdio
platform: Probing driver fsl-gianfar_mdio with device fsl-gianfar_mdio.-5
DEV: registering device: ID = 'e0024520:00'
bus mdio_bus: add device e0024520:00
DEV: registering device: ID = 'e0024520:1f'
bus mdio_bus: add device e0024520:1f
Gianfar MII Bus: probed
bound device 'fsl-gianfar_mdio.-5' to driver 'fsl-gianfar_mdio'
platform: Bound Device fsl-gianfar_mdio.-5 to Driver fsl-gianfar_mdio
bus platform: add driver fsl-gianfar
platform: Matched Device fsl-gianfar.0 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.0
DEV: registering device: ID = 'eth0'
eth0: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c4
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.0' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.0 to Driver fsl-gianfar
platform: Matched Device fsl-gianfar.1 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.1
DEV: registering device: ID = 'eth1'
eth1: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c5
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.1' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.1 to Driver fsl-gianfar
platform: Matched Device fsl-gianfar.2 with Driver fsl-gianfar
platform: Probing driver fsl-gianfar with device fsl-gianfar.2
DEV: registering device: ID = 'eth2'
eth2: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c6
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
bound device 'fsl-gianfar.2' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.2 to Driver fsl-gianfar
bus mdio_bus: add driver Marvell 88E1101
bus mdio_bus: add driver Marvell 88E1112
bus mdio_bus: add driver Marvell 88E1111
mdio_bus: Matched Device e0024520:00 with Driver Marvell 88E1111
mdio_bus: Probing driver Marvell 88E1111 with device e0024520:00
bound device 'e0024520:00' to driver 'Marvell 88E1111'
mdio_bus: Bound Device e0024520:00 to Driver Marvell 88E1111
bus mdio_bus: add driver Marvell 88E1145
bus mdio_bus: add driver Marvell 88E1240
bus mdio_bus: add driver LXT970
bus mdio_bus: add driver LXT971
DEV: registering device: ID = 'dummy0'
device class 'scsi_disk': registering
bus scsi: add driver sd
bus pci: add driver sata_promise
pci: Matched Device 0000:00:12.0 with Driver sata_promise
pci: Probing driver sata_promise with device 0000:00:12.0
sata_promise 0000:00:12.0: version 2.11
scsi0 : sata_promise
DEV: registering device: ID = 'host0'
CLASS: registering class device: ID = 'host0'
class_uevent - name = host0
scsi1 : sata_promise
DEV: registering device: ID = 'host1'
CLASS: registering class device: ID = 'host1'
class_uevent - name = host1
scsi2 : sata_promise
DEV: registering device: ID = 'host2'
CLASS: registering class device: ID = 'host2'
class_uevent - name = host2
ata1: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000200 irq 18
ata2: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000280 irq 18
ata3: PATA max UDMA/133 mmio m4096@0x80000000 port 0x80000300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
DEV: registering device: ID = 'target0:0:0'
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
DEV: registering device: ID = '0:0:0:0'
bus scsi: add device 0:0:0:0
scsi: Matched Device 0:0:0:0 with Driver sd
scsi: Probing driver sd with device 0:0:0:0
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
bound device '0:0:0:0' to driver 'sd'
scsi: Bound Device 0:0:0:0 to Driver sd
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
bound device '0000:00:12.0' to driver 'sata_promise'
pci: Bound Device 0000:00:12.0 to Driver sata_promise
bus pci: add driver pata_pdc2027x
usbmon: debugfs is not available
bus pci: add driver ehci_hcd
pci: Matched Device 0000:00:14.2 with Driver ehci_hcd
pci: Probing driver ehci_hcd with device 0000:00:14.2
ehci_hcd 0000:00:14.2: EHCI Host Controller
CLASS: registering class device: ID = 'usb_host1'
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
ehci_hcd 0000:00:14.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:14.2: irq 20, io mem 0x81202000
ehci_hcd 0000:00:14.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
DEV: registering device: ID = 'usb1'
bus usb: add device usb1
usb: Matched Device usb1 with Driver usb
usb: Probing driver usb with device usb1
device class 'usb_endpoint': registering
DEV: registering device: ID = 'usbdev1.1_ep00'
usb usb1: configuration #1 chosen from 1 choice
DEV: registering device: ID = '1-0:1.0'
bus usb: add device 1-0:1.0
usb: Matched Device 1-0:1.0 with Driver hub
usb: Probing driver hub with device 1-0:1.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
bound device '1-0:1.0' to driver 'hub'
usb: Bound Device 1-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev1.1_ep81'
DEV: registering device: ID = 'usbdev1.1'
bound device 'usb1' to driver 'usb'
usb: Bound Device usb1 to Driver usb
bound device '0000:00:14.2' to driver 'ehci_hcd'
pci: Bound Device 0000:00:14.2 to Driver ehci_hcd
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
bus of_platform: add driver ppc-of-ohci
bus pci: add driver ohci_hcd
pci: Matched Device 0000:00:14.0 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.0
ohci_hcd 0000:00:14.0: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host2'
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
ohci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:14.0: irq 20, io mem 0x81200000
DEV: registering device: ID = 'usb2'
bus usb: add device usb2
usb: Matched Device usb2 with Driver usb
usb: Probing driver usb with device usb2
DEV: registering device: ID = 'usbdev2.1_ep00'
usb usb2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '2-0:1.0'
bus usb: add device 2-0:1.0
usb: Matched Device 2-0:1.0 with Driver hub
usb: Probing driver hub with device 2-0:1.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
bound device '2-0:1.0' to driver 'hub'
usb: Bound Device 2-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev2.1_ep81'
DEV: registering device: ID = 'usbdev2.1'
bound device 'usb2' to driver 'usb'
usb: Bound Device usb2 to Driver usb
bound device '0000:00:14.0' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.0 to Driver ohci_hcd
pci: Matched Device 0000:00:14.1 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.1
ohci_hcd 0000:00:14.1: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host3'
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
ohci_hcd 0000:00:14.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:14.1: irq 20, io mem 0x81201000
DEV: registering device: ID = 'usb3'
bus usb: add device usb3
usb: Matched Device usb3 with Driver usb
usb: Probing driver usb with device usb3
DEV: registering device: ID = 'usbdev3.1_ep00'
usb usb3: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-0:1.0'
bus usb: add device 3-0:1.0
usb: Matched Device 3-0:1.0 with Driver hub
usb: Probing driver hub with device 3-0:1.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
bound device '3-0:1.0' to driver 'hub'
usb: Bound Device 3-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev3.1_ep81'
DEV: registering device: ID = 'usbdev3.1'
bound device 'usb3' to driver 'usb'
usb: Bound Device usb3 to Driver usb
bound device '0000:00:14.1' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.1 to Driver ohci_hcd
Initializing USB Mass Storage driver...
bus usb: add driver usb-storage
usb 3-2: new low speed USB device using ohci_hcd and address 2
DEV: registering device: ID = '3-2'
bus usb: add device 3-2
usb: Matched Device 3-2 with Driver usb
usb: Probing driver usb with device 3-2
DEV: registering device: ID = 'usbdev3.2_ep00'
usb 3-2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-2:1.0'
bus usb: add device 3-2:1.0
DEV: registering device: ID = 'usbdev3.2_ep81'
DEV: registering device: ID = 'usbdev3.2'
bound device '3-2' to driver 'usb'
usb: Bound Device 3-2 to Driver usb
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
bus type 'usb-serial' registered
bus usb: add driver usbserial
usbcore: registered new interface driver usbserial
bus usb-serial: add driver generic
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
bus usb: add driver usbserial_generic
usb: Matched Device 3-2:1.0 with Driver usbserial_generic
usb: Probing driver usbserial_generic with device 3-2:1.0
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
bus usb-serial: add driver ftdi_sio
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
bus usb: add driver ftdi_sio
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
bus usb-serial: add driver pl2303
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
bus usb: add driver pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
DEV: registering device: ID = 'mice'
DEV: registering device: ID = 'psaux'
mice: PS/2 mouse device common for all mice
bus usb: add driver usbtouchscreen
usb: Matched Device 3-2:1.0 with Driver usbtouchscreen
usb: Probing driver usbtouchscreen with device 3-2:1.0
DEV: registering device: ID = 'input0'
input: TSC-10 DM as /devices/pci0000:00/0000:00:14.1/usb3/3-2/3-2:1.0/input/input0
DEV: registering device: ID = 'mouse0'
DEV: registering device: ID = 'event0'
bound device '3-2:1.0' to driver 'usbtouchscreen'
usb: Bound Device 3-2:1.0 to Driver usbtouchscreen
usbcore: registered new interface driver usbtouchscreen
bus i2c: add driver rtc-ds1307
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
bus usb: add driver usbhid
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
DEV: registering device: ID = 'sit0'
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
driver_probe_done: probe_count = 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 120k init
class_uevent - name = 0000:00
class_uevent - name = 0:0:0:0
class_uevent - name = 0:0:0:0
class_uevent - name = host0
class_uevent - name = host1
class_uevent - name = host2
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
EXT3 FS on sda1, internal journal
Adding 2939884k swap on /dev/sda2. Priority:-1 extents:1 across:2939884k
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: registering device: ID = 'vcs2'
DEV: registering device: ID = 'vcsa2'
DEV: registering device: ID = 'vcs3'
DEV: registering device: ID = 'vcsa3'
DEV: registering device: ID = 'vcs5'
DEV: registering device: ID = 'vcsa5'
DEV: registering device: ID = 'vcs6'
DEV: registering device: ID = 'vcsa6'
DEV: registering device: ID = 'vcs4'
DEV: registering device: ID = 'vcsa4'
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present
[-- Attachment #3: .config --]
[-- Type: application/x-config, Size: 27428 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
From: Davide Libenzi @ 2007-11-28 19:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Michael Kerrisk, Arnd Bergmann, Linux Kernel Mailing List,
Kamalesh Babulal, linuxppc-dev, Paul Mackerras, Balbir Singh
In-Reply-To: <20071128104345.9474025e.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1248 bytes --]
On Wed, 28 Nov 2007, Andrew Morton wrote:
> On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > > Kernel build fails, with build error
> > >
> > > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > > make: *** [arch/powerpc/platforms] Error 2
> > >
> >
> > I guess all architectures except x86 are currently broken because they
> > reference the old sys_timerfd function.
>
> None of them were broken in my testing and I'm unsure why powerpc broke
> here.
>
> > This patch should add the missing
> > bits to powerpc.
> >
>
> Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
> _should_ have (incorrectly) picked those up.
My fault. I forgot to update sys_ni.c with the new functions (and with the
sys_timerfd->sys_timerfd_create name change).
Do you want a patch Andrew?
- Davide
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 19:20 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071128194321.0804b3aa@i1501.lan.towertech.it>
Hi, Alessandro!
Thank you for your quick response... I'll just follow your
ideas and provide you with the dmesg output ASAP.
If you are online for some more time, I will accelerate
this debugging session... Just let me know.
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
>
> mmm. I've been told it should work ;)
>
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
>
> this one must be deselected.
>
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
>
> ditto.
Will do.
>
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
>
> maybe the wrong driver is kicking in here.
> the fact that there is no rtc class
> related output in dmesg should and that
> there is no /dev/rtc0 could be a sign that the whole class
> is not going in.
>
> do you have full dmesg?
Not a full one from the 2.6.24 right now...
But I'll disable above stuff and get you a full one.
(in 5..10 minutes).
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Brandeburg, Jesse @ 2007-11-28 18:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kok, Auke-jan H; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071116073821.548CCDDDF4@ozlabs.org>
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>=20
> This fixes it by removing those temporary variables and passing
> directly the result of pci_resource_start/len to ioremap.
the patch is mostly fine, but looking through the tree, doesn't every
driver that has 64 bit capable resources have this problem?
in fact, skeleton module has this problem, if I'm not mistaken. e1000
isn't the only one. :-)
=20
> The side effect is that I removed the assignments to the netdev
> fields mem_start, mem_end and base_addr, which are totally useless
> for PCI devices.
also, concerning this, ifconfig shows the output of these variables, I
don't think we want to blatantly remove them, as it is actually removing
information that is, if not used, at least displayed to user space.
eth6 Link encap:Ethernet HWaddr 00:0E:01:0C:02:03
inet addr:134.134.3.121 Bcast:134.134.3.255
Mask:255.255.255.0
inet6 addr: fe80::20e:1ff:fe0c:203/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9022519 errors:0 dropped:0 overruns:0 frame:0
TX packets:1303701 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4044613454 (3857.2 Mb) TX bytes:118365109 (112.8 Mb)
Base address:0xf000 Memory:feac0000-feae0000
^^^^^^^^^^^^^^^^^
^ permalink raw reply
* Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
From: Andrew Morton @ 2007-11-28 18:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Kerrisk, linux-kernel, Kamalesh Babulal, linuxppc-dev,
Paul Mackerras, Davide Libenzi, Balbir Singh
In-Reply-To: <200711281432.09178.arnd@arndb.de>
On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > Kernel build fails, with build error
> >
> > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
> >
>
> I guess all architectures except x86 are currently broken because they
> reference the old sys_timerfd function.
None of them were broken in my testing and I'm unsure why powerpc broke
here.
> This patch should add the missing
> bits to powerpc.
>
Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
_should_ have (incorrectly) picked those up.
Odd.
>
> ---
>
> Disclaimer: Not tested at all, just applied common sense.
> Disclaimer2: conflicts with the sys_indirect kernel implementation
> sent by paulus last week.
>
> diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
> index 11d5383..b029368 100644
> --- a/include/asm-powerpc/systbl.h
> +++ b/include/asm-powerpc/systbl.h
> @@ -309,7 +309,9 @@ SYSCALL_SPU(getcpu)
> COMPAT_SYS(epoll_pwait)
> COMPAT_SYS_SPU(utimensat)
> COMPAT_SYS_SPU(signalfd)
> -COMPAT_SYS_SPU(timerfd)
> +COMPAT_SYS_SPU(timerfd_create)
> SYSCALL_SPU(eventfd)
> COMPAT_SYS_SPU(sync_file_range2)
> COMPAT_SYS(fallocate)
> +COMPAT_SYS_SPU(sys_timerfd_settime)
> +COMPAT_SYS_SPU(sys_timerfd_gettime)
> diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
> index 97d82b6..4ba2d20 100644
> --- a/include/asm-powerpc/unistd.h
> +++ b/include/asm-powerpc/unistd.h
> @@ -328,14 +328,16 @@
> #define __NR_epoll_pwait 303
> #define __NR_utimensat 304
> #define __NR_signalfd 305
> -#define __NR_timerfd 306
> +#define __NR_timerfd_create 306
> #define __NR_eventfd 307
> #define __NR_sync_file_range2 308
> #define __NR_fallocate 309
> +#define __NR_sys_timerfd_settime 310
> +#define __NR_sys_timerfd_gettime 311
>
> #ifdef __KERNEL__
>
> -#define __NR_syscalls 310
> +#define __NR_syscalls 312
>
> #define __NR__exit __NR_exit
> #define NR_syscalls __NR_syscalls
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Alessandro Zummo @ 2007-11-28 18:43 UTC (permalink / raw)
To: Clemens Koller; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <474DB27C.7020909@anagramm.de>
On Wed, 28 Nov 2007 19:25:00 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:
> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
> on my MPC8540(ads like) PowerPC working properly on
> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
> as well as a 2.6.22-rc6-gb75ae860 is working fine.
> (mainstream's console is broken, so cannot test these, yet.)
>
>
> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
> and it also breaks the deprecated SENSORS_DS1337. :-(
mmm. I've been told it should work ;)
> Here is a snippet from my .config which is similar among my kernels.
> CONFIG_GEN_RTC=y
this one must be deselected.
> CONFIG_SENSORS_DS1337=y
> CONFIG_SENSORS_DS1374=y
ditto.
> DEV: registering device: ID = '0-0068'
> bus i2c: add device 0-0068
> bound device '0-0068' to driver 'ds1337'
maybe the wrong driver is kicking in here.
the fact that there is no rtc class
related output in dmesg should and that
there is no /dev/rtc0 could be a sign that the whole class
is not going in.
do you have full dmesg?
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 18:25 UTC (permalink / raw)
To: linuxppc-embedded, rtc-linux, a.zummo
Hi, there!
(Only subscribed to linuxppc-embedded and lkml; otherwise, please CC)
Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
on my MPC8540(ads like) PowerPC working properly on
latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
as well as a 2.6.22-rc6-gb75ae860 is working fine.
(mainstream's console is broken, so cannot test these, yet.)
My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
and it also breaks the deprecated SENSORS_DS1337. :-(
Before I start bisecting and digging in the code (I'm booting from
flash, so it isn't fun to change kernels on the fly), I just want
to verify that my configuration is correct.
I am using hwclock-2.31 from Bryan Henderson since the one
which comes with util-linux doesn't support to choose another
rtc device than /dev/rtc.
Here is a snippet from my .config which is similar among my kernels.
CONFIG_GEN_RTC=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SENSORS_DS1337=y
CONFIG_SENSORS_DS1374=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_M41T00=y
CONFIG_HWMON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DEBUG=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_LIB=y
So, I enabled both, the new rtc-lib DS1307 (which is compatible to the DS1337)
and the deprecated SENSORS_DS1337.
Deselecting SENSORS_* doesn't help.
My /etc/udev/rules.d/50-udev-default.rules contains the line:
KERNEL=="rtc[0-9]*", MODE="0666"
When the RTC is working, I get the following:
dmesg:
------
i2c /dev entries driver
ds1307 0-0068: rtc core: registered ds1307 as rtc0
ds1307 0-0068: setting the system clock to 2007-11-28 18:56:33 (1196276193)
and I get:
root@fox_1:/dev$ l rtc*
crw-r--r-- 1 root root 10, 135 Jan 1 2000 rtc
crw-rw---- 1 root root 239, 0 Jan 1 2000 rtc0
(Jan 1 2000 is the default date when the rtc chip was powered down, so the
rtc was read successfully.)
$hwclock --systohc --rtc /dev/rtc0
is working properly...
When it's NOT working (2.6.24-rc2-git with some debugging enabled) I get:
dmesg:
------
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
bus i2c: add driver ds1337
DEV: registering device: ID = '0-0068'
bus i2c: add device 0-0068
bound device '0-0068' to driver 'ds1337'
bus i2c: add driver lm75
DEV: registering device: ID = '0-0048'
bus i2c: add device 0-0048
bound device '0-0048' to driver 'lm75'
DEV: registering device: ID = 'hwmon0'
bus i2c: add driver max6650
$ ls /dev/rt*
crw-r--r-- 1 root root 10, 135 Jan 1 1970 rtc
and
$ cat /proc/driver/rtc
rtc_time : 00:00:570426440
rtc_date : 269131772-01-00
rtc_epoch : 1900
alarm : 00:00:00
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 0
batt_status : okay
shows up but these values never seem to get an update.
(==stable among reboots) :-(
My /etc/udev/50-udev-default.rules
contains
KERNEL=="rtc", MODE="0644"
Any ideas to debug?
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-28 18:12 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded, Michal Simek
In-Reply-To: <20071128172713.AA7D835004D@mail53-sin.bigfish.com>
On 11/28/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> So, John: would you care to make a goal (for say 2.6.25 or 26) of
> working with me to get the microblaze into mainline? I think the
> community exists to keep things maintained, but I'm guessing that it
> would help to have an existing LKMLer or two take a look over the code.
> Given the move towards device trees, getting someone from powerpc would
> seem to be natural. Anybody interested?
I'll provide as much support as I can, given that I'm not very
familiar with microblaze.
Cheers,
g
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] SET_NETDEV_DEV() in fec_mpc52xx.c
From: David Woodhouse @ 2007-11-28 18:04 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, Domen Puncer, netdev
This helps to allow the Fedora installer to use the built-in Ethernet on
the Efika for a network install.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -971,6 +971,8 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
mpc52xx_fec_reset_stats(ndev);
+ SET_NETDEV_DEV(ndev, &op->dev);
+
/* Register the new network device */
rv = register_netdev(ndev);
if (rv < 0)
--
dwmw2
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: David Woodhouse @ 2007-11-28 18:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Jeff Garzik, Domen Puncer, netdev
In-Reply-To: <9e4733910711181749p1d2744b1md8ea92fdca60d6d6@mail.gmail.com>
On Sun, 2007-11-18 at 20:49 -0500, Jon Smirl wrote:
> On 11/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > > This is the reason I couldn't get user space started or connect to my
> > > > nfs server. Patch is against current linus git.
> > > >
> > > > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > > > where the wrong skb buffer was being referenced.
> > > >
> > > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > >
> > > Acked-by: Domen Puncer <domen.puncer@telargo.com>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Jeff, can you please pick this up for .24?
>
> This is didn't make it into rc3. Without this patch this driver is broken.
Jeff?
--
dwmw2
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-28 17:28 UTC (permalink / raw)
To: John Williams; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <474CBBDE.9010007@itee.uq.edu.au>
=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of John Williams
> Sent: Tuesday, November 27, 2007 4:53 PM
> To: Stephen Neuendorffer
> Cc: Michal Simek; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>=20
> Stephen Neuendorffer wrote:
>=20
> >>From: John Williams [mailto:jwilliams@itee.uq.edu.au]=20
>=20
> >>MicroBlaze is a highly configurable CPU in terms of its=20
> >>instruction set,=20
> >>features and so on. To make use of this, it is essential that each=20
> >>kernel image be compiled to match the CPU configuration. While a=20
> >>generic kernel, making use of no features (MUL, DIV, Shift,=20
> >>MSR ops etc)=20
> >>would run on any CPU, performance would be abysmal.
> >=20
> > I think the userspace is actually much more critical than=20
> the kernel for
> > most of these things (with the exception of msrset/msrclr, and the
> > barrel shifter perhaps). Unfortunately, even if you implement an
> > alternatives-style mechanism for the kernel, you're still hosed for
> > userspace. =20
>=20
> I haven't benchmarks each option on the kernel - you are right that=20
> shift is a big one, but mul I think is also important, given=20
> that every=20
> array access generates an integer multiply,
Good point.
>=20
> Once I a big enough system, it's just unfeasible to
> > recompile everything anyway. I think this is where=20
> autoconfig starts to
> > break down.
>=20
> I'm not sure I agree, here, given that most people building=20
> MicroBlaze=20
> systems are doing so with uClinux-dist (or PetaLinux), you=20
> can do a full=20
> rebuilt, kernel libs apps, in a couple of minutes. Much shorter than=20
> sythnesis and P&R, that's for sure (and runtime is linear in size,=20
> unlike P&R :)
Let's not bash the P&R guys too much... You try working on a problem
that is known to be insolvable, and where no matter how many people you
make happier, you'll always get bashed by the guy whose design no longer
meets timing. :)
> > It's not nice, I agree. I think the key principle should be that I
> > should be able to get a system working as quickly as possible, and I
> > might optimize things later. One thing that device trees=20
> will allow is
> > for *all* the drivers to get compiled in to the kernel, and=20
> only as a
> > late stage operation does a designer need to start throwing=20
> things away.
> > Using traps I can easily start with a 'kitchen sink'=20
> design, and start
> > discarding processor features, relying on the traps. When I get low
> > enough down on the performance curve, I can uas an autoconfig-type
> > mechanism to regain a little of what I lost by optimizing=20
> away the trap
> > overhead.=20
>=20
> OK, but now we have a kernel dependent on *3* files - a DTS, a=20
> Kconfig.auto, and (indirectly) the bitstream itself.
The kernel might be generated from them, but it is not *dependent* on
them. The same kernel can run on other hardware, with other dts's. If
there was a traps mechanism (or alternatives), then it could also run on
other designs with different processor features.
> Another thing I suggested to Michal recently, perhaps we need=20
> kernel/lib/libof to store common OF / DT handling code. Much better=20
> than duplicating it accross microblaze and PPC, and maybe=20
> other arch's=20
> would also see the light.. That would also add a claim for=20
> the DTC to=20
> go in scripts/
There's some shared code in 2.6.24-rc in drivers/of. Now that things
are settling down in terms of bugs, I'll probably transition to pushing
a 2.6.24-rc branch soon. However, the few brief conversations I've had
suggest that what microblaze might need or want has very little
influence until it is visible in mainline. Once that happens, I think
it will be easy to justify putting code like libfdt and some of the
kernel of/dt code in a common place. =20
So, John: would you care to make a goal (for say 2.6.25 or 26) of
working with me to get the microblaze into mainline? I think the
community exists to keep things maintained, but I'm guessing that it
would help to have an existing LKMLer or two take a look over the code.
Given the move towards device trees, getting someone from powerpc would
seem to be natural. Anybody interested?
Steve
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Jon Loeliger @ 2007-11-28 17:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071128165335.GA4597@loki.buserror.net>
So, like, the other day Scott Wood mumbled:
> On Wed, Nov 28, 2007 at 09:39:08AM -0600, Kumar Gala wrote:
> > Take from u-boot whitespace fixup of the file
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
[snip]
> I don't think this is an improvement... tabs are great for indentation, but
> they suck for alignment.
>
> -Scott
The issue was consistency with U-Boot for update reasons.
I'm fine with it....
jdl
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-28 16:57 UTC (permalink / raw)
To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474CE85A.1020902@gdatech.co.in>
vijay baskar wrote:
> Hi, "The kernel also allows hardcoded mapping of IO regions into its
> virtual address space through the io_block_mapping interface."
>
> Can u tell me how this is in current arch/powerpc.
Everything is explicitly ioremapped.
> Also does it mean that whatever be the size of the ram > 768 MB there
> is not going to be much improvement in performance in kernel space
> irrespective of invoking CONFIG_HIGHMEM or not?
Well, the kernel can use highmem for cache... I'm not sure what you
mean by "in kernel space".
> Also do you think this low mem be enough if i have lots of kernel
> space processes each invoking lots of kmallocs.
That depends on what you mean by "lots". :-)
You'll have 768MB of lowmem, and kmallocs can only use lowmem.
> Will there be bottle necks?? Also what alternative do we have if low
> mem of 768 MB is not enough??
You'll need to change the user/kernel split, and deal with anything that
breaks in the process.
Or get a 64-bit chip. :-)
-Scott
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Scott Wood @ 2007-11-28 16:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <Pine.LNX.4.64.0711280938440.3013@blarg.am.freescale.net>
On Wed, Nov 28, 2007 at 09:39:08AM -0600, Kumar Gala wrote:
> Take from u-boot whitespace fixup of the file
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> libfdt/fdt.h | 32 ++++++++++++++++----------------
> 1 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/libfdt/fdt.h b/libfdt/fdt.h
> index e00559a..48ccfd9 100644
> --- a/libfdt/fdt.h
> +++ b/libfdt/fdt.h
> @@ -4,22 +4,22 @@
> #ifndef __ASSEMBLY__
>
> struct fdt_header {
> - uint32_t magic; /* magic word FDT_MAGIC */
> - uint32_t totalsize; /* total size of DT block */
> - uint32_t off_dt_struct; /* offset to structure */
> - uint32_t off_dt_strings; /* offset to strings */
> - uint32_t off_mem_rsvmap; /* offset to memory reserve map */
> - uint32_t version; /* format version */
> - uint32_t last_comp_version; /* last compatible version */
> -
> - /* version 2 fields below */
> - uint32_t boot_cpuid_phys; /* Which physical CPU id we're
> + uint32_t magic; /* magic word FDT_MAGIC */
> + uint32_t totalsize; /* total size of DT block */
> + uint32_t off_dt_struct; /* offset to structure */
> + uint32_t off_dt_strings; /* offset to strings */
> + uint32_t off_mem_rsvmap; /* offset to memory reserve map */
> + uint32_t version; /* format version */
> + uint32_t last_comp_version; /* last compatible version */
I don't think this is an improvement... tabs are great for indentation, but
they suck for alignment.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2007-11-28 16:30 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <20071128161201.GA10916@csn.ul.ie>
On Wednesday 28 November 2007, Mel Gorman wrote:
> On (28/11/07 08:26), Arnd Bergmann didst pronounce:
> > On Wednesday 28 November 2007, Jon Tollefson wrote:
> > > This patch adds the hugepagesz boot-time parameter for ppc64 that let=
s=20
> > > you pick the size for your huge pages. =A0The choices available are 6=
4K=20
> > > and 16M. =A0It defaults to 16M (previously the only choice) if nothin=
g or=20
> > > an invalid choice is specified. =A0Tested 64K huge pages with the=20
> > > libhugetlbfs 1.2 release with its 'make func' and 'make stress' test=
=20
> > > invocations.
> >=20
> > How hard would it be to add the 1MB page size that some CPUs support
> > as well? On systems with small physical memory like the PS3, that
> > sounds very useful to me.
> >=20
>=20
> Does the PS3 support 1M pages in hardware? When I last looked, the magic
> ibm,segment-page-sizes file that described the supported pagesizes was
> missing from the device tree. In this situation, the default sizes
> become 4K and 16M because no other ones are advertised.
I think you can select the page size using a hypercall on the PS3.
The CPU supports any two of (64k, 1M, 16M) simultaneously.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-28 16:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, linux-ide
In-Reply-To: <200711272233.00456.arnd@arndb.de>
Hello.
Arnd Bergmann wrote:
>>>This driver nicely wraps around pata_platform library functions,
>>>and provides OF platform bus bindings to the PATA devices.
>>>+static struct of_device_id pata_of_platform_match[] = {
>>>+ { .compatible = "pata-platform", },
>>>+};
>>"pata-platform" really means nothing outside of linux. A more
>>generic label would be useful.
> Maybe the name of the standards it supports? Could be
> "ata-4", "ata-5" and the like,
It's not clear what info this would provide.
> or the exact transfer mode, like
> "pata-udma-5", "pata-pio-3", "sata-150", etc.
I think this info should follow from the compatible property value
implicitly, or maybe this info should be conveyed in some optional properties.
It doesn't make sense to the generic platform driver anyway since it has no
notion about the mode programming specifics. I think that as the device being
driven is assumed to be a generic IDE device, the "compatible" property should
contain "generic" or something alike (as well as usual board's and chip's names).
> Arnd <><
MBR, Sergei
^ permalink raw reply
* [PATCH][DTC] Add an option to pad the blob that is generated
From: Kumar Gala @ 2007-11-28 16:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
There are times when we need extra space in the blob and just want
to have it added on w/o know the exact size to make it.
The padding and min size options are mutually exclusive.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
dtc.c | 14 +++++++++++++-
dtc.h | 1 +
flattree.c | 20 +++++++++++++-------
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/dtc.c b/dtc.c
index 602b296..cf9a6a9 100644
--- a/dtc.c
+++ b/dtc.c
@@ -29,6 +29,7 @@
int quiet; /* Level of quietness */
int reservenum; /* Number of memory reservation slots */
int minsize; /* Minimum blob size */
+int padsize; /* Additional padding to blob */
char *join_path(char *path, char *name)
{
@@ -97,6 +98,8 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, "\t\tMake space for <number> reserve map entries (relevant for \n\t\tdtb and asm output only)\n");
fprintf(stderr, "\t-S <bytes>\n");
fprintf(stderr, "\t\tMake the blob at least <bytes> long (extra space)\n");
+ fprintf(stderr, "\t-p <bytes>\n");
+ fprintf(stderr, "\t\tAdd padding to the blob of <bytes> long (extra space)\n");
fprintf(stderr, "\t-b <number>\n");
fprintf(stderr, "\t\tSet the physical boot cpu\n");
fprintf(stderr, "\t-f\n");
@@ -124,8 +127,9 @@ int main(int argc, char *argv[])
quiet = 0;
reservenum = 0;
minsize = 0;
+ padsize = 0;
- while ((opt = getopt(argc, argv, "hI:O:o:V:R:S:fcqb:v")) != EOF) {
+ while ((opt = getopt(argc, argv, "hI:O:o:V:R:S:p:fcqb:v")) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -145,6 +149,9 @@ int main(int argc, char *argv[])
case 'S':
minsize = strtol(optarg, NULL, 0);
break;
+ case 'p':
+ padsize = strtol(optarg, NULL, 0);
+ break;
case 'f':
force = 1;
break;
@@ -173,6 +180,11 @@ int main(int argc, char *argv[])
else
arg = argv[optind];
+ /* minsize and padsize are mutually exclusive */
+ if ((minsize) && (padsize)) {
+ die("Can't set both -p and -S\n");
+ }
+
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
inform, outform, arg);
diff --git a/dtc.h b/dtc.h
index d080153..0100ad1 100644
--- a/dtc.h
+++ b/dtc.h
@@ -43,6 +43,7 @@
extern int quiet; /* Level of quietness */
extern int reservenum; /* Number of memory reservation slots */
extern int minsize; /* Minimum blob size */
+extern int padsize; /* Additional padding to blob */
static inline void __attribute__((noreturn)) die(char * str, ...)
{
diff --git a/flattree.c b/flattree.c
index 5889900..3c13566 100644
--- a/flattree.c
+++ b/flattree.c
@@ -366,7 +366,7 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
struct data dtbuf = empty_data;
struct data strbuf = empty_data;
struct fdt_header fdt;
- int padlen;
+ int padlen = 0;
for (i = 0; i < ARRAY_SIZE(version_table); i++) {
if (version_table[i].version == version)
@@ -387,16 +387,17 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
/*
* If the user asked for more space than is used, adjust the totalsize.
*/
- padlen = minsize - be32_to_cpu(fdt.totalsize);
- if (padlen > 0) {
- fdt.totalsize = cpu_to_be32(minsize);
- } else {
- if ((minsize > 0) && (quiet < 1))
+ if (minsize > 0) {
+ padlen = minsize - be32_to_cpu(fdt.totalsize);
+ if ((padlen < 0) && (quiet < 1))
fprintf(stderr,
"Warning: blob size %d >= minimum size %d\n",
be32_to_cpu(fdt.totalsize), minsize);
}
+ if (padsize > 0)
+ padlen = padsize;
+
/*
* Assemble the blob: start with the header, add with alignment
* the reserve buffer, add the reserve map terminating zeroes,
@@ -413,8 +414,10 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
* If the user asked for more space than is used, pad out the blob.
*/
if (padlen > 0) {
+ int tsize = be32_to_cpu(fdt.totalsize);
+ tsize += padlen;
blob = data_append_zeroes(blob, padlen);
- fdt.totalsize = cpu_to_be32(minsize);
+ fdt.totalsize = cpu_to_be32(tsize);
}
fwrite(blob.val, blob.len, 1, f);
@@ -544,6 +547,9 @@ void dt_to_asm(FILE *f, struct boot_info *bi, int version, int boot_cpuid_phys)
fprintf(f, "\t.space\t%d - (_%s_blob_end - _%s_blob_start), 0\n",
minsize, symprefix, symprefix);
}
+ if (padsize > 0) {
+ fprintf(f, "\t.space\t%d, 0\n", padsize);
+ }
emit_label(f, symprefix, "blob_abs_end");
data_free(strbuf);
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Mel Gorman @ 2007-11-28 16:12 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <200711280826.46820.arnd@arndb.de>
On (28/11/07 08:26), Arnd Bergmann didst pronounce:
> On Wednesday 28 November 2007, Jon Tollefson wrote:
> > This patch adds the hugepagesz boot-time parameter for ppc64 that lets
> > you pick the size for your huge pages. The choices available are 64K
> > and 16M. It defaults to 16M (previously the only choice) if nothing or
> > an invalid choice is specified. Tested 64K huge pages with the
> > libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
> > invocations.
>
> How hard would it be to add the 1MB page size that some CPUs support
> as well? On systems with small physical memory like the PS3, that
> sounds very useful to me.
>
Does the PS3 support 1M pages in hardware? When I last looked, the magic
ibm,segment-page-sizes file that described the supported pagesizes was
missing from the device tree. In this situation, the default sizes
become 4K and 16M because no other ones are advertised.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-28 16:11 UTC (permalink / raw)
To: avorontsov; +Cc: Olof Johansson, linuxppc-dev, Arnd Bergmann, linux-ide
In-Reply-To: <20071128154904.GA20722@localhost.localdomain>
Anton Vorontsov wrote:
>>>>This driver nicely wraps around pata_platform library functions,
>>>>and provides OF platform bus bindings to the PATA devices.
>>>>+static struct of_device_id pata_of_platform_match[] = {
>>>>+ { .compatible = "pata-platform", },
>>>>+};
>>>"pata-platform" really means nothing outside of linux. A more
>>>generic label would be useful.
> Agreed.
Now you're quick to agree. :-)
>>Maybe the name of the standards it supports? Could be
>>"ata-4", "ata-5" and the like, or the exact transfer mode, like
>>"pata-udma-5", "pata-pio-3", "sata-150", etc.
> You're quite optimistic about pata_platform capabilities. ;-)
Indeed. :-)
> As far as I know it is [obviously] supports PIO modes only. And so
> far I was able to get max 5.28 MB/s read transfers. Which looks like
> ideal case for PIO1 (CF I'm testing on is 3.0, max. PIO4).
Believe me, it's a great speed even for PIO4. Most systems only show 3+
MiB/s in this mode according to hdparm.
> I've modified pio_mask appropriately, plus I've tried to comment
> out .set_mode = pata_platform_set_mode, and now it says:
> ata5: PATA max PIO4 mmio cmd 0xf0000000 ctl 0xf000020c irq 24
> ata5.00: CFA: TOSHIBA THNCF512MQG, 3.00, max PIO4
> ata5.00: configured for PIO4
> ata5.00: configured for PIO4
> That looks good, but speed is the same. Oh well, it's another
> matter.
> Back to dts, I think pata-pio-X is good scheme. That way we can
> pass pio_mask via device tree. Sounds reasonable?
Grumble. Can't we pass this via some property other than "compatible"? I'm
opposed to "ata-5" and the like in there as well cause it's not clear what
information this would provide. Why people so love to make things complex WRT
the "compatible" property -- instead of making the task of selecting a proper
driver more simple, they tend to make it mode complex by trying to specify
values that have quite little to do with the device's programming interface
itself...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Jon Loeliger @ 2007-11-28 15:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711280938440.3013@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> Take from u-boot whitespace fixup of the file
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-28 15:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, linux-ide
In-Reply-To: <200711272233.00456.arnd@arndb.de>
On Tue, Nov 27, 2007 at 10:32:58PM +0100, Arnd Bergmann wrote:
> On Tuesday 27 November 2007, Olof Johansson wrote:
> > On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> > > This driver nicely wraps around pata_platform library functions,
> > > and provides OF platform bus bindings to the PATA devices.
> >
> > > +static struct of_device_id pata_of_platform_match[] = {
> > > + { .compatible = "pata-platform", },
> > > +};
> >
> > "pata-platform" really means nothing outside of linux. A more
> > generic label would be useful.
Agreed.
> Maybe the name of the standards it supports? Could be
> "ata-4", "ata-5" and the like, or the exact transfer mode, like
> "pata-udma-5", "pata-pio-3", "sata-150", etc.
You're quite optimistic about pata_platform capabilities. ;-)
As far as I know it is [obviously] supports PIO modes only. And so
far I was able to get max 5.28 MB/s read transfers. Which looks like
ideal case for PIO1 (CF I'm testing on is 3.0, max. PIO4).
I've modified pio_mask appropriately, plus I've tried to comment
out .set_mode = pata_platform_set_mode, and now it says:
ata5: PATA max PIO4 mmio cmd 0xf0000000 ctl 0xf000020c irq 24
ata5.00: CFA: TOSHIBA THNCF512MQG, 3.00, max PIO4
ata5.00: configured for PIO4
ata5.00: configured for PIO4
That looks good, but speed is the same. Oh well, it's another
matter.
Back to dts, I think pata-pio-X is good scheme. That way we can
pass pio_mask via device tree. Sounds reasonable?
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: SPI driver for spi_mpc83xx
From: fabio777 @ 2007-11-28 15:41 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <474C70EF.4040800@qstreams.com>
Thanks Ben
works.
Ben Warren wrote:
> Fabio,
>
> Note: I've changed the e-mail subject back to the original. In the
> future, please ensure that it remains intact.
>
> fabio777 wrote:
>> Thanks Ben,
>>
>> Here it is
>>
>> static struct fsl_spi_platform_data k_platform_data = {
>> .initial_spmode = 0,
>> .bus_num = 1,
> Probably should be bus_num = 0
>> .max_chipselect = 1,
>> /* board specific information */
>> .activate_cs = k_cs_activate,
>> .deactivate_cs = k_cs_deactivate,
>> .sysclk = 266,
>> };
>>
>> static struct spi_board_info spi_board_info[] __initdata = { {
>> .modalias = "kplus",
>> .platform_data = &k_platform_data,
>> .max_speed_hz = 120000,
>> .bus_num = 1,
> Again, bus_num probably should be 0
>> .chip_select = 0,
>> },
>> };
>>
>>
>> struct platform_device k_plus = {
>> .name = "kplus",
> name should be "mpc83xx_spi". At initialization, the SPI controller
> driver searches the registered platform devices (models of board
> hardware) for a match. Without a match, it gives up.
>
>> .id = 1,
>> .dev = {
>> .platform_data = &k_platform_data,
>> },
>> };
>>
>> platform_device_register(&k_plus);
>>
> Do you add the SPI controller's resources (base address and IRQ?)
> You'll need to in order for this to work. On my board, I use
> 'platform_device_register_simple()', passing the name and the two
> resources, then call 'platform_add_data()', passing in the platform
> data structure.
>> spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
>>
> Good
>> and then calls spi_register_driver(&k_driver);
> I don't think this last call is needed.
>>
>> I can't get the into the *probe functions.
>> Thanks
>>
> regards,
> Ben
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox