Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: > On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote: > > I guess the fact is that DRM concepts do not really match the OMAP DSS > > hardware, and we'll have to use whatever gives us least problems. > > Actually, I think it does map fairly well to the hardware.. at least > more so than to omapdss ;-) Hm, I'm not sure I understand, omapdss concepts map directly to the hardware. > The one area that kms mismatches a bit is decoupling of ovl from mgr > that we have in our hw.. I've partially solved that a while back w/ What do you mean with that? Ovls and mgrs are one entity in KMS? Didn't the drm_plane stuff separate these? > For enabling/disabling an output (manager+encoder), this is relatively > infrequent, so it can afford to block to avoid races. (Like userspace > enabling and then rapidly disabling an output part way through the > enable.) But enabling/disabling an overlay, or adjusting position or > scanout address must not block. And ideally, if possible, switching > an overlay between two managers should not block. Adjusting the position or address of the buffer are simple, they can be easily done without any blocking. But ovl enable/disable and switching an ovl to another mgr do (possibly) take multiple vsyncs (and in the switch case, vsyncs of two separate outputs). So if those do not block, we'll need to handle them as a state machine and try to avoid races etc. It'll be "interesting". However, we can sometimes do those operations immediately. So I think we should have these conditional fast-paths in the code, and do them in non-blocking manner when possible. > I'll look again, but as far as I remember that at least wasn't > addressing the performance issues from making overlay enable/disable Right, it wasn't addressing those issues. But your branch doesn't really address those issues either, as it doesn't handle the problems related to ovl enable/disable. > synchronous. And fixing that would, I expect, trigger the same > problems that I already spent a few days debugging before switching > over to handle apply in omapdrm. I was under the impression that the apply mechanism, the caching and setting of the configs, was the major issue you had. But you're hinting that the actual problem is related to ovl enable/disable? I haven't tried fixing the ovl enable/disable, as I didn't know it's an issue for omapdrm. Or are they both as big issues? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use
On Wed, Aug 1, 2012 at 9:06 PM, Paul Walmsley wrote: > > Hi Jon et al, > > Here's what I'm planning to queue here. The only changes from what Jon > posted are the patch changelog and some checkpatch fixes. If anyone > has any final comments, please let me know. > > > - Paul > > From: Paul Walmsley > Date: Wed, 1 Aug 2012 09:11:20 -0600 > Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU > clockdomain idle problems > > The idle status of the IP blocks and clocks inside the EMU clockdomain > isn't taken into account by the PRCM hardware when deciding whether > the clockdomain is idle. Add a workaround flag in the clockdomain > code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add > the code necessary to support it. > > If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the > clockdomain will be forced active whenever an IP block inside that > clockdomain is in use, even if the clockdomain supports > hardware-supervised idle. When the kernel indicates that the last > active IP block inside the clockdomain is no longer used, the > clockdomain will be forced idle, or, if that mode is not supported in > the hardware, it will be placed into hardware-supervised idle. > > This patch is an equal collaboration with Jon Hunter > . Ming Lei , Will Deacon > , Madhav Vij , Kevin Hilman > , Benoît Cousson , and Santosh > Shilimkar all made essential contributions > to the understanding of EMU clockdomain power management on OMAP. > > Signed-off-by: Paul Walmsley > Cc: Jon Hunter > Cc: Ming Lei > Cc: Will Deacon > Cc: Madhav Vij > Cc: Kevin Hilman > Cc: Benoît Cousson > Cc: Santosh Shilimkar > --- Acked-by: Santosh Shilimkar -- 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 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
Hi Omar
On Mon, 16 Jul 2012, Omar Ramirez Luna wrote:
> This APIs are meant to be an interface to hwmod assert/deassert
> function, omap devices can call them through their platform data
> to control their reset lines, they are expected to know the name
> of the reset line they are trying to control.
>
> Signed-off-by: Omar Ramirez Luna
This one has been queued for 3.7 with a few changes. Some more detail was
added to the function documentationrovement. Also the multiple
assignments were removed per Documentation/CodingStyle chapter 1:
"Don't put multiple assignments on a single line either."
Please let me know if you have any comments.
- Paul
From: Omar Ramirez Luna
Date: Mon, 16 Jul 2012 14:21:25 -0500
Subject: [PATCH] ARM: OMAP2+: omap_device: expose hwmod assert/deassert to
omap devices
This API is meant to be an interface to hwmod assert/deassert
function, omap devices can call them through their platform data to
control their reset lines, they are expected to know the name of the
reset line they are trying to control.
Signed-off-by: Omar Ramirez Luna
[p...@pwsan.com: tweaked some documentation; fixed CodingStyle issue]
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 55 +
2 files changed, 59 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 4327b2c..27bcc24 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -118,6 +118,10 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev);
/* Other */
+int omap_device_assert_hardreset(struct platform_device *pdev,
+const char *name);
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+const char *name);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..3b02312 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -925,6 +925,61 @@ int omap_device_shutdown(struct platform_device *pdev)
}
/**
+ * omap_device_assert_hardreset - set a device's hardreset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * name of the reset line
+ *
+ * Set the hardreset line identified by @name on the IP blocks
+ * associated with the hwmods backing the platform_device @pdev. All
+ * of the hwmods associated with @pdev must have the same hardreset
+ * line linked to them for this to work. Passes along the return value
+ * of omap_hwmod_assert_hardreset() in the event of any failure, or
+ * returns 0 upon success.
+ */
+int omap_device_assert_hardreset(struct platform_device *pdev, const char
*name)
+{
+ struct omap_device *od = to_omap_device(pdev);
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ ret = omap_hwmod_assert_hardreset(od->hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
+ * omap_device_deassert_hardreset - release a device's hardreset line
+ * @pdev: struct platform_device * to reset
+ * @name: const char * name of the reset line
+ *
+ * Release the hardreset line identified by @name on the IP blocks
+ * associated with the hwmods backing the platform_device @pdev. All
+ * of the hwmods associated with @pdev must have the same hardreset
+ * line linked to them for this to work. Passes along the return
+ * value of omap_hwmod_deassert_hardreset() in the event of any
+ * failure, or returns 0 upon success.
+ */
+int omap_device_deassert_hardreset(struct platform_device *pdev,
+ const char *name)
+{
+ struct omap_device *od = to_omap_device(pdev);
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ ret = omap_hwmod_deassert_hardreset(od->hwmods[i], name);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+/**
* omap_device_align_pm_lat - activate/deactivate device to match wakeup lat
lim
* @od: struct omap_device *
*
--
1.7.10.4
--
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 v1 1/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
On 07/31/12 02:50, Juha Kuikka wrote: > Similarly to am3703, it seems that omap3503 has an IVA control > registers even though the subsystem is non-functional. > > This patch sets the OMAP3_HAS_IVA_REGS feature to force > initialization of there registers. > > Based in Mark A. Greer's patch > "ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature". > > Signed-off-by: Juha Kuikka > --- > arch/arm/mach-omap2/id.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 4072fbd..45d3eb4 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void) > if (cpu_is_omap3630()) > omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS; If you add the flag below, then you probably want to remove it from here, right? > if (cpu_is_omap3430() || cpu_is_omap3630()) > - omap_features |= OMAP3_HAS_IO_WAKEUP; > + omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS; > if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 || > omap_rev() == OMAP3430_REV_ES3_1_2) > omap_features |= OMAP3_HAS_IO_CHAIN_CTRL; -- Regards, Igor. -- 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 v4] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
On Wed, 2012-08-01 at 07:56 -0500, Ricardo Neri wrote: > DSS code wrongly assumes that VENC is always available as source for the > external > sync signal for the display controller DIGIT channel. One cannot blindly > write/read > the value of DSS_CONTROL[15] as in certain processors (e.g., OMAP5) this > operation > may not be valid. If the the sync source is not read correctly, the callers of > dss_get_hdmi_venc_clk_source might make wrong assumptions about, for instance, > video timings. > > Logic is added to correctly get the sync signal based on the available > displays > in the DIGIT channel. The source is set only if both VENC and HDMI are > supported. Thanks, applied. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence
Hello OMar, On Mon, 16 Jul 2012, Omar Ramirez Luna wrote: > For a reset sequence to complete cleanly, a module needs its > associated clocks to be enabled, otherwise the timeout check > in prcm code can print a false failure (failed to hardreset) > that occurs because the clocks aren't powered ON and the status > bit checked can't transition without them. > > Signed-off-by: Omar Ramirez Luna Is enabling the clocks sufficient? Or do we also need to enable the IP block, e.g. by calling if (soc_ops.enable_module) soc_ops.enable_module(oh); as we do on OMAP4+ in _enable() ? - Paul -- 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: OMAP3: USB: EHCI broken on 3.5?
(Adding in the USB mailing list)...
It seems that the clocks are registered with a .dev_id of "usbhs_omap" on
OMAP3xxx, but not OMAP4xxx, and that this causes the clk_get() in ehci-omap.c
to fail.
The following fixes the problem for me, but I've no idea if this is the correct
fix or not?
(sorry if the patch is mangled, using a naff webmail client).
--- a/arch/arm/mach-omap2/clock3xxx_data.c 2012-07-21 21:58:29.0
+0100
+++ b/arch/arm/mach-omap2/clock3xxx_data.c 2012-08-02 09:07:58.205633679
+0100
@@ -3391,15 +3391,15 @@
CLK(NULL, "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK("usbhs_omap", "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK("usbhs_omap", "utmi_p1_gfclk",&dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "utmi_p2_gfclk",&dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "xclk60mhsp1_ck", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "xclk60mhsp2_ck", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_host_hs_utmi_p1_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_host_hs_utmi_p2_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_tll_hs_usb_ch0_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_tll_hs_usb_ch1_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "init_60m_fclk",&dummy_ck,
CK_3XXX),
+ CLK(NULL, "utmi_p1_gfclk",&dummy_ck, CK_3XXX),
+ CLK(NULL, "utmi_p2_gfclk",&dummy_ck, CK_3XXX),
+ CLK(NULL, "xclk60mhsp1_ck", &dummy_ck, CK_3XXX),
+ CLK(NULL, "xclk60mhsp2_ck", &dummy_ck, CK_3XXX),
+ CLK(NULL, "usb_host_hs_utmi_p1_clk", &dummy_ck,
CK_3XXX),
+ CLK(NULL, "usb_host_hs_utmi_p2_clk", &dummy_ck,
CK_3XXX),
+ CLK(NULL, "usb_tll_hs_usb_ch0_clk", &dummy_ck,
CK_3XXX),
+ CLK(NULL, "usb_tll_hs_usb_ch1_clk", &dummy_ck,
CK_3XXX),
+ CLK(NULL, "init_60m_fclk",&dummy_ck, CK_3XXX),
CLK(NULL, "usim_fck", &usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_3XXX),
CLK(NULL, "wkup_32k_fck", &wkup_32k_fck, CK_3XXX),
Cheers,
Joe
-Original Message-
From: "Joe Woodward"
To: "linux-omap@vger.kernel.org"
Date: Tue, 31 Jul 2012 13:42:07 +0100
Subject: OMAP3: USB: EHCI broken on 3.5?
> I have a GUMSTIX Overo AirSTORM (AM3703-based).
>
> When running a 3.4 kernel the USB host works just fine!
>
> However when switching to 3.5 I get a few new warning messages and USB
> host no longer works.
>
> dmesg log after successfully loading the module (modprobe echi-hcd) on
> 3.4:
> [ 23.424499] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
> Driver
> [ 23.431427] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
> [ 23.431732] ehci-omap ehci-omap.0: failed to get ehci port1
> regulator
> [ 23.431762] gpio_request: gpio-183 (USB2 PHY reset) status -16
> [ 24.433471] ehci-omap ehci-omap.0: phy reset operation timed out
> [ 24.433502] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
> cc=1 pcc=3 ordered ports=3
> [ 24.433532] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1
> uframes 256/512/1024 park
> [ 24.433532] ehci-omap ehci-omap.0: reset command 0080b02 park=3
> ithresh=8 period=1024 Reset HALT
> [ 24.433563] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [ 24.440063] ehci-omap ehci-omap.0: new USB bus registered, assigned
> bus number 1
> [ 24.448120] ehci-omap ehci-omap.0: park 0
> [ 24.448181] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
> [ 24.454162] ehci-omap ehci-omap.0: init command 0010005 (park)=0
> ithresh=1 period=512 RUN
> [ 24.474517] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> [ 24.481597] usb usb1: default language 0x0409
> [ 24.481658] usb usb1: udev 1, busnum 1, minor = 0
> [ 24.481689] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [ 24.488830] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [ 24.496398] usb usb1: Product: OMAP-EHCI Host Controller
> [ 24.501953] usb usb1: Manufacturer: Linux 3.4.0 ehci_hcd
> [ 24.507537] usb usb1: SerialNumber: ehci-omap.0
> [ 24.528747] usb usb1: usb_probe_device
> [ 24.528778] usb usb1: configuration #1 chosen from 1 choice
> [ 24.529479] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [ 24.530212] hub 1-0:1.0: usb_probe_interface
> [ 24.530242] hub 1-0:1.0: usb_probe_interface - got id
> [ 24.530303] hub 1-0:1.0: USB hub found
> [ 24.534362] hub 1-0:1.0: 3 ports detected
> [ 24.538635] hub 1-0:1.0: standalone hub
> [ 24.5
Re: am3517: USB state in 3.5-rc6
Am 24.07.2012 17:30, schrieb Jan Lübbe:
> Hi,
>
> On Mon, 2012-07-23 at 09:08 +0200, Yegor Yefremov wrote:
>> After getting MMC working I now have following issues: both musb and EHCI
>> make problems.
>>
>> musb:
>>
>> musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
>> musb-am35x musb-am35x: failed to get clock
>> musb-am35x: probe of musb-am35x failed with error -2
> I've seen the same problem after merging omap-devel-d-for-3.6 onto v3.5.
> (see
> http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=tag;h=refs/tags/omap-devel-d-for-3.6)
>
> So far I've worked around it like this (I'm not sure this is the correct
> approach, but it works):
>
> diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
> index 9f3eda9..2184693 100644
> --- a/drivers/usb/musb/am35x.c
> +++ b/drivers/usb/musb/am35x.c
> @@ -480,14 +480,14 @@ static int __devinit am35x_probe(struct platform_device
> *pdev)
> goto err1;
> }
>
> - phy_clk = clk_get(&pdev->dev, "fck");
> + phy_clk = clk_get(&pdev->dev, "hsotgusb_ick");
> if (IS_ERR(phy_clk)) {
> dev_err(&pdev->dev, "failed to get PHY clock\n");
> ret = PTR_ERR(phy_clk);
> goto err2;
> }
>
> - clk = clk_get(&pdev->dev, "ick");
> + clk = clk_get(&pdev->dev, "hsotgusb_fck");
> if (IS_ERR(clk)) {
> dev_err(&pdev->dev, "failed to get clock\n");
> ret = PTR_ERR(clk);
Jan, thanks for the patch. It helped. I've taken the upcoming vanila 3.6 kernel
and got both musb and EHCI running. I will test it further after linux-omap
will be merged with linux-2.6 after merge window is closed.
Yegor
--
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: [RFC PATCH 22/29] OMAPDSS: DISPC: Setup writeback go, enable and channel_in functions
On Tue, Dec 27, 2011 at 6:07 PM, Archit Taneja wrote:
> Fill up dispc_wb_go(), dispc_wb_go_busy(), dispc_wb_enable() and
> dispc_wb_get_channel_in()/set_channel_in() with writeback register writes.
> Make
> a minor modification in dss_wb_write_regs_extra() to pass the plane_id instead
> of the writeback id when calling dispc_wb_set_channel_in().
>
> Setup dispc_wb_enable() as dispc_enable_lcd_out() function and wait for the
> FRAMEDONEWB interrupt while disabling writeback.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/apply.c |2 +-
> drivers/video/omap2/dss/dispc.c | 68
> +++
> drivers/video/omap2/dss/dss.h |2 +-
> 3 files changed, 63 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index dd1fd419..57b061f 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -690,7 +690,7 @@ static void dss_wb_write_regs_extra(struct
> omap_dss_writeback *wb)
> if (!wp->extra_info_dirty)
> return;
>
> - dispc_wb_set_channel_in(wb->id, wp->channel_in);
> + dispc_wb_set_channel_in(wb->plane_id, wp->channel_in);
> dispc_ovl_set_fifo_threshold(wb->plane_id, wp->fifo_low,
> wp->fifo_high);
>
> wp->extra_info_dirty = false;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index c7de56d..cbce120 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -510,12 +510,26 @@ void dispc_mgr_go(enum omap_channel channel)
>
> bool dispc_wb_go_busy(int id)
> {
> - return false;
> + return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> }
>
> void dispc_wb_go(int id)
> {
> - return;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + bool enable, go;
> +
> + enable = REG_GET(DISPC_OVL_ATTRIBUTES(wb->plane_id), 0, 0) == 1;
> +
> + if (!enable)
> + return;
> +
> + go = REG_GET(DISPC_CONTROL2, 6, 6) == 1;
> + if (go) {
> + DSSERR("GO bit not down for WB\n");
> + return;
> + }
> +
> + REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
> }
>
> static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32
> value)
> @@ -903,16 +917,24 @@ static enum omap_channel dispc_ovl_get_channel_out(enum
> omap_plane plane)
> return channel;
> }
>
> -void dispc_wb_set_channel_in(int id, enum dss_writeback_channel_in ch_in)
> +void dispc_wb_set_channel_in(int plane, enum dss_writeback_channel_in ch_in)
> {
> - return;
> + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ch_in, 18, 16);
> }
>
> static enum omap_channel dispc_wb_get_channel_in(int plane)
> {
> - /* Return LCD channel for now */
> + int channel_in = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 18, 16);
>
> - return OMAP_DSS_CHANNEL_LCD;
> + switch (channel_in) {
> + case OMAP_DSS_WB_LCD2_MGR:
> + return OMAP_DSS_CHANNEL_LCD2;
> + case OMAP_DSS_WB_TV_MGR:
> + return OMAP_DSS_CHANNEL_DIGIT;
> + case OMAP_DSS_WB_LCD1_MGR:
> + default:
> + return OMAP_DSS_CHANNEL_LCD;
> + };
> }
>
What about other cases of pipelines and overlays here? You have
considered only overlays and that too ignored OMAP_DSS_CHANNEL_LCD3.
The channel_in parameter of DISPC_WB_ATTRIBUTES does handle the
following cases as well:
0x0: Primary LCD overlay output
0x1: Secondary LCD output
0x2: TV overlay output
0x7: Third LCD output
0x3: Graphics pipeline output
0x4: Video1 pipeline output
0x5: Video2 pipeline output
0x6: Video3 pipeline output
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> @@ -2138,7 +2160,39 @@ void dispc_mgr_enable(enum omap_channel channel, bool
> enable)
>
> void dispc_wb_enable(int id, bool enable)
> {
> - return;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + enum omap_plane plane = wb->plane_id;
> + struct completion frame_done_completion;
> + bool is_on;
> + int r;
> + u32 irq;
> +
> + is_on = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
> + irq = DISPC_IRQ_FRAMEDONEWB;
> +
> + if (!enable && is_on) {
> + init_completion(&frame_done_completion);
> +
> + r = omap_dispc_register_isr(dispc_disable_isr,
> + &frame_done_completion, irq);
> +
> + if (r)
> + DSSERR("failed to register FRAMEDONEWB isr\n");
> + }
> +
> + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 0, 0);
> +
> + if (!enable && is_on) {
> + if (!wait_for_completion_timeout(&frame_done_completion,
> + msecs_to_jiffies(100)))
> + DSSERR("timeout waiting for FRAMEDONEWB\n");
> +
> + r = omap_dispc_unregister_isr(dispc_d
[PATCH] drivers: usb: musb: cleanup while removing musb omap glue driver
No functional change. Just replaced the call to platform_device_del and platform_device_put with platform_device_unregister. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/musb/omap2430.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 5fdb9da..392fc7a 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -509,8 +509,7 @@ static int __devexit omap2430_remove(struct platform_device *pdev) struct omap2430_glue*glue = platform_get_drvdata(pdev); cancel_work_sync(&glue->omap_musb_mailbox_work); - platform_device_del(glue->musb); - platform_device_put(glue->musb); + platform_device_unregister(glue->musb); return 0; } -- 1.7.9.5 -- 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: [RFC PATCH 21/29] OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
On Tuesday 27 December 2011 06:07 PM, Archit Taneja wrote:
> Call dispc_plane_setup() through dispc_wb_setup() to configure overlay-like
> parameters. Create a helper function in writeback.c called
> dss_wb_calc_params()
> which for now calculates the input width and height which goes to writeback.
> Create a dummy dispc function which returns the channel of the manager to
> which
> the writeback pipeline is connected.
>
> The parameters in dispc_plane_setup() which do not hold for writeback are
> filled
> passed as zeroes or false, dispc_plane_setup() takes care of not configuring
> them if the plane is writeback.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/apply.c |5 -
> drivers/video/omap2/dss/dispc.c | 33 +++--
> drivers/video/omap2/dss/dss.h |6 +-
> drivers/video/omap2/dss/writeback.c | 17 +
> 4 files changed, 57 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index a17cc47..dd1fd419 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -661,6 +661,7 @@ static void dss_wb_write_regs(struct omap_dss_writeback
> *wb)
> {
> struct wb_priv_data *wp = get_wb_priv(wb);
> struct omap_dss_writeback_info *wi;
> + u16 in_width, in_height;
> int r;
>
> if (!wp->enabled || !wp->info_dirty)
> @@ -670,7 +671,9 @@ static void dss_wb_write_regs(struct omap_dss_writeback
> *wb)
>
> wi = &wp->info;
>
> - r = dispc_wb_setup(wb->id, wi);
> + dss_wb_calc_params(wb, wi, &in_width, &in_height);
> +
> + r = dispc_wb_setup(wb->id, wi, in_width, in_height);
> if (r) {
> DSSERR("dispc_wb_setup failed\n");
> return;
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 3a40f8e..c7de56d 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -908,6 +908,13 @@ void dispc_wb_set_channel_in(int id, enum
> dss_writeback_channel_in ch_in)
> return;
> }
>
> +static enum omap_channel dispc_wb_get_channel_in(int plane)
> +{
> + /* Return LCD channel for now */
> +
> + return OMAP_DSS_CHANNEL_LCD;
> +}
> +
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> enum omap_burst_size burst_size)
> {
> @@ -1935,9 +1942,31 @@ int dispc_ovl_setup(enum omap_plane plane, struct
> omap_overlay_info *oi,
> return r;
> }
>
> -int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi)
> +int dispc_wb_setup(int id, struct omap_dss_writeback_info *wi,
> + u16 in_width, u16 in_height)
> {
> - return 0;
> + int r;
> + struct omap_dss_writeback *wb = omap_dss_get_writeback(id);
> + const int pos_x = 0, pos_y = 0;
> + const u8 zorder = 0, global_alpha = 0;
> + const bool chroma_upscale = false, ilace = false, replication = false;
> + enum omap_channel channel;
> +
> + channel = dispc_wb_get_channel_in(wb->plane_id);
> +
> + DSSDBG("dispc_wb_setup %d, pa %x, pa_uv %x, %d,%d -> %dx%d, cmode %x, "
> + "rot %d, mir %d, chan %d\n",
> + wb->id, wi->paddr, wi->p_uv_addr, in_width, in_height,
> + wi->buf_width, wi->buf_height, wi->color_mode, wi->rotation,
> + wi->mirror, channel);
> +
> + r = dispc_plane_setup(wb->plane_id, channel, wb->caps, wi->paddr,
> + wi->p_uv_addr, in_width, pos_x, pos_y, in_width, in_height,
> + wi->buf_width, wi->buf_height, wi->color_mode, wi->rotation,
> + wi->mirror, zorder, wi->pre_mult_alpha, global_alpha,
> + wi->rotation_type, chroma_upscale, ilace, replication);
The only note worthy difference here is use of omap_dss_writeback_info
*wi instead of omap_overlay_info *oi in dispc_ovl_setup(). If
omap_overlay_info can be used instead of omap_dss_writeback_info then
the same dispc_ovl_setup() would have been used to handle writeback as a
plane just like others but with extra checks for (plane == OMAP_DSS_WB).
I think this way it would have been much cleaner otherwise it looks good.
> +
> + return r;
> }
>
> int dispc_ovl_enable(enum omap_plane plane, bool enable)
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 1b128f1..69b4793 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -249,6 +249,9 @@ void dss_init_writeback(void);
> void dss_uninit_writeback(void);
> int writeback_init_display(struct omap_dss_device *dssdev);
> enum dss_writeback_channel_in dss_wb_calc_channel_in(struct
> omap_dss_writeback *wb);
> +void dss_wb_calc_params(struct omap_dss_writeback *wb,
> + struct omap_dss_writeback_info *wi, u16 *in_width,
> + u16 *in_height);
> int dss_wb_simple_check(struct omap_dss_writeback *wb,
> const struct omap_dss_writeback_info *info);
>
[PATCH] spi: omap2-mcspi: Fix the error handling in probe
The kfree() is taken care of by the spi core (spi_master_release() function) that is called once the last reference to the underlying struct device has been released. So the driver need not call kfree. Also the put was missed in some of the error handling fix the same. There by fixing the missing device_put in some of the error paths. Acked-by: Guenter Roeck Reported-by: Guenter Roeck Signed-off-by: Shubhrajyoti D --- drivers/spi/spi-omap2-mcspi.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index bc47781..b2fb141 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1228,18 +1228,16 @@ static int __devinit omap2_mcspi_probe(struct platform_device *pdev) status = spi_register_master(master); if (status < 0) - goto err_spi_register; + goto disable_pm; return status; -err_spi_register: - spi_master_put(master); disable_pm: pm_runtime_disable(&pdev->dev); dma_chnl_free: kfree(mcspi->dma_channels); free_master: - kfree(master); + spi_master_put(master); platform_set_drvdata(pdev, NULL); return status; } -- 1.7.5.4 -- 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 v7 11/11] arm/dts: am33xx: add phy phandle to usbss
From: Ajay Kumar Gupta Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Ravi Babu --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index b03a9b5..d3ab69a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0_mode = <3>; port1_mode = <1>; power = <250>; + usb0-phy = <&usb0_phy>; + usb1-phy = <&usb1_phy>; }; }; }; -- 1.7.0.4 -- 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 v7 06/11] arm/dts: am33xx: Add dt data for usbss
From: Ajay Kumar Gupta
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = "ti,musb-am33xx";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+ port0_mode = <3>;
+ port1_mode = <1>;
+ power = <250>;
+ };
};
};
--
1.7.0.4
--
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 v7 05/11] usb: musb: dsps: add dt support
From: Ajay Kumar Gupta
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 60 +---
2 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be "ti,musb-am33xx"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ represents PERIPHERAL.
+ - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+ represents PERIPHERAL.
+ - power : Should be "250". This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index c529ccb..13c9341 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,10 @@
#include "musb_core.h"
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue->dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev->platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue->musb[id] = musb;
- pdata->platform_ops = &dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, "failed to add resources\n");
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb platfrom data\n");
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb hdrc config\n");
+ goto err2;
+ }
+
+ of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+ sprintf(res_name, "port%d_mode", id);
+ of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+ config->multipoint = of_property_read_bool(np, "multipoint");
+
+ pdata->config = config;
+ }
+
+ pdata->platform_ops = &dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id->driver_data;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(&pdev->dev, "fail to get matching of_match struct\n");
+ ret = -EINVAL;
+ go
[PATCH v7 09/11] usb: musb: dsps: remove explicit NOP device creation
From: Ajay Kumar Gupta As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta Signed-off-by: Ravi Babu --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 13c9341..891c2be 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb->mregs += wrp->musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(); + /* Get the NOP PHY */ musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.0.4 -- 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 v7 10/11] usb: musb: dsps: get the PHY using phandle api
AM33xx has two PHY of same type used by each musb controller so
use phandle of phy nodes to get the phy pointer.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt |2 ++
drivers/usb/musb/musb_dsps.c |5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 9782585..e2702df 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,6 +12,8 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+ - usb0-phy : phandle for usb0 NOP PHY
+ - usb1-phy : phandle for usb1 NOP PHY
NOP USB PHY
- compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 891c2be..255e71a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -416,9 +416,11 @@ static int dsps_musb_init(struct musb *musb)
{
struct device *dev = musb->controller;
struct platform_device *pdev = to_platform_device(dev);
+ struct platform_device *parent_pdev = to_platform_device(dev->parent);
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
void __iomem *reg_base = musb->ctrl_base;
+ char name[10];
u32 rev, val;
int status;
@@ -426,7 +428,8 @@ static int dsps_musb_init(struct musb *musb)
musb->mregs += wrp->musb_core_offset;
/* Get the NOP PHY */
- musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ sprintf(name, "usb%d-phy", pdev->id);
+ musb->xceiv = devm_usb_get_phy_by_phandle(&parent_pdev->dev, name);
if (IS_ERR_OR_NULL(musb->xceiv))
return -ENODEV;
--
1.7.0.4
--
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 v7 02/11] usb: musb: kill global and static for multi instance
From: Ajay Kumar Gupta
Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c |8 +++-
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index a565fc2..e781800 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -1804,10 +1805,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb->xceiv->state != old_state) {
- old_state = musb->xceiv->state;
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
}
@@ -2115,11 +2115,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2138,10 +2133,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2151,7 +2142,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
/* this gets called on rmmod.
@@ -2164,9 +2156,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(&pdev->dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev->dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev->parent->dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 84436f7..5ec32b9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -450,6 +450,10 @@ struct musb {
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
#endif
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s->private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *file;
int ret;
- root = debugfs_create_dir("musb", NULL);
+ root = debugfs_create_dir(dev_name(musb->controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb->debugfs_root = root;
return 0;
@@ -274,5 +272,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb->debugfs_root);
}
--
1.7.0.4
--
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 v7 08/11] arm/dts: am33xx: add dt data for usb nop phy
From: Ajay Kumar Gupta
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = "i2c3";
};
+ usb0_phy: phy0 {
+ compatible = "nop-xceiv-usb";
+ };
+
+ usb1_phy: phy1 {
+ compatible = "nop-xceiv-usb";
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = "ti,musb-am33xx";
ti,hwmods = "usb_otg_hs";
--
1.7.0.4
--
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 v7 00/11] usb: musb: adding multi instance support
This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to linux-omap (master branch) + Vaibhav baseport patches on his tree at [3] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [1] + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] + Damodar's recent patch at [2] and have been tested on Beaglebone board. 1. http://marc.info/?l=linux-usb&m=134070369306112&w=2 2. http://marc.info/?l=linux-usb&m=134200284230689&w=2 3. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 4. http://marc.info/?l=linux-usb&m=134131746111637&w=2 5. http://marc.info/?l=linux-usb&m=134131746411639&w=2 6. http://marc.info/?l=linux-usb&m=134062716011251&w=2 7. http://marc.info/?l=linux-usb&m=134061179405213&w=2 Changes from v6: - Removed parent_pdev to get glue and used dev_get_getdrv() as per Felipe's comment - use pr_debug() instead of pr_info() as per Felipe's comment Changes from v5: - Removed musb->id as per Felipe's comment - used nop_ida as per Felipe's comment Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing "id" from phy struct and removing unneeded "#else" part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the "ti" string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (10): usb: musb: add musb_ida for multi instance support usb: musb: kill global and static for multi instance usb: musb: am335x: add support for dual instance usb: otg: nop: add support for multiple tranceiver usb: musb: dsps: add dt support arm/dts: am33xx: Add dt data for usbss usb: otg: nop: add dt support arm/dts: am33xx: add dt data for usb nop phy usb: musb: dsps: remove explicit NOP device creation arm/dts: am33xx: add phy phandle to usbss Ravi Babu (1): usb: musb: dsps: get the PHY using phandle api .../devicetree/bindings/usb/am33xx-usb.txt | 19 ++ arch/arm/boot/dts/am33xx.dtsi | 21 ++ drivers/usb/musb/am35x.c | 44 +++-- drivers/usb/musb/blackfin.c| 28 ++- drivers/usb/musb/da8xx.c | 36 +++- drivers/usb/musb/davinci.c | 38 +++-- drivers/usb/musb/musb_core.c | 53 -- drivers/usb/musb/musb_core.h |6 + drivers/usb/musb/musb_debugfs.c|8 +- drivers/usb/musb/musb_dsps.c | 210 +--- drivers/usb/musb/omap2430.c| 26 ++- drivers/usb/musb/tusb6010.c| 30 ++- drivers/usb/musb/ux500.c | 33 +++- drivers/usb/otg/nop-usb-xceiv.c| 64 ++- include/linux/usb/otg.h|4 +- 15 files changed, 455 insertions(+), 165 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- 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 v7 03/11] usb: musb: am335x: add support for dual instance
From: Ajay Kumar Gupta
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
drivers/usb/musb/musb_dsps.c | 113 +-
1 files changed, 67 insertions(+), 46 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..7a09d55 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue->usb_ctrl);
+ usbphycfg = __raw_readl(glue->usb_ctrl[id]);
if (on) {
if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue->usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue->usb_ctrl);
+ __raw_writel(usbphycfg, glue->usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -207,8 +211,8 @@ static void otg_timer(unsigned long _musb)
struct musb *musb = (void *)_musb;
void __iomem *mregs = musb->mregs;
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
u8 devctl;
unsigned long flags;
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE)
- mod_timer(&glue->timer,
+ mod_timer(&glue->timer[pdev->id],
jiffies + wrp->poll_seconds * HZ);
else
musb->xceiv->state = OTG_STATE_A_IDLE;
@@ -261,9 +265,8 @@ static void otg_timer(unsigned long _musb)
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
{
struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev->parent);
- struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dsps_glue *glue = dev_get_drvdata(dev->parent);
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb->controller, "%s active, deleting timer\n",
otg_state_string(musb->xceiv->state));
- del_timer(&glue->timer);
- last_timer = jiffies;
+ del_timer(&glue->timer[pdev->id]);
+ glue->last_timer[pdev->id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) && timer_pending(&glue->timer)) {
+ if (time_after(glue->last_timer[pdev->id], timeout) &&
+ timer_pending(&glue->timer[pdev->id])) {
dev_dbg(musb->controller,
[PATCH v7 01/11] usb: musb: add musb_ida for multi instance support
From: Ajay Kumar Gupta
Added musb_ida in musb_core.c to manage the multi core ids.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 31 +++
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 210 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc("musb-hdrc", -1);
+ /* get the musb id */
+ musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+ if (musbid < 0) {
+ dev_err(&pdev->dev, "failed to allocate musb id\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc("musb-hdrc", musbid);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err1;
+ goto err2;
}
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable PHY clock\n");
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
- goto err5;
+ goto err6;
}
+ musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(&pdev->dev, "failed to add platform_data\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(&pdev->dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
goto err0;
}
-
[PATCH v7 04/11] usb: otg: nop: add support for multiple tranceiver
From: Ajay Kumar Gupta
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
drivers/usb/musb/am35x.c|2 +-
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/da8xx.c|2 +-
drivers/usb/musb/davinci.c |4 +-
drivers/usb/musb/musb_dsps.c|8 +++---
drivers/usb/musb/tusb6010.c |4 +-
drivers/usb/otg/nop-usb-xceiv.c | 54 +-
include/linux/usb/otg.h |4 +-
8 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..984e439 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data->set_phy_power(0);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..f1fe728 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb->config->gpio_vrsel);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..a5260b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..c7ef654 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb->xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 7a09d55..c529ccb 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,7 +420,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb->mregs += wrp->musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
+ /* Register NOP driver */
usb_nop_xceiv_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
@@ -456,7 +456,7 @@ static int dsps_musb_init(struct musb *musb)
return 0;
err0:
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return status;
}
@@ -472,9 +472,9 @@ static int dsps_musb_exit(struct musb *musb)
/* Shutdown the on-chip PHY and its PLL. */
musb_dsps_phy_control(glue, pdev->id, 0);
- /* NOP driver needs change if supporting dual instance */
+ /* Unregister NOP driver */
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 64a0e95..3a12330 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1132,7 +1132,7 @@ done:
iounmap(sync);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
}
return ret;
}
@@ -1148,7 +1148,7 @@ static int tusb_musb_exit(struct musb *musb)
iounmap(musb->sync_va);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 803f958..04ddcee 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -31,30 +31,69 @@
#include
#include
#include
+#include
struct nop_usb_xceiv {
struct usb_phy phy;
struct device *dev;
+ struct platform_device *pd;
};
-static struct platform_device *pd;
+static DEFINE_IDA(nop_ida);
-void usb_nop_xceiv_register(void)
+stat
[PATCH v7 07/11] usb: otg: nop: add dt support
From: Ajay Kumar Gupta
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Ravi Babu
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 10 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 04ddcee..a66e3bc 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include
+#include
#include
#include
#include
@@ -188,12 +189,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = "nop-xceiv-usb" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = "nop_usb_xceiv",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
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: [RFC 0/3] solving omapdrm/omapdss layering issues
On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote: > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >> > hardware, and we'll have to use whatever gives us least problems. >> >> Actually, I think it does map fairly well to the hardware.. at least >> more so than to omapdss ;-) > > Hm, I'm not sure I understand, omapdss concepts map directly to the > hardware. I think it is mainly exposing the encoder and panel as two separate entities.. which seems to be what Archit is working on in case of something like DVI bridge from DPI, this seems pretty straightforward.. only the connector needs to know about DDC stuff, which i2c to use and that sort of thing. So at kms level we would have (for example) an omap_dpi_encoder which would be the same for DPI panel (connector) or DPI->DVI bridge. For HDMI I'm still looking through the code to see how this would work. Honestly I've looked less at this part of code and encoder related registers in the TRM, compared to the ovl/mgr parts, but at least from the 'DSS overview' picture in the TRM it seems to make sense ;-) KMS even exposes the idea that certain crtcs can connect to only certain encoders. Or that you could you could have certain connectors switched between encoders. For example if you had a hw w/ DPI out, and some mux to switch that back and forth between a DPI lcd panel and a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does this, but it is in theory possible.) So we could expose possible video chain topologies to userspace in this way. The other thing is that we don't need to propagate timings from the panel up to the mgr at the dss level.. kms is already handling this for us. In my latest version, which I haven't pushed, I removed the 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >> The one area that kms mismatches a bit is decoupling of ovl from mgr >> that we have in our hw.. I've partially solved that a while back w/ > > What do you mean with that? Ovls and mgrs are one entity in KMS? Didn't > the drm_plane stuff separate these? yes and no.. it is in our omapdrm implementation, because each crtc has it's own private plane assigned. Basically the purpose is that we can't break the interface to existing KMS userspace, which expects a CRTC to include the dma scanout engine. But it means at the moment we can't re-use these planes from crtc's that are not in use. I have some ideas about how to expose this to userspace in a backwards compatible way, so a userspace that is aware of this can re-use planes from crtcs that are not in use. There is at least one other SoC platform (STE, IIRC?) that has similar flexibility in hw, so I think this is a worthwhile thing to do.. but just haven't gotten to it yet. >> For enabling/disabling an output (manager+encoder), this is relatively >> infrequent, so it can afford to block to avoid races. (Like userspace >> enabling and then rapidly disabling an output part way through the >> enable.) But enabling/disabling an overlay, or adjusting position or >> scanout address must not block. And ideally, if possible, switching >> an overlay between two managers should not block. > > Adjusting the position or address of the buffer are simple, they can be > easily done without any blocking. > > But ovl enable/disable and switching an ovl to another mgr do (possibly) > take multiple vsyncs (and in the switch case, vsyncs of two separate > outputs). So if those do not block, we'll need to handle them as a state > machine and try to avoid races etc. It'll be "interesting". ok, I see the problem. Really the one thing I'm not handling properly is disconnecting a plane from one crtc and connecting to another. The disconnect should synchronize on the outgoing crtc's vblank/GO, and connect on the incoming crtc. But this is not a frequent operation, so I think the easy solution here is to block on the connect-to-new-crtc if the disconnect is still pending. I'd prefer this to introducing intermediate states. A simple enable/disable without changing crtc does not need to block. If usespace disables and then re-enables before the vblank, we just apply whatever is the most recent state at the vblank. Meaning enable->disable->enable, the middle disable might just get skipped. This is fine, and actually desirable. > However, we can sometimes do those operations immediately. So I think we > should have these conditional fast-paths in the code, and do them in > non-blocking manner when possible. > >> I'll look again, but as far as I remember that at least wasn't >> addressing the performance issues from making overlay enable/disable > > Right, it wasn't addressing those issues. But your branch doesn't really > address those issues either, as it doesn't handle the problems related > to ovl enable/disable. > >> synchronous. And fixing that would, I
RE: omap_device: query on "fck" clk alias created
On Wed, Aug 01, 2012 at 19:12:59, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 08/01/2012 02:20 PM, Vaibhav Hiremath wrote:
> > Hi,
> >
> > In OMAP world, we have omap_device layer, which exports api's like
> > omap_device_build() to create and register platform_device to the
> > kernel. This layer understands hwmod infrastructure and parses all the
> > platform specific information from it.
> > Now with DT migration, the same thing is achieved using a notifier,
> > which in turn omap_device_build_from_dt(), which in turn does same thing.
> >
> > One of the thing which is happening in both execution path is, creating
> > alias for functional clock (hwmod_data->main_clk) for each device
> > getting created with the con_id = "fck".
> >
> > Now the problem with this is,
> >
> > The clk_get() api will not work, unless we pass both the arguments (dev,
> > con_id) properly. Now expecting driver to always label con_id with "fck"
> > is undesirable, as the same driver can be reused on multiple platforms,
> > which can be non-omap and/or non-ti platforms.
> > Also we have multiple examples where driver simply calls (which is right)
> >
> > clk = clk_get(&pdev->dev, NULL);
>
> Mmm, I don't know, but even if this is right, shouldn't we avoid such
> usage. It might be better to be explicit than assuming that the IP will
> always have an unique clock.
Isn't this IP specific and driver must know how many clocks he has to
address? So I believe it will not be assumption, the driver is written
considering clocksources and in some cases IP is designed and meant to
receive only one clock input.
Let me bring a real example which I am dealing with now,
DCAN IP integrated in AM335X device, this IP is not from TI. This is Bosch
IP and doesn't follow any of the TI standards, like HighLander spec. Even it
doesn't have SYSCONF register for that matter. The driver is generic,
obviously used across non-ti devices already and driver is implemented with
Clk_get(dev, NULL);
> Some IP does have several inputs that might or not be connected
> depending or the integration or on the version. So even if only one
> clock is useful at some point it will not always be true.
> We had similar issue with the IRQ lines in the past.
>
> > This would fail on OMAP platforms, unless you modify clockxxx_data.c
> > file with,
> >
> > CLK("", NULL, &xxx_fck,CK_34XX),
> >
> >
> > Devices specially with only one clock source always prefer not to
> > specify con_id.
>
> How many devices do you have with only one clock source? Could you
> provide the list of drivers that assume that?
>
I did simple grep on drivers/ directory and here is the output of it -
# grep -r clk_get drivers/* | grep -r ", NULL"
drivers/ata/pata_arasan_cf.c: acdev->clk = clk_get(&pdev->dev, NULL);
drivers/ata/sata_mv.c: hpriv->clk = clk_get(&pdev->dev, NULL);
drivers/ata/pata_imx.c: priv->clk = clk_get(&pdev->dev, NULL);
drivers/char/hw_random/nomadik-rng.c: rng_clk = clk_get(&dev->dev, NULL);
drivers/char/hw_random/picoxcell-rng.c: rng_clk = clk_get(&pdev->dev, NULL);
drivers/char/hw_random/atmel-rng.c: trng->clk = clk_get(&pdev->dev, NULL);
drivers/crypto/ux500/cryp/cryp_core.c: device_data->clk = clk_get(&pdev->dev,
NULL);
drivers/crypto/ux500/hash/hash_core.c: device_data->clk = clk_get(dev, NULL);
drivers/crypto/mv_cesa.c: cp->clk = clk_get(&pdev->dev, NULL);
drivers/dma/ipu/ipu_idmac.c:ipu_data.ipu_clk = clk_get(&pdev->dev, NULL);
drivers/dma/mv_xor.c: msp->clk = clk_get(&pdev->dev, NULL);
drivers/dma/mxs-dma.c: mxs_dma->clk = clk_get(&pdev->dev, NULL);
drivers/dma/ste_dma40.c:clk = clk_get(&pdev->dev, NULL);
drivers/gpio/gpio-pxa.c:clk = clk_get(&pdev->dev, NULL);
drivers/gpio/gpio-stp-xway.c: clk = clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-davinci.c: dev->clk = clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-sirf.c: clk = clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-designware-platdrv.c:dev->clk = clk_get(&pdev->dev,
NULL);
drivers/i2c/busses/i2c-nomadik.c: dev->clk = clk_get(&adev->dev, NULL);
drivers/i2c/busses/i2c-nuc900.c:i2c->clk = clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-tegra.c: clk = devm_clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-pxa.c: i2c->clk = clk_get(&dev->dev, NULL);
drivers/i2c/busses/i2c-sh_mobile.c: pd->clk = clk_get(&dev->dev, NULL);
drivers/i2c/busses/i2c-imx.c: i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
drivers/i2c/busses/i2c-pnx.c: alg_data->clk = clk_get(&pdev->dev, NULL);
drivers/ide/palm_bk3710.c: clk = clk_get(&pdev->dev, NULL);
drivers/input/keyboard/nomadik-ske-keypad.c:keypad->clk =
clk_get(&pdev->dev, NULL);
drivers/input/keyboard/tnetv107x-keypad.c: kp->clk = clk_get(dev, NULL);
drivers/input/keyboard/pxa27x_keypad.c: keypad->clk = clk_get(&pdev->dev, NULL);
drivers/input/keyboard/tegra-kbc.c: kbc->clk = clk_get(&pdev->dev, NULL);
drivers/input/keyboard/spear-keyboard.c:kb
RE: omap_device: query on "fck" clk alias created
On Wed, Aug 01, 2012 at 19:44:14, Russell King - ARM Linux wrote: > On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote: > > The clk_get() api will not work, unless we pass both the arguments (dev, > > con_id) properly. Now expecting driver to always label con_id with "fck" > > is undesirable, as the same driver can be reused on multiple platforms, > > which can be non-omap and/or non-ti platforms. > > Why not? > > The connection ID is defined by the driver, and the platform stuff is > expected to provide drivers with what they require. It's not the other > way around (platforms don't tell drivers what they require.) > > In other words, if the device has two clocks, one called ick and one called > fck, then the device _should_ use clk_get() specifying "ick" for one, and > "fck" for the other. > > And platforms better provide an "ick" and a "fck" for the device, even if > they have no respresentation for one or other of them (in which case you > supply a dummy clock.) > Russell, I completely agree with you, infact I am on the same page. Let me give you a real example, which I am dealing with now, On AM335x device we have integrated DCAN, this IP is not from TI. IP is from Bosch and doesn't follow any of the TI IP standards, like HighLander spec. The IP is just integrated with interconnect bus and given a required clocksource (in this case its one clock). The driver for this IP is generic, (drivers/net/can/c_can/c_can_platform.c) obviously used across non-ti devices already and driver is implemented with, clk_get(dev, NULL); So in this context, 1. Either I have to change the driver to specify con_id. Modifying a generic driver. OR 2. Change the clock tree table to add an clock entry for this clock with con_id = NULL, but I have to fix dev_id as well. I believe this I can achieve using " of_dev_auxdata". OR 3. Create an alias at run time (omap is doing currently) with using dynamic dev_id and con_id = NULL. Thanks, Vaibhav -- 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: omap_device: query on "fck" clk alias created
On Thu, Aug 02, 2012 at 12:55:42PM +, Hiremath, Vaibhav wrote: > On Wed, Aug 01, 2012 at 19:12:59, Cousson, Benoit wrote: > > Mmm, I don't know, but even if this is right, shouldn't we avoid such > > usage. It might be better to be explicit than assuming that the IP will > > always have an unique clock. > > Isn't this IP specific and driver must know how many clocks he has to > address? So I believe it will not be assumption, the driver is written > considering clocksources and in some cases IP is designed and meant to > receive only one clock input. Devices themselves define what clocks they need to operate. Drivers designed to be used with the clk API are supposed to obtain all clocks that the device requires. The device dictates what clocks are required. This does not change the way drivers deal with clocks depending on how they're integrated into a SoC: devices that need five clocks should _always_ call clk_get() five times to get each of those five clocks. Where a clock is not individually distinguishable or available in a SoC, the SoC level must arrange to return a dummy clock to the device driver. If a device only takes one single clock, then using a connection ID of NULL is acceptable. Otherwise, an explicit name must be used, which is chosen either from the device IPs documentation (eg, the name of the _clock_ _input_) or with a lack of that information, a name chosen by the driver writer according to the function of the clock. You must stop thinking about the picture you get when something gets integrated into a SoC... and making driver code conditional on the view presented by the SoC. -- 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: omap_device: query on "fck" clk alias created
On Thu, Aug 02, 2012 at 01:04:37PM +, Hiremath, Vaibhav wrote: > On Wed, Aug 01, 2012 at 19:44:14, Russell King - ARM Linux wrote: > > On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote: > > > The clk_get() api will not work, unless we pass both the arguments (dev, > > > con_id) properly. Now expecting driver to always label con_id with "fck" > > > is undesirable, as the same driver can be reused on multiple platforms, > > > which can be non-omap and/or non-ti platforms. > > > > Why not? > > > > The connection ID is defined by the driver, and the platform stuff is > > expected to provide drivers with what they require. It's not the other > > way around (platforms don't tell drivers what they require.) > > > > In other words, if the device has two clocks, one called ick and one called > > fck, then the device _should_ use clk_get() specifying "ick" for one, and > > "fck" for the other. > > > > And platforms better provide an "ick" and a "fck" for the device, even if > > they have no respresentation for one or other of them (in which case you > > supply a dummy clock.) > > > > Russell, I completely agree with you, infact I am on the same page. > Let me give you a real example, which I am dealing with now, > > On AM335x device we have integrated DCAN, this IP is not from TI. > IP is from Bosch and doesn't follow any of the TI IP standards, like > HighLander spec. The IP is just integrated with interconnect bus and given a > required clocksource (in this case its one clock). > > The driver for this IP is generic, (drivers/net/can/c_can/c_can_platform.c) > obviously used across non-ti devices already and driver is implemented with, > clk_get(dev, NULL); So, elsewhere it only has one clock. Are there any other clocks it needs on OMAP? If the answer is no, then the driver is doing the right thing, and OMAP's clk stuff needs to be adjusted to suit the drivers requirements. I've said many times over the years that clock connection IDs are defined by the device or driver and *nothing* else - they're certainly *not* source names. That's why, when I modified OMAP drivers to fix them, and they take an interface and function clock, they end up asking for "ick" and "fck" not "blah_ick" and "blah_fck". -- 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: [RFC 0/3] solving omapdrm/omapdss layering issues
On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: > On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: > > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: > >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen > >> wrote: > > > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS > >> > hardware, and we'll have to use whatever gives us least problems. > >> > >> Actually, I think it does map fairly well to the hardware.. at least > >> more so than to omapdss ;-) > > > > Hm, I'm not sure I understand, omapdss concepts map directly to the > > hardware. > > I think it is mainly exposing the encoder and panel as two separate > entities.. which seems to be what Archit is working on I still don't follow =) They are separate entities. Omapdss models the HW quite directly, I think. It doesn't expose everything, though, as the output drivers (dsi.c, dpi.c etc) are used via the panel drivers. > in case of something like DVI bridge from DPI, this seems pretty > straightforward.. only the connector needs to know about DDC stuff, > which i2c to use and that sort of thing. So at kms level we would > have (for example) an omap_dpi_encoder which would be the same for DPI > panel (connector) or DPI->DVI bridge. For HDMI I'm still looking > through the code to see how this would work. Honestly I've looked > less at this part of code and encoder related registers in the TRM, > compared to the ovl/mgr parts, but at least from the 'DSS overview' > picture in the TRM it seems to make sense ;-) > > KMS even exposes the idea that certain crtcs can connect to only > certain encoders. Or that you could you could have certain connectors > switched between encoders. For example if you had a hw w/ DPI out, > and some mux to switch that back and forth between a DPI lcd panel and > a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does > this, but it is in theory possible.) So we could expose possible > video chain topologies to userspace in this way. OMAP3 SDP board has such a setup, with manual switch to select between LCD and DVI. > The other thing is that we don't need to propagate timings from the > panel up to the mgr at the dss level.. kms is already handling this > for us. In my latest version, which I haven't pushed, I removed the > 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. You're thinking only about simple DPI cases. Consider this example, with a DSI-to-DP bridge chip. What we have is the following flow of data: DISPC -> DSI -> DSI-2-DP -> DP monitor The timings you are thinking about are in the DISPC, but here they are only one part of the link. And here the DISPC timings are not actually the timings what the user is interested about. The user wants his timings to be between DSI-2-DP chip and the DP monitor. Timings programmed to DISPC are not the same. The timings for DISPC come from the DSI driver, and they may be very different than the user's timings. With DSI video mode, the DISPC timings would have some resemblance to the user's timings, mainly the time to send one line would be the same. With DSI cmd mode, the DISPC timings would be something totally different, most likely with 0 blank times and as fast pixel clock as possible. What omapdss does currently is that you set the user's timings to the right side of the chain, which propagate back to DSS. This allows the DSI-2-DP bridge use DSI timings that work optimally for the bridge, and DSI driver will use DISPC timings that work optimally for it. And it's not only about timings above, but also other settings related to the busses between the components. Clock dividers, polarities, stuff like that. > I think the problem was there were some cases, like ovl updates before > setting the mgr, where the user_info_dirty flag would be cleared but > the registers not updated. This is what I meant by sequence of Hmm, I'd appreciate more info about this if you can give. Sounds like a bug, that shouldn't happen. So you mean that you have an ovl, with no manager set. And you change the settings of the ovl before assigning it to a mgr? That's something I haven't really tested, so it could bug, true. > operations at KMS level confusing omapdss. This should be fixable > with some debugging. Although getting rid of the state tracking at > omapdss level altogether was a much simpler solution, and is the one I > prefer :-) Yes, I don't prefer the state tracking either (we didn't have it in earlier versions of omapdss), but I still don't see an option to it if we want to support all the stuff we have. Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote: > On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: >> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: >> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> >> wrote: >> > >> >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >> >> > hardware, and we'll have to use whatever gives us least problems. >> >> >> >> Actually, I think it does map fairly well to the hardware.. at least >> >> more so than to omapdss ;-) >> > >> > Hm, I'm not sure I understand, omapdss concepts map directly to the >> > hardware. >> >> I think it is mainly exposing the encoder and panel as two separate >> entities.. which seems to be what Archit is working on > > I still don't follow =) They are separate entities. Omapdss models the > HW quite directly, I think. It doesn't expose everything, though, as the > output drivers (dsi.c, dpi.c etc) are used via the panel drivers. right.. so we just need to expose the output drivers as separate entities, and let omapdrm propagate information such as timings between them >> in case of something like DVI bridge from DPI, this seems pretty >> straightforward.. only the connector needs to know about DDC stuff, >> which i2c to use and that sort of thing. So at kms level we would >> have (for example) an omap_dpi_encoder which would be the same for DPI >> panel (connector) or DPI->DVI bridge. For HDMI I'm still looking >> through the code to see how this would work. Honestly I've looked >> less at this part of code and encoder related registers in the TRM, >> compared to the ovl/mgr parts, but at least from the 'DSS overview' >> picture in the TRM it seems to make sense ;-) >> >> KMS even exposes the idea that certain crtcs can connect to only >> certain encoders. Or that you could you could have certain connectors >> switched between encoders. For example if you had a hw w/ DPI out, >> and some mux to switch that back and forth between a DPI lcd panel and >> a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does >> this, but it is in theory possible.) So we could expose possible >> video chain topologies to userspace in this way. > > OMAP3 SDP board has such a setup, with manual switch to select between > LCD and DVI. ahh, good to know.. so I'm not crazy for wanting to expose this possibility to userspace >> The other thing is that we don't need to propagate timings from the >> panel up to the mgr at the dss level.. kms is already handling this >> for us. In my latest version, which I haven't pushed, I removed the >> 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. > > You're thinking only about simple DPI cases. Consider this example, with > a DSI-to-DP bridge chip. What we have is the following flow of data: > > DISPC -> DSI -> DSI-2-DP -> DP monitor > > The timings you are thinking about are in the DISPC, but here they are > only one part of the link. And here the DISPC timings are not actually > the timings what the user is interested about. The user wants his > timings to be between DSI-2-DP chip and the DP monitor. > > Timings programmed to DISPC are not the same. The timings for DISPC come > from the DSI driver, and they may be very different than the user's > timings. With DSI video mode, the DISPC timings would have some > resemblance to the user's timings, mainly the time to send one line > would be the same. With DSI cmd mode, the DISPC timings would be > something totally different, most likely with 0 blank times and as fast > pixel clock as possible. hmm, well kms already has a concept of adjusted_timings, which could perhaps be used here to propagate the timings between crtc->encoder.. although the order is probably backwards from what we want (it comes from the crtc to the encoder.. and if I understand properly we want it the other way and actually possibly from the connector). But that isn't to say that internally in omapdrm the crtc couldn't get the adjusted timings from the connector. So I still think the parameter flow doesn't need to be 'under the hood' in omapdss. And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper fxns, so if the way the core kms handles it isn't what we want, we can just plug in our own fxn instead of using drm_crtc_helper_set_mode(), so that isn't really a big problem. > What omapdss does currently is that you set the user's timings to the > right side of the chain, which propagate back to DSS. This allows the > DSI-2-DP bridge use DSI timings that work optimally for the bridge, and > DSI driver will use DISPC timings that work optimally for it. > > And it's not only about timings above, but also other settings related > to the busses between the components. Clock dividers, polarities, stuff > like that. I expect we could handle other settings in the same way as the timings. >> I think the problem was there were some cases, like ovl updates before >
Re: Current state of AM33xx patches
On 31.07.2012 21:29, Koen Kooi wrote: > 2/3 of the way there: > > http://patchwork.ozlabs.org/patch/174085/ > http://patchwork.ozlabs.org/patch/174086/ > > I keep failing to create a .dts that doesn't upset the dtc, so I don't have > it working yet :( Yes, that's because there are couple of sytax errors in the example bindings. Mugunthan, could you repost these patches and at least copy devicetree-disc...@lists.ozlabs.org and the ARM kernel mailing list? I can't comment on the patches you sent to net...@vger.kernel.org because I'm not currently subscribed to that list. Thanks, Daniel -- 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: Current state of AM33xx patches
Op 2 aug. 2012, om 17:30 heeft Daniel Mack het volgende geschreven: > On 31.07.2012 21:29, Koen Kooi wrote: > >> 2/3 of the way there: >> >> http://patchwork.ozlabs.org/patch/174085/ >> http://patchwork.ozlabs.org/patch/174086/ >> >> I keep failing to create a .dts that doesn't upset the dtc, so I don't have >> it working yet :( > > Yes, that's because there are couple of sytax errors in the example > bindings. Not only that, it's actually missing params and other params are wrong. See my non-constructive rant in the commit message: http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch But I still can't get it working: root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0: initializing cpsw version 1.12 (0) root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver type USB2 PHY already exists [ 13.512056] libphy: PHY davinci_mdio-0:00 not found [ 13.517168] net eth0: phy davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY davinci_mdio-0:01 not found [ 13.528675] net eth0: phy davinci_mdio-0:01 not found on slave 1 root@beaglebone:~# ifconfig -a | grep eth eth0 Link encap:Ethernet HWaddr 00:04:9F:01:1B:B8 > Mugunthan, could you repost these patches and at least copy > devicetree-disc...@lists.ozlabs.org and the ARM kernel mailing list? I > can't comment on the patches you sent to net...@vger.kernel.org because > I'm not currently subscribed to that list. Same here, I'm only on l-o, but I guess I'll need to subscribe dt-discuss in the near future :) regards, Koen-- 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: Current state of AM33xx patches
On 02.08.2012 17:37, Koen Kooi wrote: > Not only that, it's actually missing params and other params are > wrong. See my non-constructive rant in the commit message: > http://dominion.thruhere.net/koen/angstrom/beaglebone/0001-beaglebone-add-broken-cpsw-DT.patch > > But I still can't get it working: > > root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0: > initializing cpsw version 1.12 (0) > > root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux > on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver > type USB2 PHY already exists [ 13.512056] libphy: PHY > davinci_mdio-0:00 not found [ 13.517168] net eth0: phy > davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY > davinci_mdio-0:01 not found [ 13.528675] net eth0: phy > davinci_mdio-0:01 not found on slave 1 That is because the davinci_mdio driver is not yet probed from DT. I hooked up bindings to that driver and also had to augment the clock definitions, but that's giving me an "external abort on non-linefetch" at boot time. Most probably because there's something missing in the clock setup. Not sure whether I should debug that any further or if anyone has patches for that. Mugunthan, how did you test your DT bindings? Could you push your entire tree somewhere maybe for others to have a look at it? I have no problem helping you in any way, I just want to know where we currently are. Thanks for you work, Daniel -- 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 3/3] ARM: OMAP: omap_device: expose hwmod assert/deassert to omap devices
On 2 August 2012 02:43, Paul Walmsley wrote: >> This APIs are meant to be an interface to hwmod assert/deassert >> function, omap devices can call them through their platform data >> to control their reset lines, they are expected to know the name >> of the reset line they are trying to control. >> >> Signed-off-by: Omar Ramirez Luna > > This one has been queued for 3.7 with a few changes. Some more detail was > added to the function documentationrovement. Also the multiple > assignments were removed per Documentation/CodingStyle chapter 1: > > "Don't put multiple assignments on a single line either." > > Please let me know if you have any comments. Agree. Thanks, Omar -- 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 RFC] ARM: omap2/am33xx: add hwmod for davinci_mdio
Add a hwmod entry for the davinci_mdio hardware block. This aliases the
cpsw_125mhz_clkdm and re-uses am33xx_cpgmac0_hwmod_class.
Signed-off-by: Daniel Mack
---
I'm still not totally confident with the hwmod environment, so I'm not
entirely sure whether sharing the hwmod_class is the right thing to do
here. However, I can at least get ethernet to work on my board now.
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 5a4660b..637b6cc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -684,6 +684,19 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
},
};
+static struct omap_hwmod am33xx_cpsw_mdio_hwmod = {
+ .name = "davinci_mdio",
+ .class = &am33xx_cpgmac0_hwmod_class,
+ .clkdm_name = "cpsw_125mhz_clkdm",
+ .main_clk = "cpsw_125mhz_gclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_CPGMAC0_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/*
* dcan class
*/
@@ -2501,6 +2514,23 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+static struct omap_hwmod_addr_space am33xx_cpsw_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4a101000,
+ .pa_end = 0x4a101000 + SZ_256 - 1,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if am33xx_l4_hs__cpsw_mdio = {
+ .master = &am33xx_l4_hs_hwmod,
+ .slave = &am33xx_cpsw_mdio_hwmod,
+ .clk= "cpsw_125mhz_gclk",
+ .addr = am33xx_cpsw_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
@@ -3371,6 +3401,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
&am33xx_l3_main__tptc2,
&am33xx_l3_s__usbss,
&am33xx_l4_hs__cpgmac0,
+ &am33xx_l4_hs__cpsw_mdio,
NULL,
};
--
1.7.11.2
--
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: Current state of AM33xx patches
On 02.08.2012 17:37, Koen Kooi wrote: > But I still can't get it working: > > root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0: > initializing cpsw version 1.12 (0) > > root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux > on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver > type USB2 PHY already exists [ 13.512056] libphy: PHY > davinci_mdio-0:00 not found [ 13.517168] net eth0: phy > davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY > davinci_mdio-0:01 not found [ 13.528675] net eth0: phy > davinci_mdio-0:01 not found on slave 1 > > root@beaglebone:~# ifconfig -a | grep eth eth0 Link > encap:Ethernet HWaddr 00:04:9F:01:1B:B8 Ok, I got it up and and running now on my board using the two davinci_mdio drivers and the hwmod addition I just posted. With those applied on top of Mugunthan work, I can link my cpsw slave with the phy id "davinci_mdio.18-:04", but the 18 is just the global device counter which will change again once I add more devices. That still needs some cleanup. Anyway, at least I can boot into my NFS root now :) Koen, can you try this on your board and see if that works for you as well? Thanks, Daniel -- 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: Current state of AM33xx patches
Op 2 aug. 2012, om 21:56 heeft Daniel Mack het volgende
geschreven:
> On 02.08.2012 17:37, Koen Kooi wrote:
>> But I still can't get it working:
>>
>> root@beaglebone:~# dmesg | grep -i cpsw [ 13.504425] net eth0:
>> initializing cpsw version 1.12 (0)
>>
>> root@beaglebone:~# dmesg | grep -i phy [0.00] Booting Linux
>> on physical CPU 0 [0.228496] nop_usb_xceiv phy.17: transceiver
>> type USB2 PHY already exists [ 13.512056] libphy: PHY
>> davinci_mdio-0:00 not found [ 13.517168] net eth0: phy
>> davinci_mdio-0:00 not found on slave 0 [ 13.523516] libphy: PHY
>> davinci_mdio-0:01 not found [ 13.528675] net eth0: phy
>> davinci_mdio-0:01 not found on slave 1
>>
>> root@beaglebone:~# ifconfig -a | grep eth eth0 Link
>> encap:Ethernet HWaddr 00:04:9F:01:1B:B8
>
> Ok, I got it up and and running now on my board using the two
> davinci_mdio drivers and the hwmod addition I just posted.
>
> With those applied on top of Mugunthan work, I can link my cpsw slave
> with the phy id "davinci_mdio.18-:04", but the 18 is just the global
> device counter which will change again once I add more devices. That
> still needs some cleanup.
>
> Anyway, at least I can boot into my NFS root now :) Koen, can you try
> this on your board and see if that works for you as well?
[koen@Angstrom-F16-vm-rpm kernel]$ git diff
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index ac7fab5..c33a05d 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -33,6 +33,11 @@
};
};
+ mdio: davinci_mdio@4a101000 {
+ compatible = "ti,davinci-mdio";
+ ti,hwmods = "davinci_mdio";
+ };
+
mac: ethernet@4A10 {
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
@@ -49,19 +54,13 @@
no_bd_ram = <0>;
rx_descs = <64>;
mac_control = <0x20>;
- slaves = <2>;
+ slaves = <1>;
slave@0 {
slave_reg_ofs = <0x208>;
sliver_reg_ofs = <0xd80>;
- phy_id = "davinci_mdio-0:00";
+ phy_id = "davinci_mdio.21-:00";
mac-address = [00 04 9F 01 1B B8];
};
- slave@1 {
- slave_reg_ofs = <0x308>;
- sliver_reg_ofs = <0xdc0>;
- phy_id = "davinci_mdio-0:01";
- mac-address = [00 04 9F 01 1B B9];
- };
};
};
leads to:
[ 14.127177] net eth0: initializing cpsw version 1.12 (0)
[ 14.135038] net eth0: phy found : id is : 0x7c0f1
[ 17.871215] libphy: davinci_mdio.21-:00 - Link is Up - 100/Full
So you can add my Tested-by: to the patches if you want :)
regards,
Koen--
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 v7 00/11] usb: musb: adding multi instance support
Hi Ravi, On 02.08.2012 14:12, Ravi Babu wrote: > This series of patches adds, > a) Multi instances support in musb driver > b) DT support for musb_dsps glue layer > c) DT support for NOP transceiver > > AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. > This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to > get the PHY of same type. This API support is being added by Kishon's patch > discussed at [1] > > The series applies to linux-omap (master branch) > + Vaibhav baseport patches on his tree at [3] > + Kishon's multi phy patches on Felipe's branch 'xceiv' > + Kishon's patch on phandle at [1] > + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] > + Damodar's recent patch at [2] > > and have been tested on Beaglebone board. I would like to test these patches on a custom AM33xx board, but I'm having trouble applying them. I am based on Linus' master tree, and "git am" fails for drivers/usb/musb/musb_dsps.c. The commits I got for that file are: ded017ee6 usb: phy: fix return value check of usb_get_phy 662dca54c usb: otg: support for multiple transceivers by a single controller 721002ec1 usb: otg: utils: rename function name in OTG utils 9ecb88752 usb: musb: Add support for ti81xx platform I wonder which branch you are based on and which tree those patches should go thru eventually. Thanks, Daniel -- 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 2/3] ARM: OMAP: hwmod: revise deassert sequence
Hi. On 2 August 2012 02:52, Paul Walmsley wrote: > On Mon, 16 Jul 2012, Omar Ramirez Luna wrote: > >> For a reset sequence to complete cleanly, a module needs its >> associated clocks to be enabled, otherwise the timeout check >> in prcm code can print a false failure (failed to hardreset) >> that occurs because the clocks aren't powered ON and the status >> bit checked can't transition without them. >> >> Signed-off-by: Omar Ramirez Luna > > Is enabling the clocks sufficient? During my testing it seemed enough, besides it looks clk framework is doing the same as _omap4_enable_module. > Or do we also need to enable the > IP block, e.g. by calling > > if (soc_ops.enable_module) > soc_ops.enable_module(oh); > > as we do on OMAP4+ in _enable() ? Basically this is a call to _omap4_enable_module, and the latter will "Enable the modulemode inside CLKCTRL". However, _enable_clocks path which ends calling omap2_dflt_clk_enable does the same thing with its clk->enable_reg field. So in _enable: _enable_clocks(oh); if (soc_ops.enable_module) soc_ops.enable_module(oh); The enable_module part seems redundant to me, since the module should be already enabled by the first call to _enable_clocks. Regards, Omar -- 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] Revert "spi: omap2-mcspi: convert to module_platform_driver"
This reverts commit 9fdca9dfe093c76fe1ac1a09888ba9679d46996a.
Changing omap2_mcspi_init() from subsys_initcall to device_initcall broke
the display initialization on N900 when all the drivers are compiled
built-in. Display subsystem drivers need a certain initialization order
and having all of them initialize with device_initcall seems to be too
fragile. Without this revert the display init fails and the boot hangs
with the following messages:
[1.260955] acx565akm spi1.2: invalid display ID
[1.265899] panel-acx565akm display0: acx_panel_probe panel detect error
[1.273071] omapdss CORE error: driver probe failed: -19
[...]
[1.902862] omapfb omapfb: no driver for display: lcd
[1.908264] omapfb omapfb: cannot find default display
Signed-off-by: Aaro Koskinen
---
drivers/spi/spi-omap2-mcspi.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 0c73dd4..8cec17c 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1289,5 +1289,18 @@ static struct platform_driver omap2_mcspi_driver = {
.remove = __devexit_p(omap2_mcspi_remove),
};
-module_platform_driver(omap2_mcspi_driver);
+
+static int __init omap2_mcspi_init(void)
+{
+ return platform_driver_register(&omap2_mcspi_driver);
+}
+subsys_initcall(omap2_mcspi_init);
+
+static void __exit omap2_mcspi_exit(void)
+{
+ platform_driver_unregister(&omap2_mcspi_driver);
+
+}
+module_exit(omap2_mcspi_exit);
+
MODULE_LICENSE("GPL");
--
1.7.2.5
--
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] Revert "spi: omap2-mcspi: convert to module_platform_driver"
On Thu, Aug 2, 2012 at 5:08 PM, Aaro Koskinen wrote: > This reverts commit 9fdca9dfe093c76fe1ac1a09888ba9679d46996a. > > Changing omap2_mcspi_init() from subsys_initcall to device_initcall broke > the display initialization on N900 when all the drivers are compiled > built-in. Display subsystem drivers need a certain initialization order > and having all of them initialize with device_initcall seems to be too > fragile. Without this revert the display init fails and the boot hangs > with the following messages: > > [1.260955] acx565akm spi1.2: invalid display ID > [1.265899] panel-acx565akm display0: acx_panel_probe panel detect error > [1.273071] omapdss CORE error: driver probe failed: -19 The dependencies are all messed up. The reverted commit is part of fixing that and I don't really want to go backwards on it. How many drivers are failing? Can you try modifying the failure path of those drivers to return -EPROBE_DEFER and see if that helps? g. -- 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 v7 00/11] usb: musb: adding multi instance support
Hi > > On 02.08.2012 14:12, Ravi Babu wrote: > > This series of patches adds, > > a) Multi instances support in musb driver > > b) DT support for musb_dsps glue layer > > c) DT support for NOP transceiver > > > > AM33xx and TI81xx has dual musb controller and has two usb > PHY of same type. > > This patch series uses 'phandle' based API > > devm_usb_get_phy_by_phandle() to get the PHY of same type. This API > > support is being added by Kishon's patch discussed at [1] > > > > The series applies to linux-omap (master branch) > > + Vaibhav baseport patches on his tree at [3] > > + Kishon's multi phy patches on Felipe's branch 'xceiv' > > + Kishon's patch on phandle at [1] > > + AM33xx musb glue compile and bugfix patches at [4], > [5], [6] and [7] > > + Damodar's recent patch at [2] > > > > and have been tested on Beaglebone board. Have you applied the above patches before applying these patches. Ravi Babu > > I would like to test these patches on a custom AM33xx board, > but I'm having trouble applying them. I am based on Linus' > master tree, and "git am" fails for > drivers/usb/musb/musb_dsps.c. The commits I got for that file are: > > ded017ee6 usb: phy: fix return value check of usb_get_phy > 662dca54c usb: otg: support for multiple transceivers by a > single controller > 721002ec1 usb: otg: utils: rename function name in OTG utils > 9ecb88752 usb: musb: Add support for ti81xx platform > > I wonder which branch you are based on and which tree those > patches should go thru eventually. > > > Thanks, > Daniel > > -- 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 2/3] ARM: OMAP: hwmod: revise deassert sequence
On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote: > Hi. > > On 2 August 2012 02:52, Paul Walmsley wrote: >> On Mon, 16 Jul 2012, Omar Ramirez Luna wrote: >> >>> For a reset sequence to complete cleanly, a module needs its >>> associated clocks to be enabled, otherwise the timeout check >>> in prcm code can print a false failure (failed to hardreset) >>> that occurs because the clocks aren't powered ON and the status >>> bit checked can't transition without them. >>> >>> Signed-off-by: Omar Ramirez Luna >> >> Is enabling the clocks sufficient? > > During my testing it seemed enough, besides it looks clk framework is > doing the same as _omap4_enable_module. > >> Or do we also need to enable the >> IP block, e.g. by calling >> >> if (soc_ops.enable_module) >> soc_ops.enable_module(oh); >> >> as we do on OMAP4+ in _enable() ? > > Basically this is a call to _omap4_enable_module, and the latter will > "Enable the modulemode inside CLKCTRL". > > However, _enable_clocks path which ends calling omap2_dflt_clk_enable > does the same thing with its clk->enable_reg field. > > So in _enable: > > _enable_clocks(oh); > if (soc_ops.enable_module) > soc_ops.enable_module(oh); > > The enable_module part seems redundant to me, since the module should > be already enabled by the first call to _enable_clocks. > Yes they do same thing, I believe the plan is to get rid of all clock leaf-nodes in the near future, and let hwmod handle module enable/disable part. Thanks, Vaibhav > Regards, > > Omar > -- > 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 > -- 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: Current state of AM33xx patches
> -Original Message- > From: Daniel Mack [mailto:zon...@gmail.com] > Sent: Thursday, August 02, 2012 9:01 PM > To: Koen Kooi > Cc: N, Mugunthan V; Hiremath, Vaibhav; Paul Walmsley; Nori, Sekhar; > Jason Kridner; Tony Lindgren; Hilman, Kevin; Hernandez, Carlos; Maupin, > Chase; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Kridner, Jason > Subject: Re: Current state of AM33xx patches > > On 31.07.2012 21:29, Koen Kooi wrote: > > > 2/3 of the way there: > > > > http://patchwork.ozlabs.org/patch/174085/ > > http://patchwork.ozlabs.org/patch/174086/ > > > > I keep failing to create a .dts that doesn't upset the dtc, so I > don't have it working yet :( > > Yes, that's because there are couple of sytax errors in the example > bindings. Mugunthan, could you repost these patches and at least copy > devicetree-disc...@lists.ozlabs.org and the ARM kernel mailing list? I > can't comment on the patches you sent to net...@vger.kernel.org because > I'm not currently subscribed to that list. > > > Thanks, > Daniel I will repost the patch set including the device tree and arm kernel mailing list today. Regards Mugunthan V N -- 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: [RFC 0/3] solving omapdrm/omapdss layering issues
Hi Rob, Tomi, On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote: > On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote: >> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: >>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen >>> wrote: >>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> >> wrote: >>> > >>> >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >>> >> > hardware, and we'll have to use whatever gives us least problems. >>> >> >>> >> Actually, I think it does map fairly well to the hardware.. at least >>> >> more so than to omapdss ;-) >>> > >>> > Hm, I'm not sure I understand, omapdss concepts map directly to the >>> > hardware. >>> >>> I think it is mainly exposing the encoder and panel as two separate >>> entities.. which seems to be what Archit is working on >> >> I still don't follow =) They are separate entities. Omapdss models the >> HW quite directly, I think. It doesn't expose everything, though, as the >> output drivers (dsi.c, dpi.c etc) are used via the panel drivers. > > right.. so we just need to expose the output drivers as separate > entities, and let omapdrm propagate information such as timings > between them > >>> in case of something like DVI bridge from DPI, this seems pretty >>> straightforward.. only the connector needs to know about DDC stuff, >>> which i2c to use and that sort of thing. So at kms level we would >>> have (for example) an omap_dpi_encoder which would be the same for DPI >>> panel (connector) or DPI->DVI bridge. For HDMI I'm still looking >>> through the code to see how this would work. Honestly I've looked >>> less at this part of code and encoder related registers in the TRM, >>> compared to the ovl/mgr parts, but at least from the 'DSS overview' >>> picture in the TRM it seems to make sense ;-) >>> >>> KMS even exposes the idea that certain crtcs can connect to only >>> certain encoders. Or that you could you could have certain connectors >>> switched between encoders. For example if you had a hw w/ DPI out, >>> and some mux to switch that back and forth between a DPI lcd panel and >>> a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does >>> this, but it is in theory possible.) So we could expose possible >>> video chain topologies to userspace in this way. >> >> OMAP3 SDP board has such a setup, with manual switch to select between >> LCD and DVI. > > ahh, good to know.. so I'm not crazy for wanting to expose this > possibility to userspace > >>> The other thing is that we don't need to propagate timings from the >>> panel up to the mgr at the dss level.. kms is already handling this >>> for us. In my latest version, which I haven't pushed, I removed the >>> 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >> >> You're thinking only about simple DPI cases. Consider this example, with >> a DSI-to-DP bridge chip. What we have is the following flow of data: >> >> DISPC -> DSI -> DSI-2-DP -> DP monitor >> >> The timings you are thinking about are in the DISPC, but here they are >> only one part of the link. And here the DISPC timings are not actually >> the timings what the user is interested about. The user wants his >> timings to be between DSI-2-DP chip and the DP monitor. >> >> Timings programmed to DISPC are not the same. The timings for DISPC come >> from the DSI driver, and they may be very different than the user's >> timings. With DSI video mode, the DISPC timings would have some >> resemblance to the user's timings, mainly the time to send one line >> would be the same. With DSI cmd mode, the DISPC timings would be >> something totally different, most likely with 0 blank times and as fast >> pixel clock as possible. > > hmm, well kms already has a concept of adjusted_timings, which could > perhaps be used here to propagate the timings between crtc->encoder.. > although the order is probably backwards from what we want (it comes > from the crtc to the encoder.. and if I understand properly we want it > the other way and actually possibly from the connector). But that > isn't to say that internally in omapdrm the crtc couldn't get the > adjusted timings from the connector. So I still think the parameter > flow doesn't need to be 'under the hood' in omapdss. > > And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper > fxns, so if the way the core kms handles it isn't what we want, we can > just plug in our own fxn instead of using drm_crtc_helper_set_mode(), > so that isn't really a big problem. > >> What omapdss does currently is that you set the user's timings to the >> right side of the chain, which propagate back to DSS. This allows the >> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and >> DSI driver will use DISPC timings that work optimally for it. >> >> And it's not only about timings above, but also other settings related >> to the busses between the components. Clock dividers
RE: omap_device: query on "fck" clk alias created
On Thu, Aug 02, 2012 at 18:42:50, Russell King - ARM Linux wrote:
> On Thu, Aug 02, 2012 at 01:04:37PM +, Hiremath, Vaibhav wrote:
> > On Wed, Aug 01, 2012 at 19:44:14, Russell King - ARM Linux wrote:
> > > On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote:
> > > > The clk_get() api will not work, unless we pass both the arguments (dev,
> > > > con_id) properly. Now expecting driver to always label con_id with "fck"
> > > > is undesirable, as the same driver can be reused on multiple platforms,
> > > > which can be non-omap and/or non-ti platforms.
> > >
> > > Why not?
> > >
> > > The connection ID is defined by the driver, and the platform stuff is
> > > expected to provide drivers with what they require. It's not the other
> > > way around (platforms don't tell drivers what they require.)
> > >
> > > In other words, if the device has two clocks, one called ick and one
> > > called
> > > fck, then the device _should_ use clk_get() specifying "ick" for one, and
> > > "fck" for the other.
> > >
> > > And platforms better provide an "ick" and a "fck" for the device, even if
> > > they have no respresentation for one or other of them (in which case you
> > > supply a dummy clock.)
> > >
> >
> > Russell, I completely agree with you, infact I am on the same page.
> > Let me give you a real example, which I am dealing with now,
> >
> > On AM335x device we have integrated DCAN, this IP is not from TI.
> > IP is from Bosch and doesn't follow any of the TI IP standards, like
> > HighLander spec. The IP is just integrated with interconnect bus and given
> > a
> > required clocksource (in this case its one clock).
> >
> > The driver for this IP is generic, (drivers/net/can/c_can/c_can_platform.c)
> > obviously used across non-ti devices already and driver is implemented with,
> > clk_get(dev, NULL);
>
> So, elsewhere it only has one clock. Are there any other clocks it needs
> on OMAP?
>
> If the answer is no, then the driver is doing the right thing, and OMAP's
> clk stuff needs to be adjusted to suit the drivers requirements.
>
> I've said many times over the years that clock connection IDs are defined
> by the device or driver and *nothing* else - they're certainly *not* source
> names.
>
> That's why, when I modified OMAP drivers to fix them, and they take an
> interface and function clock, they end up asking for "ick" and "fck" not
> "blah_ick" and "blah_fck".
>
I am in agreement with you and I believe I came to the solution for this
issue, I used "of_dev_auxdata" to manipulate dev_id and updated clock-tree
table with required clock entry and it works, I tried it on BeagleBone
platform.
Can you please review it?
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..893cc0c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -37,11 +37,24 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
+/*
+ * Lookup table for attaching a specific name and platform_datapointer
to
+ * devices as they get created by of_platform_populate(). Ideally this table
+ * would not exist, but the current clock implementation depends on some
devices
+ * having a specific name.
+ */
+static const struct of_dev_auxdata omap_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA("bosch,d_can", 0x481cc000, "d_can.0", NULL),
+ OF_DEV_AUXDATA("bosch,d_can", 0x481d, "d_can.1", NULL),
+ { },
+};
+
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table, omap_auxdata_lookup,
NULL);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index ae27de8..f061834 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1028,6 +1028,8 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, "clkdiv32k_ick",&clkdiv32k_ick, CK_AM33XX),
CLK(NULL, "dcan0_fck",&dcan0_fck, CK_AM33XX),
CLK(NULL, "dcan1_fck",&dcan1_fck, CK_AM33XX),
+ CLK("d_can.0", NULL, &dcan0_fck, CK_AM33XX),
+ CLK("d_can.1", NULL, &dcan1_fck, CK_AM33XX),
CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX),
CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk,
CK_AM33XX),
CLK("davinci-mcasp.0", NULL, &mcasp0_fck,CK_AM33XX),
--
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 1/2] arm/dts: AM33XX: Add D_CAN device tree data
On 7/25/2012 5:53 PM, AnilKumar Ch wrote:
> Add Bosch D_CAN controller device tree data to AM33XX dtsi file
> by adding d_can device node with all the necessary parameters.
>
> Signed-off-by: AnilKumar Ch
> ---
> arch/arm/boot/dts/am33xx.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 9b974dc..2db2ffb 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -163,5 +163,10 @@
> #size-cells = <0>;
> ti,hwmods = "i2c3";
> };
> +
> + dcan1: d_can@481D {
> + compatible = "bosch,d_can";
> + ti,hwmods = "d_can1";
> + };
Anil,
Any reason why we are only specifying dcan1 instance? Shouldn't we
specify dcan0 as well here?
Thanks,
Vaibhav
> };
> };
>
--
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 2/2] OMAP4: otg: phy: remove uggly mdelay(200)
Hi, On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol wrote: > The original issue with powering on the PHY (and using > 200 ms delay after this) is not related to internal > processes in the PHY but is in the incorrect charger > detection feature usage. > > Now when it is fixed, we can safely remove this uggly So is this 200ms delay related to incorrect charger detection? How is it now fixed without the delay? Thanks Kishon -- 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
