On Thu, 11 Mar 2010 14:22:37 -0700, Grant Likely wrote:
On Thu, Mar 11, 2010 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote:
.node is being removed
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
I'm not sure, but I guess pci_setup_bridge() didn't update IO base/limit
and Mem base/limit of the bridge (:00:02.0) because of the following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus-self;
struct resource *res;
struct
This small series ensures that struct irq_desc-chip_data is available
for alternative irq_chip implementations.
There is an outstanding issue wrt when/how the chip_data field is
initialised. I am continuing to investigate this but the solution is not
turning out as easy/low-impact as expected.
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at the time the irq_desc is
setup. For now rename
2010/3/11 Németh Márton nm...@freemail.hu:
Hi,
thank you for the comments, I reworked the Freescale MPC5554 device tree
accordingly. I'm listening for comments on this draft.
Regards,
Márton Németh
---
From: Márton Németh nm...@freemail.hu
Add device tree for Freescale MPC5554.
On Thu, 11 Mar 2010 11:57:53 -0800
Roland Dreier rdre...@cisco.com wrote:
Seems fine... adding EHCA guys just to make sure.
.node is being removed
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Alexander Schmidt al...@linux.vnet.ibm.com
On Fri, Mar 12, 2010 at 11:53:15AM +0530, Amit Shah wrote:
Alan pointed out a race in the code where hvc_remove is invoked. The
recent virtio_console work is the first user of hvc_remove().
Alan describes it thus:
The hvc_console assumes that a close and remove call can't occur at the
On Thu, 11 Mar 2010 11:22:54 -0700
Grant Likely grant.lik...@secretlab.ca wrote:
.name, .match_table and .owner are duplicated in both
of_platform_driver and device_driver, so the of_platform_driver
copies will be removed soon.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
NDFC
On Thu, 11 Mar 2010 11:23:49 -0700
Grant Likely grant.lik...@secretlab.ca wrote:
.name, .match_table and .owner are duplicated in both
of_platform_driver and device_driver, so the of_platform_driver
copies will be removed soon.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
This patch adds min_direct_dma_addr to struct dev_archdata.
min_direct_dma_addr can be used to define which is the minimum address
suitable for a DMA operation.
dma_capable() is updated to use this information in the SWIOTLB case.
This will be used later to support the Nintendo Wii video game
Use the generic per-device dma coherent allocator on powerpc.
This allows a driver to declare coherent memory area from where
a device can allocate coherent memory chunks.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/include/asm/dma-mapping.h |1 +
The following patch series adds USB 2.0 support for the Wii PowerPC
platform via the EHCI controller present in the Hollywood chipset
of the video game console.
The first iterations (v1 to v3) of this patchset were submitted as RFC PATCH.
The patchset is now sent as PATCH targetted for mainline
This patch makes swiotlb_alloc_boot() available again.
This weak function can be overloaded to modify slightly how the SWIOTLB
and the overflow areas are allocated during boot.
This will be used later to support the Nintendo Wii video game console,
which requires placing the SWIOTLB area above
The current SWIOTLB code uses a default of 64MB for the IO TLB area.
This size can be influenced using a kernel command line parameter swiotlb.
Unfortunately, the parsing of the kernel command line is done _after_ the
swiotlb is initialized on some architectures.
This patch adds a new function
Split unmap_urb_for_dma() and map_urb_for_dma() into smaller pieces
to make the code easier to read and maintain.
This patch adds four new URB flags which are used by map_urb_for_dma()
to mark URBs with the exact method used to map the setup packet and/or the
transfer buffer.
These flags are
The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms.
This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by
adding two platform specific functions swiotlb_dma_sync_page() and
swiotlb_dma_sync() which can be used to explicitly manage cache coherency.
On PowerPC
The HCD_NO_COHERENT_MEM USB host controller driver flag can be enabled
to instruct the USB stack to avoid allocating coherent memory for USB
buffers.
This flag is useful to overcome some esoteric memory access restrictions
found in some platforms.
For example, the Nintendo Wii video game console
Let the Nintendo Wii gaming console use per-device dma coherent allocations.
This will be used later by some of its drivers.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/platforms/embedded6xx/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
Some of the devices in the Hollywood chipset of the Nintendo Wii video
game console have restrictions performing DMA transfers to the first
contiguous RAM region (known as MEM1).
For example, up to 3 bytes of the last word of a DMA transfer of a
non-32 bit aligned length to MEM1 may be lost.
Such
Enable the use of a software IO TLB on the Nintendo Wii video game console.
This is used by the platform DMA support code to overcome the limitations
found in some of the devices within the Hollywood chipset.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
Add support for the USB Enhanced Host Controller Interface included
in the Hollywood chipset of the Nintendo Wii video game console.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/platforms/embedded6xx/Kconfig |1 +
drivers/usb/host/Kconfig |8 +
On 03/12/2010 01:45 AM, Ian Campbell wrote:
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
because irq_desc-chip is not known at
On Fri, 5 Feb 2010 23:32:36 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip-dev specified) automatically
attached to the OpenFirmware subsystem. Which means that now
On Fri, Mar 12, 2010 at 2:07 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Fri, 5 Feb 2010 23:32:36 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
This patch implements GPIOLIB notifier hooks, and thus makes device-enabled
GPIO chips (i.e. the ones that have gpio_chip-dev
On Fri, Mar 12, 2010 at 05:14:56AM -0700, Grant Likely wrote:
2010/3/11 Németh Márton nm...@freemail.hu:
[snip]
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+
Hello Kenji-san,
Kenji Kaneshige wrote:
I'm not sure, but I guess pci_setup_bridge() didn't update IO base/limit
and Mem base/limit of the bridge (:00:02.0) because of the following
lines.
static void pci_setup_bridge(struct pci_bus *bus)
{
struct pci_dev *bridge = bus-self;
On Fri, Mar 12, 2010 at 3:36 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Fri, Mar 12, 2010 at 05:14:56AM -0700, Grant Likely wrote:
2010/3/11 Németh Márton nm...@freemail.hu:
[snip]
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+
The powerpc implementations of syscall_get_error and
syscall_set_return_value should use CCR0:S0 (0x1000) for testing
and setting syscall error status. Fortunately these APIs don't seem
to be used at the moment.
Signed-off-by: Nathan Lynch n...@pobox.com
---
Yinghai Lu ying...@kernel.org writes:
On 03/12/2010 01:45 AM, Ian Campbell wrote:
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc-chip_data.
arch_init_chip_data cannot be moved into struct irq_chip at this time
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the
The historical background here is that in the original OF spec, driver
matching was done on node name, and only then on compatible.
Essentially the node name was treated as an implicit first entry in
the compatible list. The the generic names convention came along, and
instead name became a
In this particular case, we're talking about a part that has never
previously been described in a device tree. So, since this is
something entirely new, what is the value in preserving the
PowerPC, style when there isn't any code that will be relying on
it?
There could be code that
32 matches
Mail list logo
