* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Tabi Timur-B04825 @ 2011-08-31 2:51 UTC (permalink / raw)
To: Gala Kumar-B11780
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <3F34FBCD-3F0B-4D59-A947-C16CC812B42E@freescale.com>
Kumar Gala wrote:
> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? This s=
eems to vague.
Yes, the PIXIS is generally register compatible across all boards. There=20
may be some minor differences, but the OCM driver can work with all PIXIS=20
boards that have an PIXIS.
> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
Ok.
> Also fpga-cpld makes no sense if we keep this. You are either a CPLD or =
FPGA not both.
Then I don't understand what the CPLD is.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-08-31 2:54 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <4E5DA1CC.1020808@freescale.com>
On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? =
This seems to vague.
>=20
> Yes, the PIXIS is generally register compatible across all boards. =
There=20
> may be some minor differences, but the OCM driver can work with all =
PIXIS=20
> boards that have an PIXIS.
Is this true? Don't we have pixis and ngpixis in u-boot?
>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>=20
> Ok.
>=20
>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD =
or FPGA not both.
>=20
> Then I don't understand what the CPLD is.
http://en.wikipedia.org/wiki/Complex_programmable_logic_device
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Tabi Timur-B04825 @ 2011-08-31 3:01 UTC (permalink / raw)
To: Gala Kumar-B11780
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <DBF3606B-8F59-4E5F-9B47-C3E0235665C4@freescale.com>
Kumar Gala wrote:
>
> On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
>
>> Kumar Gala wrote:
>>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? Thi=
s seems to vague.
>>
>> Yes, the PIXIS is generally register compatible across all boards. Ther=
e
>> may be some minor differences, but the OCM driver can work with all PIXI=
S
>> boards that have an PIXIS.
>
> Is this true? Don't we have pixis and ngpixis in u-boot?
I forgot about that. Well, everything I said is true about the ngpixis,=20
so I guess I should use "ngpixis" instead of just "pixis" here. I'll have=
=20
to check if the old pixis can be used this way.
>
>>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>>
>> Ok.
>>
>>> Also fpga-cpld makes no sense if we keep this. You are either a CPLD o=
r FPGA not both.
>>
>> Then I don't understand what the CPLD is.
>
> http://en.wikipedia.org/wiki/Complex_programmable_logic_device
Ok, I get it now. Is there a name for the CPLD we use on these chips?=20
I'm having a hard time getting proper documentation on the CPLD. York=20
expressed similar frustration.
Perhaps these should be called board-control devices. How about
fsl,boardcontrol-cpld
fsl,boardcontrol-ngpixis
fsl,boardcontrol-qixis
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
From: Kumar Gala @ 2011-08-31 3:05 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780,
devicetree-discuss@lists.ozlabs.org
In-Reply-To: <4E5DA412.5020300@freescale.com>
On Aug 30, 2011, at 10:01 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>>=20
>> On Aug 30, 2011, at 9:51 PM, Tabi Timur-B04825 wrote:
>>=20
>>> Kumar Gala wrote:
>>>> Do we really want the generic "fsl,fpga-cpld"& "fsl,fpga-pixis"? =
This seems to vague.
>>>=20
>>> Yes, the PIXIS is generally register compatible across all boards. =
There
>>> may be some minor differences, but the OCM driver can work with all =
PIXIS
>>> boards that have an PIXIS.
>>=20
>> Is this true? Don't we have pixis and ngpixis in u-boot?
>=20
> I forgot about that. Well, everything I said is true about the =
ngpixis,=20
> so I guess I should use "ngpixis" instead of just "pixis" here. I'll =
have=20
> to check if the old pixis can be used this way.
>=20
>>=20
>>>> Also you need "pixis" on MPC8544DS, MPC8572DS, MPC8536DS.
>>>=20
>>> Ok.
>>>=20
>>>> Also fpga-cpld makes no sense if we keep this. You are either a =
CPLD or FPGA not both.
>>>=20
>>> Then I don't understand what the CPLD is.
>>=20
>> http://en.wikipedia.org/wiki/Complex_programmable_logic_device
>=20
> Ok, I get it now. Is there a name for the CPLD we use on these chips?=20=
> I'm having a hard time getting proper documentation on the CPLD. York=20=
> expressed similar frustration.
>=20
> Perhaps these should be called board-control devices. How about
>=20
> fsl,boardcontrol-cpld
> fsl,boardcontrol-ngpixis
> fsl,boardcontrol-qixis
For the CPLD based boards I think:
<BOARDNAME>-cpld is best as there isn't really much consistent right =
now.
- k=
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2011-08-31 3:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
A few minor defconfig updates and a dts fix to send up to Linus for 3.1
- k
The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:
Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
Chunhe Lan (1):
powerpc/p1023rds: Fix the error of bank-width of nor flash
Kim Phillips (1):
powerpc/85xx: enable caam crypto driver by default
Timur Tabi (1):
powerpc/85xx: enable the audio drivers in the defconfigs
arch/powerpc/boot/dts/p1023rds.dts | 2 +-
arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 5 ++++-
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
6 files changed, 9 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: enable caam crypto driver by default
From: Kumar Gala @ 2011-08-31 3:18 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20110722154808.a9cabea2.kim.phillips@freescale.com>
On Jul 22, 2011, at 3:48 PM, Kim Phillips wrote:
> corenet based SoCs have SEC4 h/w, so enable the SEC4 driver,
> caam, and the algorithms it supports, and disable the
> SEC2/3 driver, talitos.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> v2: rebase from old e55xx_smp_defconfig file to new corenet & p1023
> defconfigs
>
> arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> arch/powerpc/configs/corenet64_smp_defconfig | 5 ++++-
> 3 files changed, 6 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] [v2] powerpc/85xx: enable the audio drivers in the defconfigs
From: Kumar Gala @ 2011-08-31 3:19 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1313534679-7523-1-git-send-email-timur@freescale.com>
On Aug 16, 2011, at 5:44 PM, Timur Tabi wrote:
> Enable the audio drivers in the non-corenet 85xx defconfigs so that audio
> is enabled on the Freescale P1022DS reference board.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/configs/mpc85xx_defconfig | 1 +
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] powerpc/p1023rds: Fix the error of bank-width of nor flash
From: Kumar Gala @ 2011-08-31 3:18 UTC (permalink / raw)
To: Chunhe Lan; +Cc: linuxppc-dev
In-Reply-To: <1313146809-13686-1-git-send-email-Chunhe.Lan@freescale.com>
On Aug 12, 2011, at 6:00 AM, Chunhe Lan wrote:
> In the p1023rds, a physical bus of nor flash is 16 bits width.
> The bank-width is width (in bytes) of the bus width. So, the
> value of bank-width of nor flash is not one, and it should be
> two.
>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/boot/dts/p1023rds.dts | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [RFC PATCH 02/10] fadump: Reserve the memory for firmware assisted dump.
From: Anton Blanchard @ 2011-08-31 4:11 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Linux Kernel, Milton Miller, Michael Ellerman, Eric W. Biederman,
linuxppc-dev
In-Reply-To: <20110713180648.6210.39530.stgit@mars.in.ibm.com>
Hi Mahesh,
Just a few comments.
> +#define RMR_START 0x0
> +#define RMR_END (0x1UL << 28) /* 256 MB */
What if the RMO is bigger than 256MB? Should we be using ppc64_rma_size?
> +#ifdef DEBUG
> +#define PREFIX "fadump: "
> +#define DBG(fmt...) printk(KERN_ERR PREFIX fmt)
> +#else
> +#define DBG(fmt...)
> +#endif
We should use the standard debug macros (pr_debug etc).
> +/* Global variable to hold firmware assisted dump configuration info. */
> +static struct fw_dump fw_dump;
You can remove this comment, especially because the variable isn't global :)
> + sections = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + NULL);
> +
> + if (!sections)
> + return 0;
> +
> + for (i = 0; i < FW_DUMP_NUM_SECTIONS; i++) {
> + switch (sections[i].dump_section) {
> + case FADUMP_CPU_STATE_DATA:
> + fw_dump.cpu_state_data_size =
> sections[i].section_size;
> + break;
> + case FADUMP_HPTE_REGION:
> + fw_dump.hpte_region_size =
> sections[i].section_size;
> + break;
> + }
> + }
> + return 1;
> +}
This makes me a bit nervous. We should really get the size of the property
and use it to iterate through the array. I saw no requirement in the PAPR
that the array had to be 2 entries long.
> +static inline unsigned long calculate_reserve_size(void)
> +{
> + unsigned long size;
> +
> + /* divide by 20 to get 5% of value */
> + size = memblock_end_of_DRAM();
> + do_div(size, 20);
> +
> + /* round it down in multiples of 256 */
> + size = size & ~0x0FFFFFFFUL;
> +
> + /* Truncate to memory_limit. We don't want to over reserve
> the memory.*/
> + if (memory_limit && size > memory_limit)
> + size = memory_limit;
> +
> + return (size > RMR_END ? size : RMR_END);
> +}
5% is pretty aribitrary, that's 400GB on an 8TB box. Also our experience
with kdump is that 256MB is too small. Is there any reason to scale it
with memory size? Can we do what kdump does and set it to a single
value (eg 512MB)?
We could override the default with a boot option, which is similar to
how kdump specifies the region to reserve.
Anton
^ permalink raw reply
* 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
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