Hello.
Subbrathnam, Swaminathan wrote:
Sergei,
I am pretty fine with both DA8xx and DMxxx devices being located in mach-davinci directory.
And I'm not. :-)
Let us not fault Kevin for it and as I see it, it was and is a community enabled decision.
In the end, it was Kevin's decision to which Mark decided to just "give
in". There was no consensus ever on this topic, e.g. I've been always
against having things in the single mach-davinci/ directory.
Both architectures share some essential similarities.
The point I am trying to make here is that functionalities such as OHCI and PHY definitions dependant on CFGCHIP register and their hookups etc. are unique to DA8xx family from USB perspective.
Yes, I know.
Whereas DMxxxx family of devices share a common definition sets for PHY and do not share any similarity with DA8xx in the way they are connected to the subsystem
I'm not sure what your last words mean... what subsystem?
and they do not have OHCI interface.
Yes, I know. I'd have gladly included some MUSB specific definitions
there, yet they were all in drivers/usb/musb/davinci.h or
include/linux/usb/musb.h, so there was nothing to include, so the file looks
a bit OHCI-biased. CFGCHIP2 bits are mostly used for MUSB control however,
and so they mostly have direct analogs in the DaVinci's PHY control register.
Given this I definitely feel the need to 2 separate header files.
Given the prior naming tradition (devices.c vs devices-da8xx.c), if that
approach will prevail, I'd definitely prefer to see usb.h for DaVinci stuff
and usb-da8xx.h for DA8xx stuff; that usb_davinci.h displeases me too much
aestetically. :-)
Either way if the general consensus is to have a single usb.h for the whole of DaVinci platform I am fine with that too.
I don't think we could have a consensus here. I'll be always against two
files -- I just don't decide anything here.
I will wait for Kevin's and community's input.
It's sounding like I wasn't a member of the community. :-)
Regards
swami
-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@xxxxxxxxxxxxx]
Sent: Thursday, October 08, 2009 3:41 PM
To: Subbrathnam, Swaminathan
Cc: davinci-linux-open-source@xxxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/7] Subscribes for USB resources for TI DM644x EVM platform.
Hello.
Subbrathnam, Swaminathan wrote:
Sergei,
usb.c contains definitions which are more applicable to DA8xx platform and is not shared in any way with other DaVinci platform devices (DMxxxx).
So what? This is due to Kevin's decision to have everything in the
single directory.
That is the reason I had created usb_davinci.h file. The functionality in this file contains represents the capability of DMxxx devices as compared to DA8xx. I would like to recommend that the usb.h file be changed to usb_da8xx.h in this way there will be clear representation.
I'm totally against creating 2 separate files for DA8xx and DMxxx but
let's hear what Kevin says.
Regards
swami
-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@xxxxxxxxxxxxx]
Sent: Wednesday, October 07, 2009 11:11 PM
To: Subbrathnam, Swaminathan
Cc: davinci-linux-open-source@xxxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/7] Subscribes for USB resources for TI DM644x EVM platform.
Hello.
Swaminathan S wrote:
This patch implements the support for USB VBUS, PHY control, DM644x USB memory
mapsi,
Maps?
IRQ, USB Mode. It initializes for a single instance of MUSB controller.
Signed-off-by: Swaminathan S <swami.iyer@xxxxxx>
[...]
diff --git a/arch/arm/mach-davinci/include/mach/usb_davinci.h b/arch/arm/mach-davinci/include/mach/usb_davinci.h
new file mode 100644
index 0000000..02f8af7
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/usb_davinci.h
Please don't create yet another header where <mach/usb.h> was
intended to be used...
@@ -0,0 +1,41 @@
+/*
+ * This file contains the processor specific USB definitions
+ * of the TI DaVinci platforms.
+ *
+ * Copyright (C) 2009 Texas Instruments.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
