* Re: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
From: Arnd Bergmann @ 2007-11-25 22:22 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711202312130.24220@blarg.am.freescale.net>
On Wednesday 21 November 2007, Kumar Gala wrote:
> + =A0 =A0* Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> + =A0 =A0SATA nodes are defined to describe on-chip Serial ATA controller=
s.
> + =A0 =A0Each SATA port should have its own node.
> +
> + =A0 =A0Required properties:
> + =A0 =A0- compatible =A0 =A0 =A0 =A0: compatible list, contains 2 entrie=
s, first is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-CHIP", where CHIP is the processor
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (m=
pc8315, mpc8379, etc.) and the second is
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "f=
sl,sata-pq2pro"
> + =A0 =A0- interrupts =A0 =A0 =A0 =A0: <interrupt mapping for SATA IRQ>
> + =A0 =A0- interrupt-parent =A0: optional, if needed for interrupt mapping
> + =A0 =A0- reg =A0 =A0 =A0 =A0 =A0 =A0 =A0 : <registers mapping>
> +
Should this maybe also mandate a compatible property that is defined
in a way to match the generic (p)ata_of_platform driver?
Arnd <><
^ permalink raw reply
* Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Grant Likely @ 2007-11-25 22:47 UTC (permalink / raw)
To: Stephen Neuendorffer, Segher Boessenkool, David Gibson,
Jon Loeliger
Cc: microblaze-uclinux, Michal Simek, git, linuxppc-dev
In-Reply-To: <20071125062456.ABA4AA4804E@mail64-cpk.bigfish.com>
On 11/24/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
Thanks for all this work; comments below.
>
> Here's what I've gotten so far:
>
> Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> #address-cells = <1>;
> #size-cells = <1>;
> network@81c00000 {
> compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac";
Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
compatible =
"xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
version if it maintains register level compatibility.
"xlnx,xps-ll-temac" is far to ambiguous.
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 3 0 >;
> llink-connected = <&PIM3>;
What's this property for?
> reg = < 81c00000 40 >;
If these registers are addressable, then the parent needs a 'ranges' property.
> xlnx,bus2core-clk-ratio = <1>;
> xlnx,phy-type = <1>;
> xlnx,phyaddr = <1>;
> xlnx,rxcsum = <0>;
> xlnx,rxfifo = <1000>;
> xlnx,temac-type = <0>;
> xlnx,txcsum = <0>;
> xlnx,txfifo = <1000>;
Would be nice to have a 'phy-handle' property as that is what is being
used on other platforms; but that's not something that EDK knows
about. It would be nice to have a way to tell EDK what PHY device is
on the board so it could generate the appropriate mdio and phy nodes.
> } ;
> } ;
> mpmc@90000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,mpmc-3.00.a", "xlnx,mpmc";
Drop 'xlns,mpmc'
> PIM3: sdma@84600180 {
> compatible = "xlnx,ll-dma-1.00a",
> "xlnx,ll-dma";
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 1 0 0 0 >;
> reg = < 84600180 80 >;
Are these directly addressable registers from the CPU? If so, the
parent node needs a 'ranges' property.
> } ;
> } ;
> DDR2_SDRAM: memory@90000000 {
> device_type = "memory";
> reg = < 90000000 10000000 >;
> } ;
>
> So: the mpmc generates a 'memory' node, corresponding to it's memory
> interface. It also gets a separate entry which contains the (optional, not
> present in this example) slave management interface (for ECC and performance
> information), and any sdma ports. In this case, this node is mpmc@90000000,
> because there is no management interface. If a management interface was
> present, then it would be @ the management address.
I don't think this is right; but I'm not sure. I don't know what the
best naming convention is for the case of no management interface, but
mpmc@90000000 doesn't feel right.
Segher, David; what's your opinion?
> The mpmc gets a compatible string that describes its management interface.
> The sdma port has information about the tx and rx interrupts and the slave
> management interface. Note that the slave management interface has the
> correct baseaddress for port3, generated from the base SDMA_CTRL_ address
> from the mpmc + the port 3 offset. Note that sdma has an artificial
> compatible name. I'm not sure whether the ll_dma driver can be easily
> convinced to bind to this, or whether the ll_temac driver will just traverse
> the device tree and then do a match against this.
Don't worry about having a too-sparse compatible property. Be
specific and we can always add entries to the bind list. For the IP
cores, always specify specific device versions in the compatible
entries.
>
> The temac works similarly, although the temac itself doesn't have a slave
> interface, so no compatible node for it. The sub nodes get the compatible
> string for the ll_temac driver. In this case, there is only one temac port
> active. Some of the parameters are specific to port 0, in which case the
> parameter names (e.g. phyaddr) are generated by stripping off the complete
> C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
> nodes, but are duplicated to make it easier for the driver to get the
> information out. At runtime, the driver has to follow the llink-connected
> path to find what it is connected to, and use the dma code, or the fifo
> code.
>
> the xps-ll-fifo structure is a bit simpler, with llink-connected pointing
> to the fifo, which looks like a 'normal' peripheral.
>
> Points for comment:
> 1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't
> correspond to a name in the .mhs) and not guaranteed to be unique. However,
> in the BSP generator it seems awkward to generate path references easily in
> a single pass. What I'd might prefer is:
> DDR2_SDRAM: mpmc@90000000 {
> sdma@3 {
>
> and refer to the sdma port using something like <&DDR2_SDRAM/sdma@3>, but I
> don't think you can do that in dtc?
If not, it is possible to extend the dtc syntax. Jon, David? Thoughts?
>
> 2) Not sure whether this is really simpler than just having a 'simple' node
> with both temacs and letting the driver sort everything out. In particular,
> I'm concerned about maintaining a bunch of semantic information about the
> ll_temac driver outside of the driver itself.
I wouldn't recommend it. It is better for probing to have one node
per logical device.
However, you could either have the network nodes as children of the
xps-ll-temac node, or they could be children of their addressable bus
and have phandles to the xps-ll-temac node...
In fact, if the network nodes are children of the xps-ll-temac node,
then the xps-ll-temac node should itself be a child of the addressable
bus (be it PLB or OPB).
Cheers,
g.
>
> 3) All of this is very different in structure from the way that the
> xparameters are organized. The ll_temac BSP code copies the xparameters out
> of the MPMC and they are simply other parameters of the ll_temac driver.
> Although the above structure better represents the actual system, there is
> another organization for people to be confused about.
>
> Steve
>
>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org
> on behalf of Stephen Neuendorffer
> Sent: Tue 11/20/2007 11:44 AM
> To: microblaze-uclinux@itee.uq.edu.au;
> linuxppc-dev@ozlabs.org; Grant Likely; Michal Simek
> Subject: Xilinx EDK BSP generation of device trees for microblaze and
> PowerPC
>
>
>
> I've updated some code from Michel Simek to generate Flat Device Trees
> from Xilinx EDK projects. This code is now hosted at:
> git://git.xilinx.com/gen-mhs-devtree.git
>
> This has one major advantage over the gen-mhs-devtree.py approach:
> default IP core parameters that are not specified in the mhs file can
> now be generated, since EDK pulls these in from the core .mpd file.
> I've also managed to incorporate a few more improvements from the
> previous review, so the BSP generator should include at least as much
> information as gen-mhs-devtree.py
>
> The next major order of business is to represent the DMA engines in the
> MPMC and locallink connections to the lltemac.
>
> Steve
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 1/2] usb: Remove broken optimisation in OHCI IRQ handler
From: Benjamin Herrenschmidt @ 2007-11-25 22:54 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb-devel
The OHCI IRQ handler has an optimisation that tries to avoid reading
the status register when it sees something has been put in the
controller "done list".
This optimisation is broken on controllers that use edge interrupt
signaling as it relies on "missed" interrupt to be re-emitted which
is not the case with egde interrupts. Among others, it breaks the
OHCI SoC controller in the AMCC 440EP PowerPC processor (and according
to David, it also breaks the SA1111).
This patch removes the optimisation along with making the code a little
bit less convoluted.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
While there, any reason why we do the read of the interenable register
and mask ? Is that actually useful in practice ? I haven't removed it
but it might be a good candidate if we want to save on MMIO reads.
drivers/usb/host/ohci-hcd.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
Index: linux-work/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-work.orig/drivers/usb/host/ohci-hcd.c 2007-11-26 09:14:12.000000000 +1100
+++ linux-work/drivers/usb/host/ohci-hcd.c 2007-11-26 09:16:40.000000000 +1100
@@ -732,24 +732,25 @@ static irqreturn_t ohci_irq (struct usb_
struct ohci_regs __iomem *regs = ohci->regs;
int ints;
- /* we can eliminate a (slow) ohci_readl()
- * if _only_ WDH caused this irq
- */
- if ((ohci->hcca->done_head != 0)
- && ! (hc32_to_cpup (ohci, &ohci->hcca->done_head)
- & 0x01)) {
- ints = OHCI_INTR_WDH;
+ /* Read interrupt status & flush pending DMAs */
+ ints = ohci_readl (ohci, ®s->intrstatus);
- /* cardbus/... hardware gone before remove() */
- } else if ((ints = ohci_readl (ohci, ®s->intrstatus)) == ~(u32)0) {
+ /* Check for an all 1's result which is the consequence of a
+ * dead or unplugged device
+ */
+ if (ints == ~(u32)0) {
disable (ohci);
ohci_dbg (ohci, "device removed!\n");
return IRQ_HANDLED;
+ }
+
+ /* We only care about interrupts that are enabled */
+ ints &= ohci_readl (ohci, ®s->intrenable);
+
/* interrupt for some other device? */
- } else if ((ints &= ohci_readl (ohci, ®s->intrenable)) == 0) {
+ if (ints == 0)
return IRQ_NOTMINE;
- }
if (ints & OHCI_INTR_UE) {
// e.g. due to PCI Master/Target Abort
^ permalink raw reply
* [PATCH 2/2] usb: Remove OHCI useless masking/unmasking of WDH interrupt
From: Benjamin Herrenschmidt @ 2007-11-25 22:54 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-usb-devel
The OHCI driver's IRQ handler, while processing a WDH interrupt, masks
and unmasks it. I believe this is both broken (no dealign with write
posting) and totally useless as the IRQ cannot re-occur while we are in
the handler anyway.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
It might be a leftover related to the bogus optmisation that I've removed
in a separate patch. Anyway, I don't think it's any use so let's remove
to useless MMIO writes.
drivers/usb/host/ohci-hcd.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux-work/drivers/usb/host/ohci-hcd.c
===================================================================
--- linux-work.orig/drivers/usb/host/ohci-hcd.c 2007-11-26 09:17:52.000000000 +1100
+++ linux-work/drivers/usb/host/ohci-hcd.c 2007-11-26 09:17:58.000000000 +1100
@@ -807,13 +807,9 @@ static irqreturn_t ohci_irq (struct usb_
}
if (ints & OHCI_INTR_WDH) {
- if (HC_IS_RUNNING(hcd->state))
- ohci_writel (ohci, OHCI_INTR_WDH, ®s->intrdisable);
spin_lock (&ohci->lock);
dl_done_list (ohci);
spin_unlock (&ohci->lock);
- if (HC_IS_RUNNING(hcd->state))
- ohci_writel (ohci, OHCI_INTR_WDH, ®s->intrenable);
}
if (quirk_zfmicro(ohci) && (ints & OHCI_INTR_SF)) {
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-25 22:55 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
In-Reply-To: <fa686aa40711251421q38f53ee3hb2a308cc5f93183f@mail.gmail.com>
Grant Likely wrote:
> nope, not at all the same as dynamic detection; just backwards
> compatibility with the way we do it now for arch/ppc.
>
Other things being equal a common architecture is preferable to a
collection of independent ones.
>
>
> No, it doesn't make sense to store is in the FPGA fabric; but if the
> design already contains BRAM then it could be placed there and
> reclaimed for other purposes after booting. Or anywhere in RAM for
> that matter. I don't know how feasible is to load a device tree into
> SDRAM at FPGA config time.
>
I am not expert on this, but at Pico we already store our boot
monitor in the .bit files in BRAM.
But that is not free. It is one of the reasons we do not use
u-boot. Our boot monitor must fit into 16K of BRAM.
Must be able to perform selftests on critical hardware, support a
flash file system, load bit files from flash to the FGA, load and
exectute elf files, allow a small set of user commands, and handle
hosted vs. standalone operation.
And aparently extract the devicetree from a bit file and pass it to
a linux kernel.
> Ah; I think I see the disconnect we're having. Device trees are not
> about, *and never have been about*, device detection. The device tree
> is simply the communication medium used to describe the hardware. It
> doesn't matter if you choose to use a 100% dynamically generated
> device tree from intelligent firmware or a 100% static device tree
> blob. All that matters is that the kernel is able to trust the
> information handed to it by firmware.
>
> Device detection is not a problem that the device tree is designed to solve.
>
> It is designed to solve the problem of telling the kernel what the
> platform looks like (which occurs after the detection stage).
>
In static or fairly static hardware, that's fine. Even in somewhat
dynamic hardware with large quantities of startup resources - like a PC.
But in highly dynamic hardware with fairly limited resources it
starts to become an issue.
Still if xilinx intends to generate the device tree with the bit
file - even better appended to the bit file or embedded in the FPGA if
feasible,
this could still work.
I do not see Detection as independent of communication.
Aside from a very minimal core, If device drivers can do a good job
of validating their hardware (back to my version registers issue in
another post) and I just load them willy nilly and let the ones that
have no hardware fail (Gross over simplification, but still viable) then
a communication scheme is meaningless. Going the opposite direction, if
I do not have the resources to detect the hardware and build the
devicetree dynamically, AND I have highly dynamic hardware, AND I do
not have an easy method I can trust of aquiring another source for the
hardware description, devicetree's aren't any help. There are alot of
AND's there but most if not all appear to be present with FPGA based
systems.
> arch/powerpc support for Virtex is now in Linus' mainline tree which
> will become 2.6.24
>
Guess it is time to pull Linus again.
> No, unfortunately they don't deal with the problem you're facing
> (which I'm facing also). But it will be solved if we figure out a
> sane way to bind the device tree up with the FPGA bitstream without
> consuming FPGA resources.
>
Note to Xilinx:
There MUST be some way of binding a device description to a bit file.
neither building it into the FPGA fabric nor appending it to the end
of the bit file are perfect solutions,
The former is more powerfull and flexible but wastes precious
resources. The later is more complex and puts more burdens on
software developers, and may be completely unfeasible in some
environments - not mine fortunately.
Regardless, something must be done. An odd collection of devicetree
files co-mingled with a collection of bit files, is little better than
xparameter files all over the place.
And once again a plea to ALWAYS make version/capabilities registers
atleast an optional part of every design.
Embeddeding a device tree into a design might be fairly expensive. a
pair of read only 32 bit registers is damn near free - basically the
FPGA equivalent of atmost 64 diodes or resistors.
> Cheers,
> g.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* RE: SPI, I2C
From: Stephen Neuendorffer @ 2007-11-25 23:17 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <4749441B.1000703@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]
The drivers for these do exist (see git.xilinx.com). I suppose as a 'control' bus, they might actually be useful inside an FPGA, but why not just use dcr? Part of the value of i2c is minimizing wires (including power wires), but that's hardly a design constraint in an FPGA compared to conserving logic.
I also got fed up with the i2c core at one point and wrote a bitbang version for the gpio. It might be a bit slower, but it's dirt simple. I can send it do you, if you're interested.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 1:44 AM
To: linuxppc-embedded
Subject: SPI, I2C
I have been asked to do SPI and I2C drivers for Pico cards.
I am trying to grasp what the practical use of either could be in an
environment where neither SPI nor I2C are going to be able to
communicate outside the FPGA.
I am guessing that SPI and I2C implementations already exist for
Xilinx FPGA's - any chance that drivers might already exist ?
I would prefer not to charge a client to reinvent something that
exists, or that can not serve a useful purpose.
I am not trying to imply that SPI or I2C are not useful, just that
they are communications channels, and unless they have outside I2C or
SPI hardware to talk to what purpose might they serve ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3492 bytes --]
^ permalink raw reply
* [RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Benjamin Herrenschmidt @ 2007-11-25 23:41 UTC (permalink / raw)
To: David Airlie; +Cc: linuxppc-dev, dri-devel, linux-kernel
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/char/drm/ati_pcigart.c | 6 ++++++
drivers/char/drm/drm_scatter.c | 12 +++++++++++-
drivers/char/drm/drm_vm.c | 20 +++++++++++++++-----
3 files changed, 32 insertions(+), 6 deletions(-)
Index: linux-work/drivers/char/drm/ati_pcigart.c
===================================================================
--- linux-work.orig/drivers/char/drm/ati_pcigart.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/ati_pcigart.c 2007-11-26 10:21:33.000000000 +1100
@@ -214,6 +214,12 @@ int drm_ati_pcigart_init(struct drm_devi
}
}
+ if (gart_info->gart_table_location == DRM_ATI_GART_MAIN)
+ dma_sync_single_for_device(&dev->pdev->dev,
+ bus_address,
+ max_pages * sizeof(u32),
+ PCI_DMA_TODEVICE);
+
ret = 1;
#if defined(__i386__) || defined(__x86_64__)
Index: linux-work/drivers/char/drm/drm_scatter.c
===================================================================
--- linux-work.orig/drivers/char/drm/drm_scatter.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/drm_scatter.c 2007-11-26 10:20:08.000000000 +1100
@@ -36,6 +36,16 @@
#define DEBUG_SCATTER 0
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
+ PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vmalloc_32(size);
+#endif
+}
+
void drm_sg_cleanup(struct drm_sg_mem * entry)
{
struct page *page;
@@ -104,7 +114,7 @@ int drm_sg_alloc(struct drm_device *dev,
}
memset((void *)entry->busaddr, 0, pages * sizeof(*entry->busaddr));
- entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
+ entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
if (!entry->virtual) {
drm_free(entry->busaddr,
entry->pages * sizeof(*entry->busaddr), DRM_MEM_PAGES);
Index: linux-work/drivers/char/drm/drm_vm.c
===================================================================
--- linux-work.orig/drivers/char/drm/drm_vm.c 2007-11-26 10:07:29.000000000 +1100
+++ linux-work/drivers/char/drm/drm_vm.c 2007-11-26 10:11:09.000000000 +1100
@@ -54,13 +54,24 @@ static pgprot_t drm_io_prot(uint32_t map
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
pgprot_val(tmp) |= _PAGE_GUARDED;
-#endif
-#if defined(__ia64__)
+#elif defined(__ia64__)
if (efi_range_is_wc(vma->vm_start, vma->vm_end -
vma->vm_start))
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
+#elif defined(__sparc__)
+ tmp = pgprot_noncached(tmp);
+#endif
+ return tmp;
+}
+
+static pgprot_t drm_dma_prot(uint32_t map_type, struct vm_area_struct *vma)
+{
+ pgprot_t tmp = vm_get_page_prot(vma->vm_flags);
+
+#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
+ tmp |= _PAGE_NO_CACHE;
#endif
return tmp;
}
@@ -617,9 +628,6 @@ static int drm_mmap_locked(struct file *
offset = dev->driver->get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
vma->vm_page_prot = drm_io_prot(map->type, vma);
-#ifdef __sparc__
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-#endif
if (io_remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
@@ -638,6 +646,7 @@ static int drm_mmap_locked(struct file *
page_to_pfn(virt_to_page(map->handle)),
vma->vm_end - vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
+ vma->vm_page_prot = drm_dma_prot(map->type, vma);
/* fall through to _DRM_SHM */
case _DRM_SHM:
vma->vm_ops = &drm_vm_shm_ops;
@@ -650,6 +659,7 @@ static int drm_mmap_locked(struct file *
vma->vm_ops = &drm_vm_sg_ops;
vma->vm_private_data = (void *)map;
vma->vm_flags |= VM_RESERVED;
+ vma->vm_page_prot = drm_dma_prot(map->type, vma);
break;
default:
return -EINVAL; /* This should never happen. */
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-25 23:58 UTC (permalink / raw)
To: David H. Lynch Jr., Grant Likely, linuxppc-embedded
In-Reply-To: <4749FD5E.7000408@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
I understand that you're trying to be somewhat of a devil's advocate here, but (as I mentioned in my other email), alot of these are issues we're attempting to tackle.
More comments below.
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of David H. Lynch Jr.
Sent: Sun 11/25/2007 2:55 PM
To: Grant Likely; linuxppc-embedded
Subject: Re: Xilinx devicetrees
Grant Likely wrote:
> I am not expert on this, but at Pico we already store our boot
> monitor in the .bit files in BRAM.
> But that is not free. It is one of the reasons we do not use
> u-boot. Our boot monitor must fit into 16K of BRAM.
> Must be able to perform selftests on critical hardware, support a
> flash file system, load bit files from flash to the FGA, load and
> exectute elf files, allow a small set of user commands, and handle
> hosted vs. standalone operation.
> And aparently extract the devicetree from a bit file and pass it to
> a linux kernel.
Once you can load a bitstream from flash, loading the device tree from flash
should be practically free. In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?)
> In static or fairly static hardware, that's fine. Even in somewhat
> dynamic hardware with large quantities of startup resources - like a PC.
> But in highly dynamic hardware with fairly limited resources it
> starts to become an issue.
As Grant says, the dynamic detection doesn't have to be done in the boot loader, it could be done in the platform code. You can largely ignore the device trees, or always boot with a core device tree and figure it all out later (perhaps using version registers). I anticipate that the 'standard flow' will have standard platform code for any board that uses a complete device tree. If you have the need to do something extraordinary, then you should feel free to hack away... However, It doesn't seem to me to be really necessary in your case, assuming that the device tree is packaged (somehow, TBD) along with the bitstream.
>> No, unfortunately they don't deal with the problem you're facing
>> (which I'm facing also). But it will be solved if we figure out a
>> sane way to bind the device tree up with the FPGA bitstream without
>> consuming FPGA resources.
>>
> Note to Xilinx:
>
> There MUST be some way of binding a device description to a bit file.
>
> neither building it into the FPGA fabric nor appending it to the end
> of the bit file are perfect solutions,
> The former is more powerfull and flexible but wastes precious
> resources. The later is more complex and puts more burdens on
> software developers, and may be completely unfeasible in some
> environments - not mine fortunately.
I don't understand the 'burden on software developers'. The code to do this will just be standard code. The worst that one can say is:
1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint.
2) I can't use compile time optimization based on xparameters as easily. Anyone want to implement the alternatives mechanism on ppc and microblaze?
3) Some additional boot time. However, again, this seems marginal.
> Regardless, something must be done. An odd collection of devicetree
> files co-mingled with a collection of bit files, is little better than
> xparameter files all over the place.
Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. That (and how it is interpreted by the platform code) should be generated in a consistent fashion by EDK. See my other email for some of the possibilities. Are there specific reasons why you think those proposals are inadequate? Now is the time when we can take criticism, with the goal towards making a good end solution.
> And once again a plea to ALWAYS make version/capabilities registers
> atleast an optional part of every design.
> Embeddeding a device tree into a design might be fairly expensive. a
> pair of read only 32 bit registers is damn near free - basically the
> FPGA equivalent of atmost 64 diodes or resistors.
Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand?
Steve
[-- Attachment #2: Type: text/html, Size: 5534 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2007-11-26 0:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Paul Mundt, linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <200711242150.09812.arnd@arndb.de>
On Sat, Nov 24, 2007 at 09:50:07PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> > Here is the PATA Platform driver using OF infrastructure.
> >
> > Mostly it's just a wrapper around a bit modified pata_platform
> > driver.
>
> Thanks a lot for doing this. Patches 2/3 are what I tried to get
> people to do for some time now but was too lazy to do myself.
>
> As a further thought, do the drivers now still need to be
> pata specific, or should the OF part be called ata_of_platform
> instead and also be used for sata devices?
Ugh, I don't know much about sata, it should act just as a pata
in the very basic usage, IIRC. So it's worth trying, but I don't
have any platform satas to try... :-/
Hereby, I'd rather stick with pata name, as it's never too late
to simply rename things later.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2007-11-26 0:23 UTC (permalink / raw)
To: Paul Mundt; +Cc: linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <20071124072613.GA7303@linux-sh.org>
On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > Anton Vorontsov wrote:
> > >Here is the PATA Platform driver using OF infrastructure.
> > >
> > >Mostly it's just a wrapper around a bit modified pata_platform
> > >driver.
> > >
> > >Patches are well split for the easier review:
> > >
> > >First one factors out platform_device specific bits and modifies
> > >pata_platform to be a library-alike driver (with platform_device
> > >default binding).
> > >
> The only issue I have here is that this library-like version has subtle
> semantic changes that will break existing drivers.
Actually I've tried to keep semantics intact:
+static int __devinit pata_platform_probe(struct platform_device *pdev)
[...]
+ /*
+ * And the IRQ
+ */
+ irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = pp_info ? pp_info->irq_flags : 0;
[...]
So, I'm passing flags from the platform data. Did you overlook these
bits, or I'm still changing semantics somewhere else?
> irq_flags exists in struct pata_platform_info precisely for the IRQ
> resource IRQ flags (as opposed to the IORESOURCE flags, which are what
> the IRQ resource flags refer to instead). This change takes that for
> granted and just assumes we're going to be using the res->flags, which is
> both an invalid assumption, and will utterly break blackfin and others
> that depend on it.
>
> Incidentally, we already have an include/linux/pata_platform.h. If this
> is going to be library-like, through the prototypes in there, rather than
> splitting them up betewen include/linux and drivers/ata. We don't need
> two headers.
My intention was: keep "private" declarations in the drivers/ata/ and
"public" in the include/linux/ -- to not confuse pata_platform users
by __pata_platform_* internal stuff. But okay, I'll merge them.
> These patches basically look fine to me otherwise, though it would be
> nice if the semantic-changing bits had been abstracted. So as long as the
> old irq_flags behaviour is maintained and that irq_res->flags stuff is
> ripped out, I'll add my Acked-by as well.
Much thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce pata node, make use pata_of_platform driver
From: Anton Vorontsov @ 2007-11-26 0:34 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <200711242157.47303.arnd@arndb.de>
On Sat, Nov 24, 2007 at 09:57:46PM +0100, Arnd Bergmann wrote:
> On Friday 23 November 2007, Anton Vorontsov wrote:
> >
> > +static struct of_device_id mpc834x_ids[] = {
> > + { .compatible = "pata-platform", },
> > + {},
> > +};
> > +
> > +static int __init mpc834x_declare_of_platform_devices(void)
> > +{
> > + if (!machine_is(mpc834x_itx))
> > + return 0;
> > +
> > + of_platform_bus_probe(NULL, mpc834x_ids, NULL);
> > +
> > + return 0;
> > +}
> > +device_initcall(mpc834x_declare_of_platform_devices);
>
> This is not really how of_platform_bus_probe was meant to be used.
> Instead of listing the device you want to probe, you should list
> all buses that potentially contain a device that you are probing.
Yup, I sort of knew it. For mpc8349emitx, pata node should be in
the localbus node. But there is no localbus node yet... I'll fix
that issue in the next round of these patches.
Much thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Paul Mundt @ 2007-11-26 1:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Jeff Garzik, linux-ide
In-Reply-To: <20071126002314.GA20104@zarina>
On Mon, Nov 26, 2007 at 03:23:14AM +0300, Anton Vorontsov wrote:
> On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote:
> > On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> > > Anton Vorontsov wrote:
> > > >Here is the PATA Platform driver using OF infrastructure.
> > > >
> > > >Mostly it's just a wrapper around a bit modified pata_platform
> > > >driver.
> > > >
> > > >Patches are well split for the easier review:
> > > >
> > > >First one factors out platform_device specific bits and modifies
> > > >pata_platform to be a library-alike driver (with platform_device
> > > >default binding).
> > > >
> > The only issue I have here is that this library-like version has subtle
> > semantic changes that will break existing drivers.
>
> Actually I've tried to keep semantics intact:
>
> +static int __devinit pata_platform_probe(struct platform_device *pdev)
> [...]
> + /*
> + * And the IRQ
> + */
> + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + if (irq_res)
> + irq_res->flags = pp_info ? pp_info->irq_flags : 0;
> [...]
>
> So, I'm passing flags from the platform data. Did you overlook these
> bits, or I'm still changing semantics somewhere else?
>
Oh, I overlooked that. Using irq_res->flags as a temporary for
pp_info->irq_flags seems a bit hacky, but as long as pp_info->irq_flags
semantics are intact, I'm not too violently opposed to this anyways.
> > Incidentally, we already have an include/linux/pata_platform.h. If this
> > is going to be library-like, through the prototypes in there, rather than
> > splitting them up betewen include/linux and drivers/ata. We don't need
> > two headers.
>
> My intention was: keep "private" declarations in the drivers/ata/ and
> "public" in the include/linux/ -- to not confuse pata_platform users
> by __pata_platform_* internal stuff. But okay, I'll merge them.
>
I suppose that depends on whether the intent is that all pata_platform
users will be stuck in drivers/ata or not. If this is treated as more of
a library, implementations can simply bury themselves in arch/ land if
they feel like it.
^ permalink raw reply
* The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
From: 郭劲 @ 2007-11-26 3:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I runed the LTIB for MPC8360,selected "configure the kernel", then the make
menuconfig is appeared,that is "linux kernel configuration". I config QE to
follow
style:
UCC1,GETH;
UCC2,GETH;
UCC5,UART;
UCC6,UART;
UCC7,UART;
UCC8,UART.
after compiled, I download the linux to MPC8360 board, but I cannot find the
serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK.
Could you tell me that what's the name for the serial device of UCC5,6,7,8?
Whether or not I can use those UART just like the ttyS0,ttyS1?
>Follow is the device name in linux for MPC8360.
>/dev # ls
>audio hdb5 mtdblock4 ram2 sdc3 tty6 ttyp0
>audio1 hdb6 mtdblock5 ram3 sdc4 tty7 ttyp1
>buttons hdb7 mtdblock6 random sdc5 ttyAM0 ttyp2
>console input net rtc sdc6 ttyAM1 ttyp3
>dsp kmem null sda sdc7 ttyAM2 ttyp4
>dsp1 loop0 ppp sda1 sdd ttyAM3 ttyp5
>fb0 loop1 psaux sda2 sdd1 ttyCPM0 ttyp6
>fb1 md0 ptmx sda3 sdd2 ttyCPM1 ttyp7
>fb2 md1 pts sda4 sdd3 ttyP0 ttyp8
>fb3 md2 ptyp0 sda5 sdd4 ttyP1 ttyp9
>hda md3 ptyp1 sda6 sdd5 ttyP2 ubda
>hda1 mem ptyp2 sda7 sdd6 ttyP3 ubda1
>hda2 mtd0 ptyp3 sdb sdd7 ttyPSC0 ubda2
>hda3 mtd1 ptyp4 sdb1 shm ttyPSC1 ubda3
>hda4 mtd2 ptyp5 sdb2 sndstat ttyPSC2 ubda4
>hda5 mtd3 ptyp6 sdb3 ts ttyPSC3 ubda5
>hda6 mtd4 ptyp7 sdb4 tty ttyPSC4 ubda6
>hda7 mtd5 ptyp8 sdb5 tty0 ttyPSC5 ubda7
>hdb mtd6 ptyp9 sdb6 tty1 ttyS0 urandom
>hdb1 mtdblock0 qspi sdb7 tty2 ttyS1 watchdog
>hdb2 mtdblock1 ram sdc tty3 ttyS2 zero
>hdb3 mtdblock2 ram0 sdc1 tty4 ttyS3
>hdb4 mtdblock3 ram1 sdc2 tty5 ttymxc0
>/dev # cat ttyS0
>
>/dev # cat ttyS1
>
>/dev # cat ttyS2
>cat: ttyS2: No such device or address
>/dev # cat ttyPSC0
>cat: ttyPSC0: No such device or address
>/dev # cat ttyP0
>cat: ttyP0: No such device or address
>/dev # cat ttyp0
>cat: ttyp0: Input/output error
>/dev # cat ttyAM0
>cat: ttyAM0: No such device or address
>/dev # cat ttyCPM0
>cat: ttyCPM0: No such device or address
>/dev #
^ permalink raw reply
* The question about the high memory support on MPC8360?
From: 郭劲 @ 2007-11-26 3:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I plug in 1GB DDR-1 on my MPC8360 board, the u-boot-1.2.0 found the DDR storage
is 1GB, but the linux just found 773504k. please see follow information.
I think I need to config the kernel to support the high memory. but if I config
the kernel to select the "high memory support" under the "platform options" on
"linux kernel configuration" during compile, the kernel is not to boot. if I
cancel this options, the kernel is ok to run.
why? how to deal with this problem? there are two DIMM-184 slots on my MPC8360
board, I want to support total 2GB DDR-1 storage. now I want to try 1GB on one of
DIMM-184 slots firstly.
please see follow information. Thanks.
~ # dmesg
Linux version 2.6.11 (olivia@bamboo) (gcc version 3.4.3) #1 Thu Jul 12 14:29:297
On node 0 totalpages: 196608
DMA zone: 196608 pages, LIFO batch:16
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/ram0
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
QE IC (64 IRQ sources) at fe100080
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 773504k available (1724k kernel code, 432k data, 100k init, 0k highmem)
Calibrating delay loop... 351.23 BogoMIPS (lpj=175616)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 3120k freed
NET: Registered protocol family 16
Registering ipic with sysfs...
SCSI subsystem initialized
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
MPC8360E PB flash device: 2000000 at fe000000 Partition number 6
MPC8360E PB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank
MPC8360E PB Flash Map Info: Found an alias at 0x1000000 for the chip at 0x0
Support for command set 0001 not present
gen_probe: No supported Vendor Command Set found
i2c /dev entries driver
eth0: Running with NAPI disabled
eth1: Running with NAPI disabled
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 100k init
eth0: PHY is Marvell 88E11x1 (1410cc1)
eth0: Full Duplex
eth0: Speed 1000BT
eth0: Link is up
U-Boot 1.2.0 (Nov 21 2007 - 16:05:15) MPC83XX
CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM:
DIMM type:
SPD size: 128
EEPROM size: 256
Memory type: 7
Row addr: 13
Column addr: 11
# of rows: 2
Row density: 128
# of banks: 4
Data width: 64
Chip width: 8
Refresh rate: 82
CAS latencies: 1C
Write latencies: 02
tRP: 60
tRCD: 60
DDR DIMM: data bus width is 64 bit without ECC
DDRC ECC mode: OFF
SDRAM on Local Bus: 64 MB
DDR RAM: 1024 MB
FLASH: 16 MB
PCI clock is 66MHz
PCI 32bit bus on PMC1 & PMC2 & PMC3
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc1)
FSL UEC0: Full Duplex
FSL UEC0: Speed 1000BT
FSL UEC0: Link is up
FSL UEC0
Hit any key to stop autoboot: 0
=> bootm fed00000 fe900000
## Booting image at fed00000 ...
Image Name: Linux-2.6.11
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1054435 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fe900000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3195657 Bytes = 3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-26 6:11 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <396049508.10992@tsinghua.org.cn>
Hi friends,
Kernel virtual space is divided into 3 different zones namely ZONE_DMA,=20
ZONE_NORMAL, ZONE_HIGHMEM.Remember that the kernel follows the 3GB/1GB=20
split ie 3 GB for user space and 1 GB for kernel space. Since your ram=20
is 1 GB, 896 MB will be mapped one to one with the kernel virtual space.=20
This one to one mapping will be done in the ZONE_NORMAL and ZONE_DMA of=20
kernel virtual space.Remaining 128 MB of kernel virtual address space=20
will be used for setting up kernel data structures and for ioremaps and=20
vmallocs that the kernel will need to perform during boot up. If u=20
configure high memory this 128 MB will be used for accessing unmapped=20
memory regions in the ram and there wont be sufficient virtual=20
addresses for ioremaps and vmallocs. Thats why your kernel did not boot=20
when high mem is configured.
Since u want to have 1 GB of ram an alternative to=20
this is that u can try 2 GB/ 2 GB split which is configurable ie 2 GB=20
for user space and 2 GB for kernel space in your kernel.
Thanks and Regards,
vijai
=E9=83=AD=E5=8A=B2 wrote:
>Hi,friends,=20
> I plug in 1GB DDR-1 on my MPC8360 board, the u-boot-1.2.0 found the DD=
R storage
>is 1GB, but the linux just found 773504k. please see follow information=
.
> I think I need to config the kernel to support the high memory. but i=
f I config
>the kernel to select the "high memory support" under the "platform optio=
ns" on
>"linux kernel configuration" during compile, the kernel is not to boot. =
if I
>cancel this options, the kernel is ok to run.
> why? how to deal with this problem? there are two DIMM-184 slots on m=
y MPC8360
>board, I want to support total 2GB DDR-1 storage. now I want to try 1GB =
on one of=20
>DIMM-184 slots firstly.
> please see follow information. Thanks.
>
>
>~ # dmesg =
=20
>Linux version 2.6.11 (olivia@bamboo) (gcc version 3.4.3) #1 Thu Jul 12 1=
4:29:297
>On node 0 totalpages: 196608 =
=20
> DMA zone: 196608 pages, LIFO batch:16 =
=20
> Normal zone: 0 pages, LIFO batch:1 =
=20
> HighMem zone: 0 pages, LIFO batch:1 =
=20
>Built 1 zonelists =
=20
>Kernel command line: console=3DttyS0,115200 root=3D/dev/ram0 =
=20
>IPIC (128 IRQ sources, 8 External IRQs) at fe000700 =
=20
>QE IC (64 IRQ sources) at fe100080 =
=20
>PID hash table entries: 4096 (order: 12, 65536 bytes) =
=20
>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) =
=20
>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) =
=20
>Memory: 773504k available (1724k kernel code, 432k data, 100k init, 0k h=
ighmem)=20
>Calibrating delay loop... 351.23 BogoMIPS (lpj=3D175616) =
=20
>Mount-cache hash table entries: 512 (order: 0, 4096 bytes) =
=20
>checking if image is initramfs...it isn't (no cpio magic); looks like an=
initrd=20
>Freeing initrd memory: 3120k freed =
=20
>NET: Registered protocol family 16 =
=20
>Registering ipic with sysfs... =
=20
>SCSI subsystem initialized =
=20
>JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc. =
=20
>Generic RTC Driver v1.07 =
=20
>Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disable=
d =20
>ttyS0 at MMIO 0xe0004500 (irq =3D 9) is a 16550A =
=20
>ttyS1 at MMIO 0xe0004600 (irq =3D 10) is a 16550A =
=20
>io scheduler noop registered =
=20
>io scheduler anticipatory registered =
=20
>io scheduler deadline registered =
=20
>io scheduler cfq registered =
=20
>RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize =
=20
>loop: loaded (max 8 devices) =
=20
>MPC8360E PB flash device: 2000000 at fe000000 Partition number 6 =
=20
>MPC8360E PB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank =
=20
>MPC8360E PB Flash Map Info: Found an alias at 0x1000000 for the chip at =
0x0 =20
>Support for command set 0001 not present =
=20
>gen_probe: No supported Vendor Command Set found =
=20
>i2c /dev entries driver =
=20
>eth0: Running with NAPI disabled =
=20
>eth1: Running with NAPI disabled =
=20
>NET: Registered protocol family 2 =
=20
>IP: routing cache hash table of 8192 buckets, 64Kbytes =
=20
>TCP established hash table entries: 131072 (order: 8, 1048576 bytes) =
=20
>TCP bind hash table entries: 65536 (order: 6, 262144 bytes) =
=20
>TCP: Hash tables configured (established 131072 bind 65536) =
=20
>NET: Registered protocol family 1 =
=20
>NET: Registered protocol family 17 =
=20
>RAMDISK: Compressed image found at block 0 =
=20
>VFS: Mounted root (ext2 filesystem) readonly. =
=20
>Freeing unused kernel memory: 100k init =
=20
>eth0: PHY is Marvell 88E11x1 (1410cc1) =
=20
>eth0: Full Duplex =
=20
>eth0: Speed 1000BT =
=20
>eth0: Link is up
>
>
>U-Boot 1.2.0 (Nov 21 2007 - 16:05:15) MPC83XX =
=20
> =
=20
>CPU: e300c1, MPC8360E, Rev: 20 at 528 MHz, CSB: 264 MHz =
=20
>Board: Freescale MPC8360EMDS =
=20
>I2C: ready =
=20
>DRAM: =
=20
>DIMM type: =
=20
>SPD size: 128 =
=20
>EEPROM size: 256 =
=20
>Memory type: 7 =
=20
>Row addr: 13 =
=20
>Column addr: 11 =
=20
># of rows: 2 =
=20
>Row density: 128 =
=20
># of banks: 4 =
=20
>Data width: 64 =
=20
>Chip width: 8 =
=20
>Refresh rate: 82 =
=20
>CAS latencies: 1C =
=20
>Write latencies: 02 =
=20
>tRP: 60 =
=20
>tRCD: 60 =
=20
> =
=20
> =
=20
> DDR DIMM: data bus width is 64 bit without ECC =
=20
> DDRC ECC mode: OFF =
=20
> =
=20
> SDRAM on Local Bus: 64 MB =
=20
> DDR RAM: 1024 MB =
=20
>FLASH: 16 MB =
=20
>PCI clock is 66MHz =
=20
>PCI 32bit bus on PMC1 & PMC2 & PMC3 =
=20
>In: serial =
=20
>Out: serial =
=20
>Err: serial =
=20
>Net: UEC: PHY is Marvell 88E11x1 (1410cc1) =
=20
>FSL UEC0: Full Duplex =
=20
>FSL UEC0: Speed 1000BT =
=20
>FSL UEC0: Link is up =
=20
>FSL UEC0 =
=20
>Hit any key to stop autoboot: 0 =
=20
>=3D> bootm fed00000 fe900000 =
=20
>## Booting image at fed00000 ... =
=20
> Image Name: Linux-2.6.11 =
=20
> Image Type: PowerPC Linux Kernel Image (gzip compressed) =
=20
> Data Size: 1054435 Bytes =3D 1 MB =
=20
> Load Address: 00000000 =
=20
> Entry Point: 00000000 =
=20
> Verifying Checksum ... OK =
=20
> Uncompressing Kernel Image ... OK =
=20
>## Loading RAMDisk Image at fe900000 ... =
=20
> Image Name: uboot ext2 ramdisk rootfs =
=20
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed) =
=20
> Data Size: 3195657 Bytes =3D 3 MB =
=20
> Load Address: 00000000 =
=20
> Entry Point: 00000000 =
=20
> Verifying Checksum ... OK =
=20
> Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> =20
>
^ permalink raw reply
* Re: [PATCH] [PPC 44x] L2-cache synchronization for ppc44x
From: Benjamin Herrenschmidt @ 2007-11-26 6:47 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <608329302.20071108021252@emcraft.com>
On Thu, 2007-11-08 at 02:12 +0300, Yuri Tikhonov wrote:
> This is the updated patch for support synchronization of L2-Cache with the external memory on the ppc44x-based platforms.
>
> Differencies against the previous patch-set:
> - remove L2_CACHE config option;
> - introduce the ppc machdep to invalidate L2 cache lines;
> - some code clean-up.
>
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
> Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
It's almost right :-0
You want something a bit more details than just a
ppc_md.l2cache_inv_range.
I'd suggest you do a separate extcache_ops structure that contains
callbacks for all 3 directions (flush, flush & invalidate, invalidate),
then fill that up accordingly.
It might be a good idea in the long run to do some tricks to avoid a
branch via function pointer since the cache ops are pretty "hot", but if
that ever happens, I'll do that via asm patching tricks I suppose.
Now regarding the line size, I would recommend using the device-tree to
describe the cache instead rather than a config option. The intend is to
be able to build a single binary kernel that can boot multiple variants
of 44x.
I may eventually rewrite your patch around those ideas next week if you
don't feel like doing it -and- I get bored :-)
Cheers,
Ben.
^ permalink raw reply
* Re: MontaVista 4.0.1 on Xilinx ML405 board
From: schardt @ 2007-11-26 7:12 UTC (permalink / raw)
To: gsk19; +Cc: linuxppc-embedded
In-Reply-To: <20071123185858.DSC68826@mas23.bezeqint.net>
lock up the location of the __log_buf in the System.map and check if
errormessages are stored there in the memory.
check the console device. it must be /dev/ttyULx
Georg
gsk19@bezeqint.net wrote:
> We built a design for ML405 using EDK 9.1.02. EDK also
> creates linux drivers for MontaVista Pro 4.0.1 (2.6.10).
> The drivers were copied to a clean copy of Pro 4.0.1 and the
> kernel was built. When we downloaded the kernel to the target
> and ran it, we got exception. We didn't get any messages on
> the hyper terminal.
> We used Tri-Mode Ethernet and UART lite.
> MontaVista checked the integration of EDK 8.2 with ML403.
> Can you help ?
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ permalink raw reply
* [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-26 7:46 UTC (permalink / raw)
To: PPCML; +Cc: Olof Johansson, Paul Mackerras, LKML
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
This patch adds checking for NULL value returned to prevent possible
NULL pointer dereference.
Also two unneeded 'return' are removed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
Any comments are welcome.
[-- Attachment #2: ppc-celleb-fix-null.diff --]
[-- Type: text/plain, Size: 2105 bytes --]
arch/powerpc/platforms/celleb/pci.c | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..9b8bb01 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -348,9 +345,25 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
pr_debug("PCI: res assigned 0x%016lx\n", (unsigned long)*res);
wi0 = of_get_property(node, "device-id", NULL);
+ if (unlikely((!wi0))) {
+ printk(KERN_ERR "PCI: device-id not found.\n");
+ goto error;
+ }
wi1 = of_get_property(node, "vendor-id", NULL);
+ if (unlikely((!wi1))) {
+ printk(KERN_ERR "PCI: vendor-id not found.\n");
+ goto error;
+ }
wi2 = of_get_property(node, "class-code", NULL);
+ if (unlikely((!wi2))) {
+ printk(KERN_ERR "PCI: class-code not found.\n");
+ goto error;
+ }
wi3 = of_get_property(node, "revision-id", NULL);
+ if (unlikely((!wi3))) {
+ printk(KERN_ERR "PCI: revision-id not found.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +385,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
* [PATCH] Add for_each_child_of_node() helper for iterating over child nodes
From: Michael Ellerman @ 2007-11-26 8:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, David S. Miller
Add for_each_child_of_node() to encapsulate the common idiom of
iterating over the children of a device_node.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
After conducting a straw pole of powerpc hackers, this seems to be the
preferred name for such a beast.
include/linux/of.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 5c39b92..c65af7b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -46,6 +46,10 @@ extern struct device_node *of_find_node_by_phandle(phandle handle);
extern struct device_node *of_get_parent(const struct device_node *node);
extern struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev);
+#define for_each_child_of_node(parent, child) \
+ for (child = of_get_next_child(parent, NULL); child != NULL; \
+ child = of_get_next_child(parent, child))
+
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
* Re: [PATCH] ehea: Add kdump support
From: Michael Ellerman @ 2007-11-26 8:16 UTC (permalink / raw)
To: Thomas Klein
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Paul Mackerras,
Marcus Eder, Stefan Roscher
In-Reply-To: <200711091433.51259.osstklei@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]
On Fri, 2007-11-09 at 14:33 +0100, Thomas Klein wrote:
> To support ehea driver reloading in a kdump kernel the driver has to perform
> firmware handle deregistrations when the original kernel crashes. As there's
> currently no notifier chain for machine crashes this patch enables kdump support
> in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
> machine crash handler. The original machine_crash_shutdown() fn is called
> afterwards. This works fine as long as the ehea driver is the only one which
> does so. Problems may occur if other drivers do the same and unload regularly.
> This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
> low risk on base kernel. In 2.6.24 we know ehea is the only user of this
> mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
> The full solution might be that register_reboot_notifier() provides sth
> like a SYS_CRASH action. Please apply.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+), 1 deletions(-)
>
Hi Thomas,
I'm sorry, but this patch is all wrong IMHO.
For kdump we have to assume that the kernel is fundamentally broken,
we've panicked, so something bad has happened - every line of kernel
code that is run decreases the chance that we'll successfully make it
into the kdump kernel.
So just calling unregister_driver() is no good, that's going to call
lots of code, try to take lots of locks, rely on lots of data structures
being uncorrupted etc. etc.
And the hijacking of machine_crash_shutdown() is IMO not an acceptable
solution, as you say it only works if EHEA is the only driver to do it.
And as soon as EHEA does it other drivers will want to do it.
What we need is the _minimal_ set of actions that can happen to make
EHEA work in the kdump kernel.
Solutions that might be better:
a) if there are a finite number of handles and we can predict their
values, just delete them all in the kdump kernel before the driver
loads.
b) if there are a small & finite number of handles, save their values
in a device tree property and have the kdump kernel read them and
delete them before the driver loads.
c) if neither of those work, provide a minimal routine that _only_
deletes the handles in the crashed kernel.
d) <something else>
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add for_each_child_of_node() helper for iterating over child nodes
From: Stephen Rothwell @ 2007-11-26 8:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, David S. Miller
In-Reply-To: <e68326d47ae49fee03c635514d5a86a566b13ff9.1196064155.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
On Mon, 26 Nov 2007 19:03:45 +1100 (EST) Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Add for_each_child_of_node() to encapsulate the common idiom of
> iterating over the children of a device_node.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-26 8:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071125194101.GD14557@curie-int.orbis-terrarum.net>
[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]
On Sun, Nov 25, 2007 at 11:41:01AM -0800, Robin H. Johnson wrote:
> I was looking around for a description of the ROM layout, and instead I
> found this: http://developer.apple.com/technotes/tn/tn2000.html
> It was relevant because it explicitly mentioned enabling the
> PCI_COMMAND_MEMORY bit in the PCI_COMMAND register, which is NOT present
> in any path of the sizing code.
...
> By doing:
> # dev="/sys/devices/pci0001:00/0001:00:03.0/0001:06:00.0/"
> # echo 1 >${dev}/enable
> # echo 1 >${dev}/rom
> # cat ${dev}/rom >rom
> The ROM is successfully returned for two of my 3 cards.
> Namely, both of the ones containing x86 BIOS (sata_sil24, ATI X700).
> The X1900 does still not return any ROM.
...
> I broke my testing kernel temporarily, so I need a bit more testing to
> see why the X1900 did not return a ROM. More on that in a couple of
> hours.
(Part of this is from an IRC discussion with benh, summarized with
results here).
Thanks to some friends, I added some more PCIe cards to the test set:
The complete list is now:
x86-BIOS:
- Silicon Image, Inc. SiI 3132 Serial ATA Raid II (sata_sil24)
- ATI X700
OpenFirmware (all get relevant nodes in the device-tree after boot):
- ATI X1900
- Nvidia 6600
- Marvell SATA 7042 (sata_mv) [Sonnet Tempo SATA E4P]
For testing, I explicitly enable the device, and then try to read the
ROM. Additionally, I have some debug printk statements scattered about
rom.c and pci-sysfs.c, to detect various parts of the branching.
Additionaly per Jon's suggestion, I also have a bit of code at the end
of the sizing routine:
if (image == rom) { printk(...); return size; }
On the G5, the results are as follows:
- sata_sil24, X700, sata_mv - ROMS readable and valid.
- Nvidia 6600 - Returns junk data, changes between boots.
pci_get_rom_size fails the size decode, the first two readb() both
return 0x33
- ATI X1900 - Returns nulls. pci_get_rom_size fails here, the readbs()
return 0x00.
On an x86_64 (Core2 Duo), the results are as follows:
- sata_sil24 , X700 - ROMS readable and valid.
- sata_mv - appears in lspci, and works, but lspci does NOT show an 'Expansion ROM' line.
- Nvidia 6600, ATI X1900 - do not show up the kernel at all, or in
lspci. The PCIe Root port [8086:29a1] is entirely missing from the
lspci output.
Regarding the sub-thread on x86 emulation, that is totally out of scope
for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
may have minor errors here, ask airlied if you need more
clarification):
a) Initialization code (I think arch-specific)
b) AtomBIOS script interpreter (I think arch-specific)
c) AtomBIOS scripts (card-specific, but not arch-specific)
d) Data tables (card-specific, but not arch-specific)
The AtomBIOS parts of the various drivers need data from c+d primarily,
and provide their own script interpreter, or not using the scripts, just
the data tables.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: perfmon2 needs hard_irq_disable() for powerpc
From: Stephane Eranian @ 2007-11-26 8:55 UTC (permalink / raw)
To: Sonny Rao
Cc: mikey, miltonm, dwg, linuxppc-dev, paulus, anton, cjashfor,
perfmon2-devel
In-Reply-To: <20071126074438.GA27499@kevlar.boston.burdell.org>
Hello Sonny,
On Mon, Nov 26, 2007 at 02:44:38AM -0500, Sonny Rao wrote:
> Hi, I've been reading through the perfmon2 patch for 2.6.23 and it
> dawned on me that in the powerpc architecture we have the notion of
> lazy-disabling of interrupts where we don't actually disable
> interrupts unless we see one come in and then turn them off. I believe
> a notable exception is the performance monitor interrupt which we
> allow to break into our critical sections. This is desirable because
> we want to profile those sections and right now, no in-kernel user of
> the performance monitor interrupt in powerpc does any synchronization
> across cpus inside the interrupt handler (oprofile seems to use
> per-cpu buffers/state for everything). We use hard_irq_disable() when
> we _really_ have to disable interrupts because we're switching out the
> kernel stack, etc.
>
> Perfmon2 is more demanding in its synchronization requirements and it
> uses spin_lock_irqsave() in the generic arch-neutral code in several
> places, I think this will break on powerpc the way we're handling
> things now.
>
We use spinlocks to serialize access to the perfmon context. The irq masking
is here to avoid a race between a user calling into perfmon and a counter
interrupt.
Allowing PMU interrupts in critical sections is useful, yet it gets
complicated very quickly because of locking issues, including within
the perfmon code. For instance, a consequence of a interrupt could be
that a SIGIO message is posted. If counter interrupts were allowed in the
signal code, then we could potentially get dedlock situations.
>From what you are saying it seems on powerpc, there may be a way to
differentiate interrupts and thus possibly allow a less restrictive
locking policy.
> I'm copying a few people to solicit opinions on how best to deal with
> this. I think it's desirable to keep the property of letting us
> profile critical sections in the kernel wherever possible. So we would
> need to add hard_irq_disable/enable calls to the generic code, but want to
> check with you guys first.
>
I am open to suggestions. If we can enable monitoring in critical sections
and still avoid races and dealocks, at least on powerpc, then I'll be happy
to allow this.
Thanks.
--
-Stephane
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Michel Dänzer @ 2007-11-26 9:20 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20071126085928.GE14557@curie-int.orbis-terrarum.net>
On Mon, 2007-11-26 at 00:59 -0800, Robin H. Johnson wrote:
>
> Regarding the sub-thread on x86 emulation, that is totally out of scope
> for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I
> may have minor errors here, ask airlied if you need more
> clarification):
> a) Initialization code (I think arch-specific)
> b) AtomBIOS script interpreter (I think arch-specific)
> c) AtomBIOS scripts (card-specific, but not arch-specific)
> d) Data tables (card-specific, but not arch-specific)
>
> The AtomBIOS parts of the various drivers need data from c+d primarily,
> and provide their own script interpreter, or not using the scripts, just
> the data tables.
Are you sure the X1900 Mac Edition ROM contains any ATOM data structures
though? I rather doubt it.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* perfmon2 needs hard_irq_disable() for powerpc
From: Sonny Rao @ 2007-11-26 7:44 UTC (permalink / raw)
To: perfmon2-devel
Cc: mikey, miltonm, dwg, linuxppc-dev, paulus, anton, eranian,
cjashfor
Hi, I've been reading through the perfmon2 patch for 2.6.23 and it
dawned on me that in the powerpc architecture we have the notion of
lazy-disabling of interrupts where we don't actually disable
interrupts unless we see one come in and then turn them off. I believe
a notable exception is the performance monitor interrupt which we
allow to break into our critical sections. This is desirable because
we want to profile those sections and right now, no in-kernel user of
the performance monitor interrupt in powerpc does any synchronization
across cpus inside the interrupt handler (oprofile seems to use
per-cpu buffers/state for everything). We use hard_irq_disable() when
we _really_ have to disable interrupts because we're switching out the
kernel stack, etc.
Perfmon2 is more demanding in its synchronization requirements and it
uses spin_lock_irqsave() in the generic arch-neutral code in several
places, I think this will break on powerpc the way we're handling
things now.
I'm copying a few people to solicit opinions on how best to deal with
this. I think it's desirable to keep the property of letting us
profile critical sections in the kernel wherever possible. So we would
need to add hard_irq_disable/enable calls to the generic code, but want to
check with you guys first.
Sonny
^ 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