* 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: 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: [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: 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
* [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: 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
* 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
* [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
* [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
* 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
* 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 devicetrees
From: Grant Likely @ 2007-11-25 22:21 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <47493D4F.4070605@dlasys.net>
On 11/25/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > One more point; it is also possible to bind the device tree up with
> > the kernel so you've got a single image just like old times. :-)
> >
> But that is not actually the same is dynamically detecting
> configuration.
nope, not at all the same as dynamic detection; just backwards
compatibility with the way we do it now for arch/ppc.
> On an ordinary PC where the critical core configuration is somewhat
> fixed and the rest can be determined by firmware (code), this makes a
> great deal of sense.
> In a system where the hardware itself is actually firmware and there
> is little or no startup software to query the device and build a device
> tree dynamically for you, it is of more questionable value.
> Maybe if there is some mechanism existed to have the devicetree
> stored into the FPGA firmware where there is a natural link between the
> implimented hardware and its description. But I am not gathering things
> going in that direction and storing the device tree in the FPGA consumes
> valuable FPGA resources.
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.
If the FPGA bitstream is stored in processor accessable flash, then
the best place would be tacked onto the end of the bitstream file. I
believe Xilinx is planning for EDK to be responsible to generate the
.dts file for the design.
>
> >
> > The board description has to live *somewhere*.
> I have done alot of code for many purposes where the code went to a
> great deal of effort to figure out its own environment dynamically.
> Some (relatively minimal) assumptions have to be made. And some
> balance has to be struck between code complexity and dynamic flexibility.
> though sometimes dynamic detection can be simpler.
> Part of what bothers me about devicetrees, is that the entire design
> seems to presume either standard hardware with minimal permutations, or
> fairly complex firmware - like boot roms to dynamically build atleast
> parts of the device tree.
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).
> > That being said, using the device tree does not preclude using
> > platform code to setup devices *where it makes sense to do so*. Many
> > things are one-off board specific things that are not well described
> > with the device tree. For example, we've been debating how to handle
> > on board sound which use common codec chips, but have custom wireup.
> > The codec chip can use a common driver, but the wireup is handled with
> > an ALSA 'fabric' driver that is pretty much a one-off for the board.
> > It probably makes more sense for the fabric driver to be instantiated
> > by the platform code rather than trying to do a full device tree
> > representation.
> >
> So I can hard code some relatively simple stripped devicetree
> that may do little more than specify the CPU, major elements of the
> memory map (maybe), and say the PIC, and then let the BSP, detect things
> like the UART(s), NIC, ...
If devices *are* detectable, then they don't need to be in the device
tree. That's why we don't describe PCI devices in the FDT for
embedded boards. (We *could* but we *don't*) :-)
> > In arch/powerpc
> > we're *still* data driven; it's just that the data is no longer
> > compiled into a static structure. Plus, in the transition we've moved
> > from needed per-device platform data structures to a more expressive
> > format. Also, per-board platform support code has become much simpler
> > (compare ml300.c in arch/ppc with platforms/40x/virtex.c)
> >
>
> I have not pulled your tree in a while - are devicetree's in your
> current git tree ?
arch/powerpc support for Virtex is now in Linus' mainline tree which
will become 2.6.24
>
> Thanks for the remarks.
>
> Again, I am just trying to figure out how to keep my Pico code in
> sync and hopefully make my life better rather than worse at the same time.
> Unfortunately, I am coming to the conclusion that DeviceTrees are
> probably not going to make it that much better,
> but they are probably not going to make it that much worse either.
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.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 14/27] powerpc: ptrace generic resume
From: Roland McGrath @ 2007-11-25 22:04 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This removes the handling for PTRACE_CONT et al from the powerpc
ptrace code, so it uses the new generic code via ptrace_request.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 46 ------------------------------------------
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index b970d79..8b056d2 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -445,52 +445,6 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
}
- case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */
- case PTRACE_CONT: { /* restart after signal. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- if (request == PTRACE_SYSCALL)
- set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- else
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- child->exit_code = data;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- ret = 0;
- break;
- }
-
-/*
- * make the child exit. Best I can do is send it a sigkill.
- * perhaps it should be put in the status that it wants to
- * exit.
- */
- case PTRACE_KILL: {
- ret = 0;
- if (child->exit_state == EXIT_ZOMBIE) /* already dead */
- break;
- child->exit_code = SIGKILL;
- /* make sure the single step bit is not set. */
- user_disable_single_step(child);
- wake_up_process(child);
- break;
- }
-
- case PTRACE_SINGLESTEP: { /* set the trap flag. */
- ret = -EIO;
- if (!valid_signal(data))
- break;
- clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- user_enable_single_step(child);
- child->exit_code = data;
- /* give it a chance to run. */
- wake_up_process(child);
- ret = 0;
- break;
- }
-
case PTRACE_GET_DEBUGREG: {
ret = -EINVAL;
/* We only support one DABR and no IABRS at the moment */
^ permalink raw reply related
* [PATCH 13/27] powerpc: arch_has_single_step
From: Roland McGrath @ 2007-11-25 22:03 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20071125215507.4B89226F8C5@magilla.localdomain>
This defines the new standard arch_has_single_step macro. It makes the
existing set_single_step and clear_single_step entry points global, and
renames them to the new standard names user_enable_single_step and
user_disable_single_step, respectively.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/ptrace.c | 12 ++++++------
include/asm-powerpc/ptrace.h | 7 +++++++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 3e17d15..b970d79 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -256,7 +256,7 @@ static int set_evrregs(struct task_struct *task, unsigned long *data)
#endif /* CONFIG_SPE */
-static void set_single_step(struct task_struct *task)
+void user_enable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -271,7 +271,7 @@ static void set_single_step(struct task_struct *task)
set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static void clear_single_step(struct task_struct *task)
+void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
@@ -313,7 +313,7 @@ static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
void ptrace_disable(struct task_struct *child)
{
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
}
/*
@@ -456,7 +456,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
child->exit_code = data;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
ret = 0;
break;
@@ -473,7 +473,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
break;
child->exit_code = SIGKILL;
/* make sure the single step bit is not set. */
- clear_single_step(child);
+ user_disable_single_step(child);
wake_up_process(child);
break;
}
@@ -483,7 +483,7 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data)
if (!valid_signal(data))
break;
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
- set_single_step(child);
+ user_enable_single_step(child);
child->exit_code = data;
/* give it a chance to run. */
wake_up_process(child);
diff --git a/include/asm-powerpc/ptrace.h b/include/asm-powerpc/ptrace.h
index 13fccc5..3063363 100644
--- a/include/asm-powerpc/ptrace.h
+++ b/include/asm-powerpc/ptrace.h
@@ -119,6 +119,13 @@ do { \
} while (0)
#endif /* __powerpc64__ */
+/*
+ * These are defined as per linux/ptrace.h, which see.
+ */
+#define arch_has_single_step() (1)
+extern void user_enable_single_step(struct task_struct *);
+extern void user_disable_single_step(struct task_struct *);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply related
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711251324y5116d90pab54a1a033d024e3@mail.gmail.com>
> You can dump the PCI config block in /sys with hexdump and see if the
> PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
> the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
> by the BIOS at boot on the x86 and not on the ppc.
The kernel doesn't until somebody calls pci_enable_device(). So yes,
that's likely to be your problem.
Ben.
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 21:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196022000.7195.70.camel@pasglop>
On 11/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
He says in the first email that when he puts the boards into an x86
box he can read them. The quick turns the ROM back on if the firmware
is turning them off.
In the PPC box the ROMs aren't being run so they would still be in
power on state. I'd expect them to be readable in power-on state.
You can dump the PCI config block in /sys with hexdump and see if the
PCI_COMMAND_MEMORY bit is set. I was also unable to locate where in
the kernel PCI_COMMAND_MEMORY is being set. It could be that it is set
by the BIOS at boot on the x86 and not on the ppc.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Dan Malek @ 2007-11-25 21:02 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071125191833.1e76f335@kernel.crashing.org>
On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
> To prevent using those pointers from within non-GPL modules. kind
> of policy now...
As the original copyright holder of nearly all of this of
this code, I do not wish this be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: PCI to Parallel for PowerPC
From: Benjamin Herrenschmidt @ 2007-11-25 21:09 UTC (permalink / raw)
To: Clemens Koller; +Cc: puyq, linuxppc-embedded, linuxppc-dev, zhang_wei, shekr06
In-Reply-To: <4749AA1B.3050805@anagramm.de>
On Sun, 2007-11-25 at 18:00 +0100, Clemens Koller wrote:
> Put that PCI Card to your host where your stepper was working
> properly to see if it's a hardware issue with that card.
>
> Then it depends on how you control your stepper motor. If you use
> some bit-banging (which I wouldn't recommend) to drive each winding
> and want to have smooth movement, you need a very precise timing
> when it comes to some "more than low-speed" stepper motors,
> otherwise your motors will start to coggle.
> To be precise: you will first have to figure out what leads to
> the effect of "it's not stable". Do you have an Oscilloscope?
Also, we might need to see the code you are using to control the
parallel port, it may be ignoring issues such as PCI write posting or
lacking appropriate memory barriers...
Ben.
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 20:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711251251v6c24b5dek2fe09f2d2964e769@mail.gmail.com>
On Sun, 2007-11-25 at 15:51 -0500, Jon Smirl wrote:
>
> They blocked the X server changes, which rendered the kernel support
> pointless. But that's all old news.
No, you are wrong, nothing was ever "blocked".
Ben.
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Jon Smirl @ 2007-11-25 20:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196022000.7195.70.camel@pasglop>
On 11/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
> >
> > > The two cards with x86 firmware return 0xFF for those two readb()
> > > instructions, while the X1900 with OF returns 0x00 for the readb().
> > >
> > > Could one of the more knowledgeable folk for PPC intricacies suggest
> > why
> > > those readb calls are returning the wrong data?
> >
> > I don't know PPC at this low of level but it may be a problem with non
> > word-aligned access to memory. I thought readb() was supposed to work
> > on all archs and alignment issues are handled inside readb(). Also,
> > the readw() may have an endian bug.
>
> Ugh ? Read be reads -bytes- ! Can you tell me how the hell can a byte
> access be non-aligned ?
readb() doesn't work on the dev board I'm currently working with
because the flash is wired in such a way that it only works for 16b
reads. Maybe calling that an alignment issue is the wrong term.
> > BenH, has source code for an x86 emulator that will run on PPC. That
> > will let you run the ROMs. The original plan was for the kernel to
> > generate a uevent that would have triggered the x86 emulator to run.
> >
> > Progress along that path was blocked by the X developers. The X server
> > contains code for enabling the PCI ROM and reading it from user space.
> > I wanted to move this code out of X and into the kernel.
> >
> > Because the path was blocked things like the PCI ROM API were never
> > throughly tested. It works most of the time but the occasional problem
> > is still turning up. Once we identify the PPC problem we can fix it in
> > the kernel.
>
> Nobody blocked anything, you are free to develop an emulator triggered
> by a uevent, nobody prevented you from doing so.
They blocked the X server changes, which rendered the kernel support
pointless. But that's all old news.
> Now, regarding that user problem, this it totally unrelated as it's a
> "mac" card.
>
> It's possible that it's one of these radeons that disable ROM access via
> a register in which case a quirk is needed to re-enable it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH resend 4/4] powerpc: Add support for PORTA and PORTB odr registers
From: Vitaly Bordug @ 2007-11-25 20:37 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B435.3080002@scram.de>
On Thu, 22 Nov 2007 17:54:13 +0100
Jochen Friedrich wrote:
> PORTA and PORTB have odr registers, as well. However, the PORTB odr
> register is only 16bit.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Acked-by: Scott Wood <scottwood@freescale.com>
Applied to linux-2.6-8xx.git, for-paulus branch
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH resend 2/4] powerpc: kill non-existent symbols from ksyms and commproc.h
From: Vitaly Bordug @ 2007-11-25 20:37 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B422.5080103@scram.de>
On Thu, 22 Nov 2007 17:53:54 +0100
Jochen Friedrich wrote:
> Remove exports of __res and cpm_install_handler/cpm_free_handler.
> Remove cpm_install_handler/cpm_free_handler from the commproc.h as
> well. Both were used for ARCH=ppc and aren't defined for
> ARCH=powerpc.
>
> CC arch/powerpc/kernel/ppc_ksyms.o
> arch/powerpc/kernel/ppc_ksyms.c:180: error: '__res' undeclared here
> (not in a function) arch/powerpc/kernel/ppc_ksyms.c:180: warning:
> type defaults to 'int' in declaration of '__res' make[1]: ***
> [arch/powerpc/kernel/ppc_ksyms.o] Error 1 make: ***
> [arch/powerpc/kernel] Error 2
>
> LD .tmp_vmlinux1
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x198): undefined reference
> to `cpm_free_handler'
> arch/powerpc/kernel/built-in.o:(__ksymtab+0x1a0): undefined reference
> to `cpm_install_handler' make: *** [.tmp_vmlinux1] Error 1
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied to linux-2.6-8xx.git, for-paulus branch.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH resend 1/4] powerpc: fix typo #ifdef -> #ifndef
From: Vitaly Bordug @ 2007-11-25 20:34 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745B41B.3040904@scram.de>
On Thu, 22 Nov 2007 17:53:47 +0100
Jochen Friedrich wrote:
> fpi->cp_command should be overwritten only if
> CONFIG_PPC_CPM_NEW_BINDING is NOT set. Otherwise it is already set
> from the device tree.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied to linux-2.6-8xx.git, for-paulus branch.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Benjamin Herrenschmidt @ 2007-11-25 20:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711250530r454c01ecoe8867a7f492b8704@mail.gmail.com>
On Sun, 2007-11-25 at 08:30 -0500, Jon Smirl wrote:
>
> > The two cards with x86 firmware return 0xFF for those two readb()
> > instructions, while the X1900 with OF returns 0x00 for the readb().
> >
> > Could one of the more knowledgeable folk for PPC intricacies suggest
> why
> > those readb calls are returning the wrong data?
>
> I don't know PPC at this low of level but it may be a problem with non
> word-aligned access to memory. I thought readb() was supposed to work
> on all archs and alignment issues are handled inside readb(). Also,
> the readw() may have an endian bug.
Ugh ? Read be reads -bytes- ! Can you tell me how the hell can a byte
access be non-aligned ?
> BenH, has source code for an x86 emulator that will run on PPC. That
> will let you run the ROMs. The original plan was for the kernel to
> generate a uevent that would have triggered the x86 emulator to run.
>
> Progress along that path was blocked by the X developers. The X server
> contains code for enabling the PCI ROM and reading it from user space.
> I wanted to move this code out of X and into the kernel.
>
> Because the path was blocked things like the PCI ROM API were never
> throughly tested. It works most of the time but the occasional problem
> is still turning up. Once we identify the PPC problem we can fix it in
> the kernel.
Nobody blocked anything, you are free to develop an emulator triggered
by a uevent, nobody prevented you from doing so.
Now, regarding that user problem, this it totally unrelated as it's a
"mac" card.
It's possible that it's one of these radeons that disable ROM access via
a register in which case a quirk is needed to re-enable it.
Ben.
^ permalink raw reply
* List of Device Bandwidths
From: narendra sisodiya @ 2007-11-25 20:15 UTC (permalink / raw)
To: computertechnology, osscampdelhi, linuxppc-embedded, fosska
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Here is a link to one of the most useful page page which tell compare almost
all device and standards in context to their bandwidth and data rate.
Hope it will be useful for somebody.
http://en.wikipedia.org/wiki/List_of_device_bandwidths
--
Narendra Sisodiya
MTech (Computer Technology), IIT Delhi
+91-9999232792
http://www.techfandu.org/index.html
[-- Attachment #2: Type: text/html, Size: 505 bytes --]
^ 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