- 22 Oct, 2010 40 commits
-
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Start unifying the PPI/EPPI peripheral structures in one place. This may be used by camera/video/fpga/high speed devices. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Also document the mailbox (channel) data array layout. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
This matches all the other Blackfin ports and keep us from having to write bf561-specific code in many places. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Now that the common 8250 serial driver supports an "irqflags" field, we don't need to patch in a custom define into the code. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Different arches use different names, so make sure we define both so common code (like MTD_XIP) "just works". Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Mainline version of git merged support for Blackfin parts, but we now need to propagate the gcc arch define to make it work. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
We have to use ioctl numbers that don't collide with common code. Otherwise, these ones never even get called because the common fs code swalled all invocations. Reported-by: Kay Duenzer <kduenzer@maku.eu> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Bob Liu authored
This board has a SSM2603 codec, so make sure we have the right resources declared for it. Signed-off-by: Bob Liu <lliubbo@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Bob Liu authored
The RX/TX address is always the same regardless of the size of the access. That means there is no dedicated "16bit" or "32bit" MMR. Trying to use these currently leads to compile errors. So change everything to use the right MMR define. Signed-off-by: Bob Liu <lliubbo@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Ashish Gupta authored
Signed-off-by: Ashish Gupta <asg@thelearninglabs.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Since these boards can boot out of NAND, make sure we give u-boot its own partition by default to avoid clobbering it. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Sonic Zhang authored
If the kernel's init section is merged back into the main memory region during boot (which it should since that is how we've laid out the kernel linker map), we want to make sure that these aren't counted as independent regions. Otherwise, if a large mapping is attempted which starts in the init region and extends into the main memory region, the access_ok func will deny it. This leads to weird messages during runtime like "unable to map xxx library" from the ldso but upon running the application again, everything works fine. So if the address of the end of the init region is the same as the start of the main memory region, simply enlarge the memory region to include the init region. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
steven miao authored
Many Blackfin parts group sets of pins into a single functional unit. This means you cannot use different pins within a group for different peripherals. Our resource conflict checking thus far has been limited to individual pins, so if someone tried to grab a different pin from the same group, it would be allowed while silently changing the other pins in the same group. One common example is the pin set PG12 - PG15 on BF51x parts. They may either be used with SPI0 (1st function), or they may be used with PTP/PWM/AMS3 (3rd function). Ideally, we'd like to use PG12 - PG14 for SPI0 while using PG15 with AMS3, but the hardware does not permit this. In the past, the software would allow the pins to be requested this way, but ultimately things like the Blackfin SPI driver would stop working when the hardware rerouted to a different peripheral. Signed-off-by: steven miao <realmz6@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Reported-by: D Binderman <dcb314@hotmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Sonic Zhang authored
Flushing caches sometimes requires anomaly workarounds which require supervisor-only insns. Normally we don't need to flush caches from userspace so this isn't a problem, but when gcc generates trampolines on the stack, we do. So add a new syscall for gcc to use modeled after the mips version. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
The BF54x processor has a ton of on-chip peripherals and in order to support them all, the u-boot image is quite large. So give it 512KiB in all bootable flashes to make our lives easier. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
steven miao authored
Signed-off-by: steven miao <realmz6@gmail.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Michael Hennerich authored
Make sure we include EMAC_SYSTAT when showing errors. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Sonic Zhang authored
The predefined i2c address 0x2c doesn't match the configuration of the ad5280 PINs AD0 and AD1 on the tftlcd add-on board. Both AD0 and AD1 are of voltage 3.3V, which means the i2c address should be 0x2F. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Robin Getz authored
Nothing actually needs to use these MMRs (as direct cache manipulation is done with the DTEST MMRs), so simply hide the read funcs behind the anomaly define. They're generally unusable anyways when this anomaly is in effect. Signed-off-by: Robin Getz <robin.getz@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
Rather than use raw numbers for the GPIO pins, use proper GPIO defines. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
When apps run with their stack in L1, some system calls might be made where a buffer is in the stack as an argument. So make sure the core Blackfin access code does not reject this memory location. Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
This board has an AD1836 codec, so make sure we have the right resources declared for it. Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
If an app is placing its stack in L1 scratchpad SRAM, make sure ptrace is granted access to it so that gdb can do its thing. Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Mike Frysinger authored
The num_chipselect field for on-chip Blackfin SPI buses is supposed to be 1 larger than the number of actual CSs available. This is because the hardware starts counting at 1 and not 0. There is a field for "CS0", but it is marked as "reserved" everywhere. Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Michael Hennerich authored
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Sonic Zhang authored
We don't need our own header and structure to hook up the ad5398 part, so drop the custom resources for it. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Sonic Zhang authored
Rather than write our own ADP switch driver, use the existing fixed regulator driver and rewrite the platform resources accordingly. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Michael Hennerich authored
Some peripherals might generate an error interrupt shortly after the data interrupt due to the fact that the peripheral isn't serviced fast enough. In most cases this isn't a problem and is expected behavior. This hasn't been a problem on most parts since you simply don't request the error interrupt (or you leave it disabled while there is an expected state) and do the peripheral status checking in the data interrupt. The Blackfin SIC allows people to prioritize data and error interrupts, and the Blackfin CEC allows interrupts of equal or higher priority to nest. The current default settings gives error interrupts a higher priority than data interrupts. So if an error occurs while processing the data interrupt, it will be serviced immediately. However, the error interrupt on the BF537 SIC cannot be enabled on a per-peripheral basis. Once the error interrupt is enabled for one peripheral, it is automatically enabled for all peripherals. Therefore lower the default multiplexed error interrupt priority so most people need not worry themselves with this issue. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Michael Hennerich authored
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Cliff Cai authored
Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Yi Li authored
Signed-off-by: Yi Li <yi.li@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-
Barry Song authored
Signed-off-by: Barry Song <barry.song@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
-