Re: [PATCH 00/14] Modifications for DWC OTG since v13
Hi, В Wed, 31 Aug 2011 10:18:42 +0900 Kyungmin Park пишет: > On Wed, Aug 31, 2011 at 12:46 AM, Pratyush Anand > wrote: > > On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri wrote: > >> <-Original Message- > >> mailto:pratyush.an...@st.com] > >> >> >> >> >> >> >> >> >> < > >> http://patchwork.ozlabs.org/patch/89560/ > >> >> >> >> >> >> >> > >> [Tirumala Marri] We are working on our next release of patches. They > >> should be coming out soon. > > > > Oh, thats great !! > > Actually, I did not get any reply of my previous mail on your patch release. > > I thought no one is maintaining., and so I sent them with my modifications, > > after testing them in all dev/host/otg mode. > > > > Regards > > Pratyush > > Hi, > > Can you provide the git repo to test? > and I wonder what's the difference between dwc (from you) and dwc3 > (from Felipe Balbi). I think it's dwc targets for usb 2.0 and dwc3 for > usb 3.0. It doesn't look the same. At least, register definitions are quite different. -- Alexander signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are some minor defconfig updates and a device tree fix from Kumar for 3.1. Cheers, Ben. The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Chunhe Lan (1): powerpc/p1023rds: Fix the error of bank-width of nor flash Kim Phillips (1): powerpc/85xx: enable caam crypto driver by default Timur Tabi (1): powerpc/85xx: enable the audio drivers in the defconfigs arch/powerpc/boot/dts/p1023rds.dts |2 +- arch/powerpc/configs/85xx/p1023rds_defconfig |1 + arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/configs/corenet64_smp_defconfig |5 - arch/powerpc/configs/mpc85xx_defconfig |1 + arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 6 files changed, 9 insertions(+), 2 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Remove linkage for sys_nfsservctl system call
The following commit didn't actually remove it from powerpc: commit f5b940997397229975ea073679b03967932a541b Author: NeilBrown Date: Fri Aug 26 18:03:11 2011 -0400 All Arch: remove linkage for sys_nfsservctl system call The nfsservctl system call is now gone, so we should remove all linkage for it. Signed-off-by: Kumar Gala --- arch/powerpc/include/asm/systbl.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index f6736b7..fa0d27a 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -171,7 +171,7 @@ SYSCALL_SPU(setresuid) SYSCALL_SPU(getresuid) SYSCALL(ni_syscall) SYSCALL_SPU(poll) -COMPAT_SYS(nfsservctl) +SYSCALL(ni_syscall) SYSCALL_SPU(setresgid) SYSCALL_SPU(getresgid) COMPAT_SYS_SPU(prctl) -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH part1 v2 0/9] ps3: General improvements and preparation for support more than the OtherOS lpar
On Thu, 2011-08-11 at 21:31 +0200, Andre Heider wrote: > This is the first part of my previous series including the discussed fixups. > > I dropped the old #2 ([PS3] Get lv1 high memory region from devtree) > and replaced it with 2 new patches, now #2 and #3. The latter contains > the fixups mentioned on the old #2 thread. Just back from vacation. I like these, good stuff. I'd like to have that in soon, can you address the remaining minor comments from Geoff ? Cheers, Ben. > Patches are based on today's Linus' tree. > > Andre Heider (7): > ps3: Add helper functions to read highmem info from the repository > ps3: Get lv1 high memory region from the repository > ps3: MEMORY_HOTPLUG is not a requirement anymore > ps3: Detect the current lpar > ps3: Log the detected lpar on startup > ps3flash: Refuse to work in lpars other than OtherOS > ps3: Only prealloc the flash bounce buffer for the OtherOS lpar > > Hector Martin (2): > Add udbg driver using the PS3 gelic Ethernet device > Add region 1 memory early > > arch/powerpc/Kconfig.debug |8 + > arch/powerpc/include/asm/ps3.h |7 + > arch/powerpc/include/asm/udbg.h |1 + > arch/powerpc/kernel/udbg.c |2 + > arch/powerpc/platforms/ps3/Kconfig | 15 ++- > arch/powerpc/platforms/ps3/Makefile |1 + > arch/powerpc/platforms/ps3/gelic_udbg.c | 273 > +++ > arch/powerpc/platforms/ps3/mm.c | 85 +-- > arch/powerpc/platforms/ps3/platform.h |7 + > arch/powerpc/platforms/ps3/repository.c | 55 ++ > arch/powerpc/platforms/ps3/setup.c | 27 +++- > drivers/char/ps3flash.c |7 + > drivers/net/ps3_gelic_net.c |3 + > drivers/net/ps3_gelic_net.h |6 + > 14 files changed, 447 insertions(+), 50 deletions(-) > create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH 01/15] [PS3] Add udbg driver using the PS3 gelic Ethernet device
On Thu, 2011-08-11 at 19:32 +0200, Andre Heider wrote: > On Thu, Aug 11, 2011 at 2:13 PM, Arnd Bergmann wrote: > > On Thursday 04 August 2011, Geoff Levand wrote: > >> > + * > >> > + * udbg debug output routine via GELIC UDP broadcasts > >> > + * Copyright (C) 2010 Hector Martin > >> > + * Copyright (C) 2011 Andre Heider > >> > >> Some of this seems to be taken from the gelic driver, so shouldn't > >> the copyright info from there be included here? > > > > Moreover, if there is a significant amount of code duplication > > between this driver and gelic, I would expect to actually share > > the code instead, either by integrating the udbg code into the > > gelic driver in form of netconsole support, or by moving the > > common parts into a separate module. > > No, thankfully there is no significant code duplication :) > It contains a few structs and defines found elsewhere, but that's > because it's not a real netdev. It just prepares the eth/ip/udp header > once for its single purpose, then uses the hypervisor to send and poll > - in contrast to the gelic driver, which reuses its irqhandler for > netconsole support. Ack. As long as it's not enabled by default and understood to be what it is, ie, a tool to debug really early boot code before a more "proper" console is available, I have no objection. There is really no code dup, just a couple of struct definitions and it's not a big deal. I'll merge it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 05/10] fadump: Convert firmware-assisted cpu state dump data into elf notes.
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 6923167..1965b50 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -49,6 +49,15 @@ static long no_blink(int state)
> long (*panic_blink)(int state);
> EXPORT_SYMBOL(panic_blink);
>
> +#ifdef CONFIG_FA_DUMP
> +/*
> + * provide an empty default implementation here -- architecture
> + * code may override this
> + */
> +void __attribute__ ((weak)) crash_fadump(struct pt_regs *regs, const char
> *str)
> +{}
> +#endif
> +
> /**
> * panic - halt the system
> * @fmt: The text string to print
> @@ -81,6 +90,13 @@ NORET_TYPE void panic(const char * fmt, ...)
> dump_stack();
> #endif
>
> +#ifdef CONFIG_FA_DUMP
> + /*
> + * If firmware-assisted dump has been registered then trigger
> + * firmware-assisted dump and let firmware handle everything else.
> + */
> + crash_fadump(NULL, buf);
> +#endif
> /*
>* If we have crashed and we have a crash kernel loaded let it handle
>* everything else.
Firmware assisted dump is an IBM POWER Systems specific feature and it
shouldn't leak into a common file like this. Isn't there an existing
hook we can catch like the panic notifier?
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 03/10] fadump: Register for firmware assisted dump.
Hi,
> +static void fadump_show_config(void)
> +{
> + DBG("Support for firmware-assisted dump (fadump): %s\n",
> + (fw_dump.fadump_supported ? "present" : "no support"));
> +
> + if (!fw_dump.fadump_supported)
> + return;
> +
> + DBG("Fadump enabled: %s\n",
> + (fw_dump.fadump_enabled ? "yes" : "no"));
> + DBG("Dump Active : %s\n", (fw_dump.dump_active ? "yes" : "no"));
> + DBG("Dump section sizes:\n");
> + DBG(" CPU state data size: %lx\n", fw_dump.cpu_state_data_size);
> + DBG(" HPTE region size : %lx\n", fw_dump.hpte_region_size);
> + DBG("Boot memory size : %lx\n", fw_dump.boot_memory_size);
> + DBG("Reserve area start: %lx\n", fw_dump.reserve_dump_area_start);
> + DBG("Reserve area size : %lx\n", fw_dump.reserve_dump_area_size);
> +}
> +
> +static void show_fadump_mem_struct(const struct fadump_mem_struct *fdm)
> +{
> + if (!fdm)
> + return;
> +
> + DBG("Firmware-assisted dump memory structure-\n");
> + DBG("header.dump_format_version: 0x%08x\n",
> + fdm->header.dump_format_version);
> + DBG("header.dump_num_sections : %d\n",
> + fdm->header.dump_num_sections);
> + DBG("header.dump_status_flag : 0x%04x\n",
> + fdm->header.dump_status_flag);
> + DBG("header.offset_first_dump_section : 0x%x\n",
> + fdm->header.offset_first_dump_section);
> +
> + DBG("header.dd_block_size : %d\n",
> + fdm->header.dd_block_size);
> + DBG("header.dd_block_offset: 0x%Lx\n",
> + fdm->header.dd_block_offset);
> + DBG("header.dd_num_blocks : %Lx\n",
> + fdm->header.dd_num_blocks);
> + DBG("header.dd_offset_disk_path: 0x%x\n",
> + fdm->header.dd_offset_disk_path);
> +
> + DBG("header.max_time_auto : %d\n",
> + fdm->header.max_time_auto);
> +
> + /* Kernel dump sections */
> + DBG("cpu_state_data.request_flag : 0x%08x\n",
> + fdm->cpu_state_data.request_flag);
> + DBG("cpu_state_data.source_data_type : 0x%04x\n",
> + fdm->cpu_state_data.source_data_type);
> + DBG("cpu_state_data.error_flags: 0x%04x\n",
> + fdm->cpu_state_data.error_flags);
> + DBG("cpu_state_data.source_address : 0x%016Lx\n",
> + fdm->cpu_state_data.source_address);
> + DBG("cpu_state_data.source_len : 0x%Lx\n",
> + fdm->cpu_state_data.source_len);
> + DBG("cpu_state_data.bytes_dumped : 0x%Lx\n",
> + fdm->cpu_state_data.bytes_dumped);
> + DBG("cpu_state_data.destination_address: 0x%016Lx\n",
> + fdm->cpu_state_data.destination_address);
> +
> + DBG("hpte_region.request_flag : 0x%08x\n",
> + fdm->hpte_region.request_flag);
> + DBG("hpte_region.source_data_type : 0x%04x\n",
> + fdm->hpte_region.source_data_type);
> + DBG("hpte_region.error_flags : 0x%04x\n",
> + fdm->hpte_region.error_flags);
> + DBG("hpte_region.source_address: 0x%016Lx\n",
> + fdm->hpte_region.source_address);
> + DBG("hpte_region.source_len: 0x%Lx\n",
> + fdm->hpte_region.source_len);
> + DBG("hpte_region.bytes_dumped : 0x%Lx\n",
> + fdm->hpte_region.bytes_dumped);
> + DBG("hpte_region.destination_address : 0x%016Lx\n",
> + fdm->hpte_region.destination_address);
> +
> + DBG("rmr_region.request_flag : 0x%08x\n",
> + fdm->rmr_region.request_flag);
> + DBG("rmr_region.source_data_type : 0x%04x\n",
> + fdm->rmr_region.source_data_type);
> + DBG("rmr_region.error_flags: 0x%04x\n",
> + fdm->rmr_region.error_flags);
> + DBG("rmr_region.source_address : 0x%016Lx\n",
> + fdm->rmr_region.source_address);
> + DBG("rmr_region.source_len : 0x%Lx\n",
> + fdm->rmr_region.source_len);
> + DBG("rmr_region.bytes_dumped : 0x%Lx\n",
> + fdm->rmr_region.bytes_dumped);
> + DBG("rmr_region.destination_addre
Re: [RFC PATCH 02/10] fadump: Reserve the memory for firmware assisted dump.
Hi Mahesh,
Just a few comments.
> +#define RMR_START0x0
> +#define RMR_END (0x1UL << 28) /* 256 MB */
What if the RMO is bigger than 256MB? Should we be using ppc64_rma_size?
> +#ifdef DEBUG
> +#define PREFIX "fadump: "
> +#define DBG(fmt...) printk(KERN_ERR PREFIX fmt)
> +#else
> +#define DBG(fmt...)
> +#endif
We should use the standard debug macros (pr_debug etc).
> +/* Global variable to hold firmware assisted dump configuration info. */
> +static struct fw_dump fw_dump;
You can remove this comment, especially because the variable isn't global :)
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + NULL);
> +
> + if (!sections)
> + return 0;
> +
> + for (i = 0; i < FW_DUMP_NUM_SECTIONS; i++) {
> + switch (sections[i].dump_section) {
> + case FADUMP_CPU_STATE_DATA:
> + fw_dump.cpu_state_data_size =
> sections[i].section_size;
> + break;
> + case FADUMP_HPTE_REGION:
> + fw_dump.hpte_region_size =
> sections[i].section_size;
> + break;
> + }
> + }
> + return 1;
> +}
This makes me a bit nervous. We should really get the size of the property
and use it to iterate through the array. I saw no requirement in the PAPR
that the array had to be 2 entries long.
> +static inline unsigned long calculate_reserve_size(void)
> +{
> + unsigned long size;
> +
> + /* divide by 20 to get 5% of value */
> + size = memblock_end_of_DRAM();
> + do_div(size, 20);
> +
> + /* round it down in multiples of 256 */
> + size = size & ~0x0FFFUL;
> +
> + /* Truncate to memory_limit. We don't want to over reserve
> the memory.*/
> + if (memory_limit && size > memory_limit)
> + size = memory_limit;
> +
> + return (size > RMR_END ? size : RMR_END);
> +}
5% is pretty aribitrary, that's 400GB on an 8TB box. Also our experience
with kdump is that 256MB is too small. Is there any reason to scale it
with memory size? Can we do what kdump does and set it to a single
value (eg 512MB)?
We could override the default with a boot option, which is similar to
how kdump specifies the region to reserve.
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1023rds: Fix the error of bank-width of nor flash
On Aug 12, 2011, at 6:00 AM, Chunhe Lan wrote: > In the p1023rds, a physical bus of nor flash is 16 bits width. > The bank-width is width (in bytes) of the bus width. So, the > value of bank-width of nor flash is not one, and it should be > two. > > Signed-off-by: Chunhe Lan > --- > arch/powerpc/boot/dts/p1023rds.dts |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] powerpc/85xx: enable the audio drivers in the defconfigs
On Aug 16, 2011, at 5:44 PM, Timur Tabi wrote: > Enable the audio drivers in the non-corenet 85xx defconfigs so that audio > is enabled on the Freescale P1022DS reference board. > > Signed-off-by: Timur Tabi > --- > arch/powerpc/configs/mpc85xx_defconfig |1 + > arch/powerpc/configs/mpc85xx_smp_defconfig |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/85xx: enable caam crypto driver by default
On Jul 22, 2011, at 3:48 PM, Kim Phillips wrote: > corenet based SoCs have SEC4 h/w, so enable the SEC4 driver, > caam, and the algorithms it supports, and disable the > SEC2/3 driver, talitos. > > Signed-off-by: Kim Phillips > --- > v2: rebase from old e55xx_smp_defconfig file to new corenet & p1023 > defconfigs > > arch/powerpc/configs/85xx/p1023rds_defconfig |1 + > arch/powerpc/configs/corenet32_smp_defconfig |1 + > arch/powerpc/configs/corenet64_smp_defconfig |5 - > 3 files changed, 6 insertions(+), 1 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Ben, A few minor defconfig updates and a dts fix to send up to Linus for 3.1 - k The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132: Linux 3.1-rc4 (2011-08-28 21:16:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge Chunhe Lan (1): powerpc/p1023rds: Fix the error of bank-width of nor flash Kim Phillips (1): powerpc/85xx: enable caam crypto driver by default Timur Tabi (1): powerpc/85xx: enable the audio drivers in the defconfigs arch/powerpc/boot/dts/p1023rds.dts |2 +- arch/powerpc/configs/85xx/p1023rds_defconfig |1 + arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/configs/corenet64_smp_defconfig |5 - arch/powerpc/configs/mpc85xx_defconfig |1 + arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 6 files changed, 9 insertions(+), 2 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
On Aug 30, 2011, at 10:01 PM, Tabi Timur-B04825 wrote: > Kumar Gala wrote: >> >> On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote: >> >>> Kumar Gala wrote: Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This seems to vague. >>> >>> Yes, the PIXIS is generally register compatible across all boards. There >>> may be some minor differences, but the OCM driver can work with all PIXIS >>> boards that have an PIXIS. >> >> Is this true? Don't we have pixis and ngpixis in u-boot? > > I forgot about that. Well, everything I said is true about the ngpixis, > so I guess I should use "ngpixis" instead of just "pixis" here. I'll have > to check if the old pixis can be used this way. > >> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS. >>> >>> Ok. >>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD or FPGA not both. >>> >>> Then I don't understand what the CPLD is. >> >> http://en.wikipedia.org/wiki/Complex_programmable_logic_device > > Ok, I get it now. Is there a name for the CPLD we use on these chips? > I'm having a hard time getting proper documentation on the CPLD. York > expressed similar frustration. > > Perhaps these should be called board-control devices. How about > > fsl,boardcontrol-cpld > fsl,boardcontrol-ngpixis > fsl,boardcontrol-qixis For the CPLD based boards I think: -cpld is best as there isn't really much consistent right now. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
Kumar Gala wrote: > > On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote: > >> Kumar Gala wrote: >>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This >>> seems to vague. >> >> Yes, the PIXIS is generally register compatible across all boards. There >> may be some minor differences, but the OCM driver can work with all PIXIS >> boards that have an PIXIS. > > Is this true? Don't we have pixis and ngpixis in u-boot? I forgot about that. Well, everything I said is true about the ngpixis, so I guess I should use "ngpixis" instead of just "pixis" here. I'll have to check if the old pixis can be used this way. > >>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS. >> >> Ok. >> >>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD or >>> FPGA not both. >> >> Then I don't understand what the CPLD is. > > http://en.wikipedia.org/wiki/Complex_programmable_logic_device Ok, I get it now. Is there a name for the CPLD we use on these chips? I'm having a hard time getting proper documentation on the CPLD. York expressed similar frustration. Perhaps these should be called board-control devices. How about fsl,boardcontrol-cpld fsl,boardcontrol-ngpixis fsl,boardcontrol-qixis -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote: > Kumar Gala wrote: >> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This >> seems to vague. > > Yes, the PIXIS is generally register compatible across all boards. There > may be some minor differences, but the OCM driver can work with all PIXIS > boards that have an PIXIS. Is this true? Don't we have pixis and ngpixis in u-boot? >> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS. > > Ok. > >> Also fpga-cpld makes no sense if we keep this. You are either a CPLD or >> FPGA not both. > > Then I don't understand what the CPLD is. http://en.wikipedia.org/wiki/Complex_programmable_logic_device - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
Kumar Gala wrote: > Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This seems > to vague. Yes, the PIXIS is generally register compatible across all boards. There may be some minor differences, but the OCM driver can work with all PIXIS boards that have an PIXIS. > Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS. Ok. > Also fpga-cpld makes no sense if we keep this. You are either a CPLD or FPGA > not both. Then I don't understand what the CPLD is. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
On Aug 29, 2011, at 2:09 PM, Timur Tabi wrote: > Standarize and document the FPGA nodes used on Freescale QorIQ reference > boards. There are three kinds of FPGAs used on the boards: pixis, qixis, and > cpld. Although their are minor differences among the boards that have one > kind of FPGA, most of the functionality is the same, so it makes sense > to create common compatibility strings. > > Signed-off-by: Timur Tabi > --- > > Changes for other Freescale boards will be made in future patches. > > .../devicetree/bindings/powerpc/fsl/board.txt | 30 > arch/powerpc/boot/dts/p1010rdb.dts | 10 ++ > arch/powerpc/boot/dts/p1020rdb.dts |7 - > arch/powerpc/boot/dts/p1022ds.dts |2 +- > arch/powerpc/boot/dts/p2020ds.dts |5 +++ > arch/powerpc/boot/dts/p2020rdb.dts |4 ++ > arch/powerpc/boot/dts/p2040rdb.dts |8 - > arch/powerpc/boot/dts/p3041ds.dts |4 +- > arch/powerpc/boot/dts/p4080ds.dts |8 - > arch/powerpc/boot/dts/p5020ds.dts |4 +- > 10 files changed, 55 insertions(+), 27 deletions(-) Do we really want the generic "fsl,fpga-cpld" & "fsl,fpga-pixis"? This seems to vague. Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS. Also fpga-cpld makes no sense if we keep this. You are either a CPLD or FPGA not both. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
On Tue, 30 Aug 2011, Gary Thomas wrote: > On 2011-08-30 15:43, Paul Walmsley wrote: > > > So are these addresses virtual? My (perhaps incorrect) understanding of > > the device tree files was that they were intended to describe the physical > > memory map, rather than the virtual memory map. Or does this PowerPC > > variant have the ability to dynamically change its own physical address > > decoding? Or is something else going on? > > These addresses correspond to the internal registers which can be moved. > The default address is set by hardware at reset time (check out the > documentation on the hardware reset word). Obviously one board is > strapped for the IMMR at one address, another board at a different > address. I almost always configure my boards to use 0xF000 for the > IMMR. Got it. Thanks Gary. - Paul ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/14] Modifications for DWC OTG since v13
On Wed, Aug 31, 2011 at 12:46 AM, Pratyush Anand wrote: > On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri wrote: >> <-Original Message- >> mailto:pratyush.an...@st.com] >> > > > > > > > > < >> http://patchwork.ozlabs.org/patch/89560/ >> > > > > > > >> [Tirumala Marri] We are working on our next release of patches. They >> should be coming out soon. > > Oh, thats great !! > Actually, I did not get any reply of my previous mail on your patch release. > I thought no one is maintaining., and so I sent them with my modifications, > after testing them in all dev/host/otg mode. > > Regards > Pratyush Hi, Can you provide the git repo to test? and I wonder what's the difference between dwc (from you) and dwc3 (from Felipe Balbi). I think it's dwc targets for usb 2.0 and dwc3 for usb 3.0. Thank you, Kyungmin Park > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
On Fri, 2011-08-26 at 14:41 +1000, David Gibson wrote: > On Wed, Aug 24, 2011 at 09:41:43PM -0300, Thiago Jung Bauermann wrote: > > On Wed, 2011-08-24 at 14:00 +1000, David Gibson wrote: > > > On Tue, Aug 23, 2011 at 02:57:56PM +0530, K.Prasad wrote: > > > > On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote: > > > > > On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote: > > > > > > > > > > > > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts > > > > > > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not > > > > > > intimated to the > > > > > > user-space debuggers (like GDB) who may want to use it. Hence we > > > > > > introduce a > > > > > > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on > > > > > > the > > > > > > "features" member of "struct ppc_debug_info" to advertise support > > > > > > for the > > > > > > same on Book3E PowerPC processors. > > > > > > > > > > I thought the idea was that the BP_EXACT mode was the default - if the > > > > > new interface was supported at all, then BP_EXACT was always > > > > > supported. So, why do you need a new flag? > > > > > > > > > > > > > Yes, BP_EXACT was always supported but not advertised through > > > > PPC_PTRACE_GETHWDBGINFO. We're now doing that. > > > > > > I can see that. But you haven't answered why. > > > > BookS doesn't support BP_EXACT, that's why I suggested this flag. > > Surely you can support it with exactly the same sort of filtering > you're using for the 8-byte ranges now? Yes, but to detect that the processor doesn't support BP_EXACT in hardware I'd have to send a ptrace request, and have it rejected. Only then I'd step back and simulate one with ranges. Considering that it's easy and backwards compatible to add a new flag to signal that BP_EXACT is not supported, I don't know why it would be better to go with the more convoluted process. -- []'s Thiago Jung Bauermann IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
On 2011-08-30 15:43, Paul Walmsley wrote:
Hi,
Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are
some files that are mostly identical, except for some strange
differences.
For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that
the former file claims that the SoC registers start at 0xe000[1], but
the latter file claims that the SoC registers start at 0xa000[2].
Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 ("powerpc/85xx: support
for the TQM8548 module using the big Flash") claims that:
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
So are these addresses virtual? My (perhaps incorrect) understanding of
the device tree files was that they were intended to describe the physical
memory map, rather than the virtual memory map. Or does this PowerPC
variant have the ability to dynamically change its own physical address
decoding? Or is something else going on?
These addresses correspond to the internal registers which can be moved.
The default address is set by hardware at reset time (check out the
documentation
on the hardware reset word). Obviously one board is strapped for the IMMR
at one address, another board at a different address. I almost always configure
my boards to use 0xF000 for the IMMR.
thanks for any clarification,
- Paul
1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53
2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux
v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl_msi: clean up and document calculation of MSIIR address
Timur Tabi wrote: > Commit 3da34aae (powerpc/fsl: Support unique MSI addresses per PCIe Root > Complex) redefined the meanings of msi->msi_addr_hi and msi->msi_addr_lo to be > an offset rather than an address. To help clarify the code, we make the > following changes: Kumar, I'm going to merge this patch into a bigger patch that makes a bunch of other fixes. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Virtual addresses in arch/powerpc/boot/dts/tqm8548*.dts ?
Hi,
Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are
some files that are mostly identical, except for some strange
differences.
For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that
the former file claims that the SoC registers start at 0xe000[1], but
the latter file claims that the SoC registers start at 0xa000[2].
Commit 02b8a3d1eb2ae6353cfbce627ded22e299cf1989 ("powerpc/85xx: support
for the TQM8548 module using the big Flash") claims that:
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
So are these addresses virtual? My (perhaps incorrect) understanding of
the device tree files was that they were intended to describe the physical
memory map, rather than the virtual memory map. Or does this PowerPC
variant have the ability to dynamically change its own physical address
decoding? Or is something else going on?
thanks for any clarification,
- Paul
1. arch/powerpc/boot/dts/tqm8548.dts line 53, as of Linux v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548.dts;h=619776f72c904c611e9507d44db4bee1200e6688;hb=HEAD#l53
2. arch/powerpc/boot/dts/tqm8548-bigflash.dts line 53, as of Linux
v3.1-rc3:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/boot/dts/tqm8548-bigflash.dts;h=9452c3c05114e523033eebb278d7f78811890a87;hb=HEAD#l53
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Implement CONFIG_STRICT_DEVMEM support for Powerpc
>From 9d899c6bcb685afc58245f1fcfe5de1e8b499856 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Mon, 29 Aug 2011 14:12:08 -0700
Subject: [PATCH 1/1] Implement CONFIG_STRICT_DEVMEM support for Powerpc.
As described in the help text in the patch, this token restricts general
access to /dev/mem as a way of increasing the security. Specifically, access
to exclusive IOMEM and kernel RAM is denied unless CONFIG_STRICT_DEVMEM is
set to 'n'.
Implement the 'devmem_is_allowed()' interface for Powerpc. It will be
called from range_is_allowed() when userpsace attempts to access /dev/mem.
This patch is based on an earlier patch from Steve Best and with input from
Paul Mackerras and Scott Wood.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/Kconfig.debug | 12
arch/powerpc/include/asm/page.h |1 +
arch/powerpc/mm/mem.c | 16
drivers/char/mem.c |4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 067cb84..1cf1b00 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -298,4 +298,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+ def_bool y
+ prompt "Filter access to /dev/mem"
+ help
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 2cd664e..9eac49e 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -261,6 +261,7 @@ extern void clear_user_page(void *page, unsigned long
vaddr, struct page *pg);
extern void copy_user_page(void *to, void *from, unsigned long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+extern int devmem_is_allowd(unsigned long pfn);
#ifdef CONFIG_PPC_SMLPAR
void arch_free_page(struct page *page, int order);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c781bbc..bb7537d 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -549,3 +549,19 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned
long address,
hash_preload(vma->vm_mm, address, access, trap);
#endif /* CONFIG_PPC_STD_MMU */
}
+
+/*
+ * devmem_is_allowed(): check to see if /dev/mem access to a certain address
+ * is valid. The argument is a physical page number.
+ *
+ * Access has to be given to non-kernel-ram areas as well, these contain the
+ * PCI mmio resources as well as potential bios/acpi data regions.
+ */
+int devmem_is_allowed(unsigned long pfn)
+{
+ if (iomem_is_exclusive(pfn << PAGE_SHIFT))
+ return 0;
+ if (!page_is_ram(pfn))
+ return 1;
+ return 0;
+}
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 8fc04b4..0fb542c 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -66,8 +66,8 @@ static inline int range_is_allowed(unsigned long pfn,
unsigned long size)
while (cursor < to) {
if (!devmem_is_allowed(pfn)) {
printk(KERN_INFO
- "Program %s tried to access /dev/mem between %Lx->%Lx.\n",
- current->comm, from, to);
+ "Program %s tried to access /dev/mem between %Lx->%Lx and "
+ "pfn %lu.\n", current->comm, from, to, pfn);
return 0;
}
cursor += PAGE_SIZE;
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix xmon for systems without MSR[RI]
On 08/30/2011 01:11 AM, Benjamin Herrenschmidt wrote: > On Mon, 2011-08-08 at 16:25 -0500, Jimi Xenidis wrote: >> From: David Gibson >> >> Based on patch by David Gibson >> >> xmon has a longstanding bug on systems which are SMP-capable but lack >> the MSR[RI] bit. In these cases, xmon invoked by IPI on secondary >> CPUs will not properly keep quiet, but will print stuff, thereby >> garbling the primary xmon's output. This patch fixes it, by ignoring >> the RI bit if the processor does not support it. >> >> There's already a version of this for 4xx upstream, which we'll need >> to extend to other RI-lacking CPUs at some point. For now this adds >> BookE processors to the mix. > > Don't freescale one have RI ? e500mc does. e500v2 doesn't -- if a machine check happens while MSR[ME]=0, it causes a checkstop. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
On Sun, Aug 28, 2011 at 05:04:32PM +0300, Avi Kivity wrote: > On 08/28/2011 04:56 PM, Joerg Roedel wrote: >> This can't be secured by a lock, because it introduces potential >> A->B<-->B->A lock problem when two processes try to take each others mm. >> It could probably be solved by a task->real_mm pointer, havn't thought >> about this yet... >> > > Or a workqueue - you get a kernel thread context with a bit of boilerplate. Right, a workqueue might do the trick. We'll evaluate that. Thanks for the idea :) Joerg ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
On Fri, Aug 26, 2011 at 12:04:22PM -0600, Alex Williamson wrote: > On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote: > > If we really expect segment numbers that need the full 16 bit then this > > would be the way to go. Otherwise I would prefer returning the group-id > > directly and partition the group-id space for the error values (s32 with > > negative numbers being errors). > > It's unlikely to have segments using the top bit, but it would be broken > for an iommu driver to define it's group numbers using pci s:b:d.f if we > don't have that bit available. Ben/David, do PEs have an identifier of > a convenient size? I'd guess any hardware based identifier is going to > use a full unsigned bit width. Okay, if we want to go the secure way I am fine with the "int *group" parameter. Another option is to just return u64 and use the extended number space for errors. But that is even worse as an interface, I think. Joerg ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/14] Modifications for DWC OTG since v13
On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri wrote: > <-Original Message- > mailto:pratyush.an...@st.com] > < > http://patchwork.ozlabs.org/patch/89560/ > > [Tirumala Marri] We are working on our next release of patches. They > should be coming out soon. Oh, thats great !! Actually, I did not get any reply of my previous mail on your patch release. I thought no one is maintaining., and so I sent them with my modifications, after testing them in all dev/host/otg mode. Regards Pratyush > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
On Tue, Aug 30, 2011 at 8:59 PM, Tirumala Marri wrote: > <-Original Message- > mailto:pratyush.an...@st.com] > < >< > > <--- > < include/linux/usb/dwc_otg.h | 274 > > [Tirumala Marri] I am not sure how to separate your changes. But we need > More time as our initial patches are still pending. > --marri Tirumala, If you agree , then I can send you modifications which I did over your patches(v13) separately, and then you can decide the final inclusion of only these modifications. Regards Pratyush > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/14] dwc/otg: Driver enable gadget support
On Tue, Aug 30, 2011 at 6:31 PM, Sergei Shtylyov wrote:
>
> Hello.
>
> On 08/30/2011 03:57 PM, Pratyush Anand wrote:
>
>> From: Tirumala Marri
>
>> Enable gadget support
>
>> Signed-off-by: Tirumala R Marri
>> Signed-off-by: Fushen Chen
>> Signed-off-by: Mark Miesfeld
>> Signed-off-by: Pratyush Anand
>> ---
>> drivers/usb/gadget/gadget_chips.h | 18 +-
>> 1 files changed, 17 insertions(+), 1 deletions(-)
>
>> diff --git a/drivers/usb/gadget/gadget_chips.h
>> b/drivers/usb/gadget/gadget_chips.h
>> index 0978103..66b8018 100644
>> --- a/drivers/usb/gadget/gadget_chips.h
>> +++ b/drivers/usb/gadget/gadget_chips.h
>> @@ -148,6 +148,19 @@
>> #define gadget_is_s3c_hsotg(g) 0
>> #endif
>>
>> +#if defined(CONFIG_DWC_OTG_MODE) || defined(CONFIG_DWC_DEVICE_ONLY)
>> +#define gadget_is_dwc_otg_pcd(g) (!strcmp("dwc_otg_pcd", (g)->name))
>> +#else
>> +#define gadget_is_dwc_otg_pcd(g) 0
>> +#endif
>> +
>> +#ifdef CONFIG_USB_GADGET_CI13XXX_MSM
>> +#define gadget_is_ci13xxx_msm(g) (!strcmp("ci13xxx_msm", (g)->name))
>> +#else
>> +#define gadget_is_ci13xxx_msm(g) 0
>> +#endif
>> +
>> +
>
> Too many newlines.
>
will correct it.
>>
>> /**
>> * usb_gadget_controller_number - support bcdDevice id convention
>> @@ -208,10 +221,13 @@ static inline int usb_gadget_controller_number(struct
>> usb_gadget *gadget)
>> return 0x26;
>> else if (gadget_is_designware(gadget))
>> return 0x27;
>> + else if (gadget_is_ci13xxx_msm(gadget))
>> + return 0x28;
>> + else if (gadget_is_dwc_otg_pcd(gadget))
>> + return 0x29;
>
> Hm, why are you adding 2 gadgets?
Yes, I also do not see reason for ci13xxx_msm.
This was added by original auther Tirumala.
@Tirumala , Please reply.
>
>> return -ENOENT;
>> }
>>
>> -
>
> Unrelated white space change.
will correct.
>
>> /**
>> * gadget_supports_altsettings - return true if altsettings work
>> * @gadget: the gadget in question
>
> WBR, Sergei
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 02/14] dwc/otg: Structure declaration for shared data
<-Original Message- mailto:pratyush.an...@st.com] <--- < include/linux/usb/dwc_otg.h | 274 [Tirumala Marri] I am not sure how to separate your changes. But we need More time as our initial patches are still pending. --marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 00/14] Modifications for DWC OTG since v13
<-Original Message- mailto:pratyush.an...@st.com] http://patchwork.ozlabs.org/patch/89560/ https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: VFIO v2 design plan
On Tue, 2011-08-30 at 17:48 +1000, David Gibson wrote: > On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote: > > On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote: > > > On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote: > > > > > > > > I don't think too much has changed since the previous email went out, > > > > but it seems like a good idea to post a summary in case there were > > > > suggestions or objections that I missed. > > > > > > > > VFIO v2 will rely on the platform iommu driver reporting grouping > > > > information. Again, a group is a set of devices for which the iommu > > > > cannot differentiate transactions. An example would be a set of devices > > > > behind a PCI-to-PCI bridge. All transactions appear to be from the > > > > bridge itself rather than devices behind the bridge. Platforms are free > > > > to have whatever constraints they need to for what constitutes a group. > > > > > > > > I posted a rough draft of patch to implement that for the base iommu > > > > driver and VT-d, adding an iommu_device_group callback on iommu ops. > > > > The iommu base driver also populates an iommu_group sysfs file for each > > > > device that's part of a group. Members of the same group return the > > > > same value via either the sysfs or iommu_device_group. The value > > > > returned is arbitrary, should not be assumed to be persistent across > > > > boots, and is left to the iommu driver to generate. There are some > > > > implementation details around how to do this without favoring one bus > > > > over another, but the interface should be bus/device type agnostic in > > > > the end. > > > > > > > > When the vfio module is loaded, character devices will be created for > > > > each group in /dev/vfio/$GROUP. Setting file permissions on these files > > > > should be sufficient for providing a user with complete access to the > > > > group. Opening this device file provides what we'll call the "group > > > > fd". The group fd is restricted to only work with a single mm context. > > > > Concurrent opens will be denied if the opening process mm does not > > > > match. The group fd will provide interfaces for enumerating the devices > > > > in the group, returning a file descriptor for each device in the group > > > > (the "device fd"), binding groups together, and returning a file > > > > descriptor for iommu operations (the "iommu fd"). > > > > > > > > A group is "viable" when all member devices of the group are bound to > > > > the vfio driver. Until that point, the group fd only allows enumeration > > > > interfaces (ie. listing of group devices). I'm currently thinking > > > > enumeration will be done by a simple read() on the device file returning > > > > a list of dev_name()s. > > > > > > Ok. Are you envisaging this interface as a virtual file, or as a > > > stream? That is, can you seek around the list of devices like a > > > regular file - in which case, what are the precise semantics when the > > > list is changed by a bind - or is there no meaningful notion of file > > > pointer and read() just gives you the next device - in which case how > > > to you rewind to enumerate the group again. > > > > I was implementing it as a virtual file that gets generated on read() > > (see example in note[2] below). It is a bit clunky as reading it a byte > > at a time could experience races w/ device add/remove. If it's read all > > at once, it's an accurate snapshot. Suggestions welcome, this just > > seemed easier than trying to stuff it into a struct for an ioctl. For a > > while I thought I could do a VFIO_GROUP_GET_NUM_DEVICES + > > VFIO_GROUP_GET_DEVICE_INDEX, but that assumes device stability, which I > > don't think we can guarantee. > > Yeah, that sounds reasonable. > > > > > Once the group is viable, the user may bind the > > > > group to another group, retrieve the iommu fd, or retrieve device fds. > > > > Internally, each of these operations will result in an iommu domain > > > > being allocated and all of the devices attached to the domain. > > > > > > > > The purpose of binding groups is to share the iommu domain. Groups > > > > making use of incompatible iommu domains will fail to bind. Groups > > > > making use of different mm's will fail to bind. The vfio driver may > > > > reject some binding based on domain capabilities, but final veto power > > > > is left to the iommu driver[1]. If a user makes use of a group > > > > independently and later wishes to bind it to another group, all the > > > > device fds and the iommu fd must first be closed. This prevents using a > > > > stale iommu fd or accessing devices while the iommu is being switched. > > > > Operations on any group fds of a merged group are performed globally on > > > > the group (ie. enumerating the devices lists all devices in the merged > > > > group, retrieving the iommu fd from any group fd results in the same fd, > > > > device fds from any group can be retrie
[PATCH 02/14] dwc/otg: Structure declaration for shared data
There are some DWC OTG parameters which might be passed by a platform.
Declaration for structure of those parameters have been provided in this
include file.
Signed-off-by: Pratyush Anand
---
include/linux/usb/dwc_otg.h | 274 +++
1 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 include/linux/usb/dwc_otg.h
diff --git a/include/linux/usb/dwc_otg.h b/include/linux/usb/dwc_otg.h
new file mode 100644
index 000..aa86adc
--- /dev/null
+++ b/include/linux/usb/dwc_otg.h
@@ -0,0 +1,274 @@
+/* DWC OTG (On The Go) defines */
+
+#ifndef __LINUX_DWC_OTG_H
+#define __LINUX_DWC_OTG_H
+
+/*
+ * The following parameters may be specified when starting the module. These
+ * parameters define how the DWC_otg controller should be configured.
Parameter
+ * values are passed to the CIL initialization function dwc_otg_cil_init.
+ */
+struct core_params {
+ /*
+* Specifies the OTG capabilities. The driver will automatically
+* detect the value for this parameter if none is specified.
+* 0 - HNP and SRP capable (default)
+* 1 - SRP Only capable
+* 2 - No HNP/SRP capable
+*/
+ int otg_cap;
+#define DWC_OTG_CAP_PARAM_HNP_SRP_CAPABLE 0
+#define DWC_OTG_CAP_PARAM_SRP_ONLY_CAPABLE 1
+#define DWC_OTG_CAP_PARAM_NO_HNP_SRP_CAPABLE 2
+
+#define dwc_param_otg_cap_default DWC_OTG_CAP_PARAM_HNP_SRP_CAPABLE
+
+ /*
+* Specifies whether to use slave or DMA mode for accessing the data
+* FIFOs. The driver will automatically detect the value for this
+* parameter if none is specified.
+* 0 - Slave
+* 1 - DMA (default, if available)
+*/
+ int dma_enable;
+#ifdef CONFIG_DWC_SLAVE
+#define dwc_param_dma_enable_default 0
+#else
+#define dwc_param_dma_enable_default 1
+#endif
+
+ /*
+* The DMA Burst size (applicable only for External DMA Mode).
+* 1, 4, 8 16, 32, 64, 128, 256 (default 32)
+*/
+ int dma_burst_size; /* Translate this to GAHBCFG values */
+#define dwc_param_dma_burst_size_default 32
+
+ /*
+* Specifies the maximum speed of operation in host and device mode.
+* The actual speed depends on the speed of the attached device and
+* the value of phy_type. The actual speed depends on the speed of the
+* attached device.
+* 0 - High Speed (default)
+* 1 - Full Speed
+*/
+ int speed;
+#define dwc_param_speed_default0
+#define DWC_SPEED_PARAM_HIGH 0
+#define DWC_SPEED_PARAM_FULL 1
+
+ /*
+* Specifies whether low power mode is supported when attached to a Full
+* Speed or Low Speed device in host mode.
+* 0 - Don't support low power mode (default)
+* 1 - Support low power mode
+*/
+ int host_support_fs_ls_low_power;
+#define dwc_param_host_support_fs_ls_low_power_default 0
+
+ /*
+* Specifies the PHY clock rate in low power mode when connected to a
+* Low Speed device in host mode. This parameter is applicable only if
+* HOST_SUPPORT_FS_LS_LOW_POWER is enabled. If PHY_TYPE is set to FS
+* then defaults to 6 MHZ otherwise 48 MHZ.
+*
+* 0 - 48 MHz
+* 1 - 6 MHz
+*/
+ int host_ls_low_power_phy_clk;
+#define dwc_param_host_ls_low_power_phy_clk_default0
+#define DWC_HOST_LS_LOW_POWER_PHY_CLK_PARAM_48MHZ 0
+#define DWC_HOST_LS_LOW_POWER_PHY_CLK_PARAM_6MHZ 1
+
+ /*
+* 0 - Use cC FIFO size parameters
+* 1 - Allow dynamic FIFO sizing (default)
+*/
+ int enable_dynamic_fifo;
+#define dwc_param_enable_dynamic_fifo_default 1
+
+ /*
+* Number of 4-byte words in the Rx FIFO in device mode when dynamic
+* FIFO sizing is enabled. 16 to 32768 (default 1064)
+*/
+ int dev_rx_fifo_size;
+#define dwc_param_dev_rx_fifo_size_default 1064
+
+ /*
+* Number of 4-byte words in the non-periodic Tx FIFO in device mode
+* when dynamic FIFO sizing is enabled. 16 to 32768 (default 1024)
+*/
+ int dev_nperio_tx_fifo_size;
+#define dwc_param_dev_nperio_tx_fifo_size_default 1024
+
+ /*
+* Number of 4-byte words in each of the periodic Tx FIFOs in device
+* mode when dynamic FIFO sizing is enabled. 4 to 768 (default 256)
+*/
+#define MAX_TX_FIFOS 15 /* Max periodic FIFOs */
+ u32 dev_perio_tx_fifo_size[MAX_TX_FIFOS];
+#define dwc_param_dev_perio_tx_fifo_size_default 256
+
+ /*
+* Number of 4-byte words in the Rx FIFO in host mode when dynamic
+* FIFO sizing is enabled. 16 to 32768 (default 1024)
+*/
+ int host_rx_fi
[PATCH 03/14] dwc/otg: Add driver framework
From: Tirumala Marri
Platform probing is in dwc_otg_apmppc.c.
Driver parameter and parameter checking are in dwc_otg_param.c.
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
Signed-off-by: Pratyush Anand
---
drivers/usb/dwc/apmppc.c | 436 ++
drivers/usb/dwc/driver.h | 76
drivers/usb/dwc/param.c | 219 +++
3 files changed, 731 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/apmppc.c
create mode 100644 drivers/usb/dwc/driver.h
create mode 100644 drivers/usb/dwc/param.c
diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
new file mode 100644
index 000..80ea274
--- /dev/null
+++ b/drivers/usb/dwc/apmppc.c
@@ -0,0 +1,436 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld
+ * Modified by Stefan Roese , DENX Software Engineering
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * The dwc_otg module provides the initialization and cleanup entry
+ * points for the dwcotg driver. This module will be dynamically installed
+ * after Linux is booted using the insmod command. When the module is
+ * installed, the dwc_otg_driver_init function is called. When the module is
+ * removed (using rmmod), the dwc_otg_driver_cleanup function is called.
+ *
+ * This module also defines a data structure for the dwc_otg driver, which is
+ * used in conjunction with the standard device structure. These
+ * structures allow the OTG driver to comply with the standard Linux driver
+ * model in which devices and drivers are registered with a bus driver. This
+ * has the benefit that Linux can expose attributes of the driver and device
+ * in its special sysfs file system. Users can then read or write files in
+ * this file system to perform diagnostics on the driver components or the
+ * device.
+ */
+
+#include
+
+#include "driver.h"
+
+#define DWC_DRIVER_VERSION "1.05"
+#define DWC_DRIVER_DESC"HS OTG USB Controller driver"
+static const char dwc_driver_name[] = "dwc_otg";
+
+/**
+ * This function is the top level interrupt handler for the Common
+ * (Device and host modes) interrupts.
+ */
+static irqreturn_t dwc_otg_common_irq(int _irq, void *dev)
+{
+ struct dwc_otg_device *dwc_dev = dev;
+ int retval;
+
+ retval = dwc_otg_handle_common_intr(dwc_dev->core_if);
+ return IRQ_RETVAL(retval);
+}
+
+/**
+ * This function is the interrupt handler for the OverCurrent condition
+ * from the external charge pump (if enabled)
+ */
+static irqreturn_t dwc_otg_externalchgpump_irq(int _irq, void *dev)
+{
+ struct dwc_otg_device *dwc_dev = dev;
+
+ if (dwc_otg_is_host_mode(dwc_dev->core_if)) {
+ struct dwc_hcd *dwc_hcd;
+ u32 hprt0 = 0;
+
+ dwc_hcd = dwc_dev->hcd;
+ spin_lock(&dwc_hcd->lock);
+ dwc_hcd->flags.b.port_over_current_change = 1;
+
+ hprt0 = DWC_HPRT0_PRT_PWR_RW(hprt0, 0);
+ dwc_write32(dwc_dev->core_if->host_if->hprt0, hprt0);
+ spin_unlock(&dwc_hcd->lock);
+ } else {
+ /* Device mode - This int is n/a for device mode */
+ dev_dbg(dev, "DeviceMode: OTG OverCurrent Detected\n");
+ }
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * This function is called w
[PATCH 00/14] Modifications for DWC OTG since v13
These patches are based on:http://patchwork.ozlabs.org/patch/89560/ After not getting any reply from developers, I started to do modifications for my platform (SPEAr1340). I have done modifications in such a way that all the code in driver/usb/dwc/ would be platform independent. I have tested this code for host/device/dma/slave mode. My fifo configuration is dedicated and dynamic. Changes since v13: 1. All the patches has been renamed from usb/ppc4xx to dwc/otg. Changes has been done, because these files are valid for other architecture also. 2. Parameter passing mechanism has been modified. Now, driver can also receive parameters from a platform device. 3. Next request is started after clear halt for all slave transfer There might be a situation, when there are data into fifo, EP is receiving IN token, but EP is disabled. In this case, EP will just stop and do nothing. So, for each transfer type start_next_request is enabled. 4. Dynamic fifo was configured by reading number of endpoints. Number of endpoints can be different than the number of dynamic fifo in the controller. Number of dynamic fifo is programmed in fifo_number parameter. Program fifos only for fifo_number of fifo. 5. If platform specific functions like phy_init and param_init is defined then call it. 6. Few define which are used for TX, were defined as RX in the code. All such definition has been replaced throughout the code. 7. There are some defined steps to disable an endpoint. It can not be disabled just by setting epdisable bit. Now, it is disabled as specification says. During stall of and endpoint, first stall bit should be set and then endpoint should be disabled. In dwc_otg_pcd_ep_disable, TX fifo must be flushed along with disabling of endpoint. In DMA mode if Fifo is flushed only once then, DMA will write data into it again. So, it must be flushed till DMA transfer is complete. 8. dwc_otg_ep_deactivate is called after dwc_otg_ep_disable. 9. platform_get_irq return -ENXIO , if requested IRQ is not found. So, return must be checked accordingly. 10. There is a struct (core_params) for all possible variable parameters of OTG. Earlier, these parameters were not modifiable for any platform data. It was reading from the HW and then was programming the same value again. Now, it has been modified. A platform code can modify these parameters. Struct definition has been moved from cil.h to a new file include/linux/usb/dwc_otg.h. Some of the parameters have been initialized with default values, while other with -1. A new parameter fifo_number has been added. This parameter is also defined in the specification. Otg code was reading number of endpoint from hwcfg regs for the purpose of this parameter, which was wrong. SW checks for only fifo_number fifos and not MAX_TX_FIFOS. Now , there is only one define for MAX_TX_FIFO and MAX_PERIO_FIFOS. As, per specification they can not be different. 11. In dwc_otg_pcd_handle_np_tx_fifo_empty_intr a different interrupt was cleared. Corrected it to clear NP TX Fifo empty interrupt. Re-enabling of interrupt was not correct when packets were still pending. This patch also corrects this behaviour. 12. Code checks for space availability in fifo during write_epmty_tx_fifo. It was writing only when space available was more than data to be written. So, it was writing 512 bytes only when 516 bytes space was available. Modified condition check from > to >=. 13. When TX fifo empty interrupt is received, transfer completion may not be true. Next transfer should only be started when transfer is complete, i.e. packet count in dieptsiz register has become zero. 14. Max number of EP increased to 16 15. There can be few devices like SPEAr1340, which issues a connection only after removal of soft disconnect. Default reset value is disconnected. It will not have any side effect even for the device where reset value is connected. 16. As per data sheet, when bit 31 of GRSTCTL is 1 then AHB is IDLE. Earlier function was waiting for this but to be 0, which was wrong. 17. Although name of file suggest that it is specific for PPC. But, all of its content are common for OTG and can be used for any platform. There were some compilation issued on ARM platform with this file. It has been removed by calling by proper functions. Pratyush Anand (4): dwc/otg: Structure declaration for shared data include/linux/usb/gadget.h : include for successful compilation usb/gadget/kconfig: added dwc otg as an option for peripheral controller arm/include/asm/io.h : added macros to read/write big/little endian register Tirumala Marri (10): dwc/otg: Add Register definitions dwc/otg: Add driver framework dwc/otg: Add Core Interface Layer (
[PATCH 10/14] dwc/otg: Add driver kernel configuration and Makefile
From: Tirumala Marri Add Synopsys DesignWare HS USB OTG driver kernel configuration. Synopsys OTG driver may operate in host only, device only, or OTG mode. The driver also allows user configure the core to use its internal DMA or Slave (PIO) mode. Signed-off-by: Tirumala R Marri Signed-off-by: Fushen Chen Signed-off-by: Mark Miesfeld --- drivers/Makefile |1 + drivers/usb/Kconfig |2 + drivers/usb/dwc/Kconfig | 84 ++ drivers/usb/dwc/Makefile | 19 ++ 4 files changed, 106 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc/Kconfig create mode 100644 drivers/usb/dwc/Makefile diff --git a/drivers/Makefile b/drivers/Makefile index a0d5aa60..d951bf6 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -68,6 +68,7 @@ obj-$(CONFIG_PARIDE) += block/paride/ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB) += uwb/ obj-$(CONFIG_USB_OTG_UTILS)+= usb/otg/ +obj-$(CONFIG_USB_DWC_OTG) += usb/dwc/ obj-$(CONFIG_USB) += usb/ obj-$(CONFIG_USB_MUSB_HDRC)+= usb/musb/ obj-$(CONFIG_PCI) += usb/ diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 8cd1df5..963e4b3 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -117,6 +117,8 @@ source "drivers/usb/host/Kconfig" source "drivers/usb/musb/Kconfig" +source "drivers/usb/dwc/Kconfig" + source "drivers/usb/class/Kconfig" source "drivers/usb/storage/Kconfig" diff --git a/drivers/usb/dwc/Kconfig b/drivers/usb/dwc/Kconfig new file mode 100644 index 000..eafc5ed --- /dev/null +++ b/drivers/usb/dwc/Kconfig @@ -0,0 +1,84 @@ +# +# USB Dual Role (OTG-ready) Controller Drivers +# for silicon based on Synopsys DesignWare IP +# + +comment "Enable Host or Gadget support for DesignWare OTG controller" + depends on !USB && USB_GADGET=n + +config USB_DWC_OTG + tristate "Synopsys DWC OTG Controller" + depends on USB || USB_GADGET + select NOP_USB_XCEIV + select USB_OTG_UTILS + default USB_GADGET + help + This driver provides USB Device Controller support for the + Synopsys DesignWare USB OTG Core used on the AppliedMicro PowerPC SoC. + +config DWC_DEBUG + bool "Enable DWC Debugging" + depends on USB_DWC_OTG + default n + help + Enable DWC driver debugging + +choice + prompt "DWC Mode Selection" + depends on USB_DWC_OTG + default DWC_HOST_ONLY + help + Select the DWC Core in OTG, Host only, or Device only mode. + +config DWC_HOST_ONLY + bool "DWC Host Only Mode" + +config DWC_OTG_MODE + bool "DWC OTG Mode" + select USB_GADGET_SELECTED + +config DWC_DEVICE_ONLY + bool "DWC Device Only Mode" + select USB_GADGET_SELECTED + +endchoice + +# enable peripheral support (including with OTG) +choice + prompt "DWC DMA/SlaveMode Selection" + depends on USB_DWC_OTG + default DWC_DMA_MODE + help + Select the DWC DMA or Slave Mode. + DMA mode uses the DWC core internal DMA engines. + Slave mode uses the processor PIO to tranfer data. + In Slave mode, processor's DMA channels can be used if available. + +config DWC_SLAVE + bool "DWC Slave Mode" + +config DWC_DMA_MODE + bool "DWC DMA Mode" + +endchoice + +config DWC_OTG_REG_LE + bool "DWC Little Endian Register" + depends on USB_DWC_OTG + default y + help + OTG core register access is Little-Endian. + +config DWC_OTG_FIFO_LE + bool "DWC FIFO Little Endian" + depends on USB_DWC_OTG + default n + help + OTG core FIFO access is Little-Endian. + +config DWC_LIMITED_XFER_SIZE + bool "DWC Endpoint Limited Xfer Size" + depends on USB_GADGET_DWC_HDRC + default n + help + Bit fields in the Device EP Transfer Size Register is 11 bits. diff --git a/drivers/usb/dwc/Makefile b/drivers/usb/dwc/Makefile new file mode 100644 index 000..4102add --- /dev/null +++ b/drivers/usb/dwc/Makefile @@ -0,0 +1,19 @@ +# +# OTG infrastructure and transceiver drivers +# +obj-$(CONFIG_USB_DWC_OTG) += dwc.o + +dwc-objs := cil.o cil_intr.o param.o + +ifeq ($(CONFIG_4xx_SOC),y) +dwc-objs += apmppc.o +endif + +ifneq ($(CONFIG_DWC_DEVICE_ONLY),y) +dwc-objs += hcd.o hcd_intr.o \ + hcd_queue.o +endif + +ifneq ($(CONFIG_DWC_HOST_ONLY),y) +dwc-objs += pcd.o pcd_intr.o +endif -- 1.7.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/14] dwc/otg: Add PCD function
From: Tirumala Marri
The PCD is responsible for translating requests from the gadget driver
to appropriate actions on the DWC OTG controller.
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
Signed-off-by: Pratyush Anand
---
drivers/usb/dwc/pcd.c | 1818 +
drivers/usb/dwc/pcd.h | 139
2 files changed, 1957 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/pcd.c
create mode 100644 drivers/usb/dwc/pcd.h
diff --git a/drivers/usb/dwc/pcd.c b/drivers/usb/dwc/pcd.c
new file mode 100644
index 000..2ef6405
--- /dev/null
+++ b/drivers/usb/dwc/pcd.c
@@ -0,0 +1,1818 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld
+ * Modified by Stefan Roese , DENX Software Engineering
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * This file implements the Peripheral Controller Driver.
+ *
+ * The Peripheral Controller Driver (PCD) is responsible for
+ * translating requests from the Function Driver into the appropriate
+ * actions on the DWC_otg controller. It isolates the Function Driver
+ * from the specifics of the controller by providing an API to the
+ * Function Driver.
+ *
+ * The Peripheral Controller Driver for Linux will implement the
+ * Gadget API, so that the existing Gadget drivers can be used.
+ * (Gadget Driver is the Linux terminology for a Function Driver.)
+ *
+ * The Linux Gadget API is defined in the header file linux/usb/gadget.h. The
+ * USB EP operations API is defined in the structure usb_ep_ops and the USB
+ * Controller API is defined in the structure usb_gadget_ops
+ *
+ * An important function of the PCD is managing interrupts generated
+ * by the DWC_otg controller. The implementation of the DWC_otg device
+ * mode interrupt service routines is in dwc_otg_pcd_intr.c.
+ */
+
+#include
+#include
+
+#include "pcd.h"
+
+/*
+ * Static PCD pointer for use in usb_gadget_register_driver and
+ * usb_gadget_unregister_driver. Initialized in dwc_otg_pcd_init.
+ */
+static struct dwc_pcd *s_pcd;
+
+static inline int need_stop_srp_timer(struct core_if *core_if)
+{
+ if (core_if->core_params->phy_type != DWC_PHY_TYPE_PARAM_FS ||
+ !core_if->core_params->i2c_enable)
+ return core_if->srp_timer_started ? 1 : 0;
+ return 0;
+}
+
+/**
+ * Tests if the module is set to FS or if the PHY_TYPE is FS. If so, then the
+ * gadget should not report as dual-speed capable.
+ */
+static inline int check_is_dual_speed(struct core_if *core_if)
+{
+ if (core_if->core_params->speed == DWC_SPEED_PARAM_FULL ||
+ (DWC_HWCFG2_HS_PHY_TYPE_RD(core_if->hwcfg2) == 2 &&
+DWC_HWCFG2_P_2_P_RD(core_if->hwcfg2) == 1 &&
+core_if->core_params->ulpi_fs_ls))
+ return 0;
+ return 1;
+}
+
+/**
+ * Tests if driver is OTG capable.
+ */
+static inline int check_is_otg(struct core_if *core_if)
+{
+ if (DWC_HWCFG2_OP_MODE_RD(core_if->hwcfg2) ==
+ DWC_HWCFG2_OP_MODE_NO_SRP_CAPABLE_DEVICE ||
+ DWC_HWCFG2_OP_MODE_RD(core_if->hwcfg2) ==
+ DWC_HWCFG2_OP_MODE_NO_SRP_CAPABLE_HOST ||
+ DWC_HWCFG2_OP_MODE_RD(core_if->hwcfg2) ==
+ DWC_HWCFG2_OP_MODE_SRP_CAPABLE_DEVICE ||
+ DWC_HWCFG2_OP_MODE_RD(core_if->hwcfg2) ==
+ DWC_HWCFG2_OP_MODE_SRP_CAPABLE_HOST)
+
[PATCH 11/14] dwc/otg: Driver enable gadget support
From: Tirumala Marri
Enable gadget support
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
Signed-off-by: Pratyush Anand
---
drivers/usb/gadget/gadget_chips.h | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index 0978103..66b8018 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -148,6 +148,19 @@
#define gadget_is_s3c_hsotg(g)0
#endif
+#if defined(CONFIG_DWC_OTG_MODE) || defined(CONFIG_DWC_DEVICE_ONLY)
+#define gadget_is_dwc_otg_pcd(g) (!strcmp("dwc_otg_pcd", (g)->name))
+#else
+#define gadget_is_dwc_otg_pcd(g) 0
+#endif
+
+#ifdef CONFIG_USB_GADGET_CI13XXX_MSM
+#define gadget_is_ci13xxx_msm(g) (!strcmp("ci13xxx_msm", (g)->name))
+#else
+#define gadget_is_ci13xxx_msm(g) 0
+#endif
+
+
/**
* usb_gadget_controller_number - support bcdDevice id convention
@@ -208,10 +221,13 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x26;
else if (gadget_is_designware(gadget))
return 0x27;
+ else if (gadget_is_ci13xxx_msm(gadget))
+ return 0x28;
+ else if (gadget_is_dwc_otg_pcd(gadget))
+ return 0x29;
return -ENOENT;
}
-
/**
* gadget_supports_altsettings - return true if altsettings work
* @gadget: the gadget in question
--
1.7.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 12/14] include/linux/usb/gadget.h : include for successful compilation
gadget.h uses struct device, which has been declared in linux/device.h. So it must be included. Signed-off-by: Pratyush Anand --- include/linux/usb/gadget.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index 006412c..32f7b69 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -16,6 +16,7 @@ #define __LINUX_USB_GADGET_H #include +#include struct usb_ep; -- 1.7.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 14/14] arm/include/asm/io.h : added macros to read/write big/little endian register
There are some peripheral(e.g dwc otg) whose registers can be configured to work in either little or big endian mode. Therefor macros like out_be32, in_be32, out_le32 and in_le32 have been added to support such peripherals. Signed-off-by: Pratyush Anand --- arch/arm/include/asm/io.h |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h index 815efa2..32282b4 100644 --- a/arch/arm/include/asm/io.h +++ b/arch/arm/include/asm/io.h @@ -297,6 +297,14 @@ extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size); extern int devmem_is_allowed(unsigned long pfn); #endif +/* Big Endian */ +#define out_be32(a, v) writel(__cpu_to_be32(v), a) +#define in_be32(a) __be32_to_cpu(readl(a)) + +/* Little endian */ +#define out_le32(a, v) writel(__cpu_to_le32(v), a) +#define in_le32(a) __le32_to_cpu(readl(a)) + /* * Convert a physical pointer to a virtual kernel pointer for /dev/mem * access -- 1.7.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/14] dwc/otg: Add Register definitions
From: Tirumala Marri Add Synopsys Design Ware core register definitions. Signed-off-by: Tirumala R Marri Signed-off-by: Fushen Chen Signed-off-by: Mark Miesfeld Signed-off-by: Pratyush Anand --- drivers/usb/dwc/regs.h | 1324 1 files changed, 1324 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc/regs.h diff --git a/drivers/usb/dwc/regs.h b/drivers/usb/dwc/regs.h new file mode 100644 index 000..f29e945 --- /dev/null +++ b/drivers/usb/dwc/regs.h @@ -0,0 +1,1324 @@ +/* + * DesignWare HS OTG controller driver + * Copyright (C) 2006 Synopsys, Inc. + * Portions Copyright (C) 2010 Applied Micro Circuits Corporation. + * + * This program is free software: you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * 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 version 2 for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, see http://www.gnu.org/licenses + * or write to the Free Software Foundation, Inc., 51 Franklin Street, + * Suite 500, Boston, MA 02110-1335 USA. + * + * Based on Synopsys driver version 2.60a + * Modified by Mark Miesfeld + * + * Revamped register difinitions by Tirumala R Marri(tma...@apm.com) + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES + * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + */ + +#ifndef __DWC_OTG_REGS_H__ +#define __DWC_OTG_REGS_H__ + +#include +#include +/*Bit fields in the Device EP Transfer Size Register is 11 bits */ +#undef DWC_LIMITED_XFER_SIZE +/* + * This file contains the Macro defintions for accessing the DWC_otg core + * registers. + * + * The application interfaces with the HS OTG core by reading from and + * writing to the Control and Status Register (CSR) space through the + * AHB Slave interface. These registers are 32 bits wide, and the + * addresses are 32-bit-block aligned. + * CSRs are classified as follows: + * - Core Global Registers + * - Device Mode Registers + * - Device Global Registers + * - Device Endpoint Specific Registers + * - Host Mode Registers + * - Host Global Registers + * - Host Port CSRs + * - Host Channel Specific Registers + * + * Only the Core Global registers can be accessed in both Device and + * Host modes. When the HS OTG core is operating in one mode, either + * Device or Host, the application must not access registers from the + * other mode. When the core switches from one mode to another, the + * registers in the new mode of operation must be reprogrammed as they + * would be after a power-on reset. + */ + +/* + * DWC_otg Core registers. The core_global_regs structure defines the + * size and relative field offsets for the Core Global registers. + */ +#defineDWC_GOTGCTL 0x000 +#defineDWC_GOTGINT 0x004 +#defineDWC_GAHBCFG 0x008 +#defineDWC_GUSBCFG 0x00C +#defineDWC_GRSTCTL 0x010 +#defineDWC_GINTSTS 0x014 +#defineDWC_GINTMSK 0x018 +#defineDWC_GRXSTSR 0x01C +#defineDWC_GRXSTSP 0x020 +#defineDWC_GRXFSIZ 0x024 +#defineDWC_GNPTXFSIZ 0x028 +#defineDWC_GNPTXSTS0x02C +#defineDWC_GI2CCTL 0x030 +#defineDWC_VDCTL 0x034 +#defineDWC_GGPIO 0x038 +#defineDWC_GUID0x03C +#defineDWC_GSNPSID 0x040 +#defineDWC_GHWCFG1 0x044 +#defineDWC_GHWCFG2 0x048 +#defineDWC_GHWCFG3 0x04c +#defineDWC_GHWCFG4 0x050 +#defineDWC_HPTXFSIZ0x100 +#defineDWC_DPTX_FSIZ_DIPTXF(x) (0x104 + x * 4) /* 15 <= x > 1 */ + +#define DWC_GLBINTRMASK0x0001 +#define DWC_DMAENABLE 0x0020 +#define DWC_NPTXEMPTYLVL_EMPTY 0x0080 +#define DWC_NPTXEMPTYLVL_HALFEMPTY
[PATCH 06/14] dwc/otg: Add HCD interrupt function
From: Tirumala Marri
Implements DWC OTG USB HCD interrupt service routine.
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
Signed-off-by: Pratyush Anand
---
drivers/usb/dwc/hcd_intr.c | 1481
1 files changed, 1481 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/hcd_intr.c
diff --git a/drivers/usb/dwc/hcd_intr.c b/drivers/usb/dwc/hcd_intr.c
new file mode 100644
index 000..2221795
--- /dev/null
+++ b/drivers/usb/dwc/hcd_intr.c
@@ -0,0 +1,1481 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld
+ * Modified by Stefan Roese , DENX Software Engineering
+ * Modified by Chuck Meade
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+#include "hcd.h"
+
+/* This file contains the implementation of the HCD Interrupt handlers.
*/
+static const int erratum_usb09_patched;
+static const int deferral_on = 1;
+static const int nak_deferral_delay = 8;
+static const int nyet_deferral_delay = 1;
+
+/**
+ * Handles the start-of-frame interrupt in host mode. Non-periodic
+ * transactions may be queued to the DWC_otg controller for the current
+ * (micro)frame. Periodic transactions may be queued to the controller for the
+ * next (micro)frame.
+ */
+static int dwc_otg_hcd_handle_sof_intr(struct dwc_hcd *hcd)
+{
+ u32 hfnum = 0;
+ struct list_head *qh_entry;
+ struct dwc_qh *qh;
+ enum dwc_transaction_type tr_type;
+ u32 gintsts = 0;
+
+ hfnum =
+ dwc_read32(hcd->core_if->host_if->host_global_regs +
+ DWC_HFNUM);
+
+ hcd->frame_number = DWC_HFNUM_FRNUM_RD(hfnum);
+
+ /* Determine whether any periodic QHs should be executed. */
+ qh_entry = hcd->periodic_sched_inactive.next;
+ while (qh_entry != &hcd->periodic_sched_inactive) {
+ qh = list_entry(qh_entry, struct dwc_qh, qh_list_entry);
+ qh_entry = qh_entry->next;
+
+ /*
+* If needed, move QH to the ready list to be executed next
+* (micro)frame.
+*/
+ if (dwc_frame_num_le(qh->sched_frame, hcd->frame_number))
+ list_move(&qh->qh_list_entry,
+ &hcd->periodic_sched_ready);
+ }
+
+ tr_type = dwc_otg_hcd_select_transactions(hcd);
+ if (tr_type != DWC_OTG_TRANSACTION_NONE)
+ dwc_otg_hcd_queue_transactions(hcd, tr_type);
+
+ /* Clear interrupt */
+ gintsts |= DWC_INTMSK_STRT_OF_FRM;
+ dwc_write32(gintsts_reg(hcd), gintsts);
+ return 1;
+}
+
+/**
+ * Handles the Rx Status Queue Level Interrupt, which indicates that there is
at
+ * least one packet in the Rx FIFO. The packets are moved from the FIFO to
+ * memory if the DWC_otg controller is operating in Slave mode.
+ */
+static int dwc_otg_hcd_handle_rx_status_q_level_intr(struct dwc_hcd *hcd)
+{
+ u32 grxsts;
+ struct dwc_hc *hc;
+
+ grxsts = dwc_read32(hcd->core_if->core_global_regs + DWC_GRXSTSP);
+ hc = hcd->hc_ptr_array[grxsts & DWC_HM_RXSTS_CHAN_NUM_RD(grxsts)];
+
+ /* Packet Status */
+ switch (DWC_HM_RXSTS_PKT_STS_RD(grxsts)) {
+ case DWC_GRXSTS_PKTSTS_IN:
+ /* Read the data into the host buffer. */
+ if (DWC_HM_RXSTS_BYTE_CNT_RD(grxsts) > 0)
[PATCH 07/14] dwc/otg: Add HCD queue function
From: Tirumala Marri
Implements functions to manage Queue Heads and Queue
Transfer Descriptors of DWC USB OTG Controller.
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
---
drivers/usb/dwc/hcd_queue.c | 696 +++
1 files changed, 696 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/hcd_queue.c
diff --git a/drivers/usb/dwc/hcd_queue.c b/drivers/usb/dwc/hcd_queue.c
new file mode 100644
index 000..1f99573
--- /dev/null
+++ b/drivers/usb/dwc/hcd_queue.c
@@ -0,0 +1,696 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld
+ * Modified by Stefan Roese , DENX Software Engineering
+ * Modified by Chuck Meade
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * This file contains the functions to manage Queue Heads and Queue
+ * Transfer Descriptors.
+ */
+
+#include "hcd.h"
+
+static inline int is_fs_ls(enum usb_device_speed speed)
+{
+ return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+/* Allocates memory for a QH structure. */
+static inline struct dwc_qh *dwc_otg_hcd_qh_alloc(void)
+{
+ return kmalloc(sizeof(struct dwc_qh), GFP_ATOMIC);
+}
+
+/**
+ * Initializes a QH structure to initialize the QH.
+ */
+#define SCHEDULE_SLOP 10
+static void dwc_otg_hcd_qh_init(struct dwc_hcd *hcd, struct dwc_qh *qh,
+ struct urb *urb)
+{
+ memset(qh, 0, sizeof(struct dwc_qh));
+
+ /* Initialize QH */
+ switch (usb_pipetype(urb->pipe)) {
+ case PIPE_CONTROL:
+ qh->ep_type = USB_ENDPOINT_XFER_CONTROL;
+ break;
+ case PIPE_BULK:
+ qh->ep_type = USB_ENDPOINT_XFER_BULK;
+ break;
+ case PIPE_ISOCHRONOUS:
+ qh->ep_type = USB_ENDPOINT_XFER_ISOC;
+ break;
+ case PIPE_INTERRUPT:
+ qh->ep_type = USB_ENDPOINT_XFER_INT;
+ break;
+ }
+
+ qh->ep_is_in = usb_pipein(urb->pipe) ? 1 : 0;
+ qh->data_toggle = DWC_OTG_HC_PID_DATA0;
+ qh->maxp = usb_maxpacket(urb->dev, urb->pipe, !(usb_pipein(urb->pipe)));
+
+ INIT_LIST_HEAD(&qh->qtd_list);
+ INIT_LIST_HEAD(&qh->qh_list_entry);
+
+ qh->channel = NULL;
+ qh->speed = urb->dev->speed;
+
+ /*
+* FS/LS Enpoint on HS Hub NOT virtual root hub
+*/
+ qh->do_split = 0;
+ if (is_fs_ls(urb->dev->speed) && urb->dev->tt && urb->dev->tt->hub &&
+ urb->dev->tt->hub->devnum != 1)
+ qh->do_split = 1;
+
+ if (qh->ep_type == USB_ENDPOINT_XFER_INT ||
+ qh->ep_type == USB_ENDPOINT_XFER_ISOC) {
+ /* Compute scheduling parameters once and save them. */
+ u32 hprt;
+ int bytecount = dwc_hb_mult(qh->maxp) *
+ dwc_max_packet(qh->maxp);
+
+ qh->usecs = NS_TO_US(usb_calc_bus_time(urb->dev->speed,
+ usb_pipein(urb->pipe),
+ (qh->ep_type ==
+ USB_ENDPOINT_XFER_ISOC),
+ bytecount));
+
+ /* Start in a slightly future (micro)frame. */
+ qh->sched_frame = dwc_frame_num_inc(hcd->frame_number,
+
[PATCH 13/14] usb/gadget/kconfig: added dwc otg as an option for peripheral controller
When dwc otg is configured as either dual or device only mode, then it can also be used as a usb gadget. So added dwc otg as an option for peripheral controller. Signed-off-by: Pratyush Anand --- drivers/usb/gadget/Kconfig | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 09fa211..ca0d83a 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -169,6 +169,23 @@ config USB_DESIGNWARE default USB_GADGET select USB_GADGET_SELECTED +config USB_GADGET_DESIGNWARE_OTG + boolean "Synopsys designware OTG Device Controller" + depends on DWC_OTG_MODE || DWC_DEVICE_ONLY + select USB_GADGET_DUALSPEED + help + This driver supports the OTG device synopsys controller. + Say "y" to link the driver statically, or "m" to build a + dynamically linked module called "spear_udc" and force all + gadget drivers to also be dynamically linked. + +config USB_DESIGNWARE_OTG + tristate + depends on USB_GADGET_DESIGNWARE_OTG + default USB_GADGET + select USB_GADGET_SELECTED + + config USB_GADGET_FSL_USB2 boolean "Freescale Highspeed USB DR Peripheral Controller" depends on FSL_SOC || ARCH_MXC -- 1.7.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 11/14] dwc/otg: Driver enable gadget support
Hello.
On 08/30/2011 03:57 PM, Pratyush Anand wrote:
From: Tirumala Marri
Enable gadget support
Signed-off-by: Tirumala R Marri
Signed-off-by: Fushen Chen
Signed-off-by: Mark Miesfeld
Signed-off-by: Pratyush Anand
---
drivers/usb/gadget/gadget_chips.h | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index 0978103..66b8018 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -148,6 +148,19 @@
#define gadget_is_s3c_hsotg(g)0
#endif
+#if defined(CONFIG_DWC_OTG_MODE) || defined(CONFIG_DWC_DEVICE_ONLY)
+#define gadget_is_dwc_otg_pcd(g) (!strcmp("dwc_otg_pcd", (g)->name))
+#else
+#define gadget_is_dwc_otg_pcd(g) 0
+#endif
+
+#ifdef CONFIG_USB_GADGET_CI13XXX_MSM
+#define gadget_is_ci13xxx_msm(g) (!strcmp("ci13xxx_msm", (g)->name))
+#else
+#define gadget_is_ci13xxx_msm(g) 0
+#endif
+
+
Too many newlines.
/**
* usb_gadget_controller_number - support bcdDevice id convention
@@ -208,10 +221,13 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x26;
else if (gadget_is_designware(gadget))
return 0x27;
+ else if (gadget_is_ci13xxx_msm(gadget))
+ return 0x28;
+ else if (gadget_is_dwc_otg_pcd(gadget))
+ return 0x29;
Hm, why are you adding 2 gadgets?
return -ENOENT;
}
-
Unrelated white space change.
/**
* gadget_supports_altsettings - return true if altsettings work
* @gadget: the gadget in question
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 12/14] include/linux/usb/gadget.h : include for successful compilation
Hello. On 08/30/2011 03:57 PM, Pratyush Anand wrote: gadget.h uses struct device, which has been declared in linux/device.h. So it must be included. Signed-off-by: Pratyush Anand --- include/linux/usb/gadget.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index 006412c..32f7b69 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -16,6 +16,7 @@ #define __LINUX_USB_GADGET_H #include +#include On what tree are you basing? There have been patches accepted in v3.1-rc1, which added a bunch of #include's to that file (including ). WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: VFIO v2 design plan
On Mon, Aug 29, 2011 at 10:24:43PM -0600, Alex Williamson wrote: > On Tue, 2011-08-30 at 13:04 +1000, David Gibson wrote: > > On Fri, Aug 26, 2011 at 11:05:23AM -0600, Alex Williamson wrote: > > > > > > I don't think too much has changed since the previous email went out, > > > but it seems like a good idea to post a summary in case there were > > > suggestions or objections that I missed. > > > > > > VFIO v2 will rely on the platform iommu driver reporting grouping > > > information. Again, a group is a set of devices for which the iommu > > > cannot differentiate transactions. An example would be a set of devices > > > behind a PCI-to-PCI bridge. All transactions appear to be from the > > > bridge itself rather than devices behind the bridge. Platforms are free > > > to have whatever constraints they need to for what constitutes a group. > > > > > > I posted a rough draft of patch to implement that for the base iommu > > > driver and VT-d, adding an iommu_device_group callback on iommu ops. > > > The iommu base driver also populates an iommu_group sysfs file for each > > > device that's part of a group. Members of the same group return the > > > same value via either the sysfs or iommu_device_group. The value > > > returned is arbitrary, should not be assumed to be persistent across > > > boots, and is left to the iommu driver to generate. There are some > > > implementation details around how to do this without favoring one bus > > > over another, but the interface should be bus/device type agnostic in > > > the end. > > > > > > When the vfio module is loaded, character devices will be created for > > > each group in /dev/vfio/$GROUP. Setting file permissions on these files > > > should be sufficient for providing a user with complete access to the > > > group. Opening this device file provides what we'll call the "group > > > fd". The group fd is restricted to only work with a single mm context. > > > Concurrent opens will be denied if the opening process mm does not > > > match. The group fd will provide interfaces for enumerating the devices > > > in the group, returning a file descriptor for each device in the group > > > (the "device fd"), binding groups together, and returning a file > > > descriptor for iommu operations (the "iommu fd"). > > > > > > A group is "viable" when all member devices of the group are bound to > > > the vfio driver. Until that point, the group fd only allows enumeration > > > interfaces (ie. listing of group devices). I'm currently thinking > > > enumeration will be done by a simple read() on the device file returning > > > a list of dev_name()s. > > > > Ok. Are you envisaging this interface as a virtual file, or as a > > stream? That is, can you seek around the list of devices like a > > regular file - in which case, what are the precise semantics when the > > list is changed by a bind - or is there no meaningful notion of file > > pointer and read() just gives you the next device - in which case how > > to you rewind to enumerate the group again. > > I was implementing it as a virtual file that gets generated on read() > (see example in note[2] below). It is a bit clunky as reading it a byte > at a time could experience races w/ device add/remove. If it's read all > at once, it's an accurate snapshot. Suggestions welcome, this just > seemed easier than trying to stuff it into a struct for an ioctl. For a > while I thought I could do a VFIO_GROUP_GET_NUM_DEVICES + > VFIO_GROUP_GET_DEVICE_INDEX, but that assumes device stability, which I > don't think we can guarantee. Yeah, that sounds reasonable. > > > Once the group is viable, the user may bind the > > > group to another group, retrieve the iommu fd, or retrieve device fds. > > > Internally, each of these operations will result in an iommu domain > > > being allocated and all of the devices attached to the domain. > > > > > > The purpose of binding groups is to share the iommu domain. Groups > > > making use of incompatible iommu domains will fail to bind. Groups > > > making use of different mm's will fail to bind. The vfio driver may > > > reject some binding based on domain capabilities, but final veto power > > > is left to the iommu driver[1]. If a user makes use of a group > > > independently and later wishes to bind it to another group, all the > > > device fds and the iommu fd must first be closed. This prevents using a > > > stale iommu fd or accessing devices while the iommu is being switched. > > > Operations on any group fds of a merged group are performed globally on > > > the group (ie. enumerating the devices lists all devices in the merged > > > group, retrieving the iommu fd from any group fd results in the same fd, > > > device fds from any group can be retrieved from any group fd[2]). > > > Groups can be merged and unmerged dynamically. Unmerging a group > > > requires the device fds for the outgoing group are closed. The iommu fd > > > will remain persistent for
