Hi Ben,
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Thursday, December 08, 2011 2:59 PM
To: Prashant Bhole
Cc: linuxppc-...@ozlabs.org; Tirumala Marri
Subject: Re: ibm_newemac tx problem with jumbo frame enabled
On Thu, 2011-12-08 at 18:31
; linuxppc-
d...@lists.ozlabs.org; Fushen Chen
Subject: Re: [PATCH v14 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core
Interface Layer (CIL)
On Fri, Oct 7, 2011 at 8:00 AM, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
[...]
+ * Do core a soft reset of the core. Be careful
What email client are you using, I have never seen this type of
formatting, and it makes it impossible to read your replies. Please
resolve this.
Wrong prefix setting. Should be fixed now.
Sometimes people miss things on previous reviews, this is not a perfict
system, only the best that we
target either -- what
the driver really needs is _functional_ cut-down to only cover the use
cases that your product uses, and staging cleanups are mostly around
style and refactoring, not changing, fixing or removing functionality.
[Tirumala Marri] I like to hear What maintainer GregKH thinks. We
Greg,
No, just start over from scratch. Just leave the crap driver behind,
use it for reference but write the new one.
It's obvious given that you are already at iteration v15 and it's
still looking this bad that this is not realistic to get reviewed and
accepted as-is. I don't think staging is
Overall this driver seems to be based on the IP vendor driver? It
looks like a completely flexible driver that implements all possible
combinations of everything.
[Tirumala Marri] Some what true that it was based on skeletal driver
Provided from IP vendor.
And as a result, it's huge, and it's
of usbcv test
cases passes
without those modifications.
So, please have a look on those comments.
You may add my signed-off.
[Tirumala Marri] I don't do all the unit tests before submission.
I only do few device tests like Ethernet and file backed storage.
For host mode I do some basic IO test. I
,
DWC_AHBCFG_GLBL_INT_MASK, 0);
? Same for other places in this file.
[Tirumala Marri] I can definitely change this at some places.
This had to do because there was suggestion modify the API to accept
The offset. It happened to be some of the accesses doesn't have offsets.
+/**
+ * Tests if the current hardware
this one is defined...
[Tirumala Marri] You mean USB_GADGET_SELECTED ? Ok I will add it.
--marri
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi,
I did find any private info for ppc in
drivers/usb/dwc/apmppc.c
do you want make it generic driver ? if yes, it could be a
generic name too.
[Tirumala Marri] This file has of PPC specific functions, like device tree
which actually contains PPC specific address ranges
these modifications and get
it included. Once these patches are
included then we can keep on sending further patches over those
included. This will shorten review time
and will be easier for inclusion.
[Tirumala Marri] We did 13 submission before and not expecting acceptance
any time soon. Let us see what
repository on github, for
example? I'm using dwc_otg on several MIPS boards and would be happy to
contribute too (at least, fix things pointed out by reviewers to speed
up inclusion).
[Tirumala Marri] I can take a look at this and setup a public git
repository.
We started the initial dwc_otg submissions
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
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
of those parameters have been provided in this
include file.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
include/linux/usb/dwc_otg.h | 274
[Tirumala Marri] I am not sure how to separate your changes. But we need
More time as our initial patches are still pending.
--marri
On Wed, Jun 15, 2011 at 7:40 AM, Suzuki Poulose suz...@in.ibm.com wrote:
On 06/15/11 15:41, Benjamin Herrenschmidt wrote:
On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:
On 06/14/11 17:34, Michal Simek wrote:
Hi,
have someone tried to support RELOCATABLE kernel on ppc44x?
As
The interesting question of course is whether that 460SX stuff is the
same as what we're using internally :-)
[marri] Sometimes open-source and internal releases may not be the same
Because of open-source standards.
Can we fix that ?
[marri] Sure I will take a look at it.
Not sure how I would know -- But with my eiger kit, I got a
cd from amcc that had a patched 2.6.30 or something kernel
in it to support the 460SX. The pci code was basically
subverted by adding a port-link=1 at the very end of the
link check to always force it to succeed. However this code
So what is the best way to handle this? It appears (based
on the comments of others and my own experience) that there
is no DCR that exists and behaves the way that previous SOCs
behaved to give us the link status? The register above
PECFGn_DLLSTA is actually in the PCIe configuration space so
Also, the patch removes the code for waiting for the link to be up with
a comment What DCR has the link status on the 460SX?. Please fix that
(Tirumala, can you provide the missing information ?)
It is not one register. Here is the flow for Gen-1.
1. PECFGn_DLLSTA[3] will be asserted when
I'm tempted to put it in if Tirumala doesn't get to review it asap.
[Marri] Sorry for the late response. I don't see any issue with changes,
please go ahead.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
You originally submitted the support for 460ex. Can you chime in (and
review Ayman patch) please ?
[Marri] Ben sure I will review it and send you my feedback in couple of
days.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
-Original Message-
From: Keshava Munegowda [mailto:keshava_mgo...@ti.com]
Sent: Tuesday, March 29, 2011 3:46 AM
To: tma...@apm.com; linux-...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org
Cc: g...@kroah.com; Fushen Chen; Mark Miesfeld
Subject: RE: [PATCH v10 02/10] USB/ppc4xx: Add
+void dwc_otg_core_init(struct core_if *core_if)
+{
+ u32 i;
+ ulong global_reg = core_if-core_global_regs;
+ struct device_if *dev_if = core_if-dev_if;
+ u32 ahbcfg = 0;
+ u32 i2cctl = 0;
+ u32 gusbcfg;
Tabify the declarations ;
[Marri] When I checked again in my
+config DWC_DEVICE_ONLY
+ bool DWC Device Only Mode
+ select USB_GADGET_SELECTED
+
+endchoice
So this is tri-modal driver after all... how come we place it in
drivers/usb/otg/dwc/, while the same tri-modal MUSB driver was placed in
drivers/usb/musb/?
[Marri] Initially this was
dwc_read_reg32 is used nowhere throughout the code. One of dwc_read32
and
dwc_read_reg32 should be removed IMO. There was once only
dwc_read_reg32. In
version 5 of your patchset I believe. Why did you add another function?
AFAIK it is not correct to store pointers in u32 because they
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of David Laight
Sent: Wednesday, January 26, 2011 8:35 AM
Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: RE: [PATCH
dwc_read_reg32 is used nowhere throughout the code. One of dwc_read32 and
dwc_read_reg32 should be removed IMO. There was once only dwc_read_reg32. In
version 5 of your patchset I believe. Why did you add another function?
AFAIK it is not correct to store pointers in u32 because they need 8 bytes
}
dev_set_drvdata(_dev, dwc_otg_device);
hcd-regs = otg_dev-base;
+ hcd-rsrc_start = otg_dev-phys_addr;
+ hcd-rsrc_len = otg_dev-base_len;
hcd-self.otg_port = 1;
[Marri] Sure
___
Linuxppc-dev mailing list
Subject: [PATCH 10/10] USB ppc4xx: Add Synopsys DWC OTG driver kernel
configuration and Makefile
From: Tirumala Marri tma...@apm.com
Add Synopsys DesignWare HS USB OTG driver kernel configuration.
Synopsys OTG driver may operate in host only, device only, or OTG mode.
The driver also allows user
-0800, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
v8:
1. Add set_wedge to usb_ep_ops.
v7:
1. Fix sparse tool warnings.
2. Fix checkpatch errors and warnings.
3. Rename USB_OTG config variable to USB_DWC_CONFIG
Tirumala Marri (10):
USB/ppc4xx: Add Synopsys DWC OTG
On Wed, Dec 15, 2010 at 2:17 AM, Neil Jones neil...@gmail.com wrote:
Hi,
I've looked at the patches but your email states there are 10 patches,
I can't see #1 and #10, only 2- 8 ??
It doesn't look like you have resolved the lockdep issues we have been
seeing, please get in contact as it
On Fri, Dec 10, 2010 at 2:44 PM, Greg KH g...@kroah.com wrote:
On Wed, Dec 08, 2010 at 04:28:59PM -0800, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
v6:
1. Replaced register definitions and bit fields with macros.
2. Replace printks with dev_dbg or dev_err functions.
3
Much nicer, thanks.
Do you wish for me to apply this to the tree if it passes review?
thanks,
greg k-h
Yes, please.
Thanks,
marri
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Dec 9, 2010 at 5:24 AM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 09-12-2010 3:32, tma...@apm.com wrote:
From: Tirumala Marritma...@apm.com
Enable gadget support
Signed-off-by: Tirumala R Marritma...@apm.com
Signed-off-by: Fushen Chenfc...@apm.com
Signed-off-by: Mark
Yes please.
Regards,
Marri
On Wed, Dec 8, 2010 at 10:47 PM, Greg KH g...@kroah.com wrote:
On Wed, Dec 08, 2010 at 04:28:59PM -0800, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
v6:
1. Replaced register definitions and bit fields with macros.
2. Replace printks
On Thu, Dec 9, 2010 at 8:52 PM, Alexander Gordeev lasa...@lvk.cs.msu.su wrote:
Hi,
В Wed, 8 Dec 2010 16:28:59 -0800
tmarri at apm.com (tmarri at apm.com) пишет:
From: Tirumala Marri tmarri at apm.com
v6:
1. Replaced register definitions and bit fields with macros.
2. Replace printks
+ msi_mask = of_get_property(dev-dev.of_node, msi-mask, NULL);
+ if (!msi_mask) {
+ err = -1;
+ goto error_out;
+ }
This will return non zero value to probe function which would call
ppc4xx_msi_remove() function. In the ppc4xx_msi_remove() function
On Mon, Nov 29, 2
My apologies in the delay here. I was on holiday for a while and never
got back to review this. A few notes below.
Also, I've added a few patches from Victor for suspend/idle support in
my next branch that cause a minor conflict with this one. It's not a
big
Appreciate your review.
+ static int int_no = 0; /* To remember last used interrupt */
This is a worry. There is nothing AFAIK to stop two drivers (eg. network
scsi) calling into here at the same time, which could lead to
corrupting int_no. If you just want a global counter you need a
I am trying to resubmit a patch for MSI support for ppc4xx devices.
One of the review feedback was not to use the bit map as it is only
for the devices which don’t have hard wired mapping between interrupt
controller interrupts and MSI number. For example intr-ctrl0
interrupt
20 goes
Hi,
I am trying to resubmit a patch for MSI support for ppc4xx devices. One of
the review feedback was not to use the bit map as it is only for the devices
which don’t have hard wired mapping between interrupt controller interrupts
and MSI number. For example intr-ctrl0 interrupt 20 goes to
You definitely need to be able to resolve used but not defined and
defined but not used warnings before tackling a driver conversion
like this. In light of this comment I wonder if it would be
appropriate to submit your original driver, that just duplicated
routines from the ppc440spe
When reposting a patch, please always indicate that this is new
version by using something like [PATCH v2] in the Subject line.
[Marri] I know, but this patch is not modification of previous patch.
It is complete brand new from scratch again. In that case isn't this
will be first version ?
On Thu, Sep 30, 2010 at 12:08 PM, Wolfgang Denk w...@denx.de wrote:
[snip other valid review comments]
This is a header file, yet you add here literally thousands of lines
of
code.
Yes, these functions are entirely too large to be inlined. It looks
like you are trying to borrow too
It would be really preferable to support all those platforms in a
single Linux
image. If technically possible, please try to move this direction.
It is do-able for couple of SoCs. Other SoC DMA engines are quite a bit
different.
Let me first do small steps first and slowly achieve some run
Will both versions of this driver exist in the same kernel build? For
example the iop-adma driver supports iop13xx and iop3xx, but we select
the archtitecture at build time? Or, as I assume in this case, will
the
two (maybe more?) ppc4xx adma drivers all be built in the same image,
more
Did you look at this changelog before sending? It just deletes 4000
lines of code??
[Marri] The reason I have to send it in different file is the size of the
patch.
There seem to be issue with patch sizes 200k or more.
___
Linuxppc-dev mailing list
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On
Behalf Of Ilya Yanok
Sent: Sunday, September 19, 2010 1:01 PM
To: linuxppc-...@ozlabs.org
Subject: Re: [PATCH 1/2] PPC4xx: Generelizing
Mr. Wolfgang
Will this driver ever include any 40x processors? If not, you probably
should use 44x instead (here and everywhere in the rest of the
code).
[Marri] Yes there is 40x based DMA engine we planned to include in the
future.
+/* Pointer to DMA0, DMA1 CP/CS FIFO */
+static void
+clock-frequency = 0; /* Filled in by U-Boot */
Out of curiosity, which version of U-Boot has (or will have) this
support?
[Marri] Currently I am working with u-boot list to accept my patch. It
should
be available as soon as it is accepted.
diff --git
We already have arch/powerpc/configs/ppc40x_defconfig and
arch/powerpc/configs/ppc44x_defconfig in mainline.
What's wrong with using these?
[Marri] Great we already have it. We should remove the defconfigs under
44x then ?
Regards,
Marri
___
On Thu, 9 Sep 2010 09:49:14 -0700
Tirumala Marri tma...@apm.com wrote:
[Marri] Great we already have it. We should remove the defconfigs
under 44x then ?
I'd rather we didn't. I thought Linus' beef was over the churn in the
defconfigs, not the fact that they exist. The 44x defconfigs
CPU portion uses SoC name.
Hm, you're right. Confusing.
Still, the cpu setup functions would make more sense to have the core
name in, not the SoC name. Especially since multiple SoC families might
use the same core, etc.
[Marri] I agree. Probably we need another node which identifies SoC
Is anyone working on Linus suggestion to combine the defconfigs under 44x
or 4xx ?
Thanks,
Marri
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Is anyone working on Linus suggestion to combine the defconfigs under 44x
or 4xx ?
Thanks,
Marri
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Is anyone working on combining defconfigs for 44x or 4xx devices ?
Regards,
Marri
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Linus made a suggestion to that effect? If so, I missed it. Have a
pointer?
There was discussion going on in arm-kernel mailing list. And I see some
patches being submitted for ARM based boards.
I think we can also combine some of the defconfigs under
arch/powerpc/configs/44x/ directory.
On Wed, Sep 08, 2010 at 03:40:37PM -0700, Tirumala Marri wrote:
Is anyone working on Linus suggestion to combine the defconfigs under
44x
or 4xx ?
Do you mean ppc44x_defconfig? Already there.
No it is not there yet. I should have said Linus suggestion about
defconfigs in ARM mailing list
Linus made a suggestion to that effect? If so, I missed it. Have a
pointer?
I am thinking that we can combine arches, Canyonlands, glacier, redwood
and eiger can be combined as ppc46x_defconfig.
here is the defconfig example ---
#
# Automatically generated make config: don't edit
Every new board needs new defconfig. And it is not same as others. It
has
Different features from other.
You make it sound as if that is a hard and fixed rule. It's not. Not
all
boards need a defconfig. Also, there was recent work to trim the
defconfigs
that exist today down so they
Then the device tree identifier, and the cpu setup functions, etc,
should indicate
464, not APM821xx.
This is new SoC based on 464 cpu core. All the previous SoC device tree
CPU portion uses SoC name.
Also, why add yet another defconfig? Isn't the eval board similar to
many others and can
APM821xx is Applied Micro Circuits Corporations naming convention for
new line of SoCs.
So is it a 440x6 core then? Or what core is inside the SoC?
[Marri] It is 464 core.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
I am seeing weird issue with latest kernel. “make uImage” failes with “no
rule to make target” error message.
Has anything changed recently ?
---msg
{tma...@svdclab61} make 44x/canyonlands_defconfig
#
# configuration written to .config
#
{tma...@svdclab61} make uImage
64 matches
Mail list logo
