* [Xenomai-help] [Xenomai -help] User space access to DMA memory @ 2010-12-20 16:52 Herrera-Bendezu, Luis 2011-01-01 22:44 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2010-12-20 16:52 UTC (permalink / raw) To: xenomai [-- Attachment #1: Type: text/plain, Size: 2083 bytes --] Hello: I have the following setup: PPC405EX Linux 2.6.30.3 Xenomai 2.4.10 I-pipe 2.7-02 ppc_4xx-gcc (GCC) 4.2.2 Configuration file is attached I am writing an RTDM driver to allocate DMA memory and map it to user space using functions: pci_alloc_consistent() rtdm_mmap_to_user() Driver can access this memory but user space access causes Oops and Kernel panic: DataData machine check in kernel mode. Oops: Machine check, sig: 7 [#1] Flex-AM Modules linked in: magnum dsp vreg vsync flx_alt_tse codec flx_alt_fpga at24 pca 953x [last unloaded: at24] NIP: c0008e24 LR: c0010920 CTR: c01d50d0 REGS: cfff9f50 TRAP: 0202 Not tainted (2.6.30.3-00059-g8f94ee9) MSR: 00021030 <ME,CE,IR,DR> CR: 04000022 XER: 20000000 TASK = cf635ce0[1455] 'ancvbirt' THREAD: cf646000 GPR00: 00008030 cf647d60 cf635ce0 cf647d70 00000001 00000005 c01d2d30 000060da GPR08: 00000034 c0010920 00021032 c0008e24 cf646248 10074cf0 0fff2500 0ffe871c GPR16: 0ffb702c 0ffdf628 cf647e38 00008000 c032947c 10624dd3 00044b83 00000004 GPR24: c03e5098 cf647e4c c03b3350 00000007 cf647ec8 c03e5140 c03e513c 00000000 NIP [c0008e24] __ipipe_grab_irq+0x0/0xa4 LR [c0010920] __ipipe_ret_from_except+0x0/0xc Call Trace: [cf647e20] [c03e5140] 0xc03e5140 [cf647e30] [c0024d64] vprintk+0x2a0/0x344 [cf647ec0] [c0025310] printk+0x9c/0x1c0 [cf647f10] [c000cd8c] machine_check_4xx+0x28/0x84 [cf647f20] [c000d658] machine_check_exception+0x64/0x228 [cf647f40] [c0010624] ret_from_crit_exc+0x0/0x11c Instruction dump: 4804c1ed 2f830200 7c651b78 409e0014 80010014 38210010 7c0803a6 4e800020 3c60c032 38636190 38800200 4801af99 <9421fff0> 7c0802a6 93e1000c 90010014 Kernel panic - not syncing: Fatal exception I also tried rtdm_iomap_to_user() using the bus address returned by pci_alloc_consistent() with same result. In addition, access to DMA memory using 'mm' utility works. So it appears to be an issue with rtdm_mmap_to_user()/rtdm_iomap_to_user(). Is this usage correct/allowed? or should I use instead the memory heap services? Thanks, Luis Herrera-Bendezu [-- Attachment #2: flex-am_defconfig --] [-- Type: application/octet-stream, Size: 40405 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30.3 # Wed Aug 25 10:45:06 2010 # # CONFIG_PPC64 is not set # # Processor support # # CONFIG_6xx is not set # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set CONFIG_40x=y # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_4xx=y CONFIG_PPC_MMU_NOHASH=y # CONFIG_PPC_MM_SLICES is not set CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y # CONFIG_SOFTDISABLE is not set CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_PPC_DCR_NATIVE=y # CONFIG_PPC_DCR_MMIO is not set CONFIG_PPC_DCR=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set # CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y # CONFIG_LOGBUFFER is not set CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Real-time sub-system # CONFIG_XENOMAI=y CONFIG_XENO_GENERIC_STACKPOOL=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_PRIOCPL=y CONFIG_XENO_OPT_PIPELINE_HEAD=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=256 CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128 CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set # CONFIG_XENO_OPT_SHIRQ is not set # # Timing # # CONFIG_XENO_OPT_TIMING_PERIODIC is not set CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # # Scalability # # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_TIMER_WHEEL is not set # # Machine # # # Interfaces # CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PERIOD=0 CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024 CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y # CONFIG_XENO_OPT_NATIVE_INTR is not set CONFIG_XENO_SKIN_POSIX=y CONFIG_XENO_OPT_POSIX_PERIOD=0 CONFIG_XENO_OPT_POSIX_SHM=y # CONFIG_XENO_OPT_POSIX_INTR is not set # CONFIG_XENO_OPT_POSIX_SELECT is not set CONFIG_XENO_OPT_DEBUG_POSIX=y # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_OPT_RTDM_PERIOD=0 CONFIG_XENO_OPT_RTDM_FILDES=128 # CONFIG_XENO_OPT_RTDM_SELECT is not set # # Drivers # # # Serial drivers # # CONFIG_XENO_DRIVERS_16550A is not set # # Testing drivers # CONFIG_XENO_KLATENCY_MODULE=m CONFIG_XENO_DRIVERS_TIMERBENCH=m CONFIG_XENO_DRIVERS_KLATENCY=m CONFIG_XENO_DRIVERS_IRQBENCH=m CONFIG_XENO_DRIVERS_SWITCHTEST=m # # CAN drivers # # CONFIG_XENO_DRIVERS_CAN is not set # CONFIG_FREEZER is not set CONFIG_PPC4xx_PCI_EXPRESS=y # # Platform support # # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC4xx_GPIO=y # CONFIG_ACADIA is not set # CONFIG_EP405 is not set CONFIG_FLEX_AM=y # CONFIG_HCU4 is not set # CONFIG_KILAUEA is not set # CONFIG_MAKALU is not set # CONFIG_WALNUT is not set # CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set # CONFIG_PPC40x_SIMPLE is not set CONFIG_405EX=y # CONFIG_IPIC is not set # CONFIG_MPIC is not set # CONFIG_MPIC_WEIRD is not set # CONFIG_PPC_I8259 is not set # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set # CONFIG_PPC_MPC106 is not set # CONFIG_PPC_970_NAP is not set # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_FSL_ULI1575 is not set # CONFIG_SIMPLE_GPIO is not set # # Kernel options # CONFIG_IPIPE=y CONFIG_IPIPE_DOMAINS=4 CONFIG_IPIPE_COMPAT=y CONFIG_IPIPE_DELAYED_ATOMICSW=y CONFIG_IPIPE_HAVE_PREEMPTIBLE_SWITCH=y # CONFIG_HIGHMEM is not set CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_SCHED_HRTICK=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set # CONFIG_HAVE_AOUT is not set # CONFIG_BINFMT_MISC is not set # CONFIG_MATH_EMULATION is not set # CONFIG_IOMMU_HELPER is not set CONFIG_PPC_NEED_DMA_SYNC_OPS=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set # CONFIG_PPC_256K_PAGES is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_PROC_DEVICETREE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="" CONFIG_EXTRA_TARGETS="" # CONFIG_PM is not set CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ZONE_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_4xx_SOC=y CONFIG_PPC_PCI_CHOICE=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCI_SYSCALL=y CONFIG_PCIEPORTBUS=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCIEAER=y # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set # CONFIG_PCI_STUB is not set # CONFIG_PCI_IOV is not set # CONFIG_PCCARD is not set CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_FAKE=y # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set # CONFIG_HAS_RAPIDIO is not set # # Advanced setup # # CONFIG_ADVANCED_OPTIONS is not set # # Default settings for advanced configuration options are used # CONFIG_LOWMEM_SIZE=0x30000000 CONFIG_PAGE_OFFSET=0xc0000000 CONFIG_KERNEL_START=0xc0000000 CONFIG_PHYSICAL_START=0x00000000 CONFIG_TASK_SIZE=0xc0000000 CONFIG_CONSISTENT_SIZE=0x00200000 CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_NET_DSA is not set CONFIG_VLAN_8021Q=y # CONFIG_VLAN_8021Q_GVRP is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set # CONFIG_NET_SCHED is not set # CONFIG_DCB is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # CONFIG_WIRELESS is not set # CONFIG_WIMAX is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_CONCAT is not set CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_OF_PARTS=y # CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y # CONFIG_MTD_BLKDEVS is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set # CONFIG_RFD_FTL is not set # CONFIG_SSFDC is not set # CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=y CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_GEN_PROBE=y # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_CFI_AMDSTD=y # CONFIG_MTD_CFI_STAA is not set CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set CONFIG_MTD_PHYSMAP_OF=y # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_DATAFLASH is not set CONFIG_MTD_M25P80=m CONFIG_M25PXX_USE_FAST_READ=y # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_NAND is not set # CONFIG_MTD_ONENAND is not set # # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set # # UBI - Unsorted block images # # CONFIG_MTD_UBI is not set CONFIG_OF_DEVICE=y CONFIG_OF_GPIO=y CONFIG_OF_I2C=y CONFIG_OF_SPI=y # CONFIG_PARPORT is not set CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=35000 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_XILINX_SYSACE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_MISC_DEVICES=y # CONFIG_PHANTOM is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_HP_ILO is not set # CONFIG_ISL29003 is not set # CONFIG_C2PORT is not set # # EEPROM support # CONFIG_EEPROM_AT24=m # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_93CX6 is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_MPT2SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_LIBFC is not set # CONFIG_LIBFCOE is not set # CONFIG_FCOE is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_MVSAS is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # Enable only one of the two stacks, unless you know what you are doing # # CONFIG_FIREWIRE is not set # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_COMPAT_NET_DEV_OPS=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_VETH is not set # CONFIG_ARCNET is not set # CONFIG_PHYLIB is not set CONFIG_NET_ETHERNET=y # CONFIG_MII is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_ENC28J60 is not set # CONFIG_ETHOC is not set # CONFIG_DNET is not set # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_IBM_NEW_EMAC=y CONFIG_IBM_NEW_EMAC_RXB=256 CONFIG_IBM_NEW_EMAC_TXB=256 CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32 CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256 CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0 # CONFIG_IBM_NEW_EMAC_DEBUG is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set CONFIG_IBM_NEW_EMAC_RGMII=y # CONFIG_IBM_NEW_EMAC_TAH is not set CONFIG_IBM_NEW_EMAC_EMAC4=y # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set # CONFIG_NET_PCI is not set # CONFIG_B44 is not set # CONFIG_ATL2 is not set # CONFIG_NETDEV_1000 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # # Enable WiMAX (Networking options) to see the WiMAX drivers # # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # # CONFIG_INPUT is not set # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # # CONFIG_VT is not set CONFIG_DEVKMEM=y # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_PCI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_UARTLITE is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL is not set CONFIG_UNIX98_PTYS=y # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_HVC_UDBG is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set # CONFIG_GEN_RTC is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_RAW_DRIVER is not set # CONFIG_BOOTCOUNT is not set # CONFIG_TCG_TPM is not set CONFIG_DEVPORT=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_HELPER_AUTO=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_ISCH is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # I2C system bus drivers (mostly embedded / system-on-chip) # # CONFIG_I2C_GPIO is not set CONFIG_I2C_IBM_IIC=y # CONFIG_I2C_MPC is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Graphics adapter I2C/DDC channel drivers # # CONFIG_I2C_VOODOO3 is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_STUB is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_24C01A is not set # CONFIG_SENSORS_AD7416 is not set # CONFIG_DS1682 is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # CONFIG_SPI_BITBANG=y # CONFIG_SPI_GPIO is not set CONFIG_SPI_PPC4xx=y # # SPI Protocol Masters # CONFIG_SPI_SPIDEV=y # CONFIG_SPI_TLE62X0 is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set CONFIG_GPIO_SYSFS=y # # Memory mapped GPIO expanders: # # CONFIG_GPIO_XILINX is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX732X is not set CONFIG_GPIO_PCA953X=m # CONFIG_GPIO_PCF857X is not set # # PCI GPIO expanders: # # CONFIG_GPIO_BT8XX is not set # # SPI GPIO expanders: # # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MCP23S08 is not set # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set CONFIG_HWMON=y CONFIG_HWMON_VID=y # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADCXX is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7473 is not set # CONFIG_SENSORS_ADT7475 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FM75 is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_G760A is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM70 is not set CONFIG_SENSORS_LM75=y # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set CONFIG_SENSORS_LM85=y # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4245 is not set # CONFIG_SENSORS_LM95241 is not set # CONFIG_SENSORS_MAX1111 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_SHT15 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1115 is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=y # CONFIG_THERMAL_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y # # Watchdog Device Drivers # # CONFIG_WD is not set # CONFIG_SOFT_WATCHDOG is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_WDT_CHAIN is not set CONFIG_BOOKE_WDT=y # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_TPS65010 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_MFD_TMIO is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_REGULATOR is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # CONFIG_SOUND is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_MON is not set # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_OHCI_HCD is not set # CONFIG_USB_UHCI_HCD is not set # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # CONFIG_USB_GADGET_MUSB_HDRC is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_VST is not set CONFIG_USB_GADGET=y # CONFIG_USB_GADGET_DEBUG is not set # CONFIG_USB_GADGET_DEBUG_FILES is not set # CONFIG_USB_GADGET_DEBUG_FS is not set CONFIG_USB_GADGET_VBUS_DRAW=2 CONFIG_USB_GADGET_SELECTED=y # CONFIG_USB_GADGET_AT91 is not set # CONFIG_USB_GADGET_ATMEL_USBA is not set # CONFIG_USB_GADGET_FSL_USB2 is not set # CONFIG_USB_GADGET_LH7A40X is not set # CONFIG_USB_GADGET_OMAP is not set # CONFIG_USB_GADGET_PXA25X is not set # CONFIG_USB_GADGET_PXA27X is not set # CONFIG_USB_GADGET_S3C2410 is not set # CONFIG_USB_GADGET_IMX is not set # CONFIG_USB_GADGET_M66592 is not set # CONFIG_USB_GADGET_AMD5536UDC is not set # CONFIG_USB_GADGET_FSL_QE is not set # CONFIG_USB_GADGET_CI13XXX is not set # CONFIG_USB_GADGET_NET2280 is not set # CONFIG_USB_GADGET_GOKU is not set # CONFIG_USB_GADGET_MUSBHSFC is not set CONFIG_USB_GADGET_DWC_OTG=y CONFIG_USB_DWC_OTG=y CONFIG_USB_DWC_OTG_INTERNAL_DMA=y # CONFIG_USB_GADGET_DUMMY_HCD is not set CONFIG_USB_GADGET_DUALSPEED=y # CONFIG_USB_ZERO is not set # CONFIG_USB_ETH is not set # CONFIG_USB_GADGETFS is not set # CONFIG_USB_FILE_STORAGE is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set # # OTG and related infrastructure # # CONFIG_USB_GPIO_VBUS is not set # CONFIG_NOP_USB_XCEIV is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set # CONFIG_RTC_CLASS is not set # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set CONFIG_UIO=y # CONFIG_UIO_CIF is not set # CONFIG_UIO_PDRV is not set # CONFIG_UIO_PDRV_GENIRQ is not set # CONFIG_UIO_SMX is not set # CONFIG_UIO_AEC is not set # CONFIG_UIO_SERCOS3 is not set # CONFIG_STAGING is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set # CONFIG_EXT4_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_BTRFS_FS is not set CONFIG_FILE_LOCKING=y CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=y # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set CONFIG_MISC_FILESYSTEMS=y # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS2_FS is not set # CONFIG_YAFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_SQUASHFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_OMFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # CONFIG_NILFS2_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set # CONFIG_NFS_V4 is not set CONFIG_ROOT_NFS=y CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set # CONFIG_NFSD_V4 is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # CONFIG_DLM is not set # CONFIG_BINARY_PRINTF is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_LAST_BIT=y # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_DECOMPRESS_GZIP=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_HAVE_LMB=y CONFIG_NLATTR=y # # Kernel hacking # # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_IPIPE_DEBUG is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_DETECT_HUNG_TASK=y # CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_CPU_STALL_DETECTOR is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_TRACING_SUPPORT=y # # Tracers # # CONFIG_FUNCTION_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_CONTEXT_SWITCH_TRACER is not set # CONFIG_EVENT_TRACER is not set # CONFIG_BOOT_TRACER is not set # CONFIG_TRACE_BRANCH_PROFILING is not set # CONFIG_STACK_TRACER is not set # CONFIG_KMEMTRACE is not set # CONFIG_WORKQUEUE_TRACER is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_DYNAMIC_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set CONFIG_PRINT_STACK_DEPTH=64 # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_CODE_PATCHING_SELFTEST is not set # CONFIG_FTR_FIXUP_SELFTEST is not set # CONFIG_MSI_BITMAP_SELFTEST is not set # CONFIG_XMON is not set # CONFIG_IRQSTACKS is not set # CONFIG_VIRQ_DEBUG is not set # CONFIG_BDI_SWITCH is not set # CONFIG_PPC_EARLY_DEBUG is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITYFS is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # # CONFIG_CRYPTO_FIPS is not set CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_PCOMP=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set CONFIG_CRYPTO_WORKQUEUE=y # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_PCBC=y # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # # Compression # # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_ZLIB is not set # CONFIG_CRYPTO_LZO is not set # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_HIFN_795X is not set # CONFIG_CRYPTO_DEV_PPC4XX is not set # CONFIG_PPC_CLOCK is not set # CONFIG_VIRTUALIZATION is not set ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2010-12-20 16:52 [Xenomai-help] [Xenomai -help] User space access to DMA memory Herrera-Bendezu, Luis @ 2011-01-01 22:44 ` Gilles Chanteperdrix 2011-01-05 21:03 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-01 22:44 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > Hello: > > I have the following setup: > PPC405EX > Linux 2.6.30.3 > Xenomai 2.4.10 > I-pipe 2.7-02 > ppc_4xx-gcc (GCC) 4.2.2 > Configuration file is attached Do you have the same issue with the latest version of the I-pipe patch for this same version of the Linux kernel? It should be 2.8-00. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-01 22:44 ` Gilles Chanteperdrix @ 2011-01-05 21:03 ` Herrera-Bendezu, Luis 2011-01-05 21:33 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-05 21:03 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Gilles: >Herrera-Bendezu, Luis wrote: >> Hello: >> >> I have the following setup: >> PPC405EX >> Linux 2.6.30.3 >> Xenomai 2.4.10 >> I-pipe 2.7-02 >> ppc_4xx-gcc (GCC) 4.2.2 >> Configuration file is attached > >Do you have the same issue with the latest version of the I-pipe patch >for this same version of the Linux kernel? It should be 2.8-00. Tried I-pipe 2.8-00 which needs Linux 2.6.32. It resulted on same problem as reported with Linux 2.6.30.3 I-pipe 2.7-02. Was there any particular set of changes that you expected it could fix the problem? Do you think more recent versions may work? If yes, which version could be tried? Thanks, Luis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-05 21:03 ` Herrera-Bendezu, Luis @ 2011-01-05 21:33 ` Gilles Chanteperdrix 2011-01-05 22:07 ` Steven A. Falco 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-05 21:33 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > Gilles: > >> Herrera-Bendezu, Luis wrote: >>> Hello: >>> >>> I have the following setup: >>> PPC405EX >>> Linux 2.6.30.3 >>> Xenomai 2.4.10 >>> I-pipe 2.7-02 >>> ppc_4xx-gcc (GCC) 4.2.2 >>> Configuration file is attached >> Do you have the same issue with the latest version of the I-pipe patch >> for this same version of the Linux kernel? It should be 2.8-00. > > Tried I-pipe 2.8-00 which needs Linux 2.6.32. Sorry, I misread the ftp list, I was rather thinking about: http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch It resulted on same problem > as reported with Linux 2.6.30.3 I-pipe 2.7-02. > > Was there any particular set of changes that you expected it could fix the > problem? Do you think more recent versions may work? If yes, which version > could be tried? Yes, there was a fix, specifially in the powerpc tree, with mappings issue. But I think it is older than 2.6.32. Now that I look at your message again, your problem seems more likely to be in your code. Specifically, you say: "bus address returned by pci_alloc_consistent()". I do not think pci_alloc_consistent return value is a bus address. The dma_handle returned by pointer probably is. But I am not sure you are supposed to know this. Please post your code (or a minimal, standalone version of it which demonstrates the problem). -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-05 21:33 ` Gilles Chanteperdrix @ 2011-01-05 22:07 ` Steven A. Falco 2011-01-05 22:29 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Steven A. Falco @ 2011-01-05 22:07 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: > Herrera-Bendezu, Luis wrote: >> Gilles: >> >>> Herrera-Bendezu, Luis wrote: >>>> Hello: >>>> >>>> I have the following setup: >>>> PPC405EX >>>> Linux 2.6.30.3 >>>> Xenomai 2.4.10 >>>> I-pipe 2.7-02 >>>> ppc_4xx-gcc (GCC) 4.2.2 >>>> Configuration file is attached >>> Do you have the same issue with the latest version of the I-pipe patch >>> for this same version of the Linux kernel? It should be 2.8-00. >> >> Tried I-pipe 2.8-00 which needs Linux 2.6.32. > > Sorry, I misread the ftp list, I was rather thinking about: > http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch > > > It resulted on same problem >> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >> >> Was there any particular set of changes that you expected it could fix the >> problem? Do you think more recent versions may work? If yes, which version >> could be tried? > > Yes, there was a fix, specifially in the powerpc tree, with mappings > issue. But I think it is older than 2.6.32. > > Now that I look at your message again, your problem seems more likely to > be in your code. Specifically, you say: "bus address returned by > pci_alloc_consistent()". I do not think pci_alloc_consistent return > value is a bus address. The dma_handle returned by pointer probably is. > But I am not sure you are supposed to know this. pci_alloc_consistent() returns two values. The kernel address is returned directly (as a void *), and the bus address is returned through the dma_handle pointer (third function argument). Luis' original email indicated that he tried rtdm_mmap_to_user() on the kernel address, and he tried rtdm_iomap_to_user() on the bus address. Either way caused the crash he reported. We have a home-grown program (mm) that basically opens /dev/mem and allows peek/poke. Using that with the bus address works to access the memory. We also pass that address to our hardware, and it correctly DMAs the data. So we believe the bus address is correct. I believe Luis has also tried a third approach - allocating with kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the resulting pointer. That works, but getting the bus address is a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. So there is something different about the way pci_alloc_consistent() allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) works with rtdm_mmap_to_user() but pci_alloc_consistent() does not. Steve > > Please post your code (or a minimal, standalone version of it which > demonstrates the problem). > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-05 22:07 ` Steven A. Falco @ 2011-01-05 22:29 ` Gilles Chanteperdrix 2011-01-06 13:48 ` Herrera-Bendezu, Luis 2011-01-06 14:32 ` Steven A. Falco 0 siblings, 2 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-05 22:29 UTC (permalink / raw) To: Steven A. Falco; +Cc: xenomai Steven A. Falco wrote: > On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >> Herrera-Bendezu, Luis wrote: >>> Gilles: >>> >>>> Herrera-Bendezu, Luis wrote: >>>>> Hello: >>>>> >>>>> I have the following setup: >>>>> PPC405EX >>>>> Linux 2.6.30.3 >>>>> Xenomai 2.4.10 >>>>> I-pipe 2.7-02 >>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>> Configuration file is attached >>>> Do you have the same issue with the latest version of the I-pipe patch >>>> for this same version of the Linux kernel? It should be 2.8-00. >>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >> Sorry, I misread the ftp list, I was rather thinking about: >> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch >> >> >> It resulted on same problem >>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>> >>> Was there any particular set of changes that you expected it could fix the >>> problem? Do you think more recent versions may work? If yes, which version >>> could be tried? >> Yes, there was a fix, specifially in the powerpc tree, with mappings >> issue. But I think it is older than 2.6.32. >> >> Now that I look at your message again, your problem seems more likely to >> be in your code. Specifically, you say: "bus address returned by >> pci_alloc_consistent()". I do not think pci_alloc_consistent return >> value is a bus address. The dma_handle returned by pointer probably is. >> But I am not sure you are supposed to know this. > > pci_alloc_consistent() returns two values. The kernel address is > returned directly (as a void *), and the bus address is returned > through the dma_handle pointer (third function argument). > > Luis' original email indicated that he tried rtdm_mmap_to_user() > on the kernel address, and he tried rtdm_iomap_to_user() on the > bus address. Either way caused the crash he reported. Ok. Could you try to do the same operation with the native API? You just have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create to get the same effect as pci_dma_alloc_coherent. Just to see if the error lies in RTDM implementation or in Xenomai generic code. > > We have a home-grown program (mm) that basically opens /dev/mem > and allows peek/poke. Using that with the bus address works to > access the memory. We also pass that address to our hardware, > and it correctly DMAs the data. So we believe the bus address > is correct. You mean much like devmem2? Now even part of the busybox? > > I believe Luis has also tried a third approach - allocating with > kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the > resulting pointer. That works, but getting the bus address is > a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. > > So there is something different about the way pci_alloc_consistent() > allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) > works with rtdm_mmap_to_user() but pci_alloc_consistent() does > not. This gives me an idea. Could you try the following patch? Even before trying the native API. diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c index 3495e63..d7dd3db 100644 --- a/ksrc/skins/rtdm/drvlib.c +++ b/ksrc/skins/rtdm/drvlib.c @@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) vaddr = (unsigned long)mmap_data->src_vaddr; paddr = mmap_data->src_paddr; if (paddr == 0) /* kmalloc memory? */ - paddr = __pa(vaddr); + paddr = page_to_phys(virt_to_page(vaddr)); maddr = vma->vm_start; size = vma->vm_end - vma->vm_start; -- Gilles. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-05 22:29 ` Gilles Chanteperdrix @ 2011-01-06 13:48 ` Herrera-Bendezu, Luis 2011-01-06 13:55 ` Gilles Chanteperdrix 2011-01-06 14:32 ` Steven A. Falco 1 sibling, 1 reply; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-06 13:48 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >Steven A. Falco wrote: >> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>> Herrera-Bendezu, Luis wrote: >>>> Gilles: >>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>> Hello: >>>>>> >>>>>> I have the following setup: >>>>>> PPC405EX >>>>>> Linux 2.6.30.3 >>>>>> Xenomai 2.4.10 >>>>>> I-pipe 2.7-02 >>>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>>> Configuration file is attached >>>>> Do you have the same issue with the latest version of the I-pipe patch >>>>> for this same version of the Linux kernel? It should be 2.8-00. >>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >>> Sorry, I misread the ftp list, I was rather thinking about: >>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7- >06.patch >>> >>> >>> It resulted on same problem >>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>>> >>>> Was there any particular set of changes that you expected it could fix the >>>> problem? Do you think more recent versions may work? If yes, which version >>>> could be tried? >>> Yes, there was a fix, specifially in the powerpc tree, with mappings >>> issue. But I think it is older than 2.6.32. >>> >>> Now that I look at your message again, your problem seems more likely to >>> be in your code. Specifically, you say: "bus address returned by >>> pci_alloc_consistent()". I do not think pci_alloc_consistent return >>> value is a bus address. The dma_handle returned by pointer probably is. >>> But I am not sure you are supposed to know this. >> >> pci_alloc_consistent() returns two values. The kernel address is >> returned directly (as a void *), and the bus address is returned >> through the dma_handle pointer (third function argument). >> >> Luis' original email indicated that he tried rtdm_mmap_to_user() >> on the kernel address, and he tried rtdm_iomap_to_user() on the >> bus address. Either way caused the crash he reported. > >Ok. Could you try to do the same operation with the native API? You just >have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >to get the same effect as pci_dma_alloc_coherent. > >Just to see if the error lies in RTDM implementation or in Xenomai >generic code. > > >> >> We have a home-grown program (mm) that basically opens /dev/mem >> and allows peek/poke. Using that with the bus address works to >> access the memory. We also pass that address to our hardware, >> and it correctly DMAs the data. So we believe the bus address >> is correct. > >You mean much like devmem2? Now even part of the busybox? > >> >> I believe Luis has also tried a third approach - allocating with >> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the >> resulting pointer. That works, but getting the bus address is >> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. >> >> So there is something different about the way pci_alloc_consistent() >> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) >> works with rtdm_mmap_to_user() but pci_alloc_consistent() does >> not. > >This gives me an idea. Could you try the following patch? Even before >trying the native API. > >diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >index 3495e63..d7dd3db 100644 >--- a/ksrc/skins/rtdm/drvlib.c >+++ b/ksrc/skins/rtdm/drvlib.c >@@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) > vaddr = (unsigned long)mmap_data->src_vaddr; > paddr = mmap_data->src_paddr; > if (paddr == 0) /* kmalloc memory? */ >- paddr = __pa(vaddr); >+ paddr = page_to_phys(virt_to_page(vaddr)); > > maddr = vma->vm_start; > size = vma->vm_end - vma->vm_start; > > >-- > Gilles. Note: patch was slightly modified to: diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c index 8922689..c8967db 100644 --- a/ksrc/skins/rtdm/drvlib.c +++ b/ksrc/skins/rtdm/drvlib.c @@ -1784,7 +1784,8 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_a paddr = mmap_data->src_paddr; if (!paddr) /* kmalloc memory */ - paddr = virt_to_phys((void *)vaddr); + paddr = page_to_phys(virt_to_page(vaddr)) + + (unsigned long)(vaddr % PAGE_SIZE); maddr = vma->vm_start; size = vma->vm_end - vma->vm_start; Problem remains. These are the two pieces of code: (1) does cause kernel panic when memory is accessed from user space while (2) works fine: #if DMA_KZALLOC == 0 // (1) vsync_private.vbi_mem.kaddr = pci_alloc_consistent(vsync_private.vf_data->fa->pdev, vsync_private.vbi_mem.size, &vsync_private.vbi_mem.daddr); if (vsync_private.vbi_mem.kaddr == NULL) { dev_err(&ofdev->dev, "%s: no memory for PCI DMA\n", __FUNCTION__); retval = -ENOMEM; goto error_fs_bsem_free; } #else // (2) vsync_private.vbi_mem.kaddr = kzalloc(vsync_private.vbi_mem.size, GFP_DMA); vsync_private.vbi_mem.daddr = page_to_phys(virt_to_page(vsync_private.vbi_mem.kaddr)) + (unsigned long)vsync_private.vbi_mem.kaddr % PAGE_SIZE; #endif ... retval = rtdm_mmap_to_user(user_info, vsync_private.vbi_mem.kaddr, vsync_private.vbi_mem.size, PROT_READ | PROT_WRITE, &pcontext->vbi_mem.uaddr, NULL, NULL); This is the kernel log when application ancvbirt attempts to read DMA memory vbi_mem.uaddr: DataData machine check in kernel mode. Oops: Machine check, sig: 7 [#1] Flex-AM Modules linked in: magnum dsp vsync vreg flx_alt_tse codec flx_alt_fpga at24 pca 953x [last unloaded: at24] NIP: c0008e24 LR: c0010920 CTR: c01d50e4 REGS: cfff9f50 TRAP: 0202 Not tainted (2.6.30.3-00059-g8f94ee9-dirty) MSR: 00021030 <ME,CE,IR,DR> CR: 04000022 XER: 20000000 TASK = cdca3180[1716] 'ancvbirt' THREAD: cdc94000 GPR00: 00008030 cfff9d60 cdca3180 cfff9d70 00000001 00000005 c01d2d44 00006027 GPR08: 00000034 c0010920 00021032 c0008e24 cfff8248 10066ad4 0fff2400 0ffe86f8 GPR16: 0ffb702c 0ffdf610 cfff9e38 00008000 c032949c 10624dd3 00044b83 00000004 GPR24: c03e5098 cfff9e4c c03b3350 00000007 cfff9ec8 c03e5140 c03e513c 00000000 NIP [c0008e24] __ipipe_grab_irq+0x0/0xa4 LR [c0010920] __ipipe_ret_from_except+0x0/0xc Call Trace: Instruction dump: 4804c1ed 2f830200 7c651b78 409e0014 80010014 38210010 7c0803a6 4e800020 3c60c032 386361b0 38800200 4801af99 <9421fff0> 7c0802a6 93e1000c 90010014 Kernel panic - not syncing: Fatal exception Rebooting in 1 seconds.. Luis ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-06 13:48 ` Herrera-Bendezu, Luis @ 2011-01-06 13:55 ` Gilles Chanteperdrix 2011-01-11 23:27 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-06 13:55 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >> Steven A. Falco wrote: >>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>> Herrera-Bendezu, Luis wrote: >>>>> Gilles: >>>>> >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>> Hello: >>>>>>> >>>>>>> I have the following setup: >>>>>>> PPC405EX >>>>>>> Linux 2.6.30.3 >>>>>>> Xenomai 2.4.10 >>>>>>> I-pipe 2.7-02 >>>>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>>>> Configuration file is attached >>>>>> Do you have the same issue with the latest version of the I-pipe patch >>>>>> for this same version of the Linux kernel? It should be 2.8-00. >>>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >>>> Sorry, I misread the ftp list, I was rather thinking about: >>>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7- >> 06.patch >>>> >>>> It resulted on same problem >>>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>>>> >>>>> Was there any particular set of changes that you expected it could fix the >>>>> problem? Do you think more recent versions may work? If yes, which version >>>>> could be tried? >>>> Yes, there was a fix, specifially in the powerpc tree, with mappings >>>> issue. But I think it is older than 2.6.32. >>>> >>>> Now that I look at your message again, your problem seems more likely to >>>> be in your code. Specifically, you say: "bus address returned by >>>> pci_alloc_consistent()". I do not think pci_alloc_consistent return >>>> value is a bus address. The dma_handle returned by pointer probably is. >>>> But I am not sure you are supposed to know this. >>> pci_alloc_consistent() returns two values. The kernel address is >>> returned directly (as a void *), and the bus address is returned >>> through the dma_handle pointer (third function argument). >>> >>> Luis' original email indicated that he tried rtdm_mmap_to_user() >>> on the kernel address, and he tried rtdm_iomap_to_user() on the >>> bus address. Either way caused the crash he reported. >> Ok. Could you try to do the same operation with the native API? You just >> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >> to get the same effect as pci_dma_alloc_coherent. >> >> Just to see if the error lies in RTDM implementation or in Xenomai >> generic code. >> >> >>> We have a home-grown program (mm) that basically opens /dev/mem >>> and allows peek/poke. Using that with the bus address works to >>> access the memory. We also pass that address to our hardware, >>> and it correctly DMAs the data. So we believe the bus address >>> is correct. >> You mean much like devmem2? Now even part of the busybox? >> >>> I believe Luis has also tried a third approach - allocating with >>> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the >>> resulting pointer. That works, but getting the bus address is >>> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. >>> >>> So there is something different about the way pci_alloc_consistent() >>> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) >>> works with rtdm_mmap_to_user() but pci_alloc_consistent() does >>> not. >> This gives me an idea. Could you try the following patch? Even before >> trying the native API. >> >> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >> index 3495e63..d7dd3db 100644 >> --- a/ksrc/skins/rtdm/drvlib.c >> +++ b/ksrc/skins/rtdm/drvlib.c >> @@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) >> vaddr = (unsigned long)mmap_data->src_vaddr; >> paddr = mmap_data->src_paddr; >> if (paddr == 0) /* kmalloc memory? */ >> - paddr = __pa(vaddr); >> + paddr = page_to_phys(virt_to_page(vaddr)); >> >> maddr = vma->vm_start; >> size = vma->vm_end - vma->vm_start; >> >> >> -- >> Gilles. > > Note: patch was slightly modified to: > > diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > index 8922689..c8967db 100644 > --- a/ksrc/skins/rtdm/drvlib.c > +++ b/ksrc/skins/rtdm/drvlib.c > @@ -1784,7 +1784,8 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_a > paddr = mmap_data->src_paddr; > if (!paddr) > /* kmalloc memory */ > - paddr = virt_to_phys((void *)vaddr); > + paddr = page_to_phys(virt_to_page(vaddr)) + > + (unsigned long)(vaddr % PAGE_SIZE); I do not think you are supposed to pass a non aligned address to rtdm_mmap_to_user. What about the other thing I asked you to test? -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-06 13:55 ` Gilles Chanteperdrix @ 2011-01-11 23:27 ` Gilles Chanteperdrix 2011-01-12 13:14 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-11 23:27 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Gilles Chanteperdrix wrote: > Herrera-Bendezu, Luis wrote: >> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>> Steven A. Falco wrote: >>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>> Ok. Could you try to do the same operation with the native API? You just >>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>> to get the same effect as pci_dma_alloc_coherent. >>> >>> Just to see if the error lies in RTDM implementation or in Xenomai >>> generic code. >>> >>> > (...) > What about the other thing I asked you to test? > Ping? Any news about this test? -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-11 23:27 ` Gilles Chanteperdrix @ 2011-01-12 13:14 ` Herrera-Bendezu, Luis 2011-01-12 13:35 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-12 13:14 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai >-----Original Message----- >From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >Sent: Tuesday, January 11, 2011 6:28 PM >To: Herrera-Bendezu, Luis >Cc: xenomai-help@gna.org >Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >Gilles Chanteperdrix wrote: >> Herrera-Bendezu, Luis wrote: >>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>> Steven A. Falco wrote: >>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>> Ok. Could you try to do the same operation with the native API? You just >>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>> to get the same effect as pci_dma_alloc_coherent. >>>> >>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>> generic code. >>>> >>>> >> (...) >> What about the other thing I asked you to test? >> > >Ping? Any news about this test? rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. Documentation indicates that H_NONCACHE is not compatible with H_DMA. Other than that memory is accessible both in kernel and user space. There still remains to setup DMA controller with corresponding bus address and handle cache coherency. Will let you know results today. Regards, Luis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 13:14 ` Herrera-Bendezu, Luis @ 2011-01-12 13:35 ` Gilles Chanteperdrix 2011-01-12 16:03 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 13:35 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: >> -----Original Message----- >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >> Sent: Tuesday, January 11, 2011 6:28 PM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >> >> Gilles Chanteperdrix wrote: >>> Herrera-Bendezu, Luis wrote: >>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>> Steven A. Falco wrote: >>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>> Ok. Could you try to do the same operation with the native API? You just >>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>> to get the same effect as pci_dma_alloc_coherent. >>>>> >>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>> generic code. >>>>> >>>>> >>> (...) >>> What about the other thing I asked you to test? >>> >> Ping? Any news about this test? > > rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. > Documentation indicates that H_NONCACHE is not compatible with H_DMA. Right, supporting H_NONCACHED | H_DMA would mean that we would have to use kmalloc/get_free_pages then establish a non-cached mapping in kernel-space with vm_map_ram. Could you try with H_NONCACHED, but without H_DMA? Of course, the mapping can not be used for DMA, as it will probably not be physically contiguous, but at least you can try whether accessing in user-space a non-cached mapping works. In any case, we see a defect in the RTDM interface here: we can not ask the mapping to be mapped non-cacheable, which somewhat defeats the purpose of pci_alloc_consistent. I do not know enough the powerpc architecture to know whether this could be the cause of your issue (the same physical area mapped twice, once cached, once non-cached). However, on the ARM architecture, for instance, it is bad. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 13:35 ` Gilles Chanteperdrix @ 2011-01-12 16:03 ` Herrera-Bendezu, Luis 2011-01-12 16:26 ` Gilles Chanteperdrix 0 siblings, 1 reply; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-12 16:03 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai >From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >Sent: Wednesday, January 12, 2011 8:35 AM >To: Herrera-Bendezu, Luis >Cc: xenomai-help@gna.org >Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >Herrera-Bendezu, Luis wrote: >>> -----Original Message----- >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>> Sent: Tuesday, January 11, 2011 6:28 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai-help@gna.org >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>> >>> Gilles Chanteperdrix wrote: >>>> Herrera-Bendezu, Luis wrote: >>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>> Steven A. Falco wrote: >>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>> >>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>> generic code. >>>>>> >>>>>> >>>> (...) >>>> What about the other thing I asked you to test? >>>> >>> Ping? Any news about this test? >> >> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >> Documentation indicates that H_NONCACHE is not compatible with H_DMA. > >Right, supporting H_NONCACHED | H_DMA would mean that we would have to >use kmalloc/get_free_pages then establish a non-cached mapping in >kernel-space with vm_map_ram. > >Could you try with H_NONCACHED, but without H_DMA? Of course, the >mapping can not be used for DMA, as it will probably not be physically >contiguous, but at least you can try whether accessing in user-space a >non-cached mapping works. It does work but unless an external unit writes to heap memory it would be difficult to verify that the non-cached memory actually works, i.e. access from user space gets expected value(s). > >In any case, we see a defect in the RTDM interface here: we can not ask >the mapping to be mapped non-cacheable, which somewhat defeats the >purpose of pci_alloc_consistent. I do not know enough the powerpc >architecture to know whether this could be the cause of your issue (the >same physical area mapped twice, once cached, once non-cached). However, >on the ARM architecture, for instance, it is bad. > Let me summarize the ideas discussed so far to allocate consistent memory suitable for DMA and corresponding mapping to user space: * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is automatically mapped to user space with rt_heap_bind(). A solution can be to allocate heap with H_SHARED | H_DMA, somehow get bus address of single block of memory (rt_heap { sba } ?) to used for DMA operations. * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. A solution can be to allocate GFP_DMA memory with kmalloc(), use rtdm_mmap to map to user space. Programmatically make memory consistent before/after DMA transfer to/from external unit, e.g. dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is similar to what streaming DMA mappings do. * Ideally, it should be possible to take memory allocated from dma_alloc_coherent()/pci_alloc_consistent() and mapped it to user space using rtdm_mmap(). Luis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 16:03 ` Herrera-Bendezu, Luis @ 2011-01-12 16:26 ` Gilles Chanteperdrix 2011-01-12 18:16 ` Herrera-Bendezu, Luis 0 siblings, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 16:26 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >> Sent: Wednesday, January 12, 2011 8:35 AM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >> >> Herrera-Bendezu, Luis wrote: >>>> -----Original Message----- >>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.org >>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>> >>>> Gilles Chanteperdrix wrote: >>>>> Herrera-Bendezu, Luis wrote: >>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>> Steven A. Falco wrote: >>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>> >>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>> generic code. >>>>>>> >>>>>>> >>>>> (...) >>>>> What about the other thing I asked you to test? >>>>> >>>> Ping? Any news about this test? >>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >> use kmalloc/get_free_pages then establish a non-cached mapping in >> kernel-space with vm_map_ram. >> >> Could you try with H_NONCACHED, but without H_DMA? Of course, the >> mapping can not be used for DMA, as it will probably not be physically >> contiguous, but at least you can try whether accessing in user-space a >> non-cached mapping works. > It does work but unless an external unit writes to heap memory it would > be difficult to verify that the non-cached memory actually works, i.e. > access from user space gets expected value(s). I am quite confident this works. >> In any case, we see a defect in the RTDM interface here: we can not ask >> the mapping to be mapped non-cacheable, which somewhat defeats the >> purpose of pci_alloc_consistent. I do not know enough the powerpc >> architecture to know whether this could be the cause of your issue (the >> same physical area mapped twice, once cached, once non-cached). However, >> on the ARM architecture, for instance, it is bad. >> > > Let me summarize the ideas discussed so far to allocate consistent memory > suitable for DMA and corresponding mapping to user space: > * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is > automatically mapped to user space with rt_heap_bind(). > > A solution can be to allocate heap with H_SHARED | H_DMA, somehow > get bus address of single block of memory (rt_heap { sba } ?) to > used for DMA operations. The test with rt_heap was just a test to have a comparison between xnheap code and rtdm_mmap. But we may indeed want to fix mmappable xnheaps later on. > > * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. > > A solution can be to allocate GFP_DMA memory with kmalloc(), use > rtdm_mmap to map to user space. Programmatically make memory > consistent before/after DMA transfer to/from external unit, e.g. > dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is > similar to what streaming DMA mappings do. > > * Ideally, it should be possible to take memory allocated from > dma_alloc_coherent()/pci_alloc_consistent() and mapped it to > user space using rtdm_mmap(). To check that the non-cacheable mapping is indeed the problem, here is a patch which adds the possibility to add non-cacheable mappings: diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c index 3495e63..ec0ddae 100644 --- a/ksrc/skins/rtdm/drvlib.c +++ b/ksrc/skins/rtdm/drvlib.c @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) struct rtdm_mmap_data { + int noncached; void *src_vaddr; phys_addr_t src_paddr; struct vm_operations_struct *vm_ops; @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) maddr = vma->vm_start; size = vma->vm_end - vma->vm_start; + if (mmap_data->noncached) + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); + #ifdef CONFIG_MMU /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, void *vm_private_data) { struct rtdm_mmap_data mmap_data = { + .noncached = 0, + .src_vaddr = src_addr, + .src_paddr = 0, + .vm_ops = vm_ops, + .vm_private_data = vm_private_data + }; + + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); +} + +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, + void *src_addr, size_t len, + int prot, void **pptr, + struct vm_operations_struct *vm_ops, + void *vm_private_data) +{ + struct rtdm_mmap_data mmap_data = { + .noncached = 1, .src_vaddr = src_addr, .src_paddr = 0, .vm_ops = vm_ops, @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, void *vm_private_data) { struct rtdm_mmap_data mmap_data = { + .noncached = 0, .src_vaddr = NULL, .src_paddr = src_addr, .vm_ops = vm_ops, Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. -- Gilles. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 16:26 ` Gilles Chanteperdrix @ 2011-01-12 18:16 ` Herrera-Bendezu, Luis 2011-01-12 20:20 ` Gilles Chanteperdrix 2011-01-12 20:36 ` Gilles Chanteperdrix 0 siblings, 2 replies; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-12 18:16 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai >From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >Sent: Wednesday, January 12, 2011 11:26 AM >To: Herrera-Bendezu, Luis >Cc: xenomai-help@gna.org >Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >Herrera-Bendezu, Luis wrote: >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>> Sent: Wednesday, January 12, 2011 8:35 AM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai-help@gna.org >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>> >>> Herrera-Bendezu, Luis wrote: >>>>> -----Original Message----- >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai-help@gna.org >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>> >>>>> Gilles Chanteperdrix wrote: >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>> Steven A. Falco wrote: >>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>> >>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>> generic code. >>>>>>>> >>>>>>>> >>>>>> (...) >>>>>> What about the other thing I asked you to test? >>>>>> >>>>> Ping? Any news about this test? >>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>> use kmalloc/get_free_pages then establish a non-cached mapping in >>> kernel-space with vm_map_ram. >>> >>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>> mapping can not be used for DMA, as it will probably not be physically >>> contiguous, but at least you can try whether accessing in user-space a >>> non-cached mapping works. >> It does work but unless an external unit writes to heap memory it would >> be difficult to verify that the non-cached memory actually works, i.e. >> access from user space gets expected value(s). > >I am quite confident this works. > >>> In any case, we see a defect in the RTDM interface here: we can not ask >>> the mapping to be mapped non-cacheable, which somewhat defeats the >>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>> architecture to know whether this could be the cause of your issue (the >>> same physical area mapped twice, once cached, once non-cached). However, >>> on the ARM architecture, for instance, it is bad. >>> >> >> Let me summarize the ideas discussed so far to allocate consistent memory >> suitable for DMA and corresponding mapping to user space: >> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >> automatically mapped to user space with rt_heap_bind(). >> >> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >> get bus address of single block of memory (rt_heap { sba } ?) to >> used for DMA operations. > >The test with rt_heap was just a test to have a comparison between >xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >xnheaps later on. > >> >> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >> >> A solution can be to allocate GFP_DMA memory with kmalloc(), use >> rtdm_mmap to map to user space. Programmatically make memory >> consistent before/after DMA transfer to/from external unit, e.g. >> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >> similar to what streaming DMA mappings do. >> >> * Ideally, it should be possible to take memory allocated from >> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >> user space using rtdm_mmap(). > >To check that the non-cacheable mapping is indeed the problem, here is a >patch which adds the possibility to add non-cacheable mappings: > >diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >index 3495e63..ec0ddae 100644 >--- a/ksrc/skins/rtdm/drvlib.c >+++ b/ksrc/skins/rtdm/drvlib.c >@@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > > #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > struct rtdm_mmap_data { >+ int noncached; > void *src_vaddr; > phys_addr_t src_paddr; > struct vm_operations_struct *vm_ops; >@@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >struct vm_area_struct *vma) > maddr = vma->vm_start; > size = vma->vm_end - vma->vm_start; > >+ if (mmap_data->noncached) >+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >+ > #ifdef CONFIG_MMU > /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ > if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >@@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > void *vm_private_data) > { > struct rtdm_mmap_data mmap_data = { >+ .noncached = 0, >+ .src_vaddr = src_addr, >+ .src_paddr = 0, >+ .vm_ops = vm_ops, >+ .vm_private_data = vm_private_data >+ }; >+ >+ return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >+} >+ >+int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >+ void *src_addr, size_t len, >+ int prot, void **pptr, >+ struct vm_operations_struct *vm_ops, >+ void *vm_private_data) >+{ >+ struct rtdm_mmap_data mmap_data = { >+ .noncached = 1, > .src_vaddr = src_addr, > .src_paddr = 0, > .vm_ops = vm_ops, >@@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > void *vm_private_data) > { > struct rtdm_mmap_data mmap_data = { >+ .noncached = 0, > .src_vaddr = NULL, > .src_paddr = src_addr, > .vm_ops = vm_ops, > >Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. > Get same kernel panic error as before with this patch. I need to look closer at what are the memory allocation functions used by pci_ and dma_. Luis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 18:16 ` Herrera-Bendezu, Luis @ 2011-01-12 20:20 ` Gilles Chanteperdrix 2011-01-12 20:36 ` Gilles Chanteperdrix 1 sibling, 0 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 20:20 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: >> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >> > > Get same kernel panic error as before with this patch. I need to look closer > at what are the memory allocation functions used by pci_ and dma_. You need to look closely into rtdm_mmap_to_buffer what physical address gets passed to the mapping function (should be xnarch_remap_vm_page, as the virtual address being mapped non cacheable, it probably belongs to the vmalloc area). In particular, it should be the same as the dma_addr_t returned by pci_alloc_consistent. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 18:16 ` Herrera-Bendezu, Luis 2011-01-12 20:20 ` Gilles Chanteperdrix @ 2011-01-12 20:36 ` Gilles Chanteperdrix 2011-01-12 21:57 ` Herrera-Bendezu, Luis 1 sibling, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 20:36 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >> Sent: Wednesday, January 12, 2011 11:26 AM >> To: Herrera-Bendezu, Luis >> Cc: xenomai@xenomai.org >> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >> >> Herrera-Bendezu, Luis wrote: >>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>> Sent: Wednesday, January 12, 2011 8:35 AM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.org >>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>> >>>> Herrera-Bendezu, Luis wrote: >>>>>> -----Original Message----- >>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>>> To: Herrera-Bendezu, Luis >>>>>> Cc: xenomai@xenomai.org >>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>> >>>>>> Gilles Chanteperdrix wrote: >>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>>> Steven A. Falco wrote: >>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>>> >>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>>> generic code. >>>>>>>>> >>>>>>>>> >>>>>>> (...) >>>>>>> What about the other thing I asked you to test? >>>>>>> >>>>>> Ping? Any news about this test? >>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>>> use kmalloc/get_free_pages then establish a non-cached mapping in >>>> kernel-space with vm_map_ram. >>>> >>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>>> mapping can not be used for DMA, as it will probably not be physically >>>> contiguous, but at least you can try whether accessing in user-space a >>>> non-cached mapping works. >>> It does work but unless an external unit writes to heap memory it would >>> be difficult to verify that the non-cached memory actually works, i.e. >>> access from user space gets expected value(s). >> I am quite confident this works. >> >>>> In any case, we see a defect in the RTDM interface here: we can not ask >>>> the mapping to be mapped non-cacheable, which somewhat defeats the >>>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>>> architecture to know whether this could be the cause of your issue (the >>>> same physical area mapped twice, once cached, once non-cached). However, >>>> on the ARM architecture, for instance, it is bad. >>>> >>> Let me summarize the ideas discussed so far to allocate consistent memory >>> suitable for DMA and corresponding mapping to user space: >>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >>> automatically mapped to user space with rt_heap_bind(). >>> >>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >>> get bus address of single block of memory (rt_heap { sba } ?) to >>> used for DMA operations. >> The test with rt_heap was just a test to have a comparison between >> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >> xnheaps later on. >> >>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >>> >>> A solution can be to allocate GFP_DMA memory with kmalloc(), use >>> rtdm_mmap to map to user space. Programmatically make memory >>> consistent before/after DMA transfer to/from external unit, e.g. >>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >>> similar to what streaming DMA mappings do. >>> >>> * Ideally, it should be possible to take memory allocated from >>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >>> user space using rtdm_mmap(). >> To check that the non-cacheable mapping is indeed the problem, here is a >> patch which adds the possibility to add non-cacheable mappings: >> >> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >> index 3495e63..ec0ddae 100644 >> --- a/ksrc/skins/rtdm/drvlib.c >> +++ b/ksrc/skins/rtdm/drvlib.c >> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); >> >> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) >> struct rtdm_mmap_data { >> + int noncached; >> void *src_vaddr; >> phys_addr_t src_paddr; >> struct vm_operations_struct *vm_ops; >> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >> struct vm_area_struct *vma) >> maddr = vma->vm_start; >> size = vma->vm_end - vma->vm_start; >> >> + if (mmap_data->noncached) >> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >> + >> #ifdef CONFIG_MMU >> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ >> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, >> void *vm_private_data) >> { >> struct rtdm_mmap_data mmap_data = { >> + .noncached = 0, >> + .src_vaddr = src_addr, >> + .src_paddr = 0, >> + .vm_ops = vm_ops, >> + .vm_private_data = vm_private_data >> + }; >> + >> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >> +} >> + >> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >> + void *src_addr, size_t len, >> + int prot, void **pptr, >> + struct vm_operations_struct *vm_ops, >> + void *vm_private_data) >> +{ >> + struct rtdm_mmap_data mmap_data = { >> + .noncached = 1, >> .src_vaddr = src_addr, >> .src_paddr = 0, >> .vm_ops = vm_ops, >> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, >> void *vm_private_data) >> { >> struct rtdm_mmap_data mmap_data = { >> + .noncached = 0, >> .src_vaddr = NULL, >> .src_paddr = src_addr, >> .vm_ops = vm_ops, >> >> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >> > > Get same kernel panic error as before with this patch. I need to look closer > at what are the memory allocation functions used by pci_ and dma_. Could you try rtdm_iomap_to_user (but beware, pass the physical address returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will not work with vmalloc/ioremap addresses. And pci_alloc_consistent probably returns a vmalloc mapping due to the fact that the mapping needs to be non-cacheable, which will happen if your powerpc does not support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 20:36 ` Gilles Chanteperdrix @ 2011-01-12 21:57 ` Herrera-Bendezu, Luis 2011-01-12 22:11 ` Philippe Gerum 2011-01-12 22:15 ` Gilles Chanteperdrix 0 siblings, 2 replies; 27+ messages in thread From: Herrera-Bendezu, Luis @ 2011-01-12 21:57 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai >-----Original Message----- >From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >Sent: Wednesday, January 12, 2011 3:37 PM >To: Herrera-Bendezu, Luis >Cc: xenomai-help@gna.org >Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >Herrera-Bendezu, Luis wrote: >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>> Sent: Wednesday, January 12, 2011 11:26 AM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai-help@gna.org >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>> >>> Herrera-Bendezu, Luis wrote: >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>> Sent: Wednesday, January 12, 2011 8:35 AM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai-help@gna.org >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>>> -----Original Message----- >>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>>>> To: Herrera-Bendezu, Luis >>>>>>> Cc: xenomai-help@gna.org >>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>> >>>>>>> Gilles Chanteperdrix wrote: >>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>>>> Steven A. Falco wrote: >>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>>>> >>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>>>> generic code. >>>>>>>>>> >>>>>>>>>> >>>>>>>> (...) >>>>>>>> What about the other thing I asked you to test? >>>>>>>> >>>>>>> Ping? Any news about this test? >>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>>>> use kmalloc/get_free_pages then establish a non-cached mapping in >>>>> kernel-space with vm_map_ram. >>>>> >>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>>>> mapping can not be used for DMA, as it will probably not be physically >>>>> contiguous, but at least you can try whether accessing in user-space a >>>>> non-cached mapping works. >>>> It does work but unless an external unit writes to heap memory it would >>>> be difficult to verify that the non-cached memory actually works, i.e. >>>> access from user space gets expected value(s). >>> I am quite confident this works. >>> >>>>> In any case, we see a defect in the RTDM interface here: we can not ask >>>>> the mapping to be mapped non-cacheable, which somewhat defeats the >>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>>>> architecture to know whether this could be the cause of your issue (the >>>>> same physical area mapped twice, once cached, once non-cached). However, >>>>> on the ARM architecture, for instance, it is bad. >>>>> >>>> Let me summarize the ideas discussed so far to allocate consistent memory >>>> suitable for DMA and corresponding mapping to user space: >>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >>>> automatically mapped to user space with rt_heap_bind(). >>>> >>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >>>> get bus address of single block of memory (rt_heap { sba } ?) to >>>> used for DMA operations. >>> The test with rt_heap was just a test to have a comparison between >>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >>> xnheaps later on. >>> >>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >>>> >>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use >>>> rtdm_mmap to map to user space. Programmatically make memory >>>> consistent before/after DMA transfer to/from external unit, e.g. >>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >>>> similar to what streaming DMA mappings do. >>>> >>>> * Ideally, it should be possible to take memory allocated from >>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >>>> user space using rtdm_mmap(). >>> To check that the non-cacheable mapping is indeed the problem, here is a >>> patch which adds the possibility to add non-cacheable mappings: >>> >>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >>> index 3495e63..ec0ddae 100644 >>> --- a/ksrc/skins/rtdm/drvlib.c >>> +++ b/ksrc/skins/rtdm/drvlib.c >>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); >>> >>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) >>> struct rtdm_mmap_data { >>> + int noncached; >>> void *src_vaddr; >>> phys_addr_t src_paddr; >>> struct vm_operations_struct *vm_ops; >>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >>> struct vm_area_struct *vma) >>> maddr = vma->vm_start; >>> size = vma->vm_end - vma->vm_start; >>> >>> + if (mmap_data->noncached) >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >>> + >>> #ifdef CONFIG_MMU >>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ >>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, >>> void *vm_private_data) >>> { >>> struct rtdm_mmap_data mmap_data = { >>> + .noncached = 0, >>> + .src_vaddr = src_addr, >>> + .src_paddr = 0, >>> + .vm_ops = vm_ops, >>> + .vm_private_data = vm_private_data >>> + }; >>> + >>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >>> +} >>> + >>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >>> + void *src_addr, size_t len, >>> + int prot, void **pptr, >>> + struct vm_operations_struct *vm_ops, >>> + void *vm_private_data) >>> +{ >>> + struct rtdm_mmap_data mmap_data = { >>> + .noncached = 1, >>> .src_vaddr = src_addr, >>> .src_paddr = 0, >>> .vm_ops = vm_ops, >>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, >>> void *vm_private_data) >>> { >>> struct rtdm_mmap_data mmap_data = { >>> + .noncached = 0, >>> .src_vaddr = NULL, >>> .src_paddr = src_addr, >>> .vm_ops = vm_ops, >>> >>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >>> >> >> Get same kernel panic error as before with this patch. I need to look closer >> at what are the memory allocation functions used by pci_ and dma_. > >Could you try rtdm_iomap_to_user (but beware, pass the physical address >returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will >not work with vmalloc/ioremap addresses. And pci_alloc_consistent >probably returns a vmalloc mapping due to the fact that the mapping >needs to be non-cacheable, which will happen if your powerpc does not >support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. > Your suggestion works. Can you highlight why it fails when using rtdm_mmap_to_user()? I am using PPC405 processor which does not support snooping and yes CONFIG_NOT_COHERENT_CACHE is defined. But I still need to make memory consistent (dma_sync_single_*) after each DMA transfer. Thanks, Luis ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 21:57 ` Herrera-Bendezu, Luis @ 2011-01-12 22:11 ` Philippe Gerum 2011-01-12 22:14 ` Gilles Chanteperdrix 2011-01-12 22:15 ` Gilles Chanteperdrix 1 sibling, 1 reply; 27+ messages in thread From: Philippe Gerum @ 2011-01-12 22:11 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai On Wed, 2011-01-12 at 16:57 -0500, Herrera-Bendezu, Luis wrote: > > >-----Original Message----- > >From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >Sent: Wednesday, January 12, 2011 3:37 PM > >To: Herrera-Bendezu, Luis > >Cc: xenomai@xenomai.org > >Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > > > >Herrera-Bendezu, Luis wrote: > >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>> Sent: Wednesday, January 12, 2011 11:26 AM > >>> To: Herrera-Bendezu, Luis > >>> Cc: xenomai@xenomai.org > >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>> > >>> Herrera-Bendezu, Luis wrote: > >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>>>> Sent: Wednesday, January 12, 2011 8:35 AM > >>>>> To: Herrera-Bendezu, Luis > >>>>> Cc: xenomai@xenomai.org > >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>>>> > >>>>> Herrera-Bendezu, Luis wrote: > >>>>>>> -----Original Message----- > >>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM > >>>>>>> To: Herrera-Bendezu, Luis > >>>>>>> Cc: xenomai@xenomai.org > >>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>>>>>> > >>>>>>> Gilles Chanteperdrix wrote: > >>>>>>>> Herrera-Bendezu, Luis wrote: > >>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: > >>>>>>>>>> Steven A. Falco wrote: > >>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: > >>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just > >>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create > >>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. > >>>>>>>>>> > >>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai > >>>>>>>>>> generic code. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> (...) > >>>>>>>> What about the other thing I asked you to test? > >>>>>>>> > >>>>>>> Ping? Any news about this test? > >>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. > >>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. > >>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to > >>>>> use kmalloc/get_free_pages then establish a non-cached mapping in > >>>>> kernel-space with vm_map_ram. > >>>>> > >>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the > >>>>> mapping can not be used for DMA, as it will probably not be physically > >>>>> contiguous, but at least you can try whether accessing in user-space a > >>>>> non-cached mapping works. > >>>> It does work but unless an external unit writes to heap memory it would > >>>> be difficult to verify that the non-cached memory actually works, i.e. > >>>> access from user space gets expected value(s). > >>> I am quite confident this works. > >>> > >>>>> In any case, we see a defect in the RTDM interface here: we can not ask > >>>>> the mapping to be mapped non-cacheable, which somewhat defeats the > >>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc > >>>>> architecture to know whether this could be the cause of your issue (the > >>>>> same physical area mapped twice, once cached, once non-cached). However, > >>>>> on the ARM architecture, for instance, it is bad. > >>>>> > >>>> Let me summarize the ideas discussed so far to allocate consistent memory > >>>> suitable for DMA and corresponding mapping to user space: > >>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is > >>>> automatically mapped to user space with rt_heap_bind(). > >>>> > >>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow > >>>> get bus address of single block of memory (rt_heap { sba } ?) to > >>>> used for DMA operations. > >>> The test with rt_heap was just a test to have a comparison between > >>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable > >>> xnheaps later on. > >>> > >>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. > >>>> > >>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use > >>>> rtdm_mmap to map to user space. Programmatically make memory > >>>> consistent before/after DMA transfer to/from external unit, e.g. > >>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is > >>>> similar to what streaming DMA mappings do. > >>>> > >>>> * Ideally, it should be possible to take memory allocated from > >>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to > >>>> user space using rtdm_mmap(). > >>> To check that the non-cacheable mapping is indeed the problem, here is a > >>> patch which adds the possibility to add non-cacheable mappings: > >>> > >>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > >>> index 3495e63..ec0ddae 100644 > >>> --- a/ksrc/skins/rtdm/drvlib.c > >>> +++ b/ksrc/skins/rtdm/drvlib.c > >>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > >>> > >>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > >>> struct rtdm_mmap_data { > >>> + int noncached; > >>> void *src_vaddr; > >>> phys_addr_t src_paddr; > >>> struct vm_operations_struct *vm_ops; > >>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, > >>> struct vm_area_struct *vma) > >>> maddr = vma->vm_start; > >>> size = vma->vm_end - vma->vm_start; > >>> > >>> + if (mmap_data->noncached) > >>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >>> + > >>> #ifdef CONFIG_MMU > >>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ > >>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { > >>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > >>> void *vm_private_data) > >>> { > >>> struct rtdm_mmap_data mmap_data = { > >>> + .noncached = 0, > >>> + .src_vaddr = src_addr, > >>> + .src_paddr = 0, > >>> + .vm_ops = vm_ops, > >>> + .vm_private_data = vm_private_data > >>> + }; > >>> + > >>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); > >>> +} > >>> + > >>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, > >>> + void *src_addr, size_t len, > >>> + int prot, void **pptr, > >>> + struct vm_operations_struct *vm_ops, > >>> + void *vm_private_data) > >>> +{ > >>> + struct rtdm_mmap_data mmap_data = { > >>> + .noncached = 1, > >>> .src_vaddr = src_addr, > >>> .src_paddr = 0, > >>> .vm_ops = vm_ops, > >>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > >>> void *vm_private_data) > >>> { > >>> struct rtdm_mmap_data mmap_data = { > >>> + .noncached = 0, > >>> .src_vaddr = NULL, > >>> .src_paddr = src_addr, > >>> .vm_ops = vm_ops, > >>> > >>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. > >>> > >> > >> Get same kernel panic error as before with this patch. I need to look closer > >> at what are the memory allocation functions used by pci_ and dma_. > > > >Could you try rtdm_iomap_to_user (but beware, pass the physical address > >returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will > >not work with vmalloc/ioremap addresses. And pci_alloc_consistent > >probably returns a vmalloc mapping due to the fact that the mapping > >needs to be non-cacheable, which will happen if your powerpc does not > >support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. > > > Your suggestion works. Can you highlight why it fails when using > rtdm_mmap_to_user()? Because unlike the former, it does not get the right platform-dependent protection bits for the vma from phys_mem_access_prot() for this kind of memory. > > I am using PPC405 processor which does not support snooping and yes > CONFIG_NOT_COHERENT_CACHE is defined. But I still need to make memory > consistent (dma_sync_single_*) after each DMA transfer. > > Thanks, > Luis > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 22:11 ` Philippe Gerum @ 2011-01-12 22:14 ` Gilles Chanteperdrix 2011-01-12 22:18 ` Gilles Chanteperdrix 2011-01-13 8:27 ` Philippe Gerum 0 siblings, 2 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 22:14 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Philippe Gerum wrote: > On Wed, 2011-01-12 at 16:57 -0500, Herrera-Bendezu, Luis wrote: >>> -----Original Message----- >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>> Sent: Wednesday, January 12, 2011 3:37 PM >>> To: Herrera-Bendezu, Luis >>> Cc: xenomai@xenomai.org >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>> >>> Herrera-Bendezu, Luis wrote: >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>> Sent: Wednesday, January 12, 2011 11:26 AM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai@xenomai.org >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>> Sent: Wednesday, January 12, 2011 8:35 AM >>>>>>> To: Herrera-Bendezu, Luis >>>>>>> Cc: xenomai@xenomai.org >>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>> >>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>>> Cc: xenomai@xenomai.org >>>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>>>> >>>>>>>>> Gilles Chanteperdrix wrote: >>>>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>>>>>> Steven A. Falco wrote: >>>>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>>>>>> >>>>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>>>>>> generic code. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> (...) >>>>>>>>>> What about the other thing I asked you to test? >>>>>>>>>> >>>>>>>>> Ping? Any news about this test? >>>>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>>>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>>>>>> use kmalloc/get_free_pages then establish a non-cached mapping in >>>>>>> kernel-space with vm_map_ram. >>>>>>> >>>>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>>>>>> mapping can not be used for DMA, as it will probably not be physically >>>>>>> contiguous, but at least you can try whether accessing in user-space a >>>>>>> non-cached mapping works. >>>>>> It does work but unless an external unit writes to heap memory it would >>>>>> be difficult to verify that the non-cached memory actually works, i.e. >>>>>> access from user space gets expected value(s). >>>>> I am quite confident this works. >>>>> >>>>>>> In any case, we see a defect in the RTDM interface here: we can not ask >>>>>>> the mapping to be mapped non-cacheable, which somewhat defeats the >>>>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>>>>>> architecture to know whether this could be the cause of your issue (the >>>>>>> same physical area mapped twice, once cached, once non-cached). However, >>>>>>> on the ARM architecture, for instance, it is bad. >>>>>>> >>>>>> Let me summarize the ideas discussed so far to allocate consistent memory >>>>>> suitable for DMA and corresponding mapping to user space: >>>>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >>>>>> automatically mapped to user space with rt_heap_bind(). >>>>>> >>>>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >>>>>> get bus address of single block of memory (rt_heap { sba } ?) to >>>>>> used for DMA operations. >>>>> The test with rt_heap was just a test to have a comparison between >>>>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >>>>> xnheaps later on. >>>>> >>>>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >>>>>> >>>>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use >>>>>> rtdm_mmap to map to user space. Programmatically make memory >>>>>> consistent before/after DMA transfer to/from external unit, e.g. >>>>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >>>>>> similar to what streaming DMA mappings do. >>>>>> >>>>>> * Ideally, it should be possible to take memory allocated from >>>>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >>>>>> user space using rtdm_mmap(). >>>>> To check that the non-cacheable mapping is indeed the problem, here is a >>>>> patch which adds the possibility to add non-cacheable mappings: >>>>> >>>>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >>>>> index 3495e63..ec0ddae 100644 >>>>> --- a/ksrc/skins/rtdm/drvlib.c >>>>> +++ b/ksrc/skins/rtdm/drvlib.c >>>>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); >>>>> >>>>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) >>>>> struct rtdm_mmap_data { >>>>> + int noncached; >>>>> void *src_vaddr; >>>>> phys_addr_t src_paddr; >>>>> struct vm_operations_struct *vm_ops; >>>>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >>>>> struct vm_area_struct *vma) >>>>> maddr = vma->vm_start; >>>>> size = vma->vm_end - vma->vm_start; >>>>> >>>>> + if (mmap_data->noncached) >>>>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >>>>> + >>>>> #ifdef CONFIG_MMU >>>>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ >>>>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >>>>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, >>>>> void *vm_private_data) >>>>> { >>>>> struct rtdm_mmap_data mmap_data = { >>>>> + .noncached = 0, >>>>> + .src_vaddr = src_addr, >>>>> + .src_paddr = 0, >>>>> + .vm_ops = vm_ops, >>>>> + .vm_private_data = vm_private_data >>>>> + }; >>>>> + >>>>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >>>>> +} >>>>> + >>>>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >>>>> + void *src_addr, size_t len, >>>>> + int prot, void **pptr, >>>>> + struct vm_operations_struct *vm_ops, >>>>> + void *vm_private_data) >>>>> +{ >>>>> + struct rtdm_mmap_data mmap_data = { >>>>> + .noncached = 1, >>>>> .src_vaddr = src_addr, >>>>> .src_paddr = 0, >>>>> .vm_ops = vm_ops, >>>>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, >>>>> void *vm_private_data) >>>>> { >>>>> struct rtdm_mmap_data mmap_data = { >>>>> + .noncached = 0, >>>>> .src_vaddr = NULL, >>>>> .src_paddr = src_addr, >>>>> .vm_ops = vm_ops, >>>>> >>>>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >>>>> >>>> Get same kernel panic error as before with this patch. I need to look closer >>>> at what are the memory allocation functions used by pci_ and dma_. >>> Could you try rtdm_iomap_to_user (but beware, pass the physical address >>> returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will >>> not work with vmalloc/ioremap addresses. And pci_alloc_consistent >>> probably returns a vmalloc mapping due to the fact that the mapping >>> needs to be non-cacheable, which will happen if your powerpc does not >>> support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. >>> >> Your suggestion works. Can you highlight why it fails when using >> rtdm_mmap_to_user()? > > Because unlike the former, it does not get the right platform-dependent > protection bits for the vma from phys_mem_access_prot() for this kind of > memory. There is another issue: the memory returned by pci_alloc_consistent should be handled as vmalloc memory, but it is allocated in a separated area, the CONSISTENT_BASE, CONSISTENT_END area. So the test: if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) returns false, and the memory is handled as if it were kmalloced memory. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 22:14 ` Gilles Chanteperdrix @ 2011-01-12 22:18 ` Gilles Chanteperdrix 2011-01-12 22:45 ` Gilles Chanteperdrix 2011-01-13 8:27 ` Philippe Gerum 1 sibling, 1 reply; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 22:18 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> On Wed, 2011-01-12 at 16:57 -0500, Herrera-Bendezu, Luis wrote: >>>> -----Original Message----- >>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>> Sent: Wednesday, January 12, 2011 3:37 PM >>>> To: Herrera-Bendezu, Luis >>>> Cc: xenomai@xenomai.org >>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>> >>>> Herrera-Bendezu, Luis wrote: >>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>> Sent: Wednesday, January 12, 2011 11:26 AM >>>>>> To: Herrera-Bendezu, Luis >>>>>> Cc: xenomai@xenomai.org >>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>> >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>>> Sent: Wednesday, January 12, 2011 8:35 AM >>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>> Cc: xenomai@xenomai.org >>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>>> >>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>>>> Cc: xenomai@xenomai.org >>>>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>>>>> >>>>>>>>>> Gilles Chanteperdrix wrote: >>>>>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>>>>>>> Steven A. Falco wrote: >>>>>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>>>>>>> >>>>>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>>>>>>> generic code. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> (...) >>>>>>>>>>> What about the other thing I asked you to test? >>>>>>>>>>> >>>>>>>>>> Ping? Any news about this test? >>>>>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>>>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>>>>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>>>>>>> use kmalloc/get_free_pages then establish a non-cached mapping in >>>>>>>> kernel-space with vm_map_ram. >>>>>>>> >>>>>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>>>>>>> mapping can not be used for DMA, as it will probably not be physically >>>>>>>> contiguous, but at least you can try whether accessing in user-space a >>>>>>>> non-cached mapping works. >>>>>>> It does work but unless an external unit writes to heap memory it would >>>>>>> be difficult to verify that the non-cached memory actually works, i.e. >>>>>>> access from user space gets expected value(s). >>>>>> I am quite confident this works. >>>>>> >>>>>>>> In any case, we see a defect in the RTDM interface here: we can not ask >>>>>>>> the mapping to be mapped non-cacheable, which somewhat defeats the >>>>>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>>>>>>> architecture to know whether this could be the cause of your issue (the >>>>>>>> same physical area mapped twice, once cached, once non-cached). However, >>>>>>>> on the ARM architecture, for instance, it is bad. >>>>>>>> >>>>>>> Let me summarize the ideas discussed so far to allocate consistent memory >>>>>>> suitable for DMA and corresponding mapping to user space: >>>>>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >>>>>>> automatically mapped to user space with rt_heap_bind(). >>>>>>> >>>>>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >>>>>>> get bus address of single block of memory (rt_heap { sba } ?) to >>>>>>> used for DMA operations. >>>>>> The test with rt_heap was just a test to have a comparison between >>>>>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >>>>>> xnheaps later on. >>>>>> >>>>>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >>>>>>> >>>>>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use >>>>>>> rtdm_mmap to map to user space. Programmatically make memory >>>>>>> consistent before/after DMA transfer to/from external unit, e.g. >>>>>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >>>>>>> similar to what streaming DMA mappings do. >>>>>>> >>>>>>> * Ideally, it should be possible to take memory allocated from >>>>>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >>>>>>> user space using rtdm_mmap(). >>>>>> To check that the non-cacheable mapping is indeed the problem, here is a >>>>>> patch which adds the possibility to add non-cacheable mappings: >>>>>> >>>>>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >>>>>> index 3495e63..ec0ddae 100644 >>>>>> --- a/ksrc/skins/rtdm/drvlib.c >>>>>> +++ b/ksrc/skins/rtdm/drvlib.c >>>>>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); >>>>>> >>>>>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) >>>>>> struct rtdm_mmap_data { >>>>>> + int noncached; >>>>>> void *src_vaddr; >>>>>> phys_addr_t src_paddr; >>>>>> struct vm_operations_struct *vm_ops; >>>>>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >>>>>> struct vm_area_struct *vma) >>>>>> maddr = vma->vm_start; >>>>>> size = vma->vm_end - vma->vm_start; >>>>>> >>>>>> + if (mmap_data->noncached) >>>>>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >>>>>> + >>>>>> #ifdef CONFIG_MMU >>>>>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ >>>>>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >>>>>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, >>>>>> void *vm_private_data) >>>>>> { >>>>>> struct rtdm_mmap_data mmap_data = { >>>>>> + .noncached = 0, >>>>>> + .src_vaddr = src_addr, >>>>>> + .src_paddr = 0, >>>>>> + .vm_ops = vm_ops, >>>>>> + .vm_private_data = vm_private_data >>>>>> + }; >>>>>> + >>>>>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >>>>>> +} >>>>>> + >>>>>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >>>>>> + void *src_addr, size_t len, >>>>>> + int prot, void **pptr, >>>>>> + struct vm_operations_struct *vm_ops, >>>>>> + void *vm_private_data) >>>>>> +{ >>>>>> + struct rtdm_mmap_data mmap_data = { >>>>>> + .noncached = 1, >>>>>> .src_vaddr = src_addr, >>>>>> .src_paddr = 0, >>>>>> .vm_ops = vm_ops, >>>>>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, >>>>>> void *vm_private_data) >>>>>> { >>>>>> struct rtdm_mmap_data mmap_data = { >>>>>> + .noncached = 0, >>>>>> .src_vaddr = NULL, >>>>>> .src_paddr = src_addr, >>>>>> .vm_ops = vm_ops, >>>>>> >>>>>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >>>>>> >>>>> Get same kernel panic error as before with this patch. I need to look closer >>>>> at what are the memory allocation functions used by pci_ and dma_. >>>> Could you try rtdm_iomap_to_user (but beware, pass the physical address >>>> returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will >>>> not work with vmalloc/ioremap addresses. And pci_alloc_consistent >>>> probably returns a vmalloc mapping due to the fact that the mapping >>>> needs to be non-cacheable, which will happen if your powerpc does not >>>> support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. >>>> >>> Your suggestion works. Can you highlight why it fails when using >>> rtdm_mmap_to_user()? >> Because unlike the former, it does not get the right platform-dependent >> protection bits for the vma from phys_mem_access_prot() for this kind of >> memory. > > There is another issue: the memory returned by pci_alloc_consistent > should be handled as vmalloc memory, but it is allocated in a separated > area, the CONSISTENT_BASE, CONSISTENT_END area. So the test: > > if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) > > returns false, and the memory is handled as if it were kmalloced memory. Replacing this test with if (!virt_addr_valid(vaddr)) should do the trick. Remains to see whethe this macro existed in older versions. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 22:18 ` Gilles Chanteperdrix @ 2011-01-12 22:45 ` Gilles Chanteperdrix 0 siblings, 0 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 22:45 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Gilles Chanteperdrix wrote: >> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) >> >> returns false, and the memory is handled as if it were kmalloced memory. > > Replacing this test with if (!virt_addr_valid(vaddr)) should do the > trick. Remains to see whethe this macro existed in older versions. > No, it will not work. vmalloc_to_page will fail for the same reason. So, we can not use rtdm_mmap_to_user with virtual address returned by dma_alloc_coherent, unless we start writing a page walk table like vmalloc_to_page but which does not test that the give address is in the vmalloc range. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 22:14 ` Gilles Chanteperdrix 2011-01-12 22:18 ` Gilles Chanteperdrix @ 2011-01-13 8:27 ` Philippe Gerum 2011-01-13 8:33 ` Gilles Chanteperdrix 1 sibling, 1 reply; 27+ messages in thread From: Philippe Gerum @ 2011-01-13 8:27 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Wed, 2011-01-12 at 23:14 +0100, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Wed, 2011-01-12 at 16:57 -0500, Herrera-Bendezu, Luis wrote: > >>> -----Original Message----- > >>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>> Sent: Wednesday, January 12, 2011 3:37 PM > >>> To: Herrera-Bendezu, Luis > >>> Cc: xenomai@xenomai.org > >>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>> > >>> Herrera-Bendezu, Luis wrote: > >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>>>> Sent: Wednesday, January 12, 2011 11:26 AM > >>>>> To: Herrera-Bendezu, Luis > >>>>> Cc: xenomai@xenomai.org > >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>>>> > >>>>> Herrera-Bendezu, Luis wrote: > >>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>>>>>> Sent: Wednesday, January 12, 2011 8:35 AM > >>>>>>> To: Herrera-Bendezu, Luis > >>>>>>> Cc: xenomai@xenomai.org > >>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>>>>>> > >>>>>>> Herrera-Bendezu, Luis wrote: > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] > >>>>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM > >>>>>>>>> To: Herrera-Bendezu, Luis > >>>>>>>>> Cc: xenomai@xenomai.org > >>>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory > >>>>>>>>> > >>>>>>>>> Gilles Chanteperdrix wrote: > >>>>>>>>>> Herrera-Bendezu, Luis wrote: > >>>>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: > >>>>>>>>>>>> Steven A. Falco wrote: > >>>>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: > >>>>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just > >>>>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create > >>>>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. > >>>>>>>>>>>> > >>>>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai > >>>>>>>>>>>> generic code. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> (...) > >>>>>>>>>> What about the other thing I asked you to test? > >>>>>>>>>> > >>>>>>>>> Ping? Any news about this test? > >>>>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. > >>>>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. > >>>>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to > >>>>>>> use kmalloc/get_free_pages then establish a non-cached mapping in > >>>>>>> kernel-space with vm_map_ram. > >>>>>>> > >>>>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the > >>>>>>> mapping can not be used for DMA, as it will probably not be physically > >>>>>>> contiguous, but at least you can try whether accessing in user-space a > >>>>>>> non-cached mapping works. > >>>>>> It does work but unless an external unit writes to heap memory it would > >>>>>> be difficult to verify that the non-cached memory actually works, i.e. > >>>>>> access from user space gets expected value(s). > >>>>> I am quite confident this works. > >>>>> > >>>>>>> In any case, we see a defect in the RTDM interface here: we can not ask > >>>>>>> the mapping to be mapped non-cacheable, which somewhat defeats the > >>>>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc > >>>>>>> architecture to know whether this could be the cause of your issue (the > >>>>>>> same physical area mapped twice, once cached, once non-cached). However, > >>>>>>> on the ARM architecture, for instance, it is bad. > >>>>>>> > >>>>>> Let me summarize the ideas discussed so far to allocate consistent memory > >>>>>> suitable for DMA and corresponding mapping to user space: > >>>>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is > >>>>>> automatically mapped to user space with rt_heap_bind(). > >>>>>> > >>>>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow > >>>>>> get bus address of single block of memory (rt_heap { sba } ?) to > >>>>>> used for DMA operations. > >>>>> The test with rt_heap was just a test to have a comparison between > >>>>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable > >>>>> xnheaps later on. > >>>>> > >>>>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. > >>>>>> > >>>>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use > >>>>>> rtdm_mmap to map to user space. Programmatically make memory > >>>>>> consistent before/after DMA transfer to/from external unit, e.g. > >>>>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is > >>>>>> similar to what streaming DMA mappings do. > >>>>>> > >>>>>> * Ideally, it should be possible to take memory allocated from > >>>>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to > >>>>>> user space using rtdm_mmap(). > >>>>> To check that the non-cacheable mapping is indeed the problem, here is a > >>>>> patch which adds the possibility to add non-cacheable mappings: > >>>>> > >>>>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > >>>>> index 3495e63..ec0ddae 100644 > >>>>> --- a/ksrc/skins/rtdm/drvlib.c > >>>>> +++ b/ksrc/skins/rtdm/drvlib.c > >>>>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); > >>>>> > >>>>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) > >>>>> struct rtdm_mmap_data { > >>>>> + int noncached; > >>>>> void *src_vaddr; > >>>>> phys_addr_t src_paddr; > >>>>> struct vm_operations_struct *vm_ops; > >>>>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, > >>>>> struct vm_area_struct *vma) > >>>>> maddr = vma->vm_start; > >>>>> size = vma->vm_end - vma->vm_start; > >>>>> > >>>>> + if (mmap_data->noncached) > >>>>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > >>>>> + > >>>>> #ifdef CONFIG_MMU > >>>>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ > >>>>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { > >>>>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, > >>>>> void *vm_private_data) > >>>>> { > >>>>> struct rtdm_mmap_data mmap_data = { > >>>>> + .noncached = 0, > >>>>> + .src_vaddr = src_addr, > >>>>> + .src_paddr = 0, > >>>>> + .vm_ops = vm_ops, > >>>>> + .vm_private_data = vm_private_data > >>>>> + }; > >>>>> + > >>>>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); > >>>>> +} > >>>>> + > >>>>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, > >>>>> + void *src_addr, size_t len, > >>>>> + int prot, void **pptr, > >>>>> + struct vm_operations_struct *vm_ops, > >>>>> + void *vm_private_data) > >>>>> +{ > >>>>> + struct rtdm_mmap_data mmap_data = { > >>>>> + .noncached = 1, > >>>>> .src_vaddr = src_addr, > >>>>> .src_paddr = 0, > >>>>> .vm_ops = vm_ops, > >>>>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, > >>>>> void *vm_private_data) > >>>>> { > >>>>> struct rtdm_mmap_data mmap_data = { > >>>>> + .noncached = 0, > >>>>> .src_vaddr = NULL, > >>>>> .src_paddr = src_addr, > >>>>> .vm_ops = vm_ops, > >>>>> > >>>>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. > >>>>> > >>>> Get same kernel panic error as before with this patch. I need to look closer > >>>> at what are the memory allocation functions used by pci_ and dma_. > >>> Could you try rtdm_iomap_to_user (but beware, pass the physical address > >>> returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will > >>> not work with vmalloc/ioremap addresses. And pci_alloc_consistent > >>> probably returns a vmalloc mapping due to the fact that the mapping > >>> needs to be non-cacheable, which will happen if your powerpc does not > >>> support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. > >>> > >> Your suggestion works. Can you highlight why it fails when using > >> rtdm_mmap_to_user()? > > > > Because unlike the former, it does not get the right platform-dependent > > protection bits for the vma from phys_mem_access_prot() for this kind of > > memory. > > There is another issue: the memory returned by pci_alloc_consistent > should be handled as vmalloc memory, but it is allocated in a separated > area, the CONSISTENT_BASE, CONSISTENT_END area. So the test: > > if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) > > returns false, and the memory is handled as if it were kmalloced memory. > This is the reason why calling rtdm_mmap_to_user for mapping coherent memory is not appropriate in the first place, because as the doc states, it is for mapping kernel memory pages, but DMA/PCI coherent memory may have platform-dependent specifics which make it a different kind of beast. Perhaps the documentation should stress this aspect, so that rtdm_iomap_to_user() is considered instead. -- Philippe. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-13 8:27 ` Philippe Gerum @ 2011-01-13 8:33 ` Gilles Chanteperdrix 0 siblings, 0 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-13 8:33 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Philippe Gerum wrote: > On Wed, 2011-01-12 at 23:14 +0100, Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >>> On Wed, 2011-01-12 at 16:57 -0500, Herrera-Bendezu, Luis wrote: >>>>> -----Original Message----- >>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>> Sent: Wednesday, January 12, 2011 3:37 PM >>>>> To: Herrera-Bendezu, Luis >>>>> Cc: xenomai@xenomai.org >>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>> Sent: Wednesday, January 12, 2011 11:26 AM >>>>>>> To: Herrera-Bendezu, Luis >>>>>>> Cc: xenomai@xenomai.org >>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>> >>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>>>> Sent: Wednesday, January 12, 2011 8:35 AM >>>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>>> Cc: xenomai@xenomai.org >>>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>>>> >>>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] >>>>>>>>>>> Sent: Tuesday, January 11, 2011 6:28 PM >>>>>>>>>>> To: Herrera-Bendezu, Luis >>>>>>>>>>> Cc: xenomai@xenomai.org >>>>>>>>>>> Subject: Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory >>>>>>>>>>> >>>>>>>>>>> Gilles Chanteperdrix wrote: >>>>>>>>>>>> Herrera-Bendezu, Luis wrote: >>>>>>>>>>>>> On 01/05/2011 5:29 PM Gilles Chanteperdrix wrote: >>>>>>>>>>>>>> Steven A. Falco wrote: >>>>>>>>>>>>>>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>>>>>>>>>>>> Ok. Could you try to do the same operation with the native API? You just >>>>>>>>>>>>>> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >>>>>>>>>>>>>> to get the same effect as pci_dma_alloc_coherent. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just to see if the error lies in RTDM implementation or in Xenomai >>>>>>>>>>>>>> generic code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> (...) >>>>>>>>>>>> What about the other thing I asked you to test? >>>>>>>>>>>> >>>>>>>>>>> Ping? Any news about this test? >>>>>>>>>> rt_heap_create() with flags H_SHARED | H_DMA | H_NONCACHED report -EINVAL. >>>>>>>>>> Documentation indicates that H_NONCACHE is not compatible with H_DMA. >>>>>>>>> Right, supporting H_NONCACHED | H_DMA would mean that we would have to >>>>>>>>> use kmalloc/get_free_pages then establish a non-cached mapping in >>>>>>>>> kernel-space with vm_map_ram. >>>>>>>>> >>>>>>>>> Could you try with H_NONCACHED, but without H_DMA? Of course, the >>>>>>>>> mapping can not be used for DMA, as it will probably not be physically >>>>>>>>> contiguous, but at least you can try whether accessing in user-space a >>>>>>>>> non-cached mapping works. >>>>>>>> It does work but unless an external unit writes to heap memory it would >>>>>>>> be difficult to verify that the non-cached memory actually works, i.e. >>>>>>>> access from user space gets expected value(s). >>>>>>> I am quite confident this works. >>>>>>> >>>>>>>>> In any case, we see a defect in the RTDM interface here: we can not ask >>>>>>>>> the mapping to be mapped non-cacheable, which somewhat defeats the >>>>>>>>> purpose of pci_alloc_consistent. I do not know enough the powerpc >>>>>>>>> architecture to know whether this could be the cause of your issue (the >>>>>>>>> same physical area mapped twice, once cached, once non-cached). However, >>>>>>>>> on the ARM architecture, for instance, it is bad. >>>>>>>>> >>>>>>>> Let me summarize the ideas discussed so far to allocate consistent memory >>>>>>>> suitable for DMA and corresponding mapping to user space: >>>>>>>> * rt_heap cannot be created with both H_NONCACHED and H_DMA. But it is >>>>>>>> automatically mapped to user space with rt_heap_bind(). >>>>>>>> >>>>>>>> A solution can be to allocate heap with H_SHARED | H_DMA, somehow >>>>>>>> get bus address of single block of memory (rt_heap { sba } ?) to >>>>>>>> used for DMA operations. >>>>>>> The test with rt_heap was just a test to have a comparison between >>>>>>> xnheap code and rtdm_mmap. But we may indeed want to fix mmappable >>>>>>> xnheaps later on. >>>>>>> >>>>>>>> * RTDM interface rtdm_mmap/unmap cannot handle non-cacheable memory. >>>>>>>> >>>>>>>> A solution can be to allocate GFP_DMA memory with kmalloc(), use >>>>>>>> rtdm_mmap to map to user space. Programmatically make memory >>>>>>>> consistent before/after DMA transfer to/from external unit, e.g. >>>>>>>> dma_sync_single_for_device()/dma_sync_single_for_cpu(). This is >>>>>>>> similar to what streaming DMA mappings do. >>>>>>>> >>>>>>>> * Ideally, it should be possible to take memory allocated from >>>>>>>> dma_alloc_coherent()/pci_alloc_consistent() and mapped it to >>>>>>>> user space using rtdm_mmap(). >>>>>>> To check that the non-cacheable mapping is indeed the problem, here is a >>>>>>> patch which adds the possibility to add non-cacheable mappings: >>>>>>> >>>>>>> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >>>>>>> index 3495e63..ec0ddae 100644 >>>>>>> --- a/ksrc/skins/rtdm/drvlib.c >>>>>>> +++ b/ksrc/skins/rtdm/drvlib.c >>>>>>> @@ -1791,6 +1791,7 @@ void rtdm_nrtsig_pend(rtdm_nrtsig_t *nrt_sig); >>>>>>> >>>>>>> #if defined(CONFIG_XENO_OPT_PERVASIVE) || defined(DOXYGEN_CPP) >>>>>>> struct rtdm_mmap_data { >>>>>>> + int noncached; >>>>>>> void *src_vaddr; >>>>>>> phys_addr_t src_paddr; >>>>>>> struct vm_operations_struct *vm_ops; >>>>>>> @@ -1815,6 +1816,9 @@ static int rtdm_mmap_buffer(struct file *filp, >>>>>>> struct vm_area_struct *vma) >>>>>>> maddr = vma->vm_start; >>>>>>> size = vma->vm_end - vma->vm_start; >>>>>>> >>>>>>> + if (mmap_data->noncached) >>>>>>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); >>>>>>> + >>>>>>> #ifdef CONFIG_MMU >>>>>>> /* Catch vmalloc memory (vaddr is 0 for I/O mapping) */ >>>>>>> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) { >>>>>>> @@ -1975,6 +1979,24 @@ int rtdm_mmap_to_user(rtdm_user_info_t *user_info, >>>>>>> void *vm_private_data) >>>>>>> { >>>>>>> struct rtdm_mmap_data mmap_data = { >>>>>>> + .noncached = 0, >>>>>>> + .src_vaddr = src_addr, >>>>>>> + .src_paddr = 0, >>>>>>> + .vm_ops = vm_ops, >>>>>>> + .vm_private_data = vm_private_data >>>>>>> + }; >>>>>>> + >>>>>>> + return rtdm_do_mmap(user_info, &mmap_data, len, prot, pptr); >>>>>>> +} >>>>>>> + >>>>>>> +int rtdm_mmap_noncached_to_user(rtdm_user_info_t *user_info, >>>>>>> + void *src_addr, size_t len, >>>>>>> + int prot, void **pptr, >>>>>>> + struct vm_operations_struct *vm_ops, >>>>>>> + void *vm_private_data) >>>>>>> +{ >>>>>>> + struct rtdm_mmap_data mmap_data = { >>>>>>> + .noncached = 1, >>>>>>> .src_vaddr = src_addr, >>>>>>> .src_paddr = 0, >>>>>>> .vm_ops = vm_ops, >>>>>>> @@ -2043,6 +2065,7 @@ int rtdm_iomap_to_user(rtdm_user_info_t *user_info, >>>>>>> void *vm_private_data) >>>>>>> { >>>>>>> struct rtdm_mmap_data mmap_data = { >>>>>>> + .noncached = 0, >>>>>>> .src_vaddr = NULL, >>>>>>> .src_paddr = src_addr, >>>>>>> .vm_ops = vm_ops, >>>>>>> >>>>>>> Simply call rtdm_mmap_noncached_to_user instead of rtdm_mmap_to_user. >>>>>>> >>>>>> Get same kernel panic error as before with this patch. I need to look closer >>>>>> at what are the memory allocation functions used by pci_ and dma_. >>>>> Could you try rtdm_iomap_to_user (but beware, pass the physical address >>>>> returned by pointer by pci_alloc_consistent)? virt_to_page, or __pa will >>>>> not work with vmalloc/ioremap addresses. And pci_alloc_consistent >>>>> probably returns a vmalloc mapping due to the fact that the mapping >>>>> needs to be non-cacheable, which will happen if your powerpc does not >>>>> support cache snooping, and define CONFIG_NOT_COHERENT_CACHE. >>>>> >>>> Your suggestion works. Can you highlight why it fails when using >>>> rtdm_mmap_to_user()? >>> Because unlike the former, it does not get the right platform-dependent >>> protection bits for the vma from phys_mem_access_prot() for this kind of >>> memory. >> There is another issue: the memory returned by pci_alloc_consistent >> should be handled as vmalloc memory, but it is allocated in a separated >> area, the CONSISTENT_BASE, CONSISTENT_END area. So the test: >> >> if ((vaddr >= VMALLOC_START) && (vaddr < VMALLOC_END)) >> >> returns false, and the memory is handled as if it were kmalloced memory. >> > > This is the reason why calling rtdm_mmap_to_user for mapping coherent > memory is not appropriate in the first place, because as the doc states, > it is for mapping kernel memory pages, but DMA/PCI coherent memory may > have platform-dependent specifics which make it a different kind of > beast. Perhaps the documentation should stress this aspect, so that > rtdm_iomap_to_user() is considered instead. Yes, OK, I was trying to find a way to get rtdm_mmap_to_user working in that case. But that is kind of useless, since rtdm_iomap_to_user is working anyway. We still have the issue with noncacheable mappings with RTDM though, does adding two new services: rtdm_mmap_noncacheable_to_user() and rtdm_iomap_noncacheable_to_user() look reasonable, or is there a better alternative? > -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-12 21:57 ` Herrera-Bendezu, Luis 2011-01-12 22:11 ` Philippe Gerum @ 2011-01-12 22:15 ` Gilles Chanteperdrix 1 sibling, 0 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-12 22:15 UTC (permalink / raw) To: Herrera-Bendezu, Luis; +Cc: xenomai Herrera-Bendezu, Luis wrote: > > I am using PPC405 processor which does not support snooping and yes > CONFIG_NOT_COHERENT_CACHE is defined. But I still need to make memory > consistent (dma_sync_single_*) after each DMA transfer. That is because the memory is mapped cacheable in user-space. You need the path which sets the vma protection to non-cacheable, but add an rtdm_iomap_noncacheable_to_user function. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-05 22:29 ` Gilles Chanteperdrix 2011-01-06 13:48 ` Herrera-Bendezu, Luis @ 2011-01-06 14:32 ` Steven A. Falco 2011-01-06 14:44 ` Gilles Chanteperdrix 2011-01-06 14:45 ` Steven A. Falco 1 sibling, 2 replies; 27+ messages in thread From: Steven A. Falco @ 2011-01-06 14:32 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On 01/05/2011 05:29 PM, Gilles Chanteperdrix wrote: > Steven A. Falco wrote: >> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>> Herrera-Bendezu, Luis wrote: >>>> Gilles: >>>> >>>>> Herrera-Bendezu, Luis wrote: >>>>>> Hello: >>>>>> >>>>>> I have the following setup: >>>>>> PPC405EX >>>>>> Linux 2.6.30.3 >>>>>> Xenomai 2.4.10 >>>>>> I-pipe 2.7-02 >>>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>>> Configuration file is attached >>>>> Do you have the same issue with the latest version of the I-pipe patch >>>>> for this same version of the Linux kernel? It should be 2.8-00. >>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >>> Sorry, I misread the ftp list, I was rather thinking about: >>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch >>> >>> >>> It resulted on same problem >>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>>> >>>> Was there any particular set of changes that you expected it could fix the >>>> problem? Do you think more recent versions may work? If yes, which version >>>> could be tried? >>> Yes, there was a fix, specifially in the powerpc tree, with mappings >>> issue. But I think it is older than 2.6.32. >>> >>> Now that I look at your message again, your problem seems more likely to >>> be in your code. Specifically, you say: "bus address returned by >>> pci_alloc_consistent()". I do not think pci_alloc_consistent return >>> value is a bus address. The dma_handle returned by pointer probably is. >>> But I am not sure you are supposed to know this. >> >> pci_alloc_consistent() returns two values. The kernel address is >> returned directly (as a void *), and the bus address is returned >> through the dma_handle pointer (third function argument). >> >> Luis' original email indicated that he tried rtdm_mmap_to_user() >> on the kernel address, and he tried rtdm_iomap_to_user() on the >> bus address. Either way caused the crash he reported. > > Ok. Could you try to do the same operation with the native API? You just > have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create > to get the same effect as pci_dma_alloc_coherent. > > Just to see if the error lies in RTDM implementation or in Xenomai > generic code. > > >> >> We have a home-grown program (mm) that basically opens /dev/mem >> and allows peek/poke. Using that with the bus address works to >> access the memory. We also pass that address to our hardware, >> and it correctly DMAs the data. So we believe the bus address >> is correct. > > You mean much like devmem2? Now even part of the busybox? I had not known about devmem2 when I wrote my "mm" program; "mm" turns out to be very similar to devmem2. One difference is that I use mmap64() rather than mmap(), because the PowerPC440EPx uses 36-bit addresses even though it has a 32-bit instruction set. Other than that, the two programs are remarkably similar. Steve > >> >> I believe Luis has also tried a third approach - allocating with >> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the >> resulting pointer. That works, but getting the bus address is >> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. >> >> So there is something different about the way pci_alloc_consistent() >> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) >> works with rtdm_mmap_to_user() but pci_alloc_consistent() does >> not. > > This gives me an idea. Could you try the following patch? Even before > trying the native API. > > diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > index 3495e63..d7dd3db 100644 > --- a/ksrc/skins/rtdm/drvlib.c > +++ b/ksrc/skins/rtdm/drvlib.c > @@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) > vaddr = (unsigned long)mmap_data->src_vaddr; > paddr = mmap_data->src_paddr; > if (paddr == 0) /* kmalloc memory? */ > - paddr = __pa(vaddr); > + paddr = page_to_phys(virt_to_page(vaddr)); > > maddr = vma->vm_start; > size = vma->vm_end - vma->vm_start; > > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-06 14:32 ` Steven A. Falco @ 2011-01-06 14:44 ` Gilles Chanteperdrix 2011-01-06 14:45 ` Steven A. Falco 1 sibling, 0 replies; 27+ messages in thread From: Gilles Chanteperdrix @ 2011-01-06 14:44 UTC (permalink / raw) To: Steven A. Falco; +Cc: xenomai Steven A. Falco wrote: > On 01/05/2011 05:29 PM, Gilles Chanteperdrix wrote: >> Steven A. Falco wrote: >>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>> Herrera-Bendezu, Luis wrote: >>>>> Gilles: >>>>> >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>> Hello: >>>>>>> >>>>>>> I have the following setup: >>>>>>> PPC405EX >>>>>>> Linux 2.6.30.3 >>>>>>> Xenomai 2.4.10 >>>>>>> I-pipe 2.7-02 >>>>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>>>> Configuration file is attached >>>>>> Do you have the same issue with the latest version of the I-pipe patch >>>>>> for this same version of the Linux kernel? It should be 2.8-00. >>>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >>>> Sorry, I misread the ftp list, I was rather thinking about: >>>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch >>>> >>>> >>>> It resulted on same problem >>>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>>>> >>>>> Was there any particular set of changes that you expected it could fix the >>>>> problem? Do you think more recent versions may work? If yes, which version >>>>> could be tried? >>>> Yes, there was a fix, specifially in the powerpc tree, with mappings >>>> issue. But I think it is older than 2.6.32. >>>> >>>> Now that I look at your message again, your problem seems more likely to >>>> be in your code. Specifically, you say: "bus address returned by >>>> pci_alloc_consistent()". I do not think pci_alloc_consistent return >>>> value is a bus address. The dma_handle returned by pointer probably is. >>>> But I am not sure you are supposed to know this. >>> pci_alloc_consistent() returns two values. The kernel address is >>> returned directly (as a void *), and the bus address is returned >>> through the dma_handle pointer (third function argument). >>> >>> Luis' original email indicated that he tried rtdm_mmap_to_user() >>> on the kernel address, and he tried rtdm_iomap_to_user() on the >>> bus address. Either way caused the crash he reported. >> Ok. Could you try to do the same operation with the native API? You just >> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >> to get the same effect as pci_dma_alloc_coherent. >> >> Just to see if the error lies in RTDM implementation or in Xenomai >> generic code. >> >> >>> We have a home-grown program (mm) that basically opens /dev/mem >>> and allows peek/poke. Using that with the bus address works to >>> access the memory. We also pass that address to our hardware, >>> and it correctly DMAs the data. So we believe the bus address >>> is correct. >> You mean much like devmem2? Now even part of the busybox? > > I had not known about devmem2 when I wrote my "mm" program; "mm" > turns out to be very similar to devmem2. > > One difference is that I use mmap64() rather than mmap(), because > the PowerPC440EPx uses 36-bit addresses even though it has a 32-bit > instruction set. Other than that, the two programs are remarkably > similar. Ahah. This may be another reason for failure. Is "void *" a 64 bits pointer when compiling kernel in this case? Or are there some typedefs to handle these extended pointers? In other words, does rtdm_mmap_to_user work on this architecture (ISTR RTDM had some fixes for this case, but I no longer recall if this included rtdm_mmap_to_user). But if you compile devmem2 with LFS options, it will use 64 bits mmap too. -D_FILE_OFFSET_BITS=64 does the trick I think. -- Gilles. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xenomai-help] [Xenomai -help] User space access to DMA memory 2011-01-06 14:32 ` Steven A. Falco 2011-01-06 14:44 ` Gilles Chanteperdrix @ 2011-01-06 14:45 ` Steven A. Falco 1 sibling, 0 replies; 27+ messages in thread From: Steven A. Falco @ 2011-01-06 14:45 UTC (permalink / raw) To: Steven A. Falco; +Cc: xenomai On 01/06/2011 09:32 AM, Steven A. Falco wrote: > On 01/05/2011 05:29 PM, Gilles Chanteperdrix wrote: >> Steven A. Falco wrote: >>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote: >>>> Herrera-Bendezu, Luis wrote: >>>>> Gilles: >>>>> >>>>>> Herrera-Bendezu, Luis wrote: >>>>>>> Hello: >>>>>>> >>>>>>> I have the following setup: >>>>>>> PPC405EX >>>>>>> Linux 2.6.30.3 >>>>>>> Xenomai 2.4.10 >>>>>>> I-pipe 2.7-02 >>>>>>> ppc_4xx-gcc (GCC) 4.2.2 >>>>>>> Configuration file is attached >>>>>> Do you have the same issue with the latest version of the I-pipe patch >>>>>> for this same version of the Linux kernel? It should be 2.8-00. >>>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32. >>>> Sorry, I misread the ftp list, I was rather thinking about: >>>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch >>>> >>>> >>>> It resulted on same problem >>>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02. >>>>> >>>>> Was there any particular set of changes that you expected it could fix the >>>>> problem? Do you think more recent versions may work? If yes, which version >>>>> could be tried? >>>> Yes, there was a fix, specifially in the powerpc tree, with mappings >>>> issue. But I think it is older than 2.6.32. >>>> >>>> Now that I look at your message again, your problem seems more likely to >>>> be in your code. Specifically, you say: "bus address returned by >>>> pci_alloc_consistent()". I do not think pci_alloc_consistent return >>>> value is a bus address. The dma_handle returned by pointer probably is. >>>> But I am not sure you are supposed to know this. >>> >>> pci_alloc_consistent() returns two values. The kernel address is >>> returned directly (as a void *), and the bus address is returned >>> through the dma_handle pointer (third function argument). >>> >>> Luis' original email indicated that he tried rtdm_mmap_to_user() >>> on the kernel address, and he tried rtdm_iomap_to_user() on the >>> bus address. Either way caused the crash he reported. >> >> Ok. Could you try to do the same operation with the native API? You just >> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create >> to get the same effect as pci_dma_alloc_coherent. >> >> Just to see if the error lies in RTDM implementation or in Xenomai >> generic code. >> >> >>> >>> We have a home-grown program (mm) that basically opens /dev/mem >>> and allows peek/poke. Using that with the bus address works to >>> access the memory. We also pass that address to our hardware, >>> and it correctly DMAs the data. So we believe the bus address >>> is correct. >> >> You mean much like devmem2? Now even part of the busybox? > > I had not known about devmem2 when I wrote my "mm" program; "mm" > turns out to be very similar to devmem2. > > One difference is that I use mmap64() rather than mmap(), because > the PowerPC440EPx uses 36-bit addresses even though it has a 32-bit > instruction set. Other than that, the two programs are remarkably > similar. I should have mentioned that while the "mm" tool is 64-bit capable, the CPU Luis is currently running on is a PowerPC _405EX_, which uses conventional 32-bit addressing. Hence, devmem2 should be fully interchangeable with mm for testing purposes. And any software bugs would not have anything to do with the wider address space of the PPC440EPx. I didn't want people to go down the wrong path. :-) Steve > > Steve > >> >>> >>> I believe Luis has also tried a third approach - allocating with >>> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the >>> resulting pointer. That works, but getting the bus address is >>> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer. >>> >>> So there is something different about the way pci_alloc_consistent() >>> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA) >>> works with rtdm_mmap_to_user() but pci_alloc_consistent() does >>> not. >> >> This gives me an idea. Could you try the following patch? Even before >> trying the native API. >> >> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c >> index 3495e63..d7dd3db 100644 >> --- a/ksrc/skins/rtdm/drvlib.c >> +++ b/ksrc/skins/rtdm/drvlib.c >> @@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct vm_area_struct *vma) >> vaddr = (unsigned long)mmap_data->src_vaddr; >> paddr = mmap_data->src_paddr; >> if (paddr == 0) /* kmalloc memory? */ >> - paddr = __pa(vaddr); >> + paddr = page_to_phys(virt_to_page(vaddr)); >> >> maddr = vma->vm_start; >> size = vma->vm_end - vma->vm_start; >> >> > > -- A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-01-13 8:33 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-20 16:52 [Xenomai-help] [Xenomai -help] User space access to DMA memory Herrera-Bendezu, Luis 2011-01-01 22:44 ` Gilles Chanteperdrix 2011-01-05 21:03 ` Herrera-Bendezu, Luis 2011-01-05 21:33 ` Gilles Chanteperdrix 2011-01-05 22:07 ` Steven A. Falco 2011-01-05 22:29 ` Gilles Chanteperdrix 2011-01-06 13:48 ` Herrera-Bendezu, Luis 2011-01-06 13:55 ` Gilles Chanteperdrix 2011-01-11 23:27 ` Gilles Chanteperdrix 2011-01-12 13:14 ` Herrera-Bendezu, Luis 2011-01-12 13:35 ` Gilles Chanteperdrix 2011-01-12 16:03 ` Herrera-Bendezu, Luis 2011-01-12 16:26 ` Gilles Chanteperdrix 2011-01-12 18:16 ` Herrera-Bendezu, Luis 2011-01-12 20:20 ` Gilles Chanteperdrix 2011-01-12 20:36 ` Gilles Chanteperdrix 2011-01-12 21:57 ` Herrera-Bendezu, Luis 2011-01-12 22:11 ` Philippe Gerum 2011-01-12 22:14 ` Gilles Chanteperdrix 2011-01-12 22:18 ` Gilles Chanteperdrix 2011-01-12 22:45 ` Gilles Chanteperdrix 2011-01-13 8:27 ` Philippe Gerum 2011-01-13 8:33 ` Gilles Chanteperdrix 2011-01-12 22:15 ` Gilles Chanteperdrix 2011-01-06 14:32 ` Steven A. Falco 2011-01-06 14:44 ` Gilles Chanteperdrix 2011-01-06 14:45 ` Steven A. Falco
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.