[PATCH] Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2
http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2
and appears to have been sent for merging before one of its prerequisites
was merged:
http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2
Signed-off-by: Paul Walmsley
Cc: Jean Pihet
Cc: Kevin Hilman
Cc: Aaro Koskinen
Cc: Felipe Balbi
---
Intended for 3.7-rc.
arch/arm/plat-omap/i2c.c | 21 +
drivers/i2c/busses/i2c-omap.c | 32 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5683a8..6013831 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,12 +26,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#define OMAP_I2C_SIZE 0x3f
@@ -127,6 +129,16 @@ static inline int omap1_i2c_add_bus(int bus_id)
#ifdef CONFIG_ARCH_OMAP2PLUS
+/*
+ * XXX This function is a temporary compatibility wrapper - only
+ * needed until the I2C driver can be converted to call
+ * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
+ */
+static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, t);
+}
+
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -158,6 +170,15 @@ static inline int omap2_i2c_add_bus(int bus_id)
dev_attr = (struct omap_i2c_dev_attr *)oh->dev_attr;
pdata->flags = dev_attr->flags;
+ /*
+* When waiting for completion of a i2c transfer, we need to
+* set a wake up latency constraint for the MPU. This is to
+* ensure quick enough wakeup from idle, when transfer
+* completes.
+* Only omap3 has support for constraints
+*/
+ if (cpu_is_omap34xx())
+ pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..0b02543 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,7 +43,6 @@
#include
#include
#include
-#include
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -187,8 +186,9 @@ struct omap_i2c_dev {
int reg_shift; /* bit shift for I2C register
addresses */
struct completion cmd_complete;
struct resource *ioarea;
- u32 latency;/* maximum MPU wkup latency */
- struct pm_qos_request pm_qos_request;
+ u32 latency;/* maximum mpu wkup latency */
+ void(*set_mpu_wkup_lat)(struct device *dev,
+ long latency);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -494,7 +494,9 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev,
u8 size, bool is_rx)
dev->b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
- dev->latency = (100 * dev->threshold) / (1000 * dev->speed / 8);
+ if (dev->set_mpu_wkup_lat != NULL)
+ dev->latency = (100 * dev->threshold) /
+ (1000 * dev->speed / 8);
}
/*
@@ -629,16 +631,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r < 0)
goto out;
- /*
-* When waiting for completion of a i2c transfer, we need to
-* set a wake up latency constraint for the MPU. This is to
-* ensure quick enough wakeup from idle, when transfer
-* completes.
-*/
- if (dev->latency)
- pm_qos_add_request(&dev->pm_qos_request,
- PM_QOS_CPU_DMA_LATENCY,
- dev->latency);
+ if (dev->set_mpu_wkup_lat != NULL)
+ dev->set_mpu_wkup_lat(dev->dev, dev->latency);
for (i = 0; i < num; i++) {
r = omap_i2c_xfer_msg(adap, &msgs[i], (i == (num - 1)));
@@ -646,8 +640,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
break;
}
- if (dev->latency)
- pm_qos_remove_request(&dev->pm_qos_request);
+ if (dev->set_mpu_wkup_lat != NU
Re: [PATCH] i2c: omap: Move the remove constraint
Hi Shubhrajyoti, On Tue, Nov 6, 2012 at 10:54 AM, Shubhrajyoti D wrote: > Currently we just queue the transfer and release the > qos constraints, however we donot wait for the transfer > to complete to release the constraint. Move the remove > constraint after the bus busy as we are sure that the > transfers are completed by then. > > Signed-off-by: Shubhrajyoti D Good catch, the change definitely makes sense. Feel free to add: Acked-by: Jean Pihet Thanks, Jean. > --- > drivers/i2c/busses/i2c-omap.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 94ff685..8b079d7 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -655,13 +655,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg > msgs[], int num) > break; > } > > - if (dev->latency) > - pm_qos_remove_request(&dev->pm_qos_request); > - > if (r == 0) > r = num; > > omap_i2c_wait_for_bb(dev); > + > + if (dev->latency) > + pm_qos_remove_request(&dev->pm_qos_request); > out: > pm_runtime_mark_last_busy(dev->dev); > pm_runtime_put_autosuspend(dev->dev); > -- > 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 -- 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 baseline test results for v3.7-rc1
On Tue, 6 Nov 2012, Jean Pihet wrote: > On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman > wrote: > > > FYI... I just ran across what appears to be the same bug on 3430/n900 > > during suspend/resume testing. With CPUidle enabled, this happens every > > time. > > > > Reverting the I2C QoS patch makes it work again. > > That makes sense with CPU_IDLE enabled and suspend. ... > For the records here are the patches that have been submitted to > support the OMAP PM QoS: > - func power states [1], > - OMAP PM QoS support [2], which includes the latency figures update > and which depends on [1], > - the conversion of I2C to PM QoS [3], > - the removal of the old no-op OMAP PM API [4], which depends on [3], > > The chicken-and-egg problem is clearly visible since [3] depends on [2]. Well it's definitely time for a revert, then. #3 should not have been sent until #2 was merged. Will send this in a new thread, please ack it. - 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: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 03:38 AM, Bedia, Vaibhav wrote: > Hi Jon, > > On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote: > [...] >> >> Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx? >> Is it using smart-idle? >> > > Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup > since this timer is not wakeup capable) but unfortunately this is not > sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in > PER domain are disabled by s/w, PER domain can't transition. > >>> The next one is that >>> the clockevent doesn't generate any further interrupts once the >>> system resumes. We need to restore the pre-suspend configuration. >>> I haven't tried but I guess we could have used the save and restore >>> of timer registers here. >> >> It would be interesting to try using an non-wakeup domain timer on >> OMAP3/4 for clock events and seeing if suspend/resume works. >> >> Do you know what the exact problem here is? I understand that the timer >> context could get lost, but exactly what is not getting restarted by the >> kernel? For example, the only place we set the interrupt enable is >> during the clock event init and so if the context is lost, then I could >> see no more interrupts occurring. So is it enough to just restore the >> interrupt enable register, do you really need to program the timer again? >> > > Just restoring the interrupt enable register works. But since there's no logic > retention I think a context save-restore would be better. Ok, we may need to check the order in which events occur following resume. The kernel will restart the clock-events and we just need to make sure we do not restore the context after the clock-events has been restarted. Cheers Jon -- 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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 01:32 AM, Bedia, Vaibhav wrote:
> Hi Jon,
>
> On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
> [...]
>>> static struct clock_event_device clockevent_gpt = {
>>> .name = "gp_timer",
>>> .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
>>> @@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
>>> .rating = 300,
>>> .set_next_event = omap2_gp_timer_set_next_event,
>>> .set_mode = omap2_gp_timer_set_mode,
>>> + .suspend= omap_clkevt_suspend,
>>> + .resume = omap_clkevt_resume,
>>
>> So these suspend/resume callbacks are going to be called for all OMAP2+
>> and AM devices? I don't think we want that. AFAIK OMAP timers will
>> idle on their own when stopped and don't require this.
>>
>
> IMO instead of skipping the callback registration we could have checks in the
> suspend/resume callbacks to decide what to do.
>
> I'll check if the idling part is AM33xx specific. If not, based on the recent
> timer
> changes that you did, perhaps checking if the clockevent selected doesn't
> have the
> "ti,timer-alwon" capability will be good enough. What do you think?
Yes, I was thinking along the same lines. If I get chance I will try and
test your scenario on an OMAP3 too.
Cheers
Jon
--
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: hdmi on 4430 (kernel 3.4)
On 11/06/2012 03:05 AM, Federico Fuga wrote: > Hi Jon, > > > Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter ha > scritto: > >>> I wanted to check the HDMI registers, but I didn't find the hdmi registers >>> table on the TRM. >>> Does someone have some hint, comment or previous experience on that? >>> Where can I find the hdmi registers list on the manual or other >>> documentation? >>> Note that as far as i know, the 2.6.35 kernel was working correctly (I >>> can't check right now, unfortunately). >>> Thank you. >> >> I would recommend posting this query on the TI E2E forum for Linux [1]. >> You may get better help there seeing that this is with regard to a >> specific TI development kernel branch. >> > > > Thank you very much for the suggestion! I'll post there. > Can you confirm that the kernel version I am using works without problem with > HDMI-1080p? Sorry, I have not tried. However, hopefully someone from the forum can help. Cheers Jon -- 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] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
On Mon, Oct 22, 2012 at 6:29 PM, Felipe Balbi wrote:
> prepare() is supposed to prevent new children from
> being registered. On the MMC subsystem, children
> (new cards) registration starts with the card
> detect IRQ.
>
> Move card detect IRQ disabling to prepare() so that
> no new cards will be registered while we're trying
> to suspend.
>
> Likewise, move card detect IRQ enabling to complete()
> so we only try to register new children after our MMC
> IP is back up.
>
> Signed-off-by: Felipe Balbi
> ---
>
> Venkat, do you think the patch below makes sense ?
Except for the minor nit mentioned below, it works well.
I'll include it in my patch series.
>
> cheers
>
> drivers/mmc/host/omap_hsmmc.c | 45
> ---
> 1 file changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 54bfd0c..4c8b41e 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2022,6 +2022,26 @@ static int __devexit omap_hsmmc_remove(struct
> platform_device *pdev)
> }
>
> #ifdef CONFIG_PM
> +static int omap_hsmmc_prepare(struct device *dev)
> +{
> + struct omap_hsmmc_host *host = dev_get_drvdata(dev);
> +
> + if (host->pdata->suspend)
> + return host->pdata->suspend(dev, host->slot_id);
> +
> + return 0;
> +}
> +
> +static int omap_hsmmc_complete(struct device *dev)
The .complete() function prototype requires to return void.
This one emits a compilation warning.
--
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] ARM: dts: AM33XX: Add usbss node
On 11/06/2012 03:29 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:59:38PM +0530, Afzal Mohammed wrote:
>> From: Ajay Kumar Gupta
>>
>> Device tree node for usbss on AM33XX. There are two musb
>> controllers on am33xx platform so have port0-mode and
>> port1-mode data.
>>
>> [af...@ti.com: reg & interrupt property addition]
>>
>> Signed-off-by: Ajay Kumar Gupta
>> Signed-off-by: Santhapuri, Damodar
>> Signed-off-by: Ravi Babu
>> Signed-off-by: Afzal Mohammed
>
> to my eyes, this looks ok.
>
> Reviewed-by: Felipe Balbi
Thanks Felipe. Patch applied in for_3.8/dts_part2 branch.
Regards,
Benoit
>
>> ---
>>
>> v2: node named as "usb"
>>
>> Depends on "usb: musb: dsps: dt binding - add resources, example"
>> (https://patchwork.kernel.org/patch/1704691/)
>>
>> arch/arm/boot/dts/am33xx.dtsi | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 5dfd682..20a3f29 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -321,5 +321,22 @@
>> ti,hwmods = "spi1";
>> status = "disabled";
>> };
>> +
>> +usb@4740 {
>> +compatible = "ti,musb-am33xx";
>> +reg = <0x4740 0x1000/* usbss */
>> + 0x47401000 0x800 /* musb instance 0 */
>> + 0x47401800 0x800>; /* musb instance 1 */
>> +interrupts = <17/* usbss */
>> + 18/* musb instance 0 */
>> + 19>; /* musb instance 1 */
>> +multipoint = <1>;
>> +num-eps = <16>;
>> +ram-bits = <12>;
>> +port0-mode = <3>;
>> +port1-mode = <3>;
>> +power = <250>;
>> +ti,hwmods = "usb_otg_hs";
>> +};
>> };
>> };
>> --
>> 1.7.12
>>
>
--
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/RESEND 2/2] usb: musb: dsps: document dt bindings properly
DT bindings normally use '-' (hyphens) instead of '_' (underscore), driver has it the proper way, but binding documentation does not reflect it, fix it. Signed-off-by: Afzal Mohammed --- Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index ca8fa56..a922505 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -3,12 +3,12 @@ AM33XX MUSB GLUE - 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 + - 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" + - 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" + - 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. -- 1.7.12 -- 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/RESEND 1/2] Revert "usb: musb: dsps: remove explicit NOP device creation"
This reverts commit d8c3ef256f88b7c6ecd673d03073b5645be9c5e4. Above mentioned change was made along with multi usb phy change and adding DT support for nop transceiver. But other two changes did not make it to mainline. This in effect makes dsps musb wrapper unusable even for single instance. Hence revert it so that at least single instance can be supported. Signed-off-by: Afzal Mohammed --- drivers/usb/musb/musb_dsps.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 6053af1..e770f79 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -411,7 +411,8 @@ 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; - /* Get the NOP PHY */ + /* NOP driver needs change if supporting dual instance */ + usb_nop_xceiv_register(); musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.12 -- 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/RESEND 0/2] usb: musb: am335x support part-2
Hi Balbi, This is a resend of remaining changes to get am335x usb working. These were sent on 31 Oct with subject, "usb: musb: dsps: fixes for -rc. First one restores capability to support at least one instance of musb. Without it, even a single instance can't be supported as change which is reverted by it was made along with multi phy changes and nop transciever dt support, both other changes didn't make it to mainline. Second one corrects binding document; changes were made in driver as per review comments, but documentation was not updated. This is made on top of your "musb" branch. To get USB0 functional on am335x based boards like beagle bone, first one is required. Regards Afzal Afzal Mohammed (2): Revert "usb: musb: dsps: remove explicit NOP device creation" usb: musb: dsps: document dt bindings properly Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 drivers/usb/musb/musb_dsps.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) -- 1.7.12 -- 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 RESEND 00/10] ARM: dts: AM33XX: Add device tree data
Hi Anil, On 11/06/2012 02:48 PM, AnilKumar Ch wrote: > Add device tree date for GPIO based various drivers matrix keypad, > volume keys, push buttons and use leds accross three AM33XX devices > viz EVM, BeagleBone and Starter Kit. > > To make it functional this series also adds pinctrl data for all > the GPIOs used by various drivers. In this series only default state > pinmux/conf settings are added because of sleep/idle state pinctrl > values are not available. > > These patches are based on linux-omap-dt:for_3.8/dts_part2 tree and > these were tested on am33xx devices according to added functionality. > > Change log: > - Rebased on for_3.8/dts_part2 Thanks for the update. Applied in for_3.8/dts_part2. BTW, I've just noticed that am335x-evmsk is not built with make dtbs. The target was missing from the arch/arm/boot/dts/Makefile. Please find below the patch to add it. Thanks, Benoit --- >From 6990451aca80a5107206688308302241f799057a Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Tue, 6 Nov 2012 15:52:23 +0100 Subject: [PATCH] ARM: dts: Makefile: Add the am335x-evmsk target in dtbs list The EVMSK was not built with the 'make dtbs' command. Add the missing antry in the dts Makefile. Signed-off-by: Benoit Cousson --- arch/arm/boot/dts/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 634bd42..2458b69 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap4-sdp.dtb \ omap5-evm.dtb \ am335x-evm.dtb \ + am335x-evmsk.dtb \ am335x-bone.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_U8500) += snowball.dtb -- 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: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen wrote: > On 2012-11-05 16:21, Rob Clark wrote: >> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: > But even then, choosing the manager is not easy, as whoever chooses the > >>manager needs to observe all the possible displays used at the same > >>time... > >Right. I was wondering if omapfb/omapdrm could understand the 'all >possible displays information' better compared to a panel's probe. > >Even omapdrm/omafb can't be perfect because we could insert a panel >driver module at any time, and omapfb/omapdrm may miss that out. >>> True, omapdrm/fb may have a better idea. It's still unclear though. >>> Currently we have quite strict order in the sequence the modules need to >>> be loaded, which is quite bad and causes issues. We should make things >>> more dynamic, so that the initialization of the drivers could happen >>> more freely. >>> >>> But that creates more problems: when booting up, omapfb starts. But >>> omapfb can't know if all the panel drivers have already been loaded. >>> omapfb may see that DVI is the default display, but what should it do if >>> DVI doesn't have a driver yet? It could wait, but perhaps the driver for >>> DVI will never even be loaded. >> >> The encoder which is connected to the crtc (manager) is picked by >> combination of encoder->possible_crtcs bitmask and >> connector->best_encoder(). We could keep things limited so that the >> association of crtc to encoder (manager to output, roughly) never >> changes, but this isn't really the right thing to do. It is better that >> the dssdev not rely on knowing the manager it is attached to at probe >> time, but instead grab resources more dynamically. >> >> Also, at the moment we don't really have any notification to userspace >> about new encoders/connectors showing up (or conversely, being >> removed). Only about existing connectors being plugged/unplugged. The >> closest analogy is perhaps the USB display devices, but even there it is >> only the entire drm device that is plugged/unplugged. And TBH I don't >> really see the point in supporting panel drivers being dynamically >> loaded. It isn't like someone is dynamically soldering on a new display >> connector to some board that is running. I think omapfb or omapdrm >> probe should trigger registering the compiled-in panel drivers, so that >> it can be sure that the dssdev's pop up before it goes and creates drm >> connector objects. Currently we have to hack around this in omapdrm >> with late_initcall() to ensure the panel drivers are probed first, but >> that is an ugly hack that I'd like to get rid of. > > We have panel devices and panel drivers, each of which can appear at any > time. Both are needed for the panel probe to happen. If we don't support > device hotplugging (dynamic creation of devices), we need to use > late_initcall for omapfb/drm. At least I don't see any other option. > > You say that omapdrm should trigger registering of the drivers. How > would that work? Do you mean that the panel drivers would register > themselves to some common list, and omapdrm would go through this list > when drm is loaded, calling probe for the items in the list? I guess > that's doable, but... It's not how kernel drivers are supposed to work, > and so doesn't sound very clean approach to me. I mean, similar to how we handle the subdev for dmm.. the omap_drm_init() does the platform_driver_register() for the dmm device before the platform_driver_register() for omapdrm itself, so we know if there is a dmm device, the driver gets probed first before omapdrm. It could be a matter of iterating through a list, or something like this.. that is basically an implementation detail. But the end result is that the order the drivers are registered is controlled so the probe sequence works out properly (not to mention suspend/resume sequence). > I think we should support proper hotplugging of the panels. This would > fix the problem about init order, but it would also give us device > hotplug support. Obviously nobody is going to solder panel to a running > board, but I don't see any reason why panels, or, more likely, panels on > an add-on boards (like the capes being discussed in omap ml) would not > be hotpluggable using whatever connector is used on the particular use case. > > And even if we don't support removing of the devices, things like the > add-on capes could cause the panel on the cape to be identified at some > late time (the panel is not described in the board file or DT data, but > found at runtime depending on the ID of the cape). This would add > another step to the init sequence that should be just right, if we don't > support hotplug. If capes are really hot-pluggable, then maybe it is worth thinking about how to make this more dynamic. Although it is a bigger problem, which involves userspace being aware that connectors can dynamically appear/disappear. And the dynamic di
RE: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Hi Santosh, On Tue, Nov 06, 2012 at 03:29:22, Shilimkar, Santosh wrote: [...] > > > > IMO, assuming that idle will not be useful from the begining is leading > > down the path to poor design choices that will be much more difficult to > > fixup down the road in order to add idle support later. We need to > > design both idle and suspend at the same time. > > > I agree with Kevin. Not supporting CPUIDLE deep states can hit the > active power numbers dearly. I just don't know why the SOCs don't share > the standard and must have design choices. But thats another discussion. > Yes, active power numbers are not comparable to OMAP :( > How about leaving the timer choices as is. PER timer for clock source > and wakeuptimer for clock event. Anyway in suspend the clock-source > can be suspended and that is evident from recent discussion. The only > downside is you won't count time in suspend which is any way the case. > > Vaibhav, > Do you guys see any implementation bottleneck for above ? > Looking at the timekeeping code I see one more potential reason for making this change. OMAP registers the 32k sync timer as the persistent clock and since there's no 32k sync timer in AM33xx it doesn't register a persistent clock right now. Based on what I understood, we need to have to register one and DMTimer1 is the only clock that can serve as the persistent clock in suspend state. When we do so we might as well use it as the clocksource. A related question that I had was, is there a mechanism to handle the 32k counter (DMTimer or sync timer) wraparound condition in suspend? Regards, 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 4/5] usb: musb: dsps: dt binding - add resources, example
Hi Balbi,
On Tuesday 06 November 2012 06:32 PM, Felipe Balbi wrote:
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
+Example:
+
+usb_otg_hs@4740 {
this should be usb@4740.
Updated version with the above change has been posted.
Regards
Afzal
--
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] ARM: dts: AM33XX: Add usbss node
Hi,
On Tue, Nov 06, 2012 at 07:59:38PM +0530, Afzal Mohammed wrote:
> From: Ajay Kumar Gupta
>
> Device tree node for usbss on AM33XX. There are two musb
> controllers on am33xx platform so have port0-mode and
> port1-mode data.
>
> [af...@ti.com: reg & interrupt property addition]
>
> Signed-off-by: Ajay Kumar Gupta
> Signed-off-by: Santhapuri, Damodar
> Signed-off-by: Ravi Babu
> Signed-off-by: Afzal Mohammed
to my eyes, this looks ok.
Reviewed-by: Felipe Balbi
> ---
>
> v2: node named as "usb"
>
> Depends on "usb: musb: dsps: dt binding - add resources, example"
> (https://patchwork.kernel.org/patch/1704691/)
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 5dfd682..20a3f29 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -321,5 +321,22 @@
> ti,hwmods = "spi1";
> status = "disabled";
> };
> +
> + usb@4740 {
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> + };
> };
> };
> --
> 1.7.12
>
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Hi Kevin, On Mon, Nov 05, 2012 at 23:33:07, Kevin Hilman wrote: > "Bedia, Vaibhav" writes: > > > On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote: > > [...] > >> >> > >> >> Doesn't this also mean that you won't get timer wakeups > >> >> in idle? Or are you keeping the domain where the clockevent is > >> >> on during idle? > >> >> > >> > > >> > The lowest idle state that we are targeting will have MPU powered > >> > off with external memory in self-refresh mode. Peripheral domain > >> > with the clockevent will be kept on. > >> > >> Is this a limitation of the hardware? or the software? > >> > > > > Well, making the lowest idle state same as the suspend state will > > require us to involve WKUP_M3 in the idle path and wakeup sources get > > limited to the IPs in the WKUP domain alone. There's no IO daisy > > chaining in AM33XX so that's one big difference compared to OMAP. The > > other potential problem is that the IPC mechanism that we have uses > > interrupts. > > It can still interrupt the M3, it's only the interrupt back to the MPU > that is the issue, right? That being said, there's no reason it > couldn't use polling in the idle path, right? > Yes we could use polling but I think we have a bigger problem in the chip architecture. > > Assuming that the lowest idle state, say Cx, is the same as the > > suspend state, we'll need to communicate with the WKUP_M3 using > > interrupts once we decide to enter Cx. I am not sure if we can do > > something in the cpuidle implementation to work around the "interrupt > > for idle" problem. > > > > We could probably not wait for an ACK when we want to enter Cx, > > why not? > > Are the response times from the M3 really up to 500ms (guessing based on > the timeout you used in the suspend path.) That seems rather unlikely. > No 500ms is too high. Actual delays would be much lower, I need to check with the design team on the expected number. > Hmm, but as I think about it. Why does the MPU need to wait for an ACK > at all? Why not just send the cmd and WFI? > I have myself being going back and forth on this. There are lot of things that we do in software, DDR being one of them. We can't do some of the DDR related stuff unless memory enter self-refresh AND EMIF gets disabled. Doing so essentially means that the drivers have entered sort of suspend state. Given this h/w limitation I don't see how we could handle without impacting a running system. > > but the problem of limited wakeup sources remains. If we let the > > various drivers block the entry to Cx, since almost all the IPs are in > > the peripheral domain a system which uses anything other than UART and > > Timer in WKUP domain will probably never be able enter Cx. > > Even so, I think the system needs to be designed to hit the same power > states in idle and suspend. Then, the states can be restricted based > wakeup capabilities as you described. This would be easy to do in the > runtime PM implementation for this device. > > IMO, assuming that idle will not be useful from the begining is leading > down the path to poor design choices that will be much more difficult to > fixup down the road in order to add idle support later. We need to > design both idle and suspend at the same time. > Getting PER to transition on a running system is something I can't figure out. Maybe MPU OFF is the lowest we can go. > Also, don't forget about GPIO0. Systems could easily be built such that > peripherals which want to wakeup but don't have native wakeup > capabilities could use a GPIO in bank 0 to wake the system. > > Similarily, I2C0 is in WKUP, and brought out to capes, so some simple > designs with with I2C devices on a cape might be perfectly capable of > hitting deep power states in idle. > Ok this is interesting. AFAIK I2C wakeup requires the device to be operating in slave mode. If so, is this something that's already supported on OMAP? Regards, 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
[PATCH v2] ARM: dts: AM33XX: Add usbss node
From: Ajay Kumar Gupta
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg & interrupt property addition]
Signed-off-by: Ajay Kumar Gupta
Signed-off-by: Santhapuri, Damodar
Signed-off-by: Ravi Babu
Signed-off-by: Afzal Mohammed
---
v2: node named as "usb"
Depends on "usb: musb: dsps: dt binding - add resources, example"
(https://patchwork.kernel.org/patch/1704691/)
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..20a3f29 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = "spi1";
status = "disabled";
};
+
+ usb@4740 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800>; /* musb instance 1 */
+ interrupts = <17/* usbss */
+ 18/* musb instance 0 */
+ 19>; /* musb instance 1 */
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ port0-mode = <3>;
+ port1-mode = <3>;
+ power = <250>;
+ ti,hwmods = "usb_otg_hs";
+ };
};
};
--
1.7.12
--
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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
Hi Benoit, On Tue, Nov 06, 2012 at 19:20:46, Cousson, Benoit wrote: > Hi Vaibhav & Vaibhav, > > On 11/06/2012 02:46 PM, Bedia, Vaibhav wrote: > > On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: > >> On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: > >>> On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: > >>> [...] > > > > Ok I checked this one. The change I made was indirectly fixing another > > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > > entries and the SYSC register is part of the second entry. The function > > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > > SYSC address of CPGMAC0 and the IP went to standby during bootup. > > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > > things work fine. > > > > Good catch. > > Just a side note on this, driver expects the addresses in this order > only, first SS and then WR. > > >>> > >>> Sorry I didn't understand your comment. For HWMOD code to work as > >>> expected, > >>> we need to change the order. > >> > >> Why do you want to change the order? Just specify "ADDR_TYPE_RT", that > >> should be it. > >> > > > > The problem is that the memory space without the SYSC comes first and is > > labeled > > as ADDR_TYPE_RT. I think this is not correct and hence either we change the > > order > > or remove the flag from the first entry. If we do the latter then taking > > the logic > > of putting in the flag only for memory spaces with SYSC further we need to > > fixup > > the entries for ephrpwm0/1/2 and ecap0/1/2. > > The order should not matter, just use ADDR_TYPE_RT for the relevant > entry. I have a patch ongoing to remove this flag for the non-SYSC entry > to avoid this kind of confusion. > The name should probably be changed as well to reflect that at some point. > Since these entries will be removed anyway with pure DT boot, that > should be a temporary issue. > Thanks for the clarification. I'll make the change accordingly. Regards, 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
[PATCH v2] usb: musb: dsps: dt binding - add resources, example
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed
---
v2: node name changed to "usb"
.../devicetree/bindings/usb/am33xx-usb.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be "ti,musb-am33xx"
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be "usb_otg_hs"
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+ compatible = "ti,musb-am33xx";
+ reg = <0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800>; /* musb instance 1 */
+ interrupts = <17/* usbss */
+ 18/* musb instance 0 */
+ 19>; /* musb instance 1 */
+ multipoint = <1>;
+ num-eps = <16>;
+ ram-bits = <12>;
+ port0-mode = <3>;
+ port1-mode = <3>;
+ power = <250>;
+ ti,hwmods = "usb_otg_hs";
+};
--
1.7.12
--
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 0/3] capebus moving omap_devices to mach-omap2
Από το iPhone μου 6 Νοε 2012, 12:16, ο/η Grant Likely έγραψε: > On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou > wrote: >> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: >>> Sure, so if we add data type supplementary properties to the tree to >>> indicate the data type as "indirect phandle", then kernel could refer >>> to the index in the got-like table to fetch the actual phandle address >>> (1-level of indirection), instead of directly using the address in the >>> data field. >> >> I'm fine with this. > > But if the data about phandles is already in the tree, then the need > for a GOT simply goes away. The phandles can be fixed up directly and > it is so much better because it works with existing parsing code after > the merge is applied. > Either way works. It is your call after all. I agree that your method is simpler. > g. Regards -- Pantelis-- 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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
Hi Vaibhav & Vaibhav, On 11/06/2012 02:46 PM, Bedia, Vaibhav wrote: > On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: >> On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: >>> On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: >>> [...] > > Ok I checked this one. The change I made was indirectly fixing another > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > entries and the SYSC register is part of the second entry. The function > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > SYSC address of CPGMAC0 and the IP went to standby during bootup. > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > things work fine. > Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. >>> >>> Sorry I didn't understand your comment. For HWMOD code to work as expected, >>> we need to change the order. >> >> Why do you want to change the order? Just specify "ADDR_TYPE_RT", that >> should be it. >> > > The problem is that the memory space without the SYSC comes first and is > labeled > as ADDR_TYPE_RT. I think this is not correct and hence either we change the > order > or remove the flag from the first entry. If we do the latter then taking the > logic > of putting in the flag only for memory spaces with SYSC further we need to > fixup > the entries for ephrpwm0/1/2 and ecap0/1/2. The order should not matter, just use ADDR_TYPE_RT for the relevant entry. I have a patch ongoing to remove this flag for the non-SYSC entry to avoid this kind of confusion. The name should probably be changed as well to reflect that at some point. Since these entries will be removed anyway with pure DT boot, that should be a temporary issue. Regards, Benoit -- 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 RESEND 08/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
Add gpio-leds device tree data to am335x-evmsk device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on am335x starter
kit.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evmsk.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 659ec5b..7262fa8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -100,6 +100,36 @@
regulator-name = "lis3_reg";
regulator-boot-on;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@1 {
+ label = "evmsk:green:usr0";
+ gpios = <&gpio2 4 0>;
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "evmsk:green:usr1";
+ gpios = <&gpio2 5 0>;
+ default-state = "off";
+ };
+
+ led@3 {
+ label = "evmsk:green:mmc0";
+ gpios = <&gpio2 6 0>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led@4 {
+ label = "evmsk:green:heartbeat";
+ gpios = <&gpio2 7 0>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+ };
};
/include/ "tps65910.dtsi"
--
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
[PATCH RESEND 05/10] ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
Add pinmux configurations for gpio based user-keys to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 91eee97..1aac58b 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,6 +24,20 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins = <
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = "okay";
--
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
[PATCH RESEND 07/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
Add pinmux configurations for gpio based volume keys to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evmsk.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 6f53879..659ec5b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -30,6 +30,20 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_leds_s0>;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins = <
+ 0x10 0x7/* gpmc_ad4.gpio1_4, OUTPUT |
MODE7 */
+ 0x14 0x7/* gpmc_ad5.gpio1_5, OUTPUT |
MODE7 */
+ 0x18 0x7/* gpmc_ad6.gpio1_6, OUTPUT |
MODE7 */
+ 0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = "okay";
--
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
[PATCH RESEND 03/10] ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
Add pinmux configurations for gpio volume keys. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 8076e66..e087b87 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&matrix_keypad_s0>;
+ pinctrl-0 = <&matrix_keypad_s0 &volume_keys_s0>;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins = <
@@ -37,6 +37,13 @@
0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
>;
};
+
+ volume_keys_s0: volume_keys_s0 {
+ pinctrl-single,pins = <
+ 0x150 0x27 /* spi0_sclk.gpio0_2, INPUT |
MODE7 */
+ 0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
+ >;
+ };
};
ocp {
--
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
[PATCH RESEND 10/10] ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
Add gpio based push buttons device tree data to am335x-evmsk device
by adding all the necessary parameters like key-code, gpios and etc.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evmsk.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0f825dd..f5a6162 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -139,6 +139,37 @@
default-state = "off";
};
};
+
+ gpio_buttons: gpio_buttons@0 {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@1 {
+ label = "button0";
+ linux,code = <0x100>;
+ gpios = <&gpio3 3 0>;
+ };
+
+ switch@2 {
+ label = "button1";
+ linux,code = <0x101>;
+ gpios = <&gpio3 2 0>;
+ };
+
+ switch@3 {
+ label = "button2";
+ linux,code = <0x102>;
+ gpios = <&gpio1 30 0>;
+ gpio-key,wakeup;
+ };
+
+ switch@4 {
+ label = "button3";
+ linux,code = <0x103>;
+ gpios = <&gpio3 5 0>;
+ };
+ };
};
/include/ "tps65910.dtsi"
--
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
[PATCH RESEND 01/10] ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
Add pinmux configurations for gpio matrix keypad. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 513284f..9199456 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -24,6 +24,21 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&matrix_keypad_s0>;
+
+ matrix_keypad_s0: matrix_keypad_s0 {
+ pinctrl-single,pins = <
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x7/* gpmc_a6.gpio1_22, OUTPUT |
MODE7 */
+ 0x64 0x27 /* gpmc_a9.gpio1_25, INPUT |
MODE7 */
+ 0x68 0x27 /* gpmc_a10.gpio1_26, INPUT |
MODE7 */
+ 0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
+ >;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = "okay";
--
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
[PATCH RESEND 04/10] ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
Add gpio based volume keys device tree data to am335x-evm by adding
all the required parameters like keycode, gpios and etc.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e087b87..9f65f17 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -137,6 +137,27 @@
0x0101001c /* ENTER */
0x0201006c>;/* DOWN */
};
+
+ gpio_keys: volume_keys@0 {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ switch@9 {
+ label = "volume-up";
+ linux,code = <115>;
+ gpios = <&gpio1 2 1>;
+ gpio-key,wakeup;
+ };
+
+ switch@10 {
+ label = "volume-down";
+ linux,code = <114>;
+ gpios = <&gpio1 3 1>;
+ gpio-key,wakeup;
+ };
+ };
};
/include/ "tps65910.dtsi"
--
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
[PATCH RESEND 00/10] ARM: dts: AM33XX: Add device tree data
Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts_part2 tree and these were tested on am33xx devices according to added functionality. Change log: - Rebased on for_3.8/dts_part2 AnilKumar Ch (10): ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk arch/arm/boot/dts/am335x-bone.dts | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 63 +++ arch/arm/boot/dts/am335x-evmsk.dts | 84 3 files changed, 191 insertions(+) -- 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
[PATCH RESEND 09/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
Add pinmux configurations for gpio based keys to am335x-evmsk. In
this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evmsk.dts | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 7262fa8..0f825dd 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = "default";
- pinctrl-0 = <&user_leds_s0>;
+ pinctrl-0 = <&user_leds_s0 &gpio_keys_s0>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
@@ -42,6 +42,15 @@
0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
>;
};
+
+ gpio_keys_s0: gpio_keys_s0 {
+ pinctrl-single,pins = <
+ 0x94 0x27 /* gpmc_oen_ren.gpio2_3, INPUT
| MODE7 */
+ 0x90 0x27 /* gpmc_advn_ale.gpio2_2, INPUT
| MODE7 */
+ 0x70 0x27 /* gpmc_wait0.gpio0_30, INPUT |
MODE7 */
+ 0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
+ >;
+ };
};
ocp {
--
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
[PATCH RESEND 06/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
Add gpio-leds device tree data to am335x-bone device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1aac58b..2c33888 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -53,6 +53,36 @@
};
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@2 {
+ label = "beaglebone:green:heartbeat";
+ gpios = <&gpio2 21 0>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led@3 {
+ label = "beaglebone:green:mmc0";
+ gpios = <&gpio2 22 0>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led@4 {
+ label = "beaglebone:green:usr2";
+ gpios = <&gpio2 23 0>;
+ default-state = "off";
+ };
+
+ led@5 {
+ label = "beaglebone:green:usr3";
+ gpios = <&gpio2 24 0>;
+ default-state = "off";
+ };
+ };
};
/include/ "tps65217.dtsi"
--
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
[PATCH RESEND 02/10] ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
Add matrix keypad device tree data to am335x-evm by adding all
the necessary parameters like keymap, row & column gpios and etc.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9199456..8076e66 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -110,6 +110,26 @@
regulator-name = "lis3_reg";
regulator-boot-on;
};
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = "gpio-matrix-keypad";
+ debounce-delay-ms = <5>;
+ col-scan-delay-us = <2>;
+
+ row-gpios = <&gpio2 25 0/* Bank1, pin25 */
+&gpio2 26 0/* Bank1, pin26 */
+&gpio2 27 0>; /* Bank1, pin27 */
+
+ col-gpios = <&gpio2 21 0/* Bank1, pin21 */
+&gpio2 22 0>; /* Bank1, pin22 */
+
+ linux,keymap = <0x008b /* MENU */
+ 0x019e /* BACK */
+ 0x0269 /* LEFT */
+ 0x0001006a /* RIGHT */
+ 0x0101001c /* ENTER */
+ 0x0201006c>;/* DOWN */
+ };
};
/include/ "tps65910.dtsi"
--
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: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: > On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: > > On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: > > [...] > > > > > > > > Ok I checked this one. The change I made was indirectly fixing another > > > > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > > > > entries and the SYSC register is part of the second entry. The function > > > > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > > > > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > > > > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > > > > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > > > > SYSC address of CPGMAC0 and the IP went to standby during bootup. > > > > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > > > > things work fine. > > > > > > > > > > Good catch. > > > > > > Just a side note on this, driver expects the addresses in this order > > > only, first SS and then WR. > > > > > > > Sorry I didn't understand your comment. For HWMOD code to work as expected, > > we need to change the order. > > Why do you want to change the order? Just specify "ADDR_TYPE_RT", that > should be it. > The problem is that the memory space without the SYSC comes first and is labeled as ADDR_TYPE_RT. I think this is not correct and hence either we change the order or remove the flag from the first entry. If we do the latter then taking the logic of putting in the flag only for memory spaces with SYSC further we need to fixup the entries for ephrpwm0/1/2 and ecap0/1/2. Regards, 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 12/12] OMAPDSS: DPI: always use DSI PLL if available
On 2012-11-05 16:21, Rob Clark wrote: > On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the >>manager needs to observe all the possible displays used at the same >>time... >>> > >>> >Right. I was wondering if omapfb/omapdrm could understand the 'all >>> >possible displays information' better compared to a panel's probe. >>> > >>> >Even omapdrm/omafb can't be perfect because we could insert a panel >>> >driver module at any time, and omapfb/omapdrm may miss that out. >> True, omapdrm/fb may have a better idea. It's still unclear though. >> Currently we have quite strict order in the sequence the modules need to >> be loaded, which is quite bad and causes issues. We should make things >> more dynamic, so that the initialization of the drivers could happen >> more freely. >> >> But that creates more problems: when booting up, omapfb starts. But >> omapfb can't know if all the panel drivers have already been loaded. >> omapfb may see that DVI is the default display, but what should it do if >> DVI doesn't have a driver yet? It could wait, but perhaps the driver for >> DVI will never even be loaded. > > The encoder which is connected to the crtc (manager) is picked by > combination of encoder->possible_crtcs bitmask and > connector->best_encoder(). We could keep things limited so that the > association of crtc to encoder (manager to output, roughly) never > changes, but this isn't really the right thing to do. It is better that > the dssdev not rely on knowing the manager it is attached to at probe > time, but instead grab resources more dynamically. > > Also, at the moment we don't really have any notification to userspace > about new encoders/connectors showing up (or conversely, being > removed). Only about existing connectors being plugged/unplugged. The > closest analogy is perhaps the USB display devices, but even there it is > only the entire drm device that is plugged/unplugged. And TBH I don't > really see the point in supporting panel drivers being dynamically > loaded. It isn't like someone is dynamically soldering on a new display > connector to some board that is running. I think omapfb or omapdrm > probe should trigger registering the compiled-in panel drivers, so that > it can be sure that the dssdev's pop up before it goes and creates drm > connector objects. Currently we have to hack around this in omapdrm > with late_initcall() to ensure the panel drivers are probed first, but > that is an ugly hack that I'd like to get rid of. We have panel devices and panel drivers, each of which can appear at any time. Both are needed for the panel probe to happen. If we don't support device hotplugging (dynamic creation of devices), we need to use late_initcall for omapfb/drm. At least I don't see any other option. You say that omapdrm should trigger registering of the drivers. How would that work? Do you mean that the panel drivers would register themselves to some common list, and omapdrm would go through this list when drm is loaded, calling probe for the items in the list? I guess that's doable, but... It's not how kernel drivers are supposed to work, and so doesn't sound very clean approach to me. I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case. And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug. Yes, I know it's not simple =). And I'm fine with simpler approach for the time being, but I'd like full hotplug to be the future goal. At least the common panel framework should not create restrictions about this, even if drm wouldn't allow device hotplug. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On 11/6/2012 3:39 PM, Bedia, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
Will remove this flag as it is a parrent-child relationship
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = &am33xx_cpgmac0_hwmod,
+ .slave = &am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
This flag is necessary as MPU is going to access to device.
The patch will look like
@@ -2501,6 +2516,21 @@ static struct omap_hwmod_ocp_if
am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = &am33xx_cpgmac0_hwmod,
+ .slave = &am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
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: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
> OMAP2+ family of devices are now obtaining resources via DT, earlier
> it was obtained from hwmod. Update binding document accrodingly, while
> at it add example.
>
> Signed-off-by: Afzal Mohammed
> ---
> .../devicetree/bindings/usb/am33xx-usb.txt | 21
> +
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> index a922505..6b7e3bd 100644
> --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
> @@ -1,5 +1,7 @@
> AM33XX MUSB GLUE
> - compatible : Should be "ti,musb-am33xx"
> + - reg : offset and length of register sets, first usbss, then for musb
> instances
> + - interrupts : usbss, musb instance interrupts in order
> - ti,hwmods : must be "usb_otg_hs"
> - multipoint : Should be "1" indicating the musb controller supports
> multipoint. This is a MUSB configuration-specific setting.
> @@ -12,3 +14,22 @@ AM33XX MUSB GLUE
> represents PERIPHERAL.
> - power : Should be "250". This signifies the controller can supply upto
> 500mA when operating in host mode.
> +
> +Example:
> +
> +usb_otg_hs@4740 {
this should be usb@4740.
> + compatible = "ti,musb-am33xx";
> + reg = <0x4740 0x1000/* usbss */
> +0x47401000 0x800 /* musb instance 0 */
> +0x47401800 0x800>; /* musb instance 1 */
> + interrupts = <17/* usbss */
> + 18/* musb instance 0 */
> + 19>; /* musb instance 1 */
> + multipoint = <1>;
> + num-eps = <16>;
> + ram-bits = <12>;
> + port0-mode = <3>;
> + port1-mode = <3>;
> + power = <250>;
> + ti,hwmods = "usb_otg_hs";
> +};
> --
> 1.7.12
>
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: > On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: > [...] > > > > > > Ok I checked this one. The change I made was indirectly fixing another > > > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > > > entries and the SYSC register is part of the second entry. The function > > > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > > > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > > > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > > > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > > > SYSC address of CPGMAC0 and the IP went to standby during bootup. > > > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > > > things work fine. > > > > > > > Good catch. > > > > Just a side note on this, driver expects the addresses in this order > > only, first SS and then WR. > > > > Sorry I didn't understand your comment. For HWMOD code to work as expected, > we need to change the order. Why do you want to change the order? Just specify "ADDR_TYPE_RT", that should be it. 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 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Tue, Nov 06, 2012 at 15:39:11, Bedia, Vaibhav wrote:
> On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
> [...]
>
> > +
> > +static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> > + .master = &am33xx_epwmss0_hwmod,
> > + .slave = &am33xx_ecap0_hwmod,
> > + .clk= "l4ls_gclk",
> > + .addr = am33xx_ecap0_addr_space,
> > + .user = OCP_USER_MPU,
> > +};
>
> Noticed this in another patch which is quite similar so commenting here
> again. Is the user field required if you are just creating a parent-child
> relationship here?
>
I think user field is not related to parent-child nodes, it defines the
initiator to interact with hwmod
Copy-pasted from "arch/arm/plat-omap/include/plat/omap_hwmod.h"
"indicate the initiators that use this interface to interact with the
hwmod"
And in this case, its MPU is the initiator to interact with this interface.
Thanks,
Vaibhav
> Regards,
> 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tue, Nov 06, 2012 at 18:08:36, Shilimkar, Santosh wrote: > On Tuesday 06 November 2012 06:29 AM, Bedia, Vaibhav wrote: > > Hi Santosh, Kevin > > > > On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: > > [...] > > > + > +/* > + * This a subset of registers defined in drivers/memory/emif.h > + * Move that to include/linux/? > + */ > >>> > >>> I'd probably suggest just moving the register definitions you > >>> need into so they can be shared with the driver. > >>> > >>> Also, the EMIF stuff would benefit greatly from using symbolic defines > >>> for the values being written. Probably having those in > >>> would also help out here. > >>> > >>> Or, maybe the EMIF driver can provide some self-contained stubs that can > >>> be copied to OCP RAM for the functionality needed here? > >>> > >>> Santosh, what do you think of that? > >>> > >> Thats what I mentioned in my comment. I also don't know why such a bad > >> hardware choice was made when we have perfectly working EMIF IP across > >> low power states. Even the self refresh control is managed inside > >> hardware upon idle. My guess is DDR self-refresh might be the reason > >> to use OCMC RAM. > >> > >> In either case, Keeping EMIF changes separate as part of EMIF > >> driver/platform code is right way to go about it. May be the > >> disable_selfrefresh() might need to kept in assembly files since it > >> needs to be running from SRAM but rest need not be part of > >> PM code. > >> > > > > > > In the suspend path we do lot of I/O manipulations to lower final power > > number which must be done after the external memory has gone into > > self-refresh. So, these steps will have to be done from code in OCMC RAM. > > > Only the DDR IO needs to be done after memory enters into self refresh. > Rest of the IOs can be handled and moved to low power modes before DDR > being in self refresh, No ? > All the code is related to DDR IOs only. We have some code for changing the pull configuration of the DATA and CMD macros of the PHY and then some code for DDR VTP control. We also switch over the DDR IOs to mDDR mode to lower the leakage. > > Other than saving the EMIF configuration the other thing that we do during > > suspend from assembly is to put the PLLs in bypass. We could possibly move > > the DISP PLL bypass to C code. MPU PLL is another candidate but this might > > add in more delays in the suspend and abort sequence (I don't have any > > delay numbers to justify this right now) > > > So DPLLS doesn't support low power bypass mode which should take > care of itself on clock gating ? Are the DPLL IPs different than > what they are on OMAP ? Same IP but no auto-mode :( > > > The resume path undoes the I/O manipulations and then restores the EMIF > > configuration all of which I think is necessary before we can jump back to > > external memory. > > > As I memtioned above, you should limit these IOs to only DDR IOs. > > > So, I think we'll have just the EMIF context save and possibly the PLL > > bypass for DISP PLL during suspend that we can move out of assembly. > > > EMIF context save also can be done in advance. Restore is what you need > to take care in early resume before bringing out DDR out of self > refresh. > Yes I can move the context save earlier. Will try that out and put in the next version. > > Coming to point of sharing the EMIF register definitions, with the recent > > changes to move around the header files out of plat-omap, is it ok to > > add in the required offsets and related bit-field definitions from > > the EMIF driver to plat-omap? > > > We can have that in linux/include/* as well if the register > defines can be shared. > Ok. Regards, 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 v2 2/2] mailbox: split internal header from API header
On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
> Now internal structures can remain hidden to the user and just API
> related functions and defines are made available.
>
> Signed-off-by: Omar Ramirez Luna
> ---
> drivers/mailbox/mailbox.c | 34
> drivers/mailbox/mailbox.h | 48
> +
> include/linux/mailbox.h | 22 +++
I agree with the file split but I think mailbox framework API should be
more generic.
omap_ prefix should not be used. mailbox_ prefix will be better.
Message type must be more opened like for example:
struct mailbox_msg {
int size;
unsigned char header;
unsigned char *pdata;
};
Regards,
Loic--
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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tuesday 06 November 2012 06:29 AM, Bedia, Vaibhav wrote: Hi Santosh, Kevin On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: [...] + +/* + * This a subset of registers defined in drivers/memory/emif.h + * Move that to include/linux/? + */ I'd probably suggest just moving the register definitions you need into so they can be shared with the driver. Also, the EMIF stuff would benefit greatly from using symbolic defines for the values being written. Probably having those in would also help out here. Or, maybe the EMIF driver can provide some self-contained stubs that can be copied to OCP RAM for the functionality needed here? Santosh, what do you think of that? Thats what I mentioned in my comment. I also don't know why such a bad hardware choice was made when we have perfectly working EMIF IP across low power states. Even the self refresh control is managed inside hardware upon idle. My guess is DDR self-refresh might be the reason to use OCMC RAM. In either case, Keeping EMIF changes separate as part of EMIF driver/platform code is right way to go about it. May be the disable_selfrefresh() might need to kept in assembly files since it needs to be running from SRAM but rest need not be part of PM code. In the suspend path we do lot of I/O manipulations to lower final power number which must be done after the external memory has gone into self-refresh. So, these steps will have to be done from code in OCMC RAM. Only the DDR IO needs to be done after memory enters into self refresh. Rest of the IOs can be handled and moved to low power modes before DDR being in self refresh, No ? Other than saving the EMIF configuration the other thing that we do during suspend from assembly is to put the PLLs in bypass. We could possibly move the DISP PLL bypass to C code. MPU PLL is another candidate but this might add in more delays in the suspend and abort sequence (I don't have any delay numbers to justify this right now) So DPLLS doesn't support low power bypass mode which should take care of itself on clock gating ? Are the DPLL IPs different than what they are on OMAP ? The resume path undoes the I/O manipulations and then restores the EMIF configuration all of which I think is necessary before we can jump back to external memory. As I memtioned above, you should limit these IOs to only DDR IOs. So, I think we'll have just the EMIF context save and possibly the PLL bypass for DISP PLL during suspend that we can move out of assembly. EMIF context save also can be done in advance. Restore is what you need to take care in early resume before bringing out DDR out of self refresh. Coming to point of sharing the EMIF register definitions, with the recent changes to move around the header files out of plat-omap, is it ok to add in the required offsets and related bit-field definitions from the EMIF driver to plat-omap? We can have that in linux/include/* as well if the register defines can be shared. Regards Santosh -- 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] omap3 nand : use NAND_BUSWIDTH_AUTO
Cc: Tony Lindgren, Afzal Mohammed,
On 11/06/12 12:51, Matthieu CASTET wrote:
> This allow to clean the omap nand driver that were trying in x8 and x16 bits
> mode.
>
> This also make work onfi detection on beagleboard :
>
> Before :
> [1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND
> 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64
>
> After :
> [1.914825] ONFI param page 0 valid
> [1.919158] ONFI flash detected
> [1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
> MT29F2G16ABD), page size: 2048, OOB size: 64
>
> platform data devsize is renamed bussize. It now indicate the maximun size of
> the nand bus.
>
> Signed-off-by: Matthieu CASTET
I think, you should base on one of Tony's branches with that kind of patches.
Because, for example the omap_nand_flash_init() function does not exist anymore
in Tony's master and may be several more things will need to have adjustments.
Also, the GPMC related stuff inside the NAND driver
should probably be coordinated with Afzal, as he is reworking the whole
GPMC related code.
> ---
> arch/arm/mach-omap2/board-3630sdp.c |2 +-
> arch/arm/mach-omap2/board-devkit8000.c |2 +-
> arch/arm/mach-omap2/board-flash.c|8 ++---
> arch/arm/mach-omap2/board-igep0020.c |2 +-
> arch/arm/mach-omap2/board-omap3beagle.c |2 +-
> arch/arm/mach-omap2/board-omap3evm.c |2 +-
> arch/arm/mach-omap2/board-omap3pandora.c |2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
> arch/arm/mach-omap2/board-zoom.c |2 +-
> arch/arm/mach-omap2/common-board-devices.c |2 +-
> arch/arm/mach-omap2/gpmc-nand.c |5 ---
> drivers/mtd/nand/omap2.c | 42
> ++
> include/linux/platform_data/mtd-nand-omap2.h |7 -
> 13 files changed, 42 insertions(+), 38 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c
> b/arch/arm/mach-omap2/board-3630sdp.c
> index fc224ad..d7b981b 100644
> --- a/arch/arm/mach-omap2/board-3630sdp.c
> +++ b/arch/arm/mach-omap2/board-3630sdp.c
> @@ -198,7 +198,7 @@ static void __init omap_sdp_init(void)
> h8mbx00u0mer0em_sdrc_params);
> zoom_display_init();
> board_smc91x_init();
> - board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
> + board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_OMAP_BUS_16);
> enable_board_wakeup_source();
> usbhs_init(&usbhs_bdata);
> }
> diff --git a/arch/arm/mach-omap2/board-devkit8000.c
> b/arch/arm/mach-omap2/board-devkit8000.c
> index 1fd161e..b3487e1 100644
> --- a/arch/arm/mach-omap2/board-devkit8000.c
> +++ b/arch/arm/mach-omap2/board-devkit8000.c
> @@ -621,7 +621,7 @@ static void __init devkit8000_init(void)
>
> usb_musb_init(NULL);
> usbhs_init(&usbhs_bdata);
> - omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
> + omap_nand_flash_init(NAND_OMAP_BUS_16, devkit8000_nand_partitions,
>ARRAY_SIZE(devkit8000_nand_partitions));
> omap_twl4030_audio_init("omap3beagle");
>
> diff --git a/arch/arm/mach-omap2/board-flash.c
> b/arch/arm/mach-omap2/board-flash.c
> index 0cabe61..488a1fa 100644
> --- a/arch/arm/mach-omap2/board-flash.c
> +++ b/arch/arm/mach-omap2/board-flash.c
> @@ -133,12 +133,12 @@ static struct omap_nand_platform_data board_nand_data =
> {
>
> void
> __init board_nand_init(struct mtd_partition *nand_parts,
> - u8 nr_parts, u8 cs, int nand_type)
> + u8 nr_parts, u8 cs, int bus_type)
> {
> board_nand_data.cs = cs;
> board_nand_data.parts = nand_parts;
> board_nand_data.nr_parts= nr_parts;
> - board_nand_data.devsize = nand_type;
> + board_nand_data.bussize = bus_type;
>
> board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
> gpmc_nand_init(&board_nand_data);
> @@ -185,7 +185,7 @@ unmap:
> * @return - void.
> */
> void __init board_flash_init(struct flash_partitions partition_info[],
> - char chip_sel_board[][GPMC_CS_NUM], int nand_type)
> + char chip_sel_board[][GPMC_CS_NUM], int bus_type)
> {
> u8 cs = 0;
> u8 norcs = GPMC_CS_NUM + 1;
> @@ -238,5 +238,5 @@ void __init board_flash_init(struct flash_partitions
> partition_info[],
> pr_err("NAND: Unable to find configuration in GPMC\n");
> else
> board_nand_init(partition_info[2].parts,
> - partition_info[2].nr_parts, nandcs, nand_type);
> + partition_info[2].nr_parts, nandcs, bus_type);
> }
> diff --git a/arch/arm/mach-omap2/board-igep0020.c
> b/arch/arm/mach-omap2/board-igep0020.c
> index 48d5e41..732f183 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/ar
RE: [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Santosh, Kevin On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: [...] > >> + > >> +/* > >> + * This a subset of registers defined in drivers/memory/emif.h > >> + * Move that to include/linux/? > >> + */ > > > > I'd probably suggest just moving the register definitions you > > need into so they can be shared with the driver. > > > > Also, the EMIF stuff would benefit greatly from using symbolic defines > > for the values being written. Probably having those in > > would also help out here. > > > > Or, maybe the EMIF driver can provide some self-contained stubs that can > > be copied to OCP RAM for the functionality needed here? > > > > Santosh, what do you think of that? > > > Thats what I mentioned in my comment. I also don't know why such a bad > hardware choice was made when we have perfectly working EMIF IP across > low power states. Even the self refresh control is managed inside > hardware upon idle. My guess is DDR self-refresh might be the reason > to use OCMC RAM. > > In either case, Keeping EMIF changes separate as part of EMIF > driver/platform code is right way to go about it. May be the > disable_selfrefresh() might need to kept in assembly files since it > needs to be running from SRAM but rest need not be part of > PM code. > In the suspend path we do lot of I/O manipulations to lower final power number which must be done after the external memory has gone into self-refresh. So, these steps will have to be done from code in OCMC RAM. Other than saving the EMIF configuration the other thing that we do during suspend from assembly is to put the PLLs in bypass. We could possibly move the DISP PLL bypass to C code. MPU PLL is another candidate but this might add in more delays in the suspend and abort sequence (I don't have any delay numbers to justify this right now) The resume path undoes the I/O manipulations and then restores the EMIF configuration all of which I think is necessary before we can jump back to external memory. So, I think we'll have just the EMIF context save and possibly the PLL bypass for DISP PLL during suspend that we can move out of assembly. Coming to point of sharing the EMIF register definitions, with the recent changes to move around the header files out of plat-omap, is it ok to add in the required offsets and related bit-field definitions from the EMIF driver to plat-omap? Regards, 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 v4 0/7] usb: dwc3-omap: add dt support
On Mon, Oct 15, 2012 at 06:57:53PM +0530, Kishon Vijay Abraham I wrote:
> This patch series adds dt support to dwc3 core and fixes few minor
> stuff in dwc3-omap glue to get dwc3 working.
>
> While at that it also uses *of_platform* to create the child device
> (dwc3-core) and fixes to use runtime API's to enable clock and write
> to SYSCONFIG register.
>
> Changes from v3:
> * rebased to latest commit in balbi's tree
> * Fixed few typos in the commit log
> * Added *extern* keyword for dwc3_omap_mailbox function declaration
>
> Changes from v2:
> * Fixed Sergei comment to use of_property_read_u32 insted of of_get_property
>
> Changes from v1:
> * made device_for_each_child() as a seperate patch
> * made all other minor fixes wrt typos and function renames
>
> This patch series is developed on:
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3
please rebase on my dwc3 branch. Because of commit belo, patches 1 and 2
won't apply:
commit 124dafde8f8174caf5cef1c3eaba001657d66f4f
Author: Sebastian Andrzej Siewior
Date: Mon Oct 29 18:09:53 2012 +0100
usb: dwc3: remove custom unique id handling
The lockless implementation of the unique id is quite impressive (:P)
but dirver's core can handle it, we can remove it and make our code a
little smaller.
Cc: Anton Tikhomirov
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..d8d327a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -66,45 +66,6 @@ MODULE_PARM_DESC(maximum_speed, "Maximum supported speed.");
/* --
*/
-#define DWC3_DEVS_POSSIBLE 32
-
-static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
-
-int dwc3_get_device_id(void)
-{
- int id;
-
-again:
- id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
- if (id < DWC3_DEVS_POSSIBLE) {
- int old;
-
- old = test_and_set_bit(id, dwc3_devs);
- if (old)
- goto again;
- } else {
- pr_err("dwc3: no space for new device\n");
- id = -ENOMEM;
- }
-
- return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
- int ret;
-
- if (id < 0)
- return;
-
- ret = test_bit(id, dwc3_devs);
- WARN(!ret, "dwc3: ID %d not in use\n", id);
- smp_mb__before_clear_bit();
- clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
{
u32 reg;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 243affc..4999563 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -868,7 +868,4 @@ void dwc3_host_exit(struct dwc3 *dwc);
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
-extern int dwc3_get_device_id(void);
-extern void dwc3_put_device_id(int id);
-
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..586f105 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -94,7 +94,6 @@ static int __devinit dwc3_exynos_probe(struct platform_device
*pdev)
struct dwc3_exynos *exynos;
struct clk *clk;
- int devid;
int ret = -ENOMEM;
exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
@@ -105,20 +104,16 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, exynos);
- devid = dwc3_get_device_id();
- if (devid < 0)
- goto err1;
-
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(&pdev->dev, "couldn't register PHYs\n");
goto err1;
}
- dwc3 = platform_device_alloc("dwc3", devid);
+ dwc3 = platform_device_alloc("dwc3", PLATFORM_DEVID_AUTO);
if (!dwc3) {
dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
- goto err2;
+ goto err1;
}
clk = clk_get(&pdev->dev, "usbdrd30");
@@ -170,8 +165,6 @@ err4:
clk_put(clk);
err3:
platform_device_put(dwc3);
-err2:
- dwc3_put_device_id(devid);
err1:
kfree(exynos);
err0:
@@ -187,8 +180,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
- dwc3_put_device_id(exynos->dwc3->id);
-
if (pdata && pdata->phy_exit)
pdata->phy_exit(pdev, pdata->phy_type);
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index ee57a10..900d435 100644
--- a/drivers/
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi, On Thu, Oct 25, 2012 at 08:24:09PM +0530, kishon wrote: > Hi Benoit, > > On Thursday 25 October 2012 07:11 PM, Benoit Cousson wrote: > >Hi Kishon, > > > >On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote: > >>Includes few minor fixes in dwc3-omap like populating the compatible > >>string in a correct way, extracting the utmi-mode property properly and > >>changing the index of get_irq since irq of core is removed from hwmod > >>entry. > >>Also updated the documentation with dwc3-omap device tree binding > >>information. > >> > >>Signed-off-by: Kishon Vijay Abraham I > >>--- > >> drivers/usb/dwc3/dwc3-omap.c | 14 ++ > >> 1 file changed, 6 insertions(+), 8 deletions(-) > >> > >>diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c > >>index b84ddf3..10aad46 100644 > >>--- a/drivers/usb/dwc3/dwc3-omap.c > >>+++ b/drivers/usb/dwc3/dwc3-omap.c > >>@@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct > >>platform_device *pdev) > >>struct resource *res; > >>struct device *dev = &pdev->dev; > >> > >>- int size; > >>int ret = -ENOMEM; > >>int irq; > >> > >>- const u32 *utmi_mode; > >>+ u32 utmi_mode; > >>u32 reg; > >> > >>void __iomem*base; > >>@@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct > >>platform_device *pdev) > >> > >>platform_set_drvdata(pdev, omap); > >> > >>- irq = platform_get_irq(pdev, 1); > >>+ irq = platform_get_irq(pdev, 0); > > > >Cannot you use the name of the resource to avoid that kind of trick? > > *name* is mostly used when we have multiple resource of the same type > for a single device. Previously we were clubbing wrapper resources > and core resources in a single hwmod device, so we had to use > different indexing. > But with dt we have separated those under two different devices and > hence we can always use index as '0'. But if you think we should have > *name*, let me know, I can resend this patch :-) since there were no more replies here, i'm assuming Benoit's happy with Kishon's explanation. Will apply this series as is. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: > From: Michal Nazarewicz > > The File-backed Storage Gadget (g_file_storage) is being removed, since > it has been replaced by Mass Storage Gadget (g_mass_storage). This commit > changes defconfigs point to the new gadget. > > Signed-off-by: Michal Nazarewicz I need more Acks here. Only got one from Nicolas. Anyone else ? > --- > arch/arm/configs/afeb9260_defconfig|2 +- > arch/arm/configs/at91sam9260_defconfig |2 +- > arch/arm/configs/at91sam9261_defconfig |2 +- > arch/arm/configs/at91sam9263_defconfig |2 +- > arch/arm/configs/at91sam9g20_defconfig |2 +- > arch/arm/configs/corgi_defconfig |2 +- > arch/arm/configs/davinci_all_defconfig |2 +- > arch/arm/configs/h7202_defconfig |3 +-- > arch/arm/configs/magician_defconfig|2 +- > arch/arm/configs/mini2440_defconfig|2 +- > arch/arm/configs/omap1_defconfig |3 +-- > arch/arm/configs/prima2_defconfig |1 - > arch/arm/configs/spitz_defconfig |2 +- > arch/arm/configs/stamp9g20_defconfig |2 +- > arch/arm/configs/viper_defconfig |2 +- > arch/arm/configs/zeus_defconfig|2 +- > arch/avr32/configs/atngw100_defconfig |2 +- > arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- > arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- > arch/avr32/configs/atngw100_mrmt_defconfig |2 +- > arch/avr32/configs/atngw100mkii_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- > .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- > arch/avr32/configs/atstk1002_defconfig |2 +- > arch/avr32/configs/atstk1003_defconfig |2 +- > arch/avr32/configs/atstk1004_defconfig |2 +- > arch/avr32/configs/atstk1006_defconfig |2 +- > arch/avr32/configs/favr-32_defconfig |2 +- > arch/avr32/configs/hammerhead_defconfig|2 +- > arch/blackfin/configs/CM-BF527_defconfig |2 +- > arch/blackfin/configs/CM-BF548_defconfig |2 +- > arch/blackfin/configs/CM-BF561_defconfig |2 +- > arch/mips/configs/bcm47xx_defconfig|2 +- > arch/mips/configs/mtx1_defconfig |2 +- > arch/sh/configs/ecovec24_defconfig |2 +- > arch/sh/configs/se7724_defconfig |2 +- > 37 files changed, 35 insertions(+), 39 deletions(-) > > diff --git a/arch/arm/configs/afeb9260_defconfig > b/arch/arm/configs/afeb9260_defconfig > index c285a9d..a8dbc1e 100644 > --- a/arch/arm/configs/afeb9260_defconfig > +++ b/arch/arm/configs/afeb9260_defconfig > @@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_RTC_CLASS=y > CONFIG_RTC_DEBUG=y > diff --git a/arch/arm/configs/at91sam9260_defconfig > b/arch/arm/configs/at91sam9260_defconfig > index 505b376..0ea5d2c 100644 > --- a/arch/arm/configs/at91sam9260_defconfig > +++ b/arch/arm/configs/at91sam9260_defconfig > @@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_RTC_CLASS=y > CONFIG_RTC_DRV_AT91SAM9=y > diff --git a/arch/arm/configs/at91sam9261_defconfig > b/arch/arm/configs/at91sam9261_defconfig > index 1e8712e..c87beb9 100644 > --- a/arch/arm/configs/at91sam9261_defconfig > +++ b/arch/arm/configs/at91sam9261_defconfig > @@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_MMC=y > CONFIG_MMC_ATMELMCI=m > diff --git a/arch/arm/configs/at91sam9263_defconfig > b/arch/arm/configs/at91sam9263_defconfig > index d2050ca..c5212f4 100644 > --- a/arch/arm/configs/at91sam9263_defconfig > +++ b/arch/arm/configs/at91sam9263_defconfig > @@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_ETH=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m > CONFIG_USB_G_SERIAL=m > CONFIG_MMC=y > CONFIG_SDIO_UART=m > diff --git a/arch/arm/configs/at91sam9g20_defconfig > b/arch/arm/configs/at91sam9g20_defconfig > index e1b0e80..3b18810 100644 > --- a/arch/arm/configs/at91sam9g20_defconfig > +++ b/arch/arm/configs/at91sam9g20_defconfig > @@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_GADGET=y > CONFIG_USB_ZERO=m > CONFIG_USB_GADGETFS=m > -CONFIG_USB_FILE_STORAGE=m > +CONFIG_USB_MASS_STORAGE=m >
Re: [PATCH v3 0/7] Create platform device for audio support
On 2012-11-06 08:19, Ricardo Neri wrote: > Hi Tomi, l-o list, > > The main purpose of this patch set is to create a platform device for audio > support from the OMAPDSS HDMI driver. This tries to follow an approach similar > to MFD drivers in which a core driver creates domain-specific devices. Under > this approach, the OMAPDSS HDMI drivers acts as the core driver, retrieves its > resources (from DT or hwmod) and passes the relevant audio resources for > other drivers to use. > > This is also beneficial for future DT boot support, as the OMAP HDMI IP will > be > represented by a single node in the tree. > > Before creating the platform device for audio, I also did minor cleanup to the > OMAPDSS HDMI driver probe function. > > Changes from v2: > *Check the validity of the audio platform device by checking a non-NULL > condition > rather than an error pointer condition. > *Pass the ID of the HDMI platform device to handle more than one instance of > HDMI audio platform devices. This is for future implementations that support > more than one HDMI output. > > Changes from v1: > *Simplify ioremap further by using devm_request_and_ioremap. > *Pass to the audio driver only the DMA port and not the whole register space. > *Use a local array for the audio resources and init them with DEFINE_RES_MEM. > *Obtain the DMA port address offset and size from the HDMI IP-specific > library. > > v2 is accessible here: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79529.html > > v1 is accessible here: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg77861.html Looks good to me, I'll apply to omapdss tree. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On 11/6/2012 3:39 PM, Bedia, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = &am33xx_cpgmac0_hwmod,
+ .slave = &am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
Will remove the unnecessary flags and submit the patch.
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: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou wrote: > On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: >> Sure, so if we add data type supplementary properties to the tree to >> indicate the data type as "indirect phandle", then kernel could refer >> to the index in the got-like table to fetch the actual phandle address >> (1-level of indirection), instead of directly using the address in the >> data field. >> > > I'm fine with this. But if the data about phandles is already in the tree, then the need for a GOT simply goes away. The phandles can be fixed up directly and it is so much better because it works with existing parsing code after the merge is applied. 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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou wrote: > Hi Grant, > > On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: > >> Hey folks, >> >> As promised, here is my early draft to try and capture what device >> tree overlays need to do and how to get there. Comments and >> suggestions greatly appreciated. >> >> Device Tree Overlay Feature >> >> Purpose >> === >> Sometimes it is not convenient to describe an entire system with a >> single FDT. For example, processor modules that are plugged into one or >> more modules (a la the BeagleBone), or systems with an FPGA peripheral >> that is programmed after the system is booted. >> >> For these cases it is proposed to implement an overlay feature for the >> so that the initial device tree data can be modified by userspace at >> runtime by loading additional overlay FDTs that amend the original data. >> >> User Stories >> >> Note - These are potential use cases, but just because it is listed here >> doesn't mean it is important. I just want to thoroughly think through the >> implications before making design decisions. >> >> >> Jane is building custom BeagleBone expansion boards called 'capes'. She >> can boot the system with a stock BeagleBoard device tree, but additional >> data is needed before a cape can be used. She could replace the FDT file >> used by U-Boot with one that contains the extra data, but she uses the >> same Linux system image regardless of the cape, and it is inconvenient >> to have to select a different device tree at boot time depending on the >> cape. >> >> Jane solves this problem by storing an FDT overlay for each cape in the >> root filesystem. When the kernel detects that a cape is installed it >> reads the cape's eeprom to identify it and uses request_firmware() to >> obtain the appropriate overlay. Userspace passes the overlay to the >> kernel in the normal way. If the cape doesn't have an eeprom, then the >> kernel will still use firmware_request(), but userspace needs to already >> know which cape is installed. > > Jane is a really productive hardware engineer - she manages to fix a > number of problems with her cape design by spinning different revisions > of the cape. Using the flexibility that the DT provides, documents and > defines the hardware changes of the cape revisions in the FDT overlay. > The loader matches the revision of the cape with the proper FDT overlay > so that the drivers are relieved of having to do revision management. Okay >> By installing dtc on the Pi, Mandy compiles the overlay for her >> prototype hardware. However, she doesn't have a copy of the Pi's >> original FDT source, so instead she uses the dtc 'fs' input format to >> compile the overlay file against the live DT data in /proc. > > Jane (the cape designer) can use this too. Developing the cape, she really > appreciates that she doesn't have to reboot every time she makes a change > in the cape hardware. By removing the FDT overlay, compiling with the dtc > on the board, and re-inserting the overlay, she can be more productive by > waiting less. Yes, but I'll leave this paragraph out of the spec. It isn't significantly different from what is already there. > Johnny, Jane's little son, doesn't know anything about device trees, linux > kernel trees, or hard-core s/w engineering. He is a bright kid, and due to > the board having a node.js based educational electronic design kit, he > can use the web-based simplified development environment, that allows > him graphically to connect the parts in his kit. He can save the design > and the IDE creates on the fly the DT overlay for later use. Yes. >> Joanne has purchased one of Jane's capes and packaged it into a rugged >> case for data logging. As far as Joanne is concerned, the BeagleBone and >> cape together are a single unit and she'd prefer a single monolithic FDT >> instead of using an FDT overlay. >> Option A: Using dtc, she uses the BeagleBone and cape .dts source files >> to generate a single .dtb for the entire system which is >> loaded by U-Boot. -or- > Unlikely. >> Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files >> (instead of .dts files), -or- > Possible but low probability. >> Option C: U-Boot loads both the base and overlay FDT files, merges them, >> and passes the resolved tree to the kernel. > Could be made to work. Only really required if Joanne wants the > cape interface to work for u-boot too. For example if the cape has some > kind of network interface that u-boot will use to boot from. Unlikely for your focus perhaps, but I'm trying to capture all the relevant permutations, and I can guarantee that some people really will want this. If not on the bone, then on some other platform. >> Summary points: >> - Create an FDT overlay data format and usage model >> - SHALL reliable resolve or validate of phandles between base and >>overlay trees >> - SHOULD reliably handle changes between different u
[PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
This allow to clean the omap nand driver that were trying in x8 and x16 bits
mode.
This also make work onfi detection on beagleboard :
Before :
[1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND
256MiB 1,8V 16-bit), page size: 2048, OOB size: 64
After :
[1.914825] ONFI param page 0 valid
[1.919158] ONFI flash detected
[1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
MT29F2G16ABD), page size: 2048, OOB size: 64
platform data devsize is renamed bussize. It now indicate the maximun size of
the nand bus.
Signed-off-by: Matthieu CASTET
---
arch/arm/mach-omap2/board-3630sdp.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-flash.c|8 ++---
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-zoom.c |2 +-
arch/arm/mach-omap2/common-board-devices.c |2 +-
arch/arm/mach-omap2/gpmc-nand.c |5 ---
drivers/mtd/nand/omap2.c | 42 ++
include/linux/platform_data/mtd-nand-omap2.h |7 -
13 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index fc224ad..d7b981b 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -198,7 +198,7 @@ static void __init omap_sdp_init(void)
h8mbx00u0mer0em_sdrc_params);
zoom_display_init();
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
+ board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_OMAP_BUS_16);
enable_board_wakeup_source();
usbhs_init(&usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..b3487e1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -621,7 +621,7 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
+ omap_nand_flash_init(NAND_OMAP_BUS_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
omap_twl4030_audio_init("omap3beagle");
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..488a1fa 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,12 +133,12 @@ static struct omap_nand_platform_data board_nand_data = {
void
__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+ u8 nr_parts, u8 cs, int bus_type)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.devsize = nand_type;
+ board_nand_data.bussize = bus_type;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(&board_nand_data);
@@ -185,7 +185,7 @@ unmap:
* @return - void.
*/
void __init board_flash_init(struct flash_partitions partition_info[],
- char chip_sel_board[][GPMC_CS_NUM], int nand_type)
+ char chip_sel_board[][GPMC_CS_NUM], int bus_type)
{
u8 cs = 0;
u8 norcs = GPMC_CS_NUM + 1;
@@ -238,5 +238,5 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err("NAND: Unable to find configuration in GPMC\n");
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs, bus_type);
}
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 48d5e41..732f183 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -175,7 +175,7 @@ static void __init igep_flash_init(void)
pr_info("IGEP: initializing NAND memory device\n");
board_nand_init(igep_flash_partitions,
ARRAY_SIZE(igep_flash_partitions),
- 0, NAND_BUSWIDTH_16);
+ 0, NAND_OMAP_BUS_16);
} else if (mux == IGEP_SYSBOOT_ONENAND) {
pr_info("IGEP: initializing OneNAND memory device\n");
board_onenand_init(igep_flash_partitions,
diff --git a/arch/arm/mach-omap2/board-om
[PATCH 2/3] mtd nand : add NAND_BUSWIDTH_AUTO to autodetect bus width
The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.
This work because readid and onfi are read work 8 byte mode.
Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID,
NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of
address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.
[1]
3.3.2. Target Initialization
[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus.
The host shall not issue commands that use a word data width on x16 devices
until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: Matthieu CASTET
---
drivers/mtd/nand/nand_base.c | 14 +-
include/linux/mtd/nand.h |7 +++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index abeb8e9..c90ef66 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3245,11 +3245,15 @@ ident_done:
break;
}
- /*
-* Check, if buswidth is correct. Hardware drivers should set
-* chip correct!
-*/
- if (busw != (chip->options & NAND_BUSWIDTH_16)) {
+ if (chip->options & NAND_BUSWIDTH_AUTO) {
+ WARN_ON(chip->options & NAND_BUSWIDTH_16);
+ chip->options |= busw;
+ nand_set_defaults(chip, busw);
+ } else if (busw != (chip->options & NAND_BUSWIDTH_16)) {
+ /*
+* Check, if buswidth is correct. Hardware drivers should set
+* chip correct!
+*/
pr_info("NAND device: Manufacturer ID:"
" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id,
*dev_id, nand_manuf_ids[maf_idx].name, mtd->name);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 24e9159..c8518d4 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -219,6 +219,13 @@ typedef enum {
#define NAND_OWN_BUFFERS 0x0002
/* Chip may not exist, so silence any errors in scan */
#define NAND_SCAN_SILENT_NODEV 0x0004
+/*
+ * Autodetect nand buswidth with readid/onfi.
+ * This suppose the driver will configure the hardware in 8 bits mode
+ * when calling nand_scan_ident, and update its configuration
+ * before calling nand_scan_tail.
+ */
+#define NAND_BUSWIDTH_AUTO 0x0008
/* Options set by nand scan */
/* Nand scan has allocated controller struct */
--
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
[PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
- NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20) - NAND_CMD_PARAM want 8 bits data Signed-off-by: Matthieu CASTET --- drivers/mtd/nand/nand_base.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 5894c2c..abeb8e9 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2851,6 +2851,8 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip, int i; int val; + /* ONFI need to be probed in 8 bits mode */ + WARN_ON(chip->options & NAND_BUSWIDTH_16); /* Try ONFI for unknown chip or LP */ chip->cmdfunc(mtd, NAND_CMD_READID, 0x20, -1); if (chip->read_byte(mtd) != 'O' || chip->read_byte(mtd) != 'N' || -- 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 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
On Tue, Nov 06, 2012 at 01:42:18PM +0530, Mugunthan V N wrote: > This patch-series adds support for, > > [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's > > [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw >driver, as in case of AM33XX, the resources are shared and common >register bit-field is provided to control module/clock enable/disable, >makes it difficult to handle common resource. > >So the solution here is, to create parent<->child relation between > them. > > [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. > > [4/7]: cpsw: simplify the setup of the register pointers > > [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, >am335x-evm.dts and am335x-bone.dts file > > [6/7]: Enable CPSW support to omap2plus_defconfig > > [7/7]: cpsw: Kernel warn fix during suspend Acked-by: Richard Cochran -- 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Kevin,
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
>
> First, some general comments. This is a big patch and probably should
> be broken up a bit. I suspect it could be broken up a bit, maybe into
> at least:
>
> - EMIF interface
> - SCM interface, new APIs
> - assembly/OCM code
> - pm33xx.[ch]
> - lastly, the late_init stuff that actually initizlizes
Ok, I'll try splitting the patches in the next version.
>
> I have a handful of comments below. I wrote this up on the plane over
> the weekend, and I see that Santosh has already made some similar
> comments, but I'll send mine anyways.
[...]
>
> Doing this on every suspend looks a bit strange. Why not just have some
> init function handle these devices once at boot. If this is really
> needed on every suspend, it needs some more description, and probably
> some basic stub drivers need to be created.
We do require it for every suspend (but more below). I'll add in more
description in the comment that's already there.
>
> Also, if there are drivers for these devices, won't this interfere?
>
Hmm, I can think of the following scenarios
1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
in their suspend callbacks they end up doing omap_hwmod_idle() via the
runtime PM APIs. In this case the omap_hwmod_enable() followed by
omap_hwmod_idle() is not necessary in the PM code.
2. The drivers are not compiled in - In this case, the hwmod code puts
the IPs in standby during bootup so the first suspend-resume iteration
will pass. During resuming, the SYSC configuration for forced standby will
be lost, so in the subsequent iterations these IPs won't go standby and the
hwmod code does not touch them since they never got enabled. In this case
we do need the sequence that is there currently.
3. For some reason the respective drivers don't idle the IPs during suspend -
(no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
we should abort the suspend process since we know that the suspend is not
going to work.
Is there some other scenario that needs to be covered?
How about adding some flag in hwmod code for handling this? Something
similar to what was done for MMC [1]. I think the problem that we have
is in some ways similar to the one addressed in [1].
> > + /* Put the GFX clockdomains to sleep */
> > + clkdm_sleep(gfx_l3_clkdm);
> > + clkdm_sleep(gfx_l4ls_clkdm);
> > +
> > + /* Try to put GFX to sleep */
> > + pwrdm_set_next_pwrst(gfx_pwrdm, PWRDM_POWER_OFF);
>
> ditto.
I'll check if this can be removed.
>
> [...]
>
> > +static int am33xx_pm_begin(suspend_state_t state)
> > +{
> > + int ret = 0;
> > +
> > + disable_hlt();
> > +
> > + /*
> > +* Physical resume address to be used by ROM code
> > +*/
> > + wkup_m3->resume_addr = (AM33XX_OCMC_END - am33xx_do_wfi_sz +
> > + am33xx_resume_offset + 0x4);
>
> Why does this need to be calculated every suspend/resume?
>
Will move this to init phase.
> > + wkup_m3->sleep_mode = IPC_CMD_DS0;
> > + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> > + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> > +
> > + am33xx_ipc_cmd();
>
> This IPC needs a cleaner interface/API. Also, since it involves
> register writes to the SCM, it should be defined in control.c. (NOTE:
> we're in the process of creating a real driver out of the SCM, so all
> SCM register accesses need to be contained in control.c)
>
> For example, you probably want an am33xx_m3_* API in control.c, with
> some pre-baked commands for the M3.
Ok. I'll work on this for the next version.
>
> > + wkup_m3->state = M3_STATE_MSG_FOR_LP;
> >
> > + omap_mbox_enable_irq(wkup_m3->mbox, IRQ_RX);
> > +
> > + ret = omap_mbox_msg_send(wkup_m3->mbox, 0xABCDABCD);
> > + if (ret) {
> > + pr_err("A8<->CM3 MSG for LP failed\n");
> > + am33xx_m3_state_machine_reset();
> > + ret = -1;
> > + }
> > +
> > + if (!wait_for_completion_timeout(&wkup_m3_sync,
> > + msecs_to_jiffies(500))) {
>
> hmm, interesting. I know you're not implementing idle here, but I'm
> rather curious how this sync w/M3 is going to work for idle.
>
Like you mentioned in another thread we could probably not have
a sync in the idle path. (More in the other thread).
> > + pr_err("A8<->CM3 sync failure\n");
> > + am33xx_m3_state_machine_reset();
> > + ret = -1;
> > + } else {
> > + pr_debug("Message sent for entering DeepSleep mode\n");
> > + omap_mbox_disable_irq(wkup_m3->mbox, IRQ_RX);
> > + }
> > +
> > + return ret;
> > +}
> > +
>
> [...]
>
> > +static void am33xx_m3_state_machine_reset(void)
> > +{
> > + int ret = 0;
> > +
> > + wkup_m3->resume_addr= 0x0;
> > + wkup_m3->sleep_mode = IPC_CMD_RESET;
> > + wkup_m3->ipc_data1 = DS_IPC_DEFAULT;
> > + wkup_m3->ipc_data2 = DS_IPC_DEFAULT;
> > +
> > + am33xx_ipc_cm
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: > On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely > wrote: > >> Jane is building custom BeagleBone expansion boards called 'capes'. She >> can boot the system with a stock BeagleBoard device tree, but additional >> data is needed before a cape can be used. She could replace the FDT file >> used by U-Boot with one that contains the extra data, but she uses the >> same Linux system image regardless of the cape, and it is inconvenient >> to have to select a different device tree at boot time depending on the >> cape. > > What's wrong with having the boot loader detect the presence of the > Cape and update the device tree accordingly? We do this all the time > in U-Boot. Doing stuff like reading EEPROMs and testing for the > presence of hardware is easier in U-Boot than in Linux. > > For configurations that can be determined by the boot loader, I'm not > sure overlays are practical. > Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. >> Nigel is building a real-time video processing system around a MIPS SoC >> and a Virtex FPGA. Video data is streamed through the FPGA for post >> processing operations like motion tracking or compression. The FPGA is >> configured via the SPI bus, and is also connected to GPIO lines and the >> memory mapped peripheral bus. Nigel has designed several FPGA >> configurations for different video processing tasks. The user will >> choose which configuration to load which can even be reprogrammed at >> runtime to switch tasks. > > Now this, on the other hand, makes more sense. If the hardware > configuration is literally user-configurable, then okay. However, I'm > not sure I see the need to update the device tree. The device tree is > generally for hardware that cannot be discovered/probed by the device > driver. If we're loading a configuration from user space, doesn't the > driver already know what the hardware's capabilities are, since it's > the one doing the uploading of a new FPGA code? Why not skip the > device tree update and just tell the driver what the new capabilities > are? > > -- > Timur Tabi > Linux kernel developer at Freescale Regards -- Pantelis -- 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] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: > Hey folks, > > As promised, here is my early draft to try and capture what device > tree overlays need to do and how to get there. Comments and > suggestions greatly appreciated. > > Device Tree Overlay Feature > > Purpose > === > Sometimes it is not convenient to describe an entire system with a > single FDT. For example, processor modules that are plugged into one or > more modules (a la the BeagleBone), or systems with an FPGA peripheral > that is programmed after the system is booted. > > For these cases it is proposed to implement an overlay feature for the > so that the initial device tree data can be modified by userspace at > runtime by loading additional overlay FDTs that amend the original data. > > User Stories > > Note - These are potential use cases, but just because it is listed here > doesn't mean it is important. I just want to thoroughly think through the > implications before making design decisions. > > > Jane is building custom BeagleBone expansion boards called 'capes'. She > can boot the system with a stock BeagleBoard device tree, but additional > data is needed before a cape can be used. She could replace the FDT file > used by U-Boot with one that contains the extra data, but she uses the > same Linux system image regardless of the cape, and it is inconvenient > to have to select a different device tree at boot time depending on the > cape. > > Jane solves this problem by storing an FDT overlay for each cape in the > root filesystem. When the kernel detects that a cape is installed it > reads the cape's eeprom to identify it and uses request_firmware() to > obtain the appropriate overlay. Userspace passes the overlay to the > kernel in the normal way. If the cape doesn't have an eeprom, then the > kernel will still use firmware_request(), but userspace needs to already > know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. > > > Nigel is building a real-time video processing system around a MIPS SoC > and a Virtex FPGA. Video data is streamed through the FPGA for post > processing operations like motion tracking or compression. The FPGA is > configured via the SPI bus, and is also connected to GPIO lines and the > memory mapped peripheral bus. Nigel has designed several FPGA > configurations for different video processing tasks. The user will > choose which configuration to load which can even be reprogrammed at > runtime to switch tasks. > > Each FPGA has a different interface to the processor, so the kernel > needs additional data before it can use each device. Nigel is passing > that data to the kernel using an FDT overlay. When Linux loads a new > FPGA configuration, it uses request_firmare() to obtain the overlay for > that FPGA. When the FPGA gets reprogrammed, the kernel throws away the > previous overlay data and uses request_firmware() to get the overlay for > the new design. > > > Mandy has a Raspberry Pi which she has wired by hand up to sensors and > motor controllers in her prototype autonomous robot project. She is doing > self-hosted driver development on the Raspberry Pi itself. However, she > needs a method to tell the kernel about the attached devices. > > By installing dtc on the Pi, Mandy compiles the overlay for her > prototype hardware. However, she doesn't have a copy of the Pi's > original FDT source, so instead she uses the dtc 'fs' input format to > compile the overlay file against the live DT data in /proc. > > Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. > Amit is writing kernel drivers for Jane's BeagleBone capes, but he > finds loading new DT files into the root filesystem inconvenient. > Instead, he includes the FDT overlay file in the initramfs that is built > and linked in at kernel compile time so that the kernel can find and > load overlays automatically. > > > Joanne has pur
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 11:39:18, Hiremath, Vaibhav wrote: > On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: > > Hi > > > > On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: > > > > > This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform > > > and its booting up for me without any issues. > > > Jon had submitted another patch which fixes boot issue on Bone. > > > > > > https://patchwork.kernel.org/patch/1606471/ > > > > v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it > > is due to the original u-boot that was shipped with the MMC card: > > > > Pulling the tree, let me try now and update you shortly... > Just tried -rc4, and it boots up fine for me. I tested it with Mainline u- boot and mainline Kernel, I have pasted log below for reference - > > U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) > > arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) > > I do not suspect anything here, but still think we should use mainline u-boot version. Can you share the images with me, so that I can try them? Log=== U-Boot SPL 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3842256 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3842192 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc4 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 IST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b94 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:52 PM, Mark Brown wrote: > On Tue, Nov 06, 2012 at 02:47:27PM +0530, Shubhrajyoti D wrote: >> The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] >> changed the wait_for_completion order. Move the wait so that the >> rx doesnot wait for the tx to complete. > > Is this a resend of the patch I just applied, or is it something > different? No please ignore this one. Something wrong at my end it got sent twice. Please ignore. -- 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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] > > > > Ok I checked this one. The change I made was indirectly fixing another > > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > > entries and the SYSC register is part of the second entry. The function > > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > > SYSC address of CPGMAC0 and the IP went to standby during bootup. > > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > > things work fine. > > > > Good catch. > > Just a side note on this, driver expects the addresses in this order > only, first SS and then WR. > Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Are you saying that I should not be doing this because the driver will get affected? Regards, 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 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
> +
> +static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
> + .master = &am33xx_epwmss0_hwmod,
> + .slave = &am33xx_ecap0_hwmod,
> + .clk= "l4ls_gclk",
> + .addr = am33xx_ecap0_addr_space,
> + .user = OCP_USER_MPU,
> +};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
Regards,
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 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> + {
> + .pa_start = 0x4A101000,
> + .pa_end = 0x4A101000 + SZ_256 - 1,
> + .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
> + },
> + { }
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> + .master = &am33xx_cpgmac0_hwmod,
> + .slave = &am33xx_mdio_hwmod,
> + .addr = am33xx_mdio_addr_space,
> + .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
Regards,
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 baseline test results for v3.7-rc1
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman wrote: > Jean Pihet writes: > > [...] > >> I ran some intensive stress tests on the I2C and ... unfortunately I >> could not trigger the problem. It looks like the issue is caused by >> some transient situation where the CORE and/or I2C is in a low power >> state. > > FYI... I just ran across what appears to be the same bug on 3430/n900 > during suspend/resume testing. With CPUidle enabled, this happens every > time. > > Reverting the I2C QoS patch makes it work again. I think we should defer the release of the constraints Does this help http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79841.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
[PATCH] i2c: omap: Move the remove constraint
Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D --- drivers/i2c/busses/i2c-omap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 94ff685..8b079d7 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -655,13 +655,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev->latency) - pm_qos_remove_request(&dev->pm_qos_request); - if (r == 0) r = num; omap_i2c_wait_for_bb(dev); + + if (dev->latency) + pm_qos_remove_request(&dev->pm_qos_request); out: pm_runtime_mark_last_busy(dev->dev); pm_runtime_put_autosuspend(dev->dev); -- 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
Re: OMAP baseline test results for v3.7-rc3
On 06/11/12 06:16, Hiremath, Vaibhav wrote: > > Where is your DTB? Is it appended to Kernel image? > Can you try below sequence/commands from u-boot? > > > mmc rescan 0 > fatload mmc 0 8000 am335x-bone.dtb > fatload mmc 0 8100 uImage > setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw > noinitrd rootfstype=ext3 rootwait earlyprink=serial > sendln 'bootm 8100 - 8000' > > > > To build DTB files, use "make dtbs" command on your kernel home directory. That works ... great !! But now I'm confused, since I thought the DTB was appended to the uImage file. I have the following in my .config:- ARM_ATAG_DTB_COMPAT=y ARM_APPENDED_DTB=y ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And then I create my uImage file using:- $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb > arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage Do you now have to load the DTB as a separate file ? Or should the appended DTB still work ? Cheers Mark J. -- 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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
Hi Jon, On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote: [...] > > Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx? > Is it using smart-idle? > Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup since this timer is not wakeup capable) but unfortunately this is not sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in PER domain are disabled by s/w, PER domain can't transition. > > The next one is that > > the clockevent doesn't generate any further interrupts once the > > system resumes. We need to restore the pre-suspend configuration. > > I haven't tried but I guess we could have used the save and restore > > of timer registers here. > > It would be interesting to try using an non-wakeup domain timer on > OMAP3/4 for clock events and seeing if suspend/resume works. > > Do you know what the exact problem here is? I understand that the timer > context could get lost, but exactly what is not getting restarted by the > kernel? For example, the only place we set the interrupt enable is > during the clock event init and so if the context is lost, then I could > see no more interrupts occurring. So is it enough to just restore the > interrupt enable register, do you really need to program the timer again? > Just restoring the interrupt enable register works. But since there's no logic retention I think a context save-restore would be better. Regards, 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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On 11/5/2012 2:40 PM, Bedia, Vaibhav wrote: > On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote: >> On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote: >>> On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT instead of ADDR_TYPE_RT to ensure the omap hwmod code maps the memory space at init and writes to the SYSCONFIG registers. Signed-off-by: Vaibhav Bedia --- >>> Sorry again similar question. >>> >>> Why CPGMAC0 should be mapped and sysconfig updated early ? >>> >> >> Hmm I need to revisit this one. CPGMAC0 was not going to standby >> without this. Maybe something else is wrong in the hwmod data and >> needs fixing. >> > > Ok I checked this one. The change I made was indirectly fixing another > issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two > entries and the SYSC register is part of the second entry. The function > _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with > the flag ADDR_TYPE_RT flag. The change I made indirectly made the second > entry in am33xx_cpgmac0_addr_space[] become the first memory space with > the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct > SYSC address of CPGMAC0 and the IP went to standby during bootup. > After changing the order of the entries in am33xx_cpgmac0_addr_space[] > things work fine. > Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Thanks, Vaibhav > I'll make the changes in the next version. > > Regards, > 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 > -- 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 baseline test results for v3.7-rc1
Hi Kevin, Paul, On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman wrote: > Jean Pihet writes: > > [...] > >> I ran some intensive stress tests on the I2C and ... unfortunately I >> could not trigger the problem. It looks like the issue is caused by >> some transient situation where the CORE and/or I2C is in a low power >> state. > > FYI... I just ran across what appears to be the same bug on 3430/n900 > during suspend/resume testing. With CPUidle enabled, this happens every > time. > > Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. The cause of the problem is that the cpuidle influences the MPU and CORE states, depending on the constraints set and the latency figures for the power domains (in arch/arm/mach-omap2/cpuidle34xx.c). Since the latency numbers have not been updated to measured (i.e. realistic) values in too-low power state is used, hence the timeout problem. Note: that does not explain why the I2C timeout issue is present without CPU_IDLE enabled, since in that case PM QoS should not have any effect on the power domains states. So yes the PM QoS I2C patch shall be reverted as long as the PM QoS support for OMAP is not merged in. For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. What to do now with those patches? As said above [3] and [4] must be held until [1] and [2] are merged in. [1] http://marc.info/?l=linux-arm-kernel&m=134744383120921&w=2 [2] http://marc.info/?l=linux-omap&m=134795835604288&w=2 [3] http://marc.info/?l=linux-omap&m=134815730108344&w=2 [4] http://marc.info/?l=linux-omap&m=134795836904299&w=2 > Kevin Thanks for testing and reporting the issue. Jean > > > # rtcwake -m mem -s 1 > Date:Fri Dec 31 17:00:34 MST 1999 > hwclock: Sat Jan 1 00:00:34 2000 0.00 seconds > [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready > wakeup from "mem" at Sat Jan 1 00:00:36 2000 > [ 38.841949] PM: Syncing filesystems ... done. > [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. > [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) > done. > [ 38.916412] Suspending console(s) (use no_console_suspend to debug) > [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready > [ 39.944305] twl: i2c_read failed to transfer all messages > [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 > [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error > -110 > [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready > [ 40.97] twl: i2c_read failed to transfer all messages > [ 40.97] VMMC2_IO_18: failed to disable > [ 40.978698] PM: suspend of devices complete after 2049.163 msecs > [ 40.984222] PM: late suspend of devices complete after 5.493 msecs > [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs > [ 40.992187] Disabling non-boot CPUs ... > [ 40.992675] Successfully put all powerdomains to target state > [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs > [ 41.002014] PM: early resume of devices complete after 3.601 msecs > [ 41.179016] PM: resume of devices complete after 176.818 msecs > [ 41.277740] Restarting tasks ... done. > real0m 3.50s > user0m 0.00s > sys 0m 0.10s > Date:Fri Dec 31 17:00:40 MST 1999 > hwclock: Sat Jan 1 00:00:40 2000 0.00 seconds -- 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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 06, 2012 at 02:47:27PM +0530, Shubhrajyoti D wrote: > The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] > changed the wait_for_completion order. Move the wait so that the > rx doesnot wait for the tx to complete. Is this a resend of the patch I just applied, or is it something different? signature.asc Description: Digital signature
Re: [PATCHv9 0/8] ARM: OMAP4: core retention support
Hi Kevin,
On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> Hi Tero,
>
> Tero Kristo writes:
>
> > Hi,
> >
> > Changes compared to previous version:
> > - rebased on top of 3.7-rc1
> > - applies on top of latest func pwrst code (v6)
> > - added back patch #1 to this set (it wasn't queued yet after all)
> > - added patch #7 for fixing a bug in the functional pwrst code
> > - added patch #8 for fixing a regression with MUSB PHY power handling
> > (not quite sure if this is the correct way to fix this or not)
> >
> > Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
> > suspend.
> >
> > Branch also available here:
> > git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> > branch: mainline-3.7-rc1-omap4-ret-v9
>
> I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
> several domains not hitting target power state in suspend[1].
>
> Am I missing some other fixes? Using omap2plus_defconfig, I tried your
> branch alone, and merged with v3.7-rc4, and I get the same errors.
>
> Kevin
>
> [1]
> # echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
> # echo mem > /sys/power/state
> [ 102.271087] PM: Syncing filesystems ... done.
> [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done.
> [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
> done.
> [ 102.343353] Suspending console(s) (use no_console_suspend to debug)
> �[ 102.363433] PM: suspend of devices complete after 10.650 msecs
> [ 102.365631] PM: late suspend of devices complete after 2.166 msecs
> [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs
> [ 102.369232] Disabling non-boot CPUs ...
> [ 102.373016] CPU1: shutdown
> [ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1
> [ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1
> [ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1
> [ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1
> [ 104.357482] Could not enter target state in pm_suspend
> [ 104.357666] Enabling non-boot CPUs ...
> [ 104.359863] CPU1: Booted secondary processor
> [ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19)
> [ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19]
> [ 104.360656] CPU1 is up
> [ 104.362579] PM: noirq resume of devices complete after 1.892 msecs
> [ 104.364807] PM: early resume of devices complete after 1.373 msecs
> [ 104.710937] PM: resume of devices complete after 346.099 msecs
> [ 104.817901] Restarting tasks ... done.
This looks like a combination of boot loader/kernel problems. My guess
is that l3init is probably held on by the USB, and both ivahd / tesla
are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least
partially, but also the USB DPLL itself might be in wrong state,
attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are
using? (Can you provide git / commit / config info?)
-Tero
>From 2bde02977db605822ee83042ebc0077ba133277e Mon Sep 17 00:00:00 2001
From: Tero Kristo
Date: Thu, 21 Jun 2012 14:56:40 +0300
Subject: [PATCH 3/7] ARM: OMAP4: clock: setup USB DPLL during init
The reset setup for USB DPLL does not allow idle, thus the kernel must
program it during init. This puts the USB DPLL in locked mode, autoidle
for it is enabled automatically later during the boot sequence.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock44xx_data.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e2b701e..e28950a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3413,6 +3413,7 @@ int __init omap4xxx_clk_init(void)
{
struct omap_clk *c;
u32 cpu_clkflg;
+ struct clk *dpll_usb;
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
@@ -3456,5 +3457,12 @@ int __init omap4xxx_clk_init(void)
*/
clk_enable_init_clocks();
+ /*
+ * Setup USB DPLL
+ */
+ dpll_usb = clk_get(NULL, "dpll_usb_ck");
+
+ clk_set_rate(dpll_usb, 96000);
+
return 0;
}
--
1.7.4.1
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:33 PM, Mark Brown wrote: > On Tue, Nov 06, 2012 at 02:30:19PM +0530, Shubhrajyoti D wrote: >> The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] >> changed the wait_for_completion order. Move the wait so that the >> rx doesnot wait for the tx to complete. > > Applied, thanks. Thanks Mark, -- 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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function]
changed the wait_for_completion order. Move the wait so that the
rx doesnot wait for the tx to complete.
Reported-and-tested-by: Sørensen, Stefan
Signed-off-by: Shubhrajyoti D
---
drivers/spi/spi-omap2-mcspi.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bcfd062..251f6d0 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- u8 * rx;
const u8* tx;
- void __iomem*chstat_reg;
- struct omap2_mcspi_cs *cs = spi->controller_state;
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
count = xfer->len;
- rx = xfer->rx_buf;
tx = xfer->tx_buf;
- chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
if (mcspi_dma->dma_tx) {
struct dma_async_tx_descriptor *tx;
@@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
dma_async_issue_pending(mcspi_dma->dma_tx);
omap2_mcspi_set_dma_req(spi, 0, 1);
- wait_for_completion(&mcspi_dma->dma_tx_completion);
- dma_unmap_single(mcspi->dev, xfer->tx_dma, count,
-DMA_TO_DEVICE);
-
- /* for TX_ONLY mode, be sure all words have shifted out */
- if (rx == NULL) {
- if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_TXS) < 0)
- dev_err(&spi->dev, "TXS timed out\n");
- else if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_EOT) < 0)
- dev_err(&spi->dev, "EOT timed out\n");
- }
}
static unsigned
@@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
struct dma_slave_config cfg;
enum dma_slave_buswidth width;
unsigned es;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
@@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
omap2_mcspi_tx_dma(spi, xfer, cfg);
if (rx != NULL)
- return omap2_mcspi_rx_dma(spi, xfer, cfg, es);
-
+ count = omap2_mcspi_rx_dma(spi, xfer, cfg, es);
+
+ if (tx != NULL) {
+ chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
+ wait_for_completion(&mcspi_dma->dma_tx_completion);
+ dma_unmap_single(mcspi->dev, xfer->tx_dma, xfer->len,
+DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) < 0)
+ dev_err(&spi->dev, "TXS timed out\n");
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) < 0)
+ dev_err(&spi->dev, "EOT timed out\n");
+ }
+ }
return count;
}
--
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
Re: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic
On Mon, 2012-11-05 at 14:25 -0800, Kevin Hilman wrote: > Tero Kristo writes: > > > From: Colin Cross > > > > 'Workaround for ROM bug because of CA9 r2pX gic control' > > register change disables the gic distributor while the secondary > > Just to clarify: this is referring to PATCH 3/8 of this series, correct? > Yes. -Tero -- 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: hdmi on 4430 (kernel 3.4)
Hi Jon, Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter ha scritto: >> I wanted to check the HDMI registers, but I didn't find the hdmi registers >> table on the TRM. >> Does someone have some hint, comment or previous experience on that? >> Where can I find the hdmi registers list on the manual or other >> documentation? >> Note that as far as i know, the 2.6.35 kernel was working correctly (I can't >> check right now, unfortunately). >> Thank you. > > I would recommend posting this query on the TI E2E forum for Linux [1]. > You may get better help there seeing that this is with regard to a > specific TI development kernel branch. > Thank you very much for the suggestion! I'll post there. Can you confirm that the kernel version I am using works without problem with HDMI-1080p? Thanks Cheers Federico -- 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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 06, 2012 at 02:30:19PM +0530, Shubhrajyoti D wrote: > The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] > changed the wait_for_completion order. Move the wait so that the > rx doesnot wait for the tx to complete. Applied, thanks. signature.asc Description: Digital signature
[PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function]
changed the wait_for_completion order. Move the wait so that the
rx doesnot wait for the tx to complete.
Reported-and-tested-by: Sørensen, Stefan
Signed-off-by: Shubhrajyoti D
---
drivers/spi/spi-omap2-mcspi.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bcfd062..251f6d0 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- u8 * rx;
const u8* tx;
- void __iomem*chstat_reg;
- struct omap2_mcspi_cs *cs = spi->controller_state;
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
count = xfer->len;
- rx = xfer->rx_buf;
tx = xfer->tx_buf;
- chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
if (mcspi_dma->dma_tx) {
struct dma_async_tx_descriptor *tx;
@@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
dma_async_issue_pending(mcspi_dma->dma_tx);
omap2_mcspi_set_dma_req(spi, 0, 1);
- wait_for_completion(&mcspi_dma->dma_tx_completion);
- dma_unmap_single(mcspi->dev, xfer->tx_dma, count,
-DMA_TO_DEVICE);
-
- /* for TX_ONLY mode, be sure all words have shifted out */
- if (rx == NULL) {
- if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_TXS) < 0)
- dev_err(&spi->dev, "TXS timed out\n");
- else if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_EOT) < 0)
- dev_err(&spi->dev, "EOT timed out\n");
- }
}
static unsigned
@@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
struct dma_slave_config cfg;
enum dma_slave_buswidth width;
unsigned es;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
@@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
omap2_mcspi_tx_dma(spi, xfer, cfg);
if (rx != NULL)
- return omap2_mcspi_rx_dma(spi, xfer, cfg, es);
-
+ count = omap2_mcspi_rx_dma(spi, xfer, cfg, es);
+
+ if (tx != NULL) {
+ chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0;
+ wait_for_completion(&mcspi_dma->dma_tx_completion);
+ dma_unmap_single(mcspi->dev, xfer->tx_dma, xfer->len,
+DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) < 0)
+ dev_err(&spi->dev, "TXS timed out\n");
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) < 0)
+ dev_err(&spi->dev, "EOT timed out\n");
+ }
+ }
return count;
}
--
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
Re: [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote: > On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren wrote: > > > Is this a public interface to the driver? If so, shouldn't the header be > > in include/linux somewhere? > > I think the split out of the public header is done in patch 2/2. Yes, but the names are still omap_*, which doesn't make much sense here. greg k-h -- 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] mailbox: OMAP: introduce mailbox framework
On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren wrote: > Is this a public interface to the driver? If so, shouldn't the header be > in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yours, Linus Walleij -- 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 0/3] capebus moving omap_devices to mach-omap2
Hi Joel, On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: > Hi Grant, > > On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely > wrote: >> >> >> Joel A Fernandes wrote: >> >>> Hi Grant, >>> >>> On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely >>> wrote: I'm open to suggestions if anyone has any. I have not objections to a fixup approach, but I'm not comfortable with anything that is fragile to modifications to the fragment. >>> >>> I am fairly new to the DT world so please bear with me, but how about >>> a method that resolves symbols the same way that the linux dynamic >>> linker does when shared libraries are loaded? >>> >>> A separate table (similar to .PLT/GOT sections in the ELF object >>> format) could be created when the fragment is loaded, and the phandle >>> references could be fixed to point to the table offsets during compile >>> time. This table would be a second level indirection and the kernel >>> would populate this table with the in-kernel values of the phandles >>> that the dt fragment refers to. >> >> That's an interesting idea that is worth exploring. That would make >> it possible to avoid a fixup stage, but it also means that any parsing >> code must know how to handle the got-like table. It won't be >> backwards compatible with existing tools. It also wouldn't easily >> support the case of firmware applying the overlay and passing the >> resulting tree to the kernel. Hmmm Not being backwards compatible >> at the data level is a big problem. I really want a method that can >> resolve back to the current data format or is a compatible extension >> of it. >> > > Is it meaningful or feasible to make the table a part of the tree > structure itself? the table would initially be empty. If I'm right, > this is how the GOT tables in ELF objects that refer to unresolved > symbols in shared libraries are implemented as well, they are a part > of the object and are loaded into memory and fixed up. If the table is > a part of the DT data, the tools would then be able to parse such a > tree. We could enforce that the got-like tree would strictly follow a > predefined format. > > Something along these lines would also avoid the need for a tree fix > up. Do you think this reduces the difficulty of backward compatibility > with the parsing tools and firmware loading? To be honest here, we are discussing a new object format. There are a few twists IMO. a) We definitely, absolutely, don't want to introduce anything that will risk compatibility with devices already out there. The binary format for device trees that don't need the dynamic resolution features we're talking about here, should be be usable for those older devices. b) Device tree is flexible enough to store the additional data in it's own node format. So we shouldn't have any kind of binary data tacked on; this ties with a) - make sure that the binary format doesn't change. c) There is no need (at least AFAIKT) of having any other resolution type than a phandle of a node. d) Finally, for some use-cases the problem is simplified by not having all the features of a true dynamic linker. For example for the capebus case the 'base' DTS won't have any references to any fragments. It is only the fragments that have unresolved references and only to the 'base' DTS. > >>> >>> This might involve changes to the DT core, but as such, this method >>> wouldn't suffer from the fragility problem of either base or fragment >>> DT trees being modified. >>> >>> The table itself could be added to the tree by the compiler, and the >>> phandles could point to it (fixed). such phandles could be marked for >>> special handling to facilitate the 1-level indirection. >> >> That's part of the problem. Property values are essentially >> anaonymous data. There is no mechanism currently for marking data >> such as indicate which data values are phandles. If there were then >> it would be a simple matter to find all the phandles and fix them up. >> >> We could possibly add data type suppplementary properties to the tree >> to solve that problem. They would have to be optional for the base >> tree to retain backwards compatibility, but could be required on >> overlays. >> > > Sure, so if we add data type supplementary properties to the tree to > indicate the data type as "indirect phandle", then kernel could refer > to the index in the got-like table to fetch the actual phandle address > (1-level of indirection), instead of directly using the address in the > data field. > I'm fine with this. > > Thanks and Regards, > > Joel Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent<->child relation between them. [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. [4/7]: cpsw: simplify the setup of the register pointers [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: cpsw: Kernel warn fix during suspend This patch series has been created on top of net-next/master and tested on BeagleBone platform for NFS boot and basic ping test cases. Mugunthan V N (4): ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support net: cpsw: halt network stack before halting the device during suspend Richard Cochran (1): cpsw: simplify the setup of the register pointers Vaibhav Hiremath (2): net: davinci_mdio: Fix typo mistake in calling runtime-pm api net: cpsw: Add parent<->child relation support between cpsw and mdio Documentation/devicetree/bindings/net/cpsw.txt | 34 arch/arm/boot/dts/am335x-bone.dts |8 + arch/arm/boot/dts/am335x-evm.dts |8 + arch/arm/boot/dts/am33xx.dtsi | 42 + arch/arm/configs/omap2plus_defconfig |3 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32 drivers/net/ethernet/ti/cpsw.c | 231 ++-- drivers/net/ethernet/ti/davinci_mdio.c |2 +- include/linux/platform_data/cpsw.h | 19 -- 9 files changed, 193 insertions(+), 186 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] net: cpsw: halt network stack before halting the device during suspend
Move network stack halt APIs before halting the hardware to ensure no packets are queued to hardware during closing the device during suspend sequence. Signed-off-by: Mugunthan V N --- drivers/net/ethernet/ti/cpsw.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index f94aa8f..b46dbb4 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -698,12 +698,12 @@ static int cpsw_ndo_stop(struct net_device *ndev) struct cpsw_priv *priv = netdev_priv(ndev); cpsw_info(priv, ifdown, "shutting down cpsw device\n"); - cpsw_intr_disable(priv); - cpdma_ctlr_int_ctrl(priv->dma, false); - cpdma_ctlr_stop(priv->dma); netif_stop_queue(priv->ndev); napi_disable(&priv->napi); netif_carrier_off(priv->ndev); + cpsw_intr_disable(priv); + cpdma_ctlr_int_ctrl(priv->dma, false); + cpdma_ctlr_stop(priv->dma); cpsw_ale_stop(priv->ale); for_each_slave(priv, cpsw_slave_stop, priv); pm_runtime_put_sync(&priv->pdev->dev); -- 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 1/7] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Vaibhav Hiremath By mistake (most likely a copy-paste), instead of pm_runtime_get_sync() api, driver is calling pm_runtime_put_sync() api in resume callback function. The bug was introduced by commit id (ae2c07aaf74: davinci_mdio: runtime PM support). Now, the reason why it didn't impact functionality is, the patch has been tested on AM335x-EVM and BeagleBone platform while submitting; and in case of AM335x the MDIO driver doesn't control the module enable/disable part, which is handled by CPSW driver. Signed-off-by: Vaibhav Hiremath Cc: Mugunthan V N Cc: Richard Cochran --- drivers/net/ethernet/ti/davinci_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 51a96db..ae74280 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev) u32 ctrl; spin_lock(&data->lock); - pm_runtime_put_sync(data->dev); + pm_runtime_get_sync(data->dev); /* restart the scan state machine */ ctrl = __raw_readl(&data->regs->control); -- 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 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
Enable CPSW support in defconfig which is present in AM33xx SoC Signed-off-by: Mugunthan V N --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a4b330e..41b595e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -242,3 +242,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_TI_DAVINCI_MDIO=y +CONFIG_TI_DAVINCI_CPDMA=y +CONFIG_TI_CPSW=y -- 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 4/7] cpsw: simplify the setup of the register pointers
From: Richard Cochran
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran
Signed-off-by: Mugunthan V N
---
Documentation/devicetree/bindings/net/cpsw.txt | 34
drivers/net/ethernet/ti/cpsw.c | 209 +--
include/linux/platform_data/cpsw.h | 19 --
3 files changed, 82 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 2214607..6cf5d92 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -9,15 +9,7 @@ Required properties:
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
-- host_port_no : Specifies host port shift
-- cpdma_reg_ofs: Specifies CPDMA submodule register offset
-- cpdma_sram_ofs : Specifies CPDMA SRAM offset
-- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
-- host_port_reg_ofs: Specifies host port register offset
-- hw_stats_reg_ofs : Specifies hardware statistics register offset
-- cpts_reg_ofs : Specifies the offset of the CPTS registers
-- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
@@ -26,8 +18,6 @@ Required properties:
- cpts_active_slave: Specifies the slave to use for time stamping
- cpts_clock_mult : Numerator to convert input clock ticks into
nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
-- slave_reg_ofs: Specifies slave register offset
-- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
@@ -49,15 +39,7 @@ Examples:
interrupts = <55 0x4>;
interrupt-parent = <&intc>;
cpdma_channels = <8>;
- host_port_no = <0>;
- cpdma_reg_ofs = <0x800>;
- cpdma_sram_ofs = <0xa00>;
- ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
- host_port_reg_ofs = <0x108>;
- hw_stats_reg_ofs = <0x900>;
- cpts_reg_ofs = <0xc00>;
- bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
@@ -67,15 +49,11 @@ Examples:
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
- slave_reg_ofs = <0x200>;
- sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = <0x300>;
- sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
@@ -87,15 +65,7 @@ Examples:
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
cpdma_channels = <8>;
- host_port_no = <0>;
- cpdma_reg_ofs = <0x800>;
- cpdma_sram_ofs = <0xa00>;
- ale_reg_ofs = <0xd00>;
ale_entries = <1024>;
- host_port_reg_ofs = <0x108>;
- hw_stats_reg_ofs = <0x900>;
- cpts_reg_ofs = <0xc00>;
- bd_ram_ofs = <0x2000>;
bd_ram_size = <0x2000>;
no_bd_ram = <0>;
rx_descs = <64>;
@@ -105,15 +75,11 @@ Examples:
cpts_clock_mult = <0x8000>;
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
- slave_reg_ofs = <0x200>;
- sliver_reg_ofs = <0xd80>;
phy_id = "davinci_mdio.16:00";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = <0x300>;
- sliver_reg_ofs = <0xdc0>;
phy_id = "davinci_mdio.16:01";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00
[PATCH 5/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N
Signed-off-by: Vaibhav Hiremath
Cc: Richard Cochran
Cc: Benoit Cousson
---
arch/arm/boot/dts/am335x-bone.dts |8 +++
arch/arm/boot/dts/am335x-evm.dts |8 +++
arch/arm/boot/dts/am33xx.dtsi | 42 +
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+&cpsw_emac0 {
+ phy_id = "4a101000.mdio:00";
+};
+
+&cpsw_emac1 {
+ phy_id = "4a101000.mdio:01";
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+&cpsw_emac0 {
+ phy_id = "4a101000.mdio:00";
+};
+
+&cpsw_emac1 {
+ phy_id = "4a101000.mdio:01";
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..2a0c8fe 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,47 @@
interrupt-parent = <&intc>;
interrupts = <91>;
};
+
+ mac: ethernet@4A10 {
+ compatible = "ti,cpsw";
+ ti,hwmods = "cpgmac0";
+ cpdma_channels = <8>;
+ ale_entries = <1024>;
+ bd_ram_size = <0x2000>;
+ no_bd_ram = <0>;
+ rx_descs = <64>;
+ mac_control = <0x20>;
+ slaves = <2>;
+ cpts_active_slave = <0>;
+ cpts_clock_mult = <0x8000>;
+ cpts_clock_shift = <29>;
+ reg = <0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
+ interrupts = <40 41 42 43>;
+ ranges;
+ cpsw_emac0: slave@0 {
+ phy_id = "davinci_mdio.16:00";
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave@1 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "davinci_mdio";
+ bus_freq = <100>;
+ reg = <0x4a101000 0x100>;
+ };
+ };
};
};
--
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 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
This patch adds hwmod entry for davinci MDIO module,
creating parent<->child relationship between CPSW and MDIO module.
This Parent-child relation is required in order to use common resources
like, clock, but still maintaining the logical separation between them.
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci
family of devices, so separate and independent platform devices &
drivers for CPSW and MDIO is implemented.
In case of AM33XX, the resources are shared and common register
bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resources from both drivers.
So the solution is, create parent<->child relationship between
CPGMAC & MDIO modules.
Signed-off-by: Mugunthan V N
Signed-off-by: Vaibhav Hiremath
Cc: Richard Cochran
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..b3f9ce4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -674,6 +674,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.name = "cpgmac0",
.class = &am33xx_cpgmac0_hwmod_class,
.clkdm_name = "cpsw_125mhz_clkdm",
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.mpu_irqs = am33xx_cpgmac0_irqs,
.main_clk = "cpsw_125mhz_gclk",
.prcm = {
@@ -685,6 +686,20 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
};
/*
+ * mdio class
+ */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = "davinci_mdio",
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = "davinci_mdio",
+ .class = &am33xx_mdio_hwmod_class,
+ .clkdm_name = "cpsw_125mhz_clkdm",
+ .main_clk = "cpsw_125mhz_gclk",
+};
+
+/*
* dcan class
*/
static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
@@ -2501,6 +2516,22 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = &am33xx_cpgmac0_hwmod,
+ .slave = &am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
@@ -3371,6 +3402,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_cpgmac0__mdio,
NULL,
};
--
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 2/7] net: cpsw: Add parent<->child relation support between cpsw and mdio
From: Vaibhav Hiremath
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices & drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent<->child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath
Cc: Mugunthan V N
Cc: Richard Cochran
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7654a62..7007aba 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1144,7 +1144,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, "slave") {
struct cpsw_slave_data *slave_data = data->slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -1179,6 +1179,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+* Populate all the child nodes here...
+*/
+ ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn("Doesn't have any child node\n");
+
return 0;
error_ret:
@@ -1212,6 +1220,11 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
priv->msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv->rx_packet_max = max(rx_packet_max, 128);
+ /*
+* This may be required here for child devices.
+*/
+ pm_runtime_enable(&pdev->dev);
+
if (cpsw_probe_dt(&priv->data, pdev)) {
pr_err("cpsw: platform data missing\n");
ret = -ENODEV;
@@ -1238,7 +1251,6 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
for (i = 0; i < data->slaves; i++)
priv->slaves[i].slave_num = i;
- pm_runtime_enable(&pdev->dev);
priv->clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "fck is not found\n");
--
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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 09:07:47AM +0100, Hiremath, Vaibhav wrote:
> On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
> > Hi,
> >
> > On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> > > On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > > > Hi,
> > > >
> > > > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > > > * Felipe Balbi [121030 10:34]:
> > > > > > Hi,
> > > > > >
> > > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > > * Vaibhav Hiremath [121030 07:50]:
> > > > > > > > >
> > > > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt,
> > > > > > > > > which he has
> > > > > > > > > already submitted to the list recently. So MMC support will
> > > > > > > > > come along with
> > > > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets
> > > > > > > > > see how it goes.
> > > > > > >
> > > > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > > > without DMA.
> > > > > >
> > > > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > > > >
> > > > > It should just print a warning instead and continue.
> > > > >
> > > > > > 1869 host->rx_chan = dma_request_channel(mask,
> > > > > > omap_dma_filter_fn, &rx_req);
> > > > > > 1870 if (!host->rx_chan) {
> > > > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain
> > > > > > RX DMA engine channel %u\n", rx_req);
> > > > > > 1872 ret = -ENXIO;
> > > > > > 1873 goto err_irq;
> > > > > > 1874 }
> > > > > > 1875
> > > > > > 1876 host->tx_chan = dma_request_channel(mask,
> > > > > > omap_dma_filter_fn, &tx_req);
> > > > > > 1877 if (!host->tx_chan) {
> > > > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain
> > > > > > TX DMA engine channel %u\n", tx_req);
> > > > > > 1879 ret = -ENXIO;
> > > > > > 1880 goto err_irq;
> > > > > > 1881 }
> > > > > >
> > > > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > > > omap_dma_filter_fn() right ?
> > > > >
> > > > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > > > then there's a bug somewhere.
> > > >
> > > > you're right, there's a static inline nop for when we don't have omap
> > > > dma engine driver compiled.
> > > >
> > > > nevermind.
> > > >
> > >
> > > Did anybody tried polling mode MMC support on OMAP devices in the
> > > past?
> >
> > why are you trying out polling when we have a working interrupt mode ?
> >
> The thread started with need of MMC support without EDMA. So when I
> say polling, I would like to try MMC without DMA support, not to put
> dependency on EDMA-DMA engine migration patches.
I see, so you meant interrupt/PIO mode. That's supposed to be working
and I'm sure Venkat and Balaji test that every now and then.
--
balbi
signature.asc
Description: Digital signature
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
> Hi,
>
> On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> > On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > > Hi,
> > >
> > > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > > * Felipe Balbi [121030 10:34]:
> > > > > Hi,
> > > > >
> > > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > > * Vaibhav Hiremath [121030 07:50]:
> > > > > > > >
> > > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt,
> > > > > > > > which he has
> > > > > > > > already submitted to the list recently. So MMC support will
> > > > > > > > come along with
> > > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
> > > > > > > > how it goes.
> > > > > >
> > > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > > without DMA.
> > > > >
> > > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > > >
> > > > It should just print a warning instead and continue.
> > > >
> > > > > 1869 host->rx_chan = dma_request_channel(mask,
> > > > > omap_dma_filter_fn, &rx_req);
> > > > > 1870 if (!host->rx_chan) {
> > > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX
> > > > > DMA engine channel %u\n", rx_req);
> > > > > 1872 ret = -ENXIO;
> > > > > 1873 goto err_irq;
> > > > > 1874 }
> > > > > 1875
> > > > > 1876 host->tx_chan = dma_request_channel(mask,
> > > > > omap_dma_filter_fn, &tx_req);
> > > > > 1877 if (!host->tx_chan) {
> > > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX
> > > > > DMA engine channel %u\n", tx_req);
> > > > > 1879 ret = -ENXIO;
> > > > > 1880 goto err_irq;
> > > > > 1881 }
> > > > >
> > > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > > omap_dma_filter_fn() right ?
> > > >
> > > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > > then there's a bug somewhere.
> > >
> > > you're right, there's a static inline nop for when we don't have omap
> > > dma engine driver compiled.
> > >
> > > nevermind.
> > >
> >
> > Did anybody tried polling mode MMC support on OMAP devices in the
> > past?
>
> why are you trying out polling when we have a working interrupt mode ?
>
The thread started with need of MMC support without EDMA.
So when I say polling, I would like to try MMC without DMA support, not to
put dependency on EDMA-DMA engine migration patches.
Thanks,
Vaibhav
> --
> balbi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
> On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
> > Hi,
> >
> > On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi [121030 10:34]:
> > > > Hi,
> > > >
> > > > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > > > * Vaibhav Hiremath [121030 07:50]:
> > > > > > >
> > > > > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which
> > > > > > > he has
> > > > > > > already submitted to the list recently. So MMC support will come
> > > > > > > along with
> > > > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
> > > > > > > how it goes.
> > > > >
> > > > > This is a bogus dependency, the MMC driver needs to also work
> > > > > without DMA.
> > > >
> > > > heh, too bad driver errors out when it doesn't find DMA channels :-)
> > >
> > > It should just print a warning instead and continue.
> > >
> > > > 1869 host->rx_chan = dma_request_channel(mask,
> > > > omap_dma_filter_fn, &rx_req);
> > > > 1870 if (!host->rx_chan) {
> > > > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX
> > > > DMA engine channel %u\n", rx_req);
> > > > 1872 ret = -ENXIO;
> > > > 1873 goto err_irq;
> > > > 1874 }
> > > > 1875
> > > > 1876 host->tx_chan = dma_request_channel(mask,
> > > > omap_dma_filter_fn, &tx_req);
> > > > 1877 if (!host->tx_chan) {
> > > > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX
> > > > DMA engine channel %u\n", tx_req);
> > > > 1879 ret = -ENXIO;
> > > > 1880 goto err_irq;
> > > > 1881 }
> > > >
> > > > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > > > omap_dma_filter_fn() right ?
> > >
> > > It should, CONFIG_DMADEVICES is optional. If it does not compile,
> > > then there's a bug somewhere.
> >
> > you're right, there's a static inline nop for when we don't have omap
> > dma engine driver compiled.
> >
> > nevermind.
> >
>
> Did anybody tried polling mode MMC support on OMAP devices in the
> past?
why are you trying out polling when we have a working interrupt mode ?
--
balbi
signature.asc
Description: Digital signature
