date:20110228

Re: [PATCH 06/10] arm: omap: usb: usbhs core device initialization

2011-02-28 Thread Felipe Balbi

On Sat, Feb 26, 2011 at 04:36:34AM +0530, Keshava Munegowda wrote:
 +void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
 +{
 + struct platform_device  *pdev;
 + int i;
 +
 + pdev = platform_device_alloc(OMAP_USBHS_DEVICE, 0);

this particular pdev should be a static variable. Only his children
should be dynamically allocated.

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/10] usb: host: omap: ehci and ohci simplification

2011-02-28 Thread Felipe Balbi

Hi,

On Sat, Feb 26, 2011 at 04:36:37AM +0530, Keshava Munegowda wrote:
 @@ -148,137 +52,24 @@
  #define  EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
  #define  EHCI_INSNREG05_ULPI_WRDATA_SHIFT0
  
 -/* Values of UHH_REVISION - Note: these are not given in the TRM */
 -#define OMAP_EHCI_REV1   0x0010  /* OMAP3 */
 -#define OMAP_EHCI_REV2   0x50700100  /* OMAP4 */
 +/*-*/
  
 -#define is_omap_ehci_rev1(x) (x-omap_ehci_rev == OMAP_EHCI_REV1)
 -#define is_omap_ehci_rev2(x) (x-omap_ehci_rev == OMAP_EHCI_REV2)
 +static const struct hc_driver ehci_omap_hc_driver;
  
 -#define is_ehci_phy_mode(x)  (x == OMAP_EHCI_PORT_MODE_PHY)
 -#define is_ehci_tll_mode(x)  (x == OMAP_EHCI_PORT_MODE_TLL)
 -#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC)
  
 -/*-*/
 -
 -static inline void ehci_omap_writel(void __iomem *base, u32 reg, u32 val)
 +static inline void ehci_write(void __iomem *base, u32 reg, u32 val)
  {
   __raw_writel(val, base + reg);
  }
  
 -static inline u32 ehci_omap_readl(void __iomem *base, u32 reg)
 +static inline u32 ehci_read(void __iomem *base, u32 reg)

renaming these functions is not part of this patch.

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display

2011-02-28 Thread Semwal, Sumit

Hi,

On Mon, Feb 28, 2011 at 12:57 PM, archit taneja arc...@ti.com wrote:
 Hi,

 On Monday 28 February 2011 12:49 PM, Valkeinen, Tomi wrote:

 On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:

 Hi,

 On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:

snip
 I just realized that changing the driver name will break all scripts
 and
 applications using omapdss sysfs files.

 How does this sound:

 Let's leave the omapdss device name as it is. It represents a super
 device, containing the dss sysfs files and upper level dss management.

 Name the HW module platform drivers as: omapdss_dss, omapdss_venc,
 omapdss_dispc, etc. This would indicate them to be clearly parts of
 DSS,
 and would also prevent any possible name conflict if there would happen
 to be a, say, dsi block in some other HW component.

 Any comments on this?

 I also think we need to stick to the older name, omapdss_dss sounds a
 bit confusing, and I think one of the previous versions had something
 like dss_dss in it and it wasn't approved. Does something like
 omapdss_core or omapdss_dss_core make sense, or is it more
 misleading?

 It is confusing, but so is the hardware naming =). There is a DSS module
 inside the omap display subsystem. That's why I would like to name it
 dss, not core, so it's clear it refers to this DSS module.

 dss_dss looks a bit silly, but I think omapdss_dss is slightly
 better in the sense that it doesn't repeat the same dss, and there is
 an omapdss device, which acts like manager for these module devices.
 But yes, I wouldn't call it perfect either.

 omapdss_dss_core is one option. But then again, TRM doesn't speak of
 core.

 Yes, it might get misleading if someone looking at the code tries to find
 core in the TRM, I guess we should stick to omapdss_dss, this also
 ensures a uniform matching of the platform driver names and the beginning of
 register names for each HW module.

Hmmm... I guess omapdss_dss seems a better name in this view; I'm ok
with this way of naming - do you want me to send a patch for it, or
would you update this patch itself?
~Sumit.

 Archit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display

2011-02-28 Thread Tomi Valkeinen

On Mon, 2011-02-28 at 02:16 -0600, Semwal, Sumit wrote:
 Hi,
 
 On Mon, Feb 28, 2011 at 12:57 PM, archit taneja arc...@ti.com wrote:

snip

  Yes, it might get misleading if someone looking at the code tries to find
  core in the TRM, I guess we should stick to omapdss_dss, this also
  ensures a uniform matching of the platform driver names and the beginning of
  register names for each HW module.
 
 Hmmm... I guess omapdss_dss seems a better name in this view; I'm ok
 with this way of naming - do you want me to send a patch for it, or
 would you update this patch itself?

I've made the change. I changed the commits in my tree according to this
new naming. Quite a bit of changes, so I removed tested-bys from the
patches. I'll do some more testing, and push the changes to my master
branch.

 Tomi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cbus-retu: Add status reg bits and ADC channel definitions

2011-02-28 Thread Felipe Balbi

