* Re: [RFC PATCH 03/10] fadump: Register for firmware assisted dump.
From: Anton Blanchard @ 2011-08-31 4:20 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Eric W. Biederman,
linuxppc-dev
In-Reply-To: <20110713180705.6210.44160.stgit@mars.in.ibm.com>
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_address : 0x%016Lx\n",
> + fdm->rmr_region.destination_address);
> +
> + DBG("--------Firmware-assisted dump memory structure---------\n");
> +}
> +
That's an awful lot of debug information. I don't think we need to carry
this around in the kernel once the feature is working.
> +static ssize_t fadump_enabled_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
> +}
> +
> +static ssize_t fadump_region_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf)
> +{
> + const struct fadump_mem_struct *fdm_ptr;
> + ssize_t n = 0;
> +
> + if (!fw_dump.fadump_enabled)
> + return n;
> +
> + if (fdm_active)
> + fdm_ptr = fdm_active;
> + else
> + fdm_ptr = &fdm;
> +
> + n += sprintf(buf,
> + "CPU : [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->cpu_state_data.destination_address,
> + fdm_ptr->cpu_state_data.destination_address +
> + fdm_ptr->cpu_state_data.source_len - 1,
> + fdm_ptr->cpu_state_data.source_len,
> + fdm_ptr->cpu_state_data.bytes_dumped);
> + n += sprintf(buf + n,
> + "HPTE: [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->hpte_region.destination_address,
> + fdm_ptr->hpte_region.destination_address +
> + fdm_ptr->hpte_region.source_len - 1,
> + fdm_ptr->hpte_region.source_len,
> + fdm_ptr->hpte_region.bytes_dumped);
> + n += sprintf(buf + n,
> + "DUMP: [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + fdm_ptr->rmr_region.destination_address,
> + fdm_ptr->rmr_region.destination_address +
> + fdm_ptr->rmr_region.source_len - 1,
> + fdm_ptr->rmr_region.source_len,
> + fdm_ptr->rmr_region.bytes_dumped);
> +
> + if (!fdm_active ||
> + (fw_dump.reserve_dump_area_start ==
> + fdm_ptr->cpu_state_data.destination_address))
> + return n;
> +
> + /* Dump is active. Show reserved memory region. */
> + n += sprintf(buf + n,
> + " : [%#016llx-%#016llx] %#llx bytes, "
> + "Dumped: %#llx\n",
> + (unsigned long long)fw_dump.reserve_dump_area_start,
> + fdm_ptr->cpu_state_data.destination_address - 1,
> + fdm_ptr->cpu_state_data.destination_address -
> + fw_dump.reserve_dump_area_start,
> + fdm_ptr->cpu_state_data.destination_address -
> + fw_dump.reserve_dump_area_start);
> + return n;
> +}
> +
> +static struct kobj_attribute fadump_attr = __ATTR(fadump_enabled,
> + 0444, fadump_enabled_show,
> + NULL);
> +static struct kobj_attribute fadump_region_attr = __ATTR(fadump_region,
> + 0444, fadump_region_show, NULL);
> +
> +static int fadump_init_sysfs(void)
> +{
> + int rc = 0;
> +
> + rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
> + if (rc)
> + printk(KERN_ERR "fadump: unable to create sysfs file"
> + " (%d)\n", rc);
> +
> + rc = sysfs_create_file(kernel_kobj, &fadump_region_attr.attr);
> + if (rc)
> + printk(KERN_ERR "fadump: unable to create sysfs file"
> + " (%d)\n", rc);
> + return rc;
> +}
> +subsys_initcall(fadump_init_sysfs);
Do we need to dump this all out via sysfs? Will tools depend on this,
or is it just for debug? It might be better to place in debugfs.
Anton
^ permalink raw reply
* Re: [RFC PATCH 05/10] fadump: Convert firmware-assisted cpu state dump data into elf notes.
From: Anton Blanchard @ 2011-08-31 4:23 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Eric W. Biederman,
linuxppc-dev
In-Reply-To: <20110713180722.6210.20251.stgit@mars.in.ibm.com>
> 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
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 01/15] [PS3] Add udbg driver using the PS3 gelic Ethernet device
From: Benjamin Herrenschmidt @ 2011-08-31 4:26 UTC (permalink / raw)
To: Andre Heider
Cc: cbe-oss-dev, Geoff Levand, Hector Martin, linuxppc-dev,
Arnd Bergmann
In-Reply-To: <CAHsu+b8e2eZZA_ogVP5fpsepWXGWw=dvJAAVCGD94rW3WdZj=w@mail.gmail.com>
On Thu, 2011-08-11 at 19:32 +0200, Andre Heider wrote:
> On Thu, Aug 11, 2011 at 2:13 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 04 August 2011, Geoff Levand wrote:
> >> > + *
> >> > + * udbg debug output routine via GELIC UDP broadcasts
> >> > + * Copyright (C) 2010 Hector Martin <hector@marcansoft.com>
> >> > + * Copyright (C) 2011 Andre Heider <a.heider@gmail.com>
> >>
> >> 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.
^ permalink raw reply
* Re: [PATCH part1 v2 0/9] ps3: General improvements and preparation for support more than the OtherOS lpar
From: Benjamin Herrenschmidt @ 2011-08-31 4:29 UTC (permalink / raw)
To: Andre Heider; +Cc: Geoff Levand, cbe-oss-dev, Hector Martin, linuxppc-dev
In-Reply-To: <1313091073-4572-1-git-send-email-a.heider@gmail.com>
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
>
^ permalink raw reply
* [PATCH] powerpc: Remove linkage for sys_nfsservctl system call
From: Kumar Gala @ 2011-08-31 4:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
The following commit didn't actually remove it from powerpc:
commit f5b940997397229975ea073679b03967932a541b
Author: NeilBrown <neilb@suse.de>
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 <galak@kernel.crashing.org>
---
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
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-08-31 6:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
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(-)
^ permalink raw reply
* Re: [PATCH 00/14] Modifications for DWC OTG since v13
From: Alexander Gordeev @ 2011-08-31 6:49 UTC (permalink / raw)
To: Kyungmin Park
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, rajeev-dlh.kumar,
bhupesh.sharma, Tirumala Marri, Pratyush Anand, vipin.kumar,
shiraz.hashim, Amit.VIRDI, linux-usb, Mark Miesfeld, deepak.sikri,
linuxppc-dev, Fushen Chen
In-Reply-To: <CAH9JG2WzpYgM0r+Zgf2cnL94-qG4XmVm3RxYqRRezHhMgeovYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]
Hi,
В Wed, 31 Aug 2011 10:18:42 +0900
Kyungmin Park <kmpark@infradead.org> пишет:
> On Wed, Aug 31, 2011 at 12:46 AM, Pratyush Anand
> <pratyush.anand@gmail.com> wrote:
> > On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri <tmarri@apm.com> wrote:
> >> <-----Original Message-----
> >> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
> >> <Sent: Tuesday, August 30, 2011 4:58 AM
> >> <To: linux-usb@vger.kernel.org
> >> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
> >> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
> >> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
> >> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
> >> <Anand
> >> <Subject: [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.
> >>
> >> [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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 00/14] Modifications for DWC OTG since v13
From: Pratyush Anand @ 2011-08-31 7:03 UTC (permalink / raw)
To: Kyungmin Park
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
Tirumala Marri, linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <CAH9JG2WzpYgM0r+Zgf2cnL94-qG4XmVm3RxYqRRezHhMgeovYQ@mail.gmail.com>
On Wed, Aug 31, 2011 at 6:48 AM, Kyungmin Park <kmpark@infradead.org> wrote=
:
> On Wed, Aug 31, 2011 at 12:46 AM, Pratyush Anand
> <pratyush.anand@gmail.com> wrote:
>> On Tue, Aug 30, 2011 at 8:57 PM, Tirumala Marri <tmarri@apm.com> wrote:
>>> <-----Original Message-----
>>> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
>>> <Sent: Tuesday, August 30, 2011 4:58 AM
>>> <To: linux-usb@vger.kernel.org
>>> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
>>> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
>>> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
>>> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyus=
h
>>> <Anand
>>> <Subject: [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.
>>>
>>> [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 rele=
ase.
>> I thought no one is maintaining., and so I sent them with my modificatio=
ns,
>> after testing them in all dev/host/otg mode.
>>
>> Regards
>> Pratyush
>
> Hi,
>
> Can you provide the git repo to test?
Currently, these patches are also in circulation for internal reviews.
Once reviewed internally, will push them to git repo and will let you know.
> 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.
>
dwc3 is for " DesignWare USB3 DRD Controller Core "
these patches are for "DesignWare USB2.0 High Speed OTG Controller"
Regards
Pratyush
> Thank you,
> Kyungmin Park
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: [PATCH 03/14] dwc/otg: Add driver framework
From: Sebastian Andrzej Siewior @ 2011-08-31 7:19 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, linux-usb,
vipin.kumar, shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar,
mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <73a8a4be221e3bc0404da22473913e9a846ee0df.1314704557.git.pratyush.anand@st.com>
* Pratyush Anand | 2011-08-30 17:27:50 [+0530]:
>diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
>new file mode 100644
>index 0000000..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 <mmiesfeld@apm.com>
>+ * Modified by Stefan Roese <sr@denx.de>, 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.
>+ *
>+ */
In every file...
>+/*
>+ * 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 <linux/platform_device.h>
>+
>+#include "driver.h"
>+
>+#define DWC_DRIVER_VERSION "1.05"
do you intend to increment this version number?
>+#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 when a device is unregistered with the
>+ * dwc_otg_driver. This happens, for example, when the rmmod command is
>+ * executed. The device may or may not be electrically present. If it is
>+ * present, the driver stops device processing. Any resources used on behalf
>+ * of this device are freed.
>+ */
>+static int __devexit dwc_otg_driver_remove(struct platform_device *ofdev)
>+{
>+ struct device *dev = &ofdev->dev;
>+ struct dwc_otg_device *dwc_dev = dev_get_drvdata(dev);
>+
>+ /* Memory allocation for dwc_otg_device may have failed. */
>+ if (!dwc_dev)
>+ return 0;
>+
>+ /* Free the IRQ */
>+ if (dwc_dev->common_irq_installed)
>+ free_irq(dwc_dev->irq, dwc_dev);
>+
>+ if (!dwc_has_feature(dwc_dev->core_if, DWC_DEVICE_ONLY)) {
>+ if (dwc_dev->hcd) {
>+ if (dwc_dev->hcd->cp_irq_installed)
>+ free_irq(dwc_dev->hcd->cp_irq, dwc_dev);
>+ dwc_otg_hcd_remove(dev);
>+ }
>+ }
>+
>+ if (!dwc_has_feature(dwc_dev->core_if, DWC_HOST_ONLY)) {
>+ if (dwc_dev->pcd)
>+ dwc_otg_pcd_remove(dev);
>+ }
>+
>+ if (dwc_dev->core_if)
>+ dwc_otg_cil_remove(dwc_dev->core_if);
>+
>+ /* Return the memory. */
>+ if (dwc_dev->base)
>+ iounmap(dwc_dev->base);
>+
>+ if (dwc_dev->phys_addr)
>+ release_mem_region(dwc_dev->phys_addr, dwc_dev->base_len);
>+
>+ if (dwc_dev->core_if->xceiv) {
>+ otg_put_transceiver(dwc_dev->core_if->xceiv);
>+ dwc_dev->core_if->xceiv = NULL;
>+ usb_nop_xceiv_unregister();
>+ }
>+
>+ kfree(dwc_dev);
>+
>+ /* Clear the drvdata pointer. */
>+ dev_set_drvdata(dev, NULL);
>+ return 0;
>+}
>+
>+/**
>+ * This function is called when an device is bound to a
>+ * dwc_otg_driver. It creates the driver components required to
>+ * control the device (CIL, HCD, and PCD) and it initializes the
>+ * device. The driver components are stored in a dwc_otg_device
>+ * structure. A reference to the dwc_otg_device is saved in the
>+ * device. This allows the driver to access the dwc_otg_device
>+ * structure on subsequent calls to driver methods for this device.
>+ */
This is almost kernel doc. Mind doing a proper kernel doc?
>+static int __devinit dwc_otg_driver_probe(struct platform_device *ofdev)
>+{
>+ int retval;
>+ struct dwc_otg_device *dwc_dev;
>+ struct device *dev = &ofdev->dev;
>+ struct resource *res;
>+ struct dwc_otg_plat_data *pdata;
>+ ulong gusbcfg_addr;
>+ u32 usbcfg = 0;
>+
>+ dev_dbg(dev, "dwc_otg_driver_probe(%p)\n", dev);
__func__, but do you really care?
>+ dwc_dev = kzalloc(sizeof(*dwc_dev), GFP_KERNEL);
>+ if (!dwc_dev) {
>+ dev_err(dev, "kmalloc of dwc_otg_device failed\n");
>+ retval = -ENOMEM;
>+ goto fail_dwc_dev;
>+ }
>+
>+ /* Retrieve the memory and IRQ resources. */
Most people can read C
>+ dwc_dev->irq = platform_get_irq(ofdev, 0);
>+ if (dwc_dev->irq == NO_IRQ) {
>+ dev_err(dev, "no device irq\n");
>+ retval = -ENODEV;
>+ goto fail_of_irq;
>+ }
>+ dev_dbg(dev, "OTG - device irq: %d\n", dwc_dev->irq);
>+
>+ res = platform_get_resource(ofdev, IORESOURCE_MEM, 0);
>+ if (!res) {
>+ dev_err(dev, "%s: Can't get USB-OTG register address\n",
>+ __func__);
>+ retval = -ENOMEM;
>+ goto fail_of_irq;
>+ }
>+ dev_dbg(dev, "OTG - ioresource_mem start0x%llx: end:0x%llx\n",
>+ (unsigned long long)res->start, (unsigned long long)res->end);
>+
>+ dwc_dev->phys_addr = res->start;
>+ dwc_dev->base_len = res->end - res->start + 1;
>+ if (!request_mem_region(dwc_dev->phys_addr,
>+ dwc_dev->base_len, dwc_driver_name)) {
>+ dev_err(dev, "request_mem_region failed\n");
>+ retval = -EBUSY;
>+ goto fail_of_irq;
>+ }
>+
>+ /* Map the DWC_otg Core memory into virtual address space. */
>+ dwc_dev->base = ioremap(dwc_dev->phys_addr, dwc_dev->base_len);
>+ if (!dwc_dev->base) {
>+ dev_err(dev, "ioremap() failed\n");
>+ retval = -ENOMEM;
>+ goto fail_ioremap;
>+ }
>+ dev_dbg(dev, "mapped base=0x%08x\n", (__force u32)dwc_dev->base);
>+
>+ pdata = dev_get_platdata(dev);
>+ if (pdata) {
>+ if (pdata->phy_init)
>+ pdata->phy_init();
>+ if (pdata->param_init)
>+ pdata->param_init(&dwc_otg_module_params);
>+ }
>+
>+ /*
>+ * Initialize driver data to point to the global DWC_otg
>+ * Device structure.
>+ */
>+ dev_set_drvdata(dev, dwc_dev);
>+
>+ dwc_dev->core_if =
>+ dwc_otg_cil_init(dwc_dev->base, &dwc_otg_module_params);
>+ if (!dwc_dev->core_if) {
>+ dev_err(dev, "CIL initialization failed!\n");
>+ retval = -ENOMEM;
>+ goto fail_cil_init;
>+ }
>+
>+ /*
>+ * Validate parameter values after dwc_otg_cil_init.
>+ */
Single line would do it.
>+ if (check_parameters(dwc_dev->core_if)) {
>+ retval = -EINVAL;
>+ goto fail_check_param;
>+ }
>+
>+ usb_nop_xceiv_register();
>+ dwc_dev->core_if->xceiv = otg_get_transceiver();
>+ if (!dwc_dev->core_if->xceiv) {
>+ retval = -ENODEV;
>+ goto fail_xceiv;
>+ }
>+ dwc_set_feature(dwc_dev->core_if);
>+
>+ /* Initialize the DWC_otg core. */
>+ dwc_otg_core_init(dwc_dev->core_if);
>+
>+ /*
>+ * Disable the global interrupt until all the interrupt
>+ * handlers are installed.
>+ */
>+ dwc_otg_disable_global_interrupts(dwc_dev->core_if);
>+
>+ /*
>+ * Install the interrupt handler for the common interrupts before
>+ * enabling common interrupts in core_init below.
>+ */
>+ retval = request_irq(dwc_dev->irq, dwc_otg_common_irq,
>+ IRQF_SHARED, "dwc_otg", dwc_dev);
>+ if (retval) {
>+ dev_err(dev, "request of irq%d failed retval: %d\n",
>+ dwc_dev->irq, retval);
>+ retval = -EBUSY;
>+ goto fail_req_irq;
>+ } else {
>+ dwc_dev->common_irq_installed = 1;
>+ }
>+
>+ gusbcfg_addr = (ulong) (dwc_dev->core_if->core_global_regs)
>+ + DWC_GUSBCFG;
This looks wrong. If this is a virtual pointer (i.e. from ioremap()) it
should have the type "__iomem void *" and never be casted to something
else.
>+ if (dwc_has_feature(dwc_dev->core_if, DWC_DEVICE_ONLY)) {
>+ usbcfg = dwc_read32(gusbcfg_addr);
>+ usbcfg &= ~DWC_USBCFG_FRC_HST_MODE;
>+ usbcfg |= DWC_USBCFG_FRC_DEV_MODE;
>+ dwc_write32(gusbcfg_addr, usbcfg);
>+ }
>+
>+ if (!dwc_has_feature(dwc_dev->core_if, DWC_HOST_ONLY)) {
>+ /* Initialize the PCD */
>+ retval = dwc_otg_pcd_init(dev);
>+ if (retval) {
>+ dev_err(dev, "dwc_otg_pcd_init failed\n");
>+ dwc_dev->pcd = NULL;
>+ goto fail_req_irq;
>+ }
>+ }
>+
>+ if (dwc_has_feature(dwc_dev->core_if, DWC_HOST_ONLY)) {
>+ /* Initialize the HCD and force_host_mode */
>+ usbcfg = dwc_read32(gusbcfg_addr);
>+ usbcfg |= DWC_USBCFG_FRC_HST_MODE;
>+ usbcfg &= ~DWC_USBCFG_FRC_DEV_MODE;
>+ dwc_write32(gusbcfg_addr, usbcfg);
>+ }
>+
>+ if (!dwc_has_feature(dwc_dev->core_if, DWC_DEVICE_ONLY)) {
>+ /* update transiver state */
>+ dwc_dev->core_if->xceiv->state = OTG_STATE_A_HOST;
>+
>+ retval = dwc_otg_hcd_init(dev, dwc_dev);
>+ if (retval) {
>+ dev_err(dev, "dwc_otg_hcd_init failed\n");
>+ dwc_dev->hcd = NULL;
>+ goto fail_hcd;
>+ }
>+ /* configure chargepump interrupt */
>+ dwc_dev->hcd->cp_irq = platform_get_irq(ofdev, 1);
>+ if (dwc_dev->hcd->cp_irq != -ENXIO) {
>+ retval = request_irq(dwc_dev->hcd->cp_irq,
>+ dwc_otg_externalchgpump_irq,
>+ IRQF_SHARED,
>+ "dwc_otg_ext_chg_pump", dwc_dev);
>+ if (retval) {
>+ dev_err(dev,
>+ "request of irq failed retval: %d\n",
>+ retval);
>+ retval = -EBUSY;
>+ goto fail_hcd;
>+ } else {
>+ dev_dbg(dev, "%s: ExtChgPump Detection "
>+ "IRQ registered\n", dwc_driver_name);
>+ dwc_dev->hcd->cp_irq_installed = 1;
>+ }
>+ }
>+ }
>+ /*
>+ * Enable the global interrupt after all the interrupt
>+ * handlers are installed.
>+ */
>+ dwc_otg_enable_global_interrupts(dwc_dev->core_if);
>+ return 0;
>+fail_hcd:
>+ free_irq(dwc_dev->irq, dwc_dev);
>+ if (!dwc_has_feature(dwc_dev->core_if, DWC_HOST_ONLY)) {
>+ if (dwc_dev->pcd)
>+ dwc_otg_pcd_remove(dev);
>+ }
>+fail_req_irq:
>+ otg_put_transceiver(dwc_dev->core_if->xceiv);
>+fail_xceiv:
>+ usb_nop_xceiv_unregister();
>+fail_check_param:
>+ dwc_otg_cil_remove(dwc_dev->core_if);
>+fail_cil_init:
>+ dev_set_drvdata(dev, NULL);
>+ iounmap(dwc_dev->base);
>+fail_ioremap:
>+ release_mem_region(dwc_dev->phys_addr, dwc_dev->base_len);
>+fail_of_irq:
>+ kfree(dwc_dev);
>+fail_dwc_dev:
>+ return retval;
>+}
>+
>+/*
>+ * This structure defines the methods to be called by a bus driver
>+ * during the lifecycle of a device on that bus. Both drivers and
>+ * devices are registered with a bus driver. The bus driver matches
>+ * devices to drivers based on information in the device and driver
>+ * structures.
>+ *
>+ * The probe function is called when the bus driver matches a device
>+ * to this driver. The remove function is called when a device is
>+ * unregistered with the bus driver.
>+ */
>+
>+#if defined(CONFIG_OF)
>+static const struct of_device_id dwc_otg_match[] = {
>+ {.compatible = "amcc,dwc-otg",},
Do you explain this binding somewhere? I.e. additional properties and
so? If so ignore this, I will find it :)
>+ {}
>+};
>+MODULE_DEVICE_TABLE(of, dwc_otg_match);
>+#endif
>+
>+static struct platform_driver dwc_otg_driver = {
>+ .probe = dwc_otg_driver_probe,
>+ .remove = __devexit_p(dwc_otg_driver_remove),
>+ .driver = {
>+ .name = "dwc_otg",
>+ .owner = THIS_MODULE,
>+#if defined(CONFIG_OF)
>+ .of_match_table = dwc_otg_match,
>+#endif
ifdef CONFIG_OF is not required at all.
>+ },
>+};
>+
>+/**
>+ * This function is called when the dwc_otg_driver is installed with the
>+ * insmod command. It registers the dwc_otg_driver structure with the
>+ * appropriate bus driver. This will cause the dwc_otg_driver_probe function
>+ * to be called. In addition, the bus driver will automatically expose
>+ * attributes defined for the device and driver in the special sysfs file
>+ * system.
>+ */
>+static int __init dwc_otg_driver_init(void)
>+{
>+
>+ pr_info("%s: version %s\n", dwc_driver_name, DWC_DRIVER_VERSION);
>+ return platform_driver_register(&dwc_otg_driver);
>+}
>+
>+module_init(dwc_otg_driver_init);
>+
>+/**
>+ * This function is called when the driver is removed from the kernel
>+ * with the rmmod command. The driver unregisters itself with its bus
>+ * driver.
>+ *
>+ */
>+static void __exit dwc_otg_driver_cleanup(void)
>+{
>+ platform_driver_unregister(&dwc_otg_driver);
>+}
>+
>+module_exit(dwc_otg_driver_cleanup);
>+
>+MODULE_DESCRIPTION(DWC_DRIVER_DESC);
>+MODULE_AUTHOR("Mark Miesfeld <mmiesfeld@apm.com");
>+MODULE_LICENSE("GPL");
>diff --git a/drivers/usb/dwc/driver.h b/drivers/usb/dwc/driver.h
>new file mode 100644
>index 0000000..a86532b
>--- /dev/null
>+++ b/drivers/usb/dwc/driver.h
>@@ -0,0 +1,76 @@
>+/*
>+ * 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 <mmiesfeld@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.
>+ *
>+ */
>+
>+#if !defined(__DWC_OTG_DRIVER_H__)
>+#define __DWC_OTG_DRIVER_H__
>+
>+/*
>+ * This file contains the interface to the Linux driver.
>+ */
>+#include "cil.h"
Oh, onion layers? Will check, never mind.
>+/*
>+ * This structure is a wrapper that encapsulates the driver components used to
>+ * manage a single DWC_otg controller.
>+ */
>+struct dwc_otg_device {
>+ /* Base address returned from ioremap() */
>+ __iomem void *base;
>+
>+ /* Pointer to the core interface structure. */
>+ struct core_if *core_if;
>+
>+ /* Pointer to the PCD structure. */
>+ struct dwc_pcd *pcd;
>+
>+ /* Pointer to the HCD structure. */
>+ struct dwc_hcd *hcd;
>+
>+ /* Flag to indicate whether the common IRQ handler is installed. */
>+ u8 common_irq_installed;
please correct if I'm wring but it seems the only reason when this is
not set is in an error case. In this case the driver is not loaded. So
why do we have this here?
>+
>+ /* Interrupt request number. */
>+ unsigned int irq;
>+
>+ /*
>+ * Physical address of Control and Status registers, used by
>+ * release_mem_region().
>+ */
>+ resource_size_t phys_addr;
If this is a physical address it should phys_addr_t.
>+
>+ /* Length of memory region, used by release_mem_region(). */
>+ unsigned long base_len;
this should be resource_size_t. But why are you collecting all this
informations? You need it just for probe and remove right? Wouldn't it
be easier to grab it again from platoform_device?
>+};
>+#endif
>diff --git a/drivers/usb/dwc/param.c b/drivers/usb/dwc/param.c
>new file mode 100644
>index 0000000..b9fcfa3
>--- /dev/null
>+++ b/drivers/usb/dwc/param.c
>@@ -0,0 +1,219 @@
>+/*
>+ * 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 <mmiesfeld@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.
>+ *
>+ */
>+
>+/*
>+ * This file provides dwc_otg driver parameter and parameter checking.
>+ */
>+
>+#include "cil.h"
>+
>+/*
>+ * Encapsulate the module parameter settings
>+ */
>+struct core_params dwc_otg_module_params = {
>+ .otg_cap = dwc_param_otg_cap_default,
>+ .dma_enable = dwc_param_dma_enable_default,
>+ .dma_burst_size = dwc_param_dma_burst_size_default,
>+ .speed = dwc_param_speed_default,
>+ .host_support_fs_ls_low_power
>+ = dwc_param_host_support_fs_ls_low_power_default,
>+ .host_ls_low_power_phy_clk
>+ = dwc_param_host_ls_low_power_phy_clk_default,
>+ .enable_dynamic_fifo = -1,
>+ .dev_rx_fifo_size = -1,
>+ .dev_nperio_tx_fifo_size = -1,
>+ .dev_perio_tx_fifo_size = {-1, -1, -1, -1, -1, -1, -1, -1,
>+ -1, -1, -1, -1, -1, -1, -1}, /* 15 */
>+ .host_rx_fifo_size = -1,
>+ .host_nperio_tx_fifo_size = -1,
>+ .host_perio_tx_fifo_size = -1,
>+ .max_transfer_size = -1,
>+ .max_packet_count = -1,
>+ .host_channels = -1,
>+ .dev_endpoints = -1,
>+ .phy_type = dwc_param_phy_type_default,
>+ .phy_utmi_width = dwc_param_phy_utmi_width_default,
>+ .phy_ulpi_ddr = dwc_param_phy_ulpi_ddr_default,
>+ .phy_ulpi_ext_vbus = dwc_param_phy_ulpi_ext_vbus_default,
>+ .i2c_enable = dwc_param_i2c_enable_default,
>+ .ulpi_fs_ls = dwc_param_ulpi_fs_ls_default,
>+ .ts_dline = dwc_param_ts_dline_default,
>+ .en_multiple_tx_fifo = -1,
>+ .dev_tx_fifo_size = {-1, -1, -1, -1, -1, -1, -1, -1, -1,
>+ -1, -1, -1, -1, -1, -1}, /* 15 */
>+ .fifo_number = MAX_TX_FIFOS,
>+ .thr_ctl = dwc_param_thr_ctl_default,
>+ .tx_thr_length = dwc_param_tx_thr_length_default,
>+ .rx_thr_length = dwc_param_rx_thr_length_default,
>+};
>+
>+/**
>+ * Checks that parameter settings for the periodic Tx FIFO sizes are correct
>+ * according to the hardware configuration. Sets the size to the hardware
>+ * configuration if an incorrect size is detected.
>+ */
>+static int set_valid_perio_tx_fifo_sizes(struct core_if *core_if)
>+{
>+ ulong regs = (u32) core_if->core_global_regs;
>+ u32 *param_size = &dwc_otg_module_params.dev_perio_tx_fifo_size[0];
>+ u32 i, size;
>+
>+ for (i = 0; i < dwc_otg_module_params.fifo_number; i++) {
>+ if (param_size[i] == -1) {
>+ size = dwc_read32(regs + DWC_DPTX_FSIZ_DIPTXF(i));
>+ param_size[i] = DWC_TX_FIFO_DEPTH_RD(size);
>+ }
>+ }
>+ return 0;
>+}
>+
>+/**
>+ * Checks that parameter settings for the Tx FIFO sizes are correct according to
>+ * the hardware configuration. Sets the size to the hardware configuration if
>+ * an incorrect size is detected.
>+ */
>+static int set_valid_tx_fifo_sizes(struct core_if *core_if)
>+{
>+ ulong regs = (u32) core_if->core_global_regs;
>+ u32 *param_size = &dwc_otg_module_params.dev_tx_fifo_size[0];
>+ u32 i, size;
>+
>+ for (i = 0; i < dwc_otg_module_params.fifo_number; i++) {
>+ if (param_size[i] == -1) {
>+ size = dwc_read32(regs + DWC_DPTX_FSIZ_DIPTXF(i));
>+ param_size[i] = DWC_TX_FIFO_DEPTH_RD(size);
>+ }
>+ }
>+ return 0;
>+}
>+
>+/**
>+ * This function is called during module intialization to verify that
>+ * the module parameters are in a valid state.
>+ */
>+int __devinit check_parameters(struct core_if *core_if)
>+{
>+ int size;
>+
>+ /* Hardware read only configurations of the OTG core. */
>+ dwc_otg_module_params.enable_dynamic_fifo =
>+ DWC_HWCFG2_DYN_FIFO_RD(core_if->hwcfg2);
>+ dwc_otg_module_params.max_transfer_size =
>+ (1 << (DWC_HWCFG3_XFERSIZE_CTR_WIDTH_RD(core_if->hwcfg3) + 11))
>+ - 1;
>+ dwc_otg_module_params.max_packet_count =
>+ (1 << (DWC_HWCFG3_PKTSIZE_CTR_WIDTH_RD(core_if->hwcfg3) + 4))
>+ - 1;
>+ dwc_otg_module_params.host_channels =
>+ DWC_HWCFG2_NO_HST_CHAN_RD(core_if->hwcfg2) + 1;
>+ dwc_otg_module_params.dev_endpoints =
>+ DWC_HWCFG2_NO_DEV_EP_RD(core_if->hwcfg2);
>+ dwc_otg_module_params.en_multiple_tx_fifo =
>+ (DWC_HWCFG4_DED_FIFO_ENA_RD(core_if->hwcfg4) == 0)
>+ ? 0 : 1, 0;
>+
>+ /*
>+ * Hardware read/write configurations of the OTG core.
>+ * If not defined by platform then read it from HW itself
>+ */
>+ if (dwc_otg_module_params.dev_rx_fifo_size == -1)
>+ dwc_otg_module_params.dev_rx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GRXFSIZ);
>+
>+ if (dwc_otg_module_params.dev_nperio_tx_fifo_size == -1) {
>+ size = dwc_read32(core_if->core_global_regs + DWC_GNPTXFSIZ);
>+ dwc_otg_module_params.dev_nperio_tx_fifo_size =
>+ DWC_TX_FIFO_DEPTH_RD(size);
>+ }
>+
>+ if (dwc_otg_module_params.en_multiple_tx_fifo)
>+ set_valid_tx_fifo_sizes(core_if);
>+ else
>+ set_valid_perio_tx_fifo_sizes(core_if);
>+
>+ if (dwc_otg_module_params.host_rx_fifo_size == -1)
>+ dwc_otg_module_params.host_rx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GRXFSIZ);
>+ if (dwc_otg_module_params.host_nperio_tx_fifo_size == -1) {
>+ size
>+ = dwc_read32(core_if->core_global_regs + DWC_GNPTXFSIZ) >> 16;
>+ dwc_otg_module_params.host_nperio_tx_fifo_size =
>+ DWC_TX_FIFO_DEPTH_RD(size);
>+ }
>+ if (dwc_otg_module_params.host_perio_tx_fifo_size == -1) {
>+ size =
>+ dwc_read32(core_if->core_global_regs + DWC_HPTXFSIZ) >> 16;
>+ dwc_otg_module_params.host_perio_tx_fifo_size =
>+ DWC_TX_FIFO_DEPTH_RD(size);
>+ }
>+
>+ /*
>+ * Hardware read/write configurations of the OTG core.
>+ * If not defined by platform then read it from HW itself
>+ * If defined by platform then write the same value in HW regs
>+ */
>+ if (dwc_otg_module_params.dev_rx_fifo_size == -1)
>+ dwc_otg_module_params.dev_rx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GRXFSIZ);
>+ else
>+ dwc_write32(core_if->core_global_regs + DWC_GRXFSIZ,
>+ dwc_otg_module_params.dev_rx_fifo_size);
>+
>+ if (dwc_otg_module_params.dev_nperio_tx_fifo_size == -1)
>+ dwc_otg_module_params.dev_nperio_tx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GNPTXFSIZ) >> 16;
>+ else
>+ dwc_write32(core_if->core_global_regs + DWC_GNPTXFSIZ,
>+ (dwc_otg_module_params.dev_rx_fifo_size |
>+ (dwc_otg_module_params.dev_nperio_tx_fifo_size << 16)));
>+
>+ set_valid_perio_tx_fifo_sizes(core_if);
>+ set_valid_tx_fifo_sizes(core_if);
>+
>+ if (dwc_otg_module_params.host_rx_fifo_size == -1)
>+ dwc_otg_module_params.host_rx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GRXFSIZ);
>+ if (dwc_otg_module_params.host_nperio_tx_fifo_size == -1)
>+ dwc_otg_module_params.host_nperio_tx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_GNPTXFSIZ) >> 16;
>+ if (dwc_otg_module_params.host_perio_tx_fifo_size == -1)
>+ dwc_otg_module_params.host_perio_tx_fifo_size =
>+ dwc_read32(core_if->core_global_regs + DWC_HPTXFSIZ) >> 16;
oh boy, oh boy. This is a huge number of module parameters. Do you
actually expect someone setting all of them on modprobe? And if udev is
faster you rmmod and modpobe again, right? The clever ones would enter
it somewhere in modprobe.conf or so. Anyway. Since you have
already device tree bindings and I assume you are using them, why not
move all this parameters into the device and remove _all_ module
parameters?
>+ return 0;
>+}
>+
>+module_param_named(dma_enable, dwc_otg_module_params.dma_enable, bool, 0444);
>+MODULE_PARM_DESC(dma_enable, "DMA Mode 0=Slave 1=DMA enabled");
Sebastian
^ permalink raw reply
* Re: [PATCH 14/14] arm/include/asm/io.h : added macros to read/write big/little endian register
From: Sebastian Andrzej Siewior @ 2011-08-31 7:35 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, linux-usb,
vipin.kumar, shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar,
mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <335243c9467c0127206234819a94c9f72358fdf2.1314704558.git.pratyush.anand@st.com>
* Pratyush Anand | 2011-08-30 17:28:01 [+0530]:
>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))
In LE-mode __le32_to_cpu() is NOP and you get a LE value.
In BE-mode readl() will swap a and le32_to_cpu will swap a again. So you
get a BE value. Is this what you want?
>+
Please split this patch out and get it accepterd by ARM community. USB
people won't merge this.
Sebastian
^ permalink raw reply
* Re: [PATCH 08/14] dwc/otg: Add PCD function
From: Sebastian Andrzej Siewior @ 2011-08-31 7:44 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, linux-usb,
vipin.kumar, shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar,
mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <1b982bbcef0019d506c79ab90621ffe7744751b4.1314704558.git.pratyush.anand@st.com>
* Pratyush Anand | 2011-08-30 17:27:55 [+0530]:
>diff --git a/drivers/usb/dwc/pcd.c b/drivers/usb/dwc/pcd.c
>new file mode 100644
>index 0000000..2ef6405
>--- /dev/null
>+++ b/drivers/usb/dwc/pcd.c
>+static const struct usb_gadget_ops dwc_otg_pcd_ops = {
>+ .get_frame = dwc_otg_pcd_get_frame,
>+ .wakeup = dwc_otg_pcd_wakeup,
You may want to provide udc_start and udc_stop hooks.
drivers/usb/dwc3/gadget.c and drivers/usb/musb/musb_gadget.c are two
driver which are using it. The other gadget are using .start and .stop
hooks which I would like to go.
>+ /* not selfpowered */
>+};
>+
>+/**
>+ * This function registers a gadget driver with the PCD.
>+ *
>+ * When a driver is successfully registered, it will receive control
>+ * requests including set_configuration(), which enables non-control
>+ * requests. then usb traffic follows until a disconnect is reported.
>+ * then a host may connect again, or the driver might get unbound.
>+ */
>+int usb_gadget_probe_driver(struct usb_gadget_driver *driver,
>+ int (*bind) (struct usb_gadget *))
You can not provide usb_gadget_probe_driver() anymore. That is why you
need to provide those hooks I mentioned.
Sebastian
^ permalink raw reply
* Re: [v3 PATCH 1/1] booke/kprobe: make program exception to use one dedicated exception stack
From: tiejun.chen @ 2011-08-31 9:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <1314683064.2488.76.camel@pasglop>
Benjamin Herrenschmidt wrote:
>>> As I understand it, the problem comes from the fact that stwu combines the
>>> creation of a stack frame with storing into that stack frame. If they were
>> Yes.
>>
>>> separate instructions you'd have a new exception frame at a lower address
>>> by the time you actually store to the non-exception frame.
>> So when kprobe we should use a unique stack frame to skip that stack frame the
>> kprobed stwu want to create.
>
> I still don't like that patch. Potentially the problem exist for all
> variants of powerpc, not just booke, and I'm not sure I like adding yet
Yes.
> another exception stack.
But I think we should extend easily this for other powerpc variants. And only
when enable CONFIG_KPROBES that dedicated exception stack is valid, so its not
such a big risk :)
>
> Another (non-great) approach would be to special case stwu to the stack,
> and instead of doing the store while emulating the instruction, keep the
> store address around and do it later, after the stack has been unwound,
> in the exit path (a TIF flag to hit the slow path and then do it in the
> slow path).
Actually I also considered one idea that we do stw-update in the exit path like
your proposal. But I'm not sure if its worth intruding a new TIF flag only for
'stwu'. And if I understand what your exit path means properly, we should do
this on ret_from_except_full,
...
exc_exit_restart:
lwz r11,_NIP(r1)
lwz r12,_MSR(r1)
Looks we have to add something to update as 'stwu' since _NIP/_MSR are also
corrupted potentially. So I feel we'll make this complicated if we really do here.
exc_exit_start:
mtspr SPRN_SRR0,r11
mtspr SPRN_SRR1,r12
REST_2GPRS(11, r1)
lwz r1,GPR1(r1)
.globl exc_exit_restart_end
exc_exit_restart_end:
PPC405_ERR77_SYNC
rfi
b . /* prevent prefetch past rfi */
If I'm wrong please correct me.
>
> It sounds hackish but it makes it easier to fix everybody at once, there
> are "issues" with changing stacks especially on ppc64 and it would
> definitely be affected as well if the stack frame created is larger than
> our gap.
If we provide another exception stack like we did debug exception on ppc64, are
there those "issues" you said?
Thanks
Tiejun
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* [PATCH] [ps3] Add gelic udbg driver
From: Geoff Levand @ 2011-08-31 16:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: cbe-oss-dev, Andre Heider, linuxppc-dev, Hector Martin
In-Reply-To: <4E541344.5010802@infradead.org>
From: Hector Martin <hector@marcansoft.com>
Add a new udbg driver for the PS3 gelic Ehthernet device.
This driver shares only a few stucture and constant definitions with the
gelic Ethernet device driver, so is implemented as a stand-alone driver
with no dependencies on the gelic Ethernet device driver.
Signed-off-by: Hector Martin <hector@marcansoft.com>
Signed-off-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/powerpc/Kconfig.debug | 8 +
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
arch/powerpc/platforms/ps3/Kconfig | 12 ++
arch/powerpc/platforms/ps3/Makefile | 1 +
arch/powerpc/platforms/ps3/gelic_udbg.c | 273 +++++++++++++++++++++++++++++++
drivers/net/ps3_gelic_net.c | 3 +
drivers/net/ps3_gelic_net.h | 6 +
8 files changed, 306 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/ps3/gelic_udbg.c
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 067cb84..ab2335f 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -258,6 +258,14 @@ config PPC_EARLY_DEBUG_WSP
depends on PPC_WSP
select PPC_UDBG_16550
+config PPC_EARLY_DEBUG_PS3GELIC
+ bool "Early debugging through the PS3 Ethernet port"
+ depends on PPC_PS3
+ select PS3GELIC_UDBG
+ help
+ Select this to enable early debugging for the PlayStation3 via
+ UDP broadcasts sent out through the Ethernet port.
+
endchoice
config PPC_EARLY_DEBUG_HVSI_VTERMNO
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 93e05d1..7cf796f 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -54,6 +54,7 @@ extern void __init udbg_init_40x_realmode(void);
extern void __init udbg_init_cpm(void);
extern void __init udbg_init_usbgecko(void);
extern void __init udbg_init_wsp(void);
+extern void __init udbg_init_ps3gelic(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index faa82c1..5b3e98e 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -67,6 +67,8 @@ void __init udbg_early_init(void)
udbg_init_usbgecko();
#elif defined(CONFIG_PPC_EARLY_DEBUG_WSP)
udbg_init_wsp();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_PS3GELIC)
+ udbg_init_ps3gelic();
#endif
#ifdef CONFIG_PPC_EARLY_DEBUG
diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig
index dfe316b..476d9d9 100644
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -148,4 +148,16 @@ config PS3_LPM
profiling support of the Cell processor with programs like
oprofile and perfmon2, then say Y or M, otherwise say N.
+config PS3GELIC_UDBG
+ bool "PS3 udbg output via UDP broadcasts on Ethernet"
+ depends on PPC_PS3
+ help
+ Enables udbg early debugging output by sending broadcast UDP
+ via the Ethernet port (UDP port number 18194).
+
+ This driver uses a trivial implementation and is independent
+ from the main network driver.
+
+ If in doubt, say N here.
+
endmenu
diff --git a/arch/powerpc/platforms/ps3/Makefile b/arch/powerpc/platforms/ps3/Makefile
index ac1bdf8..02b9e63 100644
--- a/arch/powerpc/platforms/ps3/Makefile
+++ b/arch/powerpc/platforms/ps3/Makefile
@@ -2,6 +2,7 @@ obj-y += setup.o mm.o time.o hvcall.o htab.o repository.o
obj-y += interrupt.o exports.o os-area.o
obj-y += system-bus.o
+obj-$(CONFIG_PS3GELIC_UDBG) += gelic_udbg.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SPU_BASE) += spu.o
obj-y += device-init.o
diff --git a/arch/powerpc/platforms/ps3/gelic_udbg.c b/arch/powerpc/platforms/ps3/gelic_udbg.c
new file mode 100644
index 0000000..20b46a1
--- /dev/null
+++ b/arch/powerpc/platforms/ps3/gelic_udbg.c
@@ -0,0 +1,273 @@
+/*
+ * udbg debug output routine via GELIC UDP broadcasts
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2006, 2007 Sony Corporation
+ * Copyright (C) 2010 Hector Martin <hector@marcansoft.com>
+ * Copyright (C) 2011 Andre Heider <a.heider@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ */
+
+#include <asm/io.h>
+#include <asm/udbg.h>
+#include <asm/lv1call.h>
+
+#define GELIC_BUS_ID 1
+#define GELIC_DEVICE_ID 0
+#define GELIC_DEBUG_PORT 18194
+#define GELIC_MAX_MESSAGE_SIZE 1000
+
+#define GELIC_LV1_GET_MAC_ADDRESS 1
+#define GELIC_LV1_GET_VLAN_ID 4
+#define GELIC_LV1_VLAN_TX_ETHERNET_0 2
+
+#define GELIC_DESCR_DMA_STAT_MASK 0xf0000000
+#define GELIC_DESCR_DMA_CARDOWNED 0xa0000000
+
+#define GELIC_DESCR_TX_DMA_IKE 0x00080000
+#define GELIC_DESCR_TX_DMA_NO_CHKSUM 0x00000000
+#define GELIC_DESCR_TX_DMA_FRAME_TAIL 0x00040000
+
+#define GELIC_DESCR_DMA_CMD_NO_CHKSUM (GELIC_DESCR_DMA_CARDOWNED | \
+ GELIC_DESCR_TX_DMA_IKE | \
+ GELIC_DESCR_TX_DMA_NO_CHKSUM)
+
+static u64 bus_addr;
+
+struct gelic_descr {
+ /* as defined by the hardware */
+ __be32 buf_addr;
+ __be32 buf_size;
+ __be32 next_descr_addr;
+ __be32 dmac_cmd_status;
+ __be32 result_size;
+ __be32 valid_size; /* all zeroes for tx */
+ __be32 data_status;
+ __be32 data_error; /* all zeroes for tx */
+} __attribute__((aligned(32)));
+
+struct debug_block {
+ struct gelic_descr descr;
+ u8 pkt[1520];
+} __packed;
+
+struct ethhdr {
+ u8 dest[6];
+ u8 src[6];
+ u16 type;
+} __packed;
+
+struct vlantag {
+ u16 vlan;
+ u16 subtype;
+} __packed;
+
+struct iphdr {
+ u8 ver_len;
+ u8 dscp_ecn;
+ u16 total_length;
+ u16 ident;
+ u16 frag_off_flags;
+ u8 ttl;
+ u8 proto;
+ u16 checksum;
+ u32 src;
+ u32 dest;
+} __packed;
+
+struct udphdr {
+ u16 src;
+ u16 dest;
+ u16 len;
+ u16 checksum;
+} __packed;
+
+static __iomem struct ethhdr *h_eth;
+static __iomem struct vlantag *h_vlan;
+static __iomem struct iphdr *h_ip;
+static __iomem struct udphdr *h_udp;
+
+static __iomem char *pmsg;
+static __iomem char *pmsgc;
+
+static __iomem struct debug_block dbg __attribute__((aligned(32)));
+
+static int header_size;
+
+static void map_dma_mem(int bus_id, int dev_id, void *start, size_t len,
+ u64 *real_bus_addr)
+{
+ s64 result;
+ u64 real_addr = ((u64)start) & 0x0fffffffffffffffUL;
+ u64 real_end = real_addr + len;
+ u64 map_start = real_addr & ~0xfff;
+ u64 map_end = (real_end + 0xfff) & ~0xfff;
+ u64 bus_addr = 0;
+
+ u64 flags = 0xf800000000000000UL;
+
+ result = lv1_allocate_device_dma_region(bus_id, dev_id,
+ map_end - map_start, 12, 0,
+ &bus_addr);
+ if (result)
+ lv1_panic(0);
+
+ result = lv1_map_device_dma_region(bus_id, dev_id, map_start,
+ bus_addr, map_end - map_start,
+ flags);
+ if (result)
+ lv1_panic(0);
+
+ *real_bus_addr = bus_addr + real_addr - map_start;
+}
+
+static int unmap_dma_mem(int bus_id, int dev_id, u64 bus_addr, size_t len)
+{
+ s64 result;
+ u64 real_bus_addr;
+
+ real_bus_addr = bus_addr & ~0xfff;
+ len += bus_addr - real_bus_addr;
+ len = (len + 0xfff) & ~0xfff;
+
+ result = lv1_unmap_device_dma_region(bus_id, dev_id, real_bus_addr,
+ len);
+ if (result)
+ return result;
+
+ return lv1_free_device_dma_region(bus_id, dev_id, real_bus_addr);
+}
+
+static void gelic_debug_init(void)
+{
+ s64 result;
+ u64 v2;
+ u64 mac;
+ u64 vlan_id;
+
+ result = lv1_open_device(GELIC_BUS_ID, GELIC_DEVICE_ID, 0);
+ if (result)
+ lv1_panic(0);
+
+ map_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID, &dbg, sizeof(dbg),
+ &bus_addr);
+
+ memset(&dbg, 0, sizeof(dbg));
+
+ dbg.descr.buf_addr = bus_addr + offsetof(struct debug_block, pkt);
+
+ wmb();
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_MAC_ADDRESS, 0, 0, 0,
+ &mac, &v2);
+ if (result)
+ lv1_panic(0);
+
+ mac <<= 16;
+
+ h_eth = (struct ethhdr *)dbg.pkt;
+
+ memset(&h_eth->dest, 0xff, 6);
+ memcpy(&h_eth->src, &mac, 6);
+
+ header_size = sizeof(struct ethhdr);
+
+ result = lv1_net_control(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ GELIC_LV1_GET_VLAN_ID,
+ GELIC_LV1_VLAN_TX_ETHERNET_0, 0, 0,
+ &vlan_id, &v2);
+ if (!result) {
+ h_eth->type = 0x8100;
+
+ header_size += sizeof(struct vlantag);
+ h_vlan = (struct vlantag *)(h_eth + 1);
+ h_vlan->vlan = vlan_id;
+ h_vlan->subtype = 0x0800;
+ h_ip = (struct iphdr *)(h_vlan + 1);
+ } else {
+ h_eth->type = 0x0800;
+ h_ip = (struct iphdr *)(h_eth + 1);
+ }
+
+ header_size += sizeof(struct iphdr);
+ h_ip->ver_len = 0x45;
+ h_ip->ttl = 10;
+ h_ip->proto = 0x11;
+ h_ip->src = 0x00000000;
+ h_ip->dest = 0xffffffff;
+
+ header_size += sizeof(struct udphdr);
+ h_udp = (struct udphdr *)(h_ip + 1);
+ h_udp->src = GELIC_DEBUG_PORT;
+ h_udp->dest = GELIC_DEBUG_PORT;
+
+ pmsgc = pmsg = (char *)(h_udp + 1);
+}
+
+static void gelic_debug_shutdown(void)
+{
+ if (bus_addr)
+ unmap_dma_mem(GELIC_BUS_ID, GELIC_DEVICE_ID,
+ bus_addr, sizeof(dbg));
+ lv1_close_device(GELIC_BUS_ID, GELIC_DEVICE_ID);
+}
+
+static void gelic_sendbuf(int msgsize)
+{
+ u16 *p;
+ u32 sum;
+ int i;
+
+ dbg.descr.buf_size = header_size + msgsize;
+ h_ip->total_length = msgsize + sizeof(struct udphdr) +
+ sizeof(struct iphdr);
+ h_udp->len = msgsize + sizeof(struct udphdr);
+
+ h_ip->checksum = 0;
+ sum = 0;
+ p = (u16 *)h_ip;
+ for (i = 0; i < 5; i++)
+ sum += *p++;
+ h_ip->checksum = ~(sum + (sum >> 16));
+
+ dbg.descr.dmac_cmd_status = GELIC_DESCR_DMA_CMD_NO_CHKSUM |
+ GELIC_DESCR_TX_DMA_FRAME_TAIL;
+ dbg.descr.result_size = 0;
+ dbg.descr.data_status = 0;
+
+ wmb();
+
+ lv1_net_start_tx_dma(GELIC_BUS_ID, GELIC_DEVICE_ID, bus_addr, 0);
+
+ while ((dbg.descr.dmac_cmd_status & GELIC_DESCR_DMA_STAT_MASK) ==
+ GELIC_DESCR_DMA_CARDOWNED)
+ cpu_relax();
+}
+
+static void ps3gelic_udbg_putc(char ch)
+{
+ *pmsgc++ = ch;
+ if (ch == '\n' || (pmsgc-pmsg) >= GELIC_MAX_MESSAGE_SIZE) {
+ gelic_sendbuf(pmsgc-pmsg);
+ pmsgc = pmsg;
+ }
+}
+
+void __init udbg_init_ps3gelic(void)
+{
+ gelic_debug_init();
+ udbg_putc = ps3gelic_udbg_putc;
+}
+
+void udbg_shutdown_ps3gelic(void)
+{
+ udbg_putc = NULL;
+ gelic_debug_shutdown();
+}
+EXPORT_SYMBOL(udbg_shutdown_ps3gelic);
diff --git a/drivers/net/ps3_gelic_net.c b/drivers/net/ps3_gelic_net.c
index d82a82d..e743c94 100644
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -1674,6 +1674,9 @@ static int __devinit ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
int result;
pr_debug("%s: called\n", __func__);
+
+ udbg_shutdown_ps3gelic();
+
result = ps3_open_hv_device(dev);
if (result) {
diff --git a/drivers/net/ps3_gelic_net.h b/drivers/net/ps3_gelic_net.h
index d3fadfb..a93df6a 100644
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -359,6 +359,12 @@ static inline void *port_priv(struct gelic_port *port)
return port->priv;
}
+#ifdef CONFIG_PPC_EARLY_DEBUG_PS3GELIC
+extern void udbg_shutdown_ps3gelic(void);
+#else
+static inline void udbg_shutdown_ps3gelic(void) {}
+#endif
+
extern int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask);
/* shared netdev ops */
extern void gelic_card_up(struct gelic_card *card);
^ permalink raw reply related
* RE: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Tirumala Marri @ 2011-08-31 17:17 UTC (permalink / raw)
To: Pratyush Anand
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <CAHM4w1nHQ1arnTjFyp4dbmp1SBWKJPfREOOR_yykfaVyS48-iA@mail.gmail.com>
<
<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.
[Tirumala Marri] Sounds like a plan. Could you send the changes, I will
take
A look at the changes.
--marri
^ permalink raw reply
* Re: [PATCH 00/14] Modifications for DWC OTG since v13
From: Felipe Balbi @ 2011-08-31 20:33 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, Greg KH,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <cover.1314704557.git.pratyush.anand@st.com>
[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]
Hi,
(you did not add Greg in Cc, he's the USB maintainer. You also didn't Cc
myself as maintainer of the gadget framework)
On Tue, Aug 30, 2011 at 05:27:47PM +0530, Pratyush Anand wrote:
> 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.
Looking at that driver code, I believe this is pretty much Synopsys
reference code with a few tweaks. If you want some tip, don't do that.
The reference driver, while functional, has lots of unnecessary layering
which should be avoided.
See how we wrote the DWC3 driver. It's very small code which does the
necessary. It's now functionally complete, from now on we only need to
improve on performance (for example starting transfers on Transfer
Complete event if we already have requests queued). Nevertheless, the
driver is small and has been tested with all transfer types.
If you really want to use this driver as is, that's your call. But I
would suggest to Greg that he only takes this in if there is someone
dedicated to maintain it. It's a really big codebase and whenever I
change something on the gadget framework I will have to patch this
beast too.
If there's no maintainer assigned to it, who's willing to put effort in
improving this driver in the long run, I think this will become yet
another burden on the community. Still, it's your call.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix xmon for systems without MSR[RI]
From: Jimi Xenidis @ 2011-08-31 21:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4E5D272B.6000403@freescale.com>
On Aug 30, 2011, at 1:08 PM, Scott Wood wrote:
> 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 <dwg@au1.ibm.com>
>>>=20
>>> Based on patch by David Gibson <dwg@au1.ibm.com>
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> Don't freescale one have RI ?
>=20
> e500mc does.
hmm, according to the ISA, MSR[RI] is only defined for Book3s and is not =
defined for Book3e
Should we scope it to just book3e?
-jx
>=20
> e500v2 doesn't -- if a machine check happens while MSR[ME]=3D0, it =
causes
> a checkstop.
>=20
> -Scott
>=20
^ permalink raw reply
* Re: [v3 PATCH 1/1] booke/kprobe: make program exception to use one dedicated exception stack
From: Benjamin Herrenschmidt @ 2011-08-31 21:32 UTC (permalink / raw)
To: tiejun.chen; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <4E5DFC41.7030606@windriver.com>
On Wed, 2011-08-31 at 17:17 +0800, tiejun.chen wrote:
> > It sounds hackish but it makes it easier to fix everybody at once, there
> > are "issues" with changing stacks especially on ppc64 and it would
> > definitely be affected as well if the stack frame created is larger than
> > our gap.
>
> If we provide another exception stack like we did debug exception on ppc64, are
> there those "issues" you said?
Actually if we allocate it like the irq stacks, we should be ok, but
that's yet another 16K per CPU that needs to be covered by the first
segment, nasty....
In any case, please try to come up with a patch that covers all
variants.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Greg KH @ 2011-08-31 22:36 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, linux-usb,
vipin.kumar, shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar,
mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <d10bbf1498af371e41907fa07624456d981e56af.1314704557.git.pratyush.anand@st.com>
On Tue, Aug 30, 2011 at 05:27:49PM +0530, Pratyush Anand wrote:
> 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 <pratyush.anand@st.com>
> ---
> 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
Shouldn't this be in include/linux/platform/ instead?
^ permalink raw reply
* Re: [PATCH 01/14] dwc/otg: Add Register definitions
From: Greg KH @ 2011-08-31 22:35 UTC (permalink / raw)
To: Pratyush Anand
Cc: viresh.kumar, vipulkumar.samar, bhupesh.sharma, tmarri, linux-usb,
vipin.kumar, shiraz.hashim, Amit.VIRDI, rajeev-dlh.kumar,
mmiesfeld, deepak.sikri, linuxppc-dev, fchen
In-Reply-To: <ff45c2ef4d21fa8ae27b36b2862962bf792e2b6b.1314704557.git.pratyush.anand@st.com>
On Tue, Aug 30, 2011 at 05:27:48PM +0530, Pratyush Anand wrote:
> From: Tirumala Marri <tmarri@apm.com>
>
> Add Synopsys Design Ware core register definitions.
>
> Signed-off-by: Tirumala R Marri <tmarri@apm.com>
> Signed-off-by: Fushen Chen <fchen@apm.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> ---
> 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 0000000..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.
You can stop the boiler-plate text here, because:
> + *
> + * 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.
Unless you wish to track the office location of the FSF for the next 20+
years, remove this, and the previous paragraph please.
> + *
> + * Based on Synopsys driver version 2.60a
> + * Modified by Mark Miesfeld <mmiesfeld@apm.com>
> + *
> + * Revamped register difinitions by Tirumala R Marri(tmarri@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.
This paragraph is not needed, right?
> + *
> + */
> +
> +#ifndef __DWC_OTG_REGS_H__
> +#define __DWC_OTG_REGS_H__
> +
> +#include <linux/types.h>
> +#include <linux/usb/dwc_otg.h>
> +/*Bit fields in the Device EP Transfer Size Register is 11 bits */
What is this comment for?
Did you drop a space? And forget an extra line?
> +#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.
> + */
> +#define DWC_GOTGCTL 0x000
> +#define DWC_GOTGINT 0x004
> +#define DWC_GAHBCFG 0x008
> +#define DWC_GUSBCFG 0x00C
> +#define DWC_GRSTCTL 0x010
> +#define DWC_GINTSTS 0x014
> +#define DWC_GINTMSK 0x018
> +#define DWC_GRXSTSR 0x01C
> +#define DWC_GRXSTSP 0x020
> +#define DWC_GRXFSIZ 0x024
> +#define DWC_GNPTXFSIZ 0x028
> +#define DWC_GNPTXSTS 0x02C
> +#define DWC_GI2CCTL 0x030
> +#define DWC_VDCTL 0x034
> +#define DWC_GGPIO 0x038
> +#define DWC_GUID 0x03C
> +#define DWC_GSNPSID 0x040
> +#define DWC_GHWCFG1 0x044
> +#define DWC_GHWCFG2 0x048
> +#define DWC_GHWCFG3 0x04c
> +#define DWC_GHWCFG4 0x050
> +#define DWC_HPTXFSIZ 0x100
> +#define DWC_DPTX_FSIZ_DIPTXF(x) (0x104 + x * 4) /* 15 <= x > 1 */
Drop the tab after #define please, as you don't have it anywhere else.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Greg KH @ 2011-08-31 22:36 UTC (permalink / raw)
To: Tirumala Marri
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <9183dc7afa5b8cde400e9f37f5679d4f@mail.gmail.com>
On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
> <-----Original Message-----
> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
> <Sent: Tuesday, August 30, 2011 4:58 AM
> <To: linux-usb@vger.kernel.org
> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
> <Anand
> <Subject: [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 <pratyush.anand@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.
pending where? Have you submitted them for inclusion?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Josh Boyer @ 2011-09-01 0:18 UTC (permalink / raw)
To: Greg KH
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
Tirumala Marri, linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <20110831223633.GC27818@kroah.com>
On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
>> <-----Original Message-----
>> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
>> <Sent: Tuesday, August 30, 2011 4:58 AM
>> <To: linux-usb@vger.kernel.org
>> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
>> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
>> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
>> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
>> <Anand
>> <Subject: [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 thi=
s
>> <include file.
>> <
>> <Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
>> <---
>> < include/linux/usb/dwc_otg.h | =A0274
>>
>> [Tirumala Marri] I am not sure how to separate your changes. But we need
>> More time as our initial patches are still pending.
>
> pending where? =A0Have you submitted them for inclusion?
>
13 times in fact. Each time, more comments and fixes need. Par for
the course with a vendor driver, but in this case Pratyush thought the
APM guys had let it die and tried to carry it forward. I guess APM
has been sitting on it for more than 4 months now.
Anyway, hope that clears up some of the confusion.
josh
^ permalink raw reply
* Re: [PATCH 02/14] dwc/otg: Structure declaration for shared data
From: Greg KH @ 2011-09-01 1:37 UTC (permalink / raw)
To: Josh Boyer
Cc: Pratyush Anand, viresh.kumar, vipulkumar.samar, bhupesh.sharma,
Tirumala Marri, linux-usb, vipin.kumar, shiraz.hashim, Amit.VIRDI,
rajeev-dlh.kumar, Mark Miesfeld, deepak.sikri, linuxppc-dev,
Fushen Chen
In-Reply-To: <CA+5PVA569eWwYvU9Ghs6yGNimTPDX0+fbmouMV2yuxjyA7J4+g@mail.gmail.com>
On Wed, Aug 31, 2011 at 08:18:12PM -0400, Josh Boyer wrote:
> On Wed, Aug 31, 2011 at 6:36 PM, Greg KH <greg@kroah.com> wrote:
> > On Tue, Aug 30, 2011 at 08:29:21AM -0700, Tirumala Marri wrote:
> >> <-----Original Message-----
> >> <From: Pratyush Anand [mailto:pratyush.anand@st.com]
> >> <Sent: Tuesday, August 30, 2011 4:58 AM
> >> <To: linux-usb@vger.kernel.org
> >> <Cc: tmarri@apm.com; linuxppc-dev@lists.ozlabs.org; fchen@apm.com;
> >> <mmiesfeld@apm.com; shiraz.hashim@st.com; deepak.sikri@st.com;
> >> <vipulkumar.samar@st.com; rajeev-dlh.kumar@st.com; vipin.kumar@st.com;
> >> <bhupesh.sharma@st.com; viresh.kumar@st.com; Amit.VIRDI@st.com; Pratyush
> >> <Anand
> >> <Subject: [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 <pratyush.anand@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.
> >
> > pending where? Have you submitted them for inclusion?
> >
>
> 13 times in fact. Each time, more comments and fixes need. Par for
> the course with a vendor driver, but in this case Pratyush thought the
> APM guys had let it die and tried to carry it forward. I guess APM
> has been sitting on it for more than 4 months now.
>
> Anyway, hope that clears up some of the confusion.
It does, thanks.
greg k-h
^ permalink raw reply
* Re: VFIO v2 design plan
From: David Gibson @ 2011-09-01 4:10 UTC (permalink / raw)
To: Alex Williamson
Cc: aafabbri, Alexey Kardashevskiy, kvm, Paul Mackerras,
Roedel, Joerg, agraf, qemu-devel, chrisw, iommu, Avi Kivity,
Anthony Liguori, linux-pci@vger.kernel.org, linuxppc-dev, benve
In-Reply-To: <1314715900.2859.480.camel@bling.home>
On Tue, Aug 30, 2011 at 08:51:38AM -0600, Alex Williamson wrote:
> 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:
[snip]
> > > > > 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 the remaining merged group.
> > > >
> > > > As I've said I prefer a persistent group model, rather than this
> > > > transient group model, but it's not a dealbreaker by itself. How are
> > > > unmerges specified?
> > >
> > > VFIO_GROUP_UNMERGE ioctl taking a group fd parameter.
> > >
> > > > I'm also assuming that in this model closing a
> > > > (bound) group fd will unmerge everything down to atomic groups again.
> > >
> > > Yes, it will unmerge the closed group down to the atomic group.
> >
> > Hrm, not thrilled with the merging semantics, but I can probably live
> > with them. Still some clarifications, though..
> >
> > If you open a group, merge in a bunch of other groups, then re-open
> > /dev/vfio/NNN for one of the groups mergeed, presumably the new fd
> > must also see the merged group? So presumably you must only unmerge
> > everything when all the fds are closed.
>
> The device fds for the group to be unmerged must be closed before an
> unmerge. The iommu fd is tricky. The iommu fd is really the iommu for
> the merged group, not the individual groups, so it's context stays with
> the remaining group. Therefore I don't enforce a refcnt on the iommu
> fd. The usage model I expect is that if a merge works, the user will
> probably use a single iommu fd for the whole merged group. Maybe that
> should be enforced?
I thought I recalled you saying earlier that the iommu fd could not be
open when merging new groups in. I would expect that also to be true
when unmerging in that case.
> > If you open groups a and b, then merge a (disjoint) bunch of things
> > into each, then merge b into a, what are the semantics? Wheat about
> > if you then unmerge b from a - does it just remove the atomic group b,
> > or everything you merged into b earlier? Or, what happens if you open
> > group a, merge in some things, then attempt to unmerge a from the
> > merged group?
>
> Simple, don't allow merging and unmerging of merged groups. Merge and
> unmerge only work on singleton groups.
Ok, in that case I think we should call it "add" and "remove" rather
than merge and unmerge.
> The last case we must support.
> In that case you just use:
>
> ioctl(a.fd, VFIO_GROUP_MERGE, b.fd)
> ioctl(b.fd, VFIO_GROUP_UNMERGE, a.fd)
>
> The groups are peers when merged, so b can remove a as easily as a can
> remove b. Group b is left with any iommu context setup while
> merged.
Um *goes cross-eyed*. So, if you open (atomic) groups a and b, then
add group b to a, are the two open fds now functionally identical?
And likewise if you then open either a or b again straight from from
/dev/vfio?
Except, that the b fd must then retain the fact that it was originally
for atomic group (b), so that it can be used as a handle for an
unmerge/remove.
The more I dig into the details of these semantics the more I dislike
them.
[snip]
> > > Beyond unbind, we also need to think about hotplug. If a system had
> > > multiple hotplug slots below a P2P bridge and a device was added while
> > > the group is in use, what do we do? Maybe we can somehow disable it or
> > > mark it for vfio in our bus notifier routines(?).
> >
> > That is a very good point. It actually brings into focus a niggling
> > concern I had about this model where the group becomes vfio usable
> > once all the devices in it are bound to vfio. Because of the
> > possibility of hotplug, I think its conceptually more correct to not
> > treat vfio as just another kernel driver which can bind devices, but a
> > special state that the whole group goes into atomically. So the
> > sequence would be:
> > - Admin asks that a group go into vfio state
> > - kernel (attempts to) unbind kernel drivers from every device
> > in the group
> > - group is marked in vfio/limbo state
> >
> > At this point no kernel drivers may bind to anything in the group,
> > including things that are hotplugged into the group after this initial
> > sequence.
>
> It seems like this is a mode that could only be accessible if the group
> is opened w/ admin capabilities, I don't think we'd want to let the vfio
> group chrdev owner be able to do that automatically.
They have to do something that's just as restrictive automatically.
If new devices enter an atomic group that's in use by a guest, the
kernel must not bind drivers to them. I'm just trying to make the
semantics clearer, than proxying the restrictions by binding a dummy
driver to everything.
> I don't know of
> any other drivers that behave like this, being able to unbind running
> drivers and pull devices into itself.
Well, it's not a driver behaving like this, it's an explicit admin
operation to unbind all drivers from the whole group and put it in a
state that's suitable for vfio assignment.
> > > > > If the device fds are not released and
> > > > > subsequently the iommu fd released as well, vfio will kill the user
> > > > > process after some delay.
> > > >
> > > > Ouch, this seems to me a problematic semantic. Whether the user
> > > > process survives depends on whether it processes the remove requests
> > > > fast enough - and a user process could be slowed down by system load
> > > > or other factors not entirely in its control.
> > >
> > > I was assuming "ample" time to process a hot remove, but yes, it's an
> > > area of concern. I'm not sure how much of a problem it is in practice
> > > though. Yes you can shoot your VM accidentally as root... don't do
> > > that.
> >
> > They can, but with this semantic they can't know in advance whether
> > the command is going to kill the VM or not. I can just see a
> > situation where the admin issues a command to remove the device from
> > the guest, and usually that goes through the hot guest unplug
> > mechanisms, the guest keeps running and everything is happy. Then one
> > time they issue *exactly the same command* and the VM dies, because
> > the system is running really slow for some reason (huge load, or maybe
> > someone switched the VM into full emulation for debugging).
>
> Not sure how to handle this other than leave a trail of bread crumbs.
I have no idea what you mean by that.
> > > > I'd be more comfortable with a model where there was a distinction
> > > > between a "soft" and "hard" remove. The soft would either simply
> > > > fail, if the device is in use by vfio, or block indefinitely. The
> > > > hard would kill the user process without delay. This effectively
> > > > allows your semantics to be implemented in userspace (soft remove,
> > > > wait, hard remove) - where it's easier to tweak the policy of how long
> > > > to wait.
> > >
> > > Your first example is essentially what current vfio does now, request
> > > remove, wait indefinitely and qemu triggers an abort if the guest
> > > doesn't respond. The trouble with moving this policy to userspace is
> > > that we're not protecting the host.
> >
> > How is the host not protected? Bear in mind that when I say
> > "userspace" I'm not thinking qemu, I'm thinking the admin equipped
> > with whatever tools he uses for moving devices between guests. So
> > they go:
> > - Please remove this group from the guest
> > - Waits for an amount of time of their choice
> > - Decide, crap, the guest is broken
> > - Hard remove the group from the guest, killing the guest
> >
> > It's basic in perfect analogy to the old:
> > - kill -15
> > - *drum fingers*
> > - Damn, it's stuck
> > - kill -9
>
> And what if the remove is initiated by a hardware admin that walks over
> to the system, and presses the PCI device hot unplug doorbell? It just
> looks like a driver hang. Thanks,
Hm, true. How is this case handled on the host side?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Kumar Gala @ 2011-09-01 4:42 UTC (permalink / raw)
To: Chunhe Lan, Chris Ball; +Cc: Shengzhou Liu, linux-mmc, PPC list
In-Reply-To: <1314345310-15041-1-git-send-email-Chunhe.Lan@freescale.com>
On Aug 26, 2011, at 2:55 AM, Chunhe Lan wrote:
> The mmc_delay() is a wrapper function for mdelay() and msleep().
>=20
> o mdelay() -- block the system when busy-waiting.
> o msleep() -- suspend the currently running task to enable CPU
> to process other tasks, so it is non-blocking
> regarding the whole system.
>=20
> When the desired delay time is more than a period of timer interrupt,
> just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
> CPU when busy wait.
>=20
> Signed-off-by: Shengzhou Liu <b36685@freescale.com>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> Cc: Chris Ball <cjb@laptop.org>
> ---
> drivers/mmc/host/sdhci.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
It might be good to either merge patch 2/3 & 3/3 or rename them since =
they have same commit message.
Chris,
Any comments on closing on these patches?
- k=
^ permalink raw reply
* Re: [PATCH 2/4] dma-mapping: add get_required_mask if arch overrides default
From: Benjamin Herrenschmidt @ 2011-09-01 5:35 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: vinod.koul, linux-kernel, miltonm, nacc, dan.j.williams,
linuxppc-dev
In-Reply-To: <20110629171304B.fujita.tomonori@lab.ntt.co.jp>
On Wed, 2011-06-29 at 17:19 +0900, FUJITA Tomonori wrote:
> On Fri, 24 Jun 2011 12:05:23 -0700
> Nishanth Aravamudan <nacc@us.ibm.com> wrote:
>
> > From: Milton Miller <miltonm@bga.com>
> >
> > If an architecture sets ARCH_HAS_DMA_GET_REQUIRED_MASK and has settable
> > dma_map_ops, the required mask may change by the ops implementation.
> > For example, a system that always has an mmu inline may only require 32
> > bits while a swiotlb would desire bits to cover all of memory.
> >
> > Therefore add the field if the architecture does not use the generic
> > definition of dma_get_required_mask. The first use will by by powerpc.
> > Note that this does add some dependency on the order in which files are
> > visible here.
.../...
> If you add get_required_mask to dma_map_ops, we should clean up ia64
> too and implement the generic proper version in
> dma-mapping-common.h. Then we kill ARCH_HAS_DMA_GET_REQUIRED_MASK
> ifdef hack. Otherwise, I don't think it makes sense to add this to
> dma_map_ops.
In the meantime, can I have an ack so I can include this along with the
rest of Milton's patches ? It's been around for a while now :-)
I'm a bit late for producing a powerpc-next (due to travelling).
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox