lisa/android_kernel_xiaomi_sm8350
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
b9da3b9240
android_kernel_xiaomi_sm8350/arch/powerpc/include/asm/dcr-mmio.h

62 lines
1.8 KiB
C
Raw Normal View History

[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
/*
* (c) Copyright 2006 Benjamin Herrenschmidt, IBM Corp.
* <benh@kernel.crashing.org>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
* the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#ifndef _ASM_POWERPC_DCR_MMIO_H
#define _ASM_POWERPC_DCR_MMIO_H
#ifdef __KERNEL__
#include <asm/io.h>
[POWERPC] Store the base address in dcr_host_t In its current form, dcr_map() doesn't remember the base address you passed it, which means you need to store it somewhere else. Rather than adding the base to another struct it seems simpler to store it in the dcr_host_t. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-17 02:05:00 -04:00
typedef struct {
void __iomem *token;
unsigned int stride;
unsigned int base;
[POWERPC] Refactor DCR code Previously, DCR support was configured at compile time to either use MMIO or native dcr instructions. Although this works for most platforms, it fails on FPGA platforms: 1) Systems may include more than one DCR bus. 2) Systems may be native DCR capable and still use memory mapped DCR interface. This patch provides runtime support based on the device trees for the case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both selected. Previously, this was a poorly defined configuration, which happened to provide NATIVE support. The runtime selection is made based on the dcr-controller having a 'dcr-access-method' attribute in the device tree. If only one of the above options is selected, then the code uses #defines to select only the used code in order to avoid introducing overhead in existing usage. Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-05-06 14:29:17 -04:00
} dcr_host_mmio_t;
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
[POWERPC] Refactor DCR code Previously, DCR support was configured at compile time to either use MMIO or native dcr instructions. Although this works for most platforms, it fails on FPGA platforms: 1) Systems may include more than one DCR bus. 2) Systems may be native DCR capable and still use memory mapped DCR interface. This patch provides runtime support based on the device trees for the case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both selected. Previously, this was a poorly defined configuration, which happened to provide NATIVE support. The runtime selection is made based on the dcr-controller having a 'dcr-access-method' attribute in the device tree. If only one of the above options is selected, then the code uses #defines to select only the used code in order to avoid introducing overhead in existing usage. Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-05-06 14:29:17 -04:00
static inline bool dcr_map_ok_mmio(dcr_host_mmio_t host)
{
return host.token != NULL;
}
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
[POWERPC] Refactor DCR code Previously, DCR support was configured at compile time to either use MMIO or native dcr instructions. Although this works for most platforms, it fails on FPGA platforms: 1) Systems may include more than one DCR bus. 2) Systems may be native DCR capable and still use memory mapped DCR interface. This patch provides runtime support based on the device trees for the case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both selected. Previously, this was a poorly defined configuration, which happened to provide NATIVE support. The runtime selection is made based on the dcr-controller having a 'dcr-access-method' attribute in the device tree. If only one of the above options is selected, then the code uses #defines to select only the used code in order to avoid introducing overhead in existing usage. Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-05-06 14:29:17 -04:00
extern dcr_host_mmio_t dcr_map_mmio(struct device_node *dev,
unsigned int dcr_n,
unsigned int dcr_c);
extern void dcr_unmap_mmio(dcr_host_mmio_t host, unsigned int dcr_c);
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
[POWERPC] Refactor DCR code Previously, DCR support was configured at compile time to either use MMIO or native dcr instructions. Although this works for most platforms, it fails on FPGA platforms: 1) Systems may include more than one DCR bus. 2) Systems may be native DCR capable and still use memory mapped DCR interface. This patch provides runtime support based on the device trees for the case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both selected. Previously, this was a poorly defined configuration, which happened to provide NATIVE support. The runtime selection is made based on the dcr-controller having a 'dcr-access-method' attribute in the device tree. If only one of the above options is selected, then the code uses #defines to select only the used code in order to avoid introducing overhead in existing usage. Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-05-06 14:29:17 -04:00
static inline u32 dcr_read_mmio(dcr_host_mmio_t host, unsigned int dcr_n)
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
{
Add dcr_host_t.base in dcr_read()/dcr_write() Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 05:34:36 -04:00
return in_be32(host.token + ((host.base + dcr_n) * host.stride));
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
}
[POWERPC] Refactor DCR code Previously, DCR support was configured at compile time to either use MMIO or native dcr instructions. Although this works for most platforms, it fails on FPGA platforms: 1) Systems may include more than one DCR bus. 2) Systems may be native DCR capable and still use memory mapped DCR interface. This patch provides runtime support based on the device trees for the case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both selected. Previously, this was a poorly defined configuration, which happened to provide NATIVE support. The runtime selection is made based on the dcr-controller having a 'dcr-access-method' attribute in the device tree. If only one of the above options is selected, then the code uses #defines to select only the used code in order to avoid introducing overhead in existing usage. Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-05-06 14:29:17 -04:00
static inline void dcr_write_mmio(dcr_host_mmio_t host,
unsigned int dcr_n,
u32 value)
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
{
Add dcr_host_t.base in dcr_read()/dcr_write() Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we can save them the trouble and do it in dcr_read()/dcr_write(). As some background to why we just went through all this jiggery-pokery, benh sayeth: Initially the goal of the dcr_read/dcr_write routines was to operate like mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx hardware, indirect DCR access is a pain (goes through a table of instructions) and it's useful to have the compiler resolve an absolute DCR inline. We decided that wasn't worth the API bastardisation since most places where absolute DCR values are used are low level 4xx-only code which may as well continue using mfdcr/mtdcr, while the new API is designed for device "instances" that can exist on 4xx and Axon type platforms and may be located at variable DCR offsets. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-10-15 05:34:36 -04:00
out_be32(host.token + ((host.base + dcr_n) * host.stride), value);
[POWERPC] Generic DCR infrastructure This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that can be used by drivers to transparently address either native DCRs or memory mapped DCRs. The implementation for memory mapped DCRs is done after the binding being currently worked on for SLOF and the Axon chipset. This patch enables it for the cell native platform Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 01:24:53 -05:00
}
extern u64 of_translate_dcr_address(struct device_node *dev,
unsigned int dcr_n,
unsigned int *stride);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_MMIO_H */
Reference in New Issue Copy Permalink