On Sat, Feb 26, 2011 at 12:18:36AM +0100, Michael Buesch wrote:
 This adds definitions for power management related
 RETU_REG_STATUS bits and a list of ADC channels.
 
 Signed-off-by: Michael Buesch m...@bu3sch.de

this looks fine although I don't have documentation for those :-(

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cbus-tahvo: Add battery related register defines

2011-02-28 Thread Felipe Balbi

On Sat, Feb 26, 2011 at 12:23:24AM +0100, Michael Buesch wrote:
 This adds battery related register defines to the tahvo driver.
 
 Signed-off-by: Michael Buesch m...@bu3sch.de

looks good.

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cbus-retu: Acquire mutex on write operation

2011-02-28 Thread Felipe Balbi

On Sun, Feb 27, 2011 at 12:34:33AM +0100, Michael Buesch wrote:
 The mutex has to be acquired on register write to avoid interference
 with a simultaneous retu_set_clear_reg_bits operation.
 
 Signed-off-by: Michael Buesch m...@bu3sch.de

good catch, please do the same for retu_read_reg()

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch-v2.6.39 03/12] usb: musb: gadget: do not poke with gadget's list_head

2011-02-28 Thread Felipe Balbi

On Fri, Feb 25, 2011 at 07:41:47PM +, Pavol Kurina wrote:
 Felipe Balbi balbi at ti.com writes:
  
  struct usb_request's list_head is supposed to be
  used only by gadget drivers, but musb is abusing
  that. Give struct musb_request its own list_head
  and prevent musb from poking into other driver's
  business.
 
 Hi,
 
 I think, the patch misses to fix the usage of 
 request-list in musb_gadget_dequeue in 
 musb_gadget.c.
 
 I found out by having troubles with f_mass_storage. 
 It needs musb_gadget_dequeue to work properly...
 
 I backported the patch to android-2.6.35 kernel on a 
 omap4 system and also fixed the musb_gadget_dequeue 
 there so f_mass_storage seem to work at least there 
 now...
 
 Can you check this patch regarding some missing bits
 please?

Looks like we need some extra tests to be added to g_zero, I tested with
g_zero and it didn't find that problem. Anyway, here's a patch which
probably fixes what you need to be fixed. Would you test it for me ?

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index da8c93b..bf88a61 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1274,7 +1274,8 @@ cleanup:
 static int musb_gadget_dequeue(struct usb_ep *ep, struct usb_request *request)
 {
struct musb_ep  *musb_ep = to_musb_ep(ep);
-   struct usb_request  *r;
+   struct musb_request req = to_musb_request(request);
+   struct musb_request *r;
unsigned long   flags;
int status = 0;
struct musb *musb = musb_ep-musb;
@@ -1285,10 +1286,10 @@ static int musb_gadget_dequeue(struct usb_ep *ep, 
struct usb_request *request)
spin_lock_irqsave(musb-lock, flags);
 
list_for_each_entry(r, musb_ep-req_list, list) {
-   if (r == request)
+   if (r == req)
break;
}
-   if (r != request) {
+   if (r != req) {
DBG(3, request %p not queued to %s\n, request, ep-name);
status = -EINVAL;
goto done;

-- 
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3]OMAP: DSS2: Abstract away DSI VC information from dsi panel drivers

2011-02-28 Thread Archit Taneja

The current DSI driver design requires the DSI panel driver to specify the
DSI Virtual Channel and the Panel Virtual Channel ID for the transfer of
commands and frame data. Out of these, only the second parameter is a property
of the Panel.

The DSI Virtual Channel in use by the panel driver ideally shouldn't be provided
by the panel driver. The current design leads to the following issues:
-Multiple panels connected to the same DSI interface would be unaware of the
VC's in use.
-Hard coded Virtual Channel numbers in panel drivers which is not generic.
-No clean way of configuring DSI for panels which need atleast 2 DSI Virtual
Channels.
-No clean way of configuring DSI for the special case where a panel may have 2
or VC ID's corresponding to it.

The panel driver should, instead, request for, and release DSI Virtual Channels
through calls to the DSI driver. The DSI driver should return VC numbers which
the panel can use. The panel driver then uses this VC to either send pixel data,
send commands and receive data from the panel. The DSI driver then automatically
configures the Virtual Channel source to either Video Port or L4 Slave Port.

This patch set tries to achieve the above design, and make Panel Taal driver use
this approach.

Note:
Patches can be tested on:
http://dev.omapzoom.org/?p=axelcx/kernel-display.git;a=shortlog;h=refs/heads/lo-dss2-Feb25

Archit Taneja (3):
OMAP: DSS2: Functions to request/release DSI VCs
OMAP: DSS2: Use request / release calls in Taal for DSI Virtual
Channels.
OMAP: DSS2: Taal: Use 2 DSI Virtual Channels for Taal

arch/arm/plat-omap/include/plat/display.h |3 +
drivers/video/omap2/displays/panel-taal.c | 121 +
drivers/video/omap2/dss/dsi.c | 58 --
3 files changed, 124 insertions(+), 58 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

1 2 >

1 - 100 of 133 matches

Mail list logo