* [PATCH] powerpc/86xx: Add I2C device mappings in DTS for SBC610
From: Martyn Welch @ 2009-05-19 9:40 UTC (permalink / raw)
To: galak, linuxppc-dev
Mappings for temperature sensors (adt7461 and lm92) are missing from the
SBC610's DTS file.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6898d7e..85d1416 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -153,6 +153,16 @@
interrupt-parent = <&mpic>;
dfsrr;
+ hwmon@48 {
+ compatible = "national,lm92";
+ reg = <0x48>;
+ };
+
+ hwmon@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+
rtc@51 {
compatible = "epson,rx8581";
reg = <0x00000051>;
^ permalink raw reply related
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Wolfgang Grandegger @ 2009-05-19 8:10 UTC (permalink / raw)
To: Piotr Zięcik; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <200905190947.22972.kosmo@semihalf.com>
Piotr Zięcik wrote:
> Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisał(a):
>>> I have simple question about bus speed setting support. Existing
>>> implementation uses default safe speed if there is no 'clock-frequency'
>>> property in i2c node. Comments in code suggest that this behaviour is
>>> left for backward compatibility only. Should I make the 'clock-frequency'
>>> property mandatory for a new type of I2C controller (MPC5121) ?
>> I don't think so, for the same backward compatibility reason as for the
>> other boards. But the DTS file might be changed to use clock-frequency.
>
> In my opinion implementing "backward compatilility" for MPC5121 is not good
> idea. MPC5121 I2C support is completly new thing in mainline. Simply, there is
> no DTS with which I have to be compatible. Adding backward compatibility
> with nothing may be confusing.
There is a port for the MPC5121 in mainline since 2.6.25 including DTS
file:
http://lxr.linux.no/linux+v2.6.25/arch/powerpc/boot/dts/mpc5121ads.dts
If it was really usable or even used is another question. But it's fine
for me be more restrictive, e.g. print a warning when save values are
selected.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Piotr Zięcik @ 2009-05-19 8:03 UTC (permalink / raw)
To: Hongjun Chen; +Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk
In-Reply-To: <200905190937411866001@freescale.com>
Tuesday 19 May 2009 03:37:47 Hongjun Chen wrote:
> Since you have reuse most part of our BSP, why should you reinvent wheel
> for MPC512x DMA? We have one ready DMA driver, which has been used by AC9=
7,
> ATA, VIU etc.
>
Answer is simple. The old one does not fit Linux DMA API. New one uses=20
existing infrastructure which makes DMA engine aviable for existing consume=
rs
in Linux kernel. For example network stack. Support for I/O <-> memory=20
transfers will be added when more consumers arrive.
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: Piotr Zięcik @ 2009-05-19 7:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel, linux-i2c
In-Reply-To: <4A1170B0.5080203@grandegger.com>
Monday 18 May 2009 16:29:04 Wolfgang Grandegger napisa=B3(a):
> > I have simple question about bus speed setting support. Existing
> > implementation uses default safe speed if there is no 'clock-frequency'
> > property in i2c node. Comments in code suggest that this behaviour is
> > left for backward compatibility only. Should I make the 'clock-frequenc=
y'
> > property mandatory for a new type of I2C controller (MPC5121) ?
>
> I don't think so, for the same backward compatibility reason as for the
> other boards. But the DTS file might be changed to use clock-frequency.
In my opinion implementing "backward compatilility" for MPC5121 is not good
idea. MPC5121 I2C support is completly new thing in mainline. Simply, there=
is=20
no DTS with which I have to be compatible. Adding backward compatibility
with nothing may be confusing.
=2D-=20
Best Regards,
Piotr Zi=EAcik
^ permalink raw reply
* Re: fs_enet build breakage
From: Kumar Gala @ 2009-05-19 6:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, Kumar Gala, linuxppc-dev list
In-Reply-To: <1242683444.16901.1.camel@pasglop>
On May 18, 2009, at 4:50 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote:
>>> I'm pretty sure the driver changes to address this are in dave's
>> net-
>>> next tree.
>>
>> Won't this break git bisect?
>>
>> Not to mention anyone trying to use your tree now...
>
> Right, though if you have the commit ID in DaveM tree, I can work with
> him to sort out that driver, for example by having the same commit in
> my tree.
As discussed on IRC, its easier to modify the commit that cause the
issue to drop removing IMAP_ADDR for cpm1 devices for now. I'll
generate a separate patch for us to deal w/during the merge window
for .31
- k
^ permalink raw reply
* Please pull from 'next' branch
From: Kumar Gala @ 2009-05-19 5:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
This is based on benh/next and fixes the cpm cruft patch to drop the
removal of IMAP_ADDR from cpm1 so we still build on 8xx. Will deal with
that when we get into the merge window for 2.6.31.
- k
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
Documentation/powerpc/dts-bindings/ecm.txt | 64 +
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 3
Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 5
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 +
arch/powerpc/boot/dts/gef_ppc9a.dts | 14
arch/powerpc/boot/dts/gef_sbc310.dts | 14
arch/powerpc/boot/dts/gef_sbc610.dts | 14
arch/powerpc/boot/dts/ksi8560.dts | 13
arch/powerpc/boot/dts/mpc832x_mds.dts | 3
arch/powerpc/boot/dts/mpc832x_rdb.dts | 3
arch/powerpc/boot/dts/mpc8349emitx.dts | 2
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 1
arch/powerpc/boot/dts/mpc834x_mds.dts | 2
arch/powerpc/boot/dts/mpc836x_mds.dts | 3
arch/powerpc/boot/dts/mpc836x_rdk.dts | 2
arch/powerpc/boot/dts/mpc8377_mds.dts | 1
arch/powerpc/boot/dts/mpc8378_mds.dts | 1
arch/powerpc/boot/dts/mpc8379_mds.dts | 1
arch/powerpc/boot/dts/mpc8536ds.dts | 18
arch/powerpc/boot/dts/mpc8540ads.dts | 15
arch/powerpc/boot/dts/mpc8541cds.dts | 16
arch/powerpc/boot/dts/mpc8544ds.dts | 18
arch/powerpc/boot/dts/mpc8548cds.dts | 17
arch/powerpc/boot/dts/mpc8555cds.dts | 16
arch/powerpc/boot/dts/mpc8560ads.dts | 15
arch/powerpc/boot/dts/mpc8568mds.dts | 51 +
arch/powerpc/boot/dts/mpc8569mds.dts | 583 +++++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 17
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 39 -
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 16
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 16
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 609 ++++++++++++++++
arch/powerpc/boot/dts/p2020ds.dts | 704 +++++++++++++++++++
arch/powerpc/boot/dts/sbc8349.dts | 1
arch/powerpc/boot/dts/sbc8548.dts | 16
arch/powerpc/boot/dts/sbc8560.dts | 15
arch/powerpc/boot/dts/sbc8641d.dts | 16
arch/powerpc/boot/dts/socrates.dts | 15
arch/powerpc/boot/dts/stx_gp3_8560.dts | 15
arch/powerpc/boot/dts/tqm8540.dts | 15
arch/powerpc/boot/dts/tqm8541.dts | 15
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 16
arch/powerpc/boot/dts/tqm8548.dts | 16
arch/powerpc/boot/dts/tqm8555.dts | 15
arch/powerpc/boot/dts/tqm8560.dts | 15
arch/powerpc/include/asm/cpm2.h | 4
arch/powerpc/include/asm/mpc86xx.h | 33
arch/powerpc/include/asm/pci-bridge.h | 6
arch/powerpc/include/asm/qe.h | 21
arch/powerpc/oprofile/op_model_fsl_emb.c | 14
arch/powerpc/platforms/82xx/pq2ads.h | 13
arch/powerpc/platforms/85xx/Kconfig | 1
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 43 +
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 52 +
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1
arch/powerpc/platforms/86xx/gef_sbc310.c | 1
arch/powerpc/platforms/86xx/gef_sbc610.c | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8
arch/powerpc/platforms/86xx/sbc8641d.c | 1
arch/powerpc/platforms/8xx/mpc885ads.h | 4
arch/powerpc/platforms/fsl_uli1575.c | 24
arch/powerpc/sysdev/cpm2.c | 2
arch/powerpc/sysdev/fsl_msi.c | 9
arch/powerpc/sysdev/fsl_pci.c | 132 +++
arch/powerpc/sysdev/fsl_pci.h | 6
arch/powerpc/sysdev/fsl_rio.c | 15
arch/powerpc/sysdev/fsl_soc.c | 14
arch/powerpc/sysdev/qe_lib/qe.c | 75 +-
drivers/dma/fsldma.c | 13
drivers/net/ucc_geth.c | 24
drivers/net/ucc_geth.h | 4
drivers/of/base.c | 1
drivers/rapidio/rio-scan.c | 6
include/linux/pci_ids.h | 4
78 files changed, 2810 insertions(+), 272 deletions(-)
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (2):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Kumar Gala (18):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
powerpc/fsl: Update FSL esdhc binding
powerpc/85xx: Add P2020DS board support
powerpc/fsl: Setup PCI inbound window based on actual amount of memory
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (1):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: FUJITA Tomonori @ 2009-05-19 5:27 UTC (permalink / raw)
To: beckyb; +Cc: fujita.tomonori, linuxppc-dev, linux-kernel
In-Reply-To: <1242340949-16369-2-git-send-email-beckyb@kernel.crashing.org>
CC'ed linux-kernel
On Thu, 14 May 2009 17:42:28 -0500
Becky Bruce <beckyb@kernel.crashing.org> wrote:
> This patch includes the basic infrastructure to use swiotlb
> bounce buffering on 32-bit powerpc. It is not yet enabled on
> any platforms. Probably the most interesting bit is the
> addition of addr_needs_map to dma_ops - we need this as
> a dma_op because the decision of whether or not an addr
> can be mapped by a device is device-specific.
>
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/Kconfig | 12 ++-
> arch/powerpc/include/asm/dma-mapping.h | 11 ++
> arch/powerpc/include/asm/swiotlb.h | 27 +++++
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/dma-swiotlb.c | 163 ++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/dma.c | 2 +-
> arch/powerpc/kernel/setup_32.c | 6 +
> arch/powerpc/kernel/setup_64.c | 6 +
> 8 files changed, 226 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/include/asm/swiotlb.h
> create mode 100644 arch/powerpc/kernel/dma-swiotlb.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index a0d1146..54e519a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -296,9 +296,19 @@ config IOMMU_VMERGE
> config IOMMU_HELPER
> def_bool PPC64
>
> +config SWIOTLB
> + bool "SWIOTLB support"
> + default n
> + select IOMMU_HELPER
> + ---help---
> + Support for IO bounce buffering for systems without an IOMMU.
> + This allows us to DMA to the full physical address space on
> + platforms where the size of a physical address is larger
> + than the bus address. Not all platforms support this.
> +
> config PPC_NEED_DMA_SYNC_OPS
> def_bool y
> - depends on NOT_COHERENT_CACHE
> + depends on (NOT_COHERENT_CACHE || SWIOTLB)
>
> config HOTPLUG_CPU
> bool "Support for enabling/disabling CPUs"
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index c69f2b5..71bbc17 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -15,9 +15,18 @@
> #include <linux/scatterlist.h>
> #include <linux/dma-attrs.h>
> #include <asm/io.h>
> +#include <asm/swiotlb.h>
>
> #define DMA_ERROR_CODE (~(dma_addr_t)0x0)
>
> +/* Some dma direct funcs must be visible for use in other dma_ops */
> +extern void *dma_direct_alloc_coherent(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flag);
> +extern void dma_direct_free_coherent(struct device *dev, size_t size,
> + void *vaddr, dma_addr_t dma_handle);
> +
> +extern unsigned long get_dma_direct_offset(struct device *dev);
> +
> #ifdef CONFIG_NOT_COHERENT_CACHE
> /*
> * DMA-consistent mapping functions for PowerPCs that don't support
> @@ -76,6 +85,8 @@ struct dma_mapping_ops {
> dma_addr_t dma_address, size_t size,
> enum dma_data_direction direction,
> struct dma_attrs *attrs);
> + int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
> + size_t size);
> #ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
> void (*sync_single_range_for_cpu)(struct device *hwdev,
> dma_addr_t dma_handle, unsigned long offset,
> diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/include/asm/swiotlb.h
> new file mode 100644
> index 0000000..30891d6
> --- /dev/null
> +++ b/arch/powerpc/include/asm/swiotlb.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#ifndef __ASM_SWIOTLB_H
> +#define __ASM_SWIOTLB_H
> +
> +#include <linux/swiotlb.h>
> +
> +extern struct dma_mapping_ops swiotlb_dma_ops;
> +extern struct dma_mapping_ops swiotlb_pci_dma_ops;
> +
> +int swiotlb_arch_address_needs_mapping(struct device *, dma_addr_t,
> + size_t size);
> +
> +static inline void dma_mark_clean(void *addr, size_t size) {}
> +
> +extern unsigned int ppc_swiotlb_enable;
> +int __init swiotlb_setup_bus_notifier(void);
> +
> +#endif /* __ASM_SWIOTLB_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 71901fb..34c0a95 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_KPROBES) += kprobes.o
> obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
> obj-$(CONFIG_STACKTRACE) += stacktrace.o
> +obj-$(CONFIG_SWIOTLB) += dma-swiotlb.o
>
> pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
> obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
> diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
> new file mode 100644
> index 0000000..68ccf11
> --- /dev/null
> +++ b/arch/powerpc/kernel/dma-swiotlb.c
> @@ -0,0 +1,163 @@
> +/*
> + * Contains routines needed to support swiotlb for ppc.
> + *
> + * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/pfn.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/pci.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/swiotlb.h>
> +#include <asm/dma.h>
> +#include <asm/abs_addr.h>
> +
> +int swiotlb __read_mostly;
> +unsigned int ppc_swiotlb_enable;
> +
> +void *swiotlb_bus_to_virt(struct device *hwdev, dma_addr_t addr)
> +{
> + unsigned long pfn = PFN_DOWN(swiotlb_bus_to_phys(hwdev, addr));
> + void *pageaddr = page_address(pfn_to_page(pfn));
> +
> + if (pageaddr != NULL)
> + return pageaddr + (addr % PAGE_SIZE);
> + return NULL;
> +}
> +
> +dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
> +{
> + return paddr + get_dma_direct_offset(hwdev);
> +}
> +
> +phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
> +
> +{
> + return baddr - get_dma_direct_offset(hwdev);
> +}
> +
> +/*
> + * Determine if an address needs bounce buffering via swiotlb.
> + * Going forward I expect the swiotlb code to generalize on using
> + * a dma_ops->addr_needs_map, and this function will move from here to the
> + * generic swiotlb code.
> + */
> +int
> +swiotlb_arch_address_needs_mapping(struct device *hwdev, dma_addr_t addr,
> + size_t size)
> +{
> + struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
> +
> + BUG_ON(!dma_ops);
> + return dma_ops->addr_needs_map(hwdev, addr, size);
> +}
> +
> +/*
> + * Determine if an address is reachable by a pci device, or if we must bounce.
> + */
> +static int
> +swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
> +{
> + u64 mask = dma_get_mask(hwdev);
> + dma_addr_t max;
> + struct pci_controller *hose;
> + struct pci_dev *pdev = to_pci_dev(hwdev);
> +
> + hose = pci_bus_to_host(pdev->bus);
> + max = hose->dma_window_base_cur + hose->dma_window_size;
> +
> + /* check that we're within mapped pci window space */
> + if ((addr + size > max) | (addr < hose->dma_window_base_cur))
> + return 1;
> +
> + return !is_buffer_dma_capable(mask, addr, size);
> +}
> +
> +static int
> +swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
> +{
> + return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
> +}
I think that swiotlb_pci_addr_needs_map and swiotlb_addr_needs_map
don't need swiotlb_arch_range_needs_mapping() since
- swiotlb_arch_range_needs_mapping() is always used with
swiotlb_arch_address_needs_mapping().
- swiotlb_arch_address_needs_mapping() uses is_buffer_dma_capable()
and powerpc doesn't overwrite swiotlb_arch_address_needs_mapping()
Do I miss something?
Anyway, we need to fix swiotlb checking code to if an area is
DMA-capable or not.
swiotlb_arch_address_needs_mapping() calls is_buffer_dma_capable() in
dma-mapping.h but it should not. It should live in an arch-specific
place such as arch's dma-mapping.h or something since
is_buffer_dma_capable() is arch-specific. I didn't know that
is_buffer_dma_capable() is arch-specific when I added it to the
generic place.
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev, dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
But I guess the bad thing is that we can't the arch abstraction due to
dom0 support.
^ permalink raw reply
* [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-19 5:22 UTC (permalink / raw)
To: linux-i2c, linuxppc-dev
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads. With this patch, it is possible to do an i2c_transfer() with
additional i2c_msg's following the I2C_M_RD messages.
It still needs to be resolved if it is possible to fix this issue
by removing the STOP condition after reads in a robust way.
Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
---
drivers/i2c/busses/i2c-mpc.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4af5c09..0199f9a 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
}
for (i = 0; ret >= 0 && i < num; i++) {
+ int restart = i;
pmsg = &msgs[i];
dev_dbg(i2c->dev,
"Doing %s %d bytes to 0x%02x - %d of %d messages\n",
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
+ if (i > 0 && ((pmsg - 1)->flags & I2C_M_RD))
+ restart = 0;
if (pmsg->flags & I2C_M_RD)
ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
else
ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Sean MacLennan @ 2009-05-19 3:57 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev, Timur Tabi
In-Reply-To: <fa686aa40905181958ye89c1far6a53dc57cf650728@mail.gmail.com>
On Mon, 18 May 2009 20:58:03 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> Then let it lie fallow on the list and in patchwork. It is published,
> and people know that it is available (I'll certainly consider it as I
> do driver work), but there must be real (not just theoretical) in
> kernel users of the interface. I someone wants to use it, then they
> can add it to their series or ping the list about getting it merged.
That's too bad. If it is ever merged, could you also ping the list?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Grant Likely @ 2009-05-19 2:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: scottwood, linuxppc-dev, smaclennan
In-Reply-To: <ed82fe3e0905181549n6d9a5370rcc0e1f52cebdc2d3@mail.gmail.com>
On Mon, May 18, 2009 at 4:49 PM, Timur Tabi <timur@freescale.com> wrote:
> On Thu, May 14, 2009 at 11:10 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> In other words, write your patches which use it and submit the lot as
>> a patch series with this patch as the first. =A0That gives some evidence
>> that this macro will actually be used and useful.
>
> This is going to be more difficult than you think. =A0The problem is
> that I don't have access to much hardware that uses drivers which can
> take advantage of this macro. =A0I can find one, maybe two examples, but
> if I put a timeout that's too short, I might break some other platform
> without knowing it.
Then let it lie fallow on the list and in patchwork. It is published,
and people know that it is available (I'll certainly consider it as I
do driver work), but there must be real (not just theoretical) in
kernel users of the interface. I someone wants to use it, then they
can add it to their series or ping the list about getting it merged.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] Allow selecting mv643xx_eth on Pegasos again
From: David Miller @ 2009-05-19 2:35 UTC (permalink / raw)
To: paubert; +Cc: netdev, linuxppc-dev, pacman, tbm, buytenh
In-Reply-To: <20090518232113.GA18469@iram.es>
From: Gabriel Paubert <paubert@iram.es>
Date: Tue, 19 May 2009 01:21:13 +0200
> Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity
> to remove the stale MV64360 config option.
>
> Signed-off-by: Gabriel Paubert <paubert@iram.es>
This patch doesn't even apply to net-next-2.6, please send me
changes relative to that.
^ permalink raw reply
* Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Hongjun Chen @ 2009-05-19 1:37 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc-dev@ozlabs.org; +Cc: Piotr Ziecik, Wolfgang Denk
In-Reply-To: <1241640919-4650-12-git-send-email-wd@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
Since you have reuse most part of our BSP, why should you reinvent wheel for MPC512x DMA? We have one ready DMA driver, which has been used by AC97, ATA, VIU etc.
Hongjun Chen
2009-05-19
发件人： Wolfgang Denk
发送时间： 2009-05-07 04:15:18
收件人： linuxppc-dev@ozlabs.org
抄送： Piotr Ziecik; Wolfgang Denk
主题： [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Piotr Ziecik <kosmo@semihalf.com>
This patch adds initial version of MPC512x DMA driver.
Only memory to memory transfers are currenly supported.
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: John Rigby <jcrigby@gmail.com>
---
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 1 +
drivers/dma/Kconfig | 7 +
drivers/dma/Makefile | 1 +
drivers/dma/mpc512x_dma.c | 642 ++++++++++++++++++++++++++
drivers/dma/mpc512x_dma.h | 192 ++++++++
6 files changed, 844 insertions(+), 1 deletions(-)
create mode 100644 drivers/dma/mpc512x_dma.c
create mode 100644 drivers/dma/mpc512x_dma.h
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 4230 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc/pci: clean up direct access to sysdata by iseries platform
From: Stephen Rothwell @ 2009-05-19 0:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1242651387-13194-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi Kumar,
On Mon, 18 May 2009 07:56:27 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> We shouldn't directly access sysdata to get the device node. We should
> be calling pci_device_to_OF_node().
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> * Fixed compile error (dev -> pdev)
I tested the previous version with the typo fixed, so assuming that you
changed nothing else,
Tested-by: Stephen Rothwell <sfr@canb.auug.org.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: 197 bytes --]
^ permalink raw reply
* [PATCH v2] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 23:21 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D459@az33exm24.fsl.freescale.net>
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity
to remove the stale MV64360 config option.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 214a92d..aff4f8c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) || PLAT_ORION
+ depends on MV64X60 || PPC32 || PLAT_ORION
select INET_LRO
select PHYLIB
help
^ permalink raw reply related
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 22:53 UTC (permalink / raw)
To: Gabriel Paubert
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <20090518221847.GA17348@iram.es>
Hello Gabriel,
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]
> Sent: Monday, May 18, 2009 5:19 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Lennert Buytenhek; tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David
> Miller
> Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> Hello Medve
>=20
> On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1
wrote:
> >
> > You're correct. MV64360 seems to be stale. Do you want to re-spin
your
> > patch to get rid of it?
>=20
>=20
> No problem, bu should I respin in from the current official git
> or on top of yours?
Top of the tree should be good.
Cheers,
Emil.
> > (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
>=20
> Fine with me.
>=20
> Regards,
> Gabriel
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-18 22:49 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev, smaclennan
In-Reply-To: <fa686aa40905140910i194acbd7y34142720874b8299@mail.gmail.com>
On Thu, May 14, 2009 at 11:10 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> In other words, write your patches which use it and submit the lot as
> a patch series with this patch as the first. =A0That gives some evidence
> that this macro will actually be used and useful.
This is going to be more difficult than you think. The problem is
that I don't have access to much hardware that uses drivers which can
take advantage of this macro. I can find one, maybe two examples, but
if I put a timeout that's too short, I might break some other platform
without knowing it.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Benjamin Herrenschmidt @ 2009-05-18 22:17 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, Piotr Zięcik, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood, Wolfgang Denk
In-Reply-To: <fa686aa40905140700k3ca28ac0m74c9c161ad538abc@mail.gmail.com>
On Thu, 2009-05-14 at 08:00 -0600, Grant Likely wrote:
>
> All of this doesn't actually affect the driver code at all. It's all
> handled by the kernel and the DMA apis. What it does affect is
> multiplatform kernels. The DMA behaviour is set at compile time, not
> run time, depending on the setting of CONFIG_NON_COHERENT_CACHE (see
> arch/powerpc/platforms/Kconfig.cputype). A kernel which has it on
> won't run properly on a platform which has it off, and visa-versa.
We are close to the point where we can make this a runtime option
though, by just having a different set of dma_ops hooked in.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 22:18 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D3A5@az33exm24.fsl.freescale.net>
Hello Medve
On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1 wrote:
>
> You're correct. MV64360 seems to be stale. Do you want to re-spin your
> patch to get rid of it?
No problem, bu should I respin in from the current official git
or on top of yours?
>
> (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
Fine with me.
Regards,
Gabriel
^ permalink raw reply
* Re: [OT] Lite5200B w/ nfs root hangs after some time
From: Jerome Walters @ 2009-05-18 22:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1240422181.5492.0@antares>
We experience exactly the same problem. Our client is Debian Testing
(_Squeeze_) x86 =E2=80=93 diskless node which uses nfsroot and boots from t=
he server
also Debian Testing (_Squeeze_) x86. While the client hang the server is
responding to everyone else's requests. Restarting the nfsd on the server
doesn't solve the problem.
At first I wasnt able to capture debug information on the client side since
/var/log was mounted over the nfs, so I have installed a hard drive where I
mounted only /var/log to be able to capture debug logs from the client as
well.
Debug Logs:=20
http://fixity.net/tmp/client.log.gz - Kernel RPC Debug Log from the client
http://fixity.net/tmp/server.log.gz - Kernel RPC Debug Log from the server
How reproducible:
Happens from 10 to 90 minutes after booting the diskless node.
Actual results:
NFS connections stop responding, system hangs or becomes very slow and
unresponsive (it doesnt respond to Ctrl+Alt+Del as well). 60 to 90 minutes
after the first server time out client says server OK but the client is
still
unresponsive. Immediately after that the client logs server connection loss
again which leads to continues loop. Client is still unresponsive. Sometime=
s
client resumes normal operation for couple of hours but then the problem
repeats.
Connectivity info:=20
Both the client and the server are connected to Gigabit Ethernet Cisco Metr=
o
series managable switch. Both of them use Intel Pro 82545GM Gigabit Etherne=
t
Server Controllers. Neither one of them log any Ethernet errors and none ar=
e
logged by the switch.
Client & Server Load:
For the purposes of testing both machines were only running needed daemons
and
weren't loaded at all.
Client & Server Kernel:
On both the client and server custom compiled linux 2.6.29.3 kernel was
used.
Configuration file @ http://fixity.net/tmp/config-2.6.29.3.gz
Client & Server Network interface fragmented packet queue length:
net.ipv4.ipfrag_high_thresh =3D 524288
net.ipv4.ipfrag_low_thresh =3D 393216
Client Versions:
libnfsidmap2/squeeze uptodate 0.21-2
nfs-common/squeeze uptodate 1:1.1.4-1
Client Mount (cat /proc/mounts | grep nfsroot):
10.11.11.1:/nfsroot / nfs
rw,vers=3D3,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,nointr,nolock,p=
roto=3Dtcp,timeo=3D7,retrans=3D10,sec=3Dsys,addr=3D10.11.11.1
0 0
Client fstab:
proc /proc proc defaults 0 0
/dev/nfs / nfs defaults 1 1
none /tmp tmpfs defaults 0 0
none /var/run tmpfs defaults 0 0
none /var/lock tmpfs defaults 0 0
none /var/tmp tmpfs defaults 0 0
Client Daemons:
portmap, rpc.statd, rpc.idmapd
Server Daemons:
portmap, rpc.statd, rpc.idmapd, rpc.mountd --manage-gids
Server Versions:
libnfsidmap2/squeeze uptodate 0.21-2
nfs-common/squeeze uptodate 1:1.1.4-1
nfs-kernel-server/testing uptodate 1:1.1.4-1
Server Export:
/nfsroot 10.11.11.*(rw,no_root_squash,async,no_subtree_check)
Server Options:
RPCNFSDCOUNT=3D16
RPCNFSDPRIORITY=3D0
RPCMOUNTDOPTS=3D--manage-gids
NEED_SVCGSSD=3Dno
RPCSVCGSSDOPTS=3Dno
Additional Info:
Since I have read that tweaking the nfsroot mount options could improve the=
=20
situation a have tested with different options as follows:
rsize/wsize=3D1024|2048|4096|8192|32768|524288
timeo=3D7|15|60|600
retrans=3D3|10|20
None resulted in solving the problem.
I have also tested with the following version on the client and server end
without any difference in the behaviour:
libnfsidmap2/testing uptodate 0.21-2
nfs-common 1:1.1.6-1 newer than version in archive
nfs-kernel-server 1:1.1.6-1 newer than version in archive
Any help or suggestions on fixing the problem would be highly appreciated. =
I=20
have been messing with that problem for the last couple of weeks and ran ou=
t
of ideas.
Best Regards,
Jerome Walters =20
--=20
View this message in context: http://www.nabble.com/-OT--Lite5200B-w--nfs-r=
oot-hangs-after-some-time-tp23181953p23606187.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: fs_enet build breakage
From: Benjamin Herrenschmidt @ 2009-05-18 21:50 UTC (permalink / raw)
To: Scott Wood; +Cc: Kumar Gala, linuxppc-dev list
In-Reply-To: <20090518172016.GB18620@b07421-ec1.am.freescale.net>
On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote:
> > I'm pretty sure the driver changes to address this are in dave's
> net-
> > next tree.
>
> Won't this break git bisect?
>
> Not to mention anyone trying to use your tree now...
Right, though if you have the commit ID in DaveM tree, I can work with
him to sort out that driver, for example by having the same commit in
my tree.
Ben.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Benjamin Herrenschmidt @ 2009-05-18 21:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <DE108B1C-85A6-4D1F-8E4D-E1AB5495578A@kernel.crashing.org>
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>
> Part of this is how the generic swiotlb code works and part of it
> was
> our desire not to bloat dev archdata by adding such info that as you
> say is either bus specific or conveyed in the dma addr mask.
Right but perf sucks :-)
Maybe an option is to clamp the DMA mask when it's set by the driver to
limit it to the available inbound window ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 20:15 UTC (permalink / raw)
To: Gabriel Paubert
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <20090518184752.GA12972@iram.es>
Hello Gabriel,
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]
> Sent: Monday, May 18, 2009 1:48 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Lennert Buytenhek; tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David
> Miller
> Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1
wrote:
> > > -----Original Message-----
> > > From: =
linuxppc-dev-bounces+emilian.medve=3Dfreescale.com@ozlabs.org
> > [mailto:linuxppc-dev-
> > > bounces+emilian.medve=3Dfreescale.com@ozlabs.org] On Behalf Of
Gabriel
> > Paubert
> > > Sent: Monday, May 18, 2009 12:38 PM
> > > To: Lennert Buytenhek
> > > Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
> > netdev@vger.kernel.org; David Miller
> > > Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
> > >
> > > Since PPC_MUTIPLATFORM was removed, it was impossible to select
the
> > > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > > the driver on CHRP platforms; Pegasos is a CHRP platform and the
> > driver
> > > will not work without arch/powerpc/platforms/chrp/pegasos_eth.
> > >
> > > Signed-off-by: Gabriel Paubert <paubert@iram.es>
> > >
> > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > > index 214a92d..6fc0ff4 100644
> > > --- a/drivers/net/Kconfig
> > > +++ b/drivers/net/Kconfig
> > > @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
> > >
> > > config MV643XX_ETH
> > > tristate "Marvell Discovery (643XX) and Orion ethernet support"
> > > - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
> > PLAT_ORION
> > > + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> > > select INET_LRO
> > > select PHYLIB
> > > help
> >
> > This got fixed here:
> >
http://git.kernel.org/?p=3Dlinux/kernel/git/davem/net-next-2.6.git;a=3Dco=
mmi
> > tdiff;h=3D952ee9df26c487f2d73b2dced58ec904f19ea0f8
>=20
> Ok, I was not aware of it, but the fact is that MV64360 no more exists
> and the only non MV64X60 platform that may need it is the Pegasos (to
my
> knowledge) and it relies on some platform specific code enabled
> by PPC_CHRP.
You're correct. MV64360 seems to be stale. Do you want to re-spin your
patch to get rid of it?
(I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
=20
Cheers,
Emil.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Segher Boessenkool @ 2009-05-18 19:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Ingo Molnar, Sam Ravnborg
In-Reply-To: <1242620044.18075.31.camel@pasglop>
> Segher, what are we missing here ?
The symbol name is misleading, and the help text is incorrect.
With those things fixed, I won't oppose the patch; it would
be nice if the logic here was cleaned up to avoid all the
double negations, but I'm not going to do it, so I won't ask
others to either.
Segher
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 18:47 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D323@az33exm24.fsl.freescale.net>
On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1 wrote:
> > -----Original Message-----
> > From: linuxppc-dev-bounces+emilian.medve=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-
> > bounces+emilian.medve=freescale.com@ozlabs.org] On Behalf Of Gabriel
> Paubert
> > Sent: Monday, May 18, 2009 12:38 PM
> > To: Lennert Buytenhek
> > Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
> netdev@vger.kernel.org; David Miller
> > Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
> >
> > Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > the driver on CHRP platforms; Pegasos is a CHRP platform and the
> driver
> > will not work without arch/powerpc/platforms/chrp/pegasos_eth.
> >
> > Signed-off-by: Gabriel Paubert <paubert@iram.es>
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 214a92d..6fc0ff4 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
> >
> > config MV643XX_ETH
> > tristate "Marvell Discovery (643XX) and Orion ethernet support"
> > - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
> PLAT_ORION
> > + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> > select INET_LRO
> > select PHYLIB
> > help
>
> This got fixed here:
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commi
> tdiff;h=952ee9df26c487f2d73b2dced58ec904f19ea0f8
Ok, I was not aware of it, but the fact is that MV64360 no more exists
and the only non MV64X60 platform that may need it is the Pegasos (to my
knowledge) and it relies on some platform specific code enabled
by PPC_CHRP.
Regards,
Gabriel
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Chris Plasun @ 2009-05-18 18:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <c384c5ea0905181118g34896cc3s1e77b9ba22c4e164@mail.gmail.com>
Hi Leon,
Leon Woestenberg wrote:
> Hello Chris,
>
> On Mon, May 18, 2009 at 8:06 PM, Chris Plasun <chrispl78@yahoo.com> wrote:
>> Scott Wood wrote:
>>> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>>>> (I haven't found any answers in the archives)
>>>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>>> Will Samba run on a Freescale MPC8313?
>>> It should (and if it doesn't, file a bug with them).
>>> Userspace is pretty much the same at the source-code and user-interface
>>> level -- the answer to "how do I do X on this PPC board" is generally the
>>> same as the answer to "how do I do X on Linux", other than that you may
>>> need to compile some packages manually if they don't come with whatever
>>> distribution you're using.
>> Thanks Scott.
>>
>> I did some more reading on the board and it appears that it's not as limited
>> as I thought. The "custom" Linux we're running is very limited (so it
>> appears) and I interpreted the board to be so as well.
>>
>
> To build your own fully-open Linux for this board, I can recommend
> both these projects:
>
> LTIB (http://www.bitshrine.org/)
> OpenEmbedded (http://www.openembedded.org/)
>
> We use the latter in an industrial setting with much success,
Thanks Leon. I'll definitely be back to ask for help to get these
distributions running =)
cp
^ 